The Class
Every year during IAP in January, MIT hosts a class in which students design, build, code, and test robots that must perform specific tasks in competition. These robots are autonomous- once the competition begins, the robot has no help from humans to decide what to do.
Legos are used for the body of the robot. Motors, servos, many different kinds of sensors, and a custom designed microcontroller are used to help the robot complete its tasks.
This year, we had to design a robot that would collect balls from known locations on a game board, and return the balls to our goal.
Much more information about the class and competition can be found at the 6.270 website.
Our Process
We worked quite hard on our robot throughout the month of January, even working through the afternoon, evening, following morning, and following afternoon to complete the robot on time. However, it was a great learning experience, and we are quite pleased with the results. Our process can be roughly grouped into the following categories.
Plan
We spent many hours during the first couple of weeks formulating a strategy, deciding on necessary design features for our robot, and building prototypes to demonstrate how our ideas would work.
We decided that our robot must be simple, small, modular, and flexible. Thus, we planned a simple mechanism for capturing and releasing small balls and finding the goal. We believed that if we could score a couple points reliably regardless of the conditions, we would be in very good shape. We brainstormed ideas for raising the flag and capturing large balls, but decided that our first priority must be to reliably score small balls. Later, we decided we would have more success against more powerful robots if we blocked their goal at the beginning of the match.
Build
Next, we finalized our strategy and began to build the final body of our robot. The body was very strong, but also compact and quite modular. We built a gear box (1:75 gear ratio) and soldered and attached motors to drive the wheels. Finally, we soldered the sensors we would need and tested them with our microcontroller. We used a gyro, breakbeam sensors, bump sensors, and infrared light sensors.
Code
We spent quite a bit of time discussing the design of our code. Although we were confined to coding in C, we decided to use an pseudo object oriented MVC (Model View Controller) paradigm with an extensive use of threading. Each sensor ran in its own thread and acted like a model. In a manner similar to KVO, a controller could ask the model to start or stop observing the value on a sensor, and when the model detected that the sensor value changed by a significant amount, it would "notify" the controller of the change using function pointers. A DriveController "class" abstracted many of the common tasks we wanted our robot to perform, such as driving a particular distance, turning an arbitrary number of degrees, or going forward until the robot hits a wall, or finding a line. The main code simply had to call these DriveController functions to make the robot do something.
Unfortunately, due to time restrictions and bugs in the OS's threading implementation, some of these features were never fully functional for the competition.
Test
We spent the last several days simply testing the robot on the board, fixing bugs, adding timeouts and error handlers, and testing again.The Results
We tied for fifth in the competition, winning our first three matches, and losing our last two. Considering the number of amazing entries into the competition, we are very pleased with how we did.