E-Puck

From GCtronic Wiki

Jump to: navigation, search

Contents

Hardware

Revisions

There are two hardware revisions: HWRev.1 (models from 0 to 1499), HWRev.2 (models from 1500 on, production of June 2008). The two revisions differ slightly: in the HWRev.2 there is a newer camera and a newer bluetooth chip conforming to the Bluetooth 2.0 specification.
An easy way to distinguish between hardware revisions is to modify directly the EEPROM; this could be modified based on the camera model mounted on the robot and its orientation. On certain robot this modification is already applied and follow these rules: the modification apply only to the last word of the EEPROM, at address 0x7FFFFE; bits 14 and 15 are used to indicate the rotation (11=no rotation, 01=90 degrees, 10=-90 degrees) and bit 13 is used to indicate the camera model (0=PO3030, 1=PO6030); so for example:

  • 0xFFFF (0xFFF1111): PO3030 with no rotation
  • 0xFFFE (0xFFF1110): PO3030 turned by -90 degrees
  • 0xFFF9 (0xFFF1001): PO6030 turned by 90 degrees

The following example illustrates how to read this word: 

#include <DataEEPROM.h>

/*read HW version from the eeprom (last word)*/

int HWversion=0xFFFF;

int temp = 0;

temp = ReadEE(0x7F,0xFFFE,&HWversion, 1);

This file (.hex, src) can be used to update the EEPROM to the last hardware revision.

Specifications

The hardware specifications are valid for all e-puck models, except when explicitly specified with an hardware revision.

  • Motors:


Serial communication

The communication between the robot and the computer can be also handled with a serial cable; the serial connector position on the robot, the related cable and the electric schema are shown on the following figures.

In order to communicate with the robot through a serial line, the robot firmware must be implemented using the functions of the UART2 instead the one of UART1 (BT). All the functions implemented for the UART1 are also available for the UART2, so it's only a matter of changing the function call names. Anyway the standard demo (demoGCtronic_1.2.2.hex) contains already a mode that communicates over serial line selecting position 11; in this mode you can configure the BT.

Batteries

The last robot production comes with small differences regarding the battery; the type of battery is always the same but the mechanics of the positive pin is slightly different from one version to the other. The version with the black plastic cover comes out a bit more then the version with the brown cardboard cover.

The e-puck contact has been slightly modified to have a better contact with both version as shown in the following figure; see the Contact-modification.pdf document to get more information on how to apply this modification.

The charger makes contact with both versions, as illustrated below.

The positive pin has the tendency to get a bit oxidated and might need to be scratched a bit for a perfect connection.

Software

The embedded software running on the e-puck is continuously extended and managed under GNA using Subversion at svn://svn.gna.org/svn/e-puck/trunk; the SVN tree comprises a complete library to work with all the sensors mounted on the e-puck.
Additionally, a nice demo was implemented to start playing with the robot: demoGCtronic_1.2.2.hex, demoGCtronic_1.2.2.zip (depends on the previously mentioned library). There are various demo that could be started based on the selector position; here is the the demo corresponding to the selector position:

  • Selector position 0: Shock detection. Look at runaccelerometer.h for more information.
  • Selector position 1: Locate the sound source. Look at runlocatesound.h for more information.
  • Selector position 2: Follow the wall. Look at runwallfollow.h for more information.
  • Selector position 3: Advanced sercom protocol.
  • Selector position 5: Sensor "feedback display".
  • Selector position 6: Camera points to light.
  • Selector position 7: Act like the ASL RS232 - I2C translator.
  • Selector position 8: Show the ground direction. Look at rungrounddirection.h for more information.
  • Selector position 11: Bluetooth configuration (serial communication).
  • Selector position 12: Global test (serial communication).
  • Selector position 13: Uart1 to uart2 transponder.
  • Selector position 14: Follow what is detected by the two front proximities detectors. Look at runbreitenberg_adv.h for more information.
  • Selector position 15: Simple dust cleaner behaviour.
  • Other selector position: Avoid the obstacles. Look at runbreitenberg_adv.h for more information.

