Skip to content

Latest commit

 

History

History
333 lines (251 loc) · 13.6 KB

README.md

File metadata and controls

333 lines (251 loc) · 13.6 KB
Raw

Bridge communication between ROS and Gazebo

This package provides a network bridge which enables the exchange of messages between ROS and Gazebo Transport.

The following message types can be bridged for topics:

ROS type Gazebo Transport Type
actuator_msgs/msg/Actuators gz.msgs.Actuators
builtin_interfaces/msg/Time gz.msgs.Time
geometry_msgs/msg/Point gz.msgs.Vector3d
geometry_msgs/msg/Pose gz.msgs.Pose
geometry_msgs/msg/PoseArray gz.msgs.Pose_V
geometry_msgs/msg/PoseStamped gz.msgs.Pose
geometry_msgs/msg/PoseWithCovariance gz.msgs.PoseWithCovariance
geometry_msgs/msg/PoseWithCovarianceStamped gz.msgs.PoseWithCovariance
geometry_msgs/msg/Quaternion gz.msgs.Quaternion
geometry_msgs/msg/Transform gz.msgs.Pose
geometry_msgs/msg/TransformStamped gz.msgs.Pose
geometry_msgs/msg/Twist gz.msgs.Twist
geometry_msgs/msg/TwistStamped gz.msgs.Twist
geometry_msgs/msg/TwistWithCovariance gz.msgs.TwistWithCovariance
geometry_msgs/msg/TwistWithCovarianceStamped gz.msgs.TwistWithCovariance
geometry_msgs/msg/Vector3 gz.msgs.Vector3d
geometry_msgs/msg/Wrench gz.msgs.Wrench
geometry_msgs/msg/WrenchStamped gz.msgs.Wrench
gps_msgs/msg/GPSFix gz.msgs.NavSat
nav_msgs/msg/Odometry gz.msgs.Odometry
nav_msgs/msg/Odometry gz.msgs.OdometryWithCovariance
rcl_interfaces/msg/ParameterValue gz.msgs.Any
ros_gz_interfaces/msg/Altimeter gz.msgs.Altimeter
ros_gz_interfaces/msg/Contact gz.msgs.Contact
ros_gz_interfaces/msg/Contacts gz.msgs.Contacts
ros_gz_interfaces/msg/Dataframe gz.msgs.Dataframe
ros_gz_interfaces/msg/Entity gz.msgs.Entity
ros_gz_interfaces/msg/Float32Array gz.msgs.Float_V
ros_gz_interfaces/msg/GuiCamera gz.msgs.GUICamera
ros_gz_interfaces/msg/JointWrench gz.msgs.JointWrench
ros_gz_interfaces/msg/Light gz.msgs.Light
ros_gz_interfaces/msg/ParamVec gz.msgs.Param
ros_gz_interfaces/msg/ParamVec gz.msgs.Param_V
ros_gz_interfaces/msg/SensorNoise gz.msgs.SensorNoise
ros_gz_interfaces/msg/StringVec gz.msgs.StringMsg_V
ros_gz_interfaces/msg/TrackVisual gz.msgs.TrackVisual
ros_gz_interfaces/msg/VideoRecord gz.msgs.VideoRecord
rosgraph_msgs/msg/Clock gz.msgs.Clock
sensor_msgs/msg/BatteryState gz.msgs.BatteryState
sensor_msgs/msg/CameraInfo gz.msgs.CameraInfo
sensor_msgs/msg/FluidPressure gz.msgs.FluidPressure
sensor_msgs/msg/Image gz.msgs.Image
sensor_msgs/msg/Imu gz.msgs.IMU
sensor_msgs/msg/JointState gz.msgs.Model
sensor_msgs/msg/Joy gz.msgs.Joy
sensor_msgs/msg/LaserScan gz.msgs.LaserScan
sensor_msgs/msg/MagneticField gz.msgs.Magnetometer
sensor_msgs/msg/NavSatFix gz.msgs.NavSat
sensor_msgs/msg/PointCloud2 gz.msgs.PointCloudPacked
std_msgs/msg/Bool gz.msgs.Boolean
std_msgs/msg/ColorRGBA gz.msgs.Color
std_msgs/msg/Empty gz.msgs.Empty
std_msgs/msg/Float32 gz.msgs.Float
std_msgs/msg/Float64 gz.msgs.Double
std_msgs/msg/Header gz.msgs.Header
std_msgs/msg/Int32 gz.msgs.Int32
std_msgs/msg/String gz.msgs.StringMsg
std_msgs/msg/UInt32 gz.msgs.UInt32
tf2_msgs/msg/TFMessage gz.msgs.Pose_V
trajectory_msgs/msg/JointTrajectory gz.msgs.JointTrajectory
vision_msgs/msg/Detection2D gz.msgs.AnnotatedAxisAligned2DBox
vision_msgs/msg/Detection2DArray gz.msgs.AnnotatedAxisAligned2DBox_V
vision_msgs/msg/Detection3D gz::msgs::AnnotatedOriented3DBox
vision_msgs/msg/Detection3DArray gz::msgs::AnnotatedOriented3DBox_V

