One of the first things that we need to decide on is how we are going to approach this problem. Nobody on this team has any experience with building combat robots – or any sort of robots for that matter. This means that we don’t have a good idea of the areas that need the most work, or the problems that we will face during the build.
I would like to suggest that we design and construct this robot in small pieces (modules) to allow the design to evolve over time. In my experience, projects never work out the way that you think they will, so it is critically important that we keep our options open during the execution of this project. The following diagram is an example of the different subsystems that need to be engineered:
Using a modular approach gives us a number of advantages:
- Each module can be allocated to a single person, dividing up the work.
- Modules can be upgraded easily without having to redesign other parts of the system.
- Repairs are made easier because modules are isolated and can be tested separately.
- Each team member gets experience at designing an entire product from start to finish.
However, designing a robot in modules has some drawbacks as well:
- Crafting the interfaces between modules requires very good communication between team members.
- Peer review of components is essential to ensure that they are well engineered.
- The overall design process is more complex, but it is divided amongst more people.
I feel that this approach is suitable for us because the choices you make in the early stages of a project don’t come back to haunt you later when you realise you didn’t fully understand the situation. In my experience, this design strategy is a little more difficult at the start, but saves a lot of time later on due to its flexibility.
Please tell me what you all think.
= Self Destruct