In order to run more consistent and accurate autonomous routines, we have looked into implementing either Team 3015’s PathPlanner or WPILIB’s PathWeaver, both path-generation tools with their own advantages.
PATH PLANNER
Our team decided to use PathPlanner at first due to its appealing user interface and began experimenting with the software near the end of the off-season. After configuring the AutonBuilder with the Ramsete Controller, we got our flatbot to reach its desired target with a margin of error of 3 inches. However, we ran into trouble when attempting to create a path that allowed our robot to drive in reverse. Initially, our flatbot would drive forward rather than backward. As a workaround, we resorted to detecting whether the reversed boolean in the path was true and manually inverting the motors. While that allowed us to travel in reverse, our robot would now aggressively turn. We believed this was due to the difference between how PathPlanner calculates its angles and how the gyro reports its angles. PathPlanner uses an angle of 0 to -180 degrees on the robot’s left side and 0 to 180 degrees on the right, while the gyro reports an angle from 0 to 360. So when our robot heading was set to 180, it would turn, and PathPlanner would want it to be negative, but it would still be positive. We attempted to change how the gyro reported its angles to match PathPlanner, but we continued to run into issues. By week 3, our team decided that getting our robot to travel in reverse through a path planner would have to become an off-season task and we resorted to switching to PathWeaver. While the GUI was less attractive, our team realized that it had more support as a WPILIB tool and was better suited for differential drives.
PATHWEAVER
System Identification
The first thing we did was system identification of the robot. We created an identification routine that included two types of tests: quasistatic and dynamic, each run once forward and backward. For each test, we logged the data for the applied voltage, velocity, and position to the roboRIO and attempted to load the files in the System Identification Tool.
However, we got an error saying we did not have enough data to run the acceleration calculation. Thanks to the help of a WPILIB docs maintainer, we were able to figure out that instead of running each of the four tests separately, which would produce four log files, we needed to run all four tests together (without disabling the robot), which gave us only one log file. After doing this, we recorded the ks, kv, ka, and kp values from the feedforward analysis.
Trajectory Following
First, we followed WPILIB’s tutorial for following a trajectory, creating a Ramsete Command using our robot specific sysid values.
We managed to create a simple path consisting of two trajectories that would make the robot drive 2 meters forward and back, but we noticed a lot of stuttering every time we increased the robot’s speed. Interestingly, the robot would also drive backward at the end of every trajectory as if correcting for overshooting, even though it was undershooting by about 12 inches every time.
Robot Stutter
We realized that the issue was our ka value. The ka value should be very small for light drivetrains, but we had a ka value close to 2. By changing this value to 0, we eliminated the stutter and decreased our margin of error to roughly 4 inches. This error did not change with increasing maximum speeds or accelerations.
We were also able to combine our trajectories with autonomous limelight alignment, where the robot could correct itself to its original angle after rotating to face an AprilTag and complete its intended path with accuracy.
Limelight Align with PathWeaver
Finally, putting everything together, our team created an accurate 3-note autonomous path with a maximum velocity of 4 m/s and a maximum acceleration of 3 m/s^2. Our flatbot can complete the path in roughly 8 seconds, giving us 7 seconds for alignment and shooting.
We had a nice crowd of our 
