Note for all sample codes:
serial monitor baudrate shd be set to 19200(in serial monitor) for 9600(in code)
Download all sample code
With the help of pandemic data, explore/see the turbulent relationship within reported/death rates among major travel hubs.
Research different mechanisms for generating movement. Found several inspirations from automata. Able to represent time versus value data with simple cam mechanism. Further augmented with linkages/gears etc.
Some visual ideas for representing the data as a wave of sorts:
General overview of how installation will appear (very much work in progress).
Build a simplified prototype to learn more. many adjustments were required to obtain a simple model:
- holes need to fit well but not be too loose-fitting
- angle of chamfers/smoothness of surfaces affect movement
- trying to lock cam shapes onto a thin rod was very challenging(thus switched to threaded rod)
this style of cam locking is not ideal, but will suffice for now. an addition of spring on the rods will allow the model to be used upside down and also perhaps resolve potential pulling strength issues.
- build a larger scale cam model
- experiment with rods as linkages
- experiment with drawn cam shapes to better represent ‘data’
- finalise frame scaffold so that can start build
The reading had quite a few very relatable examples that I myself have experienced during my brief decade of working.
Eventually, the superintendent admitted that this was the largest pour he had ever undertaken and that he had not asked anyone for help in planning the concrete pour. The contractor spent the next three months fixing the mistake, a mistake that could have been avoided had a work plan been developed based on sound practical experience.
I thought this was a very relevant example of how a seemingly small shortcut can lead to a much larger inconvenience and loss. I think this same lesson can be applied from everyday tasks to month/year-long endeavours. Also, the other key lesson is to know your limitations and when/where to seek help when necessary. Yet, I think there is also a conundrum when it comes to knowing where something can be learnt by iterative experimentation. This is perhaps more applicable in our academic setting, where learning by doing is imperative. The ability to decide when to experiment and when to seek help is a thin but necessary line to maneuver, both in school and at the workplace.
A contingency of 10 percent is a very common percentage, but other percentages may make more sense taking into account project specifics.
This is something I feel has been slowly built into my psyche from my years of good and bad experience working at several places/environments. I think it is just good practice to always have some leeway in whatever you do, even something as mundane as buying ingredients for cooking. Mistakes, spoilages, different proportions etc will most surely force you to unnecessarily make another trip back to the store. Likewise, for my personal projects in making, I have learnt I always need more wood, screws, wheels(you get the idea) than I planned, no matter how immaculate of a CAD I prepared.
A task is an essential activity or increment of work. Every task requires three elements to fully define it.
- An objective
- A duration
- A level of effort
This seemingly silly and simplistic paragraph is effective for distilling the essence of what we do every day. Everything should have these three elements, and a significant compromise in any(mostly point 2 & 3) is undesirable. I have witnessed many colleagues and sometimes myself how an unreasonable amount of time is spent on a task without reflection on how it can be accomplished more effectively. However, this also comes with a certain level of experience; how can one know he/she is spending too much time on something if he/she has never done it many times before to attain a frame of reference? My best guess is to ask around how others have done similar tasks or have a best-guess estimate(err on underestimating with a margin for error). I think this estimation is crucial as it allows one to be fully aware of the process and not be buried in an endless cycle of perfection/completion/struggling, unless it is a one-task project you are trying to achieve. Realistically, different areas of a project require different levels of finesse, so it would also make sense that amount of time and effort commensurate accordingly.
Outline of a Typical Project Work Plan Document
- Project objectives
- General description of the project…
- Major project objectives
- Major milestones…
- Project construction budget…
- Deliverables by milestones…
This last section of chapter 5 is the backbone of any mid-long term project. I think it is always helpful to have an outline similar to this when tackling any project of sufficient complexity. The milestones(with dates) allow one to be wary of how much ahead/behind one is, and whether any adjustments to the design, and consequently workload, has to be made. Project objectives are also likely continually adjusted to corroborate with changing designs. Budget ensures that one doesn’t get into trouble, especially with finishing the project; half done project = no project = all money wasted. Budgeting can also give a sense of whether the design is too wasteful or can be modified for more economical material options. Deliverables by milestones is a useful self-check mechanism for keeping your team of one(or many) in check, in a very honest and direct manner; it is either done or not done, nothing ambiguous or in between.