Testing the latest 2024 beta release (and vendordeps) I am seeing a serious problem with failed deployments. After turning the robot on, the first deployment always succeeds. After that there may be one or two successful deployments and then further deployments complete successfully in as shown in the VSCode progress window and the riolog opens but is blank. On the DS, the robot code led is red. Further deployments all fail. Rebooting the RIO sometimes fixes this and sometimes you have to power cycle. After a reboot or cycle, the code does come up and is the code that was last deployed but failed to start.

Further, every few successful deployments, when the code runs it experiences errors on can bus devices. Redeploy cures this code runs normally. Next deployment we are back to blank riolog and no robot code led red. On continued attempts to deploy is will see some random output from our tracing facility in the riolog but robot code led still red.

Finally thought to do a gradle clean. After the clean, the code consistenly deploys, but the riolog contains left over output from an earlier deploy (the random output mentioned above, its the same output each time) followed by our logging showing successful start up.

It appears that things appear to be ok now (other than garbage at start of riolog), so maybe the clean removed something that was causing the problem.

Update: after repeated successful deploys after clean, I did get one where the code started ok but then got lots of errors from CAN devices. redeployed and code ran fine. Deployed again and CAN errors. Deployed again, no errors. After almost 50 deployments trying to nail this down I am calling it a day.

Code is at https://github.com/ORF-4450/Robot24B

I had game tools beta 1 installed, and after installing beta 2, neither the DS or imaging tool or images were updated. I had to uninstall game tools and then reinstall it to get those updated.

See also https://www.chiefdelphi.com/t/wpilib-2024-beta/442360/94?u=joe_ross

I just installed the software on a MacBook Pro (OSX Sonoma 14.0)
In past years, wpilib installed into the /Users/_Username_/wpilib/_YEAR_ folder.
This year, the beta version installed into the /Users/_Username_/Documents/wpilib/2024 folder. Not sure if that was intentional or not.
However, the log files went into /Users/_Username_/wplib/2024/logs folder. Again, not sure if that was intentional or not.
I did not see it listed in the 2024 changes.

Since the Upload WPILogs feature takes files from the roboRIO and puts them on the DS compunter, this seems like it should be called downloading rather then uploading

• When using the methods getRightX() / getRightY() of a CommandPS5Controller object, the returned value is always stuck at -1.
• in the Driverstation Joystick view, everything seems good,
• I'm using a PS5 controller IRL (obviously)
• CommandPS4Controller works fine

I don't have access to a robot at the moment, but If needed i'll have access to one this Sunday (to provide, pictures / log files / code etc)

