PEIS Home Simulator - Örebro universitet

Examensarbete 20 poäng D-nivå
PEIS Home Simulator
Reg.kod: Oru-Te-EXA089-D100/06
Jan Larsson
Datamagisterprogrammet 160 p
Örebro vårterminen 2007
Supervisor: Alessandro Saffiotti
Examinator: Mathias Broxvall
Örebro universitet
Institutionen för teknik
701 82 Örebro
Örebro University
Department of technology
SE-701 82 Örebro, Sweden

PEIS Home Simulator 26 May 2007
Abstract
This is a report for a project done on an assignment by the The AASS Mobile Robotics Lab at
Örebro University in the spring of 2007.
The intended reader should have some experience with programming.
The goal of this project was to develop a 3D simulator for an apartment built by AASS called the
“PEIS Home”. In the home there are robots and various other devices, sensors like cameras
mounted in the ceiling.
Sammanfattning
Det här en rapport för ett projekt gjort på uppdrag utav AASS Mobile Robotics Lab vid Örebro
Universitet våren 2007.
Läsaren bör ha någon erfarenhet av programmering.
Målet med det här projektet var att utveckla en 3D simulator för en lägenhet byggd av AASS kallad
”PEIS Home”. I hemmet finns det robotar och diverse andra apparater, sensorer såsom kameror
monterade i taket.
1

Contents
ABSTRACT.......................................................................................................................................................................1
SAMMANFATTNING .....................................................................................................................................................1
CONTENTS.......................................................................................................................................................................2
ACKNOWLEDGEMENTS..............................................................................................................................................4
1 INTRODUCTION.............................................................................................................................................5
1.1 CONTEXT .............................................................................................................................................................5
1.1.1 PEIS............................................................................................................................................................5
1.1.2 PEIS Ecology..............................................................................................................................................5
1.1.3 The PEIS Home...........................................................................................................................................5
1.2 MOTIVATION........................................................................................................................................................6
1.3 ORIGINAL OBJECTIVES .........................................................................................................................................7
2 THE PLAYER PROJECT................................................................................................................................8
2.1 PLAYER................................................................................................................................................................8
2.2 STAGE ..................................................................................................................................................................9
2.3 GAZEBO ...............................................................................................................................................................9
2.3.1 World files...................................................................................................................................................9
2.3.2 Models ......................................................................................................................................................10
2.4 WHY GAZEBO ....................................................................................................................................................11
2.4.1 Alternatives...............................................................................................................................................11
3 SIMULATION ENVIRONMENT .................................................................................................................12
3.1 HOME.................................................................................................................................................................12
3.1.1 Floor .........................................................................................................................................................12
3.1.2 Walls .........................................................................................................................................................13
3.1.3 Windows....................................................................................................................................................14
3.1.4 Fake window.............................................................................................................................................15
3.1.5 Kitchen......................................................................................................................................................16
3.2 FURNITURE ........................................................................................................................................................19
3.2.1 Bed............................................................................................................................................................19
3.2.2 Bookcase...................................................................................................................................................20
3.2.3 Chair.........................................................................................................................................................21
3.2.4 Table .........................................................................................................................................................21
3.2.5 Sofa ...........................................................................................................................................................22
3.2.6 Table with Shelves ....................................................................................................................................22
3.2.7 Wall cabinet..............................................................................................................................................23
3.3 PROBLEMS..........................................................................................................................................................23
4 STATIC SENSORS.........................................................................................................................................25
4.1 CEILING CAMERAS .............................................................................................................................................25
4.2 STEREO CAMERA ...............................................................................................................................................27
4.3 PROBLEMS..........................................................................................................................................................28
5 ROBOTS ..........................................................................................................................................................29
5.1 PEOPLEBOT........................................................................................................................................................29
5.2 FRIDGE...............................................................................................................................................................31
5.3 MANIPULATOR...................................................................................................................................................32
5.4 PROBLEMS..........................................................................................................................................................34
6 OVERALL VIEW ...........................................................................................................................................35
7 CONCLUSIONS..............................................................................................................................................37
7.1 ACHIEVED OBJECTIVES......................................................................................................................................37
7.2 LIMITATIONS AND PROBLEMS ............................................................................................................................38
2

7.2.1 Camera movement ....................................................................................................................................38
7.2.2 Modelling..................................................................................................................................................38
7.2.3 Resetting models .......................................................................................................................................38
7.2.4 Attaching devices to GroundPlane ...........................................................................................................38
7.2.5 Lighting model..........................................................................................................................................38
7.3 FUTURE EXTENSIONS..........................................................................................................................................39
7.3.1 Improvements............................................................................................................................................39
7.3.2 Adding features.........................................................................................................................................39
8 REFERENCES ................................................................................................................................................40
3

Acknowledgements
Thanks go to the following:
Alessandro Saffiotti, supervisor for the exjob, for his guidance and encouragement. Mathias
Broxvall for all his helpful advice during the project. Per Sporrong for his help in the PEIS Home.
Thanks also to everyone else I’ve spoken with at AASS (Applied Autonomous Sensor Systems) for
being helpful and nice in general.
Finally, thanks to the developers of “The Player Project”, especially those creating Gazebo.
4

