the Robot Construction Kit
This page describes the principles behind the overall development workflow. It gives some details about the network generation algorithm in the process, as these details will help understanding each steps of the workflow
The very first step is to model the components and how the components should be connected together.
TODO: model browsing screencast
Component models, in Rock, are always done by the component developers when they use oroGen. The toolchain is designed so that using oroGen is the only constraint that needs to be followed to be able to use rock-roby.
Defining how components can be bound together is done by the system designer in rock-roby. It is done by creating so-called compositions, which are a collection of components and connections between these components, necessary to provide a given function. In order to make these compositions reusable, the modelling allows you to define abstract component models (or so-called data services). For instance, one would add a Pose service in a composition instead of referring to a specific component that would provide a pose.
Existing models can be browsed graphically using
System Model Example showing the dataflow in the OrientationEstimator Composition from the AVALON AUV student project.
The second step is to use these composition models to create high-level functions. Two things are at work there:
TODO: composer video
Finally, you (the user) requires that a set of these subsystems run at a given point in time. The underlying network generation algorithm will then take care of removing redundancies, i.e. merging components that are part of the same subsystem together, and finally adapting the currently running network to match the new requirements.
At this stage, a lot of constraint checking is done to ensure that the final network is sound.
TODO: merging video TODO: runtime adaptation video (avalon ?)
The subsystem design and runtime deployment steps are fully dynamic. In general, the workflow is to design subsystems statically and then switch between different system configurations (i.e. choice of subsystems) at runtime. However, it is also possible to create new subsystem definitions at runtime through e.g. learning mechanisms.