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 versions 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; a snapshot can be downloaded from e-puck-svn-snapshot.zip (full SVN tree of August 2008). The SVN tree comprises a complete library to work with all the sensors mounted on the e-puck and is the basis for many demos.

Standard firmware

The robot is initially programmed with a firmware that includes many demos that could be started based on the selector position. The full code is available as MPLAB project from DemoGCtronic-complete.zip, otherwise if only the hex file is needed it is available from DemoGCtronic-complete.hex. Afterwards are listed all the demos and related selector position available in the standard firmware:

  • 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.

Project building

The standard firmware project is based on the e-puck library that can be found within the snapshot downloadable from e-puck-svn-snapshot.zip. The library folder and the project folder must be placed at the correct positions; since the project has relative references to the library, this is the only way to build the project without missing files problems, thus:

1) download and extract the SVN snapshot, let say in the folder SVN; you should have the following situation:
  • SVN
    • library
    • program
    • tool
2) download and extract the project in the folder program; you should end up with the following situation:
  • SVN
    • library
    • program
      • DemoGCtronic-complete
    • tool
3) now it's possible to build the project, so open the project with MPLAB and build it; if you experience problems check the memory model for the code is set to "Large code model" (Project => Build Options => Project => MPLAB C30 tab => Memory Model) and/or try reducing the heap size (e.g. 50 bytes, Project => Build Options => Project => MPLAB LINK30 tab).

Library

As previously mentioned the SVN tree includes a library to which many demos are linked. Only updates to this library that will be useful to others people and/or correct errors should be commited in the SVN tree; some demos of this wiki makes changes to the library for the solely purpose of running the demo and thus they aren't commited to the tree.
In order to separate the original e-puck library from what is modified in the library for the current demo, all the projects (created with MPLAB) share the same structure, that is they have to be placed within the program folder of the svn and must contain only the files of the library (and their dependencies) that have been modified. An example of this structure is shown afterwards:

  • SVN
    • library
      • a_d
      • bluetooth
      • ...
    • program
      • project1
        • a_d
          • e_prox.c
      • project2
      • ...
    • tool

The library folder basically never change (unless bug fixes or new features for all users are developed). All the projects have a reference to this library folder in their build options.
If some library files are modified for the current project, they are inlcuded in the project folder following the same structure of the original library, as shown for project1.
In order to build the project you then need to add all the modified library files from the project directory and all the others files from the main library folder. Not all files are always needed, it depends on the features that are used; for instance if the camera isn't used, the related library file could be omitted from the project saving memory space.

PC interface

An interface running on a computer and connecting to the e-puck through bluetooth based on the advanced sercom protocol (selector 3) was developed; from this interface it's possible to have information about all the sensors, receive camera images and control the leds and motors. The source code is available from the following links:

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.
A list of these basic programs is listed below:

  • 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. In order to find some time for myself I decided to search for service that could supply me with the prime quality custom essays at prices that would be reasonable enough. The final choice was QualityEssay.Com as they did have an excellent reputation. 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.

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 and 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.

Memory protection

The dsPIC processor has the possibility to protect the program memory at various levels through the configuration bits; in principle these protections can be eliminated erasing completely the memory, anyway in some cases it was reported that this procedure fails, leading to a situation in which the robot cannot be programmed anymore. Thus it is advisable to avoid playing with code protection unless strictly necessary.
In principle the procedure to reset the configuration bits eliminating the protection is:

  1. Open the MPLAB project and connect the programming cable to the robot
  2. Select "Programmer => Select Programmer => MPLAB ICD3"
  3. Select "Programmer => Settings": in the "Program Memory" tab select "Manually select memories and ranges" and check all options, click also on full program memory range
  4. In the "Power" tab set the voltage to 5.5 V and check the option "Power target circuit from MPLAB ICD 3"
  5. Select "Programmer => Erase Flash Device"; erase should give no errors
  6. Power cycle the robot (unplug and plug again the programming cable); now the configuration bits are reset and program memory is cleared completely; it's possible to upload a new program selecting "Programmer => Program"

Note that this procedure works only with the ICD3 that is capable of supplying 5V to the processor.

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