bridging the reality gap between the webots simulator and e-puck robots

Robotics and Autonomous Systems 62 (2014) 1549–1567

Contents lists available at ScienceDirect

Robotics and Autonomous Systems

journal homepage: www.elsevier.com/locate/robot

Bridging the reality gap between the Webots simulator ande-puck robotsMicael S. Couceiro a,b,∗, Patricia A. Vargas c, Rui P. Rocha a

a Artificial Perception for Intelligent Systems and Robotics (AP4ISR), Institute of Systems and Robotics (ISR), University of Coimbra, 3030-290,Coimbra, Portugalb Ingeniarius, Lda., Rua da Vacariça, n.37, 3050-381, Mealhada, Portugalc Robotics Laboratory, School of Mathematical and Computer Science, Heriot–Watt University, EH14 4AS, Edinburgh, UK

h i g h l i g h t s

• A set of computational techniques to improve the cross-compatibility between the Webots simulator and the e-puck are presented.• A newWebots programming architecture is presented, thus providing full control over the real e-puck’s capabilities.• The successful implementation of e-puck’s microphones, speaker and Bluetooth communication is fully described.• The Gumstix Overo COM turret is integrated within Webots framework, offering robot–robot WiFi communication.• Experiments conducted depict the compatibility using both virtual and real e-pucks under the Webots framework.

a r t i c l e i n f o

Article history:Received 13 December 2013Received in revised form24 April 2014Accepted 9 May 2014Available online 28 May 2014

Keywords:SimulationMulti-robot systemsEducational toolsRobot–robot interactionMobile robots

a b s t r a c t

This work presents a set of techniques to improve the cross-compatibility between the Webots simula-tor and the educational e-puck mobile robot. The work is motivated by the need of a realistic simulationenvironment, especially designed to consider the unique challenges associated to multi-robot systems(MRS), such as the robot–robot interaction (RRI). This article starts by proposing a newWebots program-ming architecture that provides full control of the e-puck’s firmware. By doing so, one can easily improvethe already existing e-puck’s functionalities onWebots, as well as adding new functionalities required bymostMRS applications. Among the range of newpossible functionalities, this article describes the success-ful implementation of the microphone, the speaker, and the Bluetooth for robot–robot communication.Due to the limitations of the e-puck’s Bluetooth modules, this work goes even further by bringing someinsights about the Gumstix Overo COM turret and how robot–robot communication may be achieved us-ing WiFi technology. The outcomes provided by the experiments conducted using both virtual and reale-pucks under the Webots framework open new doors for low-cost multi-robot applications.

© 2014 Elsevier B.V. All rights reserved.

1. Introduction

Simulation experiments play an essential role on robotics.One may not only assess the performance of new controllersvia simulation, especially when those are difficult to be ana-lytically characterized, but also overcome the cost inherent torobotics development [1]. However, the usefulness of a simulation

∗ Corresponding author at: Artificial Perception for Intelligent Systems andRobotics (AP4ISR), Institute of Systems and Robotics (ISR), University of Coimbra,3030-290, Coimbra, Portugal. Tel.: +351 919549194.

E-mail addresses:[email protected], [email protected],[email protected] (M.S. Couceiro), [email protected] (P.A. Vargas),[email protected] (R.P. Rocha).

http://dx.doi.org/10.1016/j.robot.2014.05.0070921-8890/© 2014 Elsevier B.V. All rights reserved.

environment grows with the consistency between simulationand real-world results. In robotics, such consistency needs to behandled by the adequate implementation of several real-worldfeatures such as sensor noise, robot dimensions and actuatorsnonlinearities. Nevertheless, when one goes from single robot tomulti-robot systems (MRS) applications, the level of complexitysignificantly grows. Moreover, one needs to consider the severalmechanisms that might foster cooperation in MRS (e.g., robot–robot communication) [2].

One of themost well-known and educationally popular simula-tors is the Webots mobile robot simulation software developed byCyberbotics [3]. The Webots robot simulation is a commercial soft-ware for fast prototyping and simulation of mobile robots whichhas developed tight links with one of the robotic platforms most

http://dx.doi.org/10.1016/j.robot.2014.05.007

http://www.elsevier.com/locate/robot

http://www.elsevier.com/locate/robot

http://crossmark.crossref.org/dialog/?doi=10.1016/j.robot.2014.05.007&domain=pdf

mailto:[email protected]






1550 M.S. Couceiro et al. / Robotics and Autonomous Systems 62 (2014) 1549–1567

widely used on both educational and research applications—thee-puck mobile robot [4]. Although the e-puck platform was orig-inally developed for teaching purposes, the number of sensor itpossesses, its low-cost and size make it an ideal tool for MRS ex-periments, especially in swarm robotics. Moreover, every e-puckhardware and software is a fully open source, providing low-levelaccess to every electronic device and offering unlimited exten-sion possibilities. Unfortunately, despite the significant compati-bility between Webots environment and e-puck platforms, somefunctionalities still remain to be implemented to fully access thereal e-puck’s capabilities, for instance: (i) access to the micro-phone, (ii) the speaker and,most importantly, (iii) the Bluetooth forrobot–robot communication. The microphone can extend e-puck’ssensing capabilities on both real world and simulations toward op-timization problems, e.g., to find audio sources emulating victimsin a search-and-rescue (SaR) scenarios. Combining the speakerwith the microphones may allow the creation of a communicationnetwork with the ability to detect the direction of teammates orpromote the robot–robot interaction (RRI), or even human–robotinteraction (HRI). At last, and as most MRS require, the Bluetoothradio link allows robot–robot explicit communication necessary toshare information and bring forth the necessary cooperation to ac-complish a collective task.

Hence, the major motivation of this article is to bridge the re-ality gap between both simulation and real-world robotic applica-tions using the Webots simulator and the e-puck robot platforms.The adopted procedures are described throughout this paperwhich are complemented with a brief walkthrough presented atthe official webpage.1 At first, a general overview of Webots’ ar-chitecture is presented in Section 2, thus describing the program-ming process and dependencies regarding virtual and real e-puckrobots. Such an architecture is optimized in such a way to broadenthe range of features and control over the platforms. Afterwards,the discrepancies between the virtual and real e-pucks are miti-gated, by overcoming the previously described limitations in Sec-tion 3. Other additional features such as the debug possibility forreal platforms and direct access to a unique robot identifier are alsoimplemented to support the development of real applications. Go-ing one step further, and due to the limitations inherent to e-puck’sBluetooth modules, Section 4 brings some insights about the Gum-stix Overo COM turret2 and presents a methodology to enablerobot–robot communication using WiFi technology. It does thatwhile keeping theWebots architecture, in such away that onemayfulfil the same MRS experiments on both virtual and real-worldscenarios using WiFi communication.

To evaluate the consistency ofWebots extension as the e-puck’smost suited simulation platform, both simulated and real experi-ments are carried out throughout this article and results are closelycompared regarding sensing capabilities and robot–robot commu-nication. Sections 4 and 5 outline the main discussion points andconclusions.

2. Programming e-puck’s robots with Webots simulator

The correspondence between simulation and reality has beenhighly discussed in the literature and several simulation environ-ments have been proposed such as the Virtual ExperimentationPlatform Coppelia Robotics (V-REP) [5] and the well-known RobotOperating System (ROS) [6]. Despite these recent accomplishments,the environment that still presents a higher compatibility betweenthe real and virtual e-puck robot is still theWebots simulator. This

1 http://www2.isr.uc.pt/~micaelcouceiro/webotsepuck/about.html.2 http://www.cyberbotics.com/e-puck/gumstix.

Fig. 1. Overview of the e-puck robot platform [1].

Table 1Main e-puck’s features (basic configuration).

Features Description

Small size ∅ 70 millimeters (mm)Low cost ≈700 e

High battery autonomy ≈3 hAvailable wireless communication Bluetooth (UART1)Available wired communication RS232 (UART2)High sensing capabilities 8 infrared proximity sensors

1 3D accelerometer1 640 × 480 CMOS color camera3 microphones

High actuation capabilities 2 1000 steps/rev stepper motors1 speaker8 red light emitting diodes (LED)

High expansion capabilities Omnidirectional visionGround sensorsColor LED communicationZigBee communicationMagnetic wheelsLinux extension

is mainly due to the close relation between e-puck and the edu-cation field that is the main target of Cyberbotics. Hence, this isfrequently seen as a win–win relationship to train beginners touse Webots and consequently increase e-puck’s usage (and so thee-puck community). In fact, the number of papers using both We-bots and e-puck real robots greatly exceed any other simulator+ platform combo. For instance, Rohrer’s report presents a full cur-riculum describing the link between the e-puck andWebots, goingfroma totally beginner audience to expert skilled programmers [7].

The e-puckdepicted in Fig. 1was officially presented for the firsttime in a scientific paper on 2009 [4] with a project that startedwith the Ecole Polytechnique Fédérale de Lausanne as collaborationbetween the Autonomous Systems Lab, the Swarm-Intelligent Sys-tems group and the Laboratory of Intelligent System. Since then,manyother works have been benefiting from the e-puck platform due toits price/features qualities (Table 1).

As it is possible to see in Table 1, the basic configuration pro-vides a high level of applicability with a large number of sensorsand actuation capabilities. Moreover, its low cost and small desk-top size, together with the open source feature, make the e-puckas one of the most widely used robotic platforms in the laboratorycontext. Although it still presents some limitations, those can beovercome by adding turrets (extension boards) for an extra cost toendow robots with additional CPU processing power and capabili-ties (Linux Gumstix Overo turret or Fly-Vision omnidirectional visionturret). As those turrets greatly increase e-puck’s cost and the basicconfiguration is still the most acquired one, we will only focus onthat one.

Programming e-pucks by using Webots has been consensual inmost research using e-puck robotic platforms. Eithermore directedfor education purposes as the work of [8] or all the way to swarm

http://www2.isr.uc.pt/~micaelcouceiro/webotsepuck/about.html

