Safety Violation Error Triggered by External Abrupt Movements
Closed this issue · 4 comments
When an external abrupt movement is applied to the robot, a safety violation error occurs, prompting the message "Please confirm the safety violation(s) have been resolved." as shown in the following screenshot:
And this is the rule 2 description under "work" safety scenario as stated in the generated Safetyexport:
This error first occurred when the mobile platform to which the robot is mounted passed above something, causing an abrupt movement. Upon further testing, we observed that the error consistently happens when we move one of the robot's axes quickly but only a little bit. Interestingly, if we move it slowly, even with the same small distance, the error doesn't occur. The error happens regardless of whether the robot is locked or unlocked and whether the Franka Control Interface (FCI) is enabled or disabled.
The main problem we have is that we cannot confirm this error programmatically through ROS.
We need help identifying the cause of this error and finding a solution. Since the mobile platform won't always move on smooth surfaces, we expect to come across this issue quite often. Any insights, suggestions, or fixes to eliminate this error and ensure safe robot operations would be greatly appreciated.
Can you show the complete rule? We need info about activation space and safety function.
.
Currently, you could easily set up a rule that will always engage safety violations if the brakes are locked or not.
FCI currently (and probably in the future) will not be able to modify or resolve safety-relevant issues. Resolving these issues can only be done via Desk.
These are the 2 rules we have currently:
If it is useful, I could also send the safety report generated by the robot (privately if possible).
FCI currently (and probably in the future) will not be able to modify or resolve safety-relevant issues. Resolving these issues can only be done via Desk.
This makes sense and understandable for major safety-relevant issues, but the current error we have is triggered very easily.
These two rules are almost default ones. You should get in touch with our customer support since this looks like an internal problem with a robot.
Abrupt movements cause accelerations on the robot that trigger the SMS. This makes sense and is the desired behavior so I will close the issue.
Thank you.