[ros-users] ros-users Digest, Vol 48, Issue 9

Christian Schlegel schlegel at hs-ulm.de
Tue Feb 18 21:45:31 UTC 2014

Dear all,

sorry for another email, hopefully not too lenghty...

in order to avoid confusion I refer to services as in the sense of 
service-oriented architectures (and not in sense of a ROS service). To 
make that more concrete, let me include the API of the SmartSoft 
communication patterns as you see it from inside a component as a 
component builder.

The first example is a "query". The client side exposes synchronous as 
well as asynchronous access methods and you do not have to care about 
multithreaded access, mixture of concurrent synchronous and asynchronous 
access etc.. The server side just forwards each incoming request to any 
processing by the handler upcall and you provide the return answer via 
the "answer" method.

The next example is a publish / subscribe pattern. A client subscribes 
to get newest updates and either check for them, wait for the next one 
etc. The server side just pushes in updates via the "put" method.

In general, we have a few more patterns in order to make live for 
robotics people as easy as possible but basically, you need a request / 
response and a publish / subscribe pattern. We provide:

- send           just oneway
- query          request / response
- push newest    update all subscribed clients as soon as new data is 
available at the server
- push timed     provide periodic updates to subscribed clients

- event          inform as soon as a server side predicate became true
- wiring         allow for dynamic rewiring of components during runtime
- state          manage the life-cycle of a component (activate, 
deactivate, shutdown, error, ...)
- parameter      parameterize a component from outside at run-time
- monitoring     diagnostic port

Inside these patterns, you run a protocol that is not visible to the 
robotics component builder. It is based on messages and these form the 
stable interface to the underlying middleware. You "just" have to map 
that protocol onto whatever middleware you are interested in. Just a 
snapshot of parts of the internal protocol:

Now what would be interesting?
- discuss such communication patterns for robotics
- define them (their semantics) independently of the underlying middleware
- although there is already work available here:
     - how to present QoS at the API of the patterns?
     - how to map QoS onto middleware if it provides QoS support?
     - ...

Am 18.02.2014 09:42, schrieb Ingo Lütkebohle:
> On Tue, Feb 18, 2014 at 2:12 AM, Brian Gerkey 
> <gerkey at osrfoundation.org <mailto:gerkey at osrfoundation.org>> wrote:
>     On Mon, Feb 17, 2014 at 9:06 AM, Wrede, Sebastian
>     <swrede at techfak.uni-bielefeld.de
>     <mailto:swrede at techfak.uni-bielefeld.de>> wrote:
>     >  * How will services / RPC be implemented with DDS? Is there
>     already an
>     > accepted standard protocol for doing RPC over DDS?
>     My understanding is: (i) the current DDS spec doesn't include what we
>     call services; (ii) there's an extension for services that is
>     currently under consideration and may make its way into a future
>     revision of the spec; and (iii) some current implementations have
>     vendor-specific extensions for services.
> I know that many people feel otherwise, but in my personal opinion, 
> services are a bad idea anyway, and what we really want is something 
> more like (though not necessarily exactly the same) what actionlib 
> offers. That is, something which *explicitly* acknowledges that there 
> are always packets/messages underneath, that there is asynchronicity, 
> and that there may be impossibility to act *in the protocol*.
> Just saying ;-)
> cheers
> -- 
> Ingo Lütkebohle, Dr.-Ing.
> Machine Learning and Robotics Lab, IPVS, Universität Stuttgart
> http://www.ipvs.uni-stuttgart.de/abteilungen/mlr/abteilung/mitarbeiter/Ingo.Luetkebohle
> +49-711-685-88350
> PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B

Prof. Dr. Christian Schlegel
Prodekan, Studiendekan Master IS
Fakultät Informatik
Hochschule Ulm

Tel.: 0731 / 50-28242


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20140218/dd7fac16/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jfbbbghb.png
Type: image/png
Size: 84377 bytes
Desc: not available
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20140218/dd7fac16/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fedifjcb.png
Type: image/png
Size: 61938 bytes
Desc: not available
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20140218/dd7fac16/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bgchfcfa.png
Type: image/png
Size: 271696 bytes
Desc: not available
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20140218/dd7fac16/attachment-0005.png>

More information about the ros-users mailing list