1 Introduction
1.1 Context
1.1.1 PEIS
PEIS is an abbreviation for “Physically Embedded Intelligent System”. A PEIS is a device capable
of doing some computing and communication. A PEIS may, or may not, be able to affect/sense the
environment through sensors. Using some uniform communications model all PEIS sharing an
environment are able to exchange information and access resources of one another. 1
1.1.2 PEIS Ecology
The idea of a PEIS ecology is to have an environment filled with PEIS and instead of having each
individual component working by itself to perform tasks they work together to achieve goals. En
example scenario:
” Johanna is 76 years old, and she lives in a small house. Soon before she wakes up, her
fridge realizes that there is little milk left and sends a request for a new bottle to the local
store. Johanna’s autonomous trolley goes to the store and fetches the milk together with the
usual newspaper. When Johanna gets out of bed, her motion is detected and the coffee
machine starts to brew coffee. A team of kitchen robots bring bread, butter, jam and coffee
on the table. When Johanna walks out of the bathroom, she finds her breakfast ready. She
hears the cleaning robot that cleans the bathroom after her.” 1
Individual PEIS in the ecology need not be complex. With cooperation complex tasks, difficult for a
single PEIS, can be accomplished by the ecology as a whole.
One way too look at this is that instead of having some sort of intelligent robotic system helping in
an environment, the whole environment is an intelligent robotic system.
1.1.3 The PEIS Home
The PEIS Home is a real world demonstration environment built for research of PEIS technology as
part of the “PEIS-Ecology project” at the AASS Mobile Robotics Lab at Örebro Universitet. It is
built to resemble part of a modern apartment home. It has a kitchen, bedroom and living area. There
is an observation area on one side of the room that is not considered to be an actual part of the home
(not part of the simulated environment). As part of the “PEIS-Ecology project” a uniform
communication and cooperation model was developed. Called the PEIS kernel this model is a runtime
library that acts as middleware for all components in the ecology.
1 PEIS Ecologies: Ambient Intelligence meets Autonomous Robotics, Alessandro Saffiotti & Mathias Broxvall
5

Figure 1.1 Physical Layout of the PEIS Home. Blue coloured area to the right is the observation area. Note that
some measures and wall placements are not entirely correct compared to the real world PEIS Home.
1.2 Motivation
There are several advantages to having a simulator versus performing experiments in the real world.
• It is easy to restart an experiment and try again without a lot of setup time, an initial state is
easy re-established.
• Time can be manipulated; the simulation can be paused or run slower, or faster, than real
time.
• Outside factors which might disturb a real world experiment are avoided. In the real world
things outside the home might cause disturbances.
• Devices and other features which you don’t actually have can be implemented and tested in
the simulator without any real world commitments.
• Purely mechanical errors that can cause failures and imprecise actuations do not occur in
simulation.
• Lighting conditions are controlled in simulation.
6

1.3 Original objectives
The goal of the project was to develop a 3D simulator of the PEIS Home and of all the devices in it.
The simulator would use the Gazebo open-source 3D simulator for which devices and configuration
files specific for the PEIS home were to be developed.
The goal was to be achieved in a series of steps as follows:
1. Get familiar with the Gazebo development environment.
2. Create basic PEIS Home environment for Gazebo simulation (walls and furniture).
3. Add a PeopleBot to the simulation, configured in a way which is as close as possible to the
real PeopleBot used in the PEIS-Home.
4. Add ceiling cameras to the simulation, configured in a way which is as close as possible to
the real ceiling cameras mounted in the PEIS-Home.
5. Add the PEIS-fridge to the simulation. This will involve creating new devices and interfaces
in Gazebo for the fridge.
6. Write the documentation, in the form of: (a) comments in the code, and (b) final X-job
report. The documentation should be such as to allow a next student to take over and
develop the simulator further.
There were also a set of additional objectives defined. These objectives were to be considered and
possible implemented depending on time available given the progress in meeting the main
objectives.
• Adding a stereo camera mounted on the ceiling to the simulation.
• Adding an autonomous moving table (based on an AmigoBot 2 ) to the simulation.
• Adding a manipulator to procure drinks from the fridge.
• Writing a detailed "guide" to include new objects, robots and device in the simulator, to be
used by the next student(s) who will develop the simulator further.
2 http://www.activrobots.com/ROBOTS/amigobot.html
7

2 The Player Project
The Player Project 3 is a project that provides software for use of robotics/sensors and research
thereof. All the software is free, distributed under the GNU General Public License.
2.1 Player
Player is a program for controlling robots which is in widespread use. The Player program is run as
a server, on a robot for example, to which a client can connect to and communicate using TCP
sockets. A client can be written using any language supporting the use of TCP sockets so there is no
dependency on a particular platform. A variety of different hardware and common sensors are
supported in Player.
In Player there are a multitude of abstract interfaces for different devices such as sensors and robots.
Player uses different drivers for different devices but a client to Player only uses the interfaces
which are standardized for general types of devices. This allows great portability for client
programs for different but similar devices. For example; a client program written to move around
robot “A” using a “position” interface can also be used to control a different robot “B” if it supports
the position interface, even if they have entirely different hardware and specs.
You run a Player server with a configuration file, in this configuration file what drivers to load and
the interfaces to provide are specified.
Part of the Player project is two different simulators, Stage and Gazebo. One simulates in 2D the
other in 3D. Simulated devices in either simulator make no use of the device drivers in Player,
instead Gazebo and Stage have their own drivers which Player make use of but they use the same
interfaces as real devices.
This makes it easy to use client programs for real or simulated devices often without any need for
changes. An illustration of how Player works with real devices compared to simulated:
Figure 2.1 A comparison of how Player works with a real robot vs. a Stage/Gazebo simulated one. Image taken
from the Player wiki 4 .
3 http://playerstage.sourceforge.net
4 http://playerstage.sourceforge.net/wiki/Player
8

