ros-control 2.0?

[kphawkins]

Is there any talk of developing a fork of the main development branch where we can make serious infrastructure changes to handle the issues many of us have been running into? Below are features I'd personally like a new version of ros-control to handle:

• The composite hardware interfaces/multicontrollers problem: #153 #151 #138 #137 #75
• Joint mode native support: #128, #99, wiki
• Multiple update rates: #127

I believe most of these changes would require serious code modification to implement cleanly. Perhaps we can start something akin to an REP? If we started an experimental fork, I'd like to contribute. What are everyone's thoughts on the issue?

[adolfo-rt]

Hey!

Recall that ros_control has not yet reached 1.0, so it's still time to make changes that break existing interfaces. The items you raise in the original post are very relevant ones, which could be addressed with modest/reasonable API changes. My suggestion to move these things forward would be to keep on prototyping stuff in feature branches that are as atomic as possible, and upon review merge them in the jturtle-devel branch (which does not exist yet). The important thing here is to introduce (and announce) such changes when new ros releases occur, to prevent unexpectedly breaking other people's code.

Coming back to the individual features:

• The composite hardware interfaces/multicontrollers problem: #153 #151 #138 #137 #75

I would separate this into two orthogonal problems:

• Composing hardware interfaces It looks like this could be implemented with only API additions, which would be fantastic. I have some pending comments (but not code) on this front. I'll reflect them in #138.
• Controllers with multiple hardware interfaces. This one requires modifying the ROS and C++ APIs, and adding convenience classes for dealing with multi-interface controllers, and not having to build upon ControllerBase.

Related to composing hardware interfaces. It would also be interesting to allow not only adding, but also removing resources from a robot (e.g., a tool change). A softer version of removing resources would be disabling them, which could be realized though joint modes (below).

• Joint mode native support: #128, #99, wiki

I don't anticipate API changes here, but I'm not 100% sure, as I haven't looked into it in detail.

• Multiple update rates: #127

This one seems pretty much ready to merge, right?. It needs some commit squashing, and of course, tests.

[adolfo-rt]

On the 2.0 part of the title. I've started to wonder how the ROS 2.0 effort might benefit ros_control, or writing control code in general. There is actually potential for huge gains, but the landscape is still fuzzy. ROSCON'14 will be fertile ground to discuss these ideas.

In the ROS on DDS whitepaper, it is mentioned that:

"...a custom intraprocess communication system would need to be developed for ROS which would never serialize nor convert messages, but instead would pass pointers (to shared in process memory) between publishers and subscribers..."

"The point to take away here is that efficient intraprocess communication will be addressed regardless of the network/interprocess implementation of the middleware."

If this mechanism ends up being realtime-friendly, then writing control code would become (almost) as convenient as writing regular ROS code, and would enable the long-desired feature of writing perception and control pipelines.

Things to take into consideration to be realtime-friendly are the ability to pre-allocate message data, the primitives used to handle concurrency, and more generally the 'no system calls' rule. It would also be great if arbitrary data structures and not just ROS messages could be shared through the intra-process communication mechanism, to avoid the overhead of copying data between messages and structures that can be operated on.

[kphawkins]

I'm very excited about DDS coming to ROS, but I feel like discussing the addition of a perception/control pipeline might be something separate. Trying to work something like that into ros-control is something I'd be really interested in, but I'm worried that we might be reinventing the wheel. Both Rock and Orocos RTT were designed for this purpose, as far as I can tell. Honestly, I'm curious about what they might have to offer since I don't have any experience with them.

In doing a little research, I found this stack rtt_ros_integration. It seems to be fairly active and relatively well maintained and documented. @jbohren, perhaps you can comment on how ros-control and Orocos RTT can/should interact.

[adolfo-rt]

I don't think there is any intention to reinvent the wheel. I am somewhat familiar with Rock, and very familiar with Orocos (we use it a lot). There are still usecases I think are not supported well by it, nor by other alternatives that I'm aware of. Minimizing overlap between projects is important, but can rarely be zero. Analyzing these overlaps are a good opportunity to see how things can be done differently and better in the future.

I've been cautiously observing the landscape for the last months, looking at what's out there, and what could make it to the scene in some time. The ROS 2.0 discussion threads are part of that.

ros_control has some clear limitations, and if they end up being addressed, it would be interesting to do so by not growing ros_control itself, but by leveraging existing high-quality tools developed and maintained by a greater community. I like the idea of the ros_control core being small, and the larger chunk of it being made up of robots and control code: ready-to-use robot abstractions, simulation backends, controllers, etc.

[jbohren]

@kphawkins In doing a little research, I found this stack rtt_ros_integration. It seems to be fairly active and relatively well maintained and documented. @jbohren, perhaps you can comment on how ros-control and Orocos RTT can/should interact.

Check out the comparison of ros_control and Orocos that I just wrote up in another thread here: https://groups.google.com/forum/#!topic/ros-sig-robot-control/qUAnF6enTUo

Given those comments, I'm not sure there's a good way to combine ros_control as it stands with Orocos. It's possible that the overhead in connecting the two frameworks could be greater than the cost of just implementing a given control law from a ros_control controller in an Orocos component and then using something else to expose a similar controller-switching API like my ConMan Orocos controller manager.

The real question when talking about integrating Orocos (general purpose framework) and ros_control (controller constraints and resource models) is how do you combine the best of both without including the parts which overlap. For example, Orocos already has a very well-defined inter-component communication model, so a lot of the JointHandle-type interfaces used by ros_control would be superfluous. At the same time, in order to have the constraints which make ros_control-based controllers shareable, one would need to decide on a standard datatype for use for different semantically-meaningful information flowing between blocks. Something like the auto-connection of semantically-equivalent dataports could be a way in which ros_control-like ideas could be applied to Orocos.

I could keep going, but this is really suitable for a longer, more in-depth discussion.