[ros-users] Joint controller manager

Sachin Chitta sachinc at willowgarage.com
Mon Jan 28 22:28:03 UTC 2013


Hey Adolfo,

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. The controller manager and the controllers are intended to be
usable with multiple realtime operating systems. 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.

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

Best Regards,
Sachin


On Mon, Jan 28, 2013 at 7:04 AM, Adolfo Rodríguez Tsouroukdissian <
adolfo.rodriguez at pal-robotics.com> wrote:

> Hello ROS and Orocos users,
>
> This is a call for feedback. I'm currently working on a "joint controller
> manager", that is, a component that manages joint resources and exposes
> them to control. For those familiar with the pr2_controller_manager, this
> would provide similar functionality and interfaces, while relaxing some
> constraints to allow easy porting to different hardware platforms. Exposing
> hardware to control (and realtime control in particular) is still a big
> hurdle, and it would be very desirable to make this at least an order of
> magnitude easier. Once a minimal set of controller interfaces are made
> available for a given platform (eg. mobile base controller, spline
> interpolator, ...), a truckload of higher-level functionality becomes
> available.
>
> At the moment I have an existing in-house solution that from a ROS API
> point of view looks pretty much like a pr2_controller_manager, and a design
> of where I'd like things to go, which is attached to this message in pdf
> form. As a next step I was planning on setting up a public repo and port
> the existing design from Orocos 1.x to Orocos 2.x, which adds the
> expressivity needed to address the missing features. But before that, I'd
> like to make a pause and ask for some feedback.
>
> - Is there interest in giving this topic a dedicated discussion place,
> like a mailing list or a ROS special interest group?.
>
> - If you take a look at the attached design, please be critic about it.
> What would you add or remove?, what would you do differently?.
>
> - What can you not accomplish (or have had trouble accomplishing) with the
> tools you or your team have used so far?.
>
> Finally, I'd like to be aware of any active and similarly scoped
> initiative, so please let me know if you're working on the subject. Late
> last week I found out almost by chance about the yet undocumented
> ros_control [1] repository, which deferred the writing of this email a day
> so I could familiarize with it. Its scope is very much aligned with my
> current objectives, as it consists of a library offering functionality
> similar to that of the pr2_controller_manager that can be adapted to other
> robot platforms. I'm looking forward to sharing opinions and use cases with
> all interested parties, and if possible map interest overlaps to common
> code. Some questions that come to my mind after reviewing the code in [1]:
>
> - Is it possible to have a controller with multiple interfaces (eg. send
> position + velocity + effort 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?.
>
> - 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?.
>
> - 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?.
>
> - 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.
>
> That's it for now, thanks for reading.
>
> [1] https://github.com/willowgarage/ros_control
>
> --
> Adolfo Rodríguez Tsouroukdissian
> Senior robotics engineer
> adolfo.rodriguez at pal-robotics.com
> http://www.pal-robotics.com
>
> PAL ROBOTICS S.L
> c/ Pujades 77-79, 4º4ª
> 08005 Barcelona, Spain.
> Tel. +34.93.414.53.47
> Fax.+34.93.209.11.09
> Skype: adolfo.pal-robotics
> Facebook <http://www.facebook.com/palrobotics1> - Twitter<http://twitter.com/#%21/palrobotics>- PAL
> Robotics YouTube Channel <http://www.youtube.com/user/PALRobotics>
>
> AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos, pueden
> contener información privilegiada y/o confidencial que está dirigida
> exclusivamente a su destinatario. Si usted recibe este mensaje y no es el
> destinatario indicado, o el empleado encargado de su entrega a dicha
> persona, por favor, notifíquelo inmediatamente y remita el mensaje original
> a la dirección de correo electrónico indicada. Cualquier copia, uso o
> distribución no autorizados de esta comunicación queda estrictamente
> prohibida.
>
> CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may
> contain confidential information which is privileged and intended only for
> the individual or entity to whom they are addressed.  If you are not the
> intended recipient, you are hereby notified that any disclosure, copying,
> distribution or use of this e-mail and/or accompanying document(s) is
> strictly prohibited.  If you have received this e-mail in error, please
> immediately notify the sender at the above e-mail address.
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>


-- 
Sachin Chitta
Manager and Research Scientist
Autonomous Mobile Manipulation Group
Willow Garage
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20130128/bfc08e33/attachment-0004.html>


More information about the ros-users mailing list