25 days 144 screws 4,737 lines of code
Introducing PropellerBot
PropellerBot is a mobile robot designed to play the ME 218 GIT-inspired game during which it has to navigate around a game field and push blocks against another robot opponent.
The Game
The ME218 game board consists of two home regions ("Repos"), three lanes ("branches"), three moveable walls ("Commits"), and four IR beacons (each emitting a signal of a different frequency).
During a game, one robot starts in the local repo and the other in the remote repo. Both robots are placed in a random orientation. Using the IR beacons on the game board, a robot must determine at the start of the game which “team”, local or remote, it has been placed on. The branches on the game board are accessible by both opposing robots. The goal of the game is for the robot to push the commits down the branches towards the other team’s repo. After 2 minutes and 18 seconds, whichever robot has more area in the branches on their side of the game board wins. |
Functionality Description
PropellerBot is designed to find IR beacons, push commits to the end of a branch, and navigate its home repository outside of the branches. The chassis has two motor-powered wheels and two castor wheels, allowing the bot to move forward, backwards, and rotate about its center. The drive train includes a 2:1 gear ratio to increase the speed of PropellerBot.
When game play begins, PropellerBot rotates in place until it locates the IR beacon. The IR signal is detected by a photo transistor located in the central tower, and processed by a signal conditioning board below. PropellerBot then uses optical sensors (located underneath the chassis) to align with the tape on the gameboard and follow this tape down the branch. When it hits the commit, it accelerates, and pushes the commit to the end of the branch before returning to its own repo. In the repo, PropellerBot waits for the user to press the button corresponding to the branch it should travel to next. Once a branch is selected, PropellerBot navigates to that branch and goes down the branch, pushing the commit to the end and returning to the repo. This repeats for two minutes and eighteen seconds, the duration of game play.
When game play begins, PropellerBot rotates in place until it locates the IR beacon. The IR signal is detected by a photo transistor located in the central tower, and processed by a signal conditioning board below. PropellerBot then uses optical sensors (located underneath the chassis) to align with the tape on the gameboard and follow this tape down the branch. When it hits the commit, it accelerates, and pushes the commit to the end of the branch before returning to its own repo. In the repo, PropellerBot waits for the user to press the button corresponding to the branch it should travel to next. Once a branch is selected, PropellerBot navigates to that branch and goes down the branch, pushing the commit to the end and returning to the repo. This repeats for two minutes and eighteen seconds, the duration of game play.
PropellerBot has several ways to indicate its status during game play. When the game begins, the propeller on the front of the bot begins moving back and forth, and continues moving until the gameplay timer expires. During the initial scan for the beacon and alignment, the bot uses the frequency of the beacon it detects to determine if it is in the local or remote repo. A red LED turns on if the robot is in the local repo, and a blue LED turns on if the bot is in the remote repo. During the game, whenever the robot returns to its home repo and is ready for player input, an additional green LED lights up. This indicates that the player can select the next branch. Whenever PropellerBot is lost in the repo and needs position adjustment, the player can press the yellow start button again. This will turn on a white LED, which indicates that the branch buttons have been remapped to initiate small adjustments in the robots position: turning clockwise, counterclockwise, or moving forward.
|
The functionality of PropellerBot is implemented using two PIC32 microcontrollers. One acts as a leader, in charge of the communication between the two, and the other is a follower, relying on commands from the leader to know what to execute next. The leader is running a hierarchical state chart containing four state machines. This is how the robot is able to transition between different functionalities during the game. While the main sensors are connected to the leader, the motors are connected to the follower so communication is key for the robot to play the game. We used SPI communication between the two devices.
Semi-Finals Competition
During the semi-finals, we implemented our "emergency" game play where we directly controlled the navigation of our robot in the home repository. This significantly slowed us down, but allowed us to play!
Gems of Wisdom (for future ME218 students)
- When you have a bug, remember to check your hardware! We often ran into problems and tried debugging on the software side when it was really a hardware issue.
- Create the state chart as a team! We did this and it was very helpful to ensure we were all on the same page early on in the project.
- Implement an “emergency” game mode. Our robot was not doing what we had planned at the last minute but we had a way to re-map our interaction buttons so that we could better control the robot and still play the game.
- Adding a mechanical advantage (gearbox, big propeller fan, etc) takes a lot of time. Always strive towards the MVP first. This project is harder than it seems.
- If your phototransistor stops working with the same circuit, try another one.
- Plan for more time than you need for each step of the project.
- Keep a stash of snacks in SPDL or in your backpack.
- Take breaks and get enough sleep!
- Read past year’s team’s Gem’s of Wisdom.
- Use acrylic gears.
Meet the Team!
Left to right in left photo above: Kara Herson, M.S. Mechanical Engineering, Rachel Wallstrom, M.S. Mechanical Engineering, Olivia Tomasetti, Ph.D. Candidate Mechanical Engineering.