WPILib 2023.4.3 Release

This is an update release of WPILib for the 2023 season. This release reduces NetworkTables CPU usage and latency, improves dashboard NetworkTables connection/disconnection behavior, and has several other quality-of-life improvements, in particular to Shuffleboard. This release also includes all fixes made in earlier releases.

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.2


  • Optimize scan of outgoing messages by PeterJohnson
  • NT4 client: close timed-out connections by PeterJohnson
  • Use int64 for datalog type string by PeterJohnson
  • ParallelTcpConnector: don’t connect to duplicate addresses by PeterJohnson


  • Check LTV controller max velocity precondition by calcmogul
  • Fix invalid iterator access in TimeInterpolatableBuffer by virtuald
  • Fix Pose3d log returning Twist3d NaN for theta between 1E-9 and 1E-7 by 7910f6ba7ee4
  • Fix NaN in C++ MakeCostMatrix() that takes an array by calcmogul
  • Fix potential divide-by-zero in RKDP by calcmogul


  • RamseteCommand: default-initialize m_prevSpeeds by PeterJohnson


  • Add isTestEnabled and minor docs cleanup by rzblue
  • Fix enableLiveWindowInTest crashing in disabled by rzblue
  • DataLogManager: increase time for datetime to be valid by PeterJohnson
  • Fix DutyCycleEncoder.setDistancePerRotation() in java simulation by rzblue
  • Fix RobotController.getComments() mishandling quotes inside the comments string by rzblue
  • [java] DriverStation: Fix joystick data logs by PeterJohnson
  • Shuffleboard: Keep duplicates on SelectTab() by Starlight220


  • Fix IndexOutOfBoundsException in tab setup by Starlight220
  • Make any entries set by dashboard retained by PeterJohnson
  • FieldData: Don’t throw on missing data by Starlight220
  • Add DataSource.equals() by Starlight220
  • Don’t switch to selected tab on value change by Starlight220
  • CameraServerWidget: Explicitly unbox Number objects by Starlight220
  • Use ConcurrentHashMap for static collection of NT sources by Starlight220


  • Give measurement period a valid default of 1 by calcmogul
  • Add Venom support by wlmchen


  • CommandScheduler.isComposed: Remove incorrect throws clause (NFC) by DAflamingFOX
  • WaitCommand: Remove subclass note (NFC) by Starlight220


  • Shuffleboard: Correct parameter order by Starlight220

New Contributors

  • 7910f6ba7ee4 made their first contribution
  • wlmchen made their first contribution

Peter and crew thank you for all of the continued support and effort that go into these releases!

Any thoughts or advice on upgrading for those of us with week 5 events?




Thanks for the hard work indeed @Peter_Johnson and co.

Same question as @Hollisms : can we blindly upgrade knowing we won’t have time to properly test the new release prior to our next event this weekend?

If you can’t test it yet, update when you’re next able to test it–whether it be the pits or the practice field. Never update things without testing!

1 Like



Get it… but if that thread where people had to turn off shuffleboard, etc. due to network issues has me scared… On thing worse than doing it today is doing it on Saturday…


Will this be required for week 5 onwards or is it a nice to have?

@Peter_Johnson Not sure if you’ve been exposed to the CHS Packet loss thread from last weekend.

In my observation, the packet loss we were seeing was almost always correlated to how many network tables values you were passing with Shuffleboard as your client.

From the technical side of the WPILib release, is there a technical pathway where these updates could change things from that perspective?

For example, there were two major symptoms of network problems at the event:

  1. Massive Packet Loss from certain teams,
  2. Robot control latency for the drivers. This was something that was more widely distributed amongst teams.

From your understanding of control packet flow, is there a causal pathway where network tables/shuffleboard could have a negative relationship with driver controls when the robots are connected to the FMS/field?

We as a team use Shuffleboard, but had disabled all of our vision and things that do a lot of dynamic updating of values. We probably had fewer than 10 topics of doubles that update regularly (as an example). We were mostly unscathed, up until our playoff matches.

Isn’t it required to update for comps?

Linking thread here for reference CHS Timonium Event Packet Loss - Competition - Chief Delphi

Only the RIO image and Driver Station image (eg, combined, the primary safety mechanism) are required to be updated. Everything else (motor controller firmware etc) is team discretion.