2.2 Stage
Stage is a simulator for robots, sensors and other objects in 2D environments. It is designed to be
good at simulating systems containing many devices. The simulation models used are simple but
computationally inexpensive which is appropriate when simulating large populations of devices.
Stage is most often used as a plugin module to Player and clients connect to simulated devices in
the same way as their real world counterparts. Stage also provides a C library which can be used by
itself if wished.
2.3 Gazebo
Gazebo is a simulator made as part of the same project as Player and Stage. Like stage it is a
simulator but in 3D instead of only 2D. Gazebo provides a more accurate model of reality than
stage at the price of being more computationally expensive. This makes Gazebo more suited to
simulations with smaller numbers of devices and a need for more realistic behaviours.
Gazebo works with Player in the same way as stage does, allowing client programs written for
Player to control simulated devices. Like Stage, there is also a C library available should one wish
to ignore Player and work directly with Gazebo.
The code language Gazebo is written in is C++. However more advanced features of C++ compared
to C are not used and it is mainly used as “C with classes”.
The graphical components in Gazebo make use of OpenGL 5 . OpenGL stands for Open Graphics
Library and it is an API for developing applications with 3D and/or 2D computer graphics.
To simulate the physical interactions in Gazebo ODE 6 is used. ODE stands for Open Dynamics
Engine that can simulate rigid body dynamics and collision detection.
2.3.1 World files
Gazebo (and stage) use world files to describe simulation environments. These world files are
written in XML. A world file determines how a simulated world looks and what objects are in it.
For everything in the simulation environment there model declarations. A model can be a robot,
sensor or some static feature of the world, such as the ground or a light source.
The following is a model declaration for a PeopleBot robot in XML-code:
robot1
0 0 0.241
0 0 45
5 http://opengl.org
6 http://ode.org/
9

The start and end tags; “” and “”, are the only parts that
are strictly necessary to add the robot to the world. Everything in between these tags is attributes of
the model. For example, the information given by the “” tag specifies the model’s position in
the world and “” how its rotation.
You can attach models to other models in Gazebo. To do this you simple add a model declaration of
the model you want to attach within the model declaration of the model you want to attach to.
Here’s an example were a Canon VCC4 camera is attached to a PeopleBot robot:
robot1
0 0 0.241
0 0 45
camera1
0.044 0.000 0.900
2.3.2 Models
Models are written in C++ code as the rest of Gazebo. There are basically two kinds of models in
Gazebo; Static models and plugin models.
Static models are models that are included with the source code of, and compiled with, Gazebo
itself.
Plugin models are shared objects that can be loaded dynamically at runtime by Gazebo. There are
several advantages to working with plugin models:
• They are easier to build, there’s no need to touch the Gazebo installation files (reconfigure
makefiles etc).
• Debugging is faster. Models can be coded, compiled and tested singularly without recompiling
all of Gazebo.
• Source code can be placed anywhere, there is no need to compile it in any specific place.
Because of this, making models as plugins is the recommended way to make new models. 7
When using a plugin model an extra attribute must be added to the model in the world file. In this
attribute the path to the compiled shared object file should be specified. The tag for this is “plugin”.
7 Gazebo 0.7.0 manual, HOWTO: Creating a Plugin Model
10

2.4 Why Gazebo
Some of the reasoning behind choosing Gazebo as the platform for the PEIS Home Simulator:
• Much of the equipment was already using Player.
• Player is becoming a common standard in robotics, this will make it easier to share the
simulator with other researchers.
• Gazebo is open source.
• Compared to building a simulator from scratch it is relatively easy to develop new models
for Gazebo.
2.4.1 Alternatives
2.4.1.1 Robocup Soccer simulator
An alternative means of creating a simulator of the PEIS Home could have been the Robocup
Soccer simulator. Despite the name, this simulator is intended for general simulations of robots in
3D environments. This simulator could have been used as a base and built upon to provide a
simulation of the PEIS Home. Player support would have had to been added, the various devices of
the PEIS Home implemented and lots of general modifications made. Doing something like this
would most likely have been a much more time consuming task, beyond the scope of a single
student exjob.
2.4.1.2 Blender
Another alternative could have been to use Blender, which is a free 3D computer animation
program. Blender, being a 3D animation program, has tools to model 3D objects that would have
been very useful when modelling the PEIS Home environment and its various components.
There is also a physics engine integrated in Blender but it is currently a bit lacking. Most likely this
would’ve made simulating realistic physical interactions difficult. Blender lacks an internal absolute
time count which is necessary for proper simulation of physics. There also seems to be a lack of
readymade actuators and sensors which could’ve made such difficult to add.
11

