[Rock-dev] Fwd: Remote ActionInterface for Visualization

[Sylvain Joyeux]

-------- Original Message --------
Subject: 	Remote ActionInterface for Visualization
Date: 	Tue, 30 Apr 2013 20:16:24 +0200
From: 	Chris Mueller <christoph.mueller at dfki.de>
To: 	Allan E. Conquest <conquest at tzi.de>, Sylvain Joyeux 
<sylvain.joyeux at dfki.de>
CC: 	Felix Rehrmann <felix.rehrmann at dfki.de>



Hi all,

Sorry for not reporting to you within the last weeks. I was a little 
busy with some preparation of my thesis :-).

As you already know i'm currently evaluating roby's remote interface in 
order to provide all necessary data for Allan
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
you some informations (I have also some issues to discuss)

We have currently the following use cases for the GUI:
1) Get and visualize a complete list about all available behaviours
2) Get and visualize a complete list of running behaviours
3) Support an Interaction-Interface to start and stop behaviours

For Allan:
You can already completely implement Use Case (1). I've add a simple 
ruby script (with some helpful hints) which outputs
a list of all possible actions from the ActionInterface.
You can find it under the autoproj location: 
virgo/robots_viz/roby_remote_interface/roby_interface.rb
It should deliver all necessary information you need to fill your widgets.

Issue (1):
We need a mechanism to filter out the behaviour actions from the rest, 
because currently all behaviours are pure Roby::Actions.
I've done something similar for the RIMRES project, where we explicit 
marked exported actions:
http://spacegit.dfki.uni-bremen.de/rimres/bundle-rimres/blobs/master/models/planners/rimres_main.rb
But I would recommend to keep this more simple and would introduce some 
convention to prefix all actions in the action interface.
(We could then filtered out behaviours by its prefixed action name). 
This would be already sufficient in my opinion.

Use Case (2) is a little bit more complicated and needs maybe some 
refactorings like Sylvain has mentioned to me.
An interesting entrypoint for this problem is surely the following call:

# remote_interface (Roby::RemoteInterface ..)
tasks = remote_interface.find_tasks.running.to_a

With this i get a list of all running tasks (actions, missions, tasks, 
defines, for clarification i call them: task concepts) through DRb 
interface and i guess it can be also directly controlled due to the 
remote object mechanism (also known as RMI) to each listed unit.

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".
(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
it's more relevant for roby's developers)

The clarification would be helpful because find_tasks on the remote side 
is implemented by a Roby::Query-class and
that is e.g. interacting with several instances of these tasks concepts.

Currently known:
  * Actions
  * Missions
  * Jobs (only accessible from the shell, but it corresponds to the plan)
  * Defines
  * Permanent tasks
  * Interruptable tasks
  * ...

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
also extended in a more generalized fashion for all task concepts and 
provide a complete, clean "remote control interface". Do you have any 
preferences
how we going on in this case?

e.g.:
  - 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
in sources)
  - or we are first coping with Virgo requirements and let the sources 
unchanged as possible.

Issue (2):
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
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
time would be very grateful for all other implemtentations that access 
this interface.

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
about running behaviours, of course. (But this needs probably some 
interfacing to the RemoteInterface).


Chris









-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20130502/f92023ba/attachment.htm