Differentiating strengths of ros_control and OROCOS

[Daniel Loret de Mola Lemus]

Hello,

I am evaluating the use of ros_control or OROCOS to redesign the control layer of the robots at the company I work for, and I would like to ask those of you with practical experience on both frameworks about their particular advantages as compared to each other. I spent a few days investigating current open source control frameworks, and I narrowed it down to those two. The benefits I see in using ros_control are that our robots would be entirely within ROS' ecosystem, its development has been very active throughout the last year, and seems that it will be well supported in the future. In the case of OROCOS, it seems to me that it gives greater freedom when implementing control architectures. However, I do not have experience with any of them, so that is why I am seeking input on them.

In general, I would like to know why would one choose one over the other. For example, what are the use cases that each framework excels at? What use cases motivated the development of ros_control that OROCOS could not properly address?

Also, in terms of control engineering, what can be done in OROCOS that cannot be done in ros_control, and vice versa? For instance, I read that controllers implemented as OROCOS components can easily be set to work at different frequencies, while in ros_control cycle-skipping has to be hard coded in the controller (although I saw a patch in GitHub that tried to alleviate this). Another thing is that the controller manager in ros_control runs in a single thread, while multithreaded processes are possible in OROCOS.

It will be very helpful in our decision process if you could share with us your points of view and experiences with these frameworks.

Thank you,

Daniel

[Jonathan Bohren]

Daniel,

As you've correctly observed, Orocos and ros_control serve different roles in the space of open-source robot control. As you've seen, while Orocos is very much integrated with the ROS ecosystem these days [1], it was developed independently from ROS. ros_control, on the other hand, grew out of the controller architecture developed for the PR2 at willow garage. These separate origins are readily apparent in the capabilities and patterns afforded by the two systems.

Orocos, at its core, is a general-purpose component-based programming architecture. This includes abstracted facilities for component lifecycles, threading, scheduling, communication, and logging. This means that while superbly useful for building robot control systems, it is about as "robot-specific" as is the ROS core. Orocos components are like ROS nodes, and the graph of Orocos peers is provides similar scoping functions as the tree of ROS namespaces. Orocos DataPorts play the same role as ROS Topics, and Orocos Operations play the same role as ROS Services. This means that it's fairly intuitive to integrate Orocos components. Where Orocos's analogous functionalities differ from ROS, however, is in how they are built to support real-time execution from the ground-up. Orocos even provides an extensible architecture for defining real-time safe transports for datatypes (as are generated for ROS messages automatically via the `rtt_roscomm` package [2]), ad well as a real-time scripting language for integrating components. This real-time scripting language is an invaluable tool for debugging, since it gives you a live console with which you can introspect on, start, stop, reconnect, and reconfigure components. 

With great flexibility, however, it is up to Orocos component implementers to enforce design patterns and standards if they wish to share components with each-other. As such, it is, in general, unlikely that two sets of control components which were developed on top of Orocos independently by two different research groups could interoperate. This is because in order to do so, they would need to agree on (i) datatypes, scheduling patterns, configuration parameters, and external APIs which expose the component capabilities to higher-level systems like those running in ROS.

ros_control enters from the opposite direction. It begins with a design pattern (single-thread, single-hardware device) which proved easy to use when building controllers for the PR2. Additionally, it standardizes on only one representation for each type of semantic command implementation. It also enforces a resource model which enables reasoning about which controllers can be running at once. While this means that it's easier to share controllers, it also means that controllers are more likely to be monolithic since they cannot be inter-connected. In ros_control, controllers talk to a hardware interface, but controllers cannot talk to other controllers. This means that for fully-integrated, PR2-like platforms, ros_control fits well. In a laboratory setting, however, where you have more modular, sometimes hacked together hardware, building a ros_control hardware interface for each permutation of devices begins to explode. There have been numerous proposed extensions to ros_control, as you have also seen, but I haven't been keeping up with them too closely.

In over-simplified summary: Orocos gives you flexibility, and ros_control gives you simplicity. I've been trying to mitigate some of the issues with both approaches through the introduction of an Orocos controller manager called ConMan [3]. ConMan provides a similar serial execution pattern to ros_control, as well as a resource-aware switching functionality. At the same time, since it's implemented in Orocos, it's easy to break out of the scheduling constraints when necessary. I won't go into more detail here, but I will say that ConMan supports the same service calls as ros_control for switching and introspecting on running controllers, as well as a deeper introspection interface integrated with the rqt framework [4].

-j

[1] rtt_ros_integration: https://github.com/orocos/rtt_ros_integration

[2] rtt_roscomm: https://github.com/orocos/rtt_ros_integration/tree/hydro-devel/rtt_roscomm

[3] ConMan: https://github.com/jbohren/conman

[4] rqt_conman: https://github.com/jbohren/conman/tree/master/rqt_conman

--
Jonathan Bohren
Laboratory for Computational Sensing and Robotics
http://dscl.lcsr.jhu.edu/People/JonathanBohren

[Daniel Loret de Mola Lemus]

Jonathan,

Thank you for your thorough reply and the helpful links. This resonates with the general idea I gathered when reading about the frameworks: with OROCOS one has fine-grained control over the implementation of the control system, but it is up to you to define a general architecture. On the other hand, ros_control has clear abstractions for controllers and the hardware interface (actuators/sensors), but the controllers are not modularized.

Along the latter idea, you mentioned controllers in ros_control cannot talk between each other. Is it possible to interconnect controllers through code (and just expose one of them to the manager) even if they get wrapped together as a single plugin at launch?