3 Simulation Environment
3.1 Home
Here such features such as the walls of the home and kitchen fixtures are described. The following,
except for the floor, were all modelled as separate plugin models for use with Gazebo. To keep
models fixed in the environment they are attached to the floor.
3.1.1 Floor
For the floor of the home in the simulation there existed a suitable model in Gazebo. The name of
the model is “GroundPlane” and it gives a fixed plane in the environment. Besides the attributes
available to all models there are a number of others available for the “GroundPlane” model. The
following are used in the PEIS Home simulator’s world file:
• color: allows one the set a RGB value of the floor (one can also set an alpha value)
• textureFile: takes the file path to a texture to use on the ground
• textureSize: takes a number value to set what size the texture should have on the ground
• surfaceFriction: adjusts the friction of the ground according to a given number, default value
is 11.
Model declaration in the world file:
ground1
1.0 1.0 1.0
11
textures/floor.jpg
0.75 0.75
...
12

3.1.2 Walls
These are the walls, including if desired the ceiling, as they were built for the simulator.
Figure 3.1 The model of the walls, seen in Gazebo from above (ceiling disabled)
Figure 3.2 The walls, seen from the west, north, east and south side (left to right, top to bottom) in Gazebo.
13

As can be seen in the images one wall has two holes, this is where the windows are placed.
A feature that should be mentioned is that at the apparent exit is actually blocked by an invisible
wall. A robot should not be able to leave the home.
The ability to enable or disable the ceiling of the home was also included. This is done by having an
attribute tag which accepts a true/false (0 or 1) value.
The model declaration for the walls in the simulator world file:
plugins/Walls/Walls.so
0 0 0
0
The attribute tag for disabling/enabling the ceiling is “noCeiling”.
3.1.3 Windows
This is the model for the windows.
Figure 3.3 The model as it appears in Gazebo.
It is hard to see in the image but where there should be glass there are transparent parts.
There is a part of the window that divides the glass into a larger and smaller part. This division is
placed on different sides of the two windows in the real PEIS Home. Too avoid having to do a
separate model for this an attribute was added to the window model to allow switching sides of the
division. The tag for this attribute is “” and it accepts a true/false (0/1) value.
Model declaration of one of the windows in the world file:
plugins/Window/Window.so
1.310 4.130 0.7605
14

1
3.1.4 Fake window
There are plans to add a fake window to one of the walls of the real PEIS Home in the future. The
fake window does not yet actually exist in the real home so no facts were available for what
dimensions to use for the model, some appropriate values were arrived upon during programming.
Once the fake window is in the real home the model should be easy to adjust appropriately.
Figure 3.4 The model as it appears in Gazebo.
As seen in the images a texture is in the window. The model has been made to accept a
“” attribute where one could specify a file path to use to use for a texture. In its current
appearance the model more than anything resembles a framed picture
The model declaration in the world file:
plugins/FakeWindow/FakeWindow.so
0 0 90
1.375 0.007 1.000
skyTones.jpg
15

3.1.5 Kitchen
There are a few models making up the kitchen fixtures. Most of it is made of a single big model
making up benches, a sink and the parts in which the spaces for cabinets are built.
Figure 3.5 The model as it appears in Gazebo.
Worth to note is that the larger cabinet space in the model does not exist in the real home, the doors
that would open to that space if it existed are just dummies made for display.
Model declaration in the world file:
plugins/Kitchen/Kitchen.so
0.000 2.210 0
16

3.1.5.1 Cook plates
This is a model intended to represent some cooking plates. They have no functionality and so are
just for looks.
Figure 3.6 The model as it appears in Gazebo.
Model declaration in the world file:
plugins/CookPlates/CookPlates.so
0.285 2.485 0.895
Cabinet doors
This is a model for a door of a cabinet. The model has a joint which allows the door to be pulled
open from where it is positioned.
Figure 3.7 The model as it appears in Gazebo.
To make it possible to switch the sides of the door’s handle and joint placement an attribute has
been added to the model to allow one to specify if it should have a the handle on its left hand side or
not. The tag is “” and it accepts a true/false (0 or 1) value.
Model declaration for one of the doors in the world file (there are three in total):
plugins/CabinetDoor/CabinetDoor.so
0.581 3.307 0.180
0 0 0
1
17

The models together:
Figure 3.8 The kitchen with all models together as it appears in Gazebo.
18

3.2 Furniture
The following pieces of furniture are modelled as plugin models. All the furniture models have their
origin at their lowest point but otherwise centred with respect to the main parts of the model, the
exception to this being the “Table with Shelves” model.
3.2.1 Bed
A simple bed. Loose parts such as pillows and cover are not modelled, only the basic shape.
Figure 3.9 The bed model as it appears in Gazebo.
Model declaration in the world file:
plugins/Bed/Bed.so
0.600 1.070 0
0 0 90
19

3.2.2 Bookcase
This is a basic bookcase with five shelves.
Figure 3.10 The bookcase model as it appears in Gazebo.
Model declaration:
plugins/Bookcase/Bookcase.so
4.200 0.160 0
0 0 90
20

