ROS1 services & actionlib vs ros2 actions

[Thibault Kruse]

Hi,

I tried to get a better understanding of request/reply with DDS and actionlib. The ratified OMG standard specifies RFC over DDS based on pub/sub, with UIDs correlating the requestand the reply. (http://www.omg.org/spec/DDS-RPC/)

The design website is not clear on how this affects ROS2 and actions. This page defines an action hierarchy http://design.ros2.org/articles/ros_rpc.html, but it is not clear whether this page is up-to-date. If it is, it is not clear how this relates to actionlib.

This page makes suggestions but no decisions:
http://design.ros2.org/articles/ros_on_dds.html#services-and-actions

Is there a decision on this, or a currently favoured solution?

[William Woodall]

As far as I know we haven't tackled actions at all yet, and so there's no design doc or prototypes.

But the way I imagine it is as follows:

Services are asynchronous (with a synchronous API on top) and reliable. This means that you can make a request (async or sync) and you'll either get a response, or an error from the service server, or an error due to a timeout (no response from the service server). Additionally, you'll be able to associate requests and responses by comparison or with a unique identifier.

On top of this, Actions would provide a state machine on the server side allowing for preemption, as well as a way to do periodic feedback (pub/sub) between the original request and the final reply. There would be client and server side code to handle preemption requests and to generate feedback on the feedback topics.

The article "ros_rpc" that you linked was written when we were working the more abstract side of the research. It was actually written while we were prototyping with zeromq and protobuf and thinking about making our own rpc or using something like thrift. So it might be a little out of date or at least is limited to an abstract description of what we felt Services and Actions should be at the time. It's more memoranda at this point than our intention for the final design.

There was a time when we thought that having preempt-able services (basically Actions without feedback) would be desired, but I'm not sure it's an important distinction to have. Since the DDS RPC standard doesn't support preemption and most of other request-reply frameworks we looked at do not support it either, I'd say it would be best for us to implement that on top of services instead of incorporating it into services at the low level. That also keeps the rmw interface simpler.

--
You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ro...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

William Woodall

ROS Development Team

wil...@osrfoundation.org

http://wjwwood.io/

[Tully Foote]

Actions are on the roadmap here: https://github.com/ros2/ros2/wiki/Roadmap 

They're targeted for the round after the current development cycle. 

Tully

[Thibault Kruse]

On Monday, September 21, 2015 at 11:24:25 PM UTC+2, William Woodall wrote:

The article "ros_rpc" that you linked was written when we were working the more abstract side of the research. It was actually written while we were prototyping with zeromq and protobuf and thinking about making our own rpc or using something like thrift.

I thought so. A little warning at the top of that page might help put the contents in context today.

Since the DDS RPC standard doesn't support preemption and most of other request-reply frameworks we looked at do not support it either, I'd say it would be best for us to implement that on top of services instead of incorporating it into services at the low level. That also keeps the rmw interface simpler.

I guess an alternative would be to use actionlib in ROS2, but I also see how extending DDS RPC could be nicer in some ways (not necessarily helping interoperability). But that's a dicussion for later I guess, when work on actions starts.

[William Woodall]

On Tue, Sep 22, 2015 at 2:02 AM, Thibault Kruse <tibo...@googlemail.com> wrote:

On Monday, September 21, 2015 at 11:24:25 PM UTC+2, William Woodall wrote:

The article "ros_rpc" that you linked was written when we were working the more abstract side of the research. It was actually written while we were prototyping with zeromq and protobuf and thinking about making our own rpc or using something like thrift.

I thought so. A little warning at the top of that page might help put the contents in context today.

Sure, I think that would be best: https://github.com/ros2/design/pull/62

 

Since the DDS RPC standard doesn't support preemption and most of other request-reply frameworks we looked at do not support it either, I'd say it would be best for us to implement that on top of services instead of incorporating it into services at the low level. That also keeps the rmw interface simpler.

I guess an alternative would be to use actionlib in ROS2, but I also see how extending DDS RPC could be nicer in some ways (not necessarily helping interoperability). But that's a dicussion for later I guess, when work on actions starts.

We can discuss the different approaches when we start to migrate actions to ROS 2 (I hope to use the ROS 1 state machine if possible). If we think, at that point, that having preemption pushed lower in the stack we could get involved in the OMG standards process and propose it for a future version of the RPC spec.

--
You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ro...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.