Team Nine/Final Paper

Strategy

We used the map and starting location given to us to attempt localization within the field. From the map we could preplan target poses (location + angle) for each goal point which we used for path planning. Once we arrive at our goal location, the camera was used for alignment. Our strategy was simple: score on each top reactor in sequence, dump red balls over the enemy wall, and then score on the silo.

Mechanical Design

A front roller which fed ball into an archimedes screw to lift the ball. We used a layered design where each layer had a distinct function. On the first layer we mounted all the electronics, the camera, and on the underside we mounted a rack and pinion “tongue” which we planned to use for the energy silo. The second layer was for red balls which had a simple servo powered gate to release them. Color sorting was done using the tablet’s rear view camera and a mirror so we could see the ball as it was going up the screw. A servo mounted on the red layer would then punch the ball off the screw. The third layer was for green balls. An S bend would guide balls single file into a C feeder mechanism that would load up balls into a gate at the end of the layer for top reactor scoring. To keep things modular we used a server rack style design where each of the three layers could be slid in and out and locked into place for easy adjustment. Most of our work was done in the CSAIL machine shop.

Software Design

Our software development strategy revolved around using Robot Operating System (ROS), a free and open-source software framework for building robots. We developed primarily in Python and C++, the main languages ROS supports, on Ubuntu. We split up our code into four main chunks: Firmware, Robot Drivers, Vision, and State Machine. One of the benefits of ROS is that we could develop and debug these four parts as separate modules running in separate processes that could communicate through each other through cross-process messaging.

The Firmware included code for directly interfacing with the electronics, i.e. encoder code, motor controller code, etc... Most of the firmware was written, finished, and tested within the first week. The Robot Drivers served the dual purposes of allowing the computer to communicate with the Maple and wrapping lower-level mechanical behaviors into higher-level goal-oriented behaviors. An example of driver code is the 'open gate' command, which would send commands to the Maple to open the ball gate, wait, then close it again.

Lessons Learned

1. Get parts early - the lab supplies will run out
2. Be careful with your electronics. We managed to only blow up on 5V step down board but we saw a lot of dead maples.
3. Working away from lab takes a lot of time. We did a lot of work at Next House and the CSAIL machine shop and spent a lot of time and effort carrying the robot to and from those places. Work in lab.
4. Noisy IR sensors makes localization hard. 50% of the time our robot thought it was at the completely wrong place on the board.
5. ROS is useful for it’s structure and drop in code for visualization, localization, and odometry but it has a steep learning curve.