3.2.3 Chair
A basic chair. It has a very rudimentary shape.
Figure 3.11 The chair model as it appears in Gazebo.
Model declaration for one of the chairs in the home (there are two in total):
plugins/Chair/Chair.so
2.000 3.300 0
0 0 0
3.2.4 Table
A low table. There is a shelf space below the table piece and it has four wheels allowing it to be
pushed around easily.
Figure 3.12 The table model as it appears in Gazebo.
The model declaration of the table in the world file:
plugins/LowTable/LowTable.so
3.300 1.700 0
0 0 0
21

3.2.5 Sofa
This is a model of a sofa in the PEIS Home.
Figure 3.13 The sofa model as it appears in Gazebo.
Model declaration in the world file:
plugins/Sofa/Sofa.so
5.500 2.100 0
0 0 180
3.2.6 Table with Shelves
This is model is a wall mounted table and shelves combined.
Figure 3.14 The table/shelf as it appears in Gazebo.
The table in the PEIS home has a part that can be folded down. Because of this there is an attribute,
“, that allows one to specify if the table should be raised or lowered (not shown) in the
simulation, it accepts a true/false (0 or 1) value. During simulation it is locked in place so the
desired position needs to be set in the world file before starting the simulation.
22

The model declaration in the world file:
plugins/TableShelf/TableShelf.so
2.362 3.814 0.7605
0 0 -90
1
3.2.7 Wall cabinet
This is a model of a wall mounted cabinet.
Figure 3.15 The cabinet model as it appears in Gazebo.
The door opens upward and has a transparent glass part in it. The greenish part inside is a shelf.
Model declaration in the world file:
plugins/WallCabinet/WallCabinet.so
0.185 2.610 1.735
0 0 0
3.3 Problems
Fixed models
There does not seem to be any way to code a model such that it will remain fixed in the
environment by itself. The walls and other fixtures needed to be fixed in one place and it was also
decided that some of the furniture should not be possible to move. This was solved by attaching
them to the ground plane in the simulation to which it is possible to attach models like with any
other model and it is always fixed in the environment.
Unnecessary Collision Detection
During development it was discovered that adding the walls to the simulation environment caused
the simulation to slow-down. The walls were attached to the floor and it would appear that the
contact between the walls led to many calculations being performed for the collision detection
between the walls and floor. This was undesired and a way to indicate what objects should perform
collision detection between each other was discovered.
23

To avoid unnecessary computations collisions were disabled between non-device objects that were
intended to be fixed in place. This includes the floor, walls, windows, all the parts making up the
kitchen area except for the cabinet doors and all furniture except for the small, wheeled table and
the chairs.
One drawback to this is that the models currently intended to be fixed in the environment cannot be
placed by themselves but must be attached to the ground. Since collisions are disabled between
these models and the floor they would fall right through it.
Attaching models
There is a problem with attaching models to other models that are complex in the sense that they
consist of many shapes put together. Models like the walls or the main kitchen model. Attaching
models to these can result in unstable physic behaviours, such as attached models seeming to
vibrate or shake and can in some cases cause the simulator to crash. During development this was
very clear when at first the cabinet doors were attached to the main kitchen model, the simulator
would always crash when anything collided with the doors. This was solved by instead of attaching
models to the walls or kitchen model directly they were instead attached to the GroundPlane.
Because of this solution however there is an inconvenience in that should the kitchen or walls
model moved models that should be placed on them need to be moved individually to correct
positions (the cabinet doors for instance).
24

4 Static Sensors
These are sensors placed in environment but not attached to any robot.
4.1 Ceiling cameras
There are five web cameras mounted in the ceiling of PEIS Home, they are however intended to be
replaced by new cameras. Currently there is one of these new cameras in the home. In the
simulation five cameras have been added the first of which is placed as the new camera in the real
home, the others are simply placed in a line. Once the camera placement is finalized in the real
home the cameras in the simulation can be moved to appropriate positions.
In the real PEIS home the cameras are not accessed through player but to keep things simple in the
simulator a camera model supporting the Player camera interface was used.
There is a generic camera model for a monocular camera in Gazebo, based on the source code of
this model a plugin model was made instead. The modifications to the original code consisted of
changing the physical shape of the camera and making the origin of the model in the middle of the
“lens” part.
The change in the models origin was made to make placement from real world measurements
easier. In the real home it is easier to measure the position and orientation of the camera at the lens.
Thus with a measure of where a camera lens is located in the real home one can easily determine
coordinates for a simulated camera.
Figure 4.1 The model of the camera as it appears in Gazebo.
25

