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.
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
- Dashing in the
ros2branch holds the code for the ROS 2 version under development.
- Crystal in the
- This is currently under development and this document is being updated over time. Comments are welcome on issue #512.
gazebo_ros_api_pluginis being broken into smaller, optional plugins.
- Gazebo-ROS plugins can be loaded at runtime even if Gazebo wasn't launched with a specific
- Common SDF parameters across plugins to set things like namespace and remapping rules.
- See more on this tutorial.
Description: Provides a cmake config for the default version of Gazebo for the ROS distribution.
Status: Done PR #770
Description: Message and service data structures for interacting with Gazebo from ROS.
Status: Done PR #769
- 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.
Description: Robot-independent Gazebo plugins for sensors, motors and dynamic reconfigurable components.
PR #771 Plugins in
gazebo_pluginstypically had one or more
NodeHandleinstances to interact with ROS. In ROS2, plugins will use
gazebo_ros::Nodeinstead (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::Nodeimplementation 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::Nodeimplementation using remapping rules (see gazebo_ros).
Plugin's usage of
tf_prefixfunctionality 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_ray_sensor(See migration page)
gazebo_ros_imuwill be removed. Users should instead use
gazebo_ros_imu_sensorwhich uses gazebo's imu sensor instead of simulating an imu within the plugin. (See migration page)
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)
Description: Provides ROS plugins that offer message and service publishers for interfacing with Gazebo through ROS.
PR #771 There is a new class in ROS2,
gazebo_ros::Nodewhich is a child of
rclcpp::Node. Plugins will use this instead of directly using
gazebo_ros::Nodehas a static
rclcpp::Executorshared among all instances to handle spinning. This executor will be started when the first
gazebo_ros::Nodeis created and destroyed when the last
gazebo_ros::Nodecan 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_apiplugin 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_initwhich 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
The rest of the functionality provided by
gazebo_ros_apion 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.
Description: Provides an interface between Gazebo and ROS control.
ros2_control, see its current status here.
Description: Metapackage which provides interfaces for using ROS with Gazebo.
Status: Done PR #777
Basic migration using
ament_package since special metapackage logic doesn't exist yet, see its status here.