Mobile Robot Programming Laboratory
In Fall of '09, I took a class at Carnegie Mellon University called Mobile Robot Programming Laboratory.In this class, I worked on a team to program a Nomad Scout Robot in Java to perform increasingly difficult tasks: from turning to face a moving target, to following a moving target at a certain distance, to following a pre-determined path, to navigating a maze dynamically, and finally to competing with other robots to collect as many pieces of "gold" as possible and bringing them back to us.
The Nomad Scout robots were simple devices that had two solid rubber wheels, sixteen sonar sensors, and mounts for laptops, magnets, and cameras. In spite of their small size, these things could move at amazing speeds, and could even be dangerous if used improperly. To program them, we would simply interface with the internal controllers using a simple serial port interface and a laptop. The robots would "see" piecies of blue paper over iron slabs-- "gold" -- and pick them up using a powerful magnet, and then bring them back to us.
Above all, I learned one very important lesson from this class: robotics is hard, and cooperative robotics is even harder! Things which would be trivial in simulated enviornments or video games (areas which I am most familiar with) become nearly impossible when applied to robots in the real world.
The reason for this is simple: robots don't ever have an indication of exactly where they are in the world. In a simulation, everything has a position, an orientation, and a velocity stored somewhere in memory, all of which can be accessed instantaneously. In the real world, these qualities have to be calculated, or measured. But since sensors are noisy, odometry is flawed, and conditions in the real world fluctuate with time, measuring these things is an incredibly difficult practice of statistical analysis combined with calculus.
As for robotic cooperation, it takes all of the same issues and multiplies them by the number of robots cooperating! If you think race conditions, deadlock, and syncronization are headache inducing issues in parallel programming, imagine all of these issues when a race condition means a physical collision at 15 MPH, deadlock means robots sitting in place for hours on end until they run out of batteries, and failure of synchronization means robots running into walls and human beings. Every problem of parallel programming has a physical manifestation in robotics, and the stakes are twice as high.
Nevertheless, I enjoyed this class extremely much. It was amazingly fun to watch changes in my code having a real impact on the robot's performance, and by the end I was very proud of my little Nomad Scout. I managed to make it through with an A, in spite of some early hangups.