We expect that vendors will be releasing their beta software soon that supports this version, as well as NI releasing the beta 2024 roboRIO image (which is required to run this version of WPILib on a robot). Python is not included in this release; there will be a separate beta release for it soon.
Please keep an eye on the beta project discussions for further announcements and report issues/provide feedback in that venue–the WPILib team, vendors, and NI will all be monitoring the forums and working to address issues. A pre-emptive thank you to all who test the beta and provide feedback!
Check out what’s new for 2024 and jump directly to the WPILib installation guide. You’ll see in the changelog that the focus for 2024 has largely been on stability and performance improvements rather than new features.
If you’re starting from a 2023 robot project, note you will need to import it to create a 2024 project.
I’ll end with another thank you. There have been over 350 commits to the main WPILib repository since the last 2023 release touching over 2000 files. I’m pleased to share that in addition to a lot of work from the WPILib core team, there are also commits from 12 new community contributors in that period–thank you for helping make WPILib better for all teams!
You all are amazing! I’ve always told new programmers on my team how easy it is to use WPILib as a beginner, and that it’s the best documented programming library I’ve used. Very excited about all of these new changes!
Might be worth adding that there is now a function in ChassisSpeeds to account for skew, as mentioned by Tyler here, since it’s quite nice to have built in now.
I’m encountering a strange issue, when I create a new project and add a vendor library it fails to build, with the following error:
An exception occurred applying plugin request [id: 'edu.wpi.first.GradleRIO', version: '2024.1.1-beta-1']
> Failed to apply plugin class 'edu.wpi.first.gradlerio.wpi.WPIPlugin'.
> Could not create an instance of type edu.wpi.first.gradlerio.wpi.WPIExtension.
> Vendor Dependency photonlib has invalid year null. Expected to be 2024
I get this error no matter what vendor library I add, REVLib, PhotonLib, etc. Again, this is on a fresh project, though this also occurs on an imported project too.
With no vendor libraries, the project builds fine.
I’m running Linux, and I installed the fixed WPILib 2024 beta release from 15 October.
Thats a new error to stop teams from using incompatible previous year vendor deps from working. So its doing its job. Got to wait for vendor libraries that are compatible with Beta.
What is the state of swerve drivetrain characterization? Please don’t say SysID.
In 2023 WPILib, SysID didn’t get sorted out until what felt like week 6 of build season. It wasn’t even included in the first few WPILib distributions. Our team had zero luck using SysId, having used it the previous 2 years successfully. Numbers generated by the 2023 SysID were gibberish. This despite reusing SysID configuration data from previous years, fiddling with various settings, re-running. Frustratingly SysID did not like using CANivores, and would always reset the CAN bus name every time we saved the configuration files.
Sorry for a lack of precise feedback. All this SysID fiddling happened between week 6 and our week 1 competition. We were a little short on time to synthesize a comprehensive bug report, capture graphs, and record numbers.
We had good characterization constants from two previous Swerve Drives (1 heavy comp bot from 2022 and a smaller test bot) and ended up interpolating the constants we used in the 2023 season from those numbers.
Our team’s plan for characterization in 2024 is to explore other methods. What are other people doing to characterize their swerve drivetrains?
We’re running SDS mk4i with falcons in case that matters. Next year, we’ll be running (knock on wood) kraken motors on mk4is. Presumably this will have an impact on characterization.
Our current numbers:
// units = Volts. (divide constants by 12 if using percent output)
// heavy =~ 140lbs light =~ 70-80 lbs
DRIVE_KS = 0.6; // 0.628 for heavy, 0.53114 light
DRIVE_KV = 2.344; // 2.344 for heavy, 2.3423 light
DRIVE_KA = 0.35; // 0.435 for heavy, 0.12817 light
I know there are changes to improve SysId for 2024, but in case it’s useful in the meantime I’ll throw out an alternative solution.
We stopped using SysId in 2022 because of the unreliable project generation and the fact that we never used any of the data besides kS and kV. It turns out that for many systems, no kA and a bit of manual PID tuning is perfectly sufficient — we run all of our swerve drives this way, plus a host of other mechanisms. Instead of SysId, we wrote a command (FeedForwardCharacterization) that takes a generic voltage consumer and velocity supplier, then runs a ramping routine, fits a linear model, and prints kS and kV to the console. We have a drive method that takes a voltage (and controls the modules to 0°, no need for blocks) and the characterization is set up as an auto routine. The same thing works for other mechanisms like flywheels.
It takes a bit of manual setup, but for our use cases this has been simple and reliable. The changes to SysId for 2024 should hopefully address its reliability issues though (I’ll let others speak on that front if desired).
The built-in robot project in SysID has been a maintenance nightmare (as it easily broke with vendor changes and had to support many difficult-to-test combinations), and the problems were exacerbated in 2023 due to the NT changes (and various bugs) interacting poorly with the SysID tool and robot project, which relied heavily on NT to perform real-time collection of data.
The plan for SysID for 2024 is to remove the built-in project entirely, and instead make SysID an offline analysis tool only. Instead of deploying a project and capturing live data in SysID itself, a library and examples will be provided for teams to add appropriate data logging into their normal robot programs. SysID will be updated to read these captured data logs to perform the analysis. This work is still in progress.
Another fun thing we can do, since we have a monorepo, is move the OLS parts of SysId into wpimath so user code can do whatever fits they want. A libsysid might be a better idea since wpimath is already huge, and we need a place to put the user-side logging.
So we have the beta NI and wpilib tools installed, have flashed our RIO and confirmed that the 2024 v1.1 image is running on our RIO.
We’ve build a blank template and it compiles but will not deploy, we get this error:
admin @ roborio-271-FRC: Connected.
Reason: InvalidImageException
Could not parse image version!
/etc/natinst/share/scs_imagemetadata.ini contents:
[ImageMetadata]
IMAGEDESCRIPTION = “”
IMAGEID = “{979268BF-16F8-4042-BAA6-7AF50D001CEE}”
IMAGETITLE = “roboRIO2 Image”
IMAGEVERSION = “roboRIO2_2024_v1.1”
