[WPILib Blog] 2023 Kickoff Release of WPILib

Posted 20230104 on 2023 Kickoff Release of WPILib — WPILib

We are pleased to announce the availability of the 2023 kickoff release (2023.1.1) of WPILib, the official FIRST libraries for robot programming in Java and C++.

Changes for 2023

There have been many additions and new features added by the C++ and Java WPILib development team over the past year. We encourage all teams to read the New for 2023 page in the documentation for all the details! Some statistics (just for the main WPILib repository): 559 commits were made since 2022.4.1 by 39 contributors, touching nearly 3,000 files, with 167,711 added and 77,007 removed lines.

Installation Instructions

Note: Minimum system requirements have changed for 2023. WPILib now requires 64-bit Windows 10 or 11, Ubuntu 22.04, or macOS 11 or higher. Newly supported this year is Apple Silicon (arm64)! We have dropped support for older platforms including Windows 7, Ubuntu 20.04, and macOS 10.15. C++ teams should note that Visual Studio 2022 is now required for desktop builds. For this release, Mac users will need to have the Xcode Command Line Tools installed before running the installer; we are working on removing this requirement in a future release. This can be done by running xcode-select --install in the Terminal.

Thanks and an Ask

WPILib is run by a small team of volunteers and the community. Many of the features and tools included in WPILib started as community projects or ideas. As the new season begins, we challenge you when writing the next exciting project or feature to think about how you can best share your work with the community! Some projects would be great additions to WPILib and we would love the chance to include them. This is also true of any issues you run into using the current library, we are always looking to make things better for teams! We encourage you to talk to us and discuss what you are doing and how it could fit into future plans. You can reach us on GitHub, Discord, and Chief Delphi.

WPILib’s core members are as follows.

  • Ryan Blue (Ryan_Blue)
  • Jason Daming (jdaming)
  • Thad House (Thad_House)
  • Peter Johnson (Peter_Johnson)
  • Prateek Machiraju (Prateek_M)
  • Brad Miller (BradAMiller)
  • Joe Pokorny (jpokornyiii)
  • Joe Ross (Joe_Ross)
  • Austin Shalit (AustinShalit)
  • Yotam Shlomi (starlight220)
  • Dalton Smith (Daltz3)
  • Dustin Spicuzza (virtuald)
  • Tyler Veness (calcmogul)
  • Vasista Vovveti (vyo)
  • Zhiquan Yeo (zeequeue)

We would also like to call out the translation coordinators for the documentation. These people help make WPILib accessible to teams all around the world.

  • Ofek Ashery (Hebrew)
  • Regis Bekale (French)
  • Hasan Bilgin (Turkish)
  • Bruno Toso (Portuguese)
  • Max Cuevas (Spanish)
  • Yeve Rivkin (Hebrew)
  • Heber Sepúlveda (Spanish)
  • Atlas Zhang (Chinese)
  • Min Zhang (Chinese)

Major past contributors to WPILib include Eli Barnett, Jaci Brunning, Sam Carlberg, Evan Gilgenbach, Alex Henning, Jonathan Leitschuh, James Kuszmaul, Toby Macaluso, Paul Malmsten, Peter Mitrano, Kevin O’Brien, Grant Perkins, Patrick Plenefisch, Fred Silberberg, and Griffin Tabor.

In addition to these volunteers, many members of the community contribute code, open issues, give ideas, and provide feedback. A huge thanks to these members of the community for their amazing contributions to the library and to the many beta testers this fall.

45 Likes

Great! Now we just need the official releases of the vendor dependencies, and we’ll be good to go updating for the 2023 season! I’m looking forward to using the command convenience functions, they’ll remove the need for our own functions that do the same thing.

Any idea when NI will release the rio image?

I don’t have anything more specific than what is stated in the docs right now: “Game Tools will likely be available sometime on 1/4 or 1/5.”

1 Like

Follow up question - is there a reason that the JDK version was updated to JDK 17, but the source and target versions are still 11 when creating a project from template? I guess what I’m asking is, are we expected to be able to use Java 17 features (records, pattern matching) or is there a robot reason to keep it at 11?

sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11

We are running a 17 JRE on the robot side too, but this is the first year we’re doing so. 17 removed the garbage collector we used on 11, so forcing the version to 11 for one year makes it a lot lower risk to do an emergency rollback to the 11 JRE (even on a per-team basis) if that is deemed necessary. We haven’t seen any issues in beta, so the risk seems relatively low, but we don’t know for sure until we see a full season of use. The plan is to change to default to 17 for 2024.

