Showing posts with label Module. Show all posts
Showing posts with label Module. Show all posts

Tuesday, April 1, 2008

More than meets the eye

Ok, I'm done being eaten by my assignment, so I'm ready to share my brainwave for how to build the chassis. I only got about 2 hours of sleep last night, and I think I've got bird flu so right now the only thing keeping me functioning is copious amounts of amphetamines - I make no guarantees about the coherency of this post.

Right, down to business. In it's current state of design, our robot has no fixed form. We have no assurances about the availability or effectiveness of parts, only the vaguest idea of what the rules are, and we all have different ideas about what would make a good robot. As I have mentioned in previous posts, the best way to deal with this is to incorporate this flux into the design itself.

The chassis is the hardest part to design in this capacity, because it needs to accommodate all of the other parts within it. Since each module is unknown and subject to change, the chassis needs to:

  • Expand or contract in volume to encase parts of any size.
  • Provide mounting points at any location to support parts.
  • Be strong enough to support heavy parts or contain reaction forces.
  • Not be unnecessarily heavy or bulky.
I suggest that we make the chassis like a roll cage out of metal tubes and Y-joints. If we use bolts to hold the assembly together then we can re-configure it's size and shape to whatever we need. We can drill holes in the tubes without compromising much of their strength to join them together, and of course we can always cut longer tubes shorter if we need to.

  • Like lego or meccano, we can reconfigure parts of the chassis without having to buy/design an entirely new one.
  • We can easily extend mounting points by adding Y or X -joints to the scaffold.
  • Strength can be easily increased in a number of ways:
  1. Cross-beams can be added to distribute the load from places
  2. Rigidity can be increased by reinforcing corners and joints
  3. We can upgrade all or part of the chassis - from hollow aluminium to solid aluminium to iron to steel
  • Weight can easily be reduced in places it isn't needed.
Remember that the chassis is not armour. It's primary purpose is to provide mounting points for all the other modules. Once we have got all the pieces working together, we will have several upgrade options available to us: some can be used to strengthen parts of the structure and lighten others. Most importantly, we can continually re-use the pieces, so it won't cost us a fortune!

If anyone has comments or suggestions, please let me know. I will try to get my hands on some suitable material by this Thursday, so that we can use the time in the lab productively. I hope you will all come along to help out!

Sunday, March 23, 2008

Modular Design


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:

  1. Each module can be allocated to a single person, dividing up the work.
  2. Modules can be upgraded easily without having to redesign other parts of the system.
  3. Repairs are made easier because modules are isolated and can be tested separately.
  4. 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:

  1. Crafting the interfaces between modules requires very good communication between team members.
  2. Peer review of components is essential to ensure that they are well engineered.
  3. 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.