|
|
PLAYER/STAGE AND GAZEBO
Robot Environment Simulator.
Taken from http://playerstage.sourceforge.net/doc/Gazebo-manual-0.3.0-html
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!
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'':
<model:Pioneer2AT>
<id>robot1</id>
<pos>0 0 0.40</pos>
<rot>0 0 45</rot>
</model:Pioneer2AT>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:
<model:Pioneer2AT>
<id>robot1</id>
<pos>0 0 0.40</pos>
<rot>0 0 45</rot>
<model:SickLMS200>
<id>laser1</id>
<pos>0.15 0 0.20</pos>
<rot>0 0 0</rot>
</model:SickLMS200>
</model:Pioneer2AT>
We can define geometric figuresa in the environment:
<model:SimpleSolid>
<pos>2 2.1 2</pos>
<shape>sphere</shape>
<size>0.50</size>
<color>1 0 0</color>
</model:SimpleSolid>
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:
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!
|
|
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.
