This year, we have been preparing for some big improvements to our approach to programming Autonomous. Over the summer, we started work on ThunderAuto, a custom path-generation app for creating autonomous modes for Holonomic drive bases. It allows us to easily create paths using its Bézier curve editor and export them to CSV files for use on the Robot. The choice to create our own application over using pre-existing ones was to give us complete control over the process and to serve as a great learning experience. Since ThunderAuto is new, a few features aren’t fully implemented yet such as undo history, unsaved file dialog warnings, etc.
This season for programming Autonomous, our strategy is to make the robot’s task as configurable as possible. The plan is to use a custom mode-selection system on our Dashboard as shown below, that sends options over Network Tables to the robot.
Based on selections, an Autonomous mode will be constructed using multiple different ThunderAuto paths.
With the addition of AprilTags to this season’s game, we knew that we wanted to have software that could use them to help with accurately estimating the robot’s pose. We determined early on that running vision processing software on the roboRIO would not be ideal because of performance issues that we might encounter.
During the pre-season, we started writing AprilTag vision processing code into RollingRaspberry, our software for Raspberry Pi co-processors. Although not completely refined yet, we have been actively testing it and improving its functionality. One of the biggest problems that we’ve been trying to solve is resolving pose ambiguity, which we can hopefully reduce once we start testing with multiple cameras.
Scoring can take some time, so why not try to make it easier for the drivers? We are planning to create a dynamic trajectory generation system for automatically handling alignment to the grid for scoring. After consulting with our drivers, we evaluated a few key things to take into consideration. Firstly, they requested an easy-to-use control interface – specifically something that is not 9 buttons corresponding to the 9 scoring locations. Other than that, they wanted peace of mind that they could override the path at any moment in case things go awry.
The current plan for the control interface is using the current position of the robot within the community to determine which grid it’s in front of. Then the driver can use the left, right, and down directions of the controller’s D-pad to specify which column of the grid to align with. This creates a simple interface that is easy to visualize and does not require much thought on the part of the driver. Automation can be easily overridden by moving either of the joysticks to initiate manual control of the drivetrain.
Github - ThunderAuto
Github - RollingRaspberry
Github - Dashboard