-
Notifications
You must be signed in to change notification settings - Fork 771
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
crystal
branch - Dashing in the
dashing
branch - The
ros2
branch 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_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.
Description: Provides a cmake config for the default version of Gazebo for the ROS distribution.
Status: ✔️ Done PR #770
N/A
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.
Status: ✔️ Done
-
✔️ PR #771 Plugins in
gazebo_plugins
typically had one or moreNodeHandle
instances to interact with ROS. In ROS2, plugins will usegazebo_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, thegazebo_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 thegazebo_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
andgazebo_ros_openni_kinect
asgazebo_ros_camera
- ✔️ PR #785
gazebo_ros_laser
,gazebo_ros_block_laser
,gazebo_ros_gpu_laser
,gazebo_ros_range
asgazebo_ros_ray_sensor
(See migration page) - ✔️ PR #793
gazebo_ros_imu
will be removed. Users should instead usegazebo_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 togazebo_ros/utils
. (See migration page)
Description: Provides ROS plugins that offer message and service publishers for interfacing with Gazebo through ROS.
Status: ✔️ Done
-
✔️ PR #771 There is a new class in ROS2,
gazebo_ros::Node
which is a child ofrclcpp::Node
. Plugins will use this instead of directly usingrclcpp::Node
. -
✔️ PR #771
gazebo_ros::Node
has a staticrclcpp::Executor
shared among all instances to handle spinning. This executor will be started when the firstgazebo_ros::Node
is created and destroyed when the lastgazebo_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
, thegazebo_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 plugingazebo_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 firstgazebo_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.
Description: Provides an interface between Gazebo and ROS control.
Status: 🚫 Blocked
Blocked by 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.