Basics in integrating a system from scratch using Gazebo and Syskit
Rock and Syskit provide a seamless integration with Gazebo. We will leverage this integration in this section to discover how to use existing components to build and control a minimal system. This should give you a hint about what Rock offers at runtime as well as the basics of package and component management.
This will cover building a simple system and simulating using Gazebo. It will only base itself on existing components (no new components will be developed).
This section will start by bootstrapping a Rock
installation. After the install, all examples that have to be run inside a
terminal assume that you have sourced this installation's
env.sh file in the
When applicable, we will breach advanced topics, or explanations about how things are implemented under-the-hood. These will be clearly indicated by a box like this:
Advanced This will hold the summary. Just click on "Advanced".
The details will be here.
Design and runtime Rock is a model-based architecture. A Rock system is described at design time, that is before any piece of the actual processing code needs to be run, and can verify properties regarding the final system then. Runtime then refers to the point where the actual data processing code runs – which involves hardware or simulation in case of robotics.
Libraries, Components and System Deep-down, the bulk of the code that makes a Rock system is organized in libraries. Libraries propose APIs - interfaces - to solve particular problems, e.g. OpenCV to process images, PCL to process point clouds, a GPS driver to control a GPS device and read GPS positions, … This way to organize software development is nothing specific to Rock or even robotics. It's the principal way software is developed period.
However, libraries offer functionality, but do not specify how this functionality should be integrated to offer a "runtime", i.e. how the actual data being processed can be passed to the processing code in the libraries, from the sensors to the actuators, to turn all that code into a robot.
To integrate these libraries at runtime, Rock uses a components paradigm. Components are black boxes that have inputs and produce outputs - exchanging data through streams. It's by meshing these components together - connecting outputs to inputs - that an active sensor-processing-actuator loop is created and that the robot can act and react in its environment. In addition to this dataflow interface (data inputs and outputs), Rock components also offer a configuration interface where parameters can be chosen and tested.
In Rock, these components are implemented in oroGen packages. They are described in an orogen file, which code-generates the skeleton of the components. oroGen packages also define the datatypes that can be transferred between the components.
What sets Rock apart from other component-based systems is the ability to reconfigure the component network to fit the situation as best as possible. This is made possible by explicitly choosing at any point in time both which components are active, and which output-input connections are present in the network. Syskit is the tool that makes such a design feasible, pushing most of the complexity of such a dynamic system into the tool, leaving the developer make higher-level design decisions.
Software Packages A software package is a way to distribute code (software). Rock's only convention is to have one library corresponding to one package or one component to one package. Libraries should be "fat", components "slim". That is, most of the functionality should be implemented as a component-independent library.
After this, we will learn how to use an arm interface component provided by the Gazebo interface as well as existing Rock components to implement cartesian and joint control networks for this arm.
Functionally, this will look like:
|What you will do||What concepts are covered|
|Creating an arm control network||Installing new packages, Compositions|
|Holding position in the cartesian space||Constant Generator, Profiles|
|Binding the component networks to the simulator||Devices|
|Running the networks||Deployment and runtime|