[Rock-dev] Roby: Projects and Patterns

[Sylvain Joyeux]

> 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.
The reason why there are varying solution is IMO also historical. There was
already a lot of code in the iMoby controller when the task scripting arrived,
which is why we did not use too much of it. In general, I am pretty confident
that the task scripting + state machines could cover almost all our current use
cases.

> (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.
I am pretty sure that the DSL you have written is not as bad as you make it
sound ;-).

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 ?

> (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)
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.

> (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.
In general, I feel that the code in iMoby is not as well structured as you make
it sound ;-) Especially in the iMoby exploration case where a lot of
coordination got encoded in task code.

> 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.
Thanks for this great email ! We should definitely start meeting again and
discuss these things !

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