E-stop handling on ros control

asked 2022-06-02 01:48:05 -0500

RyanChen.YLC
44 ●4 ●13 ●15

Hi, all.

I have a real mobile robot and can control it well with ROS control framework.

However, for security issue, I want my robot can immediately stop when dynamic obstacles, such as people, showing up within the 3m range of its lidar sensing area. So I need an e-stop handling function.

Followings are 2 ways that may fit the function:

1) Create a node that checks sensing area, if obstacles exist, use service call to stop the ros controller.

2) Create a node that checks sensing area, if obstacles exist, sends a high level cmd_vel to "Twist_mux" to override the command from the ros controller.

I want to know which is the best and most secure way to solve the issue, or any other solution?

Thanks.

edit retag flag offensive close merge delete

add a comment

answered 2022-06-02 02:55:26 -0500

Joe28965

1124 ●3 ●73 ●28

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.

edit flag offensive delete link

Comments

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 ...(more)

RyanChen.YLC ( 2022-06-05 20:28:23 -0500 )edit

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?

RyanChen.YLC ( 2022-06-05 22:00:13 -0500 )edit

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.

Joe28965 ( 2022-06-06 00:02:10 -0500 )edit

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.

RyanChen.YLC ( 2022-06-06 03:43:27 -0500 )edit

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.