Mechanics of the e-puck

Simple mechanics

To reach the goals of the project (low price and robustness) the mechanics has to be very simple and elegant. The structure has been therefore based on one single part (followings pictures) ensuring the structure of the whole robot.

This basic part has a diameter of 70 mm and ensures the support of the motors, the printed circuit and the battery. The battery is located under the motors and is connected to the printed circuit by two vertical contacts. The battery can be easily extracted and recharged externally.

Motor

The choice of the motors is crucial for this purpose. On the e-puck design we decided to use miniature steppers motors with gear reduction. The motor has 20 steps per revolution and the gear has a reduction of 50:1. The final axis is sufficiently strong to support directly the wheel.

Wheels

The wheels diameter is about 41 mm.  The fixation is made by a four teeth chuck. There is a bras peaces insert in the plastical wheele. A green o ring is used as tire. The distance between the wheels (mounted) is about 53 mm. The maximum speed of the wheels is about 1000 steps / s, which corresponds to one wheel revolution per second.

Electronic design

The electronics was designed to support a large number of possible uses of the robot in a context of university level education. The following structure has been implemented in the actual version:

Short description of the main components around the processor:

• Single power supply. All electronics runs at 3.3V, excepted the camera needing an additional 1.8V.
• An extension connector allows to add new functionalities on an extension board.
• The robot is equipped with a RS232 and a bluetooth interface to communicate with a host computer.
• A 16 positions rotating switch allows an input from the user, for instance to set a running mode.
• Reset button and programming connector as usual.
• The battery is based on LiION technology, has 5Wh capacity and is sufficient for about 2-3 hours of intensive use. The battery can be removed and recharged externally. A battery protection is implemented.
• 8 IR proximity sensors are placed around the robot but not in a regular way (more sensors in front of the robot).
• A 3 axis accelerometer is placed inside the robot.
• Three microphones and a speaker allow sound capture and generation.
• A camera with a resolution of 640x480 color pixels is placed inside the body and looks forward.
• Can be used only through windowing or subsampling.
• 8 red leds are placed around the robot body to diplay patterns.The camera should be able to see them.

Processor

The choice of the processor is crucial for this robot. To enable nice programming, use of standard compilers (GNU) and have good computational power we made the choice of the dsPIC family from microchip. This microcontroller has a lot of very nice interfaces and has a dsp core allowing very efficient data processing. It is a very nice processor for education because of the nice structure (registers, set of instructions).

Sound sensors

The e-puck robot is equipped with three microphones placed as illustrated here:

Acquiring the three microphones, the maximal acquisition speed is 33kHz (A/D maximal frequency of 100kHz divided by three). A sound wave at 1kHz emitted from a computer speaker in front of the robot is acquired by the microphones as following:

If the same sound comes from the left, the data acquired is the following:

If the same sound comes from the right, the data acquired looks as following:

The quality of the signal is of course very dependent from the type of sound source. The microphones of the e-puck are not very senstive. This is the reason of the first tests using a "big" computer speaker. Taking a small speaker (another e-puck) placed at 130 mm of the robot on the left side, the sound (1kHz) acquired looks as following (please note the amplitude and the noise of the signal):

Here you can find the sound definition file that was used with the standard library to generate the sound on the second e-puck.

The FFT of this last signal shows well the main frequency (1kHz) but shows also a noise frequency at 11kHz... this is perhaps due to a resonance peak at 11kHz of the e-puck speaker.

Accelerometer

The e-puck robot is equipped with 3D accelerometer placed as illustrated here:

Next figure is the data acquisition when taking the e-puck and putting it back on a table making a circular mouvement in YZ plan direction (on the horizontal axis you have the sample number, on the vertical axis the values acquired on the three axis):

Next figure is the data acquisition with a 3D random movement (on the horizontal axis you have the sample number, on the vertical axis the values acquired on the three axis):

