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.
Originally posted by Joe28965 with karma: 1124 on 2022-06-02
This answer was ACCEPTED on the original site
Post score: 1
Original comments
Comment by RyanChen.YLC on 2022-06-05:
Thanks for replying, @Joe28965 and @gvdhoorn.
My robot type is AGV which weighed 1000 kg and equipped with 4 safety lidars.
What I want is almost the same as your function "we used electromagnetic fail-safe brakes hooked up to a safety PLC and specific safety lidars to decide when to overrule the brakes." I will try this.
But I have a question:
When AGV's safety lidars detect the people inside the stop area, it enables the brake to stop motors. However, the command in software (cmd_vel) is still sent (maybe 1 m/s), which is what I don't want.
So I add a variable named "stop_active_" in my ROS controller, and set it to TRUE while the safety system in hardware (assume I followed your way) is ON to make the command zero, does this make sense?
I think if software and hardware can realize safety system at the same time, it will be much safer.
Comment by RyanChen.YLC on 2022-06-05:
Update:
According to this post answered by @gvdhoorn, the hardware_interface can't directly interact with the controller. So, what I mentioned above ("add a variable ... make the command zero") can only be realized through registering custom hardware_interface?
Comment by Joe28965 on 2022-06-06:
Oh yeah, at a 1000kg you can not rely on ROS for any kind of safety. It might be interesting to see how the safety lidars are being hooked up. I assume there is a safety PLC present?
We never bothered to let ROS know that safety was engaged (either by lidars or emergency button). However, we did tell the normal PLC (I believe to stop it sending commands to the motor and potentially burning out the motors, since that thing couldn't even be pushed by the two of us if the brakes were engaged).
It would then be possible to send that command to ROS using OPC-UA (we specifically used open62541) and have it tell ros_control to stop moving.
Comment by RyanChen.YLC on 2022-06-06:
Well, this is beyond my comprehension. I've never heard OPC-UA because I know little about PLC.
But thanks for your help, I'll try my best to figure that out.
Comment by gvdhoorn on 2022-06-06:
ControllerManager::update(..) takes a reset_controllers arg.
That's what you set to true in the cycle where you detect you "should stop moving".
You can also use something like the controller_stopper node(s), which will shutdown controllers which should not be running whenever "some event" occurs.
@Joe28965:
We never bothered to let ROS know that safety was engaged (either by lidars or emergency button).
You do really want to make sure you synchronise ros_control and whatever else is "controlling" your robot. Otherwise bad things can and will happen.
Comment by RyanChen.YLC on 2022-06-06:
@gvdhoorn,
I followed your advice to try setting reset_controllers to true.
While the arg is true, the stopping() will be triggered and followed by starting(),which is so called "reset".
But at the same time, once I keep sending cmd_vel (Vx = 0.3) (from my joystick), the command calculated won't be zero.
This situation looks like:
see image
which write (front / rear) (steer / wheel) I expect them to be zero.
Comment by RyanChen.YLC on 2022-06-06:
Update:
I think I figured out the solution. I can add some operation in stopping() and starting() to make command zero.
Thanks for your help!!!
