[ros-users] [Orocos-users] Joint controller manager
Herman Bruyninckx
Herman.Bruyninckx at mech.kuleuven.be
Mon Jan 28 16:51:55 UTC 2013
On Mon, 28 Jan 2013, Jonathan Bohren wrote:
> Based on this thread, and from what I know about other efforts going on in the
> community, I just went ahead and created a google group called "ros-robot-control-sig"
> [1].
> My thought is that purpose of this group should be to coordinate efforts on a common
> interface for robot control in a ROS-based system as well as a common realtime-friendly
> and simulation-friendly controller architecture. While different platforms will always
> call for different architectures, it would be great if the different systems spoke the
> same ROS interfaces, and if similar computation platforms could use the same libraries
> for control.
Allow me to disagree... Putting the design of interfaces (and "topic" data
structures) at the level of a programming language as the most important
design decision is wrong: robotics is one of the few technology domains
(together with computer vision and machine learning) where software and
systems are made 100% by compilers and hand-written libraries; other
domains (automative, aerospace, mechatronics and control,...) start with
standardizing _models_ (and their semantics), and _generate_ code from
there.
What I now see happening all the time (and especially in the context of
so-called "hackathons") is that developers _have_ to look at each others'
implementations in order to make components/nodes work together, since the
_meaning_ of the topics is not ambiguously defined. (Similar problems occur
at the level of the "actions": too many configuration parameters are in the
"code" and not in the "model".)
And finally, the data topics on their own never fully represent an
_interface_ between two concurrent activities: there just represent functional
data flow, but also discrete coordination, bi-lateral QoS
adaptations, introspection, and data buffering policies are parts of the
interaction between components.
> If you are working on such an architecture, please sign up and post a link to your
> project and please share your experiences. It's open for anyone to join!
>
> Please also don't hesitate to join the list and tell us all that such an effort is
> futile, and why you think so ;)
>
> [1] https://groups.google.com/forum/?fromgroups#!forum/ros-robot-control-sig
>
> -jon
Herman
>
> On Mon, Jan 28, 2013 at 11:11 AM, Willy Lambert <lambert.willy at gmail.com> wrote:
> 2013/1/28 Jonathan Bohren <jonathan.bohren at gmail.com>:
> > Adolpho,
> >
> > This is great stuff!
> >
> > I've also been working on an orocos-based controller manager that has a
> > similar interface to the ROS PR2 controller manager. The system I put
> > together a year ago is really rough around the edges and could be
> designed
> > much better, though. I was already planning on jumping into a rewrite and
> > it'd be great to brainstorm ideas and put together something that can be
> > used by the community.
> >
> > One thing that I think the ros-orocos integration needs is better support
> > for actionlib for calling orocos operations over ROS.
>
> +1
>
> >
> > Another thing that I'd like to ensure is that the controller infrastructure
> > integrates well with the gazebo simulator, either via plugins or just over
> > the gazebo ROS interfaces.
> >
> > There's a lot more that I think we should talk about, maybe we should create
> > a ros-robot-control-sig?
> >
> > best,
> > -jon
> >
> >
> > On Mon, Jan 28, 2013 at 10: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 - Twitter - PAL Robotics YouTube Channel
> >>
> >> 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
> >>
> >
> >
> >
> > --
> > Jonathan Bohren
> > PhD Student
> > Dynamical Systems and Control Laboratory
> > Laboratory for Computational Sensing and Robotics
> > The Johns Hopkins University
> >
> > (707) 520-4736
> > jbo at jhu.edu
> >
> > _______________________________________________
> > ros-users mailing list
> > ros-users at code.ros.org
> > https://code.ros.org/mailman/listinfo/ros-users
> >
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
>
>
> --
> Jonathan Bohren
> PhD Student
> Dynamical Systems and Control Laboratory
> Laboratory for Computational Sensing and Robotics
> The Johns Hopkins University
>
> (707) 520-4736
> jbo at jhu.edu
>
>
--
KU Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
Vice-President Research euRobotics <http://www.eu-robotics.net>
Open RObot COntrol Software <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
More information about the ros-users
mailing list