ROS 2 integration

ROS 2 integration

This page contains historical reference for the migration from ROS 1 to ROS 2 and may not be up to date.

For updated documentation, check Gazebo Tutorials.

📋 Overview

This document contains the current design of the integration between Gazebo and ROS 2.

• The targeted Gazebo version is Gazebo 9
• Supported ROS 2 versions:
  • Crystal in the crystal branch
  • Dashing in the dashing branch
  • The ros2 branch holds the code for the ROS 2 version under development.
• This is currently under development and this document is being updated over time. Comments are welcome on issue #512.

Highlights

• gazebo_ros_api_plugin is being broken into smaller, optional plugins.
• Gazebo-ROS plugins can be loaded at runtime even if Gazebo wasn't launched with a specific SystemPlugin.
• Common SDF parameters across plugins to set things like namespace and remapping rules.
• See more on this tutorial.

📂 gazebo_dev

Description: Provides a cmake config for the default version of Gazebo for the ROS distribution.

Status: ✔️ Done PR #770

Migration notes

N/A

📂 gazebo_msgs

Description: Message and service data structures for interacting with Gazebo from ROS.

Status: ✔️ Done PR #769

Migration notes

• All messages from ROS 1 have been kept the same so they can be used with the ros1_bridge.
• As plugins are migrated, new messages may be created to support new use cases. For example, the SpawnModel service is deprecated and the new SpawnEntity service should be used instead.

📂 gazebo_plugins

Description: Robot-independent Gazebo plugins for sensors, motors and dynamic reconfigurable components.

Status: ✔️ Done

Migration notes

• ✔️ PR #771 Plugins in gazebo_plugins typically had one or more NodeHandle instances to interact with ROS. In ROS2, plugins will use gazebo_ros::Node instead (see gazebo_ros). This will allow each plugin to exist as its own Node in the ROS graph, with its own parameters, namespace, loggers, etc.

• ✔️ PR #781 In ROS1, plugins were inconsistent in their handling of namespaces, but generally used the <robotNamespace> tag. In ROS2, the gazebo_ros::Node implementation accepts an SDF element and can parse the <ros><namespace> tag. Try this demo for example.

• ✔️ PR #781 In ROS1, plugins often had SDF fields like <odomTopic> for setting the topic name of its output. In ROS2, this will be handled in the gazebo_ros::Node implementation using remapping rules (see gazebo_ros).

• ✔️ Plugin's usage of tf_prefix functionality will be removed, as it has been deprecated since Hydro.

• ✔️ Sensor plugins will remove <updateRate> tags, as this functionality is better handled by setting the update rate in the sensor SDF.

• ✔️ Sensor plugins will remove noise functionality (such as the <gaussianNoise> tag), as noise can already be added in the gazebo sensor SDF. ROS Messages which have covariance attributes will be filled with the noise set in Gazebo.

• ✔️ Plugins with very similar functionality will be merged into one, with configuration options to get the desired features:

  • ✔️ gazebo_ros_camera, gazebo_ros_triggered_camera, gazebo_ros_multicamera, gazebo_ros_triggered_multicamera, gazebo_ros_depth_camera and gazebo_ros_openni_kinect as gazebo_ros_camera
  • ✔️ PR #785 gazebo_ros_laser, gazebo_ros_block_laser, gazebo_ros_gpu_laser, gazebo_ros_range as gazebo_ros_ray_sensor (See migration page)
  • ✔️ PR #793 gazebo_ros_imu will be removed. Users should instead use gazebo_ros_imu_sensor which uses gazebo's imu sensor instead of simulating an imu within the plugin. (See migration page)

• ✔️ Some of gazebo_plugins/gazebo_ros_utils's API will be deprecated in favor of native SDF or Gazebo calls, and other functions will be migrated to gazebo_ros/utils. (See migration page)

📂 gazebo_ros

Description: Provides ROS plugins that offer message and service publishers for interfacing with Gazebo through ROS.

Status: ✔️ Done

Migration notes

• ✔️ PR #771 There is a new class in ROS2, gazebo_ros::Node which is a child of rclcpp::Node. Plugins will use this instead of directly using rclcpp::Node.

• ✔️ PR #771 gazebo_ros::Node has a static rclcpp::Executor shared among all instances to handle spinning. This executor will be started when the first gazebo_ros::Node is created and destroyed when the last gazebo_ros::Node is destroyed.

• ✔️ PR #781 gazebo_ros::Node can optionally be constructed with an SDF element which can set the node's namespace, remapping rules, and initial arguments. This will allow plugins to share a standard mechanism for these operations and avoid inconsistencies/duplicate code. The SDF follows this format:

   <!-- Optional configurations for a plugin's Node -->
   <ros>
  
     <!-- Namespace of the node -->
     <namespace></namespace>
  
     <!-- Command line arguments sent to Node's contructor for remappings -->
     <argument>my_topic:=new_topic</argument>
     <argument>__name:=super_cool_node</argument>
  
     <!-- Initial ROS params set for node -->
     <parameter name="max_velocity" type="double">55.9</parameter>
     <parameter name="publish_odom" type="bool">True</parameter>
  
   </ros>
  

• ✔️ PR #776 In the ROS1 version of gazebo_ros, the gazebo_ros_api plugin handled ROS initialization and setting up threads to "spin" (process network traffic and call callbacks), requiring users to run the api plugin before loading any gazebo plugins which use ROS. In ROS2, there will be a new plugin gazebo_ros_init which will simply initialize ROS with the system arguments passed to gazebo. If this plugin is not loaded, ROS will be initialized with no arguments when the first gazebo_ros::Node is constructed.

• ✔️ The rest of the functionality provided by gazebo_ros_api on ROS 1 will be broken into smaller plugins on ROS 2. See issue 779 for a more detailed discussion.

• ✔️ On ROS 1, launch files made use of a few bash scripts to setup environment variables and load plugins before running Gazebo executables. On ROS 2, launch files are not XML-based anymore, but Python-based. This means we can embed the logic which was previously on these bash scripts into the launch files themselves.

• ✔️ PR #804 It is possible that having one ROS Node per plugin will add too much overhead. Applications that don't mind sharing a node across plugins can use the gazebo_ros::Node::Get() function to get a node that is shared among plugins.

📂 gazebo_ros_control

Description: Provides an interface between Gazebo and ROS control.

Status: 🚫 Blocked

Migration notes

Blocked by ros2_control, see its current status here.

📂 gazebo_ros_pkgs

Description: Metapackage which provides interfaces for using ROS with Gazebo.

Status: ✔️ Done PR #777

Migration notes

Basic migration using ament_package since special metapackage logic doesn't exist yet, see its status here.