Requirement for Automatic Mode

[dmi-zie]

TL;DR Version:
Why is the Automatic Mode required? And could it be dropped in order to make abb_robot_driver usable in Manual Full Speed Mode?

Extended Version:
We would like to use abb_robot_driver with the egm hardware interface in an experimental human-robot collaboration setup. In order to add an additional layer of safety we plan to use a three-position enabling device for enabling/disabling robot movement. Since we are not going into production, we consider using the Manual Full Speed Mode for regular operation. This would make the setup easier, since we could use the three position enabling device which is already integrated into the flex pedant of the IRC5. Beside of our specific use case, I think that the possibility to test new developments in Manual Full Speed Mode would be of great benefit in general.

However, a lot of functions in abb_robot_driver explicitly check if the controller is in Automatic Mode and permit further execution if this is not the case. As far as I know, these restrictions do not result from limitations within Robotware itself. EGM as well as RWS work in Manual and Manual Full Speed Mode.

I have skimmed over the code in abb_robot_driver(incl. involved libraries) and found two points where Automatic Mode is explicitly required:

1. In abb_libegm - related to the RWSStateMachineInterface. Toggleing an IO Signal with toggleIOSignal(...) is restricted if the robot is not in Automatic Mode. From what I have seen, these IOSignals are used to spawn an interrupt on the controller side in order to transition between different states.

2. In abb_robot_driver - most functions performing an interaction with the controller call verifyAutoMode(…) and abort further execution if false.

For a quick test I have removed these two checks and was able to move the robot(simulated) in Manual Full Speed Mode by following the second bringup example. However, my quick hack may result in some problems down the line which I am not aware yet. Since I am in no way proficient or experienced with RAPID or the abb_robot_driver I don't think that i would be able to catch all possible implications just by analysing the code.

One problem I can think of is related to (1). In manual mode program execution could be stopped, or robot movement could disabled by the 3-way switch. In this case the signal would toggle, but the interrupt would be discarded. But would this cause any troubles? And if yes - would a less a less restrictive approach (e.g. check if RAPID is currently running?) may be sufficient to ensure that the interrupt fires as requested.

Are there any other reasons why the strict requirement for Automatic Mode is needed?

[enricovillagrossi]

I'm also interested in the topic.
@gavanderhoorn have you feedback on this?

[gavanderhoorn]

I don't remember exactly any more, but it could be AUTO was required as it would prevent users from violating the single-point-of-control principle (ie: either ROS is in control, or the TP, but not both).

Being able to invoke services and initiate actions remotely while having the TP also active seems like a nice idea, until someone sitting behind a PC initiate an unexpected action while your colleague is standing next to the robot.

Yes, the TP would still be an enabling device in that case, but (s)he may not be paying attention or enable the robot to initiate some other action while the driver (on request of a (ROS) user) initiates another. At the very least, that's confusing. In the worst case, it's dangerous.

While not a complete solution, requiring AUTO helps reducing this ambiguity, as running controllers in AUTO mode also 'requires' a correctly working safety system (everything depends of course on how the controller and safety system is configured, but there's only so much we can do in abb_robot_driver).

[dmi-zie]

Thank you for your detailed reply!

This is a valid point you make! I think that you are right, that in general the TP operator will assume that he is in full control of the robot and it could really pose a severe safety danger if it turns out otherwise in reality. From that point of view I agree that this is already sufficient for the requirement for Automatic Mode by default.

At a first glance, our use case may be a different kind of scenario, since the operator knows that he has just a supervising function and that the robot will follow be doing whatever ROS is requesting as soon as it is allowed to do so. The automatic mode would not activate any additional safety devices. But I have to admit, that we did not discuss this single-point-of-control perspective and need to reevaluate this in more detail.

Would you say that beside this violation of the single-point-of-control principle it is technically possible to run the abb_robot_driver in manual full speed mode? Could this cause any troubles with the state machine running on the robot controller or the ROS side of the interface?

[gavanderhoorn]

Technically it'll probably be ok. But I cannot guarantee anything.

From a safety perspective it makes me uneasy.

I'd suggest you talk to your ABB support contact to have them advice you how to correctly implement the scenario you describe.

Perhaps there is a way SafeMove could be configured, perhaps with additional safety inputs to enable controlled stops, to make this safe.

[gavanderhoorn]

since the operator knows

this is going to sound pedantic, but these are exactly the kinds of rationales which led to the expression "famous last words".

there only has to be one operator that doesn't know this, or isn't paying attention, or the person controlling the ROS PC isn't paying attention, or they both have a bad day, etc, etc, for this to go wrong.

I'm sure you get the point by now, so I'll stop the hyperbole, but please do not assume anything about anything when dealing with safety and industrial robots. Even if they are as weak as a YuMi.

[dmi-zie]

Ok. Thank you for your assessment.

Also your remarks regarding the safety perspective are valuable - and by no means pedantic. We will discuss this and reevaluate how we proceed.