Software
The software for Fili-bust-a-move was surprisingly simple. Early on, a skeleton framework was set up to allow for a complex state machine and different code modules for the various divisions of robot functionality (drive, sensing, navigation, game events simulated with keyboard presses, etc). However, the task at hand did not turn out to be so complex, so many modules were unused or not filled in by the final competition. Our control logic was as simple as: if you see the enemy in front, drive forward. If you see the enemy on the right, turn right. If you see the opponent on the left, turn left. If you do not see the opponent, turn the direction that you saw the opponent last. This simple logic did an excellent job of tracking our opponents during the tournament. Tape sensing turned out to be nonessential, because as soon as we pushed the opponent into the moat, we would lose their beacon signal, and start turning in place, thus not following them over the edge. Because we worked straight up until the end, the code was not as neatly integrated as we would have liked, but it did the job admirably.
All code was run on an Arduino Uno.
The code was organized into several modules as follows:
All code was run on an Arduino Uno.
The code was organized into several modules as follows:
- Filibuster.ino: main .ino file containing simple state machine and control loop.
- definitions.h: module for program wide definitions - enum types, etc.
- drive.h / drive.cpp: module for initializing the motors and driving the robot in various directions.
- beaconSense.h / beaconSense.cpp: module for interfacing to the IR beacon sensing circuit, including checking which sensors could see a target, and multiplexing through the different sensors.
- tapeSense.h / tapeSense.cpp (unused in final code): module for reading from the tape sensors.
- stateMachine.h / stateMachine.cpp (unused in final code): module for holding various state machines and selecting which one to use - we had different state machines for beating the minimum class requirements (defeating "The Brick"), responding to game events simulated by keyboard presses for testing / debugging purposes, and for the final competition. In theory, this would have allowed us to select different game strategies against different opponents based on human judgement during the different rounds of competition. We ended up not using these state machines in the final competition (our control loop was based in Filibuster.ino), but did use them for defeating The Brick and testing/debugging purposes during development.
- keyboardEvents.h / keyboardEvents.cpp (unused in final code): module for detecting / parsing keyboard events to simulate game events. To be used for testing / development purposes.
- navigation.h / navigation.cpp (unused in final code): module for keeping track of the absolute positions of us, our opponent, and The Sequester on the field. This module would have been used if we had a more complex strategy depending on our positioning, such as the Wall-hugger strategy.
final_filibuster_frozen.zip | |
File Size: | 185 kb |
File Type: | zip |