PC interface

Also an interface related to this demo (mode selector 3) running on a computer was developed:

Since the last version comprises a basic OpenGL representation of the e-puck you will need also the OpenGL extension libraries in order to compile the project; these should be included in the Qt SDK, but if you encounter problems refers to http://doc.trolltech.com/4.6/qtopengl.html#details; basically you need to download manually the OpenGL libraries: GLX (Linux), CGL (MacOS), WGL (Windows).
Once the project is built dynamically, some errors about missing dll may be thrown; one of these missing libraries could be the mingwm10.dll. Others could be related to Qt. To solve the problem you need either to build the project statically, or to register the libraries on the system, or to manually include all the dll with the executable.

Examples

Basic demos

The following set of simple programs for the e-puck has an increasing degree of complexity, from very basic LED blinking up to motor control depending on sensor input; it's a good starting point for beginner users. The first demos do not use interrupts and keep to a minimum the use of the library. You can download the set of these demos from this link BasicDemos.zip.

This set of simple programs, ready to perform and to be modified as you like, has an increasing degree of complexity. From very basic LED blinking up to motor control depending on sensor input. The first demos do not use interrupts and keep to a minimum the library used.

LIST OF BASIC PROGRAMS:

  • demo0: very simple LEDs blinking
  • demo1: LEDs blinking (pause with timer)
  • demo2: selector reading + LEDs
  • demo3: send selector position via Bluetooth (simplified method)
  • demo4: proximity reading with interrupts + LEDs
  • demo5: proximity reading with interrupts + LEDs + send values via BT (assembler version with interrupt and buffer)
  • demo6: motor speed controlled depending on front proximity sensor values

COMPILATION: The demos can be edited and compiled using MPLAB IDE (windows), clicking directly on the project file. The demos should be compiled with MPLAB-C30 on all operating systems. The compiled .hex file is downloaded to the e-puck robot via Bluetooth using for example tinyBootloader.

Audio recording

This demo program (hex file, MPLAB project) let the e-puck recording for about two seconds whatever you like and then reproduces it infinitely.
The program starts with a led animation (flow) and then turns all leds on for about two seconds, this is the moment for recording; note that only the right micro (mic0) is used.
It's possible also to choose the volume/amplification of the reproduction using the selector (from 1 to 16).

Still images

This demo program is optimized to let the robot handle images with resolution up to 640x480 pixels (the maximum reachable by the camera); after acquisition, the robot sends the images to a computer through bluetooth. This zip ImageReceiverBT.zip contains both the program for the robot (hex file) and the application for the computer (Windows platform). The selector of the robot must be in position 3.
You can find the sources for the application running on the computer side from this link ImageReceiverBTsrc.rar.
You can find the MPLAB project for the application running on the robot from this link DemoGCtronic-vga-images.zip.

Ground sensors

The main demo was extended to handle the ground sensors extension for the e-puck, this demo can be found in this link demo-groundsensors.hex. In order to get the values from the sensors you must put the selector in position 3 and then issue the command "m" that will return three values, one for each sensor.

Programming

If you are interested in development of embedded applications, you should firstly choose an adequate development environment. One of the most known IDE for Windows is MPLAB Integrated Development Environment that you could download for free from the Microchip site. If you prefer to work under Linux, you can choose to use Piklab.
Writing applications in C language, instead of assembly, is much more easier; for this reason you will need a C compiler for the dsPIC30F6014A, that is the e-puck's microcontroller. For Windows there is the MPLAB C Compiler for PIC24 MCUs and dsPIC DSCs (also known as MPLAB C30) for which there are special free versions for academic use and that integrates perfectly with MPLAB IDE; under Linux you can use the PIC30 toolchain.
Useful information for programming the e-puck can be found in the following documents:


