Indication of overrun of safety limits (ros ticket #4182)

[ahendrix]

The safety limits of the robot change the efforts that controllers are exerting, but the user is currently unaware that they are taking affect. Indications that the safety limits are triggering should be added.

Options for notification include:

1. rosconsole messages
2. A diagnostics panel
3. Separate topic with overrun information
4. Providing overrun information to the controller
5. rosconsole messages

Sending a warning to rosconsole is a simple way to indicate that the safety limits have been overrun.

Issues: a. Safety limit overruns occur at 1kHz, but the messages need to be rate limited to avoid flooding the console. b. How should it report that multiple joints are overrunning? This might be difficult to cram into one message. c. Realtime issues include publishing and generating strings.

1. A diagnostics panel

The diagnostics panel is a better place to show continuous information.

Issues: a. The desired update rate for diagnostics is about 1Hz, so the overrun info needs to be downsampled somehow. b. Publishing to diagnostics is also non-straightforward from realtime, but I think it might be easier than publishing to rosconsole.

1. Separate topic with overrun information

If the controller manager publishes overrun information on its own topic then it's easier to get the information at high frequency, and it's easier to analyze.

Issues: a. Not brought to the immediate attention of the user. b. May require additional tools to display the information in a meaningful way.

1. Providing overrun information to the controller

Issues: a. Not brought to the immediate attention of the user b. May require additions to the controller API, in particular extending !JointState with fields that are specific to our own safety code implemenetation.

I'm personally leaning towards option 2.

trac data:

• Owner: sglaser
• Reporter: sglaser
• Reported at: Thu Apr 15 13:31:19 2010
• URL: https://code.ros.org/trac/wg-ros-pkg/ticket/4182

[ahendrix]

[berger] #2 sounds reasonable to me. I would explore including it with the existing joints in the diagnostics display.

[ahendrix]

[gunter] How are motor-control-board errors handled. While obviously very different causes, having a motor unable to produce current or the safety limit prevent a controller from getting the torque - seem very similar in style. Just to check

a) this is safety limits only - not timing overruns?

b) can we do both: The joint state should have an error/status state that says (i) whether the safety limits are in effect and (ii) whether the motor board is working.

c) Oh, actually, can we report to joint state, what the current safety torque limits are? It probably doesn't help a controller so much to find out the limits were active last cycle. The controller really wants to know whether they will be active this cycle. And for that the controller would have to know what it wants and what the safety will allow. I.e. I'm thinking including an upper/lower torque limit in the joint state and populating with the safety code BEFORE the controllers get called.

d) For the user, it would also be nice to see some form of option 2.

-gunter

[ahendrix]

[sachinc] I would like to see (c) from Gunter's comments too. It would be nice for the controller to be aware of what the safety limits might do. A diagnostic is useful but better programmatic access would be much more useful.

[ahendrix]

[wim] It would be nice to have both 2 and 4.

Oh, actually, can we report to joint state, what the current safety torque limits are? It probably doesn't help a controller so much to find out the limits were active last cycle. The controller really wants to know whether they will be active this cycle. And for that the controller would have to know what it wants and what the safety will allow. I.e. I'm thinking including an upper/lower torque limit in the joint state and populating with the safety code BEFORE the controllers get called.

All information about the safety limits is part of the urdf, so it is available to each controller or node. Adding it to the joint states will just duplicate this information. Also, keep in mind that the safety limits are more than just a min/max joint angle; the limits have two joint angles, a velocity and an effort. The effort a controller can apply will change depending on both (i) the current joint position, (ii) the current joint velocity and (iii) the specified max effort. It could be useful though to make the controllers aware that the safety controller modified the commanded effort.

[ahendrix]

[berger] It's true that the information is there, but since it's a computation based on the current state (e.g. the velocity limits will change based on the position), it would be useful to either make the current results of the computation available, or have the computation of safety limits exposed to users so that it would be easy to answer questions about the safety limits without re-implementing those algorithms in each piece of code that cares.

[ahendrix]

[sglaser] I've added JointState::getLimits() in r35677 which provides my option 2 / Gunter's option c. One caveat: it doesn't currently take into account the current limit of the motor. I'm looking into that.

[ahendrix]

[wim] Oh I see, we want to get the min/max effort of a joint based on the measured joint state. That's great!