Problèmes connus

Cet article détaille les problèmes connus (et les solutions de contournement) relatifs à la partie logicielle du système de contrôle FRC®.

Questions ouvertes

LabVIEW Getting Started page reports 2024

Issue: The LabVIEW Getting Started page shows 2024 instead of 2025.

Workaround: This is an issue with the LabVIEW update. You can confirm that the proper version is installed by opening the Driver station and confirming the version in the titlebar is 25.0

Driver Station randomly disabled

Issue: The Driver Station contains tighter safety mechanisms introduced in 2024 to protect against control issues. Some teams have seen this cause the robot to disable.

Workaround: There are multiple potential causes for tripping the safety mechanisms.

Note

The new safety mechanisms will not disable the robot when connected to the FMS.

The Driver Station software has new tools for control packet delays that could cause this. The control system team requests that teams that experience this issue post screenshots of the Driver Station Timing window to https://github.com/wpilibsuite/allwpilib/issues/6174

Some teams have seen this happen only when the robot is operated wirelessly, but not when operated via USB or ethernet tether. Some potential mitigations:

1. Try relocating the robot radio to a better location (high in the robot and away from motors or large amounts of metal). Follow the manufacturer’s recommended mounting

2. Measure your robot’s bandwidth and ensure you have margin under the 7 Mbps bandwidth limit

3. See if the Wi-Fi environment is congested using a tool like WiFi Analyzer.

4. Utilize the recommended 2 radio setup. 1. Ensure the DS Radio is mounted high, away from interference and humans walking between the DS radio and the robot. 2. Use ethernet to connect the DS computer to the DS Radio

5. Update the Wi-Fi drivers for the DS computer.

Some teams have seen this happen due to software that is running on the driver station (such as Autodesk updater or Discord). Some potential mitigations:

1. Reboot the driver station computer

2. Close software that is running in the background

3. Follow the Driver Station Best Practices

While rare, this can be caused by robot code that oversaturates the roboRIO processor or network connection. If all other troubleshooting steps fail, you can try running with one of the WPILib example programs to see if the problem still occurs.

If you identify software that interferes with driver station, please post it to https://github.com/wpilibsuite/allwpilib/issues/6174

Driver Station Reports Less Free RAM then is Available

Issue: The Driver Station diagnostic screen reports free RAM that is misleadingly low. This is due to Linux’s use of memory caches. Linux will cache data in memory, but then relinquish when the robot programs requests more memory. The Driver Station only reports memory that isn’t used by caches.

Workaround: The true memory available to the robot program is available in the file /proc/meminfo. Use ssh to connect to the robot, and run cat /proc/meminfo.

MemTotal:         250152 kB
MemFree:           46484 kB
MemAvailable:     126956 kB

The proper value to look is as MemAvailable, rather then MemFree (which is what the driver station is reporting).

Driver Station Reporting No Code

Issue: There is a rare occurrence in the roboRIO 2.0 that causes the roboRIO to not properly start the robot program. This causes the Driver Station to report a successful connection but no code, even though code is deployed on the roboRIO.

Workaround: We are currently investigating the root cause, but FIRST volunteers have been made aware and the recommendation is to reboot the roboRIO when this occurs.

Note

Pressing the physical User button on the roboRIO for 5 seconds can also cause the robot code to not start, but a reboot will not start the robot code. If the robot code does not start after rebooting, press the User button. Ensure that nothing on the robot is in contact with the User button.

Port I2C intégré provoquant des blocages du système

Issue: Use of the onboard I2C port on the roboRIO 1 or 2, in any language, can result in system lockups. The frequency of these lockups appears to be dependent on the specific hardware (i.e. different roboRIOs will behave differently) as well as how the bus is being used.

Workaround: The only surefire mitigation is to use the MXP I2C port or another device to read the I2C data. Accessing the device less frequently and/or using a different roboRIO may significantly reduce the likelihood/frequency of lockups, it will be up to each team to assess their tolerance of the risk of lockup. This lockup can not be definitively identified on the field and a field fault will not be called for a match where this behavior is believed to occur. This lockup is a CPU/kernel hang, the roboRIO will completely stop responding and will not be accessible via the DS, webpage or SSH. If you can access your roboRIO via any of these methods, you are experiencing a different issue.

Several alternatives exist for accessing the REV color sensor without using the roboRIO I2C port. A similar approach could be used for other I2C sensors.

• Use a Raspberry Pi Pico. Supports up to 2 REV color sensors, sends data to the roboRIO via serial. The Pi Pico is low cost (less than $10) and readily available.

• Use a Raspberry Pi. Supports 1-4 color sensors, sends data to the roboRIO via NetworkTables. Primarily useful for teams already using a Raspberry Pi as a coprocessor.

La mise à jour des propriétés du roboRIO 2.0 peut être lente ou bloquée

Problème: La mise à jour des propriétés d’un roboRIO 2.0 sans avoir à le reformatter à l’aide de l’outilitaire Imaging Tool (par exemple, la configuration du numéro d’équipe) peut être lente ou bloquée.

Solution: Après quelques minutes d’attente pendant l’exécution de l’outilitaire Imaging Tool, le roboRIO devrait pouvoir être redémarré et les nouvelles propriétés devraient être configurées.

Simulation crashes on Mac after updating WPILib

Issue: On macOS, after updating the project to use a newer version of WPILib, running simulation immediately crashes without the GUI appearing.

Workaround: In VS Code, run WPILib | Run a command in Gradle, clean. Alternatively, run ./gradlew clean in the terminal or delete the build directory.

Compilation invalide en raison de l’absence de GradleRIO

Problème: Très rare, le cache Gradle d’un utilisateur sera brisé et ils recevront des erreurs similaires à ce qui suit:

Could not apply requested plugin [id: ‘edu.wpi.first.GradleRIO’, version: ‘2020.3.2’] as it does not provide a plugin with id ‘edu.wpi.first.GradleRIO’

Solution de contournement:

Delete your Gradle cache located under ~$USER_HOME/.gradle. Windows machines may need to enable the ability to view hidden files. This issue has only shown up on Windows so far. Please report this issue if you get it on an alternative OS.

Caractères chinois dans le journal du poste de conduite

Problème: Rarement, le journal du poste de conduite affichera des caractères chinois au lieu du texte anglais. Cela semble se produire uniquement lorsque Windows est défini sur une langue autre que l’anglais.

Solution de contournement: Il existe deux solutions de contournement connues:

1. Copiez et collez les caractères chinois dans le bloc-notes, et le texte anglais sera affiché.

2. Changez temporairement la langue de Windows en anglais.

C++ Intellisense - Les fichiers ouverts au lancement ne fonctionnent pas correctement

Problème: En C++, les fichiers ouverts au lancement de VS Code auront des problèmes avec Intellisense affichant les suggestions de toutes les options d’une unité de compilation et pas seulement celles appropriées ou ne trouvant pas de fichiers d’en-tête. Il s’agit d’un bogue dans VS Code.

Solution de contournement:

1. Fermez tous les fichiers dans VS Code, mais laissez VS Code ouvert

2. Supprimer le fichier c_cpp_properties.json dans le dossier .vscode, s’il existe

3. Run the « Refresh C++ Intellisense » command in VS Code.

4. En bas à droite, vous devriez voir quelque chose qui ressemble à une plate-forme (linuxathena ou windowsx86-64, etc.). S’il ne s’agit pas de linuxathena, cliquez dessus et définissez-le sur linuxathena (version)

5. Attendez ~ 1 min

6. Ouvrez le fichier cpp principal (pas un fichier d’en-tête avec extension .h). Intellisense devrait maintenant fonctionner

Problèmes avec les Dashboards WPILib et de simulation sur les éditions Windows N

Problème : Le code WPILib utilisant CSCore (dashboards et code robot simulé) aura des problèmes sur les versions Education N de Windows.

• Le shuffleboard fonctionnera, mais ne chargera pas les caméras

• Smartdashbard va planter au démarrage

• La simulation de robot va planter au démarrage

Solution: Install the Media Feature Pack

Python - CameraServer/cscore runs out of memory on roboRIO 1

Issue: When using CameraServer on a roboRIO 1, the image processing program will sometimes exit with a SIGABRT or « Error code 6 » or a MemoryError.

Solution: You may be able to workaround this issue by disabling the NI webserver using the following robotpy-installer command:

python -m robotpy installer niweb disable

Voir aussi

Github issue

Fixed by Game Tools 2025 Patch 1

Game Tools install fails due to outdated NI Package Manager

Issue: An offiline installation of NI Game Tools may fail due to outdated NI Package Manager

Workaround: Install the latest National Instruments Package Manager (Note: Click on link for « Install Offline ») and then restart Game Tools installation.

Fixed by Elastic 2025.0.2 (WPILib Installer 2025.3.1)

Elastic camera streams are very laggy

Issue: Camera streams displayed in Elastic are laggy and have low FPS.

Workaround: This is an issue that was fixed in Elastic 2025.0.2. Update Elastic by running the latest WPILib installer or Elastic installer.