The general concept in Syskit, the rock system management layer, is to provide requirements on what should run, and let the management layer (1) generate the network that is needed to run it and (2) let it handle the runtime aspects (configuration / reconfiguration, starting, monitoring)

It would be a very good idea to follow the tutorials before you continue with this documentation.

Bundles

Bundles in Rock are used to gather all that form a consistent robot application together. Outside of Syskit, they gather configuration files (for task contexts and for outside tooling such as the transformer

When using Syskit, they also will contain all the Syskit-specific models and application information. Whenever you start a new Syskit-based application, create a new bundle and convert it to a Syskit/Roby application with:

rock-create-bundle desired/path/to/my/bundle
cd desired/path/to/my/bundle
roby init

Converting an existing bundle is simply done by running “roby init” in it.

Bundles can depend on each other, allowing to reuse models from one to the next. This is done by editing config/bundle.yml and adding a line in the bundle/dependencies section:

bundles:
   dependencies:
       - rock
       - rock_ugv_nav

All newly created bundles depend on the Rock bundle by default.

When adding a bundle dependency, don’t forget to add the corresponding package in the bundle’s manifest.xml file. Bundles are usually stored in the bundles/ folder, so a bundle called “X” maps to a package called “bundles/X”

Whenever it applies, the documentation will state where the bundle directory structure each parts of a Syskit application should be placed. Then, this is going to be summarized at the end of this guide.

Components

In Syskit, a component designates a black box that has inputs and outputs, and can report about its execution. In practice, it can be:

• a task context, i.e. an actual component that is defined in oroGen and implemented in C++
• a data service, which is an abstract placeholder for “concrete” components (compositions or task contexts).
• a composition, which represents a way to bind components together to form a new component

The first part of this documentation will guide you through defining these components.

• task contexts are automatically imported from oroGen descriptions. Because of the naming convertion rules, the Roby model that represents the oroGen task context xsens_imu::Task is called XsensImu::Task.
• compositions are defined as subclasses of Syskit::Composition.

class CompositionModelName < Syskit::Composition
 <definitions>
end

• data services are defined using the following code block. This block defines a ServiceModelName Ruby module in the current module that represents the service model.

data_service_type "ServiceModelName" do
 <definitions>
end

The second part will tell you all about building systems using these parts.

Browsing

All models defined in Syskit can be browsed using the syskit command. It gives all the information about the task contexts and types that are currently installed in your rock environment, as well as about compositions and components. Additionally, it shows where (file and line) a particular model is defined and shows syntax or modelling errors. When you are developping new models, simply press the “reload” button until you fixed all errors that showed up.

To run this tool, simply go into the bundle you are working on and run

syskit browse