controller_manager: publish controller timing state (ros ticket #3397)

[ahendrix]

At a fairly low frequency (so as to try to get all the packets through realtime_publisher), publish as an array the dt data on all cycles of each controller. The goal is to emit timing data on all cycles for all controllers, so that externals tools can analyze it.

trac data:

• Owner: wim
• Reporter: gerkey
• Reported at: Mon Jan 4 11:42:56 2010
• URL: https://code.ros.org/trac/wg-ros-pkg/ticket/3397

[ahendrix]

[gerkey] If possible, provide some kind of frame / cycle number that can be used to correlate timing data with overrun errors from etherCAT (#3018).

[ahendrix]

[berger] Only useful if this is reliable.

Prioritize for 1.1

[ahendrix]

[wim] With the new rt-publishers that will be part of D-turtle, you can configure the controller manager to publish joint states at 1000 Hz. So this feature might not be needed any more.

[ahendrix]

[gunter] I didn't think the timing information is part of the joint states or even currently computed?

When all is said and done, the controller manager is really acting like a simple realtime scheduler, coordinating the various realtime threads (controllers). As I understood the request, it was to allow the user to see the timing information of each thread. Meaning it would be great to see what times were used in which controller. [I won't even mention that the manager could then act on such information, e.g. de-prioritizing a controller that is taking too much time...]

Maybe this is best done via OROCOS integration - though I have no idea on what schedule that will occur. But I'm hesitant to believe that the rt-publisher alone provides the feature.

[ahendrix]

[sglaser] The timing information is not currently in the joint states. Rough aggregates are thrown into the mechanism statistics, but I want access to the run time for every controller.

The current realtime publisher is unable to publish at 1kHz, but the new rosrt publisher is capable of it. That's why this feature is waiting on better realtime publishing. The controller manager already knows how much time each controller is taking; it's just having difficulty pushing it out fast enough.

In short, the new rt-publishers in rosrt make implementing this feature straightforward, but the implementation does require adding a "controller timings" topic.