[Rock-dev] Roby: Projects and Patterns

[Chris Müller]

 > Thanks for this great email ! We should definitely start meeting 
again and discuss these things !

I would also recommend for new meetings.


 > As far as I remember discussing the RIMRES structure in one of our 
roby meetings,
 > one issue with RIMRES is that high-level tasks often represent 
multiple services /
 > multiple processes. This might also be a reason why it gets so bloated.

Yes, i can see some similarities to the current source where i guess a 
big problem is the representation of a service which is currently 
implemented by defining
a composition, add its behaviour within directly, setup a define for it, 
and configure an add_mission in the config/deployment for automatic 
executation for the start process.
I've currently never seen something similar to a RobyTask or a defined 
planning method. (We always executed it via the roby shell).


> I am pretty sure that the DSL you have written is not as bad as you make it sound ;-).

After reviewing into the code and the current documentation i'm pretty 
sure i had a wrong, intuitional view onto some parts of the architecture 
within roby that
leads me into some traps using the API for my state machine approach. 
When i started i was strongly biased by the current code base we had 
after SAUCE-2011 where
an atomic planning entity/plan was almost represented by a planning 
method. But before i go into the details here is the snippet:

http://codepad.org/NyeO37AV (complete mission for the SAUC-E practise area)

* DSL has a very simple implementation based on the influence_by 
relation (in the past we often used depends_on. This had a too strong 
relation in my experiments with this)
* DSL can only handle the standard events :success, :failed, etc.
* Task Relation setup is completely hidden.
* Changing the flow of tasks is quite simple (Was very nice for adapting 
the practise area which differs in another location for the sauce 
stations (buoy, pipeline, wall), simple copy&paste and some fixes)
* A little risky because the implementation was not so much tested. (But 
it worked after several dry runs at the control station).

For the management of AVALON i developed for myself some fundamental 
principles in order to handle the complexity. This is of course my 
personal preference.

* Keep taskcode in compositions as small as possible because it provides 
a good view on the statical aspect of an atomic plan.
Its easier to test the composition itself, the relating structure is 
always clear and you have solid ground to develop a task method based on 
this. In practise
this means: avoid intensive usage of poll, script and other blocks 
(though they are sometimes helpful if some multiplexing compositions are 
necessary, e.g. multiple detectors with
its own controller, but only one active controller connections to the 
actuator chain).
* Manipulation of a component subnetwork are handled by Roby::Task / 
Planning Methods (This represents the dynamical aspect of an atomic plan)
* Complex plans are composed of atomic or subplans, synchronized in a 
linear- or non-linear sequence. (There was no need for parallel 
execution of plans in the past for me).
Simple Divide-And-Conquer.

Based on this aspect and argumentation i think it's obvious i'm 
currently mixing very deeply the abstract concepts on the modelling side 
of roby  (compositions, planning_methods, devices, orogen tasks)
though they are sharing common capabilities and are probably mapped 
later to the same Roby::Task abstraction on the execution level. 
(extremely approximated).


> Scripts "learned" more high-level capabilities just before I left for parental
> leave (which is why it did not get advertised). Namely, one can do
>
> # Start the required subsystem and wait for it to be running.
> start(Cmp::Localization.use(...))
> # Start the required subsystem and wait for it to end
>  run(Cmp::Localization.use(...))
>
> In conjunction with script_in_state (documented at the bottom of
> http://rock-robotics.org/master/api/tools/roby/building_plans/tasks.html), it
> already gives a pretty high-level view of a plan. How does what you did relate
> to that ? Actually, could you send a snippet of avalon code using your DSL ?

The script_in_state call is quite new for me. I guess, it was also, 
always possible to use the "script do ... end" block in a Roby::Task, 
which also offers its own event definitions, argument handling and maybe 
some
relations to necessary tasks (which can be our "static" compositions).  
Would be probably a much better spot for the DSL, i have used :-] (Have 
always seen the Roby::Task as a low-level concept, because we
didnt use it explicity much on AVALON.) However, i'll check this feature.



Honestly, if i'm in need to introduce the plan management to a newcomer 
i would currently differs the following layers:

* Layer 0: Orocos-Tasks (C++ Layer, ports, properties, operations)
* Layer 1: Orocos.rb (Forming data-driven Orocos-component networks via 
Ruby)
* Layer 2: Roby seen as fault-tolerance plattform that forms the runtime 
environment, handling orocos processes/deployments (Bridge to 
Roby::Task, Events, Task Relations)
(we had a nice discussion about that on SAUC-E, where in the beginning 
roby is probably misinterpreted as planning system associated to 
concepts like strips, etc.)
* Layer 3: Static or Modelling View of the System (Compositions, 
Devices, DataServices, Propertymanagement, Roby-deployments)
* Layer 4: Dynamical View of the System (Plans, Property-Overwritting, 
Composition-Manipulations)

Just some "small" notes how i currently see the supervision layer. If 
there are some misinterpretation, feel free to give a correction :-].

Chris

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