[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