Internal Report of 1st Month
Robotics Laboratory at Heriot-Watt University
Bridging the Gap between Webots and e-puck Robots
Towards an Improved Compatibility
Micael Santos Couceiro
SFRH/BD/73382/2010
Institute of Systems and Robotics
University of Coimbra
Internal Report
Title: “Bridging the Gap between Webots and e-puck Robots - Towards an Improved Compatibility”
Ph.D. studies of Micael Santos Couceiro
(SFRH/BD/73382/2010) - Doctoral Program in Electrical Engineering and Computers - University of
Coimbra.
1. Table of Contents
1.
Table of Contents ..................................................................................................................................................... 3
2.
Motivation ................................................................................................................................................................ 4
3.
Programming e-pucks with Webots ......................................................................................................................... 5
4.
3.1.
e-puck Programming Architecture .................................................................................................................... 6
3.2.
Proposed e-puck Programming Architecture .................................................................................................... 9
Improving e-puck compatibility with Webots ....................................................................................................... 12
4.1.
Robot ID .......................................................................................................................................................... 12
4.2.
Debug .............................................................................................................................................................. 13
4.3.
Microphone...................................................................................................................................................... 13
4.4.
Speaker ............................................................................................................................................................ 15
4.5.
Communication ............................................................................................................................................... 18
5.
Conclusions ............................................................................................................................................................ 23
6.
References .............................................................................................................................................................. 24
2. Motivation
Simulation experiments play an essential role on robotics. One may not only assess the performance of new algorithms,
especially when those are difficult to be analytically characterized, but also overcome the cost inherent to robotics
development (Reckhaus, Hochgeschwender, Paulus, Shakhimardanov, & Kraetzschmar, 2010). However, the
usefulness of a simulation environment grows with the consistency between simulation and real world results. In
robotics, such consistency needs to be handled by the adequate implementation of several real world features such as
sensor noise, robot dimensions and actuators nonlinearities. Nevertheless, when one goes from single robot applications
to cooperative multi-robot systems (MRS) the level of complexity significantly grows. Besides the previously described
phenomena, one needs to consider the several mechanisms that may foster such cooperation as, naturally, the
communication between robots (Parker, 2008).
One of the most well-known and educationally-fitted tools is the Webots mobile robot simulation software
developed by Cyberbotics (Michel, 2004). The Webots robot simulation is a commercial software for fast prototyping
and simulation of mobile robots which has developed tight links with one of the robotic platforms most widely used on
both educational and research applications - the e-puck robot (Mondada, et al., 2009). Although the e-puck platform
was originally developed for teaching purposes, the number of sensor it possesses, its low-cost and size makes it an
ideal tool for MRS experiments such as swarm robotics. Moreover, all e-puck hardware and software is fully open
source, providing low level access to every electronic device and offering unlimited extension possibilities.
Unfortunately, despite the significant compatibility between Webots environment and e-puck platforms, some
functionalities still remain to be implemented to fully access e-puck’s capabilities. Namely, three important
functionalities are still worth being implemented: access to the microphone, the speaker and, most importantly,
Bluetooth inter-robot communication. The microphone can extend e-puck’s sensing capabilities on both real world and
simulations toward optimization problems, e.g., find audio sources emulating victims in a search-and-rescue (SaR)
scenarios. Combining the speaker with the microphones may allow to create a communication network with the ability
to detect the direction of teammates or promote human-robot interaction. At last, and as most MRS require, the
Bluetooth radio link allows inter-robot explicit communication necessary to share information and bring forth the
necessary cooperation to fulfil a given task.
Hence, the major motivation of this internal report is to bridge the gap between both simulation and real world
robotic applications using Webots and e-puck platforms. At first, a general overview of Webots’ architecture will be
presented, thus describing the programming process and dependencies regarding virtual and real e-puck platforms.
Such architecture will be optimized in such a way to broaden the range of features and control over the platforms.
Afterwards, the discrepancies between the virtual and real e-pucks are mitigated by overcoming the previously
described limitations. Moreover, other additional features such as the debug possibility for real platforms and direct
access to a unique robot identifier are also implemented to support the development of real applications. To evaluate
the consistency of Webots extension as the e-puck’s most suited simulation platform, both simulated and real
experiments are carried out throughout this report and results are closely compared regarding sensing capabilities and
inter-robot communication.
3. Programming e-pucks with Webots
The correspondence between simulation and reality has been highly discussed in the literature and several simulation
environments have been proposed such as the Virtual Experimentation Platform Coppelia Robotics (V-REP) (Freese,
Singh, Ozaki, & Matsuhira, 2010) and the well-known Willow Garage Robotic Operating System (ROS) (Quigley, et
al., 2009). Despite these recent accomplishments, the environment that still presents a higher compatibility between
real and virtual e-pucks is still Webots. This is mainly due to the close relation between e-puck and the education field
that is the main target of Cyberbotics. Hence, this is frequently seen as a win-win relationship to train beginners to use
Webots and consequently increase e-puck’s utilization (and so the e-puck community). In fact, the number of papers
using both Webots and e-puck real robots greatly exceed any other simulator+platform combo. For instance, Rohrer’s
report present a full curriculum describing the link between the e-puck and Webots, going from a totally beginner
audience to expert skilled programmers (Rohrer, 2008).
The e-puck depicted on Fig. 1 was officially presented for the first time in a scientific paper on 2009 (Mondada, et
al., 2009) with a project that started with the Ecole Polytechnique Fédérale de Lausanne as collaboration between the
Autonomous Systems Lab, the Swarm-Intelligent Systems group and the Laboratory of Intelligent System. Since then,
many other works have been benefiting from the e-puck platform due to its price/features qualities (Table 1).
[UART2]
[UART1]
Figure 1. The e-puck robot platform.
As it is possible to see on Table 1, the basic configuration provides a high level of applicability with a large number
of sensors and acting capabilities. Moreover, its low-cost and small desktop size, together with the open source feature,
makes the e-puck as one of the most widely used robotic platforms in laboratory context. Although it still presents some
limitations, those may be overcome by adding turrets (extension boards) for an extra cost that may endow the robots
with CPU processing power (Linux Gumstix Overo turret or Fly-Vision omnidirectional vision turret). As those turrets
greatly increase e-puck’s cost and the basic configuration is still the most acquired one, we will only focus on that one.
Table 1. Main e-pucks features (basic configuration).
Features
Small size
Description
∅ 70 𝑚𝑚
Low cost
≈ 230 €
High battery autonomy
≈ 3 hours
Available wireless Communication Bluetooth (UART1)
Available wired Communication
RS232 (UART2)
High Sensing capabilities
8 infrared proximity sensors
1 3D accelerometer
1 640 × 480 CMOS colour camera
3 microphones
2 1000 𝑠𝑡𝑒𝑝𝑠/𝑟𝑒𝑣 stepper motors
1 Speaker
8 red light emitting diodes (LED)
Omnidirectional vision
Ground sensors
Colour LED communication
ZigBee communication
Magnetic wheels
Linux extension
High actuation capabilities
High expansion Capabilities
Programming e-pucks by using Webots has been consensual in most research using e-puck robotic platforms. Either
more directed for education purposes as the work of (Guyot, Heiniger, Michel, & Rohrer, 2011) or all the way to swarm
applications as (Cianci, Raemy, Pugh, & Martinoli, 2006), it has been consensual that the combination between Webots
and e-pucks is appropriated to the further development of robotic applications. One of the main reasons regarding such
consensus resides in the compatibility between both simulation and real worlds. Nevertheless, such compatibility is
still an on-going work and, therefore, a deeper contribution from the community is required.
Yet, to contribute one first needs to understand what is developed so far and how Webots e-puck architecture works.
3.1. e-puck Programming Architecture
In brief, in Webots environment, the Webots application and each robot C-controller are executed in distinct operating
system processes. In other words, the number of processes in memory will be, in general, the same as the number of
simulated robots plus one (Webots application). It is interesting to note that a single C-controller may be used by several
robots from the same virtual world. Different input arguments, or simply different identifications, may be used to divide
the processes by the corresponding agents. Although this seems quite easy to perform under Webots environment, the
only way to have a closely similar response from real robots is through remote control. This may be activated by first
uploading e-puck main firmware at e-puck official website1 (e.g., sercom firmware).
The remote-control tool allows to monitor and remote control a real e-puck robot from Webots controller program
over Bluetooth. In this case, the control program runs on the computer, but instead of sending commands to and reading
sensor data from the simulated robot, it sends commands to and reads sensor data from the real robot. Although this
strategy works great using a very small number of robots, it is totally impracticable as the number of robots increases.
Not only is the Bluetooth communication limited to piconets (networks) of 7 robots, but processing the algorithms of
multiple cooperative robots in a centralized fashion is completely opposite to the nature of MRS and, especially, swarm
robotics.
Therefore, only one choice is left – the cross-compilation tool. Developing a cross-compilation system allows to
compile the Webots controller for the embedded processor of the real robot. Hence, the source code for the Webots
1
http://www.e-puck.org/
virtual robot is executed on the real robot itself, and there is no need to have a permanent CPU connection with the
robot as with the remote control system. In brief, the idea is to generate a machine code HEX-file from the same C
program as the one in simulation and to upload it on the e-puck in a transparent fashion for the users. Webots then
includes the source code, and eventually low level assembly files (ASM), of robots Application Programming Interface
(API) being compatible for e-puck and the Hemisson robots. Therefore, in the case of e-puck robots, the crosscompilation system requires the source code necessary to compile the e-puck firmware. This requires rewriting many
of the Webots include files to be specific to e-puck platform. In other words, one may need to write some C-source
files to be used as a replacement for the Webots API, but running on the real e-puck. Unfortunately, such requirement
from the cross-compatibility tool turns out to make it hard to access all e-puck features. Table 2 summarizes the
functionalities one may access using both cross-compatibility and remote-control tools:
Table 2. Currently implemented e-puck functionalities (adapted from www.e-puck.org).
Features
Remote-Control Cross-Compilation
Distance Sensor
Light Sensor
LED
Wheels
Camera
Accelerometer
Bluetooth
Speaker
Microphone
Available
Not available
Available only between CPU and robot (i.e., it does not provide inter-robot Bluetooth communication)
In brief, this works aims on transforming the “Not available” signs
from cross-compilation into “Available”
ones . But before that, to better understand Webot and e-pucks compatibility, let us identify each API as it follows:
 Webots API
 e-puck API
