Simulators for ROS

1. Introduction
2. Gazebo
3. V-REP
4. Miscellaneous
5. Cloud Based Simulators

1 Introduction

Working with real robots is a challenging proposition. They are expensive, complicated, and they always seem to be broken. Developing robotic applications in simulation first is often the right way to go. Your development cycle is often much faster in simulation, you can't break anything, and it's much cheaper. In a best-case scenario, your simulator's interface is identical to your actual system, so porting code from the simulated world to the real system becomes a trivial task. Further, you hope that your simulator provides a sufficiently high-fidelity model of the system so that when you do port your code from the simulated world to the actual system, everything "just works". Unfortunately, robots interacting with the world are extremely difficulty to simulate well. Physics simulation engines must deal with complex phenomena such as contact, impacts, and friction; they do this, but they don't do it in a very physically realistic way. The takeaway is that simulations should never be fully trusted, especially if your application involves a highly dynamic system.

This lecture discusses the most common simulation engines that people use with ROS. The content will not focus on how to use these simulators. Rather, we will compare and contrast the features and structure of each of the simulators.

2 Gazebo

Gazebo is the basically the "official" simulator for ROS. Gazebo is a major software project that is managed by the Open Robotics (like ROS). Quoting from the official Gazebo website:

Gazebo is a 3D multi-robot simulator with dynamics. It offers the ability to accurately and efficiently simulate populations of robots, objects, and sensors in complex indoor and outdoor environments. Gazebo generates both realistic sensor feedback and physically plausible interactions between objects; it includes an accurate simulation of rigid-body physics.

At your fingertips is a robust physics engine, high-quality graphics, and convenient programmatic and graphical interfaces. Best of all, Gazebo is free is and supported by a vibrant community.

2.1 Primary Components and Features

Dynamics Simulation: Gazebo has the ability to simulate physics using a variety of common physics engines that have all been adapted to work with Gazebo. The engines supported by Gazebo are ODE, Bullet, Simbody, and DART.
3D Graphics: One of the best tools in ROS is rviz. Similarly, Gazebo features its own 3D graphics tool used for animating the worlds that you are simulating. The graphics look great, and the tool is relatively easy to use.
Sensors and Noise: There are simulation plugins written for a wide array of sensors commonly used in robotics. Examples include laser range finders, 2D/3D cameras, contact sensors, force-torque sensors, and more. These plugins are written such that the virtual data produced by the simulation is in exactly the same format that it would be in when using the real sensor.
Plugins: Most of the components in Gazebo are written as "plugins". This is powerful for users, because this means that new plugins can be developed for custom applications. For example, one could write a plugin to simulate a sensor that isn't available out-of-the-box.
Robot Models: In ROS the kinematics and visual representations of robots are represented in URDF files. Gazebo uses a very similar format called the SDF format. The tags supported by SDF files are a huge superset of those supported by URDF. Having a URDF is a great start to generating a robot model, but to simulate any sort of nontrivial environment, you need significantly more metadata. Note that many common robots provide simulator setup files for Gazebo. For example, there are already-defined simulations for the PR2, the TurtleBot, the Pioneer2 DX, Baxter, and many more.
TCP/IP Transport: Much like ROS itself, internally, Gazebo runs as a variety of processes that pass data back and forth between a socket-based messaging system (you can see their message definitions here). This is typically more transparent to the user than it is in ROS, and the communication protocols are different than in ROS. Even though this may not matter much to most users, it does enable several key features of Gazebo. First, it means it is easy to run simulations on remote servers and access the results through this transport mechanism. Second, this internal communications is one of the primary reasons that it is very easy to incorporate ROS and Gazebo.
Command Line Tools: Just like ROS, Gazebo has a variety of command line utilities that allow you to control simulations and inspect the details of a running simulation.

2.2 Pros and Cons

In this section, I will present a basic list of pros and cons of Gazebo. Note that these are strictly my opinions based on my experiences. There are likely users that would disagree with me.

2.2.1 Pros

ROS integration is very easy (which makes sense). Once you have a Gazebo-ROS simulation of a robotic application up and running it is completely trivial to instead run the real system. Typically all that is required is turning on the real robot instead of the simulator and running a different launch file.
Gazebo is used a lot! This means that there is a great support community.
Gazebo was the official simulator for the DARPA Robotics Challenge, as a result the growth and usage of Gazebo in the last few years has been explosive.
Generally the documentation for Gazebo is pretty good, and the tutorials are fantastic.
The number of robots that support Gazebo is definitely a plus.
The variety of sensors supported is awesome.
The ability to choose different physics engines is very useful. Some physics engines are very fast, but not particularly realistic (e.g. Bullet), others engines have more powerful numerical techniques at their core and provide more accurate simulations, typically at the expense of greater computation and a smaller variety of supported physics phenomena (e.g. DART). With Gazebo, it is easy to choose the right engine for your particular application.
Gazebo's plugin interface enables nearly unlimited extensibility. If you are willing to write some C++ code that uses the Gazebo APIs you can easily write new plugins that simulate basically anything that doesn't already have a plugin (e.g. new sensors, new physical phenomenon, new controllers, etc.).

