<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<blockquote cite="mid:5182179D.1070905@dfki.de" type="cite">
<div class="moz-forward-container"> As you already know i'm
currently evaluating roby's remote interface in order to provide
all necessary data for Allan<br>
to implement the Robot GUI. I've found now some time to look
more deeply into the roby's sources and i would like to share<br>
you some informations (I have also some issues to discuss)<br>
<br>
We have currently the following use cases for the GUI:<br>
1) Get and visualize a complete list about all available
behaviours<br>
2) Get and visualize a complete list of running behaviours <br>
3) Support an Interaction-Interface to start and stop behaviours<br>
<br>
Issue (1): <br>
We need a mechanism to filter out the behaviour actions from the
rest, because currently all behaviours are pure Roby::Actions. <br>
</div>
</blockquote>
In my opinion, it should stay that way. Actions *are* the available
behaviours. Can you give me a different use-case ?<br>
<blockquote cite="mid:5182179D.1070905@dfki.de" type="cite">
<div class="moz-forward-container"> Use Case (2) is a little bit
more complicated and needs maybe some refactorings like Sylvain
has mentioned to me.<br>
An interesting entrypoint for this problem is surely the
following call:<br>
<br>
# remote_interface (Roby::RemoteInterface ..) <br>
tasks = remote_interface.find_tasks.running.to_a <br>
</div>
</blockquote>
Actually, the jobs system is the real entry point. Ideally, one
running action = one job. Which is not currently the case, but
definitely should be (i.e. the shell interface should NOT do its own
job tracking)<br>
<blockquote cite="mid:5182179D.1070905@dfki.de" type="cite">
<div class="moz-forward-container"> It would be great if we could
shortly clarify what kind of objects the roby plan is currently
handling and what are the concrete differences between each
others "intuitively". <br>
(I always know they are existing through the sources but never
asked in detail about them. Maybe this is also some interesting
viewpoint for roby's documentation. Though<br>
it's more relevant for roby's developers)<br>
<br>
The clarification would be helpful because find_tasks on the
remote side is implemented by a Roby::Query-class and <br>
that is e.g. interacting with several instances of these tasks
concepts. <br>
<br>
Currently known:<br>
* Actions<br>
</div>
</blockquote>
The overall available system behaviours, i.e. high-level actions it
can perform. They are not directly represented in the Roby plan.
When triggered (through the shell interface for instance), the shell
interface creates a planning pattern (
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a
href="http://rock-robotics.org/master/api/tools/roby/building/runtime.html">http://rock-robotics.org/master/api/tools/roby/building/runtime.html</a>)
where the planning task is an instance of Roby::Actions::Task. You
can therefore get the list of all running behaviours with<br>
<br>
plan.find_tasks.running.<br>
with_child(Roby::Actions::Task, Roby::TaskStructure::PlannedBy)<br>
<br>
And the list of behaviours that might be started in the future with:<br>
<br>
plan.find_tasks.pending.<br>
with_child(Roby::Actions::Task, Roby::TaskStructure::PlannedBy)<br>
<br>
<blockquote cite="mid:5182179D.1070905@dfki.de" type="cite">
<div class="moz-forward-container"> * Missions<br>
</div>
</blockquote>
<blockquote cite="mid:5182179D.1070905@dfki.de" type="cite">
<div class="moz-forward-container"> * Permanent tasks<br>
</div>
</blockquote>
<a
href="http://rock-robotics.org/master/api/tools/roby/concepts/garbage_collection.html">http://rock-robotics.org/master/api/tools/roby/concepts/garbage_collection.html</a><br>
<br>
<blockquote cite="mid:5182179D.1070905@dfki.de" type="cite">
<div class="moz-forward-container"> * Interruptible tasks</div>
</blockquote>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
Tasks whose stop event have a command (<a
href="http://rock-robotics.org/master/api/tools/roby/building/tasks.html">http://rock-robotics.org/master/api/tools/roby/building/tasks.html</a>),
meaning that Roby has a way to explicitly stop them.<br>
<br>
The 'interruptible' statement in a Roby::Task class makes the stop
command call failed! (the definition of the task must define a
command for failed). This is the common pattern (but not the only
one)<br>
<br>
The 'terminates' statement also defines the failed command as<br>
<br>
emit :stop<br>
<br>
<blockquote cite="mid:5182179D.1070905@dfki.de" type="cite">
<div class="moz-forward-container"> * Jobs (only accessible from
the shell, but it corresponds to the plan) <br>
</div>
</blockquote>
That's part of the refactoring I told you about. I'd like to have
jobs == set of running action-generated tasks.<br>
<blockquote cite="mid:5182179D.1070905@dfki.de" type="cite">
<div class="moz-forward-container"> * Defines<br>
</div>
</blockquote>
A pure syskit concept: a named component network. They get all
mapped to an action, this action making sure that the component
network get deployed.<br>
<a
href="http://rock-robotics.org/master/api/tools/roby/concepts/garbage_collection.html"></a>
<blockquote cite="mid:5182179D.1070905@dfki.de" type="cite">
<div class="moz-forward-container">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
For the GUI we only need to filter out the Actions from the Rest
(for visualization) and get the corresponding task (for remote
control). But i guess it could be <br>
also extended in a more generalized fashion for all task
concepts and provide a complete, clean "remote control
interface". Do you have any preferences <br>
how we going on in this case? <br>
</div>
</blockquote>
<br>
My preference is for a cleanup. It should not require so much work<br>
- create a CommandInterface class that is instanciated in the
running Roby controller and provides an API to access the high-level
information. It would never generate any strings, only return or
call callbacks with objects<br>
- create a CommandInterfaceServer / CommandInterfaceClient using
pure sockets and Roby/Ruby- marshalling to send data through (or
maybe even http or xmlrpc if you are interested to get in there ?).
The CommandInterfaceServer would be a proxy over a CommandInterface
object. As much as I like DRb for quick stuff, it has major issues.
One of them being that it requires the name resolution to "just
work", which is rarely the case with robots.<br>
<br>
What we need to discuss is the required API. I would suggest that
you propose one API (class layout with empty methods and yard
documentation) and we discuss from there<br>
<blockquote cite="mid:5182179D.1070905@dfki.de" type="cite">
<div class="moz-forward-container"> e.g.:<br>
- i could start to branch roby and try to refactor it on myself
(or we specify an interface that can be implemented by sylvain
later, if it takes too many changes<br>
in sources)<br>
</div>
</blockquote>
+1<br>
<blockquote cite="mid:5182179D.1070905@dfki.de" type="cite">
<div class="moz-forward-container">Issue (2): <br>
If remote_interface.find_tasks is the right interface, there
will be also an open issue about it's performance. The call
itself is currently very slowly for getting <br>
the complete list (currently don't know if the bottleneck is
depended on DRb Interface or maybe on roby engine itself). Some
optimization for the response <br>
time would be very grateful for all other implemtentations that
access this interface.<br>
</div>
</blockquote>
Since you would access the jobs, it would not necessarily be
required. But, in general, I agree with your analysis. I believe
that debugging the performance problem would be a lot easier once
the split between CommandInterface / CommandInterfaceServer is done.<br>
<blockquote cite="mid:5182179D.1070905@dfki.de" type="cite">
<div class="moz-forward-container"> For Virgo, We could also touch
the trigger scheduler (whose results could be maybe also
visualized in the GUI). It should have a complete overview <br>
about running behaviours, of course. (But this needs probably
some interfacing to the RemoteInterface).<br>
</div>
</blockquote>
There is a way to extend the current Interface object (that's how
the .orocos.reload_config command appears). I would keep that and
have behave extend it with information querying for the trigger
scheduler.<br>
<pre class="moz-signature" cols="72">--
Sylvain Joyeux (Dr.Ing.)
Senior Researcher
Space & Security Robotics
Underwater Robotics
!!! Achtung, neue Telefonnummer!!!
Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany
Phone: +49 (0)421 178-454136
Fax: +49 (0)421 218-454150
E-Mail: <a class="moz-txt-link-abbreviated" href="mailto:robotik@dfki.de">robotik@dfki.de</a>
Weitere Informationen: <a class="moz-txt-link-freetext" href="http://www.dfki.de/robotik">http://www.dfki.de/robotik</a>
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
----------------------------------------------------------------------- </pre>
</body>
</html>