The first one is provided by regular C-header files located in (WEBOTS-HOME)\include\controller\c\webots.
These header files must be included as any other regular C-library. A call to the initialization function wb_robot_init
is required before any other C-function call. This function initializes the communication between the controller and
Webots. Usually, the highest level control code is placed inside a for or a while loop. Within that loop there is a call to
the wb_robot_step function that synchronizes the controller’s data with the simulator with a control step
TIME_STEP. This function needs to be present in every controller and it must be called at regular intervals, being
usually placed in the main loop. This is a highly important functionality as it describes the duration of the control steps,
i.e., the function wb_robot_step is used as a sort of delay of each loop cycle. Most importantly, this allows to
synchronize all robot’s devices (e.g., sensors). The update delay of devices is chosen to be similar to the control step
(TIME_STEP) and hence the device is updated at every wb_robot_step. If, for instance, the update delay is chosen
to be twice the control step, then the device data will be updated every two wb_robot_step. Such functionality may be
used to simulate a slow device or avoid computing irrelevant data. In other words, a larger update delay can also speed
up experiments, especially for CPU intensive devices like the Camera. Webots also allows to enable or disable devices
at any time using the corresponding wb_X_enable and wb_X_disable functions, in which X specifies the name of a
device (e.g., X= microphone).
The e-puck API, on the other hand, is located in (WEBOTS-HOME)\transfer\e-puck. However, this API may be
mainly divided into two directories:
 (WEBOTS-HOME)\transfer\e-puck\library
 (WEBOTS-HOME)\transfer\e-puck\libepuck\include\webots
