AdvantageKit 2024 Beta 5
Beta 5 of AdvantageKit is now released! The changelog can be found on the GitHub release. To update, choose the “WPILib: Manage Vendor Libraries” command in VSCode and click “Check for updates (online)”. This release includes some minor bug fixes and improvements, along with a new example project:
Advanced Swerve Drive Project
This example project shows how high-frequency (e.g. 250Hz) odometry can be implemented in an AdvantageKit project with full support for log replay. This feature is supported on all of the same hardware configurations as the standard swerve drive project, including both SparkMax and TalonFX controllers. For Phoenix devices, both non-Pro and Pro licensed devices are supported and a CANivore is not required.
The drive subsystem code can be found here. Threads are used in the IO implementations to gather data, and the inputs from each drive IO object include arrays of the samples taken between cycles. This allows each sample to be applied independently while keeping all of odometry calculations in the main thread (where they can be replayed).
Note that CAN bus utilization will increase when sending data at high frequencies. We recommend adjusting status frame periods for all devices to reduce traffic, or using multiple CAN buses on supported hardware.
Why Does This Matter?
Given the increased complexity, we felt it was necessary to gather data on how high-frequency odometry impacts accuracy for standard use cases. Note that this data is applicable to any application of this technique, not just the AdvantageKit example. This builds on the work done by CTRE here, which used teleop driving and a very small sample size when comparing 50Hz and 250Hz odometry.
We focused our testing on the accuracy of odometry during an autonomous path with no vision assistance. This is where the accuracy of wheel odometry is most critical — during teleop, additional sensors like vision will always be necessary to maintain accuracy.
Using a NEO-based swerve, we ran a ~12 second PathPlanner auto as shown below. This is intended to be representative of the type of movement that might be seen during an auto path, including holonomic rotations, movement in multiple directions, and occasional hard accelerations.
The start location of the auto is marked with the large white cross, and the robot was commanded to return to the same position. Log data shows that the robot’s odometry always reached the target with negligible error. Using a camera positioned in the ceiling, we are able to estimate the robot’s true ending position based on a tape marker at the center of the robot (example shown below). Any error from the target position to the robot’s position represents odometry error that was accumulated during the path.
We repeated this auto 16 times — 8 times with 50Hz odometry and 8 times with 250Hz odometry. The ending positions are plotted below in meters, where blue is 50Hz and orange in 250Hz. The dark circles represent the average ending position of each set of samples.
The mean error and standard deviations are shown below. Note that the improvement in mean error was relatively small compared to the improvement in standard deviation. In practice, this means that autos are unlikely to be more accurate, but they will be much more consistent/precise.
| Mean Error (m) | Standard Deviation (m) | |
|---|---|---|
| 50Hz | 0.388 | 0.180 |
| 250Hz | 0.297 | 0.028 |
| % Improvement | 23.3% | 84.4% |
CTRE’s testing also measured the impact of timestamp synchronization with a Phoenix Pro licensed CANivore bus. Their data for that testing is available here, and is based on a larger sample size with autonomous driving. They found a % improvement in error of 15.5% and in standard deviation of 34.1%. While a modest improvement compared to high-frequency odometry, this is a nice benefit for Phoenix Pro users (CANivore timestamp synchronization is supported by the AdvantageKit template on compatible hardware).