http://www.cyberbotics.com/e-puck/gumstix

M.S. Couceiro et al. / Robotics and Autonomous Systems 62 (2014) 1549–1567 1551

Table 2Currently 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.

applications as [9], it has been consensual that the combination be-tweenWebots and e-pucks is appropriated to the further develop-ment of robotic applications. One of the main reasons regardingsuch consensus resides in the compatibility between both simu-lation and real worlds. Nevertheless, such compatibility is still anon-goingwork and, therefore, a deeper contribution from the com-munity is required.

Yet, to contribute one first needs to understand what is devel-oped so far and howWebots e-puck architecture works.

2.1. Current e-puck programming architecture

In brief, in Webots environment, the Webots application andeach robot C-controller, i.e., user-created code in C/C++ language,are executed in distinct operating system processes. In otherwords, the number of processes in memory will be, in general, thesame as the number of simulated robots plus one (Webots applica-tion). It is interesting to note that a single C-controllermay be usedby several robots from the samevirtualworld. Different input argu-ments, or simply different identifications, might be used to dividethe processes by the corresponding agents. Although this seems tobe quite easy to perform underWebots environment, the only wayto have a closely similar response from real robots is through re-mote control. Thismay be activated by first uploading e-puckmainfirmware at e-puck official website3 (e.g., sercom firmware).

The remote-control tool allows us to monitor and remotelycontrol a real e-puck robot from Webots controller program overBluetooth. In this case, the control program runs on the computer,but instead of sending commands to and reading sensor data fromthe simulated robot, it sends commands to and reads sensor datafrom the real robot. Although this strategyworks great using a verysmall number of robots, it is totally impracticable as the numberof robots increases. Not only is the Bluetooth communicationlimited to piconets (networks) of 7 robots, but also processing thealgorithms ofmultiple robots in a centralized fashion is completelyopposite to the nature ofMRS and, especially, swarm robotics.

Therefore, only one choice is left—the cross-compilation tool.Developing a cross-compilation system allows us to compile theWebots controller for the embedded processor of the real robot.Hence, the source code for the Webots virtual robot is executedon the real robot itself, and there is no need to have a perma-nent CPU connection with the robot as with the remote control

3 http://www.e-puck.org/.

system. In brief, the idea is to generate a machine code HEX-filefrom the same C program as the one in simulation and to uploadit on the e-puck in a transparent fashion for the users. Webotsthen includes the source code, and eventually low-level assemblyfiles (ASM), of robots Application Programming Interface (API), be-ing compatible for e-puck and the Hemisson robots. Therefore, inthe case of e-puck robots, the cross-compilation system requiresthe source code necessary to compile the e-puck firmware. Thisrequires rewriting many of the Webots including files to be spe-cific to the e-puck platform. In other words, one may need to writesome C-source files to be used as a replacement for the WebotsAPI, but running on the real e-puck. Unfortunately, such a require-ment from the cross-compatibility tool turns out tomake it hard toaccess all e-puck features. Table 2 summarizes the functionalitiesthat one may access using both cross-compatibility and remote-control tools.

In brief, this article aims on transforming the ‘‘Not available’’

signs from cross-compilation into ‘‘Available’’ ones . Butbefore that, to better understandWebot 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 filesmust be included as any other regular C-library. A call to the ini-tialization function wb_robot_init is required before any other C-function call. This function initializes the communication betweenthe controller and Webots. Usually, the highest-level control codeis placed inside a for or a while loop.Within that loop there is a callto the wb_robot_step function that synchronizes the controller’sdata with the simulator using a control step TIME_STEP. This func-tion needs to be present in every controller and it must be calledat regular intervals, being usually placed in the main loop. This isa highly important functionality as it describes the duration of thecontrol steps, i.e., the functionwb_robot_step is used as a sort of de-lay of each loop cycle. Most importantly, this allows us to synchro-nize all robot’s devices (e.g., sensors). The update delay of devices ischosen to be similar to the control step (TIME_STEP) and hence thedevice is updated at every wb_robot_step. If, for instance, the up-date delay is chosen to be twice the control step, then the devicedata will be updated every two wb_robot_step. Such functionalitymay be used to simulate a slow device or avoid computing irrele-vant data. In other words, a larger update delay can also speed upexperiments, especially for CPU intensive devices like the Camera.Webots also allows us to enable or disable devices at any time us-ing the correspondingwb_X_enable andwb_X_disable functions, inwhich 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 dividedinto 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 recog-nize. It basically corresponds to e-puck’s library containing all filesto read the sensors and actuate the robots. Although Webots al-ready comes with e-pucks library, it is advised to download themost recent one at e-puck’s official website.

The second directory is of high relevance to this work as it ishere where the bridge between simulation and real e-puck’s pro-gramming is made and it is here in which this work will mainlyfocus. This directory needs to have all libraries used on the mainC-file developed on Webots. For instance, if one wishes to usethe microphone onWebots, the librarymicrophone.h on (WEBOTS-HOME)\include\controller\c\webots should be added. Neverthe-less, cross-compiling this code will return an error as this library

http://www.e-puck.org

http://www.e-puck.org/


Fig. 2. Webots e-puck programming architecture showing how the cross-compiler generates the machine code(s). Gray boxes correspond to the firmware andsupplementary libraries necessary to cross-compile the code requiring a pre-compilation procedure. The blue box corresponds to the high-level processes edited by theuser, disregarding whether those are to be applied under simulation or real-world experiments. The red lower box corresponds to the machine code(s) uploaded to the realplatforms. (For interpretation of the references to color in this figure legend, the reader is referred to the web version of this article.)

is not located on e-puck API. Therefore, a corresponding librarymi-crophone.hneeds to be placed on (WEBOTS-HOME)\transfer\e-puck\libepuck\include\webots. As an example, while the wb_robot_initis used on Webots API to initialize the communication betweenthe controller andWebots, this same function relays to the e-puckfirmware 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 aggregatesboth directories altogether comes: the e-puck’s firmware libepuck.clocated on (WEBOTS-HOME)\transfer\e-puck\libepuck. For e-puckprogrammers, we could say that its equivalent is the firmware.cfrom the e-puck official website. In fact, if one wishes to extendWebots e-puck functionalities, it is here that most of the pro-gramming will be carried out. Nevertheless, to do so, one needsto first change the Webots architecture. Currently, Webots cross-compiling architecture may be illustrated as Fig. 2 shows.

As one may observe, when running cross-compilation on We-bots, the C-code will be compiled and linked to the pre-compiledfirmware libepuck.a that calls e-puck API. That is to say, one needsto download a compiler and first run the Makefile on (WEBOTS-HOME)\transfer\e-puck\libepuck. All development of this workwas carried out on Microsoft Windows in which several possibil-ities to perform this are available. The most well-known are thegnuwin324 (GNU Make for Windows) and the MinGW.5 As We-bots already comes with this last compiler located on (WEBOTS-HOME)\mingw thismay be themost adequate alternative for thosewho wants to compile e-puck firmware and ignore Section 2.2.Nevertheless, this is not advised as many limitations were en-countered, for instance, regarding audio codecs (cf., Section 3.4)pre-compiling the firmware and subsequently linking it toWebotsC-code. However, some few tips are left for those who do not wishto change Webots e-puck programming architecture.

The first one will be to add (WEBOTS-HOME)\mingw\bin to thePATH system variable. The second tip consists on compiling thee-puck firmware libepuck.c using mingw32-make. To do so, justopen the console cmd with administrator rights, go to (WEBOTS-HOME)\transfer\e-puck\libepuck and run the commandmingw32-make. This will run the file Makefile. Note, however, that if onewishes to follow this approach, all changes carried out for the file

4 http://gnuwin32.sourceforge.net/packages/make.htm.5 http://www.mingw.org/.

Makefile.include (i.e.,Makefile called from theWebots interface) de-scribed in the following sections should be made on the fileMake-file instead.

Due to the limitations of this approach, including the incompat-ibility of some features (e.g., audio codecs) and the larger develop-ment time as one needs to compile two distinct codes, the Webotse-puck cross-compiling architecture has beenmodified as the nextsection describes.

2.2. Proposed e-puck programming architecture

In line with the architecture presented in Fig. 2, the newlyproposed programming/compiling architecture includes the We-bots API. However, the similarities end there. Instead of exter-nally compiling the firmware libepuck.c to generate an archive filelibepuck.awith gnuwin32,MinGW or any other tool, Webots cross-compilation tool directly compiles all the codes. That is to say, bothbase code libepuck.c that depends on e-puck API as all developedC-controllers (Fig. 3).

In other words, although Webots cross-compilation requiressomemore few seconds to be executed, it allows not only the directdevelopment of both Webots and e-puck APIs, but also editing thelibepuck.c main e-puck firmware. This greatly hastens the devel-opment time and promotes the integration of new functionalitiestoward a closer correspondence between simulation and reality.

To implement this novel architecture, the only file oneneeds to change is the Makefile.include located on (WEBOTS-HOME)\transfer\e-puck\libepuck\and called by the Webots cross-compilation tool. Although this file is available for download atauthors’ website,6 as all other files created in this work, a briefexplanation on how it was modified is given. This has the intentto introduce the necessary programming tips to further extend theherein proposed approach.

Let us then take a look at the most relevant lines of the newfileMakefile.include. Note that, as an example, we consider a singleuser-created C-controller named e_puck.c. Other not defined vari-ables in Fig. 4 are not relevant for this analysis.

As one may observe, the linking between the firmwarelibepuck.c and the remaining code is no longer made separately.If one wishes to add new dependencies, either C-files or low-level

6 http://www2.isr.uc.pt/~micaelcouceiro/media/WebotsEpuck.ziphttp://www2.isr.uc.pt/~micaelcouceiro/media/ReportFinal_1.pdf.

http://gnuwin32.sourceforge.net/packages/make.htm

http://www.mingw.org/

http://www2.isr.uc.pt/~micaelcouceiro/media/WebotsEpuck.zip

http://www2.isr.uc.pt/~micaelcouceiro/media/ReportFinal_1.pdf


