<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type"/>
</head><body style="">
<div>
> I think introducing conceptional good solutions would be much helpful
<br/>> for the usage of the framework (especially for newcomers)
<br/>> I know each projects has also its individual, harsh requirements, most
<br/>> solutions are also developed under big time pressure due
<br/>> to some milestones and generalizing in robotics is sometimes not very easy.
</div>
<div>
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.
</div>
<div>
<br/>> (AVALON 2012) For the last SAUC-E i've introduced a new abstraction
<br/>> where a state machine is modelled with a ruby DSL that setted up
<br/>> the task relations for the user automatically. It's usage was very
<br/>> limited and its design probably violates some concepts behind the roby
<br/>> mechanism. But it
<br/>> did its job and provided the advantage, a mission could be changed by
<br/>> members without a deep knowledge of the planning system.
</div>
<div>
I am pretty sure that the DSL you have written is not as bad as you make it sound ;-).
</div>
<div>
 
</div>
<div>
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
</div>
<div>
 
</div>
<div>
  # Start the required subsystem and wait for it to be running.
</div>
<div>
  start(Cmp::Localization.use(...))
</div>
<div>
  # Start the required subsystem and wait for it to end
</div>
<div>
  run(Cmp::Localization.use(...))
</div>
<div>
 
</div>
<div>
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 ?
</div>
<div>
<br/>> (RIMRES) currently embeds its code directly into its compositions
<br/>> definition and uses the mechanism for "refine_running_state" to model
<br/>> behaviour switches. Each task is directly encoded in a "poll_in_state"
<br/>> which bloats the compositions massively. State Machine transitions are
<br/>> often triggered by external RobyTasks that emits the relevant events.
<br/>> (Thats also my current point i would like to refactor)
</div>
<div>
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.
</div>
<div>
<br/>> (IMOBY) I've read a little the Roby API about its common components and
<br/>> looked afterwars into some files for imoby. I think it maps at best
<br/>> the description of the API where behaviours are encapsled in RobyTasks
<br/>> (which represents Activities of a Robot) and the sequencing is
<br/>> controlled through the Planner Interface.
</div>
<div>
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.
</div>
<div>
<br/>> Sorry, if i mixed up intensively some terminology. I hope you can follow
<br/>> this example without knowing the source code and see my points.
<br/>>
<br/>> I guess, for the future there will be also much more complex szenarios
<br/>> which would also prophibit from common patterns.
<br/>> Especially, when more projects are aiming and coping with reactive- and
<br/>> behaviour-driven control architectures (*winks_to_Jan*) and try to map this
<br/>> requirements to the Roby API.
</div>
<div>
Thanks for this great email ! We should definitely start meeting again and discuss these things !
</div>
<div>
 
</div>
<div>
Sylvain
</div>
</body></html>