Complex Computational Systems: Planning is Key
Written 2008-05-31
Tags:Building Robotics Robot Wars Programming Robot Competitions Mutual exclusion Artificial intelligence
I'd have to say that programming a robot from the ground-up is the most complex project I've ever worked on. Granted, we built this robot from aluminum, motors, gears, and wire. The three items we didn't build are a set of stereo vision cameras, a computer, and a small power-controller. And how do we integrate the separate software projects?
Earlier this year, the electrical, mechanical, and computing groups sat and decided upon the best way to integrate these systems. We created a document outlining which other systems a given module would need to communicate with. Groups were then responsible for creating message passing interfaces between their modules.
Fast forward to today. Every module works quite well in its own environment. The vision system can pick out white road-lines and construction signs when the robot is parked. The drive system is so simple it requires only three lines of code to move the robot. The AI can drive through a virtual model every time. But we're at competition now-and nothing works. One person is gluing it all together. He asked me for help, and there are global pointers everywhere. After a few hours, it started to work. It is the most complex, ugly thing I've seen. Every so often, there are segfaults whenever code ignored mutexes (there are actually pointers to mutex-protected memory).
For such a volatile system, it's working surprisingly well. This system goes against every design standard I've seen-it is a barrel full of monkeys all shouting commands at each other, and every so often monkeys shout at the same time, and scream louder, making the other monkeys act funny. But all-in-all, it looks like its working, even if we neglected to test before the competition.
Earlier this year, the electrical, mechanical, and computing groups sat and decided upon the best way to integrate these systems. We created a document outlining which other systems a given module would need to communicate with. Groups were then responsible for creating message passing interfaces between their modules.
Fast forward to today. Every module works quite well in its own environment. The vision system can pick out white road-lines and construction signs when the robot is parked. The drive system is so simple it requires only three lines of code to move the robot. The AI can drive through a virtual model every time. But we're at competition now-and nothing works. One person is gluing it all together. He asked me for help, and there are global pointers everywhere. After a few hours, it started to work. It is the most complex, ugly thing I've seen. Every so often, there are segfaults whenever code ignored mutexes (there are actually pointers to mutex-protected memory).
For such a volatile system, it's working surprisingly well. This system goes against every design standard I've seen-it is a barrel full of monkeys all shouting commands at each other, and every so often monkeys shout at the same time, and scream louder, making the other monkeys act funny. But all-in-all, it looks like its working, even if we neglected to test before the competition.