Fig. 3. Webots proposed e-puck programming architecture showing how the cross-compiler generates the machine code(s). In this configuration, the cross-compilationcomprises the firmware and necessary libraries without any sort of pre-compilation procedure. This enables the user to fully edit the overall programming structure, fromthe lowest level functions found in the APIs, to the high-level processes, passing through the firmware libepuck.c that makes the bridge between both levels (blue boxes).(For interpretation of the references to color in this figure legend, the reader is referred to the web version of this article.)

ASM-files, one only needs to write the corresponding lines as de-picted in Fig. 4 either on C_SOURCES or ASM_SOURCES. Webotscross-compilation will take care of the rest.

This implementation has one limitation that needs to be consid-ered at the beginning of any new project. All user-created projects,let us call it (PROJECTS-HOME), need to be inside a folder at the samelevel at (WEBOTS-HOME). In other words, if Webots is installed onC:\Program Files (x86), it is advised to create a folder (e.g., webot-stest) also on C:\Program Files (x86) in which the user project(s)is(are) located.

For an easier understanding of the general ideas presentedabove, Fig. 5 provides a general overview of the whole system fileorganization.

This new architecture being presented, the next section de-scribes, in a detailed fashion, how Webots and e-pucks compati-bility were extended.

3. Improving e-puck compatibility with Webots

As previously stated, to give a step towards more realis-tic experiments using e-pucks on Webots, one needs to extendvirtual e-pucks’ functionalities and, more importantly, the cross-compilation compatibility. This would allow users to validate theirapproaches on both simulation and real experiments withoutmany discrepancies. This section presents a step-by-step explana-tion on how such extension was achieved guiding users through atypical classroom session to foster the future development and im-provement of Webots/e-pucks cross-compatibility. The tour willbegin by presenting some extras to improve code developmentand algorithms’ applicability. Afterwards, we introduce the micro-phone and speaker functionalities on cross-compilation, followedby the most-wanted Bluetooth communication.

3.1. Robot ID

When one wishes to monitor the data from a specific robot,useful functions such as the printf are commonly used. Neverthe-less, the data from all the robots in the same environment ap-pears in Webots console being almost impossible to understandfrom which robot it comes. Moreover, and most importantly, ifone wishes to interact (e.g., communicate) with a specific robot, aunique identification is required. In order to provide such function-alities, Webots introduced a function called wb_robot_get_namethat returns the string saved on the node name, thus allowing us toadd a unique identifier to each virtual robot. Note that each robot’sname needs to be carefully chosen by the user as it is possible toadd the same name to different robots.

In the case of real e-pucks, one could benefit from the same ad-vantages if each robot would have a unique ID. Nevertheless, dur-ing cross-compilation, Webots redirects the wb_robot_get_ namefunction to return the string e-puck, thus removing anypossibilitiesto identify each robot in a unique fashion. To overcome this issue,the wb_robot_get_name function on robot.h library from e-pucksAPI was redirected to e-pucks main firmware libepucks.c, thus re-turning a string with the word ‘‘e-puck_’’ followed by the uniqueidentifier from each robot that corresponds to the 4 digits numberBluetooth ID (and corresponding password) that is usually writtenon each robot’s sticker (e.g., ‘‘e-puck_2185’’).

To use these functionalities and access the Bluetooth device byusing the UART1 communication channel (Fig. 1), the followingsteps need to be considered:1. Download the code Bluetooth Communication Testing - robot to

robot, named as DemoGCtronic-BT, from GCTronic72. Copy e_bluetooth.h and e_bluetooth.c from DemoGCtronic-BT/

bluetooth to (WEBOTS-HOME)\transfer\e-puck\library (e-puckAPI)

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 Make-file.include from (WEBOTS-HOME)\transfer\e-puck\libepuck\presented in Section 3.2:

5. Add the following line to theASM-files sources in thenewMake-file.include from (WEBOTS-HOME)\transfer\e-puck\libepuck\presented in Section 3.2:

3.2. Debug

In the history of C-programming, either applied to robotics ornot, one of themost useful functions evermade for debugging pur-poses is the printf. Debugging with printf is a direct way to re-trieve data robots may be computing and, consequently, correctpossible problems. Developing robotic applications with Webots

7 http://projects.gctronic.com/E-Puck/DemoGCtronic-BT.zip.

http://projects.gctronic.com/E-Puck/DemoGCtronic-BT.zip


Fig. 4. Main code of theMakefile.include necessary for Webots cross-compilation of e-puck’s code.

is not an exception. However, while in simulation this is straight-forward, any kind of printf wrapper has been developed so far toallow the same debugging possibility on the real e-pucks. In otherwords, Webots benefited from a printf_override.h library from e-pucks API to simply ignore the printf calls within Webots duringcross-compilation. In this work, the printf_ override.h library wasimproved by redirecting the printf calls to the RS-232 serial com-munication.

As depicted in Fig. 1, the e-puck has two serial outputs, namelyUART1 and UART2. While the UART1 is constantly used as it cor-responds to the Bluetooth communication that one needs to pro-gram the e-puck, theUART2 corresponds to a somehowdeprecatedutility—an RS-232 cable connecting the platform to a computer.To avoid the interference between the messages that one wishesto share between robots and debugging by means of printf calls,theUART2was the obvious remaining choice. Remember, however,


Fig. 5. System file organization of Webots program, user-created projects and other relevant folders and files.

that to do so an RS-232 cable with a specific layout needs to bebuilt.8

Since the traditional printf and related functions (e.g., sprintf )do not work properly when several variables of different types areadded to the functions’ variable argument lists (va_list) on e-pucksplatforms, a whole new printf function was developed for e-pucksAPI in which each variable from va_list was individually processedand converted to a string. Also, to avoid useless communicationload when one does not wish to debug the code, the e-puck’s se-lector to enable debugging was settled in position 0.

Besides the improvement of the printf_override.h library, thisfunctionality only requires the addition of the following line tothe ASM-files sources in the new Makefile.include from (WEBOTS-HOME)\transfer\e-puck\libepuck\presented in section Section3.2:

8 http://www.gctronic.com/doc/index.php/E-Puck#Serial_communication.

3.3. Microphone

As previously described, the e-puck is equipped with threeomnidirectional microphones placed as illustrated in Fig. 6 [4]. Thee-pucks allow us to acquire data from the three microphones at amaximum acquisition speed of 33 kHz (A/D frequency of 100 kHzdivided by three). Despite the lack of sensitivity regarding e-puck’smicrophones, thosemay still be used for sound source localization.

The Webots allows benefiting from e-puck’s microphones dur-ing simulations as the demo e-puck_sound shows. This Webotsfunction uses the swis2d plugin developed by the Swarm-IntelligentSystems Group at the EPFL, Switzerland. Nevertheless, this is an ex-perimental functionality that does not really simulate sounds, thusignoring any sort of possible noise. Moreover, Webots also doesnot allow the cross-compilation of such functionality in such awaythat one cannot program real platforms using the microphone.h li-brary fromWebots API.

To overcome this problem, the following steps were followed:1. Copymicrophone.h from (WEBOTS-HOME)\include\controller\c

\webots to (WEBOTS-HOME)\transfer\e-puck\libepuck\include\webots

2. Include the a_d/advance_ad_scan/e_micro.h library from e-puckAPI to libepuck.c

http://www.gctronic.com/doc/index.php/E-Puck#Serial_communication


Fig. 6. Image adapted from e-puck’s webpage www.e-puck.org depicting theconfiguration of e-puck’s microphones.

3. Edit the DeviceTag wb_robot_get_device accordingly and definenew tags to identify and enable each microphone as:

4. Add the following line to the C-files sources in the newMakefile.include presented in Section 3.2:

5. Create the following functions on libepuck.c:

While the first two functions from the last point are straight-forward, as they only enable and disable the microphone identi-fied by dt with a refresh rate ofms to avoid useless processing, thelast function deserves a deeper attention. The corresponding func-tion on Webots returns an array representing the reception of theemitted array by the speaker from another virtual e-puck.

For instance, on e-puck_sound demo, e-puck_1 (emitter) sendsan 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].If far away from e-puck_1 (emitter), e-puck_2 (receiver) mayreceive 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 near from e-puck_1 (emitter), and due to the multiple reflec-tions on the walls, e-puck_2 (receiver) may receive an array 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].

This is obviously not realistic at all as many other phenomena in-fluence the sound propagation. As any other wave, the sound ishighly affected by its surroundings which are far from being per-fect (e.g., surrounding noise). Moreover, the addition of obstaclesabsorbs part of the sound passing through, usually through con-version to heat energy [10]. At least, one should highlight that thevalues received by the real e-puck’s microphones do not float be-tween −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 ateach reading but yet to return the difference between the high-est and lowest intensities from the last MIC_SAMP_NB samples, inwhichMIC_SAMP_NB is defined as 100 by default. This allows over-coming the surrounding noise and, most importantly, the noisearising from the own platform during navigation. Such a value canbe directly retrieved using the function e_get_micro_ volume froma_d/advance_ad_scan/e_micro.h library from e-puck API.

This variation turns out to present similar results from bothsimulated and real worlds. Some preliminary tests were carriedout with two platforms on both simulation and real environments.One of the platforms (e_puck_1) was programmed as sound emit-ter (cf., next section) while the other (e_puck_2) as a sound receiver(i.e., using the microphones). The e_puck_ 1 was programmed toconstantly emit the same ‘‘haa’’ sound sequence (cf., next section)while standing in the same position. The e_puck_2 was pro-grammed to output the readings from the microphones while get-ting 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 printffunction used for debugging also developed in this work (cf., Sec-tion 4.2).

Fig. 7 compares the median value of a set of 10 trials with realplatforms with a trial from the simulated case (note that this lastone does not consider noise being therefore deterministic). As onemay observe, despite the evident existence of noise from the realexperiments, the captured sound decreases with the distance in avery similar fashion. The data was truncated for distances to thesound source above 200 mm since the difference starts to be con-siderably large as the microphones under the real experiments arehighly influenced by the sound coming from robot’s movements.

