With the addition of persistent alerts, would you say that it is more appropriate to remove the fields below from the Inputs class and replace them with Alerts instead?
@AutoLog
public static class ModuleIOInputs {
public boolean driveConnected = false;
...
public boolean turnConnected = false;
...
}
I understand that they will probably show up in AdvantageScope in somewhat the same format but I think having them show up as alerts in shuffleboard has it’s advantages.
And if not, are there any downsides/performance issues I’m missing?
My recommendation would be to include the connection status in the inputs object, then create and activate alerts at the subsystem level. AdvantageKit logs alerts as outputs, so this structure allows you to access alerts in the log file or via Shuffleboard while minimizing the amount of logic in the IO implementation. It also allows you to adjust or examine the logic for alerts in replay, which may be helpful for those that are more complex (like an alert where the text changes dynamically).
We ran into some issues when trying to implement sysId into our code.
We followed the following guide for setting up sysId in our code and exporting the data in AdvantageScope:
After we had exported our data in the wpilog format with AdvantageKit cycles as timestamps we were able to import everything correctly into the sysId application. Next, we dragged the sysId state string and the right velocity, position and voltage to the correct fields in the data selector. After we pressed ‘Load’ in the data selector tab in sysId, we got the following error:
Which is strange, because our logs were definitely longer than 3 entries.
In the zip file below you will find the log we downloaded from the robot in combination with the exported log with the right timestamps for sysId.
The sysId state string is under ‘RealOutputs/Drive’ and the velocity, position and voltage fields are under ‘Swerve/Module i’
It looks like the log file you posted only includes a quasistic forward test. SysId requires that you run all four tests (quasistatic and dynamic, both forwards and backwards) to do any analysis, and all of the tests should be in the same log file with no duplicates. The error message could definitely be improved to make the issue more clear.
You’ll need to pull it down ( the Elevators branch ) , and run the update.bat (windows ) , update.sh ( mac ) to use the automated build scripts. We hadn’t had these issues pre 2025 wpilib.
It looks like your project is missing the quickbuf dependency that is normally provided by GradleRIO (here). You should be able to fix it by adding that library to your dependencies, though in general this isn’t a build setup that we can provide support for.
The 2025 kickoff release of AdvantageKit is now available! Returning users should check the What’s New in 2025? page of the documentation. Feedback, feature requests, and bug reports are welcome on the issues page.
To get started, we highly recommend starting with one of the template projects and copying code from other projects as necessary. The template projects have been updated to support the 2025 versions of WPILib and vendor libraries. Note that this release does NOT include the AdvantageKit vision template as PhotonVision/PhotonLib 2025 is not available yet. We will release the updated version of the vision template once PhotonVision 2025 is available.
This release switches Maven hosting from GitHub Packages to the WPILib Artifactory site. This change will improve the stability of Maven hosting and simplify the installation process. Please see the updated installation docs for details, or download one of the updated template projects.
Template Project Updates
Teams updating from previous versions of the templates should carefully review and apply the relevant changes listed in the release notes, as this release includes several important fixes. Additionally, teams should review the template updates published December 2024 related to annotation processing and garbage collection.
Regarding Talon FXS compatibility
CTRE has announced that the Talon FXS will be compatible with the Tuner X swerve project generator, which the AdvantageKit swerve template utilizes. While we would like to offer support to teams using the new controllers for swerve drives, the delayed schedule of their release has severely restricted our ability to develop and test template updates to support the Talon FXS.
Our goal during the season is to minimize template changes and ensure a stable experience for users. Teams should be aware that support for the Talon FXS in the 2025 AdvantageKit templates is very unlikely due to their delayed release schedule and CTRE’s switch away from a source-visible swerve library for future updates. The AdvantageKit templates are designed with customization in mind, and we encourage teams to manually adapt them to support alternative hardware configurations.
2025 FIRST KitBot Template Project
This release includes a new 2025 KitBot template project, which can be downloaded from the GitHub release. The features of this project include:
Support for both brushed and brushless motors on the Spark Max/Flex, Talon FX, and Talon SRX
Modern command-based code structure
Simple built-in auto routine using PathPlanner
Physics simulation of the drive and roller subsystems
Compatible with AdvantageScope’s KitBot 3D robot model
Hi, congratulations on the kick-off release! I love it!
I have a small question: in the changelog, it mentions that the Vision example has received some upgrades. However, I wasn’t able to find a link to download it in the release assets.
What version did you update from when switching to 2025? If it was previously a 2025 beta project, make sure you’ve applied the template updates published last month which related to annotation processing. If it was previously a 2024 project, there are significant changes to build.gradle and the VSCode settings from 2024 to 2025. This is why we highly recommend starting from one of the 2025 template projects and copying code from previous projects as required.
Glad I checked here. I started going through the gradle changes before the season but missed the other template project updates.
I’m having the same issues as @meer.com with the generated AutoLogged classes for annotation logging. I’ll keep poking at it and reply here if/when I’m successful.
Update : Wow that was quick… Reminder if you used the import tool, things in your build.gradle likely got changed. (I am a goofball and didn’t think twice on that)
Question: Why does the SparkBase template not include config options that are separate for each module?
Context: We have a drive train that is all CTRE except we have Smaxes hooked up to NEOs as our turn motors. This has led to me comparing the two swerve templates to each other a lot. So far I’ve been using the talonFX version for everything except DriveConstants. Do you think that’s the best way to do this?
I’m very excited for accesible high frequency odometery! Thank you for all the work you put in to open source templates. I love being able to look at and understand the code + why it works/is structured the way it is.
For reference here is what I’ve written. I have everything working in simulation, but haven’t gotten hands on a robot yet.
The DriveConstants file for the Spark template includes some constants which are the same between all modules (wheel radius, gear ratios, etc) and some which are specific to each module (CAN IDs, encoders offset, etc). The only reason that the TalonFX template has independent sets of constants for each module is that the generated TunerConstants file structures things that way; the template itself is designed around the specific constants structure provided by CTRE.
In general, the Spark version is the more “universal” of the two AdvantageKit swerve templates since DriveConstants isn’t specifically tied to REVLib. A combination of DriveConstants from the Spark template plus part of the module implementation from the TalonFX template is probably the best way to go in your situation.
