<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<small><big><tt>Dear all,</tt><tt><br>
</tt><tt><br>
</tt><tt>sorry for another email, hopefully not too lenghty...</tt><tt><br>
</tt><tt><br>
</tt><tt>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. </tt><tt><br>
</tt><tt><br>
</tt><tt>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.</tt></big><tt><br>
</tt></small><br>
<img src="cid:part1.09040708.07000906@hs-ulm.de" alt=""><br>
<br>
<tt>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.</tt><big><br>
</big><br>
<img src="cid:part2.07010500.01040908@hs-ulm.de" alt=""><br>
<br>
<big><tt><small>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:<br>
<br>
communication:<br>
- send just oneway<br>
- query request / response<br>
- push newest update all subscribed clients as soon as new
data is available at the server<br>
- push timed provide periodic updates to subscribed
clients<br>
<br>
coordination:<br>
- event inform as soon as a server side predicate
became true<br>
- wiring allow for dynamic rewiring of components
during runtime<br>
- state manage the life-cycle of a component
(activate, deactivate, shutdown, error, ...)<br>
- parameter parameterize a component from outside at
run-time<br>
- monitoring diagnostic port</small></tt></big><br>
<br>
<tt>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:<br>
<br>
</tt><img src="cid:part3.06090803.07010300@hs-ulm.de" alt=""><br>
<br>
<tt>Now what would be interesting? <br>
- discuss such communication patterns for robotics<br>
- define them (their semantics) independently of the underlying
middleware<br>
- although there is already work available here:<br>
- how to present QoS at the API of the patterns?<br>
- how to map QoS onto middleware if it provides QoS support?<br>
- ...<br>
<br>
<br>
</tt>
<div class="moz-cite-prefix">Am 18.02.2014 09:42, schrieb Ingo
Lütkebohle:<br>
</div>
<blockquote
cite="mid:CALNz_XEs9bQC3_+_VsDEYsaiuLA2NH7dLkP0GQHVkg1iR1qrrA@mail.gmail.com"
type="cite">
<div dir="ltr">On Tue, Feb 18, 2014 at 2:12 AM, Brian Gerkey <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:gerkey@osrfoundation.org" target="_blank">gerkey@osrfoundation.org</a>></span>
wrote:<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On Mon, Feb 17, 2014 at 9:06 AM, Wrede,
Sebastian<br>
<<a moz-do-not-send="true"
href="mailto:swrede@techfak.uni-bielefeld.de">swrede@techfak.uni-bielefeld.de</a>>
wrote:<br>
> * How will services / RPC be implemented with DDS?
Is there already an<br>
> accepted standard protocol for doing RPC over DDS?<br>
<br>
</div>
My understanding is: (i) the current DDS spec doesn't
include what we<br>
call services; (ii) there's an extension for services that
is<br>
currently under consideration and may make its way into a
future<br>
revision of the spec; and (iii) some current
implementations have<br>
vendor-specific extensions for services.<br>
</blockquote>
<div><br>
</div>
<div>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*.<br>
<br>
</div>
<div>Just saying ;-)<br>
</div>
<br>
</div>
cheers<br clear="all">
</div>
<div class="gmail_extra"><br>
-- <br>
<div dir="ltr">Ingo Lütkebohle, Dr.-Ing.<br>
Machine Learning and Robotics Lab, IPVS, Universität
Stuttgart<br>
<a moz-do-not-send="true"
href="http://www.ipvs.uni-stuttgart.de/abteilungen/mlr/abteilung/mitarbeiter/Ingo.Luetkebohle"
target="_blank">http://www.ipvs.uni-stuttgart.de/abteilungen/mlr/abteilung/mitarbeiter/Ingo.Luetkebohle</a><br>
+49-711-685-88350<br>
<br>
PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F 57D4 CD90 C164
34AD CE5B</div>
</div>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Prof. Dr. Christian Schlegel
Prodekan, Studiendekan Master IS
Fakultät Informatik
Hochschule Ulm
Tel.: 0731 / 50-28242
<a class="moz-txt-link-freetext" href="http://www.hs-ulm.de/schlegel">http://www.hs-ulm.de/schlegel</a>
<a class="moz-txt-link-freetext" href="http://www.servicerobotik-ulm.de/">http://www.servicerobotik-ulm.de/</a>
<a class="moz-txt-link-freetext" href="http://www.youtube.com/user/roboticsathsulm">http://www.youtube.com/user/roboticsathsulm</a>
<a class="moz-txt-link-freetext" href="http://www.zafh-servicerobotik.de/">http://www.zafh-servicerobotik.de/</a>
<a class="moz-txt-link-freetext" href="http://smart-robotics.sourceforge.net/">http://smart-robotics.sourceforge.net/</a>
<a class="moz-txt-link-freetext" href="http://www.joser.org/">http://www.joser.org/</a></pre>
</body>
</html>