Closed pbeeson closed 6 years ago
Thanks for the PR.
Something to think about: semantically I would say that a "paused" robot can be resumed, which would imply it would also resume whatever it was doing. As the pause_robot
service cancels any active goal, this is not the case with this implementation.
I'm fine with cancelling the current goal, but then I feel the service should not be called pause_*
.
I agree, and don't mind changing this to "Halted" or "E-Stopped" or similar.
Terminology has been changed from pause/unpause to disable/enable.
We should also update the robot driver spec page after we merge this (section 1.3.3, services).
@gavanderhoorn I addressed all your issues, as they were reasonable.
Now there are Trigger services for Enagle and Disable and a GetEnabledStatus message in industrial_msgs with an appropriate service. This is also in motoman_driver as desired. Maybe someone can consider testing this PR? It works for us.
Waiting on discussion in ros-industrial/motoman#155
So, I realize this was similar to the PR in the motoman driver, but this is at the industrial client level so it allows users to use and test safe control enable/disable in industrial sim and any other ROS industrial robot at a "mid-level" of the control flow.
Closing this PR because I made it from my main branch a year and a half ago and no that branch has other changes that should be separate PRs. PR #215 has the minimal commits that address this PR.
For safety, it is sometimes desirable to have a "software level e-stop". This essentially does that for ROS-I robot by adding a service that "pauses" or "unpauses" the robot by allowing goals to come through. If the robot is paused, any current goal is canceled via the cancelCB() function, stopping the robot.
Discussed here: https://github.com/ros-industrial/motoman/issues/152