Team Seventeen/Final Paper
Contents |
Strategy
Initially, we planned to focus on ball collection and depositing in the high ports of reactors. We decided that the additional points to be gained from depositing balls in the low port were not worth the design challenge of having two mechanisms for depositing balls. Moreover, we decided to collect only green balls at the beginning of the game, before depositing, and red balls at the end. This would allow us to forgo a ball sorting mechanism and additional collection area.
Due to time constraints, we were unable to make our robot deposit balls. Instead, we tried to pick up as many balls as possible, of either color, and hold them in a collection tube. Our robot would bounce around off walls - detecting and avoiding them with short-range infrared sensors - and follow balls detected with vision. Upon getting stuck on something or oscillating back and forth in a corner, our robot would back up and turn away.
Design
Our robot uses a mounted camera to detect red and green balls. It uses a belt-driven claw elevator to scoop balls from ground level to an elevated platform. The goal of this elevator was to deposit balls in the high port of reactors. We designed and built a platform at the top of the elevator to hold two to three balls and deposit them with a servo-powered gate. Before the final competition, we dismounted the servo and replaced the end of the chute with an enclosed tube leading down to the base of the robot, for ball storage. The claw on the elevator flings balls into this tube.
Software Architecture
Our software comprises five interacting java classes. RobotBrain contains setup and loop methods which initialize the game state using pre-set constants and continually sends commands to the Arduino. The loop method contains high-level strategy, including methods like goToLargestBall. The brain contains references to the other parts of the robot - the controller, eye, world, and mouth - and coordinates between them. The RobotController class uses an instance of MapleComm to send controls to the robot on every loop. It keeps track of current encoder and infrared information and past error in position and orientation. Using a PID controller and position and orientation targets set by RobotBrain, the sendControl method determines the motor speeds to send to the Arduino. The RobotEye class processes images from the webcam. Though it implements line detection as well as red and green circle detection, we use it only for circle detection. Using a series of filters - color filters, blurring, hough circle transform - the process method returns an accurate list of detected red and green balls. To avoid lags in updating strategy and sending control signals, the eye runs continuously in a thread separate from the brain. Upon receiving new data from the eye, the brain updates an instance of RobotWorld, which forms the model. Though RobotWorld only keeps track of balls, it communicates with BotClient to receive and store the map. We hoped to use the map to create a grid of occupied and unoccupied squares and use long-range infrared sensors for localization within the playing field, but were unable to complete it in time. RobotWorld contains methods visible to the brain for determining ball positions. There were also a number of struct-like classes used for storing and sharing data - SensorData, Error, Ball, EyeData, etc. Finally, RobotMouth uses a TTS library to dictate the robot's current strategy.
The Arduino runs a modified version of the Maple firmware provided by the staff.
Things We Learned
We learned how to build a robot! None of us had experience building robots before MASLAB. Each piece of electronics was new to (most of) us, and simply being able to get information out of the sensors and to control the motors was a learning experience. We also learned a lot about mechanical design and how to fit parts together. Winter learned SolidWorks from scratch. We all learned how to use a laser cutter and became more familiar with the basic tools used to build robots.
Lessons, Advice, Regrets
- Electronics are easy to break.
- Voltages should always be checked before turning power on.
- 5V != 16V
- 16V != ground
- Wiring should be clean and color-coded, and long wires should be avoided.
- Building a prototype as early as possible would have gone a long way - there are always little mechanical problems that require you to reprint.
- Avoid complex design choices - choose the simplest option.
Acknowledgements
Thanks to the MASLAB staff for all the work they put in to make this competition happen, and for their patience when we broke stuff, fell behind, and generally messed up. They were always ready to help - from walking us through how to use parts to debugging code and wiring. Thanks to David for helping us build two of our prototypes and for lending us your Arduino - we probably would have fallen even further behind without your help. Thanks to the sponsors for letting us build a robot for free! We wouldn't have been able to build a robot without all the parts paid for by sponsors. Lastly thanks to Charles Guan for letting us use the lab. It was a great place to work and we contributed to its utter destruction.
