Open Source Robotics: Getting Started with Gazebo and ROS 2

Dolly is a robot sheep. Dolly follows around while carrying your heavy stuff.  Dolly has two motorized wheels that allow the robot to steer, and a laser scanner to detect objects ahead. It also has a bit of code to find the closest object (presumably you) in the laser scans and control the wheels to follow it.

Dolly isn’t a real robot though. It’s a simple robot simulation created as an introduction to some powerful open source tools that roboticists are using all over the world. Even though Dolly itself is pretty simple, it shares much of its code with many more complex robots such as self-driving cars, warehouse robots, industrial arms, quadcopters, humanoid robots, and even a trio of robots in the International Space Station. The software stack common to all of them is ROS, the Robot Operating System. To be precise however, Dolly is not running what most people would think of when they hear the word “ROS” today. Dolly is actually running latest generation of ROS, called ROS 2!

Like ROS 1 before it, ROS 2 is an open source software development kit for robotics applications. Development of ROS 2 is led by Open Robotics, the company that also maintains the robot simulator where Dolly lives, called Gazebo, as well as other open source robot software and hardware. These projects are distributed under permissive open source licenses such as BSD and Apache 2.0, which makes them attractive to academia and industry alike.

Robot software

The definition of the word “robot” tends to differ depending on whom you ask, but the key characteristic of the robots running ROS and being simulated in Gazebo is actuation. So no chatbots or spambots; we’re talking about robots that are physically able of interacting with their environments, moving themselves and even other objects. And they’re not wind-up toys moving blindly either; they’re equipped with sensors that allow them to observe how the world is changing around them. Tying it all together, they have logic making sense of these observations to make informed decisions about what movement to make next to complete a specific task. This is known as the sense-think-act cycle, and Dolly’s software is organized to reflect these three pieces.

ROS 2 is being developed with the goal of offering a standard software platform to industry and academia that will support them from research and prototyping up to deployment and production. ROS 2 builds on the success of ROS 1, which is already used today in various robotics applications all over the world. An important part of this transition is to maintain the core ROS concepts and tools that have made ROS so successful in the robotics community so far. One of these well-known concepts is that of a “node,” which is a unit of computation responsible for a very specific task. Each piece of Dolly’s sense-think-act cycle is mapped to a node. The “laser” node senses the world, the “follow” node processes that data to find the closest point ahead and generate a command with the direction to move, and the “diff-drive” node moves the wheels as commanded (so called because Dolly is a differential wheeled robot). As Dolly moves, its laser readings change, and the cycles starts again. Dolly’s software only has three nodes for simplicity, but large robotics applications may have hundreds of nodes working together, each responsible for a discrete well-defined task.

The most basic method of communication in ROS uses a many-to-many publisher-subscriber mechanism through channels called “topics”. The laser node publishes scans on the “scans” topic, which the follow node subscribes to; in turn, the follow node publishes movement commands on the “cmds” topic, which the diff-drive node subscribes to. Dolly only uses topics, but in addition to this one-way type of communication, ROS also offers a request-response mechanism called “services,” as well as “actions,” which are used for triggering longer behaviours.

When using these communication patterns, ROS developers tend to use standardized messages whenever possible, which makes it convenient to share nodes among various projects. In this distributed architecture, nodes don’t care about which other nodes they’re talking to, they only care about which topic, service or action is being used. This means that if one day someone decides to remove Dolly’s wheels and exchange them for propellers to turn it into a flying sheep, they won’t need to touch the laser or the follow nodes. They will only need to swap the diff-drive node for something else that translates the movement commands on the cmds topic in a way that matches the robot’s new body.

The ease of code reuse is one of ROS’s greatest strengths because it allows developers to leverage each other’s work as much as possible. By building atop existing software in the ROS ecosystem, developers can focus on the unique aspects of their particular applications. In fact, implementing Dolly only required writing the follow node, which has less than 100 lines of code. The laser and diff-drive nodes are provided by gazebo_ros_pkgs, a standard ROS package that makes the bridge between simulation-specific and non-specific logic. When Dolly is ready to become a physical robot, those nodes would be substituted by hardware-specific drivers and controllers, but the follow node can be kept the same because it publishes and subscribes to standard messages. But as you can imagine, the follow node isn’t the brightest robot logic out there. In fact, Dolly can’t tell a person from a tree. In a real application developers would leverage other capabilities provided by the community, such as the navigation stack, which would allow Dolly to move autonomously in the world.

All of the communication patterns mentioned above have been migrated from ROS 1 to ROS 2 and improved along the way. While ROS 1 uses a custom communication layer, ROS 2 is built on top of DDS. DDS is an industry standard proven in mission-critical applications such as aviation and nuclear power. You can read more details about the DDS integration in this article on InfoQ.

