[Rock-dev] Fwd: Remote ActionInterface for Visualization

Sylvain Joyeux sylvain.joyeux at dfki.de
Thu May 2 09:58:18 CEST 2013 

> 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
>
> Issue (1):
> We need a mechanism to filter out the behaviour actions from the rest, 
> because currently all behaviours are pure Roby::Actions.
In my opinion, it should stay that way. Actions *are* the available 
behaviours. Can you give me a different use-case ?
> 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
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)
> 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
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 ( 
http://rock-robotics.org/master/api/tools/roby/building/runtime.html) 
where the planning task is an instance of Roby::Actions::Task. You can 
therefore get the list of all running behaviours with

   plan.find_tasks.running.
     with_child(Roby::Actions::Task, Roby::TaskStructure::PlannedBy)

And the list of behaviours that might be started in the future with:

   plan.find_tasks.pending.
     with_child(Roby::Actions::Task, Roby::TaskStructure::PlannedBy)

>  * Missions
>  * Permanent tasks
http://rock-robotics.org/master/api/tools/roby/concepts/garbage_collection.html

>  * Interruptible tasks
Tasks whose stop event have a command 
(http://rock-robotics.org/master/api/tools/roby/building/tasks.html), 
meaning that Roby has a way to explicitly stop them.

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)

The 'terminates' statement also defines the failed command as

   emit :stop

>   * Jobs (only accessible from the shell, but it corresponds to the plan)
That's part of the refactoring I told you about. I'd like to have jobs 
== set of running action-generated tasks.
>  * Defines
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.
<http://rock-robotics.org/master/api/tools/roby/concepts/garbage_collection.html> 

> 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?

My preference is for a cleanup. It should not require so much work
   - 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
   - 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.

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
> 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)
+1
> 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.
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.
> 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).
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.

-- 
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: robotik at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
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
-----------------------------------------------------------------------

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

More information about the Rock-dev mailing list