Architecture

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.

System Diagram ==

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 -- * **Dependencies:** Protobuf and boost::ASIO * **External API:** * **Internal API:** None * **Advertised Topics:** None * **Subscribed Topics:** None

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.

Physics Library -- * **Dependencies:** Dynamics engine, and Collision Library * **External API:** Provides a simple and generic interface to physics simulation * **Internal API:** Defines a fundamental interface to the physics library for 3rd party dynamic engines.

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 -- * **Dependencies:** 3rd party collision engine * **External API:** TBD * **Internal API:** Generic interface for collision engines * **Advertised Topics:** None * **Subscribed Topics:** None

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

Rendering Library -- * **Dependencies:** OGRE * **External API:** Allows for loading, initialization, and scene creation * **Internal API:** None, we are going to use only OGRE.

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.

Sensor Generation -- * **Dependencies:** Rendering Library, Collision Library * **External API:** Provide functionality to initialize and run a set of sensors * **Internal API:** TBD

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 -- * **Dependencies:** Rendering Library, wxWidgets * **External API:** None * **Internal API:** None

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.