When the robot moves, the steppers motors perform a given number of steps per seconds. At each step there is a strong micro-acceleration and micro-deceleration of the robot. Next figure shows the acceleration measured by the accelerometer and due to the stepper motor when moving at 70steps/s. Sampling is made at 7kHz. On the X axis there is the sample number.

Proximity sensors

The e-puck robot is equipped with 8 IR proximity sensors placed as illustrated here:

Next figure is the raw data aquisition of IR0 (a front sensor) when the robot starts againts a wall and goes backwards. The X axis shows the number of steps of distance from the wall. 1000 steps correspond to 12.8cm.

Next figure is the computed sensor information (reflected light - ambient light) data aquisition of IR0 IR1 IR6 IR7 (the four front sensors) when robot is going backwards from a wall. The X axis represents the number of steps. 1000 steps correspond to 12.8cm.

The next three figures show some noise on the sensor measurement due to the activity of the stepper motor turning at 100steps/s 400steps/s and 800steps/s. Sampling is made at 64Hz. This noise comes from the power supply of the e-puck. It seem to increase when battery is going down.

Camera

The camera has a resolution of 640(h)x480(l) pixels and is color. The full flow of information this camera generates cannot be processed by a simple processor like the dsPIC on the robot. Moreover the processor has 8k of RAM, not sufficient to even store one single image. To be able to acquire the camera information, the image rate has to be reduced and the resolution too. Typically we can acquire a 40x40 subsampled color image at 4 frames per second.Without color we can go up to 8 frames per second. Not more. But you can also acquire another type of image, for instance a line of 480x1 color pixels on the ground facing the robot.

Here are some examples of images taken with the e-puck monitor program:

This first image is taken from a distance of 60 cm with a zoom of 8 (means a pixel every 8).  Max sampling is 4.3 fps.

Here the distance is the same as above (60 cm) but zoom factor is 4 (one pixel every 4). Framerate is same as zoom 8 (4.3 fps).

Here the distance is the same as above (60 cm) but zoom factor is 1 (every pixel is taken in the region). Framerate is lower (1.3 fps) because the speed is given by the acquisition rate of the processor.

Last image is the same but in grayscale. Same distance, but with higher framerate (8.6 fps).

You can of course choose a non square picture (here 80 x 20) and get more data in one direction.

Communication

Bluetooth and e-puck

The dsPIC, e-puck's microcontroller, has two uarts. The first one is connected to a bluetooth chip and the second one is physically available through a micromatch connector. The bluetooth chip, LMX9820A, can be used to access to the uart "transparently" using a bluetooth rfcomm channel. Using this mode, one can access the e-puck as it was connected to a serial port, with the exception that the LMX9820A will send special commands upon connection/disconnection. The user application must take them into account.

How to communicate with the e-puck

This section is only about communicating with an e-puck running a user program, not using the bluetooth bootloader.

Setting up a fake serial connection using bluetooth rfcomm under Linux

In order to setup a fake serial connection using bluetooth rfcomm with your e-puck under Linux, you will need the following:

• A USB bluetooth dongle
• a recent 2.4 or 2.6 kernel
• the following packages: bluez-firmware bluez-pin bluez-utils

The lsusb, hciconfig, hcitool and rfcomm commands are very useful to test the presence of a USB bluetooth dongle connected to your Linux box and to setup the connection with the e-puck:

# lsusb
# hciconfig
# hcitool scan
# l2ping
# rfcomm release rfcomm0
# rfcomm bind rfcomm0
# rfcomm connect rfcomm0

You will also need to edit your /etc/bluetooth/rfcomm.conf config file to add entries corresponding to your e-puck robots:

rfcomm0 {
bind yes;
device 08:00:17:2C:E0:88;
channel 1;
comment "e-puck_0006";
}

And possibly restart the bluetooth service:

# service bluetooth restart

A PIN number will asked to you (by bluez-pin) when trying to establish the connection. This PIN number if a 4 digits number corresponing to the name (or ID) of your e-puck. I.e, if you e-puck is called "e-puck_0006", then, this number is 0006.