Bootloader

  • Windows: tiny bootloader
  • Multiplatform: this bootloader requires that python and the pyserial module are installed in the system; in order to run the bootloader, type "python BootloaderGUI.py". This bootloader is adapted from the work done by Dr. Cédric Pradalier.

Test & Results

Bluetooth Communication Testing - PC to robot

Some tests were performed in order to analyze the bluetooth speed between a computer and the e-puck; the following three experiments were executed sending the same total amount of data but differently subdivided:

  • 19200 packets of 6 bytes each sent from computer to e-puck: about 65 seconds (BTspeed.zip)
  • 2560 packets of 45 bytes each sent from computer to e-puck: about 20 seconds (BTspeedPackets.zip)
  • 1 packet of 115200 bytes sent from computer to e-puck: about 10 seconds (BTspeedFile.zip)

Explanation: dividing a packet in small chunk of data (such as a single command) introduces pauses generated by the Bluetooth device of the PC. The mean measured delay time between a packet and the other is about 3 ms, but could be as high as 20 ms. Sending the packet in one single block like in the third experiment, has no pauses and thus needs exactly the theoretical time of 10 seconds for the channel at 115'200 Baud.

Bluetooth Communication Testing - robot to robot

Some tests were performed also to analyze the maximum speed reachable between two robots using direct communication, that is one acting as the master and the other as the slave. The Bluetooth 2.0 specification asserts 1 Mbit/s air data rate, but in practice with the Bluetooth protocol overhead the usable bandwidth is lower; moreover in our case there are others two facts to take in consideration:

  1. the communication between the robot and the BT chip is configured to be at 115200 bps
  2. the buffer handling system of the BT chip is capable of receive at maximum 200 packets per second (refers to UART buffer AN.pdf)

From the tests the resulting throughput is 18 Kb/s, sending a total of 41000 bytes with 41 bytes for each packet and waiting the response from the chip before sending the next packet; moving the slave device several meters away from the master influences the communication speed, that slows down.
The sources (MPLAB project) of the firmware used for this test can be downloaded from the following link DemoGCtronic-BT.zip.

Known problems

Re-flashing the bootloader on e-puck

In some cases it was reported that the internal bootloader on e-puck was corrupted due to a malfunction of the last code upload.
In those cases the bootloader (demo+bootloader.hex) has to be re-flashed on the robot via cable (see figure) with ICD2 and MPLAB IDE or compatible HW and SW.
See the procedure (Instruction re-program bootloader.pdf) and in case of need contact info@gctronic.com.

Uncorrect/unknown bluetooth PIN code

In a couple of rare cases it was reported that the PIN code of the Bluetooth chip was not anymore the usual one (same as e-puck number). It seems that the issue is linked to trials of robot to robot direct communication. One robot could have picked up the PIN of the other one, so you could try that PIN to get access to the robot.

Battery isolation

You should be careful when inserting and removing the battery of the e-puck in the robot or in the charger. Otherwise in the long run your battery will eventually lose its front isolator (plastic of cardboard), causing a possible short circuit. If you are already in this situation, you could try placing some isolation tape on the battery, as illustrated in the following figure. The correct procedure to insert and remove the batteries can be found in the following document Change-batteries.pdf. Basically you need to fully push in the battery compressing the springs before tilting the battery in the final position.

Bluetooth and MacBook

Some users experienced problems in connecting to the robot via Bluetooth using MacBook; using an usb BT dongle solved the problem most of the time. Some users instead experienced distance problems with the internal BT chip of the MacBook, that is the robot should be kept within 1.5 meters otherwise the connection is lost/slows down.

Links

http://www.e-puck.org/
http://www.cyberbotics.com/products/robots/e-puck.html
http://mobots.epfl.ch/e-puck.html
http://gna.org/projects/e-puck
http://en.wikipedia.org/wiki/E-puck_mobile_robot

Videos

Retrieved from "http://www.gctronic.com/doc/index.php/E-Puck"
Personal tools