In addition to the messaging system, ROS 2 provides powerful developer tools. For example, RViz is a visualizer for ROS topics that is invaluable during application development and debugging. It has a 3D scene in which data from any part of the application can be displayed together, such as point clouds and coordinate frames. RViz also provides control interfaces such as 3D markers that can be dragged to move a real robot. RQt is another handy graphical tool that lets developers quickly put together widgets to interact with any aspect of their robotics application, be it simulated or not. The image below shows Dolly’s laser scans in RViz alongside Gazebo’s view showing the visualization within simulation. RViz will display scans the same way, regardless of whether they’re simulated or coming from hardware.

Simulation

Dolly lives inside Gazebo, a robot simulator that performs physics computations, generates synthetic sensor data and offers convenient interfaces. The interfaces range from graphical tools to C++ APIs, allowing users and developers to achieve their goals more quickly. The purpose of Gazebo is to be the best possible software-only substitute for physical robots. Some of Gazebo’s uses include prototyping of new robots, development of new algorithms and behaviours, continuous integration testing, and education.

Within the simulation, the physics engine handles how Dolly interacts with the environment. This includes behaviours such as gravity pulling Dolly down to the ground, contacts between the wheels and the sidewalk, and torque applied on the wheels. Gazebo doesn’t implement its own physics engine; instead, it provides an abstraction layer that allows multiple engines to be integrated. This way, developers describe and program their robots once, then choose the most appropriate physics engine at runtime. By default, Gazebo uses the Open Dynamics Engine(ODE), but it also ships with support for Bullet,DART and Simbody.

Dolly is equipped with a single sensor, the laser scanner, but Gazebo supports over a dozen sensors, such as color and depth cameras, IMU, and GPS. Developers are also able to create new sensors through a C++ API. Sensors like cameras and laser scanners use the Ogre3D rendering engine to generate images of the world, while sensors like IMUs and sonars leverage the physics engine. A downside of simulated sensors is that they tend to be a bit too perfect when compared to their physical counterparts. Therefore, an important aspect of the sensors API is the ability to add various types of noise to the generated data and also disturb their update rates.

Gazebo has a rich graphical interface that helps users construct, introspect and interact with their simulations. Dolly’s city environment, for example, was constructed using a combination of eRuby scripts, the UI’s 3D view, and widgets that provide detailed information about every model in the scene. While the simulation is running, the 3D view is also a handy way to visualize the laser scans, as well as introspect various other aspects such as the position of joints, center of mass, and even moments of inertia. This ability of simulation to provide an aerial x-ray-view of the scene can be extremely helpful when iterating on algorithms, and is something that’s hard, if not impossible, to get in the real world.

Gazebo also lets developers interact with their robots much like they would in the real world. You could in theory put on some VR goggles and use controllers to kick Dolly like some roboticists like to do with their real robots. Note that robot abuse is definitely not being encouraged here. Instead, you could use slightly more delicate means, such as a 3D arrow that pushes the robot to check its recovery behaviour. It’s also possible to move the human, add another robot, change the city’s layout… whatever helps development for your specific project.

Worlds in Gazebo are described using the Simulation Description Format. SDF is an XML format that allows specification of every aspect of simulation, from the spring on Dolly’s waggy tail to the color of the sun light. Users can combine 3D models from an online database with their own custom ones to create various environments for their robots. In fact, the whole city environment around Dolly is composed of free models found in the Ignition Fuel online database. Dolly itself is a custom model, and all its details can be tweaked and improved through the UI or directly in its SDF file.

Dolly’s example is one of the simplest simulations one can do with Gazebo, but there are various elaborate examples available online. Simulation-based competitions such as the Virtual Robotics Challenge, the Space Robotics Challenge and the upcoming Subterranean Challenge are some good examples. Several robot manufacturers are also distributing Gazebo simulations of their robots for free, such as Fetch Robotics’s warehouse robots and Parrot’s drones. 

With the goal of tackling new use cases, the team at Open Robotics is actively working on Gazebo’s next generation, which is called Ignition. This refactoring is breaking Gazebo into smaller and more reusable libraries, with abstraction layers for physics and rendering engines, support for running large simulations distributed across machines in the cloud, and use of modern GUI (QtQuick) and transport (ZeroMQ) libraries.

Clone Dolly!

Gazebo and ROS 2 are just a few keystrokes away from you right now. You can clone Dollyand follow the instructions to get a simple example up and running. There are also various tutorials on ROS Index and Gazebo Tutorials covering a wide variety of features and use cases. You can find more in-depth discussions in the community on ROS Discourse and Gazebo Community, as well as answers to technical questions on ROS Answers and Gazebo Answers. Last, but not least, check out videos from ROSCon, the annual conference for ROS developers, and be sure to reserve a seat for ROSCon 2019, happening in Macau.

About the Author

Louise Poubel is a software engineer at Open Robotics, working on free and open source tools for robotics, like the robot simulator Gazebo and the Robot Operating System (ROS).