If you are not asked for a PIN number and you get a message like: "Can't connect RFCOMM socket: Connection refused", it may be because the PIN number is given automatically by the PC to the e-puck without prompting you. In this case, you should edit your /etc/bluetooth/hcid.conf and change the "security" parameter from "auto" to "user". Then, you may need to restart bluez-util:

# /etc/init.d/bluez-utils restart

Fly-Vision Turret

Printed Circuit Board Layout:

Base PCB Features: There are 6 connectors for the 3 cameras, allowing several different camera configurations depending on the task Oscilloscope test points are available for all camera signals and can be used for debugging A connector is available for an optoinal analogue gyroscope module (to be used for OF calculation) or any other analogue sensor

Camera Configurations:

This configuration can be used to avoid obstacles during forward motion	This configuration is useful for corridor-following algorithms	This configuration provides near-omnidirectional vision using a camera pointed backwards

Detailed schematics and PCB gerber files for the Fly-Vision Turret are available on the Download Page .

This extension was designed at the Laboratory of Intelligent Systems (LIS) at EPFL.

Ground Sensors

The Ground Sensors extension is comprised of three Infrared (IR) proximity sensors pointed directly at the ground in front of the e-Puck. These sensors are mounted on a small PCB which is placed in the slot near the front of the e-Puck's plastic base. The PCB also includes a microcontroller that continually samples the IR sensors. The value of the sensors can then be read by the e-Puck through the I2C serial interface.

The Ground Sensors can be used for many different applications, such as following a black line on a white surface, surface-detection below the robot, or fall-detection. This extension is currently being used for a student exercise in the Bio-Inspired Adaptive Machines course taught by Prof. Dario Floreano at EPFL.

	The front of the e-Puck with a Ground Sensor module
	A close-up view of the module
	The three IR sensors are spaced out on a horizontal line

Detailed schematics and PCB gerber files for the Ground Sensors can be found on the Download Page .

The user manual (by AAI Canada) of this extension is on the download page also.

This extension was designed at the Laboratory of Intelligent Systems (LIS) at EPFL.

Colour LED Communication Turret

The Colour LED Communication Turret is part of a visual communications system currently being developed by the Laboratory of Intelligent Systems (LIS) at EPFL. The LED Turret is composed of 8 sets of 3-colour Light Emitting Diodes (LEDs), each set containing a blue, red and green LED. These three colours can be mixed together at different strengths to produce hundreds of different colours in any pattern imaginable. The LEDs are all controlled using 24 separate Pulse Width Modulated (PWM) signals generated by an on-board PIC18F6722 (Microchip) microcontroller.

The Colour LED Communication Turret circuit board with side-mounted LEDs

The firmware on the PIC can control each LED individually for maximum flexibility, or in a synchronised fashion to send the same signal from every angle. The user simply has to set a few parameters (such as the maximum brightness, blinking period, and rising slope) though the I2C interface, and the firmware then generates the PWM signals by itself!

Some of the many colours that can be produced by the LED Turret

The LED Turret can also display different colours on each LED group at the same time

The other part of the visual communication system is an omni-directional camera turret that is used to read signals produced by other robots' LED turrets. This camera turret is currently in prototype development at LIS.

Detailed schematics and PCB gerber files for the LED Turret will soon be posted on the Download Page .

This extension was designed at the Laboratory of Intelligent Systems (LIS) at EPFL.

ZigBee Comm Turret

This ZigBee ready communication turret was designed by Xavier Raemy in the Swarm-Intelligent Systems (SWIS) group lab of Alcherio Martinoli . It consists of a MSP430 microcontroller running TinyOS and a Chipcon CC2420 2.4Ghz transceiver. The turret communicates with the robot using the I2C bus. An accompanying board allows the module to be programed via USB.

