Let me tell you: one can’t build a robot except for that case when you are just having fun, learning, experimenting, adding new details, trying to combine components differently, etc. There is one important point here: you are not setting any targets
and not planning any specific results. On the other hand, when you are working on a project and expect to get certain
results, planning is unavoidable. Some people say, “Let’s begin, and then we shall see what to
do next”. But think for a moment: how are you going to achieve any results when you don’t have the slightest idea what components you require, whether there are enough pins on Arduino, for instance, or whether there’s enough power for your System, etc. These little things should make you fall to thinking. Here is one more example: I have recently returned from a camp, where teenagers were working on their Arduino projects. Even those kids, who
had planned their projects beforehand, faced such difficulties as, for instance, the lack of space in the body of the device, which made it hard at the
debugging stage to remove Arduino and upload a new sketch without having to dissemble the device
completely. Naturally, if you perform that many operations, you spend so much time, and in the end, you don’t have enough of it. Here comes another example: a student is constructing an excellent Assistant
sysadmin – a robot, which can learn to reproduce the sequence of your claps and make buzzing sounds of a set range and frequency when it’s running in the background. The student has built the body of the device, realized one mode and then the second one. However, one day before the actual presentation of the project, the
student sees that the two modes do not correlate with each other, and a new
solution has to be found. Thank god, the solution has been found, but it always happens in such a rush. There are various approaches to design and planning. Every organization that specializes in industrial production of
equipment and software has its own methodology and combinations. In software design, many try to stick to certain approaches, when the requirements for the final results are specified every so often, so in the end, the project is realized after being run a multitude of times. I personally prefer the approach advocated by one of my
acquaintances, chief technical officer in a company which designs and implements ambitious large-scale hardware and software systems. This approach presupposes that one would not start implementing the system in practice, while there is still no detailed development plan. The plan should be done in such minute detail, that every
researcher would understand how particular sections run. Thus, one would not have to waste time on experiments, tests, research or learning, as everything will have been done beforehand. These sections correlate thanks to the fact that all this has been mentioned in the plan. This company’s experience shows that the planning/design ration is usually 3 to 1, which means that planning takes 3 times longer than the implementation of the project
itself. Overall, the time consumed to manufacture the product is substantially lower than in an alternative situation, when the requirements are specified
stage by stage, and the project is realized while it’s still “raw”. When it comes to commercial production, you need to accept the rules and customs which exist in the company. But for now, while we are still leaning to assemble simple
devices, I would recommend bearing in mind two principles which exist in the ideology of the above-mentioned company. The first one is: I believe that one cannot proceed with design unless the final results of the project have been specified in detail. In other words, we need to write out how exactly we are going to test our
device in order to check whether or not it performs the actions that it was initially supposed to
perform. If we write out this description, in fact, we will find it easier to describe in detail smaller components of this
device: the general description will be followed by more a detailed description, until the device is described so elaborately that it becomes super simple to
actually build it. The second point which needs to be taken into account is the fact that one should not proceed with design while there are still some unexplored facts. For instance, we might not know what solution we are going to take concerning this or that device node,
or we might not be sure how exactly the device works, how to code or power it - all these details have to do with the operation of different device
nodes. In reality, when I have classes with teenagers in camps, I always promote the importance of planning, and in the end it always turns out that those who do the planning, achieve the desired results faster. Plus, the quality of their device is
usually higher. Let’s imagine what actions WaterMe will be performing and what we will need to plan these actions. I will draw it in the form of a diagram, as usual, but first, we will need to write out the purpose of our project.