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:
communication:
- 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
coordination:
- 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@osrfoundation.org <mailto:gerkey@osrfoundation.org>> wrote:
>
> On Mon, Feb 17, 2014 at 9:06 AM, Wrede, Sebastian
> <swrede@techfak.uni-bielefeld.de
> <mailto:swrede@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
http://www.hs-ulm.de/schlegel
http://www.servicerobotik-ulm.de/
http://www.youtube.com/user/roboticsathsulm
http://www.zafh-servicerobotik.de/
http://smart-robotics.sourceforge.net/
http://www.joser.org/
_______________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users
(text/plain)