diff --git a/source/basics/composition.html.md b/source/basics/composition.html.md index 3f7a5f7..4c8ed11 100644 --- a/source/basics/composition.html.md +++ b/source/basics/composition.html.md @@ -26,10 +26,9 @@ style="opacity: 0.4;">in grey In Syskit, one has to _declare_ how components must be connected together to form a function, and then can request the system to actually run that function. - This page deals with the first step (design). The [next -page](constant_generator.html) will create the command generator, and we -will then [_deploy_ the network](deployment.html) and run it. +page](constant_generator.html) will create the command generator, and we will +then [_deploy_ the network](deployment.html) and run it. But let's not get too much ahead of ourselves. We will need to first install the control package that will implement the control. @@ -87,7 +86,9 @@ The "first match" line is always the package set where the package is defined. I -To install the package, add it in the `layout` section of `autoproj/manifest`: +In this tutorial, we will want to use the `control/orogen/cart_ctrl_wdls` which +uses the KDL library to do cartesian control of a robotic arm. To install the +package, add it in the `layout` section of `autoproj/manifest`: ~~~yaml layout: @@ -108,17 +109,17 @@ And finally build and install amake --all ~~~ -## Binding the components together {#composition} +## Using the installed components -Now that everything's installed, go back within the bundle folder. You may for -instance do `acd b/syskit` ([more about `acd`](day_to_day.html#acd)) +Now that everything's installed, go back within the bundle folder. You may not +use `acd` for this ([more about `acd`](day_to_day.html#acd)) yet, since the +bundle has not been registered in autoproj. -Compositions declare groups of components and connects them together. In -addition, we will see later on that they can be seen by the rest of the system as -components themselves, i.e. they can be used and connected in other -compositions. +Compositions declare groups of components and connects them together. Once +defined, compositions can be used in other compositions to build more complex +networks. -Let's create our `arm_cartesian_control_wdls` composition +Let's create our first building block, the `ArmCartesianControlWdls` composition ~~~ $ syskit gen cmp arm_cartesian_control_wdls @@ -128,37 +129,37 @@ $ syskit gen cmp arm_cartesian_control_wdls create test/compositions/test_arm_cartesian_control_wdls.rb ~~~ -
-
-OroGen packages in Syskit -
-
-As described in our [brief introduction](index.html), oroGen packages are -where the functionality implemented in the library packages are "packaged" into things -that can be used at runtime. To be used in Syskit, these oroGen components must be first imported using the -`using_task_library` statement. In our case, `cart_ctrl_wdls`, this is done with +As described in our [brief introduction](index.html), oroGen packages are where +the functionality implemented in the library packages are "packaged" into +things that can be used at runtime. To be used in Syskit, these oroGen +components must be first imported using the `using_task_library` statement. In +our case, `cart_ctrl_wdls`, this is done with ~~~ruby using_task_library "cart_ctrl_wdls" ~~~ This loads the oroGen project, and imports the components in it to make them -available in the Syskit models. The name of the imported models is mapped from -the oroGen naming scheme to the Syskit naming scheme by CamelCasing the project -name, e.g. `cart_ctrl_wdls` becomes `CartCtrlWdls` and the +available in the Syskit models. The task models from the oroGen project are +then made available within the Syskit app under the +`OroGen.project_name.ComponentName` scheme, e.g. the `cart_ctrl_wdls::ToPosConverter` component is accessible under -`OroGen::CartCtrlWdls::ToPosConverter` in Syskit. +`OroGen.cart_ctrl_wdls.ToPosConverter` in Syskit. -In case you're not sure about the naming, just add the `using_task_library` statement -at the toplevel of a file and load it with `syskit ide`. If we do so in our newly created `models/compositions/arm_cartesian_control_wdls.rb` and run +In case you're not sure about the naming, just add the `using_task_library` +statement at the toplevel of a file and load it with `syskit ide`. + +Let's do so in our newly created +`models/compositions/arm_cartesian_control_wdls.rb`. Then, run ~~~ -syskit ide models/compositions/arm_cartesian_control_wdls.rb +syskit ide -rgazebo models/compositions/arm_cartesian_control_wdls.rb ~~~ ![Name mapping between oroGen and Syskit](media/syskit_name_mapping.png){: .fullwidth} -
-
+ +**Note** Leave the IDE open, we will reuse it +{: .note} We now want to build the cartesian control network. What each component does in the `cart_ctrl_wdls` project can be found by reading the documentation displayed @@ -181,8 +182,8 @@ using_task_library 'cart_ctrl_wdls' module SyskitBasics module Compositions class ArmCartesianControlWdls < Syskit::Composition - add OroGen::CartCtrlWdls::WDLSSolver, as: 'twist2joint_velocity' - add OroGen::CartCtrlWdls::CartCtrl, as: 'position2twist' + add OroGen.cart_ctrl_wdls.WDLSSolver, as: 'twist2joint_velocity' + add OroGen.cart_ctrl_wdls.CartCtrl, as: 'position2twist' add CommonModels::Devices::Gazebo::Model, as: 'arm' end end @@ -191,12 +192,11 @@ end At this stage, we will have to connect the ports together. To see what inputs and outputs are available, one can have a look at the component's `.orogen` -files. The alternative is to open the `syskit ide -rgazebo` and inspect the composition -file as follows (`-rgazebo` is necessary because we are importing models from -`common_models`). **Leave the IDE open after this, we will reuse it** +files. The alternative is to use the IDE. Click the `Reload Models` button and +open the composition page:
- +
We may now start adding connections in the composition definition. The `as` @@ -210,8 +210,8 @@ command to the actual arm command input: ~~~ruby class ArmCartesianControlWdls < Syskit::Composition - add OroGen::CartCtrlWdls::WDLSSolver, as: 'twist2joint_velocity' - add OroGen::CartCtrlWdls::CartCtrl, as: 'position2twist' + add OroGen.cart_ctrl_wdls.WDLSSolver, as: 'twist2joint_velocity' + add OroGen.cart_ctrl_wdls.CartCtrl, as: 'position2twist' add CommonModels::Devices::Gazebo::Model, as: 'arm' position2twist_child.ctrl_out_port. @@ -221,7 +221,9 @@ class ArmCartesianControlWdls < Syskit::Composition end ~~~ -And hit the "Reload Models" button at the top of the IDE window +And hit the "Reload Models" button at the top of the IDE window. Syntax errors +(such as a misspelled port name) are shows at the bottom of the view. Just +click reload after you fixed them. Let's inspect the remaining unconnected input ports. There's `command`, `cartesian_status` and `joint_status` ports that obviously need to be connected @@ -234,9 +236,7 @@ arm_child.joints_status_port. However, the cartesian position feedback is not directly provided by the Gazebo model. Fortunately, the `control/orogen/robot_frames` project provides components -to do the joint-to-cartesian conversion. - -Add it now to the workspace [in the same way we added +to do the joint-to-cartesian conversion. Add it now to the workspace [in the same way we added `control/orogen/cart_ctrl_wdls`](#add_package), import it in the composition file with `using_task_library` and reload models within the IDE. Then, finally add it to the composition. @@ -251,10 +251,10 @@ using_task_library 'robot_frames' module SyskitBasics module Compositions class ArmCartesianControlWdls < Syskit::Composition - add OroGen::CartCtrlWdls::WDLSSolver, as: 'twist2joint_velocity' - add OroGen::CartCtrlWdls::CartCtrl, as: 'position2twist' + add OroGen.cart_ctrl_wdls.WDLSSolver, as: 'twist2joint_velocity' + add OroGen.cart_ctrl_wdls.CartCtrl, as: 'position2twist' add CommonModels::Devices::Gazebo::Model, as: 'arm' - add OroGen::RobotFrames::SingleChainPublisher, as: 'joint2pose' + add OroGen.robot_frames.SingleChainPublisher, as: 'joint2pose' position2twist_child.ctrl_out_port. connect_to twist2joint_velocity_child.desired_twist_port diff --git a/source/basics/constant_generator.html.md b/source/basics/constant_generator.html.md index d2450d8..7a9d575 100644 --- a/source/basics/constant_generator.html.md +++ b/source/basics/constant_generator.html.md @@ -9,10 +9,12 @@ sort_info: 30
**Where are we ?** We have created -`SyskitBasics::Compositions::ArmCartesianControlWdls`, which positions an arm -at a cartesian position. The cartesian position is provided outside the +[The `SyskitBasics::Compositions::ArmCartesianControlWdls` composition](composition.html), which positions an arm +at a given cartesian position. The cartesian position is provided outside the network. We will now create and integrate both the generator to provide this setpoint, as well as the generator to maintain a constant joint position. +The next pages will then bind the result to the simulation and finally deploy and run it. +We will also learn how to write unit tests. Below, the parts we will handle on this page are in blue. @@ -23,21 +25,11 @@ Below, the parts we will handle on this page are Types.base.commands.Joints.new( diff --git a/source/basics/day_to_day.html.md b/source/basics/day_to_day.html.md index 6a982d9..0aaea0c 100644 --- a/source/basics/day_to_day.html.md +++ b/source/basics/day_to_day.html.md @@ -58,8 +58,8 @@ shortened as long as the result is unambiguous. For instance, in the default Rock installation: ~~~ -$ acd s/gaz -# Now in simulation/gazebo +$ acd d/g +# Now in drivers/gps_base $ acd c/k multiple packages match 'c/k' in the current autoproj installation: control/kdl, control/kdl_parser $ acd c/kdl @@ -74,11 +74,11 @@ are named e.g. 'orogen' but are installed in `tools/`). `autoproj show path/to/directory` will allow you to find this out. {: .callout .callout-info} -The `-b` and `-p` options allow to move to a package's [build](#build_directory) and [prefix](#prefix_directory) directories. +The `-b` and `-p` options allow to move to a package's [build](#build_directory) and [prefix](#prefix_directory) directories. ~~~ -$ acd -b s/gaz -# Now in simulation/gazebo/build +$ acd -b d/gps +# Now in drivers/gps_base/build $ acd -p c/kdl # Now in install/ ~~~ @@ -105,6 +105,11 @@ Or, if your shell is already within a folder of said package, alog . ~~~ +**Note** that the logs are ordered by last modified date (the most recently +modified being first). The first entry is therefore most likely the one you're +looking for after an update or build failure. +{: .tip} + ### Updating Most of the time, you will want to update the whole workspace (the `-k` option @@ -122,13 +127,15 @@ name or path on the command line aup simulation/rock_gazebo ~~~ -To restrict the update to the package, excluding its dependencies, add `--deps=f`. - -`--checkout-only` will not update already checked out packages, but -only check out not currently present in the system. +To restrict the update to the package, excluding its dependencies, add `-n`. +`--checkout-only` will not update already checked out packages, but only check +out not currently present in the system. This is useful if you want to install +new packages, but not modify the already-installed ones. -`aup` without arguments is equivalent to `aup .`, i.e. update the package -located in the current directory +`aup` without arguments is equivalent to `aup .`: update the package +located in the current directory. If called outside of a package, it means +"update all packages under this directory". `aup` in the root of the workspace +is therefore equivalent to `aup --all`. {: .callout .callout-info} In some situations, or if you're trying to keep track of all the changes that @@ -155,16 +162,18 @@ name or path on the command line amake simulation/rock_gazebo ~~~ -To restrict the build to the package, excluding its dependencies, add `--deps=f`. +To restrict the build to the package, excluding its dependencies, add `-n`. -`amake` without arguments is equivalent to `amake .`, i.e. build the package -located in the current directory +`amake` without arguments is equivalent to `amake .`: update the package +located in the current directory. If called outside of a package, it means +"update all packages under this directory". `amake` in the root of the workspace +is therefore equivalent to `amake --all`. {: .callout .callout-info} ### Configuration -Build configurations may have some configuration options that the user needs to -answer on first time building. If you need to change the answers after the first +Build configurations may have some configuration options. These options are +asked during the first build. If you need to change the answers after the first run, execute ~~~ @@ -188,9 +197,10 @@ aup --no-deps amake ~~~ +`autoproj disable path/to/package` does the reverse. + Use `autoproj test list` to see which packages do have a test suite and for -which packages it is enabled. Running `autoproj test disable` disables all test -suites again. +which packages it is enabled. Running the tests can either be done using the package's test method, or through autoproj by running @@ -199,6 +209,9 @@ autoproj by running autoproj test . ~~~ +If you do want to enable all unit tests for all packages, run `enable` without +arguments. `disable` without arguments disables all test suites. + **Next**: let's get to [create our first system integration](getting_started.html) {: .next-page} diff --git a/source/basics/deployment.html.md b/source/basics/deployment.html.md index 6589af5..7aa69e9 100644 --- a/source/basics/deployment.html.md +++ b/source/basics/deployment.html.md @@ -35,9 +35,9 @@ can be found in the data logged at runtime. All oroGen components have a default deployment scheme of one component per process. The triggering mechanism does not have a default, but the `port_driven` scheme (where the component is triggered whenever data is -received on its inputs) is a very common scheme. If you look into the -`cart_ctrl_wdls` package, you would see that it's what the package's components -use. +received on its inputs) is commonly used. If you look into the +`cart_ctrl_wdls.orogen` file in `control/orogen/cart_ctrl_wdls`, you would see +that it is indeed what the package components uses. One usually starts with the defaults defined in the oroGen file. We therefore only have left to give a name to the components Syskit is using. This is done @@ -49,9 +49,9 @@ Robot.requires do Syskit.conf.use_gazebo_world('empty_world') require 'models/profiles/gazebo/arm_control' - Syskit.conf.use_deployment 'cart_ctrl_wdls::CartCtrl' => 'arm_pos2twist' - Syskit.conf.use_deployment 'cart_ctrl_wdls::WDLSSolver' => 'arm_twist2joint' - Syskit.conf.use_deployment 'robot_frames::SingleChainPublisher' => 'arm_chain_publisher' + Syskit.conf.use_deployment OroGen.cart_ctrl_wdls.CartCtrl => 'arm_pos2twist' + Syskit.conf.use_deployment OroGen.cart_ctrl_wdls.WDLSSolver => 'arm_twist2joint' + Syskit.conf.use_deployment OroGen.robot_frames.SingleChainPublisher => 'arm_chain_publisher' Syskit.conf.use_ruby_tasks SyskitBasics::Compositions::ArmCartesianConstantCommandGenerator => 'arm_constant_setpoint' Syskit.conf.use_ruby_tasks SyskitBasics::Compositions::JointPositionConstantGenerator => 'joint_position_setpoint' end @@ -82,9 +82,9 @@ Configuration of components in a Syskit system is split into two parts: The static configuration is stored within YAML files in `config/orogen/`. Each file is named after the component model that is configured, so for instance -`config/orogen/cart_ctrl_wdls::WDLSSolver` stores the configuration of all +`config/orogen/cart_ctrl_wdls::WDLSSolver.yml` stores the configuration of all components under that name. Each file can contain multiple configurations -within sections, but for now we'll only use the `default` configuration, +within sections, but for now we will only use the `default` configuration, which is the one that is loaded by default unless specified otherwise. Let's generate configuration file templates for the components we are using. The @@ -111,6 +111,21 @@ Let's look at them one by one, to see what needs to actually be configured. have a sane default is the `lambda` parameter. The documentation mentions 0.1 has a known-good parameter for some arm, let's pick that and keep in mind that it might be wrong. + + The root and tip in our case are the base and hand of the robot. So `root` should + be `ur10::base` and `tip` should be `ur10::wrist_3`. One can find this out by looking at + the SDF file. Alternatively, the chain can be + inspected using the `rock-transformer` tool: + + The parameters that have to be set should look like the following. Better + keep the rest, as it provides documentation about which parameters are + available. + + ~~~ yaml + root: 'ur10::base' + tip: 'ur10::wrist_3' + ~~~ + - `cart_ctrl_wdls::CartCtrl`. The one parameter that is probably best changed is the max output. The component's designer decided to pick `RigidBodyState` to represent a twist, which means that we only need to update the velocity @@ -118,17 +133,18 @@ Let's look at them one by one, to see what needs to actually be configured. (the `.deg` suffix will convert a degree value in radians). - `robot_frames::SingleChainPublisher` only has robot model that we will extract from the SDF model, and the tip/root parameters that have to be set - -**Note** in order to ensure consistency between the tip and root parameters of -`SingleChainPublisher` and `WDLSSolver`, another way to handle this is to make -them parameters of the compositions. + + ~~~ yaml + chain: + root_link: 'ur10::base' + tip_link: 'ur10::wrist_3' + ~~~ + +**Note** one might want at some point to use a task argument for the tip and +root parameters of `SingleChainPublisher` and `WDLSSolver`, to ensure +consistency between the components. {: .callout .callout-info} -The root and tip in our case are the base and hand of the robot. So `root` should -be `ur10::base` and `tip` should be `ur10::wrist_3`. One can find this out by looking at -the SDF file. Alternatively, the chain can be -inspected using the `rock-transformer` tool: -
@@ -198,9 +214,9 @@ class ArmCartesianControlWdls < Syskit::Composition # @return [Profile] argument :robot ... - add(OroGen::CartCtrlWdls::WDLSSolver, as: 'twist2joint_velocity'). + add(OroGen.cart_ctrl_wdls.WDLSSolver, as: 'twist2joint_velocity'). with_arguments(robot: from(:parent_task).robot) - add(OroGen::RobotFrames::SingleChainPublisher, as: 'joint2pose'). + add(OroGen.robot_frames.SingleChainPublisher, as: 'joint2pose'). with_arguments(robot: from(:parent_task).robot) end ~~~ @@ -215,7 +231,7 @@ define 'arm_cartesian_constant_control', with_arguments(robot: Base) ~~~ -We now need to modify the oroGen component models to use the robot argument. +We need to modify the oroGen component models to use the robot argument. Since oroGen components are auto-generated by Syskit, there's a special mechanism to allow modifying the generated classes after the fact. When Syskit loads an oroGen package, and after it has created the task classes, it will attempt to @@ -243,18 +259,18 @@ $ syskit gen orogen robot_frames create test/orogen/test_robot_frames.rb ~~~ -After hitting the IDE's reload button, we now get the path to the extension file: +After hitting the IDE's reload button, the IDE displays the path to the extension file: ![Message displayed by the IDE if there is an extension files](media/orogen_extension_file.png){: .fullwidth} -Now, let's edit `models/orogen/cart_ctrl_wdls.rb`. There is one `class` +Let's edit first `models/orogen/cart_ctrl_wdls.rb`. There is one `Syskit.extend_model` statement per task model in the project, but we're currently only interested in the `WDLSSolver` task. Let's add the `robot` argument, and tune the `configure` method that is described in the template to forward the model on to the task's properties. ~~~ruby -class OroGen::CartCtrlWdls::WDLSSolver +Syskit.extend_model OroGen.cart_ctrl_wdls.WDLSSolver argument :robot def configure super # call super as described in the template @@ -268,7 +284,7 @@ end and in `models/orogen/robot_frames.rb`: ~~~ruby -class OroGen::RobotFrames::SingleChainPublisher +Syskit.extend_model OroGen.robot_frames.SingleChainPublisher argument :robot def configure super # call super as described in the template @@ -282,7 +298,7 @@ end ## Building the system's action interface {#actions} A Syskit application exports functionality to the outside world as _actions_. -For now, the only thing we'll see about actions is that they have a name, +The only thing we will see about actions in this section is that they have a name, arguments and a lifetime. They either finish by themselves -- if they have a goal -- or run forever until they are "dropped" by the app's user. diff --git a/source/basics/devices.html.md b/source/basics/devices.html.md index 7992738..a751eb0 100644 --- a/source/basics/devices.html.md +++ b/source/basics/devices.html.md @@ -1,6 +1,6 @@ --- layout: documentation -title: Devices +title: Profiles and Devices sort_info: 40 --- @@ -48,11 +48,10 @@ simulated arm with the control network. ## Defining devices for the Gazebo system -The robot definition is done within a Syskit _profile_. Profiles are the models +A robot definition is created within a Syskit _profile_. Profiles are the models that bind network definitions (compositions) with devices and other -compositions. It's also where the robot definition happens. - -As a matter of convention, one usually creates a per-robot `Base` profile that +compositions. It's also where the robot definition happens. +By convention, one usually creates a per-robot `Base` profile that contains the robot definition. Let's do that now. ~~~ @@ -164,12 +163,12 @@ module SyskitBasics module Profiles module Gazebo UR10_SAFE_POSITION = Hash[ - 'shoulder_pan' => 0, - 'shoulder_lift' => -Math::PI/2, - 'elbow' => Math::PI/2, - 'wrist_1' => 0, - 'wrist_2' => 0, - 'wrist_3' => 0] + 'ur10::shoulder_pan' => 0, + 'ur10::shoulder_lift' => -Math::PI/2, + 'ur10::elbow' => Math::PI/2, + 'ur10::wrist_1' => 0, + 'ur10::wrist_2' => 0, + 'ur10::wrist_3' => 0] profile 'ArmControl' do define 'arm_cartesian_constant_control', @@ -197,7 +196,7 @@ models and roles that can be used in the `use` statement can easily be browsed using the IDE {: .callout .callout-info} -Let's have a look at the final `arm_cartesian_control` definition. +Let's have a look at the final `arm_cartesian_constant_control` definition. ![Final injected arm control network](media/injected_arm_control_network.svg){: .fullwidth} diff --git a/source/basics/getting_started.html.md b/source/basics/getting_started.html.md index 3d96fc0..2de5b31 100644 --- a/source/basics/getting_started.html.md +++ b/source/basics/getting_started.html.md @@ -116,14 +116,6 @@ In the bundles, scenes are saved in `scenes/SCENE_NAME/SCENE_NAME.world`, e.g. ~~~ -The `ur10` and `ground_plane` models we are referencing in this world file need -to be downloaded from Gazebo's model repository. This is done automatically by -`rock-gazebo` the first time they're needed, but can also be done explicitly with - -~~~ -rock-gazebo --download-only -~~~ - ## Running and visualizing a Gazebo environment Rock offers `vizkit3d`, its own 3D visualization environment. Since we will @@ -141,6 +133,17 @@ Starts both a Gazebo simulation and displays it: ![Visualization of the simulation state with rock-gazebo-viz](media/initial_rock_gazebo_viz.jpg){: .fullwidth} +
+The `ur10` and `ground_plane` models we are referencing in this world file need +to be downloaded from Gazebo's model repository. This is done automatically by +`rock-gazebo` the first time they're needed, but can also be done explicitly with +the `--download-only` option, e.g. + +~~~ +rock-gazebo --download-only empty_world +~~~ +
+ ## Preparing the `gazebo` Syskit configuration {#syskit_gazebo_configuration} Syskit configuration in bundles may be split into multiple configurations / diff --git a/source/basics/index.html.md.erb b/source/basics/index.html.md.erb index 21946d4..84fba59 100644 --- a/source/basics/index.html.md.erb +++ b/source/basics/index.html.md.erb @@ -6,7 +6,7 @@ directory_title: Basics directory_sort_info: 10 --- -# Running a simple system using Gazebo and Syskit +# 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 @@ -16,8 +16,8 @@ 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 assumes that you have a [bootstrapped Rock -installation](installation.html). All examples that have to be run inside a +This section will start by [bootstrapping a Rock +installation](installation.html). 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 current terminal. @@ -61,13 +61,15 @@ 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. -The paradigm that Rock follows is the one of **components**. Components are -black boxes that have inputs and produce outputs. It's by meshing these +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 +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. @@ -105,13 +107,13 @@ Functionally, this will look like: What you will do - What Syskit concepts are covered + What concepts are covered <%= link_to "Creating an arm control network", "composition.html" %> - Compositions + Installing new packages, Compositions <%= link_to "Holding position in the cartesian space", "constant_generator.html" %> @@ -128,5 +130,5 @@ Functionally, this will look like: -**Next**: [let's get started by installing Rock](installation.html) +**Next**: [let's get started by creating a new Rock workspace](installation.html) {: .next-page} diff --git a/source/basics/installation.html.md.erb b/source/basics/installation.html.md.erb index d8eea87..3ae7224 100644 --- a/source/basics/installation.html.md.erb +++ b/source/basics/installation.html.md.erb @@ -50,18 +50,20 @@ cause problems. Windows has seen some preliminary usage. ## Installation {#install} -Rock's current release is <%= config[:latest_release] %>, and requires **Ruby <%= config[:min_ruby_version] %> or later** +The code that is needed to follow this guide is not yet part of a core release. 1. [Install Gazebo 8](http://gazebosim.org). - 1. Install Ruby and verify that the version matches + 1. Install Ruby and verify that the version matches (must be 2.1 or later, we recommend 2.3.x) ~~~ sudo apt-get install ruby ruby --version ~~~ - 2. Create and "cd" into the directory in which you want to install the toolchain. + 2. Create and "cd" into the directory in which you want to work. This directory will + contain both the toolchain (that we will install in the next steps), as well as your + own code. This is called a _workspace_. ~~~ mkdir dev @@ -75,8 +77,8 @@ Rock's current release is <%= config[:latest_release] %>, and requires **Ruby <% ~~~ 4. Bootstrap your installation. This installs autoproj and checks out - the main build configuration, but does not check out packages. As - [previously mentioned](#not_mainline), one must use the master flavor + the main build configuration, but does not check out packages. Because + [this guide relies on code not yet in rock-core itself](#not_mainline), one must use the master flavor of Rock to go through this documentation. Select the defaults for all the proposed configuration options. @@ -96,8 +98,8 @@ Rock's current release is <%= config[:latest_release] %>, and requires **Ruby <% You **must** remember to source the generated env.sh script at the end of the -update !!! You must also do in new terminals before you can interact with the -Rock installation +amake command !!! You must also do in new terminals before you can interact with +the Rock installation {: .callout .callout-warning} **Next**: an overview of [how to interact day-to-day with the Rock diff --git a/source/basics/media/syskit_name_mapping.png b/source/basics/media/syskit_name_mapping.png index df1e1d9..fb2a9eb 100644 Binary files a/source/basics/media/syskit_name_mapping.png and b/source/basics/media/syskit_name_mapping.png differ diff --git a/source/basics/media/type_to_typekit.png b/source/basics/media/type_to_typekit.png new file mode 100644 index 0000000..ff5360e Binary files /dev/null and b/source/basics/media/type_to_typekit.png differ diff --git a/source/basics/media/ur10_dev.svg b/source/basics/media/ur10_dev.svg index 108386d..5b0f15d 100644 --- a/source/basics/media/ur10_dev.svg +++ b/source/basics/media/ur10_dev.svg @@ -4,78 +4,87 @@ - - + + %3 - -cluster_object_20072320 - - + +cluster_object_32332400 + + - -labelobject_20072320 - -OroGen::RockGazebo::ModelTask -Arguments -conf_ ["default"] -model_dev_ device(CommonModels__Devices__Gazebo__Model, as_ ur10_fixed) -orocos_name_ (unset) -ur10_dev_ device(CommonModels__Devices__Gazebo__Model, as_ ur10) -Roles - + +labelobject_32332400 + +OroGen.rock_gazebo.ModelTask +Arguments +conf: ["default"] +model_dev: device(CommonModels::Devices::Gazebo::RootModel, as: ur10_fixed) +orocos_name: (unset) +ur10_dev: device(CommonModels::Devices::Gazebo::Model, as: ur10) +Roles + - -outputsobject_20072320 - - -state + +outputsobject_32332400 + + +state +Type +/int32_t/int32_t/int32_t - - -pose_samples + + +pose_samples +Type +/base/samples/RigidBodyState - - -joints_samples + + +joints_samples +Type +/base/samples/Joints - - -ur10_pose_samples - - - - -ur10_joints_samples + + +ur10_joints_samples +Type +/base/samples/Joints - - -inputsobject_20072320 - - -model_pose + + +inputsobject_32332400 + + +model_pose +Type +/base/samples/RigidBodyState - - -joints_cmd + + +joints_cmd +Type +/base/samples/Joints - - -ur10_joints_cmd + + +ur10_joints_cmd +Type +/base/samples/Joints - + diff --git a/source/basics/media/wdls_solver_page.png b/source/basics/media/wdls_solver_page.png index 0b9e2f6..76c4567 100644 Binary files a/source/basics/media/wdls_solver_page.png and b/source/basics/media/wdls_solver_page.png differ diff --git a/source/basics/validation.html.md b/source/basics/validation.html.md index 999d913..c7bec43 100644 --- a/source/basics/validation.html.md +++ b/source/basics/validation.html.md @@ -225,9 +225,9 @@ before do EOSDF @profile = flexmock(sdf_model: SDF::Model.from_xml_string(xml)) - syskit_stub_conf OroGen::CartCtrlWdls::WDLSSolver, 'default', + syskit_stub_conf OroGen.cart_ctrl_wdls.WDLSSolver, 'default', data: { 'root' => 'test::root_test', 'tip' => 'test::tip_test' } - syskit_stub_conf OroGen::RobotFrames::SingleChainPublisher, 'default', + syskit_stub_conf OroGen.robot_frames.SingleChainPublisher, 'default', data: { 'chain' => Hash['root_link' => 'test::root_test', 'tip_link' => 'test::tip_test'] } end ~~~ diff --git a/source/index.html.md b/source/index.html.md index 06f6d83..f61c797 100644 --- a/source/index.html.md +++ b/source/index.html.md @@ -49,8 +49,8 @@ need to know at a certain point in time. ## Basics -1. [Basics: Installing Rock and Building a simple system using Gazebo and Syskit](basics/index.html) -2. [Runtime Basics: Running the basic system](runtime_overview/index.html) +1. [Basics: Integrating a system from scratch using Gazebo and Syskit](basics/index.html) +2. [Runtime: Details of running a Syskit system](runtime_overview/index.html) ## Building Systems diff --git a/videos/basics/composition-browse-creation.mp4 b/videos/basics/composition-browse-creation.mp4 new file mode 100644 index 0000000..e539fe2 --- /dev/null +++ b/videos/basics/composition-browse-creation.mp4 @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:075a8d2f976df63caa00dd8585215089b32a5bfde1919373352f58847f1ed826 +size 959609