wiki:WikiStart/Toolchain/RobySharing

This page aims at describing a working workflow where one given Rock installation, with one given bundle (i.e. supervision package) is shared among multiple people.

An example is a project-wide account on a robot that is being used by all the people in the project.

The workflow aims at:

  • sharing a common set of models and configurations
  • having at all point in time a functional base system
  • while allowing the project members to have their "private" changes to the system

The basic idea is to have a base robot configuration that is being used by all project members. On top of that, one can define its "private" configuration which changes the component configurations and/or what components should run. The workflow should be used only when the shell "does not do the trick".

Technically, it works as follows:

  • use the robot name / robot type distinction from Roby
  • define a robot type with its own controller (controllers/robot_type.rb) and deployment (config/deployments/robot_type.rb). That would be the one loaded when scripts/run robot_type is used.
  • define member-specific deployment files (config/deployments/member_name.rb) and add member-specific configuration sections in each component's configuration (config/orogen/orogen_project::Task.yml). This specific configuration will be picked up when "scripts/run member_name robot_type" is used instead of "scripts/run robot_type"

Basic configuration

Let's assume that we are managing the bundle for [the asguardv3 robot](http://robotik.dfki-bremen.de/en/research/robotsystems/asguard-iii.html). The base two files will therefore be

scripts/controllers/asguardv3.rb
config/deployments/asguardv3.rb

in scripts/controllers/asguardv3.rb, we load the corresponding deployment with

if Roby.app.find_orocos_deployment(Roby.app.robot_name)
    Roby.app.apply_orocos_deployment Roby.app.robot_name
end

This shared configuration, which is also the one used for project-wide experiments, is started with

rock-roby run -rasguardv3 -c

One can also bypass the controller script and simply deploy using config/deployments/asguardv3.rb with

rock-roby run -rasguardv3 asguardv3

Member-specific changes

Each project member creates itself a file in config/deployments/ (e.g. config/deployments/sylvain.rb). This file can add new things to run, change defaults, ...

The system is now started with

rock-roby run -rsylvain:asguardv3 -c

Or, to start something without the controller file

rock-roby run -rasguardv3 sylvain

The new file should start by loading the common configuration. This is done with

Roby.app.load_orocos_deployment 'asguardv3'

For instance, if config/deployments/asguardv3.rb does a system-wide selection for the main system controller with

use Srv::Motion2DController => Skid4Control::SimpleController

this can be overriden in config/deployments/sylvain.rb

use Srv::Motion2DController => Control::PIVTorqueController

Specific component configurations can be chosen system-wide as well, e.g.

use Dynamixel::Task => Dynamixel::Task.use_conf('defaults', 'sweeping', 'sylvain')

The specific configuration is created by adding a new section at the end of config/orogen/dynamixel::Task.yml

--- name:sylvain
sweeping_speed: 1

Finally, one can add new "things to run" with

add_mission(Dynamixel::Task).use_conf('defaults', 'sweeping', 'sylvain')

and so on and so forth ...

As a summary of what the specific file would look like:

Roby.app.load_orocos_deployment 'asguardv3'
use Srv::Motion2DController => Control::PIVTorqueController
add_mission(Dynamixel::Task).use_conf('defaults', 'sweeping', 'sylvain')

Conclusion

Once such a scheme is set up properly, project members should NOT touch any of the "system-wide" files for the purpose of experimenting. Changing these files should be done ONLY if the changes are meant to be system-wide !

Last modified 6 years ago Last modified on 11/08/12 17:19:27