And the following for services:

ROS type Gazebo request Gazebo response
ros_gz_interfaces/srv/ControlWorld gz.msgs.WorldControl gz.msgs.Boolean

Run ros2 run ros_gz_bridge parameter_bridge -h for instructions.

NOTE: If during startup, gazebo detects that there is another publisher on /clock, it will only create the fully qualified /world/<worldname>/clock topic. Gazebo would be the only /clock publisher, the sole source of clock information.

You should create an unidirectional /clock bridge:

ros2 run ros_gz_bridge parameter_bridge /clock@rosgraph_msgs/msg/Clock[gz.msgs.Clock

Example 1a: Gazebo Transport talker and ROS 2 listener

Start the parameter bridge which will watch the specified topics.

# Shell A:
. ~/bridge_ws/install/setup.bash
ros2 run ros_gz_bridge parameter_bridge /chatter@std_msgs/msg/String@gz.msgs.StringMsg

Now we start the ROS listener.

# Shell B:
. /opt/ros/rolling/setup.bash
ros2 topic echo /chatter

Now we start the Gazebo Transport talker.

# Shell C:
gz topic -t /chatter -m gz.msgs.StringMsg -p 'data:"Hello"'

Example 1b: ROS 2 talker and Gazebo Transport listener

Start the parameter bridge which will watch the specified topics.

# Shell A:
. ~/bridge_ws/install/setup.bash
ros2 run ros_gz_bridge parameter_bridge /chatter@std_msgs/msg/String@gz.msgs.StringMsg

Now we start the Gazebo Transport listener.

# Shell B:
gz topic -e -t /chatter

Now we start the ROS talker.

# Shell C:
. /opt/ros/rolling/setup.bash
ros2 topic pub /chatter std_msgs/msg/String "data: 'Hi'" --once

Example 2: Run the bridge and exchange images

In this example, we're going to generate Gazebo Transport images using Gazebo Sim, that will be converted into ROS images, and visualized with rqt_image_viewer.

First we start Gazebo Sim (don't forget to hit play, or Gazebo Sim won't generate any images).

# Shell A:
gz sim sensors_demo.sdf

Let's see the topic where camera images are published.

# Shell B:
gz topic -l | grep image
/rgbd_camera/depth_image
/rgbd_camera/image

Then we start the parameter bridge with the previous topic.

# Shell B:
. ~/bridge_ws/install/setup.bash
ros2 run ros_gz_bridge parameter_bridge /rgbd_camera/image@sensor_msgs/msg/Image@gz.msgs.Image

Now we start the ROS GUI:

# Shell C:
. /opt/ros/rolling/setup.bash
ros2 run rqt_image_view rqt_image_view /rgbd_camera/image

You should see the current images in rqt_image_view which are coming from Gazebo (published as Gazebo Msgs over Gazebo Transport).

The screenshot shows all the shell windows and their expected content (it was taken using ROS 2 Galactic and Gazebo Fortress):

Gazebo Transport images and ROS rqt

Example 3: Static bridge

In this example, we're going to run an executable that starts a bidirectional bridge for a specific topic and message type. We'll use the static_bridge executable that is installed with the bridge.

The example's code can be found under ros_gz_bridge/src/static_bridge.cpp. In the code, it's possible to see how the bridge is hardcoded to bridge string messages published on the /chatter topic.

Let's give it a try, starting with Gazebo -> ROS 2.

On terminal A, start the bridge:

ros2 run ros_gz_bridge static_bridge

On terminal B, we start a ROS 2 listener:

ros2 topic echo /chatter std_msgs/msg/String

And terminal C, publish an Gazebo message:

gz topic -t /chatter -m gz.msgs.StringMsg -p 'data:"Hello"'

At this point, you should see the ROS 2 listener echoing the message.

Now let's try the other way around, ROS 2 -> Gazebo.

On terminal D, start an Gazebo listener:

gz topic -e -t /chatter

And on terminal E, publish a ROS 2 message:

ros2 topic pub /chatter std_msgs/msg/String 'data: "Hello"' -1

You should see the Gazebo listener echoing the message.

Example 4: Service bridge

It's possible to make ROS service requests into Gazebo. Let's try unpausing the simulation.

On terminal A, start the service bridge:

ros2 run ros_gz_bridge parameter_bridge /world/shapes/control@ros_gz_interfaces/srv/ControlWorld

On terminal B, start Gazebo, it will be paused by default:

gz sim shapes.sdf

On terminal C, make a ROS request to unpause simulation:

ros2 service call /world/<world_name>/control ros_gz_interfaces/srv/ControlWorld "{world_control: {pause: false}}"

Example 5: Configuring the Bridge via YAML

When configuring many topics, it is easier to use a file-based configuration in a markup language. In this case, the ros_gz bridge supports using a YAML file to configure the various parameters.

The configuration file must be a YAML array of maps. An example configuration for 5 bridges is below, showing the various ways that a bridge may be specified:

 # Set just topic name, applies to both
- topic_name: "chatter"
  ros_type_name: "std_msgs/msg/String"
  gz_type_name: "gz.msgs.StringMsg"

# Set just ROS topic name, applies to both
- ros_topic_name: "chatter_ros"
  ros_type_name: "std_msgs/msg/String"
  gz_type_name: "gz.msgs.StringMsg"

# Set just GZ topic name, applies to both
- gz_topic_name: "chatter_gz"
  ros_type_name: "std_msgs/msg/String"
  gz_type_name: "gz.msgs.StringMsg"

# Set each topic name explicitly
- ros_topic_name: "chatter_both_ros"
  gz_topic_name: "chatter_both_gz"
  ros_type_name: "std_msgs/msg/String"
  gz_type_name: "gz.msgs.StringMsg"

# Full set of configurations
- ros_topic_name: "ros_chatter"
  gz_topic_name: "gz_chatter"
  ros_type_name: "std_msgs/msg/String"
  gz_type_name: "gz.msgs.StringMsg"
  subscriber_queue: 5       # Default 10
  publisher_queue: 6        # Default 10
  lazy: true                # Default "false"
  direction: BIDIRECTIONAL  # Default "BIDIRECTIONAL" - Bridge both directions
                            # "GZ_TO_ROS" - Bridge Gz topic to ROS
                            # "ROS_TO_GZ" - Bridge ROS topic to Gz

To run the bridge node with the above configuration:

ros2 run ros_gz_bridge parameter_bridge --ros-args -p config_file:=$WORKSPACE/ros_gz/ros_gz_bridge/test/config/full.yaml

Example 6: Using ROS namespace with the Bridge

When spawning multiple robots inside the same ROS environment, it is convenient to use namespaces to avoid overlapping topic names. There are three main types of namespaces: relative, global (/) and private (~/). For more information, refer to ROS documentation. Namespaces are applied to Gazebo topic both when specified as topic_name as well as gz_topic_name.

By default, the Bridge will not apply ROS namespace on the Gazebo topics. To enable this feature, use parameter expand_gz_topic_names. Let's test our topic with namespace:

# Shell A:
. ~/bridge_ws/install/setup.bash
ros2 run ros_gz_bridge parameter_bridge chatter@std_msgs/msg/String@ignition.msgs.StringMsg \
  --ros-args -p expand_gz_topic_names:=true -r __ns:=/demo

Now we start the Gazebo Transport listener.

# Shell B:
gz topic -e -t /demo/chatter

Now we start the ROS talker.

# Shell C:
. /opt/ros/rolling/setup.bash
ros2 topic pub /demo/chatter std_msgs/msg/String "data: 'Hi from inside of a namespace'" --once

By changing chatter to /chatter or ~/chatter you can obtain different results.

API

ROS 2 Parameters:

  • subscription_heartbeat - Period at which the node checks for new subscribers for lazy bridges.
  • config_file - YAML file to be loaded as the bridge configuration
  • expand_gz_topic_names - Enable or disable ROS namespace applied on GZ topics.