Energy saving mode (servo sleep)

[Ted Miller]

Energy-savings mode can activate in the time between robot_enable and a trajectory is sent. If this occurs, the trajectory will not be rejected. It will also not work.

To disable energy-saving mode, I have to disable and then re-enable servo power. The act of disabling servos stops the robot job. Really, we need a new robot_enable call to reset everything.

So, a couple options:

1. Is it wise to add an automatic robot_enable when a trajectory is received? Are there safety concerns? What was the reasoning for requiring manual-activation in the past?
2. Add a check for energy-saving mode when determining IsMotionReady. It would probably also be smart to stop the job at that point since a robot_enable is required anyway.

Thoughts?

[Eric Marcil]

@ted-miller
#2 seems to be the minimum thing to do.
In theory, I don't see a problem with #1 but if you ask Bill, he will probably find some safety concern about it.

[G.A. vd. Hoorn]

1. Is it wise to add an automatic robot_enable when a trajectory is received? Are there safety concerns? What was the reasoning for requiring manual-activation in the past?

If the robot was already enabled at that point, and has just disabled servo power but otherwise is still running the necessary job, there shouldn't be a problem with re-enabling the servos automatically I believe.

Wouldn't that be what would happen if an INFORM job would have a large dwell time somewhere or idle section in it?

[Ted Miller]

My plan is to do a hybrid. Upon receiving a trajectory, check for energy-saving mode. If that is the only thing preventing IsMotionReady, then do an automatic robot_enable.

Once I get that implemented on the other (insert mysterious music here) interface, I'll backport to here.

[G.A. vd. Hoorn]

Marked this as a bug, as it's definitely unexpected behaviour, even if energy saving mode is essentially a well-known-function of the Motoman controller -- and is simply doing its job.

[Christian Jülg]

Upon receiving a trajectory, check for energy-saving mode. If that is the only thing preventing IsMotionReady, then do an automatic robot_enable.

I missed that important caveat in my own /robot_enable loop, which resulted in implicit resetting minor alarms like Collision Detect (4315).

I did not expect /robot_enable to have that effect of resetting errors and enabling motion when the robot status was in_error, so I just wanted to highlight that side-effect.

[G.A. vd. Hoorn]

Thanks for posting your experience here @cjue.

robot_enable is essentially a wrapper around the Simple Message service StartTrajMode, which does everything reasonable to put the controller in the state where it's ready to accept new trajectory goals and execute them.

That includes attempting to reset anything which is not a serious alarm or error and can be remotely reset.

I can see how you would not expect that though.

We'll re-evaluate whether this is something we should change -- however doing this in a bw-compatible way will probably be difficult.

---

Were there specific issues you ran into you attribute to this automatic attempt at reset/cancel?

[Christian Jülg]

Mentioning this reset of alarms in the usage tutorial introducing robot_enable would already be a fix in my eye:
http://wiki.ros.org/motoman_driver/Tutorials/Usage

Were there specific issues you ran into you attribute to this automatic attempt at reset/cancel?

This automatic error reset made it more difficult to discover the root cause of some unexpected stops, as we did not immediately check the alarm history, which is not visible at the normal security level.

My robot_enable loop was intended to let us resume ROS control of the robot as soon as issues like manual mode or e_stop were resolved, but should not reset alarms like Collision Detect

With an additional check for in_error we can be more confident that the robot is only ready to move when nothing unexpected happened.

[G.A. vd. Hoorn]

Closing as #550 was merged.