NetworkTables is constrained by the same bandwidth constraint as everything else. It’s certainly possible to use a lot of bandwidth by sending a lot of NT data, just like streaming a video stream can. I wouldn’t see why NT itself would cause higher packet loss from the networking perspective. Shuffleboard is kind of a notorious resource hog, though, and high CPU usage on the DS can cause control latency issues, so that might be a potential cause. Separately, one bug fixed in this release could result in high CPU usage on the Rio side when publishing a lot of data to multiple clients, which could potentially impact loop times.

We’re hitting an inflection point where teams are logging and sending a lot more NT data than in previous years. NT4 is pub/sub, which should enable us to resolve this by the dashboard only subscribing to/sending what’s needed, but currently almost all clients subscribe to everything, which defeats the purpose. Updating dashboards and other clients to more intelligently subscribe should help this problem in future years.


No, this is not going to be a required update. None of the WPILib updates this year have been required, but it’s strongly recommended that teams upgrade to at least 2023.4.2.

1 Like

What would be considered multiple clients in that context? Our loop times are on the slow side with 2023.4.2, so this fix alone might justify us making the plunge at the last minute. Thanks!

So would shuffleboard subscribe to values from AdvantageKit then even if they’re not being displayed? Does this mean that turning off AdvantageKit’s NT4 publisher during comps should help?

As a point of reference, the next version of AdvantageScope will subscribe only to active topics by default. Setting it up was relatively painless, and for most use cases the change is basically invisible to the user but massively reduces bandwidth usage. I’m very optimistic about getting similar logic integrated into other clients, especially for dashboards that don’t care about historical data.

I believe this is the case, though only at a 100ms period. If you’re having issues with Shuffleboard then turning off the NT4 publishing during comps is probably a good idea. As a future addition, maybe the NT4Publisher class could have a config option to automatically pause publishing when connected to the FMS.


The bug was in the way we check the per-client outgoing queues on the server.

Operation description: As each update is received, the server looks at which clients have subscribed to that topic and adds the update to the outgoing queue for each client that’s subscribed. Unless the client has requested all changes be sent for that topic, we only want to send the latest change for any given topic, so we also check to see if the outgoing queue already has an update for that topic and overwrite it (rather than appending to the queue). The outgoing queue is emptied periodically based on the requested flush rate for that client.

The bug was in the algorithm used for the “already has an update” check—it was a linear search. So effectively O(n^2) behavior where n is the queue depth. It wasn’t doing much in each iteration (just a comparison), but it adds up fast. The fix was to use a hash map to make this O(1).

So if you have updates being sent to a lot of unique topics in between flushes, the queue depth for clients that subscribe to all topics could get deep (eg n could get large, like 1000 or more). Particularly problematic clients are NT3 ones (eg Limelight) because they subscribe to everything at a 100 ms rate.

A partial workaround is to do a network flush every periodic loop, but upgrading fixes this entirely.

This algorithm actually didn’t change between NT3 and NT4. It just is more noticeable in NT4 because we do all the server processing for all clients in one thread; NT3 had two threads per client. And teams are creating many more topics–historically it was unusual to see more than a few dozen topics, teams are now creating close to 1000.


@jonahb55 How would one go about “turning off NT4 publishing”? What would doing this impact?

@Peter_Johnson At competition we use Shuffleboard to display a few details. We use a sendable chooser to select autos. We have two Limelight 3’s on our robot. Should we consider upgrading? Do you “think” it will have any real world impact for our scenario?

To be clear both of your explanations are great and I understand what you are getting at. I think everyone is looking for some “gauge” to determine if it will matter for them (which might be impossible).

1 Like

Yes, you should consider updating. There are NT and Shuffleboard updates that should make setting autos more reliable, and with two Limelight clients, if you’re sending a lot of topics, you might see a substantial CPU reduction.

I’ll note it’s very easy to downgrade robot programs to an older version (just edit build.gradle). Desktop apps are a bit trickier, but just running the old installer again should overwrite the desktop application (I’ve not actually tested this though).


What he’s talking about his 6328’s custom logging framework. Essentially it spits out all the logging data to NT4 so that their logging client can view show all the data, but since its through NT4, Shuffleboard will also subscribe to the data. You can find out more about it here.