• use the tools/orocos.rb/lib/orocos/roby > tools/syskit migration to do some cleanup
  • roles
    • roby/syskit developer
    • system designer (e.g. asguardv4 syskit system designer): uses syskit to create the composition / data services / definitions necessary to use the robotic system.
    • system user (e.g. asguardv4 user): only interested in the action interface, i.e. wants to start eslam_localization and simple_controller

Currently, our main focus is the system designer. The system user should have an easy way to use the action interface, and not have to touch the underlying models.

Fixing the bundles

The bundles are currently confusing as it is hard to know what we actually get from "imported bundles".

One solution would be to have a tool that tell you that.

A better solution would be to make these explicit:

  • the user must explicitly require the models/ files from the imported bundles (i.e. have to say require 'rock/models/blueprints/pose' to get the pose definitions)
    • issue What to do with files in models/orogen/ and in orogen/config/ ?
    • for models/orogen: "best practice" by making files in config/orogen/ only extend the task context models, and move the compositions, specializations and data services in models/blueprints. Since other bundles will have to load the blueprint files explicitly, they will be able to get loaded. We will need a mechanism "that works" for rock-roby "scripts"

(i.e. without a bundle) and the rock-roby GUIs.

Remove config/deployments

Spread the same information across config/ROBOT.rb and the action interface

  • define('name', Stuff) would move into the planning interface with
    syskit_component 'name', Stuff
  • the toplevel use flags would become "instantiation profiles", i.e. one would say
    Syskit.profile 'asguardv4' do
      use Srv::Pose => Asguard::PoseEstimator
    in the robot's config file and would then be able to either select them globally with Syskit.use_context('asguardv4') or locally as an argument to .use() and then select contexts at config time with TODO
  • add_mission would go away, but one still has the option of calling! to add a mission to the plan. The difference is that with!, Roby will remove the mission if it fails while with add_mission it would get redeployed the next time orocos.redeploy is called in e.g. the shell. Alternative: add a :respawn option to!

Keep/remove magic

  • REMOVE autoconnect
  • REMOVE configuration mapping a device name is automatically selected. I.e. with
    device Dev::FirewireCamera, :as => 'left_camera' 
    Syskit would automatically select 'default','left_camera' as configuration if it exists.
  • REMOVE orocos deployed task selected based on the device name. I.e. with the device above, if 'left_camera' is a known deployed task, it gets automatically picked. Alternative: select the deployment explicitly with use_deployment
  • REMOVE orocos deployed tasks are selected based on 'distance'. I.e. if multiple deployed tasks match, the one 'closest' to its neighbours is selected.


  • InstanceRequirements#use_deployment should be called InstanceRequirements#use_deployed_task
  • rename Planner into ActionInterface and Planner#method into ActionInterface#action. Remove method overloading, i.e. the ability to define the same action multiple times.

Model definitions

class MyTask < Roby::Task
data_service_type 'MyService' do
class PoseEstimationCmp < Syskit::Composition

{{{k module Asguard

data_service_type 'OdometrySrv'

end # service is defined as Asguard::OdometrySrv }}}

In the future the data_service_type call would be replaced by a consistent

module Asguard
   class OdometrySrv < Syskit::DataService

Best practices

  • use static configurations from config/orogen as much as possible. Do NOT override #configure unless there are really no other way. Document how to use to make this a bit "dynamic".
Last modified 7 years ago Last modified on 12/04/12 10:57:09