WPILib 2023.4.2 Release

[Peter_Johnson]

Release v2023.4.2 · wpilibsuite/allwpilib

This is an update release of WPILib for the 2023 season. This release reduces overhead that can impact loop times in Java, and has several other quality-of-life improvements. Note: while this release only has a few changes since 2023.4.2, it includes all fixes made in earlier releases; it’s strongly recommended teams upgrade if running versions earlier than 2023.4.1.

Upgrading from earlier 2023 releases is easy: simply download and run the new installer and it will update your current installation. If you already have the 2023 WPILib vscode installed, it will detect it and you can simply click “next” for that installation step. After installation, vscode will prompt you when opening your robot project whether you want to upgrade it to this version. Note that using the installer is required to get the new version of desktop tools such as Shuffleboard.

The documentation for WPILib is located at https://docs.wpilib.org/ (if you have trouble accessing this location, FIRST Robotics Competition Control System — FIRST Robotics Competition documentation is an alternate location with the same content).

If you’re new to FRC, start with Getting Started.

A complete list of known issues with this release can be found here.

WPILib is developed by a small team of volunteers and the FIRST community.

What’s Changed since 2022.4.1

WPILib

• Fix HAL_GetRuntimeType being slow on the roboRIO by ThadHouse

Simulation

• DutyCycleEncoderSim: Add constructor that takes channel number by rzblue
• Fix REV PH solenoids 8+ simulation by superpenguin612
• Fix DataLogManager crash on exit in simulation by gaborszita

Commands

• Add default command removal method to Subsystem by democat3457

Docs

• Strip path from generated NT docs by sciencewhiz
• Fix XboxController::GetBackButton doc by auscompgeek

SysId

• Fix inversion checkbox showing up on built in Spark MAX and TalonFX encoder settings by rzblue
• Handle case where robot enables before SysId connects by calcmogul

Shuffleboard

• FmsInfo: Don’t throw on missing data by Starlight220

GradleRIO

• Don’t configure SmartDashboard as a tool on mac arm by ThadHouse

New Contributors

• gaborszita made their first contribution

[slickvic2252]

Are there any examples of how to use sysid for an arm with limited motion and an absolute encoder?

[Joe_Ross]

Characterizing an arm using a neo550 and a through bore

Correct. SysId needs velocity measurements that aren’t provided natively by duty cycle encoders. I’ve been experimenting with a different OLS formulation for SysId that supports position data as well:

[chauser]

A big Thank You to team 694 - StuyPulse - for identifying the performance problem with HAL_GetRuntimeType and to the WPILib team for providing a timely fix. It’s important for Java because HAL_GetRuntimeType may be called multiple times per robot cycle even if though we never call it explicitly in our own code.

[NOD]

We updated to 2023.4.2 because we were seeing some of the problems we thought it would solve, but still have a big unresolved issue: namely random crashes.

These occur every couple of minutes, with no error message. We simply see “No Robot Code” on the DS. Looking through the /tmp/hs_err_pid logs we see messages such as:

A fatal error has been detected by the Java Runtime Environment:

SIGSEGV (0xb) at pc=0x8a64ceec, pid=10396, tid=10429

JRE version: OpenJDK Runtime Environment (17.0.3.7) (build 17.0.3.7-frc+0-2023-17.0.5u7-1)

Java VM: OpenJDK Client VM (17.0.3.7-frc+0-2023-17.0.5u7-1, mixed mode, emulated-client, g1 gc, linux-arm)

Problematic frame:

C 0x8a64ceec

And:

Exception ‘java/lang/NoSuchMethodError’
Exception ‘java/lang/IncompatibleClassChangeError’

We tried the suggestion posted elsewhere to issue a Gradle Clean command. No luck.

Anyone have any other suggestions?

hs_err_pid10396.txt (67.6 KB)
(error log attached)

(Just now saw a DS message “terminate called after throwing an instance of std::bad_alloc”)

[Peter_Johnson]

Okay, to get more info we’re going to want to get what’s called a core dump, basically a full dump of the address space of the java program and everything it has loaded. Here’s the steps to do this:

1. Use a SSH client such as PuTTY to ssh into the Rio (roborio-TEAM-frc.local), login is lvuser (no password).
2. Run the following commands in the SSH terminal. What this does is stop the robot program, enable core dumps, and run the robot program interactively (just once, and so it won’t auto-restart):

/usr/local/frc/bin/frcKillRobot.sh -t
ulimit -c unlimited
./robotCommand

3. Try to reproduce the crash. Assuming it crashes, the SSH terminal will return to the prompt after the crash message. Somewhere at the end of the message it should say “(core dumped)” or something similar to it. It may take 10+ seconds after the crash to return to the prompt as it takes some time to write the core dump.
4. Use Windows Explorer to FTP (ftp://roborio-TEAM-frc.local/) or a program like FileZilla to SFTP to the Rio. Navigate to /var/local/natinst/log/ and download the file named core_dump.something (should be core_dump.!usr!local!frc!JRE!bin!java for a Java program).
5. Delete the core_dump file from the Rio (as it consumes a fairly large amount of disk space).
6. Zip the core_dump file and upload it somewhere like Google Drive and send the link.

For analyzing it, I’ll also need a copy of your project, or since it’s Java, at least the WPILib version (in this case 2023.4.2 it sounds like) and the exact vendor deps you’re using.

[Ice1605]

What tools do you recommend for analyzing core dumps collected from the Rio? We’ve actually run into crashes similar to this (the worst of which were seemingly resolved by reimaging the RoboRIO we were using because it was totally unusable due to JVM crashes after every deploy). Other than that RIO, we have seen hard JVM crashes a couple of times. However, we haven’t been able to rule out something in our code yet (though inspection with Visual VM didn’t show any obvious memory leaks or the like).

[Peter_Johnson]

I just use gdb, but the setup is somewhat involved, as analyzing ARM core dumps essentially requires debug info (including that for libraries) to get a backtrace. So there’s a lot of manual downloading/extracting required to get the JRE debug info, WPILib library debug info, etc. And most of the vendor libraries don’t distribute debug info AFAIK.

[Ice1605]

Cool, thanks for the info!

[BMLSS]

Does the offline update from the commend palette work? I can’t seem to get the command palette “Check for WPILib Updates” to find the offline version of the 2023.4.2 .iso file.

[Peter_Johnson]

You have to run the installer in the iso file, vscode won’t do that for you.

[BMLSS]

OK Thank you. I read that there was a problem with the command palette update tool for online use, but I thought it might work for offline. I have now run the installer from the .iso and I see that my VS code does not also need updating. I got an error if I did not do this right after a restart and before opening WPILib Code.
Thank you for your help.