PurpleLib 2025
(Almost) A Year of Development Later…
Hey y’all,
It’s been a little while since our last full update, but we’ve been hard at work behind the scenes! Over the past year, our team has been actively developing and using PurpleLib, and we’ve rolled out several key features that make it even more flexible and useful for a wider range of teams. Complete documentation is—as always—available on the project’s GitHub repository. In the meantime, here’s a quick summary of the major updates.
Brand New Hardware Support
We’ve added support for several new devices, such as the Canandgyro and ThriftyNova (…pending the release of ThriftyLib 2025). We’ve also greatly expanded our support for CTRE devices, including the TalonFX motor controller (which wraps the new Phoenix 6 API).
One of our most important changes, however, is the addition of support for several new swerve modules—including those made by Swerve Drive Specialities (SDS) and West Coast Products (WCP)—for both REV and CTRE configurations. As of right now, the full list of swerve modules supported is:
- REV MAXSwerve (REV Spark only)
- SDS MK4/MK4i/MK4c/MK4n
- WCP Swerve X/Xi/X2
- TTB Swerve
Since support for more swerve modules has always been one of our most requested feature additions, we’ve also made it easy to add support for custom modules (or those from other vendors) by creating a respective abstract class in the swerve/child directory that follows the structure seen in the other module declarations.
We know this has been a long time coming, so we appreciate your patience 
The full list of supported hardware devices, including swerve modules, is available in the projects README. More information about using swerve modules in particular can be found here.
Swerve Parent Class
With the addition of new swerve modules, we’ve created a universal Swerve Drive template that can be extended to implement a drive subsystem with the same great features, regardless of hardware configuration or chosen module. This parent class currently supports the following functionality:
- Robot rotation PID and anti-tip
- Field centric or robot centric drive
- Automatic module “locking”
- Traction control
- Swerve second order kinematics correction
- Odometry
- Easy PhotonVision integration
- Aim at point (can be used for aiming at targets)
Plus, more features are always on the way!
Additional documentation on the swerve parent class is available here. For an example of how to implement a swerve drive subsystem with PurpleLib, please reference the PurpleSwerve repository.
PhotonVision
This year, our team has also been pouring a lot of effort into our vision systems, which make extensive use of PhotonVision. In terms of PurpleLib, we have created an AprilTag Camera class that wraps much of the PhotonLib boilerplate for pose estimation. It also filters out invalid poses to provide stable, accurate vision localization data to the pose estimator. Moreover, simulation support for AdvantageScope is built in!
Vision Simulation
We’ve also been experimenting with a custom machine learning pipeline on our own fork of PhotonVision, which communicates with a PyTorch script via gRPC. Our goal is to enable us (and other teams) to leverage a custom mini-PC coprocessor for game piece detection, rather than relying on the built-in machine learning pipeline that depends on the RKNN unit exclusive to the Rockchip SoC (used on the Orange Pi).
State Machines
Our team has created several classes that make it easy to implement state machines for any subsystem you desire. This allows improved accessibility over solely command-based infrastructure. For more information, please reference the appropriate documentation here.
High Frequency Odometry
Another exciting feature we’ve implemented is high-frequency pose estimation. This estimation is performed on a thread that updates once every 10 milliseconds (i.e. 100 Hz), while logging still occurs at 50Hz on the main thread, as calls to AdvantageKit “processInputs” are not thread safe.
Health Monitoring
In addition to the device-level logging available in our hardware wrappers through AdvantageKit, we’ve also implemented health monitoring and automatic recovery using the Monitorable abstract class. If a device fails, our wrappers will attempt to reinitialize it up to 3 times by default, before declaring it dead. The status of a device can be read through the isHealthy and isDead methods. This feature is also available at the subsystem level.
Summary
With these recent updates to PurpleLib, we aim to provide the same powerful features across a wider range of hardware configurations. This allows more teams within the FRC community to benefit from our efforts, while also offering existing teams greater flexibility to switch hardware without significantly altering their codebase or sacrificing functionality. Along with an expanding list of devices that serve as drop-in replacements for existing APIs, enabling automatic device-level logging via AdvantageKit, and additional swerve modules, we’ve also implemented a variety of quality-of-life features—with even more on the way! For example, we are currently working on enhancing the realism of robot simulation by integrating physics through maple-sim.
Examples on how to use PurpleLib can be found here, as well as the PurpleSwerve project. Our past season code is also available here. However, these may not be fully updated to use the 2025 version of PurpleLib at the time of this post as our team is off for Winter Break. I’ll make sure to also post a link to the code for our 2025 robot and our OpenAlliance build thread when they become available, so that you can follow our future progress through the season. In the meantime, check out our automatically generated Javadocs here.
