SubT Part 3: Ignition

This is the third article in our five part SubT series. Check out the first post in this series if you’re just joining us and want to get the full story. In this article I’ll talk about Ignition, which provided the simulation capabilities for SubT.

Let’s begin with a bit of history. Ignition started in early 2014 as a collection of software libraries designed to simplify development of high-performance robotic applications. You’ll find everything you need, from solving mathematical transforms, to modeling sensors and connecting simulation with cloud infrastructure. Each library within Ignition is curated by Open Robotics and designed to have minimal dependencies. Just choose the libraries you need for your application and start creating.

Development of Ignition dramatically accelerated thanks to SubT. The first three major releases of Ignition all took place in 2019 to support SubT. We wrapped up SubT in 2021 on the fourth major Ignition release, named Dome. Since then we’ve released two more versions of Ignition, Edifice, an interim release, and Ignition Fortress, a long term support release. The development and release schedule has now slowed to a more steady cadence. You can find out more information about past and future releases on Ignition’s roadmap.

Now that we have Ignition’s history out of the way, we can jump into key simulation features developed during SubT. Ignition relies heavily on plugins, where our philosophy is “pay for what you use”, meaning that it is best to design new features such that they are optional. Following this model, SubT features were created as plugins. General purpose plugins, i.e. those that can be picked up by other projects,  appear in the ign-gazebo repository, whereas SubT specific plugins appear in the osrf/subt repository. 

In the following sections, I’ll go over some of the most interesting plugins developed for SubT.

Breadcrumbs

Robots operated in underground environments which limited access to terrestrial communication methods like 4G and impaired other methods like Wi-Fi. To communicate over long distances, teams could optionally carry and deploy their own wireless communication devices. These communication devices were referred to as breadcrumbs.

The breadcrumb plugin was originally designed to drop communication breadcrumb nodes from robots. We have generalized the breadcrumb plugin so that it can spawn any model based on a trigger signal sent over a topic. For example, this plugin was also used to spawn rock falls based on the presence of a robot. When robots entered certain areas of the environment, it would trigger a rock slide that the robot would need to react to. More information about the breadcrumb plugin can be found in the Ignition Gazebo documentation.

Performer detector

Dynamic obstacles, such as falling rocks, needed to know when a robot entered or left a 3D region. We created a performer detector system plugin  that allowed us to specify a 3D region and then publish a message to a topic containing information about any detected performer. In our case, a performer is a robot. This plugin was used in conjunction with the breadcrumb plugin to coordinate dynamic obstacles with robot movement, and log important events during a simulation run.

Linear Battery

Each SubT robot had a battery, which would begin with a charge that would drain over time when the robot moved. Once a battery is depleted, the robot is no longer able to move. Some robots, such as multicopters, had a shorter battery life than other robots, such as a Husky wheeled robot. These different robots all used the linear battery system plugin, which has a number of parameters that can be set to closely match a physical battery’s characteristics. There is even the option to recharge a battery based on a signal sent over a topic.

Particle Emitter

Dust is common in subterranean environments, especially when collapses occur. Additionally, smoke machines were used in the system track to act as a controllable obstacle. We relied upon Ignition Rendering’s particle system to mimic the smoke machines and generate dust effects similar to those experienced by system track competitors. The particle emitter system plugin creates topics to control emitter state. Full specification of emitter parameters is handled through SDF.

Not only were particles rendered in image cameras, they also had an impact on depth cameras and lidar sensors. Depth and lidar sensors would experience a scattering effect, with added Gaussian noise, whenever particles were present. In a smokey environment only thermal cameras could effectively see through the particle cloud.

Thermal Camera

Many SubT robots featured a thermal camera to assist with finding artifacts. Modeling a thermal camera proved to be a challenge in itself. Thermal cameras are very useful in low light conditions, especially when you’re looking for objects that emit heat such as the survivor artifact. We adapted the Ignition rendering pipeline to incorporate heat map textures and ambient temperature. The resulting thermal images mimic output from a thermal camera, as seen below.

Left pane shows a robot equipped with a thermal camera. Right pane shows output from the thermal camera.

SubT Plugins

A number of plugins were developed specifically for SubT. These plugins helped to validate worlds, apply localized wind forces, and generate videos from log files. The two most important SubT specific plugins were the communication model, which handled inter-robot communication, and the GameLogicPlugin, which implemented the SubT rules.

Subterranean environments can dramatically limit communication capabilities. Walls, narrow passages, and bends in tunnels can all cause loss of communication range and increase the number of dropped packets. The SubT communication model approximates how radio propagation works inside these subterranean environments. It's a probabilistic model that considers the topology of the path that needs to be traversed from source to destination, as well as the Euclidean distance between the robots and breadcrumbs involved. A detailed description of the communication model can be found on the SubT wiki.

The GameLogicPlugin was the wizard behind the curtain, making sure that the rules were followed. All of the work necessary to score, monitor, and log a SubT simulation run was performed by the GameLogicPlugin. Essentially, this plugin converted the SubT rules from prose to code. If you’re interested in creating your own competition or challenge, then this would be a good place to look for inspiration and tips.

These were most noteworthy developments from SubT. A lot of additional work went into performance improvements, stability, log file processing, and cloud simulation. The next article in this series will cover how we ran a competition in the cloud.