Images from the camera in the simulation to its real world counterpart (there was some work being
done in the PEIS Home at the time the image was taken):
Figure 4.2 An image comparison from the viewpoints of a real world camera and a simulated one.
Model declaration of one of the cameras in the world file:
plugins/SmallCam/SmallCam.so
ceilingcam1
6.040 2.140 2.455
0 45 180
0.100
10.000
0
1
45
320 240
Seen in the model declaration a number of attributes are available for the camera model.
The attributes “nearClip/farClip” sets the near and far clipping distances of the camera view. With
the above values objects nearer than 0.100 m and further away then 10 m cannot be seen.
The “gravity” attribute accepts a true/false value specifying if the camera should be affected by
gravity. The camera is not attached to any other model so this was set to false to keep the camera in
its place. This means that the camera can still be moved by contact with some other object in the
simulation but since they are placed out of reach at ceiling height this was not deemed to be a
problem.
“updateRate“ sets how often the camera view should be updated per simulated second, the number
of frames per second. Currently this is set low, only one frame per second, because of some
26

performance issues.
The “hfov” attribute sets the horizontal field of view of the camera, the value is in degrees.
Lastly, the “imageSize” values set the size, or resolution, of the camera image.
Player Interfaces
The “camera interface” in player is used to access the camera.
4.2 Stereo Camera
There are plans to add a stereo camera to the real PEIS Home. There exists a model for this in
Gazebo called “StereoHead” and so it was used in the simulator world file.
Figure 4.3 Stereo camera model as it appears in Gazebo.
The camera is placed in the middle of the ceiling looking downwards into the home.
Images from the stereo camera in the PEIS Home simulation:
Figure 4.4 Disparity image and normal image from a simulated stereo camera.
The left image is a disparity image generated by combining images from both lenses. The other is
an image from only one of the camera lenses.
27

Model declaration in the world file:
stereoCam1
3.000 2.210 2.455
0 90 90
0.100
10.000
0
1
87
0.200
320 240
All attributes except one is recognizable from the earlier camera model (see above). The attribute
“baseline” sets how far the distance should be between the two camera lenses on the stereo camera.
Player Interfaces
The “stereo interface” in Player is supported.
4.3 Problems
Multiple Cameras
During development it was discovered that adding several cameras greatly affected the performance
of the simulation speed negatively. Having the five ceiling cameras all using moderately high
resolution and update rate slowed the simulation speed to a crawl. To somewhat remedy this the
update rate of the cameras are set very low and the image resolution is also lower then the real
world camera counterparts. Should one wish to have these closer to the real world camera
specifications a more powerful computer (mainly in the graphics department) than the one currently
used to run Gazebo and the PEIS Home simulator is needed unless having the simulation run slowly
is acceptable.
28

5 Robots
Here are the models for the simulation that can be considered to be robotic systems.
5.1 PeopleBot
In the PEIS Home there is a ActiveMedia PeopleBot robot 8 . This robot has 2 wheels to move
around, 2 sonar rings, one placed low going all the way around the robot and one facing forwards
and mounted high. Besides this the PeopleBot used in the PEIS Home is equipped with a
pan/tilt/zoom camera, a laser rangefinder, a gripper and also a top mounted camera with a 360 o fov.
In Gazebo there is a PeopleBot model. This model had the lower sonar ring as the real PeopleBot
but no other sensors, including the front facing upper sonar ring. The model however also turned
out to be an older design then the one currently used in the real PEIS Home so instead a plugin
model was created based on the source code for the existing PeopleBot model. The older model was
a little higher then the PeopleBot in the PEIS home and the adjustments from the original Gazebo
model consisted mainly of changing the physical dimensions of the model.
The modified PeopleBot model, without any additional components mounted:
Figure 5.1 The new PeopleBot model as it appears in Gazebo
To add the front facing upper sonar ring to the PeopleBot in the simulation the code for the sonar on
the robot was taken and adapted to make a plugin model. Since it was not necessary this plugin
model was not given a physical body. It is attached to the PeopleBot in the simulation to give it the
same sonar cover as the real robot. The sonar model was called “FrontSonars”.
There are models in Gazebo for the specific pan/tilt/zoom camera, a Canon VCC4, and laser
rangefinder, SickLMS200, but models for the gripper and 360 o fov camera does not exist in
Gazebo. Adding the Canon camera and laser to the simulated robot was deemed to be sufficient for
this project.
The robot with laser and camera models added:
Figure 5.2 The new PeopleBot model with sensors attached.
8 http://www.activrobots.com/ROBOTS/peoplebot.html
29

Model declaration in the world file, including all the extra sensors:
plugins/PeopleBotP/PeopleBotP.so
robot1
1.5 2.7 0.241
plugins/FrontSonars/FrontSonars.so
sonar1
-0.050 0.000 0.835
laser1
0.005 0.000 0.000
camera1
0.044 0.000 0.695
0.010
Player Interfaces
The robot model provides the following Player interfaces:
position (for moving and reading position)
power (for reading battery levels)
sonar ( sonar information, the lower ring )
The sonar model (upper, front facing sonar) provides a “sonar interface”.
The Camera VCC4 model supports the “camera” and “ptz” (pan/tilt/zoom controls for the camera)
interfaces.
Player Interfaces
The laser provides the Player laser and fiducial interfaces.
30

