Taken from
http://playerstage.sourceforge.net/doc/Gazebo-manual-0.3.0-html

1.1
What is Gazebo?

Gazebo is a multi-robot simulator for outdoor environments. Like
Stage, it is capable of simulating a population of robots, sensors
and objects, but does so in a three-dimensional world. It generates
both realistic sensor feedback and physically plausible interactions
between objects.

Gazebo is normally used in conjunction with the Player device
server. Player provides an abstracted, network-centric mechanism (a
server) through which robot controllers (clients) can interact with
real robots and sensors. Gazebo works in conjunction with Player,
providing simulated sensor data in the place of real sensor data.
Ideally, client programs cannot tell the difference between real
devices and the Gazebo simulation of those devices.

Gazebo can also be controlled through a low-level interface
(libgazebo ). This library included to allow
third-party developers to easily integrate Gazebo into their own
(non-Player) robot device servers or architectures.

Player/Stage and Gazebo is Open Source and Free Software, released
under the GNU General Public License. If you don't like how something
works, change it. And please send us your patch!

2. Key Concepts and Basic Syntax

2.1 The World File

The world file contains a description of the world to be simulated
by Gazebo. It describes the layout of objects, robots, sensors and so
on.

Gazebo world files are written in XML, and can thus be created and
modified using a text editor.

The world consists mainly of model declarations. A model
can be a robot (e.g. a Pioneer2AT ), a sensor (e.g. SICK LMS200), a
static feature of the world (e.g. MapExtruder) or some manipulable
object. For example, the following declaration will create a
Pioneer2AT named ``robot1'':

Associated with each model is a set of attributes such as
the model's position <pos> and orientation <rot>.
Models can also be composed. One can, for example, attach a scanning
laser range-finder to a robot:

And of course how the world is going to
be like, as an example here it is a plane-grid terrain:

<model:GroundPlane>

<id>ground1</id>

<normal>0.0 0.0 1.0</normal>
<!-- Which way is up -->

<height>0.0</height>
<!-- The vertical height of the plane -->

<color>0.929 0.870
0.239</color> <!-- the color of the plane -->

<grid>

<normal>0.0 0.0
1.0</normal> <!-- Normal vector for the grid -->

<height>0.1</height>
<!-- How high (z direction) to place the grid -->

<spacing>1.0 1.0</spacing>
<!-- x,y spacing of the grid lines -->

<color>.5 .5 .5</color>
<!-- the color of the grid -->

</grid>

</model:GroundPlane>

And the Camera that we are going to use
to see the world and its components:

<model:UserX11GLCamera>

<id>usercam1</id>

<pos>5.0 0.0 1.2</pos>

<rot>0.0 0.0 90.0</rot>

<windowId>glwindow1</windowId>
<!-- the window to draw to -->

<renderToScreen>true</renderToScreen> <!-- draw to the
window -->

<refreshPeriod>0.1</refreshPeriod>
<!-- seconds between refresh -->

<shadeModel>flat</shadeModel>
<!-- flat, smooth -->

<polygonMode>fill</polygonMode>
<!-- point, line, fill -->

<compass>true</compass>
<!-- draw a compass on the screen -->

</model:UserX11GLCamera>

Gazebo interacts with Player, so let
see what is Player:

3. Player.

What is Player? Player is a robot device server. It gives you
simple and complete control over the physical sensors and actuators
on your mobile robot. When Player is running on your robot, your
client control program connects to it via a standard TCP socket, and
communication is accomplished by the sending and receiving of some of
a small set of simple messages.

Player is designed to be language and platform independent. Your
client program can run on any machine that has network connectivity
to your robot, and it can be written in any language that can open
and control a TCP socket. Client-side utilities are currently
available in C, C++, Tcl, LISP, Java, and Python. Further, Player
makes no assumptions about how you might want to structure your robot
control programs. In this way, it is much more ``minimal'' than other
robot interfaces. If you want your client to be a highly concurrent
multi-threaded program, write it like that. If you like a simple
read-think-act loop, do that. If you like to control your robot
interactively, try our Tcl client (or write your own client utilities
in your favorite interactive language).

Player is also designed to support virtually any number of
clients. Have you ever wanted your robots to ``see'' through each
others' eyes? Now they can. Any client can connect to and read sensor
data from (and even write motor commands to) any instance of Player
on any robot. Aside from distributed sensing for control, you can
also use Player for monitoring of experiments. For example, while
your C++ client controls a robot, you can run a Tk GUI client
elsewhere that shows you current sensor data, and a Python client
that logs data for later analysis. Also, on-the-fly device requests
allow your clients to gain access to different sensors and actuators
as needed for the task at hand.

In addition to controlling the physical hardware, Player can be
used to interface to the robot simulators Stage and Gazebo.

Last but not least, Player is Free Software. If you don't like how
something works, change it. And please send us your patch!

Example of Player
Operation

Figure 1.1:Example client/server interaction

As a simple example of the use of Player, consider Figure 1.1
(note that for clarity, we leave out several protocol-level
interactions). The server is executing locally on the computer to
which the devices of interest are connected. In many cases, this
computer is the robot itself, but it could also be, for example, a
desktop machine attached to a SICK laser range-finder. The client can
execute anywhere that has network connectivity to the machine hosting
the server.

First, the client establishes a TCP socket connection to the
server. The client next sends some messages to the server to open
the devices in which the client is interested. After that, the server
continuously feeds data from those devices to the client, and the
client exerts control by sending appropriate commands back to the
server. Very simple.