After adding a new online vendor dep (CTRE in my case but I don't think it matters) a dialog box appears offering to build the project with choices "Yes" "No" and "Cancel". It is unclear what the "Cancel" option would do.

For Both Java and C++ I get a fatal error when attempting to simulate even very simple robot programs (my current examples are the supplied Relay examples). Building goes fine. But after selecting the extensions to load, I get the following for C++:

HAL Extensions: Attempting to load: libhalsim_guid
Simulator GUI Initializing.
frcUserProgram: /__w/thirdparty-imgui/thirdparty-imgui/glfw/src/x11_init.c:1099: _glfwGrabErrorHandlerX11: Assertion `_glfw.x11.errorHandler == NULL' failed.

and for Java:

desktop:~/sciborgs-2024-beta/Relay-example$  cd /home/hauser/sciborgs-2024-beta/Relay-example ; /usr/bin/env HALSIM_EXTENSIONS=/oldRoot/home/hauser/sciborgs-2024-beta/Relay-example/build/jni/release/libhalsim_gui.so: DYLD_LIBRARY_PATH=/oldRoot/home/hauser/sciborgs-2024-beta/Relay-example/build/jni/release LD_LIBRARY_PATH=/oldRoot/home/hauser/sciborgs-2024-beta/Relay-example/build/jni/release /usr/lib/jvm/java-17-openjdk-amd64/bin/java -agentlib:jdwp=transport=dt_socket,server=n,suspend=y,address=localhost:35903 @/tmp/cp_4k0zjudxlm5mz0cuj60pb1jgm.argfile frc.robot.Main 
HAL Extensions: Attempting to load: libhalsim_gui
Simulator GUI Initializing.
java: /__w/thirdparty-imgui/thirdparty-imgui/glfw/src/x11_init.c:1099: _glfwGrabErrorHandlerX11: Assertion `_glfw.x11.errorHandler == NULL' failed.
Aborted (core dumped)

The Java units library is not intuitive (thanks to Java generics), so it needs to be well documented.
There are a lot of JavaDocs missing, for example, the Velocity class has no class-level documentation.
The documentation page has more information about memory usage than actual information about how to use the library. I recommend adding more examples, and a table of the available types (and maybe how to declare and initialize them.)

RobotPy simulation has a Physics Engine class that is responsible for doing the periodic updates and updating the simulator. In our Java code, inside the subsystem that holds the motor controllers, we'd create a TalonFXSimCollection object, and then inside simulationPeriodic() update the sensor inputs.

So, with CTREs lower level simulation in the past, I did all that in the subsystem. In RobotPy, it's done in the physics engine. Is there a best practice or a sane way to do this in Python?

Essentially, having examples with how to do simulation updates for TalonFXSIM collections inside of a subsystem (in a separate class), while passing information back and forth between the physics engine object, and the subsystem would be awesome.

This is probably not a new behavior, but is unlikely to occur very often -- most likely scenario is a new machine.

On a brand new machine I installed the 2024 NI Game Tools and observed the following with the DriverStation.
I entered an IP address in the Team Number box (which at the time contained xxyy). The DS did not connect to the (simulated) robot running at that IP address even after checking all the usual culprits for that problem.
What worked was to enter a team number (does not have to be the team number of the running simulation) in the box and THEN put the IP address in the box. After that the connection happened immediately.

I was able to reproduce this on a non-new machine by shutting down the Driver Station, deleting the files C:\Users\Public\Documents\FRC{DashboardSettings.ini, FRC\ DS\ Data\ Storage.ini}, and then starting the DS again.

Had issues getting the NI 2024 Beta Release 1 to work properly, particularly flashing the 2024 roboRIO firmware using the roboRIO Imaging Tool. This happened across two different computers. These were the steps I performed and the issues I ran into when trying to install and run the NI 2024 Beta Release 1 software:

• Computers were running Windows 11 with the NI Game Tools 2023 installed. The installation process for the 2024 Beta Release 1 seemed to work okay, but when using the updated roboRIO Imaging Tool to update a roboRIO to the 2024 version, the imaging process failed, citing a corrupted firmware issue.
• Decided to uninstall the NI Game tools and then do a clean install of just the NI 2024 Beta Release 1. Uninstallation was done through Window's uninstall menu to uninstall the NI Package Manger and NI Software programs and seemed to complete successfully. On attempting a reinstall of the 2024 Beta Release 1, the process kept failing when getting to the step to install the NI Package Manager, citing no action needed to be done and closing the installer without installing the FRC Driver Station or roboRIO Imaging Tool. This was resolved by manually deleting the C:\ProgramData\National Instruments directory and then running the 2024 NI Beta Release 1 installer again to get it to complete.
• Once a clean install of the NI 2024 Beta Release 1 was done, I attempted to use the 2024 roboRIO Imaging Tool. The tool could not connect to the roboRIO. Checking the computer's network adapters, it seems that the release did not install the USB-Ethernet divers to communicate with the roboRIO over USB as the NI Network adapter did not show up.
• Uninstalled the NI 2024 Beta Release 1 again, along with manually deleting C:\ProgramData\National Instruments and did a clean install of the 2023 NI Game Tools, then a clean install of the 2024 Beta Release 1. This ultimately worked, installing all of the software correctly and allowing me to image a roboRIO to the 2024 Beta firmware.

When I try to drag a CameraServer item onto a new tab in Shuffleboard, the Shuffleboard crashes. This occurs on my Windows 11 laptop but not on my Windows 10 laptop. Other differences between the two machines: Windows 11 is 10 cores, 12 logical processors, 1920x1200 display (but settting to 1920x1080 did not help). Windows 10 is 4 cores, 8 l.p., 1920x1080 display. Both machines have wpilib 2024 beta 4 installed.

I ran the 2023 shuffleboard on the Windows 11 machine and it did not crash. I ran the 2024 shuffleboard with the 2023 JVM and it did crash. By running from the command line I captured the shuffleboard output. The crashing one produces terminal output that end like this:

INFO: Took 3142ms to start Shuffleboard
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffb67fdc7f0, pid=22448, tid=21148
#
# JRE version: OpenJDK Runtime Environment Temurin-17.0.5+8 (17.0.5+8) (build 17.0.5+8)
# Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.5+8 (17.0.5+8, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# V  [jvm.dll+0xc7f0]
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Users\Public\wpilib\2024\hs_err_pid22448.log
#
# If you would like to submit a bug report, please visit:
#   https://github.com/adoptium/adoptium-support/issues

The error report file is attached.
hs_err_pid22448.log

The runs of shuffleboard that do not crash (both 2023 and 2024 versions) all show something different after the INFO message regarding shuffleboards startup time. One of those looks like this:

VideoException [edu.wpi.first.cscore.VideoException: empty value]
        at edu.wpi.first.cscore.CameraServerJNI.getTelemetryAverageValue(Native Method)
        at edu.wpi.first.cscore.CameraServerJNI.getTelemetryAverageValue(CameraServerJNI.java:364)
        at edu.wpi.first.cscore.VideoSource.getActualDataRate(VideoSource.java:334)
        at edu.wpi.first.shuffleboard.plugin.cameraserver.source.CameraServerSource.lambda$new$5(CameraServerSource.java:139)

Dec 21, 2023 2:51:28 PM edu.wpi.first.shuffleboard.plugin.cameraserver.source.CameraServerSource lambda$new$5
WARNING: Could not get framerate
VideoException [edu.wpi.first.cscore.VideoException: empty value]
        at edu.wpi.first.cscore.CameraServerJNI.getTelemetryAverageValue(Native Method)
        at edu.wpi.first.cscore.CameraServerJNI.getTelemetryAverageValue(CameraServerJNI.java:364)
        at edu.wpi.first.cscore.VideoSource.getActualFPS(VideoSource.java:321)
        at edu.wpi.first.shuffleboard.plugin.cameraserver.source.CameraServerSource.lambda$new$5(CameraServerSource.java:145)

Those WARNINGs and VideoExceptions do not appear on the terminal for the crashing version so they may be relevant.

I will try to get my hands on another Windows 11 machine for further differential testing tonight.

The FRC examples don't show in the NI example finder on the default setting of browse according to task (or else they are buried somewhere that I can't find them).

