epuck obstacle avoidance

this month I need to complete the LED and Battery testing…Here goes the video:

 

Advertisements

Getting to grips with Eclipse: cross compiling

Yesterday, when I discussed with my office mate on the issues of compiling the epuck using the linux laptop…he mentioned something brilliant i guess. Previously, I just compiled my code using the linuxboard in epuck. Jenny inform me that she never tested it in compiling the codes using laptop, but she only tested using Hello World program. I have tested with a simple hello world program and its work.But when i tested with the epuck codes it does not work as few library configuration is needed.

Googling and try to find an example that using eclipse to cross-compile and it works…

Here it goes:

Setting the path for the toolchain

Usually you will have installed a cross-toolchain into /usr/local, /opt or your home directory. In my case I have an Ångström armv5te eabi toolchain (created using “bitbake meta-toolchain” if you are curious – full details outside the scope of this tutorial) which is installed into /usr/local/angstrom/arm and the tools have the prefix arm-angstrom-linux-gnueabi-. Whether you are compiling from the command line or Eclipse, you will need to include the path to the toolchain binaries. I generally write a script file that sets the path and then loads Eclipse like this:


#!/bin/sh
PATH=/usr/local/angstrom/arm/bin:$PATH
$HOME/eclipse/eclipse -vm $HOME/jre1.6.0_12/bin/java

Creating a project

Start Eclipse and select File->New->C Project or File->New->C++ Project. You will have a choice of four project types: Executable, Shared Library, Static Library and Makefile project. With the first three Eclipse will look after building the program using its own internally-generated makefile: this tutorial is about how to set up Eclipse to use a cross-compiler in these cases. With a Makefile project you will provide the Makefile yourself and so you select the compiler and build options outside the Eclipse environment.

For the proposes of this tutorial, create a “Hello World ANSI C Project”. You will find that Eclipse compiles it automatically to produce an executable for your PC – which is not what you want.

Setting the cross compiler

For all project types except Makefile project, you need to tell Eclipse to use the cross compiler rather than the native gcc.

  • Select the project in the Eclipse Project Explorer windows and then go to Project->Properties
  • Expand the section C/C++ Build and select Settings
  • If it is a C++ project, there will be four items in the Tool settings tab: GCC C++ Compiler, GCC C Compiler, GCC C++ Linker and GCC Assembler. If it is a C project, there will be three items: GCC C Compiler, GCC C Linker and GCC Assembler
  • In each case you need to add the toolchain prefix (arm-angstrom-linux-gnueabi-) to the the tool, for example gcc becomes arm-angstrom-linux-gnueabi-gcc as shown below:

If you are using multiple configurations, Debug and Release for example, you need to do this for each of them.

Now, click on Project->Clean to force Eclipse to rebuild and you should find an executable in the Binaries folder of the type of your toolchain, arm/le in my case.

Setting the include parser

This next bit is optional since it only affects the way Eclipse parses #include directives but not the way the program is compiled. Select Project->Properties. Under C/C++ General, select Paths and Symbols. On the Includes tab, select GNU C and add the path as shown in the screen shot below:

Now, if you right-click a header file (stdio.h for example) and select Open Declaration, it will display the header from the cross toolchain, rather than the native one. This may not matter much for headers from libc, which are pretty much the same for every one, but it does make a difference for headers from other libraries that may be totally different or not even installed on your development PC.

Unfortunately it is not possible to remove the paths to the native headers, but normally it won’t be a problem because the indexer will look in the cross toolchain includes first.

the epuck work has started

How To Use the York EPucks

You will need:
* Epuck
* MicroSD card reader
* linux laptop or computer that you have root access to.
* USB to RS232 converter
* serial to robot cable described in http://lpuck.sourceforge.net/files/instruction_JC.pdf

To connect:

  • in a terminal type “kermit -c”
  • turn on the robot. In your terminal you should see lots of startup text, much like you do when turning on a desktop computer
  • Log in to the robot (when it’s finished loading and gives you a login prompt).

login: root
password: robot

  • to turn off: shutdown now / turnoff

Running player on the robot

  • Navigate to /home/utils
  • type “player lpuck.cfg &” the ampersand is important because it means you can still use the command line whilst player runs in the background
  • Navigate in the terminal to wherever your compiled program is.
  • Run your program.
  • To stop your program at any time ctrl+c (you will need the cable to be connected)
  • Sometimes the robot doesn’t stop nicely and the wheels keep running even though your code is stopped. In /home/utils there is a program called kill which you can run and it will (hopefully) stop the robot.

Compiling code for the robot

  • compile using the robot

cross compiler to compile your code on the computer and then copy the binary across onto the microSD card.

We tested the compiling on robots

some code snippet