2.2.2 Cons

While the ROS integration is very easy, understanding the relationship between Gazebo and ROS can sometimes be confusing. Here are several examples:
- A ROS version is released specifically to work with a particular Gazebo version. For example ROS Indigo is built around Gazebo 2. In fact, the ros-kinetic-desktop-full Debian package explicitly depends on ros-kinetic-simulators which eventually depends explicitly on the gazebo7 package. Both ROS and Gazebo have their own apt sources that can provide this dependency. Which one should you use (they aren't the same)? What if you need to use a different version of Gazebo than what your particular ROS version was built around? Figuring out how to properly match Gazebo/ROS versions and released simulators is a constant struggle for developers. If you did want to try it, you'd want to check out this page. Alternatively, you could use something like Gazebo Docker containers.
- The relationship between URDFs and SDFs is complicated (as we've discussed before). Often looking at a URDF of a real robot, you'll see many Gazebo-specific tags buried inside. These tags are mostly to facilitate the usage of a single URDF file for both the robot_description parameter in the ROS world and for the description of the robot in an SDF file that describes a Gazebo simulation world. If you'd like to use a URDF to automatically describe a robot in Gazebo, read this documentation on which tags are required.
- The ros_control ROS package provides a method for physically interfacing ROS with low-level motor controllers on a robot. It also has the ability to interact directly with Gazebo to enable Gazebo to simulate these low-level controllers. When all is working correctly, the simulated low-level controllers and the actual low-level controllers integrate with ROS using the exact same interfaces. Thus simple changes in launch files is all that is required to start a simulated robot or a real robot. Further, nearly the exact same control code can be used for the low-level control in both simulation and on real hardware. This all sounds great, but the relationship is complex. See the image below for graphical depictions of how ros_control interfaces with real hardware and Gazebo.
  
  Figure 1: Data flow between ROS, Gazebo, and real hardware through ros_control. Borrowed from here.
Gazebo is very complicated. When you have issues, it is often difficult to track down where they are coming from if you don't have a lot of experience. I have had many issues with Gazebo being unstable (random crashes, especially on startup). This has been improved significantly in newer Gazebo releases.
Running a full Gazebo simulator, plus all of the ROS nodes for a complicated robotics application is very computationally expensive. You need a fast computer with a decent graphics card.
Setting up a robot and an environment from scratch is a lot of work!
Gazebo is tough to run on anything but Linux. It can be done, but expect to put in some work getting everything to compile. Here are the Windows installation instructions and standard source install instructions have a special section on how to install on a Mac.

2.3 Resources

SDF File Format Specifications
List of Gazebo tutorials… of particular interest are the series of tutorials about connecting to ROS
Code API for Gazebo 2.2 (Indigo version)
Code API for Gazebo 7.0 (Kinetic version)
Code API for Gazebo 9.0 (Melodic version)
Gazebo Get Started Guide provides high-level descriptions of the core components of Gazebo
answers.gazebosim.org is just like answers.ros.org except for Gazebo

Gazebo and ROS Control mini-project from 2014. Josh Marino and Mahdieh Nejati Javaremi did a mini-project in this course where they worked through and extended the series of Gazebo tutorials involving Gazebo interacting with ROS.
ROSCon 2016 talk on the latest developments in Gazebo. This presentation is long, but it gives a great overview of all of Gazebo's features. The entire presentation is given directly in Gazebo!
This ROSCon 2017 talk focuses on the development of vehicle and city simulation tools in Gazebo. This really illustrates the extensibility of Gazebo (if you're willing to do the work).
This ROSCon 2017 talk discusses building the simulation environment for the Space Robotics Challenge. Again demonstrates the flexibility, and discusses deploying the simulation tools on the cloud.
ROSCon 2018 talk on modeling lighting conditions on the moon in Gazebo to allow realistic simulated camera images.
ROSCon 2018 talk on using Gazebo as a simulation tool for reinforcement learning.

3 V-REP

V-REP is the primary other simulator people commonly use with ROS. It is capable of simulating many of the same things that Gazebo is, and it supports a huge library of robots out of the box. In my experience it is lighter-weight than Gazebo (less CPU and memory intensive), has fewer dependencies than Gazebo (they are all bundled with the V-REP install), and less prone to crashing. I also think it is a bit easier to get a simulation up-and-running with V-REP, although Gazebo's scene editing tools have come a long way in the last few years. A huge downside to V-REP compared to Gazebo is in the difficulties associated with enabling communication with ROS.

Communication with ROS is handled in a variety of ways. V-REP has created a custom plugin that allows communication with ROS called the RosInterface plugin. Note there is an older, now deprecated plugin called the RosPlugin that you should not use. Further, the vrep_ros_bridge package (detailed installation instructions on the package's GitHub page) is an externally-developed package for connecting V-REP and ROS. In V-REP, the primary scripting language is Lua. If you want to be exchanging any sort of data between V-REP and ROS, you must explicitly add this functionality in a Lua script that accompanies your simulation. So for example, let's say that you have a simulated camera in V-REP that you'd like to subscribe to with a ROS image processing node. Then in your main Lua script that runs with your simulation, you must explicitly add a "publisher" to send that camera stream to the ROS world on an appropriate topic. This is not a huge deal if you are only interested in communicating a little bit of information between V-REP and ROS, but it can be quite an arduous task to properly setup a simulation that exchanges a lot of information between the two programs. Further, if your ROS code is going to be processing simulated sensor data and sending control commands back to the V-REP system (e.g. let's say you are doing a visual servoing task) then proper synchronization between the V-REP simulation and the ROS world can be challenging.

3.1 Pros

Very easy to use and install.
Free for academics, mostly open source, cross-platform.
Supports a wide range of robots and sensors out-of-the-box. Although, it is worth pointing out, that in my experience, the built-in models differ significantly from the real-world robots (not just in dynamic behavior, but also in fundamental things like kinematic descriptions). Just like Gazebo, if you are working with unsupported robots/sensors, you must configure your own robots/sensors using built-in modeling tools and custom plugins.
Lightweight computational requirements compared to Gazebo. In my experience, V-REP generally starts quicker, and requires less CPU and memory than Gazebo.
Features a Regular API that allows one to use many of the underlying tools of V-REP in standalone applications or in scripts directly in V-REP. Custom scripts using the Regular API are nearly always used when developing custom simulation scenes. V-REP also features a Remote API that allows programs written in a variety of other languages to connect with V-REP via a socket connection (much like inter-process communication in ROS) and call functions that are internal to V-REP. These two APIs provide many options for extending and leveraging V-REP. As an example of how we could use these APIs imagine we were trying to use V-REP's inverse kinematics (IK) solvers to provide IK solutions for an arbitrary robot that we had. We could write our own C++ code that linked against the Regular API and directly called the IK functions when we wanted an IK solution. Alternatively, we could start a running V-REP simulation (we could even do this in headless mode) and use the Remote API to send/receive IK requests/results over a socket.

3.2 Cons

Not nearly as tightly coupled as Gazebo with ROS.
Since the primary scripting language is Lua, you need to learn a bit about Lua (great… another scripting language).
The GUI is a bit tough to learn how to use. There are many menus and buttons that are unfamiliar, and they don't have great labels.
In my experience, it is more difficult to get/find help with V-REP than it is with Gazebo. Their forum is good, but it isn't used quite as widely as Gazebo.
If you have an unsupported robot or sensor, it requires a lot of work to build up the simulations of these components (much like Gazebo).
I'm really not a fan of how all of the Lua scripts that go along with a scene are bundled directly in the scene file. This makes it difficult to track changes in version control, and it causes you to have a lot of duplicated code since you can't re-use utility functions across scenes.
The built-in Lua interpreter has very few general-purpose utility functions, especially when compared against something like Python. For example, there are no tools for navigating a filesystem, reading CSV files, matrix math, etc. While there are Lua implementations of these things, none are bundled with V-REP. So you must figure out how to download the implementations and get the bundled interpreter to be able to use these implementations (usually just requires copying some scripts to the correct directory in the V-REP source).

3.3 Resources

V-Rep can be downloaded here: http://www.coppeliarobotics.com/downloads.html The PRO EDU version is free for academics.
Their tutorial on using V-Rep with ROS Indigo can be found here: http://www.coppeliarobotics.com/helpFiles/en/rosTutorialIndigo.htm. Even though this says Indigo in the title, nothing has really changed for Melodic.
The V-REP forum is a good place to go for help
Here is a link to the demos that Jon Rovira put together for using Baxter and the youBot in V-Rep: https://github.com/jonrovira/ME_495_work/tree/master/src/vrep_stuff
Here are a few scenes that I created for ME 449. They aren't fancy, but I know exactly how they work. So if you had questions about any of the details, I'd be happy to answer them.

4 Miscellaneous

In this section I will discuss just a few other simulators that exist in the robotics world that you may see people using. Some of these simulators are often coupled with ROS, and others are not.

Stage: Stage was really a precursor to Gazebo. Much like the Gazebo-ROS relationship, Stage had a corresponding framework called Player that allowed people to directly interact with either a real robot or a Stage simulation with basically no code changes. Even though Gazebo is much more powerful, Stage is still used often for 2D simulations of networked mobile robots (swarms).
Drake: Drake is the primary software from Russ Tedrake's Robot Locomotion Group at MIT. It features not only simulation tools, but many control and planning synthesis techniques. Drake seems to be gaining a lot of traction in the community. Originally this primarily supported MATLAB, but there has been quite a bit of recent work on developing a C++ API and wrappers for Python and Julia.
Morse: Morse is an actively developed generic simulator for robots that uses the Blender game engine for rendering and Bullet for dynamic simulation. All scripting is done with Python, and it officially supports ROS. The primary reason Morse doesn't get its own section is that its support for ROS is somewhat limited, and I see a far smaller userbase in the ROS world than either Gazebo or V-REP.
Webots: Webots has a long history, it has been around for over 18 years. It features a variety of APIs, it has many robots already available, and it features ROS interfaces. All that being said, I don't see it being used with ROS very often.
OpenRAVE: OpenRAVE is not really a generic robot simulator like the others in this list. Rather, OpenRAVE is specifically for simulating kinematic and geometric information and aims to provide users with an easy way to deploy motion planning algorithms. It is in this list because many people use some of OpenRAVE's core components with ROS (specifically, IKFast).
ODE: Some robotics labs use ODE directly rather than accessing it through a frontend like Gazebo.
Bullet: Some robotics labs use Bullet directly rather than accessing it through a frontend like Gazebo.
Blender: While Blender is more of an animation program, it does feature beautiful animation capabilities, IK routines, Python scripting, and dynamics simulation via Bullet. There have been a few people combining ROS + Morse + Blender into a completely integrated simulation, control, and animation environment.
trep: Obviously, this is the software that Todd Murphey's lab has developed (and I'm one of the primary maintainers). This doesn't have a large number of users, but I put it on this list because it sits on a very different end of the spectrum from the rest of the software on this list. Its graphics capabilities are very limited, and it has no built-in support for contact modeling. What it does feature, however, is a very easy interface for accessing low-level analytical results such as fast numerical evaluation of dynamics equations and their first and second order linearizations, automated optimal control calculations, and geometric introspection tools.
Custom: In my experiences of working with ROS, I have found a variety of situations where I needed to simulate something simple, and I ended up deciding that it wasn't worth the trouble of setting up a full-blown Gazebo/V-REP simulation. I instead wrote my own simple simulator that subscribes and publishes the same topics that the real robot would use. I don't necessarily advocate doing this, but do be aware, that it is always an option, and in some cases, might actually be a good way of doing things.

5 Cloud Based Simulators

The amount of effort in getting a generic simulation tool setup and running on a machine is nontrivial. Then once you have that tool setup, you need to setup the simulation parameters specifically for your situation (adding objects, robots, interfaces, etc.); this is also a highly work-intensive task. Even with the simulation tool available and a simulation scene properly setup, the actual running of the simulation can also be difficult as the simulation engines are often extremely CPU and memory intensive. All of these complications have lead to many people pushing for cloud-based simulation tools over the last few years. Below are descriptions of two cloud-based simulators that have been receiving active development; there are probably others in the works.

CloudSim

At the start of the DARPA Robotics Challenge (DRC), DARPA organized a competition to award grants to teams. This competition was called the DARPA Virtual Robotics Challenge (DVRC) and the idea was that teams would submit the control code to a cloud-based simulation and all teams could live-stream the results of the simulations. The environment that was setup for this was called CloudSim. Since the DVRC, quite a lot of work has gone into the development of CloudSim, and it is expected to be released to the public soon.

The official website allows you to sign up for notifications on the release.
At ROSCon 2016 Ian Chen from OSRF gave a presentation on the latest and greatest with CloudSim. The presentation is here and the video of the presentation is here.
Here's a video of an early demo of CloudSim

The Construct

The Construct is another cloud-based robotics simulator that can use Gazebo or Webots as a backend. They feature a repository of simulation scenes and robots, ROS teaching tools, and simulation benchmarking. Check out the ROSCon 2016 presentation on The Construct.