5.2 Fridge
There is a fridge in the real PEIS Home Ecology which has can opened remotely using the PEIS
kernel, a plugin model for this fridge was made. This makes no use of any Player interface but like
with the ceiling cameras the plugin model was made to use a Player compatible interface for
simplicity’s sake. There are also some sensors and other things in the real fridge but those did not
need to be included in the simulation.
Fridge with door closed:
Figure 5.3 Fridge model, with door closed, as it appears in Gazebo.
Fridge with door opened:
Figure 5.4 Fridge model, with door opened, as it appears in Gazebo.
There are two shelves inside the fridge model and two in the door. The real world fridge had one
more shelf but it is currently not in the model to allow some room for a manipulator (see below).
The fridge model uses an “actarray interface”, an interface intended for arrays of actuators. In the
case of the fridge there is really only one moveable part so it is like controlling an array of only one
actuator. The fridge is made to accept only position commands of numeric value 0 or 1 to the
actarray, where 0 and 1 closes and opens the door respectively.
Model declaration of the fridge in the world file:
plugins/Fridge/Fridge.so
fridge
0.350 2.675 0.000
...
31

Player Interfaces
The fridge provides an actarray interface.
5.3 Manipulator
A plugin model of a robotic arm for mounting inside the fridge has been built. The arm is controlled
using an actarray interface as that for the fridge.
The is the robotic arm in its initial state:
Figure 5.5 Manipulator model in its initial state in Gazebo.
As seen in the picture the different parts of the arm have distinctly different colours. This was to
ease the identification of different parts during development. Should a more realistic look be desired
the model can easily be adjusted to have some other colours. The smaller parts in the lower part of
the model make up a gripper, they are actually placed a bit out in the air.
The arm is simply built only having two degrees of freedom. One part extends outwards from the
main fitting:
side
top
Figure 5.6 Manipulator model in Gazebo horizontally extended.
On the extended part the vertical portion can slide out:
Side
Top
Figure 5.7 Manipulator model horizontally extended and gripper section moved out.
32

One part can move down vertically:
Figure 5.8 Manipulator model horizontally and vertically extended with gripper moved out.
In the image above when the arm is reaching downwards it is not connected all the way. Making a
model able to actually extend in such a way that the actual size of a part changed would’ve been
difficult. Such small departures from realism, as in the images above, were deemed to be
acceptable.
The gripper part at the end that can be closed/opened.
Each of the movements above are possibly by commanding four different actuators in an actarray
interface. You can either command them to move to a position or with a certain speed.
Model declaration in the world file, with the manipulator attached to the fridge:
plugins/Fridge/Fridge.so
fridge
0.350 2.675 0.000
plugins/Manipulator/Manipulator.so
fridgeArm
0.020 0.150 0.790
33

Player Interfaces
The manipulator model provides an actarray interface.
5.4 Problems
Gripper Interface
There is a gripper interface in Player and Gazebo. Initially this interface was intended to be used to
control the fridge The idea was to use the commands for opening/closing a gripper to open/close the
fridge door. However there seem to be some fault in how commands to a gripper on the Gazebo
side are handled so currently a gripper cannot be controlled using Player. This was solved by using
an actarray interface instead after using such an interface successfully with the manipulator model.
Actarray Interface
Initially when using an actarray interface for the manipulator model there was a problem were
plugin models using it would not load and Gazebo would fail with an error. There was however no
problem when compiling a model with an actarray interface so it was theorized that maybe the
problem was somehow with plugin models using such an interface.
The test if a static model might be able to handle an actarray interface one of the models included in
the Gazebo source code was modified to have one. Gazebo was then recompiled and when testing
the model it did indeed load without an error. The idea then was to make the manipulator a static
model.
Adding a static model entailed considerably more effort then making a plugin model. Instead of
modifying makefiles directly they must be generated using a tool called “automake” which uses a
configuration file. Once this was done however it turned out that reconfiguring the makefiles had
enabled actarray interfaces to work with plugin models too. So at the end the manipulator model
ended up being a plugin model.
34

6 Overall View
In this section some images from the real and the simulated home are shown.
First, an image of the complete PEIS Home in the simulator, seen from above:
Figure 6.1 The simulated PEIS Home seen from above.
35

Some images showing comparison between the real Home and the simulated one:
Figure 6.2 Outside the bedroom area, seen in the real home (left) and the simulated (right).
Figure 6.3 Living room area, seen in the real home (left) and the simulated (right).
Figure 6.4 The kitchen area, seen in the real home (left) and the simulated (right).
36

7 Conclusions
7.1 Achieved Objectives
Looking back at the starting objectives the main objectives are achieved with some exceptions.
1. Get familiar with the Gazebo development environment.
At the start of the project, a few weeks were spent installing and playing around with Gazebo,
various world examples were tried and some basic models built.
2. Create basic PEIS Home environment for Gazebo simulation (walls and furniture).
Models have been created for the Walls and furniture (also the kitchen). A world file using all
the PEIS Home simulator models has been made.
3. Add a PeopleBot to the simulation, configured in a way which is as close as possible to the
real PeopleBot used in the PEIS-Home.
A model for the PeopleBot in the PEIS Home was built and added to the simulation world
together with some sensors. Some devices, such as a gripper and 360 o fov camera that exist on
the real robot have not been added.
4. Add ceiling cameras to the simulation, configured in a way which is as close as possible to
the real ceiling cameras mounted in the PEIS-Home.
A camera model has been created and added to the simulated world. Unlike the real camera, it
is accessed using a Player interface. Because of some performance issues lesser image
resolutions and lower update rates than the real cameras have are used. See the Problems
subsection under Static Sensors in this report.
5. Add the PEIS-fridge to the simulation. This will involve creating new devices and
interfaces in Gazebo for the fridge.
A model for the fridge has been created, accessible through Player.
6. Write the documentation, in the form of: (a) comments in the code, and (b) final X-job
report. The documentation should be such as to allow a next student to take over and
develop the simulator further.
This final report is part of the final objective and at the time of writing the code could use some
more commenting. Given this the final objective is not yet fully achieved.
Looking at the optional objectives, two have been achieved, these are:
• Adding a stereo camera mounted on the ceiling to the simulation.
Using a model that existed in Gazebo a stereo camera has been added to the simulation.
• Adding a manipulator to procure drinks from the fridge.
A simple gripper model has been created for use with the fridge.
37