The next section describes the speaker implementation.

3.4. Speaker

The e-puck robot is equipped with a speaker on top of it (Fig. 1)connected to an audio codec. Combinedwith themicrophones, thespeaker can create a communication network with the ability todetect the direction of peers. It is also an excellent output devicefor the human interaction [4]. Due to speed processing reasons, theinternal functions of the speaker package are written in assemblyand a small selection of predefined sounds is available in the filecodec/e_const_sound.s. Five sounds are organized as Table 3 depicts.

Those sounds are only available in the real robots as previouslydescribed since the sound system within Webots is still experi-mental. Despite this drawback, one may emulate such sounds us-ing the swis2d plugin and the most adequate arrays of data forvirtual reproduction. Nevertheless, before this, it is necessary toenable Webots functions on cross-compilation.

Webots does not allow the cross-compilation of speakers’ func-tions in such a way that one cannot program the real platformsusing the speaker.h library from Webots API. To overcome thisproblem, the following steps were followed:1. Copy speaker.h from (WEBOTS-HOME)\include\controller\c\

webots (Webots API) to (WEBOTS-HOME)\transfer\e-puck\libepuck\include\webots (e-puck API)

2. Add the following function to speaker.h located on

http://www.e-puck.org


Fig. 7. Comparison between the data acquired by e-puck’smicrophones on both real and simulation experimentswhile getting far away from the sound source. The capturedsound decreases with the distance similarly on both experiments despite some noise occurring in the real experiments (namely between 90 and 120 s and 180 and 200 s).

Table 3Available sounds within e-pucks API.

ID Sound Words on codec/e_const_sound.s(beginning, length):

1 ‘‘haa’’ [0, 2112]2 ‘‘spaah’’ [2116, 1760]3 ‘‘ouah’’ [3878, 3412]:4 ‘‘yaouh’’ [7294, 3732]:5 ‘‘wouaaaaaaaah’’ [11028, 8016]:

3. This function should also be included in speaker.h from(WEBOTS-HOME)\include\controller\c\webots although withsome more programming (described in more detail below)

4. Include the codec/e_sound.h library frome-puckAPI to libepuck.c5. Edit theDeviceTagwb_robot_get_device() accordingly anddefine

a new tag to identify the speaker:

6. Add the following line to the C-files sources in the new Make-file.include from (WEBOTS-HOME)\transfer\e-puck\libepuck\presented in Section 3.2:

7. Add the following line to the ASM-files sources in thenew Makefile.include from (WEBOTS-HOME)\transfer\e-puck\libepuck\ presented in Section 3.2:


As opposed to the microphone functionalities, the speaker re-quires the addition of low-level assembly functions (ASM) to pro-vide access to the audio codecs. Henceforth, the ASM-files sourceson point 7 need to be added to the Makefile.include. It is also note-worthy that, without the new programming architecture proposedin Section 3.2, this would not work as the e-puck would be unableto load the audio codecs and, as a result, it would constantly resetwhen it tried to load them.

The main e-puck’s firmware libepuck.c needs to be once againextended to provide the user with the speaker functionalities. Be-sides the wb_speaker_emit_sample that was already created intoWebots API, the newly created wb_speaker_play also needs to bedefined. The first time any of those functions are called, the low-level function e_init_sound is also automatically called only once topermit the access to the audio codecs. Regarding the wb_speaker_emit_sample, and due to its functionality within Webots, this wassimply used as a relay to reproduce the predefined sounds pre-sented in Table 3 based on the range of the first value of the arraydefined by the user. Note that this is highly limited and unrealis-tic but, as previously mentioned, the e-puck does not allow play-ing sounds that are not on codec/e_const_sound.s. Therefore, it ishighly recommended to avoid the call of the functionwb_speaker_emit_sample directly. Instead of doing that and defining arrays thatcannot be reproduced on the real robots, it is advised to call thewb_speaker_play instead. Note that this function intrinsically calls thewb_speaker_emit_sample based on some experimentally validatedarrays (see below). By calling wb_speaker_play, the only necessaryinput is the argument soundID that will receive values between 1and 5 according to the ID column from Table 3. This will automat-ically call the low-level function e_play_sound receiving as inputsthe words beginning and length on codec/e_const_sound.s also ac-cording to Table 3.

Contrarily to the speaker.h located on (WEBOTS-HOME)\transfer\e-puck\libepuck\include\webots (e-puck API) in which the 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 (WebotsAPI) needs to be fullydeveloped to emulate the predefined sounds within codec/e_const_sound.s (Table 3).

The argument soundIDwill then receive values between 1 and 5according to Table 3 as previously described and, depending on thechoice, a different sequence of arrays will be loaded and emittedusing 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 neighbor e-pucks of the sounds describedin Table 3. Note that while a sequence consists of 3 arrays of 80elements each enough to describe the first 4 sounds, the last onerequires 11 arrays of 80 elements each.

Some tests were carried out with two platforms on both sim-ulation and real environments. One of the platforms (e_puck_1)was programmed as sound emitter playing the 5 sounds presentedin Table 3 successively. The other (e_puck_2) was programmedas a sound receiver (i.e., using the microphones described in the


Fig. 8. Comparison between the data acquired by e-puck’s microphones on both real and simulation experiments playing the sequence of predefined sounds presented onTable 3.

previous section). Both e_puck_1 and e-puck_2 were programmedto stand in the same position at a distance of 10 cm from eachother’s center. The e_puck_2 was programmed to output the read-ings from the microphones using the printf function used for de-bugging also developed in this work (cf., Section 4.2).

Fig. 8 compares the median value of a set of 10 trials with realplatformswith a trial from the simulated case. As onemay observe,despite the existence of noise from the real experiments, the simi-larity between sound emission, and consequently reception, undersimulation and real experiments is evident.

Going deeper into e-puck’s compatibility extension withWebots, the next section describes how to obtain inter-robot com-munication on both simulation and real experiments using theBluetooth interface.

3.5. Communication

Despite e-puck’s features, its communication capabilities didnot receive the proper attention from the community, mainly be-cause the Bluetooth interface was conceived to provide commu-nication between the CPU and the e-puck (e.g., for programming).Therefore, several alternatives to the basic configurationwere pro-posed over the last years. The first one was the Range and BearingTurret (e-RandB) allowing e-puck to communicate locally at shortdistances of up to 80 cm with infrared communication [11]. Al-though it was quite an interesting solution,more than just having avery limited communication range, the infrared signals are greatlyaffected by obstacles and environment lighting conditions. Also,such wireless technology presents itself as a bottleneck in termsof communication rate. For instance, the solution provided by [11]only allows a maximum communication rate of 30 bytes/second.Alternatively, a ZigBee turret was proposed to promote swarmrobotics using e-puck platforms [9]. This turret allows the creationof networks of e-pucks and has the major advantage over all otheralternatives of adjusting its communication range between 15 cmand up to 5 m. By controlling the communication range in sucha way, one may perform experiments in space-limited laboratorysettings to deeply study communication constraints on the algo-rithms. Despite all the positive features of this extension, it is alaboratory project and, as such, it is unavailable in the market. Amore commercial alternative for the e-puck is the Gumstix Overoturret.9 By using this extension, the e-puck robot is endowed with

9 http://www.gctronic.com/doc/index.php/Overo_Extension.

a Linux operating system with all the processing power and theimmense possibilities of it once compared to the embedded mi-crocontroller. Hence, this extension clearly leverages the capabili-ties of the e-puck robot. However, it also significantly leverages itscost. Disregarding this last issue, this is themost adequate strategyto follow if one wishes to benefit from inter-robot communicationsince the turret provides the typicalWiFi 802.11 communication. Asthis work rests on the low-cost applicability, the Bluetooth inter-face from the basic configuration will be explored on both simula-tion and real robots. Nevertheless, before looking at the technologyitself, let us first understand the inter-robot communicationmech-anism behind Webots.

The Webots environment already comes with libraries thatprovides a communication interface between virtual e-pucks. Al-though those libraries are only from Webots API and cannot beused for cross-compilation purposes, they still provide some inter-esting features as radio or infrared modeling. The main differenceresides in the fact that infrared communication takes obstacles intoaccount and allows defining an opening angle of the emission cone.As we will be focusing on Bluetooth, the radio model was the ob-vious choice.

In brief, two libraries fromWebots API need to be included intothe user-created project for inter-robot communication: the emit-ter.h and the receiver.h. Sending data using the radiomodel (defaultof the libraries) is as easy as defining the maximum communica-tion range using the function wb_emitter_ set_range and send thedesired information with wb_ emitter_send. The wb_emitter_sendfunction adds to the emitters’ queue a packet of size bytes locatedat the address indicated by the data one wishes to share. The en-queued data packets are then sent to potential receivers and re-moved from the emitter’s queue. Receiving data using the radiomodel is also simple. At first, one needs to enable it (as any otherinput device) by using thewb_receiver_enable function followed bythe wb_ receiver_get_data.

The wb_receiver_get_data function returns the data of thepacket at the head of the reception queue. The returned datapointer is only valid until the function wb_receiver_next_ packetis called. Besides those, other useful functions may be used suchas the wb_receiver_get_queue_length to control the reception ofnew data and the wb_receiver_get_ signal_strength to retrieve thestrength of the signal that may be closely related to the typicalreceived signal strength indication (RSSI) usually available on realwireless equipment. Note that the emitter/receiver libraries fromWebots API do not impose any particular format on the data being

http://www.gctronic.com/doc/index.php/Overo_Extension


Fig. 9. Inter-robot communication within Webots. The data flows from right (emitter) to left (receiver), using a classical packet queue. The variable t corresponds to thecurrent time. The receiver (left) processes a data packet sent at t − m − n.

transmitted. Anyuser chosen format is suitable, as long as the emit-ter and receiver codes agree. Also, only robots within the samechannel can communicate. This may be seen as a frequency for aradio emitter settled by the function wb_emitter_set_channel. Theemitter then needs to define a positive channel number for inter-robot communication with the receiver.

