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 wrote: > 2013/1/28 Jonathan Bohren : > > 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 > > 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@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@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@jhu.edu > > > > _______________________________________________ > > ros-users mailing list > > ros-users@code.ros.org > > https://code.ros.org/mailman/listinfo/ros-users > > > _______________________________________________ > ros-users mailing list > ros-users@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@jhu.edu > > -- KU Leuven, Mechanical Engineering, Robotics Research Group Tel: +32 16 328056 Vice-President Research euRobotics Open RObot COntrol Software Associate Editor JOSER , IJRR