> There is an interrupt (_LVDInterrupt) for low voltage detection on the dspic, 
> see datasheet "Section 9. Low Voltage Detect (LVD)". Below there is my code 
> segment where I implement the event "on_low_battery", which is fired by this 
> interrupt.
> 
> 
> static void init_lvd(){
>       on_low_battery=add_event();
>       on_low_battery->check_function=always_true;
>       set_action(on_low_battery,lowBattery);
> 
>       //set interrupt prority  ->  1
> 
>       IPC10=(IPC10 & 0xFF1F) + 0x0020;        
>       _LVDIE=0;
>       _LVDEN=1;
> 
>       //set voltage threshold  -> 7 (<3.1 V, see datasheet p. 184)
> 
>       RCON=(RCON & 0xF0FF) +0x0700;
>       while(!_BGST);
>       _LVDIF=0;
>       _LVDIE=1;
> }
> 
> void __attribute__((interrupt, auto_psv)) _LVDInterrupt(void)
> {
>       _LVDIF=0;
>       _LVDEN=0;
>       _LVDIE=0;
>       check(on_low_battery);
> }
> 
> //An example action
> 
> void lowBattery(Event *e,void *arg){
>       e_set_led(9,1);
> }
> 

Programming Epuck – Part 2

HAVE TO DO THE FOLLOWING:

  • ALGORITHM with ENERGY and DATA ( tested on real epuck ) – END OCTOBER
  • DYNAMIC ALGORITHM – END NOVEMBER

    • TESTED on REAL EPUCK: END DECEMBER


Part 2:

  • continue the unresolved issues in part 1
  • install ePic2 : ePic2 is a complete framework to command the e-puck within Matlab ( was suggestet not to use this as we can send the data using UART: need to study this)
  • UPDATE ALGORITHM (DEADLINE : END OCTOBER)

    • ENERGY and DATA
    • since our robots have moved to the new lab, we can’t really test it now rather have to wait until mid october once we have moved to the new building.

Part 1:

  • tutorial 1 & 2 : linking and compiling ( generating .hex to be transfered to e-puck robots)
  • tutorial 1 & 2: transfer to e-puck ( yet to be tested upon jon’s approval)
  • swarm beacon : linking and compiling
    • update sound.c
    • question on centroid ( answered)
    • other related issues from the code: epuckcentroid.mcp, .mcs, .mcw and the generated sound values files ( ??? ) – old and irrelevant files. just ignore or comment

Since we cannot really tested with real e-puck yet, listed are the tutorials that need to be completed by next week before updating the algorithm.

  • Tutorial 1: very simple LEDs blinking – compiled
  • Tutorial 2: LEDs blinking (pause with timer)- compiled
  • Tutorial 3: selector reading + LEDs – compiled
  • Tutorial 4: send selector position via Bluetooth (simplified method) – compiled – IMPORTANT :
    • issue: pic30-gcc does not recognize standard C keywords (void, return..etc)…..WHY? – solved
  • Tutorial 5: proximity reading with interrupts + LEDs – compiled
  • Tutorial 6: motor speed controlled depending on front proximity sensor values

Programming Epuck – Part 1 – Solved

Previous issues: the *.o files cannot be read, resulting the following errors:

avoid.o(.text+0×0): In function `_readProximitySensors’:
: multiple definition of `_readProximitySensors’
avoid.o(.text+0×0): first defined here
beacon.o(.text+0×0): In function `_detectBeacon’:

it is basically the linker issues, -pic30 cannot really link with the generated *.o files.

Do refer to tutorial 1 & Swarm taxis files for more.

( The .hex file is generated but I changed the sound.c files…need to check back the changes )

Programming Epuck – Part 1

As mentioned in the previous entry, I was pretty much occupied on learning to program the e-puck. The IDE was successfully installed in my Ubuntu and, am ready to test the first tutorial downloaded from the e-puck website.

After few attempts, it is finally compiled and .hex file is generated. Next week task is to install the program both in Windows and Linux and try to send the .hex file to the e-puck that we have in the lab….isn’t is fun to see the robots moving?

I am now preparing the swarm beacon taxis code for the e-puck. the linking looks fine but, in generating the hex file, it gives the following error:

avoid.o(.text+0x0): In function `_readProximitySensors’:
: multiple definition of `_readProximitySensors’
avoid.o(.text+0x0): first defined here
beacon.o(.text+0x0): In function `_detectBeacon’:

there must be something wrong I guess…hmmmm

Not really sure on what is the issues, all the *.s files have been generated, but the errors are unresolved …need to try again….later

(/usr/share/pic30-support/inc/)

This week task:

  • -packing — moving office and house this month
  • second iteration of conference paper ( should send the first draft to jon)
  • meet jon before he goes to Malaysia for few weeks
  • run more experiments in the lab for robustness analysis
  • continue compiling the swarm beacon taxis