[Rock-dev] Roby: Projects and Patterns

[Chris Mueller]

I'm currently refacting some points in our bundles of the RIMRES project 
and evaluating for myself the
current source code and solutions of other projects using the Roby 
Planning systems.

I'm interested in which projects additionally use / used intensively the 
Planning system? Most of the time i'm alwas looking
into:

- imoby
- avalon
- rimres

In the past there were discussions in some of our roby meetings about 
the needs to find "good practise patterns" using
the orocos.rb / roby framework. I would like to motivate this point 
again especially for generating plans because based on
my experience i'm more often see common requirements with different 
solutions.

I think introducing conceptional good solutions would be much helpful 
for the usage of the framework (especially for newcomers)
I know each projects has also its individual, harsh requirements, most 
solutions are also developed under big time pressure due
to some milestones and generalizing in robotics is sometimes not very easy.

But i would like to give you a small example what currently attracts my 
attention in the current source base to fulfill my requirements.

(Problem) The robotic system has a complete compositions model for 
sensor processing and control loops. In the past most of my
work with roby depends on generating plans, in which different tasks 
needs to be executed in a specific set of sequences. Each task
is often associated with a specific composition structure which monitors 
and controls its port connections, orocos task states and
mission state information. i often aim an execution sequence based on a 
state machine where each state can represents the
execution of task and events are controlling the transitions for task 
switches / changes.

I think the three, mentioned projects have already coped with this 
framework-relevant requirement for their individual szenarios and
and found different solutions to map the flexible roby api to this 
logical concept (linear- and non-linear sequences).

(AVALON 2011) Uses intensively the Plan Scripting Interface to 
manipulate the related composition structure. Each task is modelled by a 
scripted planning
method that was associated with a RobyTask (for EventDefinitions) and 
state changes are directly controlled by Roby relations calls
(depends_on, influence_by, starts_after calls, etc.).

(AVALON 2012) For the last SAUC-E i've introduced a new abstraction 
where a state machine is modelled with a ruby DSL that setted up
the task relations for the user automatically. It's usage was very 
limited and its design probably violates some concepts behind the roby 
mechanism. But it
did its job and provided the advantage, a mission could be changed by 
members without a deep knowledge of the planning system.

(RIMRES) currently embeds its code directly into its compositions 
definition and uses the mechanism for "refine_running_state" to model
behaviour switches. Each task is directly encoded in a "poll_in_state" 
which bloats the compositions massively. State Machine transitions are
often triggered by external RobyTasks that emits the relevant events. 
(Thats also my current point i would like to refactor)

(IMOBY) I've read a little the Roby API about its common components and 
looked afterwars into some files for imoby. I think it maps at best
the description of the API where behaviours are encapsled in RobyTasks 
(which represents Activities of a Robot) and the sequencing is
controlled through the Planner Interface.

Sorry, if i mixed up intensively some terminology. I hope you can follow 
this example without knowing the source code and see my points.

I guess, for the future there will be also much more complex szenarios 
which would also prophibit from common patterns.
Especially, when more projects are aiming and coping with reactive- and 
behaviour-driven control architectures (*winks_to_Jan*) and try to map this
requirements to the Roby API.

Chris