[Documentation] [TitleIndex] [WordIndex

Purpose

This page details the system architecture for Gazebo v1.0.

Requirements

  1. Speed

    1. Simulate indoor environments with multi-robots in real time
      1. Environments with: multi-room (~3), multiple objects, 1 PR2, multiple Turtlebots
      2. Physics requirements: Manipulate household objects while maintaining stability
  2. Usability

    1. Graphically create worlds: XML editing should not be required
      1. Import common meshes (tables, chairs, etc), such as from 3D Warehouse.
      2. Create models: create joints, set physical properties
      3. Create environments: click+drag to build walls, rooms, and place objects
    2. Controls
      1. Manipulate joints graphically
      2. Apply forces and torques to models
      3. Position objects intelligently: snap to ground, other objects, or a grid
    3. Visualization & Debugging: These features have performance implications, but are disabled by default

      1. Show sensor output: lasers, camera rendering, contacts
      2. Hooks for user generated visualization markers, similar to rviz
      3. Built in performance diagnostics
        1. Hooks for Hudson plot plugin

        2. Plot performance of key components at run time
  3. Programmatic control

    1. Create, modify and control bodies and joints at runtime.
      1. Interface provided via: ROS, custom plugin, or communication through Gazebo communication system
    2. Scriptable objects
      1. Attach scripts to objects in the environment
      2. Will support event triggers, and manipulation of dynamic objects (doors, people, lights)
  4. Portability

    1. Run on any laptop regardless of hardware and OS (linux, mac, windows)
      1. Step 1: Support visualization on alternative platforms
      2. Step 2: Support physics simulation on alternative platforms

Current Implementation

The current version of Gazebo is a monolithic implementation that glues together a physics engine (ODE), a rendering engine (OGRE), and a GUI (QT4). User access to sensors and controllers are provided via a shared memory interface.

Two threads run in Gazebo. The first manages the GUI and rendering engine, and the second thread manages the physics engine. With this setup it is possible to step the physics engine multiple times between rendering updates.

Issues

These issues are in relation to the speed and flexibility of Gazebo. The user interface requirements can be addressed independently of the underlying architecture.

  1. Generating camera sensor data forces the physics engine to pause
    1. This prevents a truly decoupled system where sensor generation can take place independently of physics simulation
  2. Difficult to use individual parts of Gazebo (just physics, or sensor generation)
  3. Difficult to run remotely if user also wants GUI
  4. Can't take advantage of distributed systems
    1. Monolithic architecture is less flexible

Proposed System

In order to address the requirements and resolve the current issues with Gazebo, we propose a distributed architecture. Gazebo will be broken into libraries for physics simulation, rendering, user interface, communication, and sensor generation. Three different processes will be provided: physics_sim, sensor_gen, gui, and a master for coordination.

Communication Between Processes

Communication between each process will use a combination of google::protobufs and sockets. The communication architecture will mimic that of ROS nodes. A simulated world will publish body pose updates, and sensor generation and GUI will consume these messages to produce output.

This mechanism will allow for introspection of a running simulation, and provide a convenient mechanism to control aspects of Gazebo.

Why google::protobufs instead of ROS messages

Gazebo is a standalone application, just as OpenCV and PCL are libraries independent of ROS. In order to use ROS messages, Gazebo would have to exist within the ROS eco-system. Until it's possible to link against specific parts of ROS, it's more practical to use google::protobufs.

Benefits

  1. Speed
    1. Decoupling of physics, sensor generation, and gui into separate processes which can be run independently
  2. Modularity
    1. User can pick and choose which processes to run and where to run them
    2. Each library has a simple API for potential use outside of gazebo
    3. Internal API allow for swapping of physics and collision engines
    4. Communication system allows a user to develop applications with minimal dependencies
      1. example: A render_server that server just images is trivial to implement

      2. example: A web server can potentially interact with a running simulation
  3. Portability
    1. User can run complete sim on cluster and run gui on local machine

Potential Complications

  1. Synchronization between processes
    1. We will use timestamped messages or give user complete control via run_once functionality

  2. Network traffic can become a potential bottleneck
  3. More difficult to run
    1. We can establish scripts for common situations
  4. Development and maintenance:
    1. Complexity leads to a longer debugging process

System Architecture

gazebo_dependency_graph.png

Gazebo Master

This is a stripped down clone of the ROS master. It provides namelookup, and topic management. A single master can handle multiple physics simulations, sensor generators, and GUIs.

Communication Library

This library is used by almost all subsequent libraries. It acts as the communication and transport mechanism for Gazebo. It currently supports only publish/subscribe, but it's possible to use RPC with minimal effort.

Protobuf Messages

Physics Library

The physics library can use any dynamic engine that conforms to the internal API (TBD). It also presents a simple external interface in order to establish a work physics simulation.

Collision Library

This is an abstraction library to handle different collision engines, and provide a simple external interface to the user.

Rendering Library

The rendering library provides a simple interface to both the GUI and sensor generation. We are currently sticking with OGRE since we don't have a better alternative. It will be possible to write plugins for the rendering engine.

Note on RVE

Significant work has been done on RVE, and we believe there may be potential to combine our efforts. In the next few days/weeks we will hash out this possibility, and how to proceed.

Sensor Generation

The sensor generation library implements all the various types of sensors, listens to world state updates from a physics simulator and produces output specified by the instantiated sensors.

GUI

The primary function of the GUI involves displaying the current state of the simulation and providing a convenient means for user input. There is no need for an internal or external API since we are sticking with wxWidgets.

Plugins

The physics, sensor, and rendering libraries will support plugins. These plugins will provide users with access to the respective libraries without using the communication system.


2024-03-23 12:35