[ros-users] Joint controller manager

Tue Jan 29 11:48:21 UTC 2013

On Mon, Jan 28, 2013 at 11:28 PM, Sachin Chitta <sachinc at willowgarage.com>wrote:

> Hey Adolfo,
>
> Hey Sachin,

> Thanks for this email. It brought out a good set of ideas on what we want
> from a controller framework. I will try and address your points with
> regards to [1] - the PR2 independent controller infrastructure that we have
> been developing.
>
> The main goal of this work is to develop a robot-agnostic version of the
> PR2 controller infrastructure. In addition, we aim to develop a few
> (limited set of) controllers (based on the current set of controllers we
> have for the PR2) and release them as an open-source robot agnostic library.

We seem to be pretty much on the same page.

> The controller manager and the controllers are intended to be usable with
> multiple realtime operating systems.

This statement makes me very happy, more below...

> A further part of this project is to take some of the workhorse
> capabilities performed by some of the controllers, e.g. the
> FollowJointTrajectory action and break them up into more sensible libraries
> (in addition to an actual controller implementation) that can be used
> across robots.
>

Yes!, about a year ago I spent many hours porting the FollowJointTrajectory
controller to our infrastructure. One pain point was comparing timestamps
generated in hard-rt and non-rt contexts [2]. Another one was separating
trajectory processing from PID control, as mentioned in an earlier post.
The downside of this effort was that I ended up with a separate codebase to
maintain, whose improvements cannot be readily merged upstream. The upside
was that I learned quite a bit by going down there :).

[2]
http://www.orocos.org/forum/orocos/orocos-users/comparing-timestamps-generated-rt-and-non-rt-contexts

> To answer some of your more direction questions:
>
> - Is it possible to have a controller with multiple interfaces (eg. send
> position + velocity + effort commands)?.
> yes, you will have to implement an interface that incorporates all these
> commands.

> - If I understand correctly, interfaces are limited by design to position,
> velocity and effort, and adding a new one (fancy example: stiffness) is not
> possible, correct?.
> Not true, you can implement other types of interfaces as well.

Thanks for clarifying the two above points, this is great news!, so no
blockers here.

>
> - Is it possible to chain controllers as in the attached figure
> (r_arm_follow_joint_traj + r_arm_pid_controller) from configuration files,
> ie. without writing code?.
> The follow joint trajectory controller will probably reuse the PID
> controllers (if that's what you are asking), but directly in code. I think
> I understand what you are referring to - we could design individual
> controllers to be more flexible so they can do something like this but its
> not something we have put much thought into yet.

I'm very interested in having a FollowJointTrajectory controller that does
not output an effort command. Chaining controllers without writing code is
important for many use cases. A very simple one is a position-controlled
robot, whose hardware interface directly accepts position commands, but
whose simulated interface (because of simulator constraints) only accepts
effort commands.

>
> - Controllers running at lower frequency than the manager need to
> implement this by doing work only one out of every n cycles, as separate
> controller threads are not supported, correct?.
> The intention of this work is to provide a simple single-threaded
> infrastructure. We are probably going to stay away from anything more (e.g.
> multi-threading, etc.) mainly because there's other tools out there that
> will provide some of those capabilities for you.

If controllers can be triggered by timers that can be individually
configured, as Herman suggests in a previous post, your solution works just
fine. The other benefit of having stuff in separate threads is protection
against mode switches and overruns, but proper monitoring and supervision
allowing to be aware that these things are happening also works for me.
Food for a second iteration.

>
> - Is there any work on decoupling the more common "workhorse" controllers
> out of the pr2_controller_manager infrastructure (eg. a couple of mobile
> base implementations, the FollowJointTrtajectory action)?. I've already
> spent some time factoring out the spline splicing and interpolation code
> from the FollowJointTrtajectory action, and was planning on writing some
> unit tests on it. If not, I can also make this available once the cleanup
> is complete.
> Yes. We probably won't do the mobile base though.
>

> This is a joint project with a spin-off from Willow Garage: HiDOF Inc. (
> hidof.com). As the project matures, more documentation will be added to
> make some of these things clearer.
>

The copyright statements and commit logs indeed reflect that :)

Thanks for the very valuable feedback.

Adolfo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20130129/7a39f702/attachment-0004.html>