Tuesday, September 15, 2009

Modular Robotics Platform (MRP)


Note: This is actually a repost of something from an older blog, just to catalog one of my projects. This writing is old, written when I was newly a college senior. I've learned a lot since then, and can probably do this project in half the time, ten times as well, for a fraction of the cost. Such is the benefit of having hindsight.



The Modular Robotics Platform (MRP) is finished (and has been for some time now). My project group (three of us in total) are currently working in writing the project documentation required for this school project. I spent the summer working with this team in order to develop the prototype, and it is something I am quite proud of. It isn't perfect, and I can rally off a list of things I would do different. The important thing is that the robot gets the job we set out to do done.

As a recap, the MRP is designed to be a modular (duh) robotics platform that can be used in robotics research and educational platform. Mechanically it is designed to be easily modifiable, electronically it allows for quick sensor and circuit design and implementation/testing, and in the realm of computer science (which was my main focus, although I worked on a bit of everything) the MRP allows for the quick development of programs and even the rapid replacement of its entire operating system. All of this for reproduction price of $1200-$1500, though I know several ways to cut price significantly.


Here's a list of some features:

Mechanical:

  1. The drive train is designed to accept either a motor or a servo by just sliding it in. The drive train can also be attached at any point on the frame.
  2. The frame is made from Item, a brand name extruded aluminum. With special connectors available from item, you can practically connect anything to the frame at any place at any angle, maximizing mechanical modularity and expandability.
  3. The robot is big enough to handle simple out doors obstacles, yet small and light enough for storage and being carried around by students

Electrical:

  1. 15 Digital I/Os that can be expanded by advanced users to over 150 I/Os, 5 ADCs, control of up to 8 servos simultaneously and four 12 volt/3 amp max motors.
  2. Rechargeable battery means you can recharge while working on it. Battery also lasts for 1.5 hours under standard usage.
  3. Fuse block design keeps all parts isolated and safe from blow outs.
  4. AVR Subsystems (to be explained later).
Computer Science

  1. TS-7800 ARM9 Embedded Board @ 500MHz. It runs Debian Linux, booting off of either its on board flash, an SD card (which I used for this project) or a microSD card.
    1. This also means that users can not only take their code with them, but can also literally swap out entire operating systems in a matter of seconds.
  2. Small C library developed to allow easy user control of the robot's hardware.
  3. Modification of some aspects of Debian Linux to make it more suitable for robotics applications.
The AVR Subsystems

One of my favorite features of the MRP was its AVR subsystem.
The AVR subsystem consists of 6 AVR chips. While in dedicated positions on this rendition of the MRP, I would make them more open on future versions. Each AVR pictured is an Atmel168, a powerful micro controller for which there are tons of projects on the web for. Easy to develop for and powerful, it can be used for any number of calculations. The only vertical chip in the picture is considered the "communications" chip, which talks to the MRP's main processor via serial. This chip communicates, passing either small commands or receiving simple values in return from the other 5 AVR chips. For this particular PCB board, we've assigned a "default" usage for these chips. Four of the chips are each dedicated to a single quadrature encoder (built into the drive train we designed). These chips keep count of each of the encoders and, when requested, return their current value or reset the counter. The fifth AVR chip is a stepper motor driver circuit, so a stepper motor could be smoothly controlled separate of all processes.

The AVR subsystem was done using socketable AVRs in the hopes that students or researchers could, if needed, pop them out of their socket and reprogram them to do another task. The PCB design did not leave this too open ended, but future renditions of the MRP should.

The Final Word

I learned an obscene amount on this project and loved every minute of it. Will there be future versions of the MRP? Who knows. As of now it won't be used in the future robotics classes at WPI, but that was a long shot anyway. I am proud of the work I did and think I hit a home run with the project.

No comments:

Post a Comment