http://gazebosim.org/tutorials?tut=ros_gzplugins
Gazebo supports several plugin types, and all of them can be connected to ROS, but only a few types can be referenced through a URDF file:
ModelPlugin
In short, the ModelPlugin
is inserted in the URDF inside the
element. It is wrapped with the
pill, to indicate information passed to Gazebo. For example:
... robot description ...
... plugin parameters ...
... robot description ...
Upon loading the robot model within Gazebo, the diffdrive_plugin
code will be given a reference to the model itself, allowing it to manipulate it. Also, it will be give a reference to the SDF element of itself, in order to read the plugin parameters passed to it.
SensorPlugin
Specifying sensor plugins is slightly different. Sensors in Gazebo are meant to be attached to links, so the
element describing that sensor must be given a reference to that link. For example:
... robot description ...
... link description ...
... sensor parameters ...
... plugin parameters ..
Upon loading the robot model within Gazebo, the camera_controller
code will be given a reference to the sensor, providing access to its API. Also, it will be give a reference to the SDF element of itself, in order to read the plugin parameters passed to it.
The following sections document all of the plugins available in the gazebo_plugins
. We suggest you review them in order because more detail is covered in the first couple of plugins and you can learn some of the concepts from the various plugins' documentation.
The names of each section is derived from the plugin class name. For example, "Block Laser" is from the GazeboRosBlockLaser
class and can be found in the file gazebo_plugins/src/gazebo_ros_block_laser.cpp
.
If there are some sections blank, it means that this author got tired of documenting every plugin and you should fill in the area with your experience should you have knowledge and examples of how to use the particular plugin.
Description: provides ROS interface for simulating cameras such as wge100_camera
by publishing the CameraInfo and Image ROS messages as described in sensor_msgs
.
In this section, we will review a simple RGB camera attached to the end of the RRBot pendulum arm. You can look inside rrbot.xacro
to follow the explanation. The first elements of this block are an extra link and joint added to the URDF file that represents the camera. We are just using a simple red box to represent the camera, though typically you could use a mesh file for a better representation.
A Xacro property is also defined:
You should be able to launch the RRBot and see a red box attached to the end of the arm.
Next we will review the Gazebo plugin that gives us the camera functionality and publishes the image to a ROS message. In the RRBot we have been following the convention of putting Gazebo elements in the rrbot.gazebo
file:
30.0
1.3962634
800
800
R8G8B8
0.02
300
gaussian
0.0
0.007
true
0.0
rrbot/camera1
image_raw
camera_info
camera_link
0.07
0.0
0.0
0.0
0.0
0.0
Let's discuss some of the properties of this plugin...
The link name "camera_link" must match the name of the link we added to the Xacro URDF.
The sensor name "camera1" must be unique from all other sensor names. The name is not used many places except for within Gazebo plugins you can access
30.0
Number of times per second a new camera image is taken within Gazebo. This is the maximum update rate the sensor will attempt during simulation but it could fall behind this target rate if the physics simulation runs faster than the sensor generation can keep up.
1.3962634
800
800
R8G8B8
0.02
300
Fill in these values to match the manufacturer's specs on your physical camera hardware. One thing to note is that the pixels are assumed to be square.
Additionally, the near and far clips are simulation-specific parameters that give an upper and lower bound to the distance in which the cameras can see objects in the simulation. This is specified in the camera's optometry frame.
This is where the actual gazebo_ros/gazebo_ros_camera.cpp
file is linked to, as a shared object.
rrbot/camera1
image_raw
camera_info
Here we define the rostopic the camera will be publishing to, for both the image topic and the camera info topic. For RRBot, you should subscribe to:
/rrbot/camera1/image_raw
/rrbot/camera1/camera_info
camera_link
The coordinate frame the image is published under in the tf tree.
After you have saved both rrbot.xacro
and rrbot.gazebo
, you should be able to launch both Rviz and Gazebo in separate terminals:
roslaunch rrbot_gazebo rrbot_world.launch
roslaunch rrbot_description rrbot_rviz.launch
In Rviz, add a ''Camera'' display and under ''Image Topic'' set it to /rrbot/camera1/image_raw
.
You should see a camera view of your Gazebo environment. In the following two pictures, a soda can was added to the environment for better visuals.
The coke can added:
The corresponding camera view after the pendulum has fallen:
Description: synchronizes multiple camera's shutters such that they publish their images together. Typically used for stereo cameras, uses a very similar interface as the plain Camera
plugin
Note: currently only supports stereo cameras. See Github issue.
In this code example there is both a left and right camera:
30.0
1.3962634
800
800
R8G8B8
0.02
300
gaussian
0.0
0.007
0 -0.07 0 0 0 0
1.3962634
800
800
R8G8B8
0.02
300
gaussian
0.0
0.007
true
0.0
multisense_sl/camera
image_raw
camera_info
left_camera_optical_frame
0.07
0.0
0.0
0.0
0.0
0.0
Description: simulates a sensor like a Kinect, which is duplicated in the Kinect plugin. Will probably be merged in the future.
Description: simulates a Microsoft Kinect, publishes the same topics as the corresponding ROS drivers for the Microsoft kinect as documented in the Fuerte documentation here.
20
1.047198
640
480
R8G8B8
0.05
3
0.2
true
1.0
${camera_name}_ir
/${camera_name}/color/image_raw
/${camera_name}/color/camera_info
/${camera_name}/depth/image_raw
/${camera_name}/depth/camera_info
/${camera_name}/depth/points
${frame_name}
0.5
3.0
0.00000001
0.00000001
0.00000001
0.00000001
0.00000001
0
0
0
0
0
You can find a more detailed description for configuring a depth camera in Use a Gazebo Depth Camera with ROS.
Description: simulates laser range sensor by broadcasting LaserScan message as described in sensor_msgs. See Hokuyo Laser Scanners Reference.
See the RRBot Example for adding a Camera to RRBot before reviewing this example. Similar to adding a camera, we will add a new link and joint to the Xacro URDF of the RRBot. This time, instead of using just a rectangle for the visual model, we'll use a mesh:
Now we'll add the plugin information to rrbot.gazebo
, again as we did for the camera example:
0 0 0 0 0 0
false
40
720
1
-1.570796
1.570796
0.10
30.0
0.01
gaussian
0.0
0.01
/rrbot/laser/scan
hokuyo_link
Most of the properties are self-explanatory, but we'll review some below:
false
When true, a semi-translucent laser ray is visualized within the scanning zone of the gpu laser. This can be an informative visualization, or an nuisance.
More documentation on the
and
elements can be found in the SDF Documentation.
/rrbot/laser/scan
hokuyo_link
Set these to the ROS topic name you would like to publish the laser scans to, and the transform frame you would like TF to use.
After you have saved both rrbot.xacro
and rrbot.gazebo
, you should be able to launch both Rviz and Gazebo in separate terminals:
roslaunch rrbot_gazebo rrbot.launch
roslaunch rrbot_description rrbot_rviz.launch
In Rviz, add a ''LaserScan'' display and under ''Topic'' set it to /rrbot/laser/scan
.
You should see a faint laser scan line in your Gazebo environment. While the pendulum is swinging, you should also see the laser scan swing. If the scan is too faint, you can up the size of the laser scan in the properties of the LaserScan display in Rviz. A size of 1m is very easy to see. In the following two pictures, a house and construction barrel was added to the environment for better visuals.
View from Gazebo:
The corresponding laser view from Rviz:
Description: the non-GPU version of GPU Laser
, but essentially uses the same code. See GPU Laser for documentation.
To run with RRBot, open rrbot.gazebo
and change the following two lines.
replace
with
and replace
with
save, then launch the same launch files as for GPU Laser.
Description: provides grid style laser range scanner simulation (e.g. Velodyne).
Description: broadcasts external forces on a body in simulation over WrenchStamped message as described in geometry_msgs.
Description: ROS interface for applying Wrench (geometry_msgs) on a body in simulation.
Description: simulates IMU sensor. Measurements are computed by the ROS plugin, not by Gazebo. See usage snippet sample below for implementation.
:
true
base_footprint
imu
imu_service
0.0
20.0
Description: simulates an Inertial Motion Unit sensor, the main differences from IMU (GazeboRosIMU) are: - inheritance from SensorPlugin instead of ModelPlugin, - measurements are given by gazebo ImuSensor instead of being computed by the ros plugin, - gravity is included in inertial measurements. - set initialOrientationAsReference
to false
to comply with REP 145.
true
true
100
true
__default_topic__
imu
imu_link
10.0
0.0
0 0 0
0 0 0
imu_link
false
0 0 0 0 0 0
Description: listens to a jointtrajectoryaction and plays back the set of joint positions. Sets the set of joints to exact positions without regards to simulated physics and forces.
Description: broadcasts the inertial pose of any body in simulation via Odometry message as described in nav_msgs via ROS topic.
Description: projects a static texture from a source outwards, such as used with the PR2's original head camera sensor. See API documentation for more information.
Description: simulates interfaces exposed by a ROS Prosilica Camera. Here's an example URDF Xacro macro.
Description: provides contact feedback via ContactsState message.
true
${update_rate}
${name}_bumper
world
Description: model plugin that provides a basic controller for differential drive robots in Gazebo. You need a well defined differential drive robot to use this plugin.
${update_rate}
base_link_left_wheel_joint
base_link_right_wheel_joint
0.5380
0.2410
1.0
20
cmd_vel
odom
odom
base_footprint
1
true
true
true
false
Description: model plugin that provides a basic controller for skid steering drive robots in Gazebo (Pioneer 3AT for instance).
100.0
/
front_left_wheel_joint
front_right_wheel_joint
back_left_wheel_joint
back_right_wheel_joint
0.4
0.215
base_link
20
cmd_vel
false
Description: visual plugin that displays a ROS image stream on an OGRE Texture inside gazebo. This plugin does not modify the texture of one of the existing link surfaces, but creates a new texture on top of it. The texture will be created on the XY plane, visible from the +Z side. The plugin requires a pixel size while constructing the texture, and will resize incoming ROS image messages to match if they are a different size.
image
120
160
Description: model plugin that allows arbitrary objects (for instance cubes, spheres and cylinders) to be moved along a horizontal plane using a geometry_msgs/Twist message. The plugin works by imparting a linear velocity (XY) and an angular velocity (Z) to the object every cycle.
Here is a full URDF example that demonstrates how to control a floating box inside gazebo using this plugin, using different visual and collision elements. Note: The object needs to have sufficient inertia to prevent undesirable motions - which can occur as a reaction to the supplied velocity. You can try increasing inertia until the object moves as desired. It is also good to have the center of mass close to the ground.
cmd_vel
odom
odom
20.0
base_footprint
Description: an example c++ plugin template for anyone who wants to write their own plugin.
Gazebo-ROS plugins are stored in a ROS package. See gazebo_plugins wiki page about how you can contribute.
In addition to the plugins explained above, there are also a number of 3rd party Gazebo-ROS plugins. Some of them are found on ros.org (example of search keyword). If a 3rd party plugin is useful and generic enough, please consider pulling it into the official gazebo_plugins package (wiki page) by opening a suggestion at the issue tracker of each repository.
Next we will analyze the ros_control
packages integrated with Gazebo for tight controller/actuator/simulator integration Actuators, controllers, and ros_control.