Mobile Robot Programming

Here's our team "Batteries Not Included" with our dressed up robots. These pictures are from the final competition, held 11/27/2001. From left to right, our team members were: Rob Siemborski, Da Xu, myself, and Norm Tubman.
A picture of our group "Batteries Not Included".	A bird's eye view of one of the mazes.	Yet another picture of our group and robots.

Each team had a pair of robots placed in a maze. The mazes were all symetrical so each match had a team on each half of the maze. The mazes all had a dividing line so the teams could not leave their half of the maze. On the walls we balanced 'gold' (a bright green sheet of paper sitting on a hunk of metal). The objective was to collect 5 pieces of gold.

This sounds pretty easy until you consider everything that might go wrong. Some pieces of gold are accessible to both teams, so there's a race to pick those up. The robots on the same team could interfere with each other by planning intersecting paths. The robot might not be stable and knock over a wall, possibly knocking over some gold as well! There could be a bug in our code effectively killing one robot. The camera might give false readings since the lighting conditions are certainly not uniform. Or even mechanical failure, the robot's sonars could die! This laundry list is far from complete, but each of these issues was to be addressed in code.

So the focus was not only on a fast robot, or an intelligent one, but rather on a robust program that could gracefully handle failures. Different teams had their own solutions. One group (which didn't make it to the semi-finals) decided that managing two robots was simply too difficult and had one hide in a corner while the other did all the work! Crazy as it sounds, this isn't a bad idea since you always have a backup plan. Another group implemented traffic rules, when two robots are about to collide, one of them waits while the other gets out of the way. This leads to some funny (and in one case fatal) behavior, but works in general.

In our group, we had implemented a lot of things that did not make it into our final robot. Early on, our robot was quite fast, but we decided that the risk of shoving walls was too high and so we end up with reasonably fast but very stable movement code. Our sonars were optimized to only fire the sonars that we needed. This was a big speed boost, but left us incredibly vulnerable to "sonar death" so we removed that code. We had our robot running 'vdr' movement, this allowed it to make very graceful and smooth turns resulting in a huge speed gain on winding corridors. This too was deemed too unstable since it occassionally clipped corners. As for planning, we had each robot plan a full path and the second robot would never cross it. This is quite restrictive and we wanted the other robot to atleast start moving towards a goal. This optimization never made it to the finished product either.

We're proud of what did make the final cut. Our robots planned their way to a goal using a speedy algorithm called 'brushfire' (aka 'wavefront') which was tweaked heavily and renamed 'forestfire'. The robots also communicated properly maintaining a shared notion of the state of the maze. Should a robot get lost, we used a seperate planner to perform localization. Combining these three, our robots performed very well in our simulator. The movement code was slowed down and ended up being very reliable. The remainning issue was the camera. This was never solved completely so we had our robots revisit all the gold after they were finished. This worked very well and got us an extra piece of gold in the preliminary matches. Surprisingly, no other team added this improvement. Overall our robot was very fault tolerant which earned us a spot in the semi-finals.

The day of the final competition there were four teams left, leaving two semi-final rounds and one competition. Plus the winner of the competition would then play a human controlled pair of robots. Our team, Batteries Not Included, played in the second semi-final match. In the first semi-final match, one team immediately lost a robot to an unknown failure, yet still managed to win the match in an amazing stroke of luck. In our match however, there were no failures and the other team was just plain faster. Thus we were eliminated by the eventual winner. The final match was quite interesting as well. Again one team immediately lost a robot, so the outcome seemed obvious. However an unfortate glitch occured to the other team late in the match, so the first team seemed destined to win. In fact they just had to use their one remaining robot to collect all the gold and it would be just enough to win. So the tables were turned and once again the outcome seemed obvious. But wouldn't you know it, another g litch crippled this final robot costing them the title! Neither team collected five pieces, and the winner of the competition was decided on a technicality.

Anyway, I really enjoyed this course and HIGHLY recommend it. For a 12 unit course it's not quite as demanding as I expected. It ends a few weeks before the end of the semester too, which is really nice. It's taught only in the fall and a follow-up research-type course is offered in the spring.