ConMan looks like a great addition to OROCOS. I liked that it mimics ros_control's manager but it still gives you the ability to run several schemes in parallel.

Thank you again for your valuable input.

Daniel

[Adolfo Rodríguez Tsouroukdissian]

On Fri, Aug 1, 2014 at 5:31 AM, Daniel Loret de Mola Lemus <danie...@hotmail.com> wrote:

Jonathan,

Thank you for your thorough reply and the helpful links. This resonates with the general idea I gathered when reading about the frameworks: with OROCOS one has fine-grained control over the implementation of the control system, but it is up to you to define a general architecture. On the other hand, ros_control has clear abstractions for controllers and the hardware interface (actuators/sensors), but the controllers are not modularized.

All,

Daniel, your question is a very relevant one, and is an issue that has been present in my thoughts for a few years now.

Jon, that was a great comparison, and reflects rather well the current state of affairs.

One way to (over) simplify the choice between the two alternatives is to see the extreme usecases.

The hardcore control person:

- You have a good background in programming and control

- You want to implement nontrivial control architectures, with complex interactions between controllers

- Your system _likely_ has realtime constraints, and feel comfortable writing realtime-safe code

- You are not intimidated by learning two frameworks: ROS and Orocos; or you already know them

- You are not so concerned about leveraging or exchanging controllers with a larger community, especially those that interact with higher-level ROS tools

The robot application creator, or system integrator:

- You may not know so much about control, but are proficient in higher-level tools that interact with controllers, like motion planning

- Your controllers are not subject to complex interactions, and when they exist, they can be statically specified (i.e., bundled in a controller plugin)

- Your system _may_ have realtime constraints, but you may not have that much experience writing realtime-safe code

- You prefer to avoid learning another framework

- You are looking forward to leveraging existing controllers rather than writing new ones, with an emphasis on those that interact with higher-level ROS tools

Orocos will likely be a better tool if you're closer to the 'hardcore control person' end of the spectrum, while ros_control will fit better if you're closer to the 'application creator, system integrator' end of the spectrum. At least, that is my personal opinion. Having used both quite extensively, I must say that either tool will likely get the job done, but as you venture more into the 'other' end of the spectrum, you will find yourself stretching the tools, missing features of its counterpart, or incurring in additional development overhead. The conman project by Jon is a good example of a different set of compromises.

There are no hard technical barriers standing in the way of having a solution with much less compromise. It's just a lot of work to get all bases covered, and there's plenty of space for discussing, designing and implementing how to best get there.

Along the latter idea, you mentioned controllers in ros_control cannot talk between each other. Is it possible to interconnect controllers through code (and just expose one of them to the manager) even if they get wrapped together as a single plugin at launch?

You can do that, yes. The downside is that you end up with as many plugins as permutations you're interested in. A very crude form of this is done when adapting a controller to different hardware interfaces. The joint_trajectory_controller [1], for instance, has three variants that produce commands for position, velocity and effort joints.

[1] https://github.com/ros-controls/ros_controllers/blob/indigo-devel/joint_trajectory_controller/include/joint_trajectory_controller/hardware_interface_adapter.h

Cheers,

Adolfo.

--
You received this message because you are subscribed to the Google Groups "ROS/Orocos Robot Control Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-robot-co...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Adolfo Rodríguez Tsouroukdissian
Senior robotics engineer
adolfo.r...@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.

[Daniel Loret de Mola Lemus]

Adolfo,

Thank you for replying and enriching the information provided with your point of view.

I think that the description of the two spectrum ends you gave is a great way for us to ponder the framework choice based on some of our high-level needs. With respect to the point about experience writing real-time safe code, why is it not that important in the ros_control end, assuming one has real-time constraints? Does ros_control provide facilities (the controller manager?) that OROCOS doesn't which simplify it?

Thank you also for addressing my last question, and giving a link to an example with your answer.

Regards,

Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-robot-control+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Adolfo Rodríguez Tsouroukdissian]

On Mon, Aug 4, 2014 at 6:27 AM, Daniel Loret de Mola Lemus <danie...@hotmail.com> wrote:

Adolfo,

Thank you for replying and enriching the information provided with your point of view.

I think that the description of the two spectrum ends you gave is a great way for us to ponder the framework choice based on some of our high-level needs. With respect to the point about experience writing real-time safe code, why is it not that important in the ros_control end, assuming one has real-time constraints?

The statement is meant in the sense that: 1. you might not have realtime constraints (or only soft ones); or 2. you do have realtime constraints, but your robot and application is such that you can leverage the existing codebase enough that you end up not having to write much (or not at all) realtime code.

 

Does ros_control provide facilities (the controller manager?) that OROCOS doesn't which simplify it?

ros_control provides a set of ready-to-use blocks of functionality that are common to many robot setups. The controller_manager is one example, but you also have controller implementations, mechanical transmissions, joint limits enforcement, etc. It's not only the realtime aspects that make them useful, it's also the ease of configuration and integration, especially if you ROS elsewhere in your system.

If we now talk about lower-level functionality for realtime programming, like lock-free data structures, realtime memory allocators, realtime logging, clock access, and general RTOS abstraction, then OROCOS has the clear upper hand.

The challenge at this point is on how to _combine_ the best of two worlds without making the learning curve too steep; an entry barrier that allows you to get things working with a modest effort, but with the possibility to grow and scale up without having to learn something new from scratch and undergo significant code migrations.

Thank you also for addressing my last question, and giving a link to an example with your answer.

Let me know if you want a link for something specific. The above comments are pretty broad and cover a lot of linkable stuff ;-)

Adolfo.

To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-robot-co...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.