Understanding Hardware Components
In order to understand each hardware component before construction of the apparatus, we wired and programmed components in separate instances. Our goal was to gain a better understanding of how each piece worked by itself and the ways we could interact with them programmatically. This was also an opportunity to discover any problems in an isolated environment where we could be sure that any problems encountered were strictly related to that device, and not due to a coupled device or due to a transient error introduced as the system grew in complexity. Another advantage of approaching the project this way is it allowed the team to work on different components concurrently.
How did it work out?
For each hardware component we worked to understand its physical and software interfaces. The physical interface is the way in which we connected it, and the software interface is its collection of APIs (libraries) and corresponding outputs. Using the information on what a device takes as input and what form its output is in, we connected multiple devices together with barely more effort and pain than when we worked with each device separately. For example, the team spent over 6 hours getting the radio from one board to communicate with the radio testing base station and with a dummy receiver on our second board. However, integrating that radio logic and functionality into both the base and hover stations took less than an hour.
Since we already tested the components individually, any errors or unexpected reactions could be attributed to the components’ interconnection. Hence, problems could be traced to either incorrect wiring on the bread board or some faulty logic in the way components interacted. This narrowed down the scope of the error, letting us track down and fix it quicker and more painlessly.
Isolating development into separate components also proved helpful to introduce the team to electrical concepts. The team had very little working knowledge of electrical engineering or hardware interfacing, and working on one piece at a time simplified the wiring. Working with hardware gradually prevented the group from feeling overwhelmed. In order to connect all the components, the wiring (even for the voltage regulators!) was trivial. Although this is not an impressive accomplishment since the wiring was rather simple, we are very happy with our progress since the team began with limited knowledge of electrical engineering.
This divide and conquer strategy was invaluable because it eliminated dependencies between components, and left the mechanical design unfettered by needs to test the components.
Our method would work not only for hardware, but for most other mechatronics project as well. Breaking down the project into more easily understandable pieces can help form a mental model of the entire project quicker through its components. This helped to streamline development as well as offer a much clearer view of the project’s progress for time-estimation and planning.
Using this approach, the team was one of the first to complete project 1, while still spending roughly as much time in the lab as other groups.