If changing the setting to browse according to directory structure, they do show up

Timeslice Robot is currently listed as "Timesice"

Other related feedback that can be moved somewhere else:
My impression is the list of project templates could benefit from reordering or reworking.
It's quite long and if you don't know which option you want going in it could be very confusing.

Maybe another selector in the wizard where you select the controller platform before selecting the project type?
(roboRIO/Romi/XRP)

In the DS Log Viewer, on Windows 11, the window is scaled so that the bottom is cut off, and there's no horizontal scroll bar. Resizing the window doesn't change anything as it adjusts the scaling.

I get a BSOD: nipcibrd.sys SECURE_PCI_CONFIG_SPACE_ACCESS_VIOLATION after installing game tools. My laptop is a 13th gen Intel 1340p with Windows 11 pro. Virtualization based security is enabled.

This is the convoluted workaround I followed to get my computer usable again (inspired by https://forums.ni.com/t5/LabVIEW/How-to-disable-the-nipcibrd-sys-driver-to-prevent-hibernation/m-p/4296535). More context: https://forums.ni.com/t5/LabVIEW/BSOD-nipcibrd-sys-SECURE-PCI-CONFIG-SPACE-ACCESS-VIOLATION/td-p/4284462 and https://forums.ni.com/t5/General/Why-does-Game-Tools-require-PXI/td-p/4315440

1. Boot into the bios and disable virtualization extensions
2. Download the offline installer from: https://www.ni.com/en-us/support/downloads/drivers/download.pxi-platform-services.html#479592 for 2023 q2)
3. Mount the downloaded iso
4. Navigate to the pool directory
5. using 7-zip, open ni-pcibrd_22.5.0.49208-0+f56_windows_x64.nipkg (version may be different)
6. double click on data.tar.gz
7. double click on data.tar
8. double click on the . folder
9. extract the 5 files, which includes pcibrdi32.msi and pcibrdi64.msi
10. Run both msi's, choosing the uninstall option.
11. reboot and re-enable virtualization extensions

I'm developing swerve code for my team with the beta 3, and I'm getting CommandScheduler loop overrun printed to the log a LOT, I don't think that that is the expected behavior, and I'm also not sure what part of my code is causing the loop overrun.

Here's the riolog as .json and .txt,

Here's a link to a specific commit of the repo which can cause this issue, as I'll still be actively developing with this repo

thanks!

The SimDevice's are named "SPARK MAX " with a trailing space. The additional space is easy to overlook and can cause errors when constructing a SimDeviceSim object. Removing the space would be more consistent with the naming scheme used by WPILib.

Additionally, there is no way to set the value returned for position or velocity from the AbsoluteEncoder object returned by CANSparkMax.getAbsoluteEncoder() when running in sim. In sim, the getPosition() and getVelocity() methods return random values. Ideally this would have a sim value that could be set by the user.

Overall, increased simulation support in REVLib would be a very welcome addition.

My computer hostname was Framework13, and the roborio failed to image and gave the hostname error. I changed my hostname to just Framework and it did image successfully.

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019Zh2SAE&l=en-US says that numbers are ok

Make sure your computer has only letters and numbers in its name, as long names or non-latin characters can affect the imaging tool.

On a WPI install of AdvantageScope, opening the app on macOS gives an error "AdvantageScope (WPILib) is damaged and can't be opened. You should move it to the trash." After going into Privacy & Security and manually allowing it to open it works normally. Peter said that this the notarization is likely missing.

getRotation2d was previously provided by the Gyro interface, it would be ideal if the AHRS class added this functionality back.

Low priority, but documenting here for reference....
While attempting to make some... obvious.... warning messages for users, we noticed inconsistency in how fonts were used when displaying the roboRIO's stdout/stderr streams:

Driver Station itself uses variable-width font.

Log File Viewer uses variable-width font:

Message console uses fixed-width font:

Obviously not a functional issue, we'll find another way to make the messages obvious. But, supporting some creative monospace things would be nice in the future.

Thanks!

Chris

As part of our periodic system testing, we found that the CPU usage of the roboRIO seems to periodically increase to very high levels with an empty TimedRobot project, shown below.

It takes 72 minutes for the issue to initially reproduce. Once it does, these cycles of increased CPU usage appear to occur with a period of around 72 minutes (36 minutes high, 36 minutes low). Our testing was performed with the roboRIO2_2024_v1.1 image and WPILib project information:

Project Version: 2024.1.1-beta-3
VS Code Version: 1.83.1
WPILib Extension Version: 2024.1.1-beta-3
C++ Extension Version: 1.17.5
Java Extension Version: 1.23.0
Java Debug Extension Version: 0.52.0
Java Dependencies Extension Version 0.23.0
Java Version: 17
Java Location: C:\Users\Public\wpilib\2024\jdk
Vendor Libraries:
    WPILib-New-Commands (1.0.0)

I've confirmed using top that the spike in CPU usage primarily comes from the robot program (/home/lvuser/frcUserProgram), although interestingly irq/61-atomiczy also seems to be elevated.

Normal CPU usage:

High CPU usage:

During high CPU usage, code deploy often fails. Restarting robot code resolves the period of high CPU usage.

Trying to open a project with 2024 LabVIEW results in the target not loading, and the following error.

Describe the bug
After a couple java project deploys, on a roboRIO 1, the DS will report an out of memory exception

To Reproduce
Steps to reproduce the behavior:

1. Format/power cycle roboRIO 1
2. Create a new Timed Robot Skeleton Java Project
3. Construct a Talon object with PWM channel 0
4. Deploy project to roboRIO 1
5. Increment channel
6. Repeat steps 4-5
7. Eventually (in less then 10 repeats), get the following error:

OpenJDK Client VM warning: INFO: os::commit_memory(0xb0000000, 4194304, 0) failed; error='Not enough space' (errno=12)
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 4194304 bytes for committing reserved memory.
# An error report file with more information is saved as:
# /tmp/hs_err_pid7540.log

Expected behavior
Out of memory exception does not occur.

Desktop (please complete the following information):

• OS: Windows 10
• Project Information:

WPILib Information:
Project Version: 2024.1.1-beta-1
VS Code Version: 1.83.1
WPILib Extension Version: 2024.1.1-beta-1
C++ Extension Version: 1.17.5
Java Extension Version: 1.23.0
Java Debug Extension Version: 0.52.0
Java Dependencies Extension Version 0.23.0
Java Version: 17
Java Location: C:\Users\Public\wpilib\2024\jdk
Vendor Libraries:
   WPILib-New-Commands (1.0.0)

Additional context
I collected memory information before and after each deploy, available as a zip below:
Deploy 0 is collected immediately after power cycling the roboRIO, Deploy 5 is after the Out of Memory error occurred.
MemoryIssues.zip

I've also attached the log file of the out of memory error:
hs_err_pid7540.log

I've also repeated this experiment on the 2023_v3.2 image for a comparison, and stopped my testing after 30 consecutive deploys without issue. This appears to be a new or worsened issue for the 2024 libraries.

When deploying

admin @ 172.22.11.2: 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"

reported that its missing the FRC_ prefix

Edit: This applies to both roboRIO 1 & 2

From the LabVIEW main screen, choosing Tools -> Download CTRE Phoenix libs fails to download.

I get this message when starting the beta 2 DS with no robot connected (haven't tried it a robot)

DriverStation.getAlliance() is returning the wrong alliance color for Red 1 and Blue 1. Selecting a value in DS returns these values:

• Red 1: Optional.empty
• Red 2: Optional[Red]
• Red 3: Optional[Red]
• Blue 1: Optional[Red]
• Blue 2: Optional[Blue]
• Blue 3: Optional[Blue]

DS: 24.0b64
RIO: roboRIO2_2024_v1.1
Lib: Java 2024.1.1-beta-2