Fig. 9 illustrates the inter-robot communication architecture onWebots. For the purpose of the Bluetooth extension herein pre-sented, the radio channel of the wb_emitter_set_channel functionwas defined with the e-puck unique ID (cf., the next section). Thevariable t corresponds to the current time. This means that the re-ceiver will currently process a data packet sent at t − m − n. Itis noteworthy that Webots does not assume any kind of delays re-garding the establishment of a new communication link or the sizeof a given message.

In spite of the efficient communication paradigm from We-bots, this may not be compared to the real Bluetooth communica-tion that e-puck possesses. The e-puck’s National SemiconductorLMX9820A Bluetooth module is quite limited when compared toother equivalent modules available in the market for the last 5years. In fact, the e-puck’s Bluetooth interface was only designedfor CPU-robot communication for programming and, eventually,debugging. It does not allow the creation of piconets with morethan 3 nodes (including the master node) as opposed to the typ-ical 7 nodes and, as a consequence, it does not allow the creationof scatternets. Therefore, due to its hard limitations, the most ade-quate use of this module within multi-robot applications, namelyon swarm robotics, consists on a robot-to-robot communication. Inother words, every message pushed into the emitter buffer of onee-puck should be directly sent to the receiver buffer of the linkede-puck, thus emulating a cable as depicted in Fig. 9.

Nonetheless, this is not a simple process as it requires the emit-ter e-puck to first inquiry for Bluetooth devices, identify the onesfrom e-pucks, select the desired e-puck and establish a Serial PortProfile (SPP) link. Only then, if all the process is successful, theemitter e-puck can send the data. However, the receiver e-puckneeds to know that one of its teammates wants to share informa-tion in such a way that it needs to wait for the SPP link to be estab-lished and for the message to be available in the buffer.

That kind of robot-to-robot Bluetooth communication withine-pucks was only addressed so far by GCtronic company and onNasser’s Thesis [12]. However, note that those works were notmotivated on yielding a common ground between Webots and e-pucks, i.e., theywere only centered on e-puck real platforms.More-over, 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 an SPP connection tobe established and a message to be available in the buffer. Also,the algorithm presented by the authors does not allow creating anSPP link to a specific e-puck, only to the first one detected. Suchassumptions cannot be hold underMRS, especially when consider-ing applications in which robots exchange messages only sporadi-cally [13].

Henceforth, some adjustments were carried out to the mainBluetooth library to enhance the compatibility between simulatedand 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 in more detailbelow)

3. Edit the wb_robot_get_device() accordingly anddefine the new tags to identify the receiver and the emitter:


As we go deeper into bringingWebots closer to e-pucks’ reality,the required level of expertise also increases. The Bluetooth com-munication functionality is the one that requires themost from thedeveloper. Contrarily to the previous extensions in which only theWebotsAPI and e-puckmain firmware functionwere edited, in thisstep one will need to edit the main Bluetooth library from e-puckAPI, the e_bluetooth.c file. Those changes may be summarized bysimply editing the e_bt_recv_SPP_data function and creating a newfunction e_bt_connect_ epuckID.

The first function will be improved by adding an inactivitythreshold Trec to prevent the stagnation of e-pucks while waitingfor a message or SPP link. Note that this threshold consists of the


Fig. 10. Flowcharts for Bluetooth communication between a pair of e-pucks. The data flows from right (emitter) to left (receiver), by first establishing an SPP link betweenrobots and then sharing the message.

number of 1-byte readings the e-puck does to its own buffer and,therefore, should be considerably high (an inactivity threshold ofTrec = 106 presented good results).

The addition of the second function e_bt_connect_epuckID al-lows for the emitter to choose a specific receiver by indicatingits unique ID (cf., the next chapter for a more detailed descrip-tion). Hence, the ID of the receiver is defined as an input argu-ment of the function bymeans ofwb_emitter_set_ channel function.The e_bt_connect_epuckID then calls the e_bt_find_epuck functionthat retrieves the e-puck robots from the list of all Bluetooth de-vices found by the low-level Bluetooth function e_bt_inquiry. After-wards, the desired e-puck is selected from that list so as to establishthe SPP link with it using the function e_bt_etablish_SPP_link andshare the data using the function e_bt_send_SPP_ data. If the re-ceiver e-puck is not on the list of Bluetooth devices found bythe emitter then an error code superior to 0x00 is returned (theLMX9820A datasheet may be consulted for more details about theerror).

Despite the number of functions one needs to add to the mainfirmware libepuck.c, the code is far from being complex. The firsttwo functions only enable and disable the receiver. As any otherinput device on Webots and to avoid irrelevant processing, thisfunctionality was implemented on the receiver device. The wb_receiver_get_data that allows virtual e-pucks to receive data onWebots follows a simple successive call of functions from thee_bluetooth.c library including the e_bt_recv_ SPP_data.

Regarding the emitter, the wb_emitter_set_channel function al-lows us to choose the receiver e-puck based on its unique IDwhile the wb_emitter_get_channel allows us to retrieve the lastteammate chosen as the receiver by the emitter e-puck. 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 ofe-pucks. In the case of establishing an SPP link by the emitter, athreshold Temi was also introduced to prevent its inactivity. On thiscase, and due to the amount of information exchanged betweenthe emitter and the receiver, a small number of Temi = 3 presentedgood results with a similar pause time then for the receiver case ofTrec = 106.

Fig. 10 depicts the flowchart describing the real communicationprocess that can be seen as a low-level translation of Fig. 9 to real-world e-pucks. Variables trec and temi are simple counters that arereset to 0 before eachmain blocks, i.e., ‘‘Wait for SPP link’’ and ‘‘Waitto receive SPP message’’ or ‘‘Create SPP link’’ and ‘‘Send SPP message’’,respectively.

As one may observe, the process, especially on the side of theemitter, is somehow complex. Associatedwith this comes the timenecessary to fulfil each one of those operations. For instance, thewhole process on the emittermayvary between around19.8±4.5 s(results retrievedwithin the experimental setup depicted in Fig. 11for 53 successful exchangedmessages), inwhich amajor part of the


-30 -20 -10 0 10 20 30

a

b

Fig. 11. Comparison between inter-robot communication on both real and simulation experiments using Bluetooth to acknowledge the reception of the sound: (a) virtualand real setups; (b) positional acknowledgment of the received sounds and least-squares fitness of ellipses. Both ellipses are similar, thus suggesting a close realism betweenthe simulated and the real world.

time is spent on searching for Bluetooth devices and creating theSPP link with the desired e-puck. With that in mind, we know thatinter-robot communication within real e-pucks correspond to aspecific pause time (i.e., inactivity) that is neglected onWebots. De-spite this difference, the possibility of exchanging data in an aperi-odic fashion on both simulation and real experimentswith e-puckssignificantly increases the assortment of multi-robot applications.

As in the previous sections, a small experimental setup to testthe robot–robot communication was settled on both real and We-bots environment. This scenario makes use of all the presentedextended functionalities. The receiver e-puck was placed at thecenter of a 60 × 60 cm field while the emitter e-puck was placedat one of the corners of the field. The receiver e-puck did not moveduring the entire trial of 6 min runtime (i.e., excluding pause timesdue to Bluetooth communication) and continuously reproducedthe sound ID 5 from Table 3, periodically from 5 to 5 s. The emit-ter was programmed with a random walk behavior and Braiten-berg collision avoidance algorithm [14]. This behavior was adaptedfrom the existing standard controller e-puck.c, which already in-cludes e-puck’s Braitenberg coefficients. The emitter e-puck wasprogrammed to listen to any sounds at each step of the algorithmby benefiting from the average output value returned by the threemicrophones (Fig. 6). The emitter e-puckwould then send themes-sage ‘‘I hear you’’ to the receiver e-puck each time the level of ac-quired sound exceeded an intensity of 60 (cf., Fig. 8).

The data compared under both simulation and real experimentswas the emitter e-puck’s position each time it was able to capturethe necessary sound intensity. It is noteworthy that the trajectoryaccomplished by the virtual and real emitter e-pucks will not bethe samedue to the stochasticity inherent to the adopted approach.However, it is expected that, in a steady-state regime, the overalldistribution of the planar coordinates to be identical.

By neglecting the pause times inherent to the Bluetooth com-munication on the real scenario, the experimental results depicta similar distribution of the points in which the emitter e-puckwas able to hear the receiver e-puck (Fig. 11). To better compare

the experimental results as a whole, particularly the positional ac-knowledgments of the received sounds, the least-squares fitting ofellipses to 2D points was adopted [15]. This allows to analyze notonly 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-puckwas from the receiver e-puck.

As one may observe, both area and rotation of the ellipses arevery similar, thus suggesting a close realismbetween the simulatedand the real world. However, it is interesting to observe that in the6 min runtime, the virtual emitter e-pucks tried to share its mes-sage with the virtual receiver e-puck 65 times against the 58 timesfrom the real e-pucks. This may be explained by the discrepanciesof sound propagation for larger inter-robot distances (cf., Fig. 7).Also, on those 58 times the real emitter e-puck tried to commu-nicate, it was only successful to effectively communicate with thereal receiver e-puck 53 times. In all occasions this happened be-cause the emitter was unable to find the desired e-puck receiver,i.e., ‘‘Search for the desired e-puck’’ block from Fig. 10. Although thiscould be improved by creating a loop of trials, this block consumesa major part of the whole inactive time of the emitter e-puck. Inother words, the communication pause time would critically in-crease with such a strategy. Hence, such a strategy was discardedsince it was possible to achieve a communication success of almost90%. It is also interesting to note that each time the emitter e-puckwas able to establish communication with the receiver e-puck, allpackets were successfully delivered.

