<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
> Thanks for this great email ! We should definitely start
meeting again and discuss these things ! <br>
<br>
I would also recommend for new meetings.<br>
<br>
<br>
> As far as I remember discussing the RIMRES structure in one of
our roby meetings, <br>
> one issue with RIMRES is that high-level tasks often represent
multiple services / <br>
> multiple processes. This might also be a reason why it gets so
bloated.<br>
<br>
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<br>
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.<br>
I've currently never seen something similar to a RobyTask or a
defined planning method. (We always executed it via the roby shell).<br>
<pre wrap="">
> I am pretty sure that the DSL you have written is not as bad as you make it sound ;-).
</pre>
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 <br>
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<br>
an atomic planning entity/plan was almost represented by a planning
method. But before i go into the details here is the snippet:<br>
<br>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<a href="http://codepad.org/NyeO37AV">http://codepad.org/NyeO37AV</a>
(complete mission for the SAUC-E practise area)<br>
<br>
* 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)<br>
* DSL can only handle the standard events :success, :failed, etc. <br>
* Task Relation setup is completely hidden.<br>
* 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)<br>
* A little risky because the implementation was not so much tested.
(But it worked after several dry runs at the control station).<br>
<br>
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.<br>
<br>
* Keep taskcode in compositions as small as possible because it
provides a good view on the statical aspect of an atomic plan. <br>
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<br>
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<br>
its own controller, but only one active controller connections to
the actuator chain).<br>
* Manipulation of a component subnetwork are handled by Roby::Task /
Planning Methods (This represents the dynamical aspect of an atomic
plan)<br>
* 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).<br>
Simple Divide-And-Conquer.<br>
<br>
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)<br>
though they are sharing common capabilities and are probably mapped
later to the same Roby::Task abstraction on the execution level.
(extremely approximated). <br>
<pre wrap="">
> 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
<a class="moz-txt-link-freetext" href="http://rock-robotics.org/master/api/tools/roby/building_plans/tasks.html">> http://rock-robotics.org/master/api/tools/roby/building_plans/tasks.html</a>), 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 ?</pre>
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<br>
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<br>
didnt use it explicity much on AVALON.) However, i'll check this
feature.<br>
<br>
<br>
<br>
Honestly, if i'm in need to introduce the plan management to a
newcomer i would currently differs the following layers:<br>
<br>
* Layer 0: Orocos-Tasks (C++ Layer, ports, properties, operations)<br>
* Layer 1: Orocos.rb (Forming data-driven Orocos-component networks
via Ruby)<br>
* Layer 2: Roby seen as fault-tolerance plattform that forms the
runtime environment, handling orocos processes/deployments (Bridge
to Roby::Task, Events, Task Relations)<br>
(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.)<br>
* Layer 3: Static or Modelling View of the System (Compositions,
Devices, DataServices, Propertymanagement, Roby-deployments)<br>
* Layer 4: Dynamical View of the System (Plans,
Property-Overwritting, Composition-Manipulations)<br>
<br>
Just some "small" notes how i currently see the supervision layer.
If there are some misinterpretation, feel free to give a correction
:-]. <br>
<br>
Chris<br>
<br>
</body>
</html>