7.2 Limitations and Problems
In this section some problems/limitations in the current version of Gazebo are described.
7.2.1 Camera movement
To move an observer camera in the graphical interface of Gazebo you click and drag with your
mouse in the observation window. The movement is actually based on what surface the mouse
pointer was over. The camera is dragged in relation to the surface touched. This can become
problematic should there be an obstacle in the way of the camera. You cannot for example zoom
past an object. This is especially inconvenient should the camera end up outside any of the walls or
above the ceiling of the home.
7.2.2 Modelling
In the current version of Gazebo there is no modelling tool to assist in the creation of models. A
physical model is built by specifying in code what geometric shapes it should consist of and where
they should be placed. The shapes one can use are mainly cubes, cylinder and spheres. It is possible
to make an advanced 3D model in a modelling tool of some sort and use as a skin for a simple
model to give it a detailed appearance. Only the simple geometric shapes the model consists of will
be used for the physical interactions though. This made the sink part particularly challenging to
make, as the round sides had to be built using cube shapes.
7.2.3 Resetting models
Models consisting of several parts bound together with one or more joints cannot be returned to
their initial state when resetting the simulation with the Gazebo interface. The main parts, the parts
that cannot move relative to one another, of a model will return to its starting position but any part
attached with a joint will maintain its position at the reset relative to the main part.
7.2.4 Attaching devices to GroundPlane
If a device providing one or more interfaces is attached to a “GroundPlane” the interfaces will not
be shown in the “simulation controls” panel if running Gazebo with a GUI. The devices can
however be accessed through player or some other client using the Gazebo library.
7.2.5 Lighting model
For the graphical parts of Gazebo mostly standard OpenGL is used. There are several limitations in
how light affects surfaces in the simulation. Most notably, objects don’t cast shadows on other
objects and they do not reflect light onto surrounding surfaces. How a surface appears depends
entirely on how it is facing relative to light sources, regardless of intervening surfaces, and what
colour properties those light sources and that surface has.
38

7.3 Future extensions
7.3.1 Improvements
7.3.1.1 Non-player accessibility
One possible improvement given more time could be to modify some of the models to work more
like the ones in the real home. Neither the existing cameras nor the fridge in the PEIS home
simulator make use of Player. If these were made to more accurately simulate how they are
accessed in the real home less software used currently will have to be adapted for use with the
simulator.
7.3.2 Adding features
7.3.2.1 Dynamically adding models
In Gazebo there is a model called “Factory”. This model has no physical shape in the simulation,
what it does is to take model declarations as text strings and then those models are added to the
simulation as if they’d been in the world file. This model can be accessed using a “speech” interface
in Player if not using the Gazebo library directly.
Using this program could be written to interactively add objects to the simulated world during
runtime. This could be a lot more user friendly then having to stop a simulation and editing world
files whenever one wants to add an object. The current “Factory” model cannot be used to remove
models from the world.
7.3.2.2 Moving objects
Gazebo has a model called “TruthWidget” without a physical body. The model provides an
interface which can be used to get its pose (position and rotation) but also set its pose. Having no
physical body itself it is meant to be attached to other models, thereby allowing them the
functionalities of the “TruthWidget”.
Using this, client programs can be written that allows moving objects around in the simulation even
if they possess no means of locomotion by themselves. This could add some useful interactivity to
anyone working with the PEIS Home simulator.
39

8 References
1) A. Saffiotti and M. Broxvall. PEIS Ecologies: Ambient Intelligence meets Autonomous
Robotics. Proc. of the sOc-EUSAI conference on Smart Objects and Ambient Intelligence.
Grenoble, France, October 2005.
2) Information on the AmigoBot.
http://www.activrobots.com/ROBOTS/amigobot.html
3) The Player Project homepage.
http://playerstage.sourceforge.net
4) The Player project information page for Player.
http://playerstage.sourceforge.net/wiki/Player
5) Information about OpenGL.
http://opengl.org
6) Information about ODE.
http://ode.org/
7) Gazebo 0.7.0 manual, HOWTO: Creating a Plugin Model
http://playerstage.sourceforge.net/doc/Gazebo-manual-0.7.0-html/plugin_models.html
8) Information on the PeopleBot
http://www.activrobots.com/ROBOTS/peoplebot.html
Websites last checked 2007-06-11.
40