Team Four/Paper
From Maslab 2006
| Maslab teams |
|---|
| Team 1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 · 9 · 10 · 11 · 12 · 13 · 15 |
| Team Four's Journal · Paper |
Contents |
Overall Strategy
Our basic strategy was to have a quick, reliable, high-capacity mechanical design which coupled with extremely fast threaded code would allow our bot to keep moving at all times, thus increasing the territory covered and balls collected. Instead of agonizing over the super ball or probabilistically optimizing the number of balls to be dropped in each goal, we would focus on making the most of the long time period we were given. After our primary mechanical designer had to leave in the first week, we split the work between the three remaining team members: Bryan handled the mechanical design and assembly; Christine worked on sensor code (including color calibration), meeting the checkpoints, and any miscellaneous programming; Gene worked on image processing and mapping algorithms in C, as well as overall software architecture.
Mechanical Design
Our mechanical design was based around a full-width conveyor belt which would collect in any ball which the bot ran over while moving forwards. The conveyor belt pulled balls up a 45 degree incline into a ball hopper which would store extra balls. Once ensnared by the belt, balls would not fall out unless the belt was run in reverse. The adjustment of the conveyor belt was obviously very important and would require constant change, so the entire system was mounted with slots and could slide up and down, changing the distance between rollers (to change belt tension) and between the rollers and the incline.
The other components, including drive train, battery, eden/orc-board, etc, fit under this incline. The optical mice were attached very close to the ground on adjustable mechanical stand-offs. We were able to take apart the mice and remove parts (such as the scroll wheel) and they still worked fine, which was great. The
Materials and Design Process
The primary material used was laser cut acrylic. Lexan would have been preferable because it is less brittle, but it releases toxic chemicals when laser cut. Acrylic puts out enough fumes already, plus it’s cheap and was sold at the Central Machine Shop, so we went with that option. Bryan spent more than a week modeling the robot in SolidWorks (available for free to MIT students!), which may or may not have been a great idea. He learnt a lot, but the time might have been better spent. Once modeled, blue-print-like diagrams could be directly printed to the laser cutter.
The laser cutter used is a CO2 model in the Stata Center available though a friend of ours. We were inexperienced with the cutter, so there were a few mistakes and imperfections. Due to focusing issues, the beam did not always make a clean cut, and sometimes the plastic would melt back together. As a result the parts had to be knocked out of the raw sheet, and one of the main side panels was cracked; we fixed this with our awesome, I-Can’t-Belive-It’s-Not-Illegal, neuron crushing epoxy. This epoxy haunts us in our sleep with it’s carcinogenic bouquet. The second mistake was throwing out the camera mount piece, which was very thin and long and we missed it while knocking out pieces. We didn’t have time to re-cut, so we replaced this with some extruded aluminum. Lastly, our acrylic piece was too large to entirely fit in the cutter, and when we were adjusting the position to cut the second half of the sheet, we forgot to flip it over, and one of the parts ended up sticking over the edge into a previously cut part. As a result our ball hopper area did not interlock correctly. We easily fixed this last problem with some duct tape.
Software design
For our software design, on the highest level we decided to go with a finite state machine. Based upon the lectures given in class, a finite state machine seemed to be the best compromise between the rigidity of the model plan act approach and the unpredictability of the stateless, emergent behavior approach.
We designed this state machine to have the broad states of general exploring, gathering balls, bringing balls to the goal, halting, finding balls, and finding goals. Within these states were more specialized states which encompassed and integrated all the moving, random wandering, scanning and decision making we needed the controlled environment of the Maslab playing field.
We abstracted away the senses of the robot, letting these run on different threads so that the control center could call upon and integrate sense data without being impeded by the speed of its collection. Image processing was done entirely in C, allowing us to calculate all the data we needed to act quickly and accurately. The interface between the finite state machine and the image processing was through a mapping class which would integrate and process information from vision. This was a helpful interface, the state machine could merely query for the relevant information regarding specific features on the playing field as well as the shortest paths between those features. We also integrated an IRSensor at the front of our robot, as a bit of an error correction to our vision as we were integrating and testing the C libraries, this IR sensor was positioned at the front of the robot, such that the robot would, in the worst case, know that there was a wall in front of it with or without vision.
Actually sensing elements were handled through an abstract sensing class which had just two simple methods, updateData and getData. Sensors ran on their own threads. This design made the integrating and addition of new sensors especially easy and as we coded sensors we made sure to code them generally enough such that adding in one of the same sensors on a different port would just involve instantiating a new class and mentioning the port number.
Our odometry was done with two optical mice, a simple way of getting reliable information about our position and heading. It took quite awhile to get the two mice to report usable data, and the drift of the mice was much much more than expected. We didn't have enough time to properly calibrate them, but they were useful even in their crudely calibrated state. Data was reported in terms of delta x and y from the previous position; this coupled with the old absolute position and heading allowed us to calculate the new absolute position and heading.
Within the image processing, we used a generated lookup table to identify pixel colors. The table was generated once on the C side when the image processing was initialized. We processed in RGB space, and generated the table by calibrating "pure" color coordinates in this space, and then every other possible coordinate in RGB space was associated with the nearest "pure" color coordinate.
Overall performance
Our performance on the first few checkpoints was excellent, we got working code straight away and started concentrating on more interesting and harder problems, such as the physical design of the robot, intricate mapping, our C vision libraries, and the novel optical odometry. Unfortunately we became too specialized in our individual task and there were integration issues in the end, especially in the last few days. In the final competition the integration issues showed as there was a threading issue within our finite state machine which prevented us from adequately highlighting the work we had put into the robot by exploring the field and illustrating our mapping capabilities. Overall performance was consequently disappointing in the end.
Conclusions/suggestions for future teams
In the end, our team would advise getting the mice up and running more quickly (please do contact us for details, if necessary), and spending more time on calibration and testing. In addition, do not see optical mice as a cure all for the drift and errors seen in traditional optical encoders and gyros. It is indeed possible to achieve greater accuracy (especially in heading) over the more traditional methods, but methods of error correction must be employed. A third or even fourth optical mouse and more testing would have been greatly useful.
While image processing could be done in milliseconds in C, coding in both Java and C introduced some bugs in the real-time analysis of the images. Debugging was difficult in the end, but we feel that the speed of the image processing allowed us to have an advantage over other teams in that we could always be working with the most up to date information and didn't need to worry about waiting too long for the sense data to be updated. We recommend building image processing up gradually and testing incrementally, rather than trying to develop and end all be all API leaving few days for testing. In addition, testing on static images is absolutely not a substitute for good old fashion real time testing. As we saw in the final contest, the team which won had a simple but functional design which they had working extremely early on. At times our team's motto was "don't build it now, if we're not going to use it later" but truly in a month long robotics competition, designing scalable, testable, and usable code from the getgo is absolutely crucial.
