search

PR2 / pr2_mechanism

Infrastructure to control the PR2 robot in a hard realtime control loop.
Other
27 stars 27 forks source link

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

Open ahendrix opened 11 years ago

ahendrix commented 11 years ago

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:

ahendrix commented 11 years ago

[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 commented 11 years ago

[berger] Only useful if this is reliable.

Prioritize for 1.1

ahendrix commented 11 years ago

[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 commented 11 years ago

[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 commented 11 years ago

[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.