However, e-puck’s Bluetooth solution may only be employedon multi-robot applications that only require sporadic communi-cation between robots (e.g., some swarm robotic algorithms) since,as previously stated, exchanging a singlemessagemay take around19.8 ± 4.5 s. Therefore, for applications in which robots needto constantly share messages, such as multi-robot exploration inwhich robots need to cooperatively map a shared environment,the standard Bluetooth is seen as unfeasible. Those applications re-quire robots to benefit froma communication network, either froma pre-existent infrastructure or ad hoc, in which a unique identifier


Fig. 12. System architecture of the e-puck robot equipped with Gumstix Overo COM. The laptop (on top) acts as the TCP/IP server running a custom-made graphical userinterface. The e-pucks (bottom) equipped with Gumstix Overo COM (middle) act as TCP/IP clients.

should be addressed to each robot for direct and fast inter-robotcommunication. The most common wireless technology that bal-ances a large bit rate with a high degree of compatibility with ex-isting infrastructures (e.g., access points) is theWiFi IEEE 802.11. Inspite of this, the e-puck platforms were equipped with the Gum-stix Overo COM turret, thus benefitting not only fromWiFi commu-nication but also from higher CPU processing power with a Linuxembedded system and other sensing capabilities. The next sectiondescribes a methodology to benefit from such features.

4. e-puck Gumstix Overo COM

The e-puck’s Gumstix Overo COM board is mostly an interfacebetween the e-puck robot and the Gumstix Overo COM developedby Gumstix. The main idea is to have a small, highly reliable andsecure off-the-shelf Linux computer-on-module on top of e-puckrobots. Between the several features that this extension adds to e-puck robots, theWiFi communication is the most attractive one.

Developing code on the Gumstix Overo COM for e-puck robotscan be simply explained by following these steps:

1. Copy the folder tcpsercom provided by this work to the PC10

(note that this folder already contains all dependencies frome-puck API that may be necessary to compile code for e-puckrobots).

2. Develop a standard Linux application using, for instance, C pro-gramming (any text editor like Notepad++ for Windows willwork) (e.g., tcpsercom.c).

10 http://www2.isr.uc.pt/~micaelcouceiro/media/Overo.rarhttp://www2.isr.uc.pt/~micaelcouceiro/media/ReportFinal_2.pdf.

3. Edit theMakefile on the root of the downloaded folder based onany other dependencies and name of the source file developed.

4. Compile the codeusing Sourcery CodeBench forARMGNU/Linux11(note that either case the downloaded folder already comeswith the necessary compilers).

5. Copy the file generated by the compilation (e.g., tcpsercom) tothe MicroSD card and put it back in Gumstix Overo COMboard.

6. Plug the PC to the Gumstix Overo COM using the Console inter-face and execute a terminal program (e.g., minicom on Linux orputty on Windows) and configure the connection with a baudrate of 115200.

7. Wait for the Gumstix Overo COM to boot (approximately 30 s)and login with user root and password root (it is however ad-vised that you skip the login step for faster development ofMRSapplications12).

8. Navigate to the directory of the MicroSD card and run the codeby simply writing its name and, if it is the case, input parame-ters of the source file.

Fig. 12 depicts our system architecture of e-puck robotsequipped with Gumstix Overo COM boards. Note that although itmay not seem ideal to have a central PC to coordinate all the in-formation, as laboratory platforms the e-puck have limited mobil-ity and, henceforth, limited applicability in real-world applications.Therefore, to manage and emulate potential failures or even radiofrequency signal propagation, a TCP/IP server, i.e., network man-ager, is required.

11 http://www.codesourcery.com/sgpp/lite/arm/portal/release1039.12 http://wiki.gumstix.org/index.php?title=AutoLogin.

http://www2.isr.uc.pt/~micaelcouceiro/media/Overo.rar

http://www2.isr.uc.pt/~micaelcouceiro/media/ReportFinal_2.pdf

http://www.codesourcery.com/sgpp/lite/arm/portal/release1039

http://wiki.gumstix.org/index.php?title%3DAutoLogin


Fig. 13. Graphical user interface of the e-puck Network Manager. Besides acting as a TCP/IP server, it also allows emulating certain phenomena, such as limiting thecommunication range between e-pucks or the maximum number of hops supported by the network.

4.1. E-puck network manager

The main idea behind the e-puck Network Manager is to actas a global server to serve all TCP/IP socket clients (i.e., e-pucks),concurrently. However, more than just establishing and receivingsocket connections, this servermanages themessages and forwardthose to the correct e-puck(s). Moreover, it also allows us to em-ulate constraints from wireless networks such as the maximumdistance between one-hop robots and the maximum number ofhops in the network. Although many other properties of phenom-ena could be emulated on the server side only those twowere con-templated so far. Nevertheless, one can easily extend the softwarepresented in this work with other features such as radio propaga-tion modeling, delays or even abrupt losses of communication.

The graphical user interface presented in Fig. 13 was designedon MatLab with the purpose of being user friendly and efficient interms of TCP/IP clients’ management as it uses an internal inter-ruption based on the bytes available at the TCP/IP socket buffer. Inother words, a single interruption function is executedwhenever abytes-available event occurs, regardless of the TCP/IP client send-ing the data. This bytes-available event occurswhen the terminatorCR is received.

The most relevant features of the e-puck Network Manager arehighlighted in Fig. 13. The association of each IP to the e-puck’s ID iscrucial as it is based on such association that the packet forwardingwill be managed.

Note that to consider the network properties, namely thedistance between hops and the maximum number of hops, it isnecessary that the e-pucks include their own position (even if onlyestimated by means of odometry) on the data packet. This willallow us to calculate the adjacency matrix and, subsequently, themultihop connectivity matrix.

The connectivity between e-pucks was described bymeans of alinkmatrix L =

lijfor anN-nodenetwork,whereinN corresponds

to the total number of e-pucks on the network (‘‘e-puck List ’’). Eachentry represents the ‘‘link’’ between nodes (i.e., e-puck) i and j.The link is defined accordingly with the distance between pairs ofnodes indicating the link distance between them [16]. An adjacencymatrix A =

aij

can then be defined based on the maximum

distance between e-pucks, respectively [17]. The adjacencymatrix,i.e., one-hop connectivity matrix, where a 1 entry at (ij) indicates aconnection between e-pucks i and j and a 0 entry at (ij) indicatesno connection between e-pucks i and j, represents the neighbors ofeach node, i.e., direct connection between robots.

aij =

1, connection between node i and j0, no connection between node i and j. (1)

Note that the diagonal elements (i.e., when i = j) of the adja-cency matrix are set equal to 0.

If onewants to configure the communication system to supportthe relay ofmessages to distant nodes via intermediate nodes, thenthe ‘‘Max. number of hops’’, let us call itK , should be configuredwitha value superior to 1 for multi-hop connections. Using the hop dis-tances, i.e., the smallest numbers of hops to connect non-adjacentrobots, the zero-valued off-diagonal entries in the adjacency ma-trix can be manipulated in order to create a multi-hop connectivitymatrix C (k)

=

c(k)ij

, for which the entry at (ij) represents themin-

imum number of hops necessary to connect e-pucks i and j, and krepresents the iteration which varies with the number of hops thenetwork can handle, i.e., K . N − 1 is the maximum number of pos-sible hops. If K is defined with a larger value than N − 1, then thesuperior threshold of N − 1 will be considered. The calculation ofthe connectivity matrix can be defined as:

c(k)ij =

h, node i connected to j by h 6 k hops0, otherwise. (2)

Note that the diagonal elements of the connectivity matrix (i =

j) are set equal to 0. Furthermore, the adjacency matrix is thefirst iteration in calculating the connectivity matrix (C (1)

= A).When k > 1 (i.e., for multi-hop connections) an auxiliary matrixB(k)

=

b(k)ij

is then calculated based on the iteration (number of

hops):

b(k)ij =

0, c(k−1)

ij > 0

k,N

t=1

c(k−1)it b(k−1)

tj > 0 and c(k−1)ij = 0.

(3)

Note that the diagonal elements (i = j) of the auxiliary matrixare set equal to 0 and (B(1)

= A). The connectivity matrix can nowbe calculated using the following equation:

C (k)= C (k−1)

+ B(k). (4)After K iterations, C (K) represents the multi-hop network con-

nectivity defined by the user. The existence of zero elements (ex-cept diagonal elements) indicates no connection between e-pucksi and j even using multi-hop of K hops.

By configuring the network according to the requirements ofthe user, one may fulfil realistic experiments with the e-puck plat-formswithout being constrained by their smallmobility or by size-limited laboratorial environments. About this brief description ofthe TCP/IP server, let us now discuss the implementation of theTCP/IP client corresponding to each e-puck robot.

4.2. E-puck TCP/IP client

The Gumstix Overo COM is generally equipped with either theZyxel or the Edimax WiFi dongles. While the first one is straight-forward and do not require any sort of initialization, the Edimax


Fig. 14. Script file to connect the e-puck to aWiFi network.

WiFi dongle requires to load the Kernelmodule to create thewlanXdevice, X ∈ N0. To do so, it is advised to copy the 8192cu.ko filelocated on home/root to the MicroSD card root (media/mmcblk0p1)in an initial stage of development to hasten tests and, afterwards,to etc/init.d to automatically start on boot (Fig. 3). To initialize justtype insmod 8192cu.ko on its location. This will then return thewlanX device identified by the Gumstix Overo COM board. After-wards, by using the typical Linux ifconfig and iwconfig commandsone can configure the network as it would do it on a regular CPU.

Tomake the whole process simpler, a script as the one depictedbelow can be created and copied to the MicroSD card root (me-dia/mmcblk0p1) in an initial stage of development and, afterwards,to etc/init.d to automatically start on boot (Fig. 5). In this example,the Kernel returned wlan8 device and we are trying to connect toa network called epuckNet with theWEP key 1234567890 in whichthe gateway has theMAC address 00:24:B2:BB:3F:B4 and IP address192.168.0.1. Note that such a network may be either created bythe TCP/IP socket server (PC) or by a different device in which theserver is simply connected with (e.g., access point, router).