So essentially, it’s fine to change that and use 17 features, but we thought it made sense to keep 11 as the default for this year “just in case”.

4 Likes

I’m saying this for myself and the thousands of other programmers who will use the new wpilib: Thank you!
We appreciate the tremendous amount of work we know all of you put into it, and are looking forward to using the new features.

23 Likes

It’s been amazing to see the continued development on WPILib over the past few years. It’s especially great to be able to take on more of an advisory role, and watch a wave of younger contributors perform the bulk of the Command-based work this past year - nothing makes me happier than seeing the project become even more self-sustaining in its growth.

The difference in the quality of the tooling available to teams between now and half a decade ago is hard to really put into words, and the difference in the health and vibrancy of the community is even bigger. I can pop on the FRC discord with an idea, and there’ll always be a volunteer to help implement it or else someone to tell me why it’s not worth doing. The amount of talent going into this framework is wonderful, and I can’t wait to see what it looks like after another 5 years of this sort of high-velocity community development.

Remember: this library is what it is because of the community. No one developer, or even handful of developers, makes this happen - it happens because of contributions from all over, big and small. I implore teams with surplus programming resources to consider upstreaming code back to WPILib, or even to just spend the time to make a github issue or two. Involvement from users is, and will always be, the primary driver of improvement.

23 Likes

SwerveDriveOdometry and SwerveDrivePoseEstimator now use wheel distances instead of wheel speeds; Use SwerveModulePosition to represent a swerve module’s angle and distance driven

Hmmm, will this now incur some auto inaccuracies with the Spark Max position measurement lag? AFAIK, velocity measurements on the Spark Max did not suffer that lag (although I’m sure there are errors trying to integrate velocity over large distances). We had good success with the old behaviour on our Summer swerve project. I hope this change doesn’t break that.

1 Like

It’s the other way around- velocity measurements on the Spark MAX are subject to a 112ms measurement delay, whereas position measurements are immediate (besides CAN latency). This change should improve odometry accuracy across the board, even compared to using velocity measurements that are not delayed.

14 Likes

So issue with Spark Max. I’m assuming this will be fixed when they release their updated api.

Getting the relative encoder using .getEncoder() throws the following error at compile time.

error: cannot access SpeedController
RelativeEncoder encoder = sparkMax.getEncoder();
^
class file for edu.wpi.first.wpilibj.SpeedController not found

Yep, SpeedController was removed. You’ll need REVLib 2023.

The 2023 Game Tools (which include the image) were released this morning.

1 Like

Has that been released yet. It doesn’t show on the SparkMax site

1 Like

Not that I know of.

Please do not link to beta software.

The entire reason beta still requires an application even though anyone can join is to prevent beta software from being accidentally used during the season. Sharing beta links publicly defeats this.

6 Likes

Teams show up to competition with prior year roboRIO images, prior year versions of WPILib, beta versions of WPILib, and the kickoff release of WPILib despite there being more recent versions of everything. Teams are bad at keeping things up to date.

By making beta artifacts harder to obtain, it at least reduces the number of teams showing up to competition with beta software that the CSAs then have to spend time upgrading to make them pass inspection.

Nothing is preventing teams from using outdated software accidentally during the season. The beta software is at least vaguely compatible with the in-season software, where old software is not. In certain cases of breaking changes, teams that accidentally use the previous year’s software will have to do a major refactor to upgrade.

As a CSA, I’d rather a team have the beta software than the previous season’s software. “Whoops there’s an esoteric bug in this beta release that you didn’t even notice, here’s a flash drive, install and you’re good to go” is a lot easier than “whoops you’re using last year’s software, you need to install the new stuff and also refactor your code because method names have been changed and previously deprecated things have been completely removed”.

A public “beta software” page with a big red “DON’T USE THIS SOFTWARE AFTER JANUARY 7TH” warning would be a better, less obtuse solution.

I don’t see a team upgrading to the beta and forgetting to upgrade to the full release, that wouldn’t otherwise be using outdated software if the beta weren’t public, as a substantially likely risk.

1 Like

In my experience, teams don’t read, let alone remember to do things later based on what they read, but we did add that to the latest beta release page a few days ago.

4 Likes

The WPILib beta releases are public (right?)

It’s just the rest of the beta software (vendor deps, rio image, and game tools) that is hidden

The public WPILib beta releases make the hidden vendordeps make even less sense

2 Likes