For e-puck programmers the first one must be easy to recognize. It basically corresponds to e-puck’s library
containing all files to actuate and read the sensors of the robots. Although Webots already comes with e-pucks library,
it is advised to download the most recent one at e-puck official website.
The second directory is of high relevance to this work as it is here where the bridge between simulation and real epuck’s programming is made and it is here in which this work will mainly focus. This directory needs to have all
libraries used on the main C-file developed on Webots. For instance, if one wishes to use the microphone on Webots,
the library microphone.h on (WEBOTS-HOME)\include\controller\c\webots should be added. Nevertheless, crosscompiling this code will return an error as this library is not located on e-puck API. Therefore, a corresponding library
microphone.h needs to be placed on (WEBOTS-HOME)\transfer\e-puck\libepuck\include\webots. As an example,
while the wb_robot_init is used on Webots API to initialize the communication between the controller and Webots,
this same function relays to e-puck firmware function to initialize most e-puck’s devices (e.g., e_init_port,
e_init_motors, among others).
And it is here where the most important file that aggregates both directories altogether comes: the e-puck’s firmware
libepuck.c located on (WEBOTS-HOME)\transfer\e-puck\libepuck. For e-puck programmers, we could say that its
equivalent is the firmware.c from e-puck official website. In fact, if one wishes to extend Webots e-puck
functionalities, it is here that most of the programming will be carried out. Nevertheless, to do so, one needs to first
change Webots architecture. Currently, Webots cross-compiling architecture may be illustrated as Fig. 2 shows.
e-puck API
Firmware
libepuck.c
External compilation
(runs Makefile)
Generates
libepuck.a
C-Controller(s)
your_code_1.c
…
your_code_n.c
Webots API
Webots cross-compilation
(runs Makefile.include)
Generates
Machine code(s)
your_code_1.hex
…
your_code_n.hex
Figure 2. Webots e-puck programming architecture.
As one may observe, when running cross-compilation on Webots, the C-code will be compiled and linked to the
pre-compiled firmware libepuck.a that calls e-puck API. That is to say, one needs to download a compiler and first run
the Makefile on (WEBOTS-HOME)\transfer\e-puck\libepuck. All development of this work was carried out on
Windows in which several possibilities to perform this are available. The most well-known are the gnuwin322 (GNU
Make for Windows) and the MinGW3. As Webots already comes with this last compiler located on (WEBOTSHOME)\mingw this may be the most adequate alternative for those that wants to compile e-puck firmware and ignore
section 3.2. Nevertheless, this is not advised as many limitations were encountered, namely regarding audio codecs (cf.,
section 4.4) pre-compiling the firmware and posteriorly link it to Webots C-code. However, some few tips are left for
those who do not wish to change Webots e-puck programming architecture.
First one will be to add (WEBOTS-HOME)\mingw to the PATH system variable. To do so, just right click on
Computer, go to Properties, click on Advanced System Properties from the context menu, and then Environment
2
3
http://gnuwin32.sourceforge.net/packages/make.htm
http://www.mingw.org/
Variables on located on the Advanced tab. Find PATH under System Variables, double click on it and edit it by
adding the following location (WEBOTS-HOME)\mingw\bin.
The second tip consists on compiling the e-puck firwamre libepuck.c using mingw32-make. To do so, just open
the console cmd with administrator rights, go to (WEBOTS-HOME)\transfer\e-puck\libepuck and run the command
mingw32-make. This will run the file Makefile. Note, however, that if one wishes to follow this approach, all changes
carried out for the file Makefile.include (i.e., Makefile called from Webots interface) described in the following
sections should be made on the file Makefile instead.
Due to the limitations of this approach, including the incompatibility of some features (e.g., audio codecs) and the
larger development time as one needs to compile two distinct codes, Webots e-puck cross-compiling architecture has
been modified as next section describes.
3.2. Proposed e-puck Programming Architecture
To the similarity of the architecture presented in Fig. 2, the newly proposed programming/compiling architecture
includes the Webots API. However, similarities ends there. Instead of externally compiling the firmware libepuck.c to
generate an archive file libepuck.a with gnuwin32, MinGW or any other tool, Webots cross-compilation tool directly
compiles all the code. That is to say, both base code libepuck.c that depends on e-puck API as all developed Ccontrollers (Fig. 3).
In other words, although Webots cross-compilation requires some more few seconds to be executed, it allows not
only the direct development of both Webots and e-puck APIs, but also editing the libepuck.c main e-puck firmware.
This greatly hastens the development time and promotes the integration of new functionalities toward a closer
correspondence between simulation and reality.
e-puck API
Firmware
libepuck.c
C-Controller(s)
your_code_1.c
…
your_code_n.c
Webots API
Webots cross-compilation
(runs Makefile.include)
Generates
Machine code(s)
your_code_1.hex
…
your_code_n.hex
Figure 3. Webots proposed e-puck programming architecture.
To implement this novel architecture, the only file one needs to change is the Makefile.include located on
(WEBOTS-HOME)\transfer\e-puck\libepuck\ and called by Webots cross-compilation tool. Although this file is
available for download at authors’ main site4, as all other files created in this work, a brief explanation on how it was
modified is given. This has the intent to introduce the necessary programming tips to further extend the herein proposed
approach.
Let us then take a look at the most relevant lines of the new file Makefile.include. Note that at this takes as example
a single C-controller named e_puck.c created by the user. Other not defined variables in Fig. 4 are not relevant for this
analysis.
4
http://www2.isr.uc.pt/~micaelcouceiro/media/WebotsEpuck.zip
# Define controller name
NAME= e_puck
# Define C-files source of the user-created C-controller
C_SOURCES2=$(NAME).c
# Define C-files dependencies of the user-created C-controller
Added for the purposes of this work!
C_SOURCES= $(LIBPATH)/libepuck/libepuck.c \
$(LIBPATH)/library/motor_led/e_init_port.c \
$(LIBPATH)/library/camera/fast_2_timer/e_calc_po3030k.c \
$(LIBPATH)/library/camera/fast_2_timer/e_calc_po6030k.c \
$(LIBPATH)/library/camera/fast_2_timer/e_common.c \
$(LIBPATH)/library/camera/fast_2_timer/e_po3030k_registers.c \
$(LIBPATH)/library/camera/fast_2_timer/e_po6030k_registers.c \
$(LIBPATH)/library/camera/fast_2_timer/e_timers.c \
$(LIBPATH)/library/I2C/e_I2C_master_module.c \
$(LIBPATH)/library/I2C/e_I2C_protocol.c \
$(LIBPATH)/library/motor_led/advance_one_timer/e_remote_control.c \
$(LIBPATH)/library/motor_led/advance_one_timer/e_motors.c \
$(LIBPATH)/library/motor_led/advance_one_timer/e_led.c \
$(LIBPATH)/library/motor_led/advance_one_timer/e_agenda.c \
$(LIBPATH)/library/a_d/advance_ad_scan/e_prox.c \
$(LIBPATH)/library/a_d/advance_ad_scan/e_ad_conv.c \
$(LIBPATH)/library/a_d/advance_ad_scan/e_micro.c \
Added for the purposes of this work!
$(LIBPATH)/library/codec/e_sound.c \
$(LIBPATH)/library/bluetooth/e_bluetooth.c
# Define the low level assembly ASM-files dependencies of the user-created C-controller
ASM_SOURCES= $(LIBPATH)/library/data_eeprom/data_eeprom.s \
$(LIBPATH)/library/camera/fast_2_timer/e_interrupt.s \
$(LIBPATH)/library/uart/e_init_uart1.s \
$(LIBPATH)/library/uart/e_uart1_rx_char.s \
Added for
$(LIBPATH)/library/uart/e_uart1_tx_char.s \
$(LIBPATH)/library/uart/e_init_uart2.s \
$(LIBPATH)/library/uart/e_uart2_rx_char.s \
$(LIBPATH)/library/uart/e_uart2_tx_char.s \
$(LIBPATH)/library/codec/e_const_sound.s \
$(LIBPATH)/library/codec/e_sub_dci_kickoff.s \
$(LIBPATH)/library/codec/e_isr_dci.s \
$(LIBPATH)/library/codec/e_init_dci_master.s \
$(LIBPATH)/library/codec/e_init_codec_slave.s
# Define the desired destination for machine code file
TARGET=$(NAME).hex
# Define the auxiliary common object file necessary to create the machine code
COF=$(TARGET:.hex=.cof)
# Define the necessary object file based on the c-files
C_OBJECTS=$(C_SOURCES2:.c=-pic30.o) $(C_SOURCES:.c=.o)
# Define the necessary object file based on the assembly files before linking them together
ASM_OBJECTS=$(ASM_SOURCES:.s=.o)
# Define the whole objects all together before linking them
OBJECTS=$(C_OBJECTS) $(ASM_OBJECTS)
the purposes of this work!
Added for the purposes of this work!
# Let us now create the target machine code!
Similar to the Makefile for libepuck.c pre-compilation
target: $(TARGET)
# 3 - Create the machine code
%.hex: %.cof
@$(B2H) $<
# 2 - Link the pre-compiled archive libepuck.a to the C-controller and create auxiliary common object file
$(COF): $(OBJECTS)
@$(LD)
-L$(LIBPATH)/std_microchip/lib
-Llib
--heap=512
--defsym=__ICD2RAM=1
-script=$(LIBPATH)/std_microchip/support/gld/p30f6014A.gld -mpic30_elf32 --start-group -lpic30-elf -lm-elf -lc-elf $(OBJECTS) --end-group -o $@
# 1 - Create the object file from the source file
%$(SUFFIX).o: %.c
@$(CC) $(CFLAGS) $< -o $@
Figure 4. Main code of the Makefile.include necessary for Webots cross-compilation of e-puck’s code.
As one may observe, the linking between the firmware libepuck.c and the remaining code is no longer made
separately. If one wishes to add new dependencies, either C-files or low level ASM-files, one only needs to write the
corresponding lines as depicted in Fig. 4 either on C_SOURCES or ASM_SOURCES. Webots cross-compilation will
take care of the rest.
This implementation has one limitation that needs to be considered at the beginning of any new project. All usercreated projects, let us call it (PROJECTS-HOME), need to be inside a folder at the same level at (WEBOTSHOME). In other words, if Webots is installed on C:\Program Files (x86), it is advised to create a folder (e.g.,
webotstest) also on C:\Program Files (x86) in which the user project(s) is(are) located.
For an easier understanding of the general ideas presented above, Fig. 5 provides a general overview of the whole
system file organization.
(WEBOTS-HOME)
Webots API
Generated
Machine Code File
A Makefile.e-puck needs to be inside the user-created project building a link to
run Makefile.include located on (WEBOTS-HOME)\transfer\e-puck\libepuck\
e-puck API
PROJECTS-HOME)
Figure 5. System file organization of Webots program, user-created projects and other relevant folders and files.
This new architecture being presented, next section describes, in a detailed fashion, how Webots and e-pucks
compatibility were extended.
4. Improving e-puck compatibility with Webots
As previously stated, to give a step towards more realistic experiments using e-pucks on Webots, one needs to extend
virtual e-pucks’ functionalities and, more importantly, the cross-compilation compatibility. This would allow users to
validate their approaches on both simulation and real experiments without much discrepancies. This section presents a
step-by-step explanation on how such extension was achieved guiding users through a typical classroom session to
foster the future development and improvement of Webots/e-pucks cross-compatibility. The tour will begin by
introducing some extras to improve code development and algorithms’ applicability. Afterwards, the microphone and
speaker functionalities on cross-compilation, followed by the most-wanted Bluetooth communication.
4.1. Robot ID
When one wishes to monitor the data from a specific robot, useful functions such as the printf are commonly used.
Nevertheless, the data from all the robots in the same environment appears in Webots console being almost impossible
to understand from which robot it comes. Moreover, and most importantly, if one wishes to interact (e.g., communicate)
with a specific robot a unique identification is required. In order to provide such functionalities, Webots introduced a
function called wb_robot_get_name that returns the string saved on the node name, thus allowing to add a unique
identifier to each virtual robot. Note that each robot’s name needs to be carefully chosen by the user as it is possible to
add the same name to different robots.
In the case of real e-pucks, one could benefit from the same advantages if each robot would have a unique ID.
Nevertheless, during cross-compilation, Webots redirects the wb_robot_get_name function to return the string epuck, thus removing any possibilities to identify each robot in a unique fashion. To overcome this issue, the
wb_robot_get_name function on robot.h library from e-pucks API was redirected to e-pucks main firmware
libepucks.c, thus returning a string with the word “e-puck_” followed by the unique identifier from each robot that
corresponds to the 4 digits number Bluetooth ID (and corresponding password) that is usually written on each robot’s
sticker (e.g., “e-puck_2185”).
To use this functionalities and access the Bluetooth device by using the UART1 communication channel (Fig. 1), the
following steps need to be considered:
1. Download the code Bluetooth Communication Testing - robot to robot, named as DemoGCtronic-BT,
from GCTronic5
2. Copy e_bluetooth.h and e_bluetooth.c from DemoGCtronic-BT/bluetooth to (WEBOTSHOME)\transfer\e-puck\library (e-puck API)
3. Include the e_bluetooth.h and uart/e_uart_char.h library from e-puck API to libepuck.c
4. Add the following line to the C-files sources in the new Makefile.include from (WEBOTSHOME)\transfer\e-puck\libepuck\ presented in section 3.2:
C_SOURCES=
…\
$(LIBPATH)/library/codec/e_bluetooth.c
5. Add the following line to the ASM-files sources in the new Makefile.include from (WEBOTSHOME)\transfer\e-puck\libepuck\ presented in section 3.2:
ASM_SOURCES=
…\
$(LIBPATH)/library/uart/e_init_uart2.s \
$(LIBPATH)/library/uart/e_uart2_rx_char.s \
$(LIBPATH)/library/uart/e_uart2_tx_char.s
5
http://projects.gctronic.com/E-Puck/DemoGCtronic-BT.zip
4.2. Debug
In the history of C-programming, either applied to robotics or not, one of the most useful functions ever made for
debugging purposes is the printf. Debugging with printf is a direct way to retrieve data robots may be computing and,
consequently, correct possible problems. Developing robotic applications with Webots is not an exception. However,
while in simulation this is straightforward, any kind of printf wrapper has been developed so far to allow the same
debugging possibility on the real e-pucks. In other words, Webots benefited from a printf_override.h library from epucks API to simply ignore the printf calls within Webots during cross-compilation. In this work, the
printf_override.h library was improved by redirecting the printf calls to the RS-232 serial communication.
As depicted in Fig. 1, the e-puck has two serial outputs, namely UART1 and UART2. While the UART1 is constantly
used as it corresponds to the Bluetooth communication that one needs to program the e-puck, the UART2 corresponds
to a somehow deprecated utility – a RS-232 cable connecting the platform to a computer. To avoid the interference
between the messages one wishes to share between robots and debugging by mean of printf calls, the UART2 was the
obvious remaining choice. Remember, however, that to do so a RS-232 cable with a specific layout needs to be built6.
Since the traditional printf and related functions (e.g., sprintf) do not work properly when several variables of
different types are added to the functions’ variable argument lists (va_list) on e-pucks platforms, a whole new printf
function was developed for e-pucks API in which each variable from va_list was individually processed and converted
to a string. Also, to avoid useless communication load when one does not wish to debug the code, the e-puck’s selector
to enable debugging was settled in position 0.
Besides the improvement of the printf_override.h library, this functionality only requires the addition of the
following line to the ASM-files sources in the new Makefile.include from (WEBOTS-HOME)\transfer\epuck\libepuck\ presented in section 3.2:
ASM_SOURCES=
…\
$(LIBPATH)/library/uart/e_init_uart1.s \
$(LIBPATH)/library/uart/e_uart1_rx_char.s \
$(LIBPATH)/library/uart/e_uart1_tx_char.s
4.3. Microphone
As previously described, the e-puck is equipped with three omnidirectional microphones placed as illustrated on Fig. 6
(Mondada, et al., 2009). The e-pucks allow to acquire data from the three microphones at a maximum acquisition speed
of 33 kHz (A/D frequency of 100kHz divided by three). Despite the lack of sensitivity regarding e-puck’s microphones,
those may still be used for sound source localization.
6
http://www.gctronic.com/doc/index.php/E-Puck#Serial_communication
Figure 6. Image from e-puck’s webpage www.e-puck.org.
The Webots allows to benefit from e-puck’s microphones during simulations as the demo e-puck_sound shows.
This Webots function uses the swis2d plugin developed by the Swarm-Intelligent Systems Group at the EPFL,
Switzerland. Nevertheless, this is an experimental functionality that does not really simulates sounds, thus ignoring any
sort of possible noise. Moreover, Webots also does not allow the cross-compilation of such functionality in such a way
that one cannot program real platforms using the microphone.h library from Webots API.
To overcome this problem, the following steps were followed:
1. Copy microphone.h from (WEBOTS-HOME)\include\controller\c\webots to (WEBOTSHOME)\transfer\e-puck\libepuck\include\webots
2. Include the a_d/advance_ad_scan/e_micro.h library from e-puck API to libepuck.c
3. Edit the DeviceTag wb_robot_get_device accordingly and define new tags to identify and enable each
microphone as:
#define DT_MIC0
(DeviceTag) 70
#define DT_MIC1
(DeviceTag) 71
#define DT_MIC2
(DeviceTag) 72
4. Add the following line to the C-files sources in the new Makefile.include presented in section 3.2:
C_SOURCES=
…\
$(LIBPATH)/library/a_d/advance_ad_scan/e_micro.c
5. Create the following functions on libepuck.c:
void wb_microphone_enable(DeviceTag dt,int ms);
void wb_microphone_disable(DeviceTag dt);
int *wb_microphone_get_sample_data(DeviceTag dt);
While the first two functions from the last point are straightforward as they only enable and disable the microphone
identified by dt with a refresh rate of ms to avoid useless processing, the last function deserves a deeper attention. The
corresponding function on Webots returns an array representing the reception of the emitted array by the speaker from
another virtual e-puck. For instance, on e-puck_sound demo, e-puck_1 (emitter) sends an array as [-128, -128, -128, 128, -128, -128, -128, -128, -128, -128, -128, -128, -128, -128, -128, -128, -128, -128, -128, -128, 127, 127, 127, 127,
127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127], while e-puck_2 (receiver) may receive
an array like [-12, -12, -12, -12, -12, -12, -12, -12, -12, -12, -12, -12, -12, -12, -12, -12, -12, -12, -12, -12, 11, 11, 11,
11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11] if far away from e-puck_1 or something like [-12241,
-12241, -12241, -12241, -12241, -12241, -12241, -12241, -12241, -12241, -12241, -12241, -12241, -12241, -12241, 12241, -12241, -12241, -12241, -12241, 12240, 12240, 12240, 12240, 12240, 12240, 12240, 12240, 12240, 12240,
12240, 12240, 12240, 12240, 12240, 12240, 12240, 12240, 12240, 12240] if near it due to the multiple reflections on
the walls. This is obviously not realistic at all as many other phenomena influences the sound propagation. As any other
wave, the sound is highly affected by its surroundings which are far from being perfect (e.g., surrounding noise).
Moreover, the addition of obstacles absorbs part of the sound passing through, usually through conversion to heat
energy (Herman, 2007). At least, one should highlight that the values received by the real e-puck’s microphones do not
float between -128 and 127 but yet between 0 and 4999.
Considering these conditions, the real e-puck wb_microphone_get_sample_data was created to return not the
intensity value at each reading but yet to return the difference between the highest and lowest intensity from the last
MIC_SAMP_NB samples, in which MIC_SAMP_NB is defined as 100 by default. This allows overcoming the
surrounding noise and, most importantly, the noise arising from the own platform during navigation. Such value can
be directly retrieved using the function e_get_micro_volume from a_d/advance_ad_scan/e_micro.h library from epuck API.
This variation turns out to present similar results from both simulated and real worlds. Some preliminary tests were
carried out with two platforms on both simulation and real environments. One of the platforms (e_puck_1) was
programmed as sound emitter (cf., next section) while the other (e_puck_2) as a sound receiver (i.e., using the
microphones). The e_puck_1 was programmed to constantly emit the same “haa” sound sequence (cf., next section)
while standing in the same position. The e_puck_2 was programmed to output the readings from the microphones while
getting far away from e_puck_2 at a constant velocity of 10 mm/s. On the real case situation, the data was acquired
using the printf function used for debugging also developed in this work (cf., section 4.2).
Fig. 7 compares the median value of a set of 10 trials with real platforms with a trial from the simulated case (note
that this last one does not consider noise being therefore deterministic). As one may observe, despite the evident
existence of noise from the real experiments the captured sound decreases with the distance in a very similar fashion.
The data was truncated for distances to the sound source above 200 𝑚𝑚 since the difference starts to be considerably
large as the microphones under the real experiments are highly influenced by the sound coming from robot’s
movements.
120
mic0
mic1
mic2
Microfones inputs
100
80
60
40
20
20
40
60
80
100
120
140
160
180
200
distance [mm]
Real experiments
Simulation experiments
Figure 7. Comparison between the data acquired by e-puck’s microphones on both real and simulation experiments while getting far
away from the sound source.
Next section describes the speaker implementation.
4.4. Speaker
The e-puck robot is equipped with a speaker on top of it (Fig. 1) connected to an audio codec. Combined with the
microphones, the speaker can create a communication network with the ability to detect the direction of peers. It is also
an excellent output device for human interaction (Mondada, et al., 2009). Due to speed processing reasons, the internals
functions of the speaker package are written in assembler and a small selection of predefined sounds is available in the
file codec/e_const_sound.s. Five sounds are organized as Table 3 depicts.
Table 3. Available sounds within e-pucks API.
2
“spaah”
Words on codec/e_const_sound.s
[𝒃𝒆𝒈𝒊𝒏𝒏𝒊𝒏𝒈, 𝒍𝒆𝒏𝒈𝒕𝒉]:
[0, 2112]
[2116, 1760]
3
“ouah”
[3878, 3412]:
4
“yaouh”
[7294, 3732]:
5
“wouaaaaaaaah” [11028, 8016]:
ID Sound
1 “haa”
Those sounds are only available in the real robots as previously described since the sound system within Webots is
still experimental. Despite this drawback, and based on what e-pucks acquire using their microphones to capture their
teammates sounds, one may emulate such sounds using the swis2d plugin and the most adequate arrays of data for
virtual reproduction. Nevertheless, before this it is necessary to enable Webots functions on cross-compilation.
Webots does not allow the cross-compilation of speakers’ functions in such a way that one cannot program the real
platforms using the speaker.h library from Webots API.
To overcome this problem, the following steps were followed:
1. Copy speaker.h from (WEBOTS-HOME)\include\controller\c\webots (Webots API) to (WEBOTSHOME)\transfer\e-puck\libepuck\include\webots (e-puck API)
2. Add the following function to speaker.h located on (WEBOTS-HOME)\transfer\epuck\libepuck\include\webots:
void wb_speaker_play(WbDeviceTag dt, int soundID);
3. This function should also be included in speaker.h from (WEBOTS-HOME)\include\controller\c\webots
although with some more programming (described with more detail bellow)
4. Include the codec/e_sound.h library from e-puck API to libepuck.c
5. Edit the DeviceTag wb_robot_get_device() accordingly and define a new tag to identify the speaker:
#define DT_SPK
(DeviceTag) 75
6. Add the following line to the C-files sources in the new Makefile.include from (WEBOTSHOME)\transfer\e-puck\libepuck\ presented in section 3.2:
C_SOURCES=
…\
$(LIBPATH)/library/codec/e_sound.c
7. Add the following line to the ASM-files sources in the new Makefile.include from (WEBOTSHOME)\transfer\e-puck\libepuck\ presented in section 3.2:
ASM_SOURCES=
…\
$(LIBPATH)/library/codec/e_const_sound.s \
$(LIBPATH)/library/codec/e_init_dci_master.s \
$(LIBPATH)/library/codec/e_init_codec_slave.s
8. Create the following functions on libepuck.c:
void wb_speaker_emit_sample(DeviceTag dt, int* SAMPLE, int sizeofSAMPLE);
void wb_speaker_play(DeviceTag dt, int soundID);
As opposed to the microphones functionalities, the speaker requires the addition of low level assembly functions
(ASM) to provide access to the audio codecs. Henceforth, the ASM-files sources on point 7 need to be added to the
Makefile.include. It is also noteworthy that without the new programming architecture proposed on section 3.2 this
would not work as the e-puck would be unable to load the audio codecs and, as a result, it will constantly reset when it
tries to load them.
The main e-puck’s firmware libepuck.c needs to be once again extended to provide the user with the speaker
functionalities. Besides the wb_speaker_emit_sample that was already created into Webots API, the newly created
wb_speaker_play also needs to be defined. The first time any of those functions are called, the low level function
e_init_sound is also automatically called only once to permit the access to the audio codecs. Regarding the
wb_speaker_emit_sample, and due to its functionality within Webots, this was simply used as a relay to reproduce
the predefined sounds presented on Table 3 based on the range of the first value of the array defined by the user. Note
that this is highly limited and unrealistic but, as previously mentioned, the e-puck does not allow playing sounds that
are not on codec/e_const_sound.s. Therefore, it is highly recommended to avoid the call of the function
wb_speaker_emit_sample directly. Instead of doing that and defining arrays that cannot be reproduced on the real
robots, it is advised to call the wb_speaker_play instead. Note that this function intrinsically calls the
wb_speaker_emit_sample based on some experimentally validated arrays (see bellow). By calling wb_speaker_play,
the only necessary input is the argument soundID that will receive values between 1 and 5 accordingly to the ID column
from Table 3. This will automatically call the low level function e_play_sound receiving as inputs the words
𝑏𝑒𝑔𝑖𝑛𝑛𝑖𝑛𝑔 and 𝑙𝑒𝑛𝑔𝑡ℎ on codec/e_const_sound.s also according to Table 3.
Contrarily to the speaker.h located on (WEBOTS-HOME)\transfer\e-puck\libepuck\include\webots (e-puck
API) in which wb_speaker_play function is relayed to e-puck’s firmware libepuck.c, the wb_speaker_play function
on speaker.h located on (WEBOTS-HOME)\include\controller\c\webots (Webots API) needs to be fully developed
to emulate the predefined sounds within codec/e_const_sound.s (Table 3). The argument soundID will then receive
values between 1 and 5 accordingly to Table 3 as previously described and, depending on the choice, a different
sequence of arrays will be loaded and emitted using the traditional wb_speaker_emit_sample from Webots API. Those
arrays were defined in such a way to fit, as most as possible, the real reception from neighbour e-pucks of the sounds
described on Table 3. Note that while a sequence of 3 arrays of 80 elements each enough to describe the first 4 sounds,
the last one requires 11 arrays of 80 elements each.
Some tests were carried out with two platforms on both simulation and real environments. One of the platforms
(e_puck_1) was programmed as sound emitter playing the 5 sounds presented on Table 3 successively. The other
(e_puck_2) was programmed as a sound receiver (i.e., using the microphones described on the previous section). Both
e_puck_1 and e-puck 2 were programmed to stand in the same position at a distance of 10 cm from each other’s centre.
The e_puck_2 was programmed to output the readings from the microphones using the printf function used for
debugging also developed in this work (cf., section 4.2).
Fig. 8 compares the median value of a set of 10 trials with real platforms with a trial from the simulated case. As
one may observe, despite the existence of noise from the real experiments, the similarity between sound emission, and
consequently reception, under simulation and real experiments is evident.
mic0
mic1
mic2
200
180
Microfones inputs
160
140
120
100
80
60
40
20
1
2
3
4
5
6
7
8
9
time [seconds]
Real experiments
Simulation experiments
Figure 8. Comparison between the data acquired by e-puck’s microphones on both real and simulation experiments playing the
sequence of predefined sounds presented on Table 3.
Going deeper into e-puck’s compatibility extension with Webots, next section describes how to obtain inter-robot
communication on both simulation and real experiments using the Bluetooth interface.
4.5. Communication
Despite e-puck’s features, the wireless communication did not had the proper attention. Mainly because the Bluetooth
interface was conceived to provide communication between the CPU and the e-puck (e.g., for programming).
Therefore, several alternatives to the basic configuration were proposed over the last years. The first one was the Range
and Bearing Turret (e-RandB) allowing e-puck to communicate locally at short distances of up to 80 𝑐𝑚 with infrared
communication (Gutiérrez, Campo, Dorigo, Monasterio-Huelin, & Donate, 2009). Although it was quite an interesting
solution, more than just having a very limited communication range, the infrared signals are greatly affected by
obstacles and environment lighting conditions. Also, such wireless technology presents itself as a bottleneck in terms
of communication rate rate. For instance, the solution provided by (Gutiérrez, Campo, Dorigo, Monasterio-Huelin, &
Donate, 2009) only allows a maximum communication rate of 30 bytes per seconds. Alternatively, a ZigBee turret was
proposed to promote swarm robotics using e-puck platforms (Cianci, Raemy, Pugh, & Martinoli, 2006). This turret
allows the creation of networks of e-pucks and has the major advantage over all other alternatives of adjusting its
communication range between 15 𝑐𝑚 and up to 5 𝑚. By controlling the communication range in such a way, one may
perform experiments in space-limited laboratory settings to deeply study communication constraints on the algorithms.
Despite all the positive features of this extension, the fact that it is a laboratory project, i.e., not available for users
unless they develop it from scratch, turns out to exclude this turret from most applications. A more commercial
alternative for the e-puck is the Gumstix Overo turret7. By using this extension, the e-puck robot is endowed with a
Linux operating system with all the processing power and the immense possibilities of it once compared to the
embedded microcontroller. Hence, this extension clearly leverages the capabilities of the e-puck robot. However, it also
significantly leverages its cost. Disregarding this last issue, this is the most adequate strategy to follow if one wishes to
benefit from inter-robot communication since the turret provides the typical WiFi 802.11 communication. As this work
rests on the low-cost applicability, the Bluetooth interface from the basic configuration will be explored on both
simulation and real robots. Nevertheless, before looking at the technology itself, let us first understand the inter-robot
communication mechanism behind Webots.
The Webots environment already comes with libraries that provides a communication interface between virtual epucks. Although those libraries are only from Webots API and cannot be used for cross-compilation purposes, they still
provide some interesting features as radio or infrared modelling. The main difference resides in the fact that infrared
communication takes obstacles into account and allows defining an opening angle of the emission cone. As we will be
focusing on Bluetooth, the radio model was the obvious choice.
In brief, two libraries from Webots API need to be included into the user-created project for inter-robot
communication: the emitter.h and the receiver.h. Sending data using the radio model (default of the libraries) is as
easy as defining the maximum communication range using the function wb_emitter_set_range and send the desired
information with wb_emitter_send. The wb_emitter_send function adds to the emitters’s queue a packet of size bytes
located at the address indicated by the data one wishes to share. The enqueued data packets are then sent to potential
receivers and removed from the emitter’s queue. Receiving data using the radio model is also simple. At first one needs
to enable it (as any other input device) by using the wb_receiver_enable function followed by the
wb_receiver_get_data. The wb_receiver_get_data function returns the data of the packet at the head of the reception
queue. The returned data pointer is only valid until the function wb_receiver_next_packet is called. Besides those,
other useful functions may be used such as the wb_receiver_get_queue_length to control the reception of new data
and the wb_receiver_get_signal_strength to retrieve the strength of the signal that may be closely related to the typical
received signal strength indication (RSSI) usually available on real wireless equipment. Note that the emitter/receiver
libraries from Webots API do not impose any particular format on the data being transmitted. Any user chosen format
is suitable, as long as the emitter and receiver codes agree. Also, only robots within the same channel can communicate.
This may be seen as a frequency for a radio emitter settled by the function wb_emitter_set_channel. The emitter then
needs to define a positive channel number for inter-robot communication with the receiver.
Fig. 9 illustrates the inter-robot communication architecture on Webots. For the purpose of the Bluetooth extension
herein presented, the radio channel of the wb_emitter_set_channel function was defined with the e-puck unique ID
(cf., next chapter). The variable 𝑡 corresponds to the current time. This means that the receiver will currently process
a data packet sent at 𝑡 − 𝑚 − 𝑛. It is noteworthy that Webots does not assume any kind of delays regarding the
establishment of a new communication link or the size of a given message.
7
http://www.gctronic.com/doc/index.php/Overo_Extension
Packet 𝑡 − 𝑚
Packet 𝑡 − 𝑚 − 1
wb_receiver_next_packet
⋱
Packet 𝑡 − 𝑚 − 2
Packet 𝑡 − 𝑚 − 𝑛
wb_receiver_get_data
wb_receiver_get_signal_strength
I
N
C
O
M
I
N
G
⋱
Packet 𝑡 − 1
Packet 𝑡
wb_emitter_send
wb_emitter_set_channel (1234)
receiver e-puck 1234
emitter e-puck 5678
Figure 9. Inter-robot communication within Webots.
Although the efficient communication paradigm from Webots, this may not be compared to the real Bluetooth
communication that e-puck possesses. The e-puck’s National Semiconductor LMX9820A Bluetooth module is quite
limited when compared to other equivalent modules available in the market for the last 5 years. In fact, the e-puck’s
Bluetooth interface was only designed for CPU-robot communication for programming and, eventually, debugging. It
does not allow the creation of piconets with more than 3 nodes (including the master node) as opposed to the typical 7
nodes and, as a consequence, it does not allow the creation of scatternets. Therefore, due to its hard limitations, the
most adequate use of this module within multi-robot applications, namely on swarm robotics, consists on a robot-torobot communication. In other words, every message pushed into the emitter buffer of one e-puck should be directly
sent to the receiver buffer of the linked e-puck as depicted in Fig. 9 emulating a cable.
Nonetheless, this is not a simple process as it requires the emitter e-puck to first inquiry for Bluetooth devices,
identify the ones from e-pucks, select the desired e-puck and establish a Serial Port Profile (SPP) link. Only then, if all
the process is successful, the emitter e-puck can send the data. However, the receiver e-puck needs to know that one of
its teammates wants to share information in such a way that it needs to wait for the SPP link to be established and for
the message to be available in the buffer.
That kind of robot-to-robot Bluetooth communication within e-pucks was only addressed so far by GCtronic
company8 and on Nassar’s Thesis (Nasser, 2010). However, note that those works were not motivated on yielding a
common ground between Webots and e-pucks, i.e., they were only centred on e-puck real platforms. Moreover,
although their algorithm for robot-to-robot communication was well defined, there were still some limitations. For
instance, a receiver e-puck would infinitely wait for a SPP connection to be establish and a message to be available in
the buffer. Also, the algorithm presented by the authors do not allow to create a SPP link to a specific e-puck, only to
the first one detected. Such assumptions cannot be hold under MRS, especially when considering applications in which
robots exchange messages only sporadically (Couceiro, Rocha, Ferreira, & Vargas, 2013).
Henceforth, some adjustments were carried out to the main Bluetooth library to enhance the compatibility between
simulated and real worlds and its applicability on multi-robot applications. At first, let us present the steps that one
should follow:
1. Copy receiver.h and emitter.h from (WEBOTS-HOME)\include\controller\c\webots (Webots API) to
(WEBOTS-HOME)\transfer\e-puck\libepuck\include\webots (e-puck API)
2. Edit e_bluetooth.h and e_bluetooth.c from (WEBOTS-HOME)\transfer\e-puck\library (e-puck API)
(described with more detail bellow)
3. Edit the DeviceTag wb_robot_get_device() accordingly and define the new tags to identify the receiver
8
http://www.gctronic.com/doc/index.php/E-Puck#Bluetooth_Communication_Testing_-_robot_to_robot
and the emitter:
#define DT_REC
(DeviceTag) 76
#define DT_EMI
(DeviceTag) 77
4. Create the following functions on libepuck.c:
void wb_receiver_enable(DeviceTag dt,int ms)
void wb_receiver_disable(DeviceTag dt)
const char* wb_receiver_get_data(DeviceTag dt)
void wb_emitter_set_channel(DeviceTag dt, int channel)
int wb_emitter_get_channel(DeviceTag dt)
int wb_emitter_send(DeviceTag dt, const char* data, int size)
As we go deeper into bringing Webots closer to e-pucks’ reality, the required level of expertise also increases. The
Bluetooth communication functionality is the one that requires the most from the developer. Contrarily to the previous
extensions in which only the Webots API and e-puck main firmware function were edited, in this step one will need to
edit the main Bluetooth library from e-puck API, the e_bluetooth.c file. Those changes may be summarized by simply
editing the e_bt_recv_SPP_data function and creating a new function e_bt_connect_epuckID.
The first function will be improved by adding an inactivity threshold 𝑇𝑟𝑒𝑐 to prevent the stagnation of e-pucks while
waiting for a message or SPP link. Note that this threshold consists on the number of 1-byte readings the e-puck does
to its own buffer and, therefore, should be considerably high (an inactivity threshold of 𝑇𝑟𝑒𝑐 = 106 presented good
results).
The addition of the second function e_bt_connect_epuckID allows for the emitter to choose a specific receiver by
indicating its unique ID (cf., next chapter for a more detailed description). Hence, the ID of the receiver is defined as
an input argument of the function by means of wb_emitter_set_channel function. The e_bt_connect_epuckID then
calls the e_bt_find_epuck function that retrieves the e-puck robots from the list of all Bluetooth devices found by the
low level Bluetooth function e_bt_inquiry. Afterwards, the desired e-puck is selected from that list so as to establish
the SPP link with it using the function e_bt_etablish_SPP_link and share the data using the function
e_bt_send_SPP_data. If the receiver e-puck is not on the list of Bluetooth devices found by the emitter then an error
code superior to 0x00 is returned (the LMX9820A datasheet may be consulted for more details about the error).
Despite the number of functions one needs to add to the main firmware libepuck.c, the code is far from being
complex. The first two functions only enables and disables the receiver. As any other input device on Webots, and to
avoid irrelevant processing, this functionality was implemented on the receiver device. The wb_receiver_get_data
that allows virtual e-pucks to receive data on Webots follows a simple successive call of functions from the
e_bluetooth.c library including the e_bt_recv_SPP_data.
Regarding the emitter, the wb_emitter_set_channel function allows to choose the receiver e-puck based on its
unique ID while the wb_emitter_get_channel allows to retrieve the last teammate chosen as receiver by the emitter epuck. Finally, the wb_emitter_send calls the new function e_bt_connect_epuckID, followed by
e_bt_etablish_SPP_link, e_bt_send_SPP_data and e_bt_release_SPP_link to withdraw the connection between the
pair of e-pucks. In the case of establishing a SPP link by the emitter, a threshold 𝑇𝑒𝑚𝑖 was also introduced to prevent
its inactivity. On this case, and due to the amount of information exchanged between the emitter and the receiver, a
small number of 𝑇𝑒𝑚𝑖 = 3 presented good results with a similar pause time then for the receiver case of 𝑇𝑟𝑒𝑐 = 106 .
Fig. 10 depicts the flowchart describing the real communication process that can be seen as a low-level translation
of Fig. 9 to real world e-pucks. Variable 𝑡𝑟𝑒𝑐 and 𝑡𝑒𝑚𝑖 are simple counters that are reset to 0 before each main blocks,
i.e., “Wait for SPP link” and “Wait to receive SPP message” or “Create SPP link” and “Send SPP message”,
respectively.
As one may observe, the process, especially in the side of the emitter, is somehow complex. Associated with this
comes the time necessary to fufil each one of those operations. For instance, the whole process on the emitter may vary
between around 19.8 ± 4.5 seconds (results retrieved within the experimental setup depicted on Fig. 11 for 53
successful exchanged messages), in which a major part of the time is spent on searching for Bluetooth devices and
creating the SPP link with the desired e-puck. With that in mind, we know that inter-robot communication within real
e-pucks correspond to a specific pause time (i.e., inactivity) that is neglected on Webots. Despite this difference, the
possibility of exchanging data in an aperiodic fashion on both simulation and real experiments with e-pucks
significantly increases the assortment of multi-robot applications.
wb_emitter_set_channel (1234)
wb_emitter_send
Select e-pucks
from the list
Inquiry Bluetooth
devices
Search for the
desired e-puck
[1234]
Desired epuck found?
wb_receiver_get_data
No
Yes
𝑡𝑟𝑒𝑐 < 𝑇𝑟𝑒𝑐
Wait for SPP link
Yes
𝑡𝑒𝑚𝑖 < 𝑇𝑒𝑚𝑖
Create SPP link
No
Yes
No
𝑡𝑒𝑚𝑖 + +
𝑡𝑟𝑒𝑐 + +
SPP link
established?
No
Yes
Wait to receive
SPP message
𝑡𝑟𝑒𝑐 < 𝑇𝑟𝑒𝑐
Yes
No
I
N
C
O
M
I
N
G
SPP link
established?
No
Yes
Send SPP
message
𝑡𝑒𝑚𝑖 < 𝑇𝑒𝑚𝑖
No
Yes
𝑡𝑟𝑒𝑐 + +
Message
received?
No
𝑡𝑒𝑚𝑖 + +
Message
sent?
Yes
No
Yes
Back to main
Back to main
receiver e-puck 1234
emitter e-puck 5678
Figure 10. Flowcharts for Bluetooth communication between a pair of e-pucks.
As in the previous sections, a small experimental setup to test the inter-robot communication was settled both real
and on Webots environment. This scenario makes use of all the presented extended functionalities. The receiver e-puck
was placed at the centre of a 60 × 60 𝑐𝑚 field while the emitter e-puck was placed at one of the corners of the field.
The receiver e-puck did not moved during the entire trial of 6 minutes runtime (i.e., excluding pause times due to
Bluetooth communication) and continuously reproduced the sound ID 5 from Table 3 from 5 to 5 seconds. The emitter
was programmed with a random walk behaviour and Braitenberg collision avoidance algorithm (Braitenberg, 1984).
Also, the emitter e-puck was programmed to listen to any sounds at each step of the algorithm by benefiting from the
average output value returned by the three microphones (Fig. 6). The emitter e-puck would then send the message “I
hear you” to the receiver e-puck each time the level of acquired sound exceeded an intensity of 60 (cf., Fig. 8).
By neglecting the pause times inherent to the Bluetooth communication on the real scenario, the experimental results
depict a similar distribution of the points in which the emitter e-puck was able to hear the receiver e-puck (Fig. 11). To
better compare the experimental results as a whole, particularly the positional acknowledgements of the received
sounds, the least-squares fitting of ellipses to 2D points was adopted (Fitzgibbon, Pilu, & Fisher, 1999). This allows
not only to analyse the precision, i.e., the dispersion related to the sound source, but also the accuracy of the data, i.e.,
how close the emitter e-puck was from the receiver e-puck. As one may observe, both area and rotation of the ellipses
are very similar, thus suggesting a close realism between the simulated and the real world. However, it is interesting to
observe that in the 6 minutes runtime, the virtual emitter e-pucks tried to share its message with the virtual receiver epuck 65 times against the 58 times from the real e-pucks. This may be explained by the discrepancies of sound
propagation for larger inter-robot distances (cf., Fig. 7). Also, on those 58 times the real emitter e-puck tried to
communicate, it was only successful to effectively communicate with the real receiver e-puck 53 times. In all occasions
this happened because the emitter was unable to find the desired e-puck receiver, i.e., “Search for the desired e-puck”
block from Fig. 10. Although this could be improved by creating a loop of trials, this block consumes a major part of
the whole inactive time of the emitter e-puck. In other words, the communication pause time would critically increase
with such strategy. Hence, such strategy was discarded since it was possible to achieve a communication success of
almost 90%. It is also interesting to note that each time the emitter e-puck was able to establish communication with
the receiver e-puck, all packets were successfully delivered.
a)
Sound propagation
(swis2d plugin)
Receiver e-puck
LED that identifies when a
Bluetooth SPP link is established
Emitter e-puck
30
b)
20
y [cm]
10
Least-square fitting of ellipses to virtual data
Virtual data of positional acknowledgments
Least-square fitting of ellipses to real data
Real data of positional acknowledgments
0
-10
-20
-30
-30
-20
-10
0
10
20
30
x [cm]
Figure 11. Comparison between inter-robot communication on both real and simulation experiments using Bluetooth to acknowledge
the reception of the sound. a) virtual and real setups; b) positional acknowledgment of the received sounds and least-squares fitness of
ellipses.
5. Conclusions
This report gives its contribute to the robotics society by extending the cross-compatibility between Webots simulator
and e-puck robotic platforms, thus increasing the range of multi-robot applications one may evaluate on both virtual
and real worlds. Giving a step closer towards merging both e-puck and Webots APIs addresses the common problem
roboticists often face on finding a consistent environment to simulate experiments with multiple robots. The
functionalities presented in this report are transparent for Webots users and do not change any of the programming
structure and style adopted so far on the development of applications using the e-puck. The changes are only observable
when one wishes to cross-compile the code developed on the virtual environment to program the real e-puck platforms.
This new extension now allows for Webots users to benefit from microphones, speaker and inter-robot Bluetooth
communication that were erstwhile inaccessible. The consistency of the experimental results obtained on both virtual
and real worlds regarding those functionalities meet the necessary requirements to consider Webots as an easily, readily
usable environment to fulfil experiments with e-pucks’ full functionalities. Although such mechanisms may not greatly
improve single robot experiments, the literature highlights the need of more sensing capabilities and robot-to-robot
ways of interaction to foster the development of multi-robot systems. However, some improvements may still take
place, especially in what concerns e-puck’s limitations. As the Bluetooth interface was never designed for inter-robot
communication, it still presents some drawbacks that one may try to address. The required time to establish a link
between pairs of robots is unsuitable for experiments that require a high rate of shared information between different
robots. Also, due to the limitations of e-puck’s Bluetooth module, it is impossible to create a wireless network that
many multi-robot systems require. In other words, the use of e-puck platforms on multi-robot applications is confined
to systems with sporadic explicit communication between robots (e.g., swarm robotics). Nevertheless, such limitation
may be overcome by either benefit from e-puck turrets available in the market (Linux Gumstix Overo) or by further
exploiting the microphone-speaker combination to explicitly share information to local neighbours. Either of those
would require a further extension of Webots/e-puck cross-compatibility in which this document gives the necessary
step-by-step necessary actions to do so.
6. References
Braitenberg, V. (1984). Vehicles. Experiments in synthetic psycology, The MIT Press.
Cianci, C. M., Raemy, X., Pugh, J., & Martinoli, A. (2006). Communication in a Swarm of Miniature Robots: The ePuck as an Educational Tool for Swarm Robotics. Em E. Sahin, W. M. Spears, & A. F. Winfield, Proceedings of
Simulation of Adaptive Behavior (SAB-2006), Swarm Robotics Workshop (pp. 103-115). Rome, Italy: Lecture
Notes in Computer Science (LNCS) 4433.
Couceiro, M. S., Rocha, R. P., Ferreira, N. M., & Vargas, P. A. (2013). Darwinian Robotic Swarms for Exploration with
Minimal Communication. IEEE Congress on Evolutionary Computation (CEC'2013), Special session on
Evolutionary Robotics, 2013. Cancún, México: IEEE Computational Intelligence Society.
Fitzgibbon, A. W., Pilu, M., & Fisher, R. B. (1999). Direct least-squares fitting of ellipses. IEEE Transactions on Pattern
Analysis and Machine Intelligence, 21(5), 476-480.
Freese, M., Singh, S., Ozaki, F., & Matsuhira, N. (2010). Virtual Robot Experimentation Platform V-REP: A Versatile
3D Robot Simulator. Em N. Ando, S. Balakirsky, T. Hemker, M. Reggiani, & O. v. Stryk, 2nd International
Conference on Simulation, Modeling, and Programming for Autonomous Robots, SIMPAR 2010 (Vol. 6472,
pp. 51-62). Darmstadt, Germany: Lecture Notes in Computer Science, Springer.
Gutiérrez, Á., Campo, A., Dorigo, M., Monasterio-Huelin, F., & Donate, J. (2009). Open E-puck Range & Bearing
Miniaturized Board for Local Communication in Swarm Robotics. Proceedings of the IEEE International
Conference on Robotics and Automation (pp. 3111-3116). Piscataway, NJ: IEEE Press.
Guyot, L., Heiniger, N., Michel, O., & Rohrer, F. (2011). Teaching robotics with an open curriculum based on the epuck robot, simulations and competitions. Proceedings of 2nd International Conference on Robotics in
Education (RiE'2011) (pp. 53-58). Vienna, Austria: INNOC - Austrian Society for Innovative Computer
Sciences.
Herman, I. (2007). Sound, hearing and the human voice. Em I. Herman, Physics of the Human Body (pp. 87-98).
Springer.
Michel, O. (2004). Webots: Professional Mobile Robot Simulation. Journal of Advanced Robotic Systems, 1, 39-42.
Mondada, F., Bonani, M., Raemy, X., Pugh, J., Cianci, C., Klaptocz, A., . . . Martinoli, A. (2009). The e-puck - a Robot
Designed for Education in Engineering. Proceedings of the 9th Conference on Autonomous Robot Systems
and Competitions, (pp. 59-65).
Nasser, M. B. (2010). On E-Puck Mobile Robots for Distributed Robotics. Department of Electrical & Computer
Engineering. Singapore: National University of Singapore.
Parker, L. E. (2008). Multiple Mobile Robot Systems. Em Springer Handbook of Robotics (pp. 921-941).
Quigley, M., Gerkey, B., Conley, K., Faust, J., Foote, T., Leibs, J., . . . Ng, A. (2009). ROS: an open-source Robot
Operating System. International Conference on Robotics and Automation (ICRA'09) Workshop on Open
Source Software. Kobe, Japan.
Reckhaus, M., Hochgeschwender, N., Paulus, J., Shakhimardanov, A., & Kraetzschmar, G. (2010). An Overview about
Simulation and Emulation in Robotics. Proceedings of SIMPAR 2010 Workshops Intl. Conf. on Simulation,
Modeling and Programming for Autonomous Robots, (pp. 365-374). Darmstadt, Germany.
Rohrer, F. (2008). Curriculum of exercises for e-puck and Webots. Swiss: EPFL.