It is noteworthy that each different e-puck will have a differentscript file as the one presented in Fig. 14. This is only natural as eache-puck has different hardware and also requires a different IP. It istherefore advised to first load theWiFi dongle Kernel to retrieve thewlanX device necessary to create the script.

Although the efficient communication paradigm from Webots,this may not be compared to the real wireless communication.First, the proposed approach should be as flexible as possible so asto allow Bluetooth communication in case the user do not have theturret extension. Second, if the Gumstix Overo COM board is avail-able, then theWiFi communication should support not only robot-to-robot communication as the Bluetooth approach (cf., previousreport) but also broadcast to thewhole network, i.e., robot-to-teamcommunication.

The first requirement was accomplished by means of the ModeSelector switch (Fig. 1). By selecting position 0 (default), one canbenefit only from Bluetooth communication (e-puck’s standardconfiguration). Note that, in this case, inter-robot communicationwill be slower and should be minimized due to the necessary timeto establish a Serial Port Profile (SPP) link between two robots.Moreover, robot-to-teamcommunication is not possible under thisapproach. By selecting position 10 (or A), the e-puck will benefitfrom the WiFi communication intrinsic to the Gumstix Overo COMboard.

In the case of robot-to-robot communication, a similar strategythan the one followed in Section 3.5with the Bluetooth technologycan be carried out. In other words, every message pushed into theemitter buffer of one e-puck should be directly sent to the receiverbuffer of the desired e-puck as depicted in Fig. 9 (Section 3.5),emulating a cable connecting both robots.

In the case of robot-to-team communication, as previouslymentioned, the only thing that changes within Webots simulatoris that the channel is defined as−1. To maintain a constant config-uration of the message in the first 5 bytes, this is simply translatedto the ID value 9999 at e-puck’s firmware libepucks.c.

At the receiver e-puck, the data message is extracted from thedata packet and directly returned calling the function wb_ re-ceiver_get_data. A delay of Trec = 106, corresponding to 3 s, was de-fined to avoid the e-puck from getting stuck on this function whilewaiting for messages. If by the end of those 3 s the e-puck doesnot receive anything, then the function wb_ receiver_get_data willreturn an empty value (NULL).

When the function wb_emitter_send is called with Mode Selec-tor in position 10 (or A), the e-puck’s firmware libepucks.c cre-ates the data packet as presented in Fig. 7 and directly sends thewhole string through RS-232 serial interface (UART2). This is ac-complished by using the function e_send_uart2_char from e-puckAPI. To read the incoming data from theUART2 one can simply ben-efit from the sertest.c code available fromGumstix Overo COM pack-age.13 This code simply forwards the data received from e-puck’sUART2 directly to the console and vice-versa.

The next step consists of directly forwarding the same datausing TCP/IP sockets to the server. This can be accomplished bycreating a TCP/IP socket client using the typical system librariessys/types.h, sys/socket.h, netinet/in.h, arpa/inet.h and netdb.h. Thesefunctionalities are implemented on the code tcpsercom.c providedwith this work.

The whole communication layer can be briefly explained inFig. 15. As it is possible to observe,most of the decision-making andhigh level processes are implemented on e-puck’s microcontroller(bottompart of the flowchart). The upper part of the flowchart por-traits the forwarding mechanism implemented on Gumstix OveroCOM.

This section outlined the extension of e-puck robots so as to en-dow them with WiFi communication capabilities, thus increasingthe scope of applications inwhich those platformsmay be used for.As previously accomplished, let us now compare an MRS experi-ment under Webots simulator and real e-pucks using WiFi com-munication.

4.3. Experimental evaluation

To effectively evaluate the proposed extension, a large popula-tion of e-pucks would be required. Even though inWebots simula-tion the communication between e-pucks is 100% efficient as it isfree of failures or any phenomena such as reflection or refraction,in real experiments such efficiency starts dropping after a consid-erably large number of network nodes due toWiFi intrinsic limita-tions. Although in theory a structured WiFi network may supportup to 2007 nodes, the quality starts dropping after some few hun-dreds of nodes for a single access point [18].

In the real experiments conducted in this section, only up to 14e-puck were used due to budget restrictions. Under those condi-tions, and considering that all messages follow a TCP/IP protocol,none of the 2000 packets exchanged between e-pucks was lost.Hence, as a quantitative measure, only the processing time to han-dle the communication procedure, i.e., pause time was consideredin this section.

To that end, each e-puckwas programmedwith a randomwan-der algorithmwith collision avoidance inWebots and deployed ona 2.0 × 1.8 m experimental setup (Fig. 16). To test the inter-robotcommunication delays, different teams between 2 and 14 e-puckwere deployed in the scenario. Each e-puck communicated after 5 swith the receiver and emitter channel defined as −1 to broadcastto the whole network.

13 http://projects.gctronic.com/Gumstix/sertest.tar.gz.

http://projects.gctronic.com/Gumstix/sertest.tar.gz


Fig. 15. Flowcharts for WiFi communication between e-pucks. The data flows from right (emitter) to left (receiver), by forwarding the message coming through RS-232 toWiFi in the emitter and fromWiFi to RS-232 in the receiver.

Fig. 16. Experimental setup with 14 e-pucks.

The pause time inherent to the whole communication proce-dure was retrieved with a timer to count the time before enter-ing the function that allows for an e-puck to send the data packets

and the time for another e-puck to receive the same data packet.This was monitored at the server level through the e-puck NetworkManager. Fig. 17 depicts the results obtained using teams of up to14 e-pucks. As it is possible to observe, and as expected, the pausetime increases with the number of e-pucks. However, such a rela-tionship is not linear as a major part of the time is spent when ane-puck tries to share its data to the server and vice-versa. In otherwords, the processing time of the e-puck Network Manager can bealmost neglected and having an e-puck communicating with a sin-gle teammate orwith 13 teammates does not significantly increasethe pause time (average difference of 5 ms). Although being farfrom real mobile wireless networks, this feature makes it possi-ble to carry out experiments under several assumptions, emulatingeither a pre-existent infrastructure of communication or a mobilead hoc network by controlling the delay between exchanged mes-sages.

5. Discussion

Inspired by the results of existing cooperation in the various bi-ological societies (e.g., ants, bees, plants, humans and others), re-searchers have placed considerable effort in developing robots that


2 3 4 5 6 7 8 9 10 11 12 13 14

number of e-pucks

175

170

165

160

155

paus

e tim

e [m

s]

Fig. 17. Boxplot of the pause time vs the number of e-pucks. The pause timeincreases with a proportion of approximately 1% for each incremental e-puck.

are able to cooperate and perform tasks that could only be per-formed using multiple robots. Nevertheless, the development ofsuch multi-robot systems (MRS) is considerably more challengingthan single robot solutions. For instance, in MRS, in order to ac-complish a given task such as finding an object, robots must shareinformation about what they are sensing [2]. This, and many otherspecific features inherent toMRS, demands for a higher implemen-tation cost and a higher development time. To overcome such de-mands, a majority of the research conducted over the last yearson robotics has been centered on robotic simulators. However, thepracticality of robotic simulators has been more than once ques-tioned due to the lack of consistency between simulation and real-world results. InMRS, such consistency needs to be handled by theadequate implementation of several real-world features such assensor noise, robot dimensions and actuators nonlinearities.

From the several robotic simulators available in themarket, Cy-berbotics Webots [3] is one of the most well-known and respectedcommercial simulators available in the market. Webots simula-tor can use C, C++, Java, Matlab and Python to create the controlprograms which can be implemented in real life robot platformslike the e-puck [4], thus supporting several sensors like odome-try, range, camera, light and touch. Despite those functionalities,Webots is still unable to realistically benefit from all the featuresthat make the e-puck as one of the most used mobile robots inboth education and laboratorial domains. In spite of those draw-backs, this article reports an extension ofWebots and e-puck cross-functionalities that significantly increases the range of applicationsone may conduct on both real and virtual experiments, as well asthe similarity between both worlds.

This article starts by proposing a new programming/compilingWebots architecture. Instead of just compiling the user-developedC-controllers by benefiting from Webots libraries (Webots API),the new architecture gives total control to the user, thus compilingthe e-puck’s firmware that encompasses all low-level functions (e-puck API). This paradigm shift is achieved by simply creating a newMakefile called by Webots cross-compilation tool in its graphicaluser interface.

The second and final contributions of this article concerns theinclusion of a set of functionalities that aims at improving thecross-compatibility between virtual and real experiments withmultiple e-pucks under theWebots framework. This is achieved byfirst introducing the capability to access a unique e-puck identifierand a debugging mechanism using serial communication. Thosetwo subsidiary functionalities are considered to be mandatory onMRS experiments, for remote monitoring and debugging of user-developed controllers [19].

Afterwards, it is presented the integration of a new sensingcapability of the e-puck under Webots simulator—the array of

microphones. To benefit from e-puck’s sound source localizationproperties, this article presented a step-by-step description of itsimplementation, strengthening it by validating the responsivenessof the threemicrophones located on top of the e-puck (Fig. 6) underboth simulation and real experiments (Fig. 7). As Fig. 7 depicts,despite someminor discrepancies related to background noise, thesimilarity between simulation and real experiments is remarkable.As a future direction, the addition of audio noise (e.g., white noise)should be considered.

This is naturally followed by the integration of the speakeractuation mechanism of the e-puck mobile robot under Webotssimulator. Combined with the microphones, this may allowcreating a communication network with the ability to detect thedirection of peers or even foster thehuman–robot interactionusingthe e-pucks [4]. Similarly as before, thiswas achieved by benefitingfrom the swis2d plugin developed at EPFL and the development ofnew libraries to extendWebots API. Moreover, the inclusion of thespeaker required the compilation of low-level assembly functions(ASM-files). As Fig. 8 depicts, despite the existence of noise fromthe real experiments, the similarity between sound emission, andconsequently reception, under simulation and real experiments isevident. Nevertheless, the addition of new predefined sounds isa necessary future direction as it is now limited to 5 (Table 3).Moreover, the possibility to create new sounds from a given datavector should also be considered.

Afterwards, this article presents the integration of the Blue-tooth communication under both simulation and real-world ex-periments. Note that this functionality has not been sufficientlyaddressed in the past as the e-puck Bluetooth communication wasexclusively designed to program the robots. As such, this last con-tribution required a higher level of complexity, in terms of im-plementation, as both Webots and e-puck APIs were manipulated.The experimental results under both real and virtual worlds illus-trated in Fig. 11 show the potential of the Bluetooth communica-tion for sporadic explicit robot–robot communication. However,some improvements may still take place, especially with regard toe-puck’s limitations. For instance, as the Bluetooth interface wasnever designed for robot–robot communication, it still presentssome drawbacks that one may try to address. The required timeto establish a link between pairs of robots is unsuitable for experi-ments that require a high bit rate for shared information betweendifferent robots. Moreover, it is impossible to create awireless net-work that many multi-robot systems require. In other words, theuse of e-puck platforms on multi-robot applications is confinedto systems with sporadic explicit communication between robots(e.g., swarm robotics). Nevertheless, such limitation may be over-come by benefiting from e-puck turrets available in the market.

As such, this article gave a closure to its contribution on Sec-tion 4 by changing Webots and e-pucks APIs so as to support theWiFi capabilities of the Gumstix Overo COM. To do so, both TCP/IPclient and server architectures were presented, thus aiming for ap-plications wherein a mobile communication network is necessaryover sporadic communication. Experimental results with up to 14e-pucks were carried out to highlight the advantages inherent to aWiFi network over the previous experiments under the Bluetoothcommunication.

6. Conclusion

Themain contribution of this article to the robotics society is theextension of the cross-compatibility between Webots simulatorand e-puck robotic platforms, thus increasing the range of multi-robot applications on both virtual and real worlds. Merging both e-puck and Webots APIs addresses the common problem roboticistsoften face on finding a consistent environment to simulate exper-iments with multiple robots. The functionalities presented in this


article are transparent for Webots users and do not change any ofthe programming structure and style adopted so far on the devel-opment of applications using the e-puck. The changes are only ob-servable when one wishes to cross-compile the code developed onthe virtual environment to program the real e-puck platforms.

This newextensionnowallows forWebots users to benefit frommicrophones, speaker and robot Bluetooth communication thatwere beforehand inaccessible. Furthermore, this article also pre-sented a step-by-stepmethodology to enableWiFi communicationusing virtual and real e-pucks by benefiting from theGumstix OveroCOM turret.

The consistency of the experimental results obtained on bothvirtual and real worlds regarding those functionalities now meetthe necessary requirements to consider Webots as an easily, read-ily usable environment to fulfil experiments with e-pucks’ fullfunctionalities. Although such mechanisms may not greatly im-prove single robot experiments, the literature highlights the needof more sensing capabilities and ways of RRI to foster the develop-ment of multi-robot systems.

Acknowledgments

This work was supported by a PhD scholarship (SFRH/BD/73382/2010) granted to the first author and the research projectCHOPIN (PTDC/EEA-CRO/119000/2010), both funded by the Por-tuguese Foundation for Science and Technology (FCT ). This workwas made possible by the School of Mathematical and ComputerSciences from Heriot–Watt University that provided the necessaryresources to conduct the experiments.

Appendix A. Supplementary data

Supplementary material related to this article can be foundonline at http://dx.doi.org/10.1016/j.robot.2014.05.007.

References

[1] M. Reckhaus, N. Hochgeschwender, J. Paulus, A. Shakhimardanov, G. Kraet-zschmar, An overview about simulation and emulation in robotics, in: Pro-ceedings of SIMPAR 2010 Workshops Intl. Conf. on Simulation, Modeling andProgramming for Autonomous Robots, Darmstadt, Germany, 2010.

[2] L.E. Parker, Multiple mobile robot systems, in: Springer Handbook of Robotics,2008, pp. 921–941.

[3] O. Michel, Webots: professional mobile robot simulation, J. Adv. Robot. Syst. 1(2004) 39–42.

[4] F. Mondada, M. Bonani, X. Raemy, J. Pugh, C. Cianci, A. Klaptocz, S.Magnenat, J.C. Zufferey, D. Floreano, A.Martinoli, The e-puck—a robot designedfor education in engineering, in: Proceedings of the 9th Conference onAutonomous Robot Systems and Competitions, 2009.

[5] M. Freese, S. Singh, F. Ozaki, N. Matsuhira, Virtual robot experimentationplatform V-REP: a versatile 3D robot simulator, in: 2nd InternationalConference on Simulation, Modeling, and Programming for AutonomousRobots, SIMPAR 2010, in: Lecture Notes in Computer Science, vol. 6472,Springer, Darmstadt, Germany, 2010, pp. 51–62.

[6] M. Quigley, B. Gerkey, K. Conley, J. Faust, T. Foote, J. Leibs, E. Berger,R. Wheeler, A. Ng, ROS: an open-source robot operating system, in:International Conference on Robotics and Automation (ICRA’09)Workshop onOpen Source Software, Kobe, Japan, 2009.

[7] F. Rohrer, Curriculum of Exercises for E-puck and Webots, EPFL, Swiss, 2008.[8] L. Guyot, N. Heiniger, O. Michel, F. Rohrer, Teaching robotics with an

open curriculum based on the e-puck robot, simulations and competitions,in: Proceedings of 2nd International Conference on Robotics in Education(RiE’2011), Vienna, Austria, 2011.

[9] C.M. Cianci, X. Raemy, J. Pugh, A. Martinoli, Communication in a swarmof miniature robots: the e-puck as an educational tool for swarm robotics,in: Proceedings of Simulation of Adaptive Behavior (SAB-2006), SwarmRoboticsWorkshop, Rome, Italy, in: LectureNotes in Computer Science (LNCS),4433, 2006, pp. 103–115.

[10] I. Herman, Sound, hearing and thehumanvoice, in: Physics of theHumanBody,Springer, 2007, pp. 87–98.

[11] Á Gutiérrez, A. Campo, M. Dorigo, F. Monasterio-Huelin, J. Donate, Open e-puck range & bearing miniaturized board for local communication in swarmrobotics, in: Proceedings of the IEEE International Conference on Robotics andAutomation, Piscataway, NJ, 2009.

[12] M.I.B.M. Nasser, On E-Puck Mobile Robots for Distributed Robotics, NationalUniversity of Singapore, Singapore, 2010.

[13] M.S. Couceiro, R.P. Rocha, N.M.F. Ferreira, P.A. Vargas, Darwinian roboticswarms for exploration with minimal communication, in: IEEE Congresson Evolutionary Computation (CEC’2013), Special session on EvolutionaryRobotics, 2013, Cancún, México, 2013.

[14] V. Braitenberg, Vehicles, in: Experiments in Synthetic Psycology, The MITPress, 1984.

[15] A.W. Fitzgibbon,M. Pilu, R.B. Fisher, Direct least-squares fitting of ellipses, IEEETrans. Pattern Anal. Mach. Intell. 21 (5) (1999) 476–480.

[16] W. Sheng, Q. Yang, J. Tan, N. Xi, Distributed multi-robot coordination in areaexploration, Robot. Auton. Syst. 54 (2006) 945–955.

[17] L.E. Miller, Multihop Connectivity of Arbitrary Networks, in: WirelessCommunication Technologies Group, NIST, 2001.

[18] J.S. Lee, Y.W. Su, C.C. Shen, A comparative study of wireless protocols:bluetooth, UWB, ZigBee, and Wi-Fi, in: Proceedings of the 33rd AnnualConference of the IEEE Industrial Electronics Society (IECON ’07), 2007,pp. 46–51.

[19] N. Michael, J. Fink, V. Kumar, Experimental testbed for large multirobotteams—verification and validation, IEEE Robot. Autom. Mag. 15 (1) (2008)53–61.

Micael S. Couceiro obtained the BSc, Teaching Licensureand Master degrees on Electrical Engineering (Automa-tion and Communications), at the Engineering Institute ofCoimbra, Polytechnic Institute of Coimbra (ISEC-IPC). Hereceived his Ph.D. on Electrical and Computer Engineeringat the Faculty of Sciences and Technology of University ofCoimbra (FCT-UC), in April 2014.

He has been conducting scientific research on severalareas besides robotics, namely computer vision, sports en-gineering, economics, sociology, digital media, and others,all at the Artificial Perception for Intelligent Systems and

Robotics (AP4ISR), Institute of Systems and Robotics (ISR-UC).

Patricia A. Vargas received her Ph.D. on Computer Engi-neering from the University of Campinas, Unicamp (Brazil)in 2005. She is currently Director of the Robotics Lab-oratory and Lecturer in Computer Science and Roboticsat the School of Mathematical and Computer Science atHeriot–Watt University (Edinburgh, Scotland, UK). Shewas a post-doc at the Centre for Computational Neu-roscience and Robotics, University of Sussex (England,UK) for 3 years. Her research interests include Evolution-ary and Bio-inspired Robotics, Swarm Robotics, Computa-tional Neuroscience, Data Mining and Machine Learning,

Biologically-inspired algorithms and Human–Robot Interaction.

Rui P. Rocha completed his Ph.D. degree on May 2006, atthe Faculty of Engineering of the University of Porto. Be-tween February 2000 and May 2006, he was a TeachingAssistant at the Department of Electrical and ComputerEngineering, in the Faculty of Sciences and Technology ofthe University of Coimbra. Currently, he is an AssistantProfessor at the Department of Electrical and ComputerEngineering and a researcher at the Institute of Systemsand Robotics, in the Faculty of Sciences and TechnologyUniversity of Coimbra. His main research topics are co-operative Multi-Robot Systems, 3-D Map Building, Dis-

tributed Architectures and Intelligent Transportation Systems.


http://refhub.elsevier.com/S0921-8890(14)00096-7/sbref2














bridging the reality gap between the webots simulator and e-puck robots

Documents