Revision history [back]

Generally, even normal PLCs aren't rated to use as safety system (if you're talking ISO 26262 at least).

I think what it comes down to in this specific case is: What kind of robot are you using?

We had a robot that weighed 100kg, we used electromagnetic fail-safe brakes hooked up to a safety PLC and specific safety lidars to decide when to overrule the brakes.

If you're talking a 5kg robot that drives < 1m/s you don't need an "e-stop" which is indeed a safety term you shouldn't use to describe something that's not safe (in your situation, what happens if your 'safety node' simply isn't running, or crashes? Nothing guards against that).

However, rewriting the question to: I want my robot to stop when dynamic objects get within 3m of my robot, then there is a ROS answer. First, I would like to reiterate that I do agree with @gvdhoorn that this is not a safety solution and it should not be used as a 'nothing to worry' system.

Simply said, option 2 has its flaws. twist_mux works by subscribing to various topics (example joy/cmd_vel nav/cmd_vel keyboard/cmd_vel) and publishes the one with the highest priority to robot/cmd_vel (example). Nothing is stopping you from directly publishing to robot/cmd_vel, either by accident or maliciously (that might be a bit dramatic, but it's still a simple truth). Then you would get conflicting messages being send (one that says drive at x velocity, the other one says drive at 0) so the robot probably still won't drive. However, it is not a clean solution.

ros_control directly controls the wheels and it would cut it off there. It would probably also require you to send a confirmation that it's allowed to drive again, instead of you simply no longer publishing (sending a confirmation is also a more conscious choice, if your node crashes in between stop and go, ros_control will not move anymore because it's not getting the go).

Again, it's not an e-stop and you shouldn't say it's 'safe' after.