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:
--
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/