In the event that you find the information presented here useful, or use a communication module based on this design for obtaining experimental results, we kindly request that you cite the following paper as the official reference:

Cianci C., Raemy X., Pugh J., and Martinoli A., “Communication in a Swarm of Miniature Robots: The e-Puck as an Educational Tool for Swarm Robotics”. Proc. of the SAB 2006 Workshop on Swarm Robotics, September-October 2006, Rome, Italy. To appear in Lecture Notes in Computer Science (2007).

Hardware details

This module is a re-designed custom version of the MoteIV TmoteSky. The principal goal was to reduce the RF range to as low as several centimeters; such that interesting experiments could be performed in a space-limited laboratory setting (on a table, for instance). In order to achieve this, we have added an RF attenuator of ~25dB between the antenna and the CC2420 transceiver. Using this, combined with the ability of the CC2420 to reduce its transmission power at runtime, we have a software-adjustable range of approximately 15 centimeters to 5 meters. The module also includes the following hardware features: Software controlled bypass of the added hardware attenuation. 4Mbit of flash memory connected via SPI to the MCU An I2C decoder allows users to put the MCU in "bootloader programming mode" using an I2C command. The serial lines used for programming the MCU are connected to the Bluetooth UART lines from the e-puck. It is therefore theoretically possible to ask the DsPic to put the MCU in programming mode using an I2C command, and then reprogram the turret using the Bluetooth connexion of the robot. (not yet tested). 3 Leds (Red, Yellow, & Green)

Software details

Currently, the MCU runs TinyOS 1.x, but it can run TinyOS 2.x.

Because the harware is not identical the the TmoteSky one, we had to create a new "platform" within TinyOS, a module for controlling the hardware atternuator, and a I2C slave layer (by default, TinyOS doen't support I2C operating in "slave" or "multi-master" modes). These modifications will eventually need to be ported to TinyOS 2.x.

Performance

Range of communication :

• Min : ~15cm
• Max:  ~5m

Power consumption (3.3V):

• MCU only : 1.4mW
• MCU and radio module enabled (receiving) :   76.2mW

Omnidirectional Vision Turret

The Omnidirectional Vision Turret (OVT) was developed at the Laboratory of Intelligent Systems (LIS) at EPFL. The purpose of this extension is to provide basic omnidirectional vision capabilities to the epuck, without the expense of complex processing hardware. Using a simple microcontroller, the turret is capable of advanced vision tasks such as distinguishing colour blogs in any direction, finding other robots in its vicinity, and basic navigation.

Vision System

Omnidirectional vision is achieved using a standard perspective camera (the same VGA camera used on the e-Puck) looking up on a custom-designed hyperbolic mirror. The mirror was designed to provide a full 360 degree view around the robot, and can see up to 5 degrees above the horizon.

An added advantage of the OVT is that it is not a top turret! All the signals from the e-Puck are passed on to a top PCB using card-edge connectors, which allows other turrets to be stacked on top of the OVT.

Hardware

The CMOS camera is connected to a First-In-First-Out (FIFO) frame buffer (Averlogic AL440B-24-PBF), which is then connected to a microcontroller (dsPIC33FJ256GP506 from Microchip). The frame buffer allows de-coupling between the camera and the microcontroller, which means that the microcontroller is no longer a slave to the camera, and can read an image at whatever pace is required from the frame buffer.

Firmware

Several algorithms have been implemented, including basic drivers for reading an image from the camera, as well as image processing algorithms. There are two ways of reading the image:

• An entire image can be read in low resolution and stored in the memory of the dsPIC. An image of up to approximately 80x80pixels can be read this way.
• The image can be read line by line, and then processed before the next line is read. This allows for the full resolution of the camera to be used (480x480 pixels), but slows down the reading time of the image. Some image processing steps also require the entire image in dsPIC’s memory to work.

Some basic image processing algorithms have also been implemented on the dsPIC

• Image unwrapping (of both low-res images resident in memory, and high-res images being read line-by-line)
• Colour thresholding (only on images stored in memory)
• Edge detection (only on images stored in memory)

The firmware for the OVT will be posted on the download page once the bugs have been ironed out.

Detailed schematics and PCB gerber files for the Omnidirectional Vision Turret can be found on the Download Page .

This extension was designed at the Laboratory of Intelligent Systems (LIS) at EPFL.

Magnetic Wheels

This is a very simple extension consisting in adding some magnets on the bottom or replacing the wheels with a magnetic version.

Here a video of the system:

Here are some details on the implementation: For adhesion on ferromagnetic ceilings, only the wheels have to be modified. The magnetic wheel has the following shape (magnet in red):

The wheel is fixed to the axis like the standard wheel. The new wheel is in ferromagnetic iron. A 3D pdf file can be found here. On this file you can take measures for size.

To climb a wall, the standard e-puck motor has not sufficient torque. For this type of operation the motor of the e-puck (a custom PG15S-020 with a resistance of 18 ohm) need to be replaced with a more powerful motor (the standard PG15S-020 with a resistance of 10 ohm). Our custom and standard motors have been purchased by EME in Switzerland at 55CHF/sample.

Epuck Range and Bearing Board

The e-Puck Range & Bearing board (e-RandB) improves the existing relative localization/communication software library (libIrcom) developed for the e-puck robot and based on its on-board infrared sensors. The e-RandB has been developed in collaboration with Robolabo, Iridia and RBZ Robot Design.

The board allows situated agents to communicate locally, obtaining at the same time both the range and the bearing of the emitter without the need of any centralized control or any external reference. Therefore, the board allows the robots to have an embodied, decentralized and scalable communication system. The system relies on infrared communications with frequency modulation and is composed of two interconnected modules for data and power measurement.

The board can communicate with the e-puck through the Uart or I2C bus. It allows the user to select one of the two buses depending on which is already used by other extension modules. However, different frame rates are achieved depending on the communicaton bus. With the actual software version we are obtaining a 50 msg/sec with the Uart bus while 150 msg/sec for the I2C, where each message is made up of a 6 bits header, 16 bits for data and 4 bits crc.

All the information about the e-RandB is provided here

The e-RandB board is actually used at:

• ROBOLABO, ETSI Telecomunicación, Universidad Politécnica de Madrid, Madrid, Spain
• IRIDIA, CoDE, Université Libre de Bruxelles, Bruxelles, Belgium
• IDSIA, University of Applied Sciences of Southern Switzerland, Manno-Lugano, Switzerland
• LARAL, Institute of Cognitive Sciences and Technologies, CNR, Rome, Italy
• ISR, Instituto Superior Técnico, Lisbon, Portugal
• Self-Organizing Systems Research Group, Harvard University, Cambridge, MA, USA

E-RandB Files:

• Schematics (pdf)
• Assembling (pdf)
• Bill of Materials (xls)
• PCB (pdf)
• Hardware source files(zip)
• Fabrication: Gerber, pick and place, ... (zip)
• e-RandB manual (pdf)
• e-RandB firmware (zip)
• e-puck software and examples (tgz)

E-RandB Articles:

Its use and capabilities are demonstrated in the following papers:

• Álvaro Gutiérrez, Alexandre Campo, Marco Dorigo, Félix Monasterio-Huelin and Jesús Donate. Open E-puck Range & Bearing Miniaturized Board for Local Communication in Swarm Robotics. Proceedings of the IEEE International Conference on Robotics and Automation, May 2009, IEEE Press, Piscataway, NJ, In press.
• Álvaro Gutiérrez, Alexandre Campo, Marco Dorigo, Daniel Amor, Luis Magdalena and Félix Monasterio-Huelin. An Open Localisation and Local Communication Embodied Sensor. Sensors 8(11), pages 7545-7563, November 2008. ISSN: 1424-8220

Tutorial

Development on the e-puck can be learned through the tutorial.

Libraries

We have developed few simple libraries allowing to access to the hardware features. The following libraries are available:

• e-puck initialisation of basic hardware features
• management of proximity sensors
• motor speed control
• leds management
• accelerometer reading
• microphone sampling
• sound emition
• image acquisition

Release versions of the libraries are available at the e-puck snapshot.

Development versions of the libraries are available at gna. If you want to take part in their development, you can join the development mailing list.

Bootloader

We have a bootloader that works through bluetooth.

ASEBA

The ASEBA architecture allows to run scripts into the e-puck microcontroller keeping a good control on the code, allowing easy debugging and visualization of key variable and sensor data. A bridge between ASEBA and ROS has been implemented and allows a link with one of the most well known robotic programming environments.

Debug

Hardware online debug has to be done using an external programmer ICD2 from Microchip. But you can manage doing simple debuging by sending information trough bluetooth.

Communication protocol

We have implemented a serial communication protocol to control the e-puck via a serial RS232 line or bluetooth. This allows simple experimentation with code developed on a PC.

Demonstrations

We have a set of demonstration illustrating the use of several sensors of the robot in several typical applications.

Compiler and IDE

The dsPIC processor family is supported by the GCC GNU compiler collection as the PIC30 target.

Windows

Under Windows, the MPLAB environment from Microchip can be used with their C30 compiler, which is a version of GCC for dsPIC with some limitations. Those limitations can be removed by recompiling C30 from its sources.

To connect the ICD2 hardware to the e-puck you need to change the connector and use an e-puck (red 6 pins) connector. It’s a Tyco connector called Micro match, type is 7-215083-6 .

To upload the .hex files without the use of microchip's ICD, you can use the Tiny PIC bootloader.

Unixes

In Unixes, the piklab environment is available. Its web page provides instructions on how to get or build gcc for PIC30.

In addition, if you are running a Debian derivative (such as Ubuntu), there are instructions here on how to build cleans debs of latest PIC30 compiler (version 2.05). If you have troubles during compilation (particularly on Ubuntu, which uses dash as /bin/sh), please read the rest of the page as there is further explanations.

To upload the .hex files you have the choices of three Unix program:

• epuckuploadbt: a C++ program, requires libbluetooth to be compiled, but then is fully automatic, uses the discovery capabilities of bluetooth and does not require any changes in /dev
• epuckupload: a perl program, does not need to be compiled nor requires libbluetooth, but need a proper rfcomm link setuped.
• using piklab-prog (from piklab): it allows you to progam your e-puck using the ICD2. Instructions for ICD2 under Linux::
  

                      First, your user must have the rights to access the ICD2 hardware. To achieve this, you simply need to add these udev rules (this requires root privileges):
  
                      valentin@lsro1pc307:~$ cat /etc/udev/rules.d/26-microchip.rules
                      #PICKit
                      SYSFS{idVendor}=="04d8", SYSFS{idProduct}=="0032", MODE="0660", GROUP="microchip"
                      #PICKit2
                      SYSFS{idVendor}=="04d8", SYSFS{idProduct}=="0033", MODE="0660", GROUP="microchip"
                      #ICD2
                      SYSFS{idVendor}=="04d8", SYSFS{idProduct}=="8000", MODE="0660", GROUP="microchip"
                      #ICD21
                      SYSFS{idVendor}=="04d8", SYSFS{idProduct}=="8001", MODE="0660", GROUP="microchip"
  
                      Be sure that your user is added in the microchip group. This can easily be done using the following command (replace user by your actual username):
  
                      valentin@lsro1pc307:~$ sudo gpasswd -a user microchip
                      When this is done, do not forget to restart the udev service and maybe relog so that all changes are effective.
  
                      You can then use piklab-prog to program you e-puck with a .hex file:
  
                      valentin@lsro1pc307:~$ piklab-prog -p icd2 -d 30F6014A --target-self-powered --force -c program e-puck.hex
                      

 

ePic2

ePic2 is a complete framework to command the e-puck within Matlab. It allows its user to interact with the e-puck as he would do using the Windows' Hyper Terminal but improves on it by allowing the data gathered by the robot to be used as variables for Matlab's tools.

ePic2 can be used in two ways. The first is through its graphical interface that can be seen below. The interface offers basic commands over the e-puck and displays the values of the sensors. It also provides a way to execute controllers written in a M-File. The second method uses Matlab functions to command the robot from the Matlab's command line. This offers more control compared to the interface.

ePic2 is available on the e-puck svn in the tool section. It requires Matlab 7.1 or higher equipped with the Instrument Control Toolbox installed. It is nevertheless recommended to use the most recent version of Matlab to avoid some stability issues. Currently ePic can be used under Windows and Linux. It does not work under Mac Os as the necessary functions to connect to the e-puck are not supported on that platform.

ePic2 and its documentation can be found in the download section but it is highly recommended to download them from the tool section of the e-puck svn as it may contain a more recent version.

ePic2 is used for education purposes at EPFL in the course Mobile Robots. ePic is the main tool used for every exercise sessions whose details, including exercise sheets and source codes, can be found on the course website.

This software was developed at the Laboratory of Intelligent Systems at EPFL by Yannick Weibel, Julien Hubert and others contributors.

IR communication

Get it right now !

Here you can find the library and two examples. All material is made available under the GNU General Public License (GPL).

How to test the examples ?

With the libIrcom library 2 examples are provided : test and synchronize.

• Windows : Open project files located in synchronize or test folders. All necessary files are loaded, you can simply compile with mplab IDE then upload with the robots. We tested compilation with mplab 8.02.
  
  
• Linux : Before compiling the examples you have to compile all the libraries. Go to the root directory of the library and launch the compilation script by typing:
  > ./make.sh
  
  
• Test example : This example shows the comunication between two robots. One will be the emitter and the other the receiver. You will choose each one with the selector switch : 1-> Emiter 2-> Receiver.
  
  The emitter will start transmiting a sequence of numbers from 0 to 255 (1 byte) continuously.
  
  The receiver will take the frame and demodulate it. If the frame is well decoded the receiver will send it through bluetooth along with information about the location of the emitter of the message (orientation and distance). The orientation is expressed in the local mark of the receiver starting from the camera and going CCW. The distance is between the center of the 2 robots.
  
  Boths robots have to be connected to a computer through bluetooth and press enter to start the comunication between them.
  
  The code for the robots is located in libIrcomXXX/e-puck/src/test/. Go to the directory and type :
  > make
  
  The binary will be generated on libIrcomXXX/e-puck/bin/. Download the file to the robots :
  > epuckupload -f test.hex
  
  The code for the computer transmition is on libIrcomXXX/pc/ircomTest/. Go to the directory and type
  > make
  
  followed by
  > ./ircomTest
  
  Once you are connected to both robots, press enter and check the transmision.
  Good luck !
  
  
• Synchronize example : This example shows how a group of robots can communicate about directions where they are pointing to surrounding neighbours and end up aligned towards the same direction. The example is based on the libIrcom library. In a complete loop, the robots try to:
  
  i)  Send information: Because of the number of robots, each robot will first send his own ID, and after that his own direction related to the robots from which it has receive a message.
  ii)  Listen for some transmissions and decode the messages. If a message is an ID, it will store the direction where it cames from. If the message is an orientation addressed to it, it will change the orientation, according to this new information.
  
  The code for the robots is on libIrcomXXX/e-puck/src/synchronize/. Go to the directory and type:  > make
  
  The binary will be generated on libIrcomXXX/e-puck/bin/. Download the file to the robots :
  > epuckupload -f sync.hex

Troubleshooting

• Wrong messages received, or messages not received. Robots emit the same infrareds. So when several robots try to send in the same time, you are likely to receive only wrong messages. In addition, IR communications are slightly sensitive to light conditions. If you want to get close to 0 messages lost, try to work with controlled light, emitting few infrareds, and without oscillations.
  
  
• Timers. libIrcom is cpu consuming because it is monitoring very regularly the sensors. The interrupt used is set to a high priority which may superseed others. If you use agendas or any other interrupt, it is likely that some steps are lost. To cope with this problems of timing, we have implemented a time counter inside libIrcom (see ircomTools.c). libIrcom is the only tool that can give you accurate timings.
  
  
• Messages going through a robot or blocked by a wall. Infrared is light. Therefore a message can not be sent accross an opaque material. Given that e-pucks are transparent, it is possible that a message goes accross a robot. Do not expect that a robot is necessarily preventing messages to go through, make some tests, and restrict the communication range if needed.
  
  
  

More informations

Find more informations on https://www.e-puck.org, or ask to the e-puck community on GNA mailing lists : https://gna.org/projects/e-puck/

Contact the authors

We are interested by your work and would be happy to know what kind of exciting things you achieved with this tool. Let us know !
For specific requests you may also contact the authors of this software...

Alexandre Campo : alexandre (dot) campo (at) ulb.ac.be
Alvaro Gutierrez : aguti (at) etsit.upm.es
Valentin Longchamp : valentin (dot) longchamp (at) epfl.ch

Player driver

A Player driver has been developed by Renato Garcia and is available here.

Enki

Enki is a open-source, fast 2D physics-based robot simulator written in C++. It is able to simulate cinematics, collisions, sensors and cameras of robots evolving on a flat surface. It also provides limited support for friction. It is able to simulate groups of robots hundred times faster than realtime on a modern desktop computer.

ENKI webpage here

Webots

The Webots mobile robot simulation software now includes models of the e-puck robot and a bluetooth remote control interface working on all Windows, Mac OS X and Linux

A model of the e-puck robot is included in the Webots simulator.

The real and simulated e-puck control window in Webots

The e-puck.wbt model features accurate physics simulation (including inertia, friction, etc.).

A bluetooth connection between Webots and the real e-puck robot allows you to remote-control the real robot from your Webots controller programs (works currently under Linux, Windows and Mac OS X).

We are working on supporting also the cross-compilation of Webots controller programs so that you can execute the code on the robot microcontroller directly.

This software is being improved regularly. The current version models the following devices:

device	number	simulation	remote-control	botstudio	cross-compilation
DistanceSensor	8
LightSensor	8
LED	9
Wheels	2
Camera	1
Accelerometer	3
Bluetooth	1
Speaker	1
Microphone	3

V-REP

V-REP is a 3D robot simulator based on a distributed control architecture: control programs (or scripts) can be directly attached to scene objects and run simultaneously in a threaded or non-threaded fashion. This makes V-REP very versatile and ideal for multi-robot applications, and allows users to model robotic systems in a similar fashion as in reality - where control is most of the time also distributed.

Complex simulation can be created by making use of the various supported functionality, including:

- 2 physics engines support (Bullet and ODE)
- Full forward/inverse kinematics solver (handles any type of mechanism)
- Collision detection calculations
- Minimum distance calculations (mesh-mesh distance)
- Path planning (holonomic tasks in 2-6 dimensions and non-holonomic tasks for car-like vehicles)
- Proximity sensor simulation (exact minimum distance calculation within a customizable detection volume)
- Camera-like sensor simulation (fully customizable, with image processing capabilities)
- Various integrated edit modes (mesh edit modes, path edit mode, and custom UI edit mode)
- CAD data import/export (DXF, OBJ, 3DS or STL)
- Simulation data recording, graphing and export
- Various extension mechanisms (through scripts, plugins or a custom client application)

Here a video on the e-puck model running:

V-REP has various prices and licensing schemes. Students can use V-REP on their private computer free of charge.