gazebo学习笔记 （英文复制）

**

1.gazebo组成

**
1.world files
The world description file contains all the elements in a simulation, including robots, lights, sensors, and static objects. This file is formatted using SDF (Simulation Description Format), and typically has a .world extension.

The Gazebo server (gzserver) reads this file to generate and populate a world.

A number of example worlds are shipped with Gazebo. These worlds are located in /share/gazebo-/worlds.

 **2.model files** 
 A model file uses the same SDF format as world files, but should only contain a single <model> ... </model>. The purpose of these files is to facilitate model reuse, and simplify world files. Once a model file is created, it can be included in a world file using the following SDF syntax:

<include>
  <uri>model://model_file_name</uri>
</include>

A number of models are provided in the online model database (in previous versions, some example models were shipped with Gazebo). Assuming that you have an Internet connection when running Gazebo, you can insert any model from the database and the necessary content will be downloaded at runtime.

 **3.Environment Variables**
 Gazebo uses a number of environment variables to locate files, and set up communications between the server and clients. Default values that work for most cases are compiled in. This means you don't need to set any variables.

Here are the variables:

GAZEBO_MODEL_PATH: colon-separated set of directories where Gazebo will search for models

GAZEBO_RESOURCE_PATH: colon-separated set of directories where Gazebo will search for other resources such as world and media files.

GAZEBO_MASTER_URI: URI of the Gazebo master. This specifies the IP and port where the server will be started and tells the clients where to connect to.

GAZEBO_PLUGIN_PATH: colon-separated set of directories where Gazebo will search for the plugin shared libraries at runtime.

GAZEBO_MODEL_DATABASE_URI: URI of the online model database where Gazebo will download models from.

These defaults are also included in a shell script:
source <install_path>/share/gazebo/setup.sh
If you want to modify Gazebo’s behavior, e.g., by extending the path it searches for models, you should first source the shell script listed above, then modify the variables that it sets.

Gazebo Server
The server is the workhorse of Gazebo. It parses a world description file given on the command line, and then simulates the world using a physics and sensor engine.

The server can be started using the following command. Note that the server does not include any graphics; it’s meant to run headless.

gzserver <world_filename>

The can be:

1.relative to the current directory,

2.an absolute path, or

3.relative to a path component in GAZEBO_RESOURCE_PATH.

Worlds that are shipped with Gazebo are located in /share/gazebo-/worlds.

For example, to use the empty.world which is shipped with Gazebo, use the following command

gzserver worlds/empty.world

Graphical Client
The graphical client connects to a running gzserver and visualizes the elements. This is also a tool which allows you to modify the running simulation.

The graphical client is run using:gzclient

Server + Graphical Client in one
The gazebo command combines server and client in one executable. Instead of running gzserver worlds/empty.world and then gzclient, you can do this:

gazebo worlds/empty.world

Plugins
Plugins provide a simple and convenient mechanism to interface with Gazebo. Plugins can either be loaded on the command line, or specified in a world/model file (see the SDF format). Plugins specified on the command line are loaded first, then plugins specified in the world/model files are loaded. Most plugins are loaded by the server; however, plugins can also be loaded by the graphical client to facilitate custom GUI generation.

Example of loading a plugin on the command line:

gzserver -s <plugin_filename> <world_file>

The same mechanism is used by the graphical client:

gzclient -g <plugin_filename>

**

2.gazebo architecture

**
Introduction
Gazebo uses a distributed architecture with separate libraries for physics simulation, rendering, user interface, communication, and sensor generation. Additionally, gazebo provides two executable programs for running simulations:

a server gzserver for simulating the physics, rendering, and sensors

a client gzclient that provides a graphical interface to visualize and interact with the simulation

The client and server communicate using the gazebo communication library.

Communication Between Processes
The communication library currently uses the open source Google Protobuf for the message serialization and boost::ASIO for the transport mechanism. It supports the publish/subscribe communication paradigm. For example, a simulated world publishes body pose updates, and sensor generation and GUI will consume these messages to produce output.

This mechanism allows for introspection of a running simulation, and provides a convenient mechanism to control aspects of Gazebo.

System
Gazebo Master
This is essentially a topic name server. 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 is possible to use RPC with minimal effort.

Physics Library
Dependencies: Dynamics engine (with internal collision detection)
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 provides a simple and generic interface to fundamental simulation components, including rigid bodies, collision shapes, and joints for representing articulation constraints. This interface has been integrated with four open-source physics engines:

Open Dynamics Engine (ODE)
Bullet
Simbody
Dynamic Animation and Robotics Toolkit (DART)
A model described in the Simulation Description Format (SDF) using XML can be loaded by each of these physics engines. This provides access to different algorithm implementations and simulation features.

Rendering Library
Dependencies: OGRE
External API: Allows for loading, initialization, and scene creation
Internal API: Store metadata for visualization, call the OGRE API for rendering.
The rendering library uses OGRE to provide a simple interface for rendering 3D scenes to both the GUI and sensor libraries. It includes lighting, textures, and sky simulation. It is possible to write plugins for the rendering engine.

Sensor Generation
Dependencies: Rendering Library, Physics 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, Qt
External API: None
Internal API: None
The GUI library uses Qt to create graphical widgets for users to interact with the simulation. The user may control the flow of time by pausing or changing time step size via GUI widgets. The user may also modify the scene by adding, modifying, or removing models. Additionally there are some tools for visualizing and logging simulated sensor data.

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

//capture screenshot –>the image will be saved to ~/.gazebo/pictures with a timestamped filenames.