Repository navigation
RobotLog.setGlobalErrorMsg disables the DS stop button, but does not stop the robot #1381
Description
I've discovered that running RobotLog.setGlobalErrorMsg does not stop the robot, even though it disables the DS stop button and prevents it from stopping the robot. This means that using it can lead to a runaway robot that cannot be stopped remotely.
In the interest of safety, I think that it should either forcibly stop the robot immediately, or it should allow the stop button to remain available.
Activity
acharraggi commentedon Dec 29, 2024
Wow! Confirmed. Setting RobotLog.setGlobalErrorMsg("Test Global Error Msg") results in a running program that can't be easily stopped. My test program had motors running and telemetry still running.
NOTE: A Restart Robot from the DS or exiting the DS app and starting the DS app WILL stop the robot.
I would think the robot should be disabled if this is called.
acharraggi commentedon Dec 29, 2024
If you want to stop the robot with an error message you could use the following code:
throw new RuntimeException("test runtime exception msg");That should stop your program with a custom message.
If you simply want to display a persistent message on the DS and let the robot continue you could call
RobotLog.addGlobalWarningMessage("Test Global Warning Msg");This displays the message in orange text on the DS (like the 5 GHz warning message).
Note: this is NOT like actual telemetry messages, if you repeatedly call this method, the RC and DS will lock up due to all the messages added.
Still looking at the set global error methods to determine what they are supposed to do. Given that you can clear the global error messages, it seems reasonable to assume the program should continue to run, in which case the driver station should not be disabled.
acharraggi commentedon Dec 31, 2024
There was one SDK Team member who commented that the SetGlobalError methods may have been intended for internal SDK use and perhaps should not have been made public. These methods are not documented in the Javadoc. They may be working as designed.
Perhaps you're allowed to set a bunch of errors, but then you're supposed to stop the robot in your code. Maybe you raise the error with a message, but then your error handling fixes things, so you clear the error and continue the program. If you don't clear the error, you stop the robot.
There appear to be other methods for displaying messages or handling errors that probably should be used instead.
Does throwing a runtime exception or setting a global warning message work better for you?
If you really want to use setGlobalErrorMsg can you post a link to your code on GitHub?
Also indicate why you need to use that method instead of a runtime exception or a warning message.
Thanks.
j5155 commentedon Dec 31, 2024
So in my case, I was debugging a library and I wanted to display a warning on the driver station from inside the library. I think setting the global warning message would work fine instead.
It would be great if this function was documented or marked as deprecated or SDK internal somehow, so others can avoid making the same mistake that I did.
j5155 commentedon May 9, 2025
Because this is an error reporting function, there is a strong potential for this bug to occur in untested and worst-possible scenarios. For example, I've just discovered a line in a very popular third-party library that because of this bug could definitely cause unsafe conditions.
CalKestis commentedon Jun 25, 2025
Addressed in v10.3. See the README notes for details.