Safety Stop Category 2 with EAC Driver and External API Control SDK

[jacob-kruse]

Hello,

I am using the MoveIt2 Python API along with the EAC driver in this package to motion plan with the Kuka LBR iisy 3 r760. Recently I increased the speed of my robot and its execution, and was wondering if it was possible to call a Safety Stop Category 2 as defined in the iiQKA.OS documentation. Currently, I can press the Emergency Stop to stop the robot, if necessary, but this causes a very abrupt stop and is hard don the robot. The documentation says that a Safety Stop Category 2 occurs when you press the "pause" button or release the "start" button so figured I would try, but it did not work. I was wondering if it was possible to send a Safety Stop Category 2 with external control.

Thanks,
Jacob Kruse

[Svastits]

Hi,

If you would like a safety stop, it is not really possible using the driver, as it is not a safe system and therefore cannot be coupled to the safety of the robot.
But I think you can configure the reaction to the emergency stop in the safety configuration, maybe you can set Stop2 there (however I am not sure)

[jacob-kruse]

Thanks for the suggestion @altex111. Unfortunately, using ros2 lifecycle set robot_manager deactivate does not produce the result I desire. When this command is used, the brakes are applied instantaneously once the deactivation is processed. This is similar to a Safety Stop 1, although it is not real time. I am looking for a way to stop the robot in a gradual manner to produce less strain on the joints.

[gavanderhoorn]

If you're using a JointTrajectoryController from ros2_control, cancelling an active goal should result in a hold trajectory getting executed.

That would be somewhat similar to a -- very much non-safety-rated -- controlled stop.

[jacob-kruse]

@gavanderhoorn
Is there a terminal command to cancel the active goal? I have been searching for a way to do this for the past 45 minutes.

[gavanderhoorn]

Haven't tested it, but Easy way to cancel a ROS2 action seems to suggest this should work:

ros2 service call <service-name> action_msgs/srv/CancelGoal

See that Q&A also for a way to find <service-name>.

(you don't necessarily need to use ros2 service of course. A regular ROS 2 service client would also work)

Essentially you'd call the service with a default/zero-initialised action_msgs/srv/CancelGoal instance, which, according to the documentation:

If the goal ID is zero and timestamp is zero, cancel all goals.

As I wrote in the linked Q&A, I've always felt this is a bit of a hack, but it would be a way to cancel active goals when you don't actually 'own' them.

[jacob-kruse]

Okay, I will give this a try and let you know the results.

[jacob-kruse]

@gavanderhoorn
I tried the goal cancellation method like you suggested. Using ros2 service call /joint_trajectory_controller/follow_joint_trajectory/_action/cancel_goal action_msgs/srv/CancelGoal, I was able to successfully stop the robot. However, it still came to an abrupt stop when the command was processed.

[gavanderhoorn]

ros_control in ROS 1 had a parameter called stop_trajectory_duration.

Doesn't look like that exists anymore: joint_trajectory_controller/src/joint_trajectory_controller_parameters.yaml.

It will of course also depend on the driver, but you could ask over at ros-controls/ros2_controllers about how to configure the stop behaviour.

(PS: this is all just an off-the-cuff remark. I haven't looked at anything in detail)

[jacob-kruse]

Thanks again for the response. I will post a question on the ros-controls/ros2_controllers forum.

[jacob-kruse]

I am still looking for a solution.

I posted on the ros2_controllers forum about my issue (ros-controls/ros2_controllers#1516). They pointed me towards a pull request that enforced acceleration limits defined in the URDF. Although this would work in theory, the KukaEACHardwareInterface does not have an acceleration command interface so it did not work. They are still working on getting back to me with a solution.

I have been looking through the kuka-external-control-sdk code for a solution, but have found that any sort of error leads to a stop flag being raised and a hard safety stop. That is why the "Brake" reaction in my safety configuration still resulted in a Safety Stop 1 when I was controlling the robot externally and violated the safety rule. When I ran a test program on the SmartPad Pro and violated the safety rule, I saw the desired braking reaction.

I have tried writing my own code that will stop the robot in a short time by scaling the velocity down until it is zero, but I have found that this is very complicated and hard to do.

All of this has led me to this point and these possible solutions.

1. Continue writing my custom, gradual stop code. This is very complicated and likely an ineffective solution.
2. Somehow edit the kuka-external-control-sdk to differentiate between the different error types and trigger the corresponding safety reaction. This is also very complicated and likely frowned upon.
3. Wait for the ros2_controllers forum to respond.

Any other suggestions?

[gavanderhoorn]

I would perhaps look into porting the halt/stop trajectory generation from ros_control to ros2_control. If the new approach indeed requires those additional interfaces, perhaps having the old approach as a fallback could help other users without those interfaces (which would probably be the majority of robots).

[jacob-kruse]

I have found a workaround solution for the time being, although the stop produced is still too abrupt for my liking.

See this discussion thread.