Adventures in Robotics

Installing Player/Stage in Ubuntu 11.10 (Oneiric Ocelot)

2011-12-13T09:54:00.002Z

This entry is my guide to installing Player/Stage on Ubuntu 11.04 updated for the next version of Ubuntu following what I learnt here.

If you have any problems or questions that aren't addressed here then I recommend you email the playerstage users mailing list.

These instructions are for Player 3.0.2 and Stage 4.0.0 which are the most recent stable versions at the time of writing this guide.
It helps to have a computer which you have sudo rights to. If the computer is networked and you can't install stuff on it then ask the network administrator to install playerstage for you, alternatively you can install Player/Stage into your home director, this is also described below.

Setup

First download Player and Stage.
- Player
- Stage
extract the tar.gz files. Right click on the icon of the thing you just downloaded and select "extract here".

Installing Dependencies

Player/Stage has a lot of dependencies, but they can be installed with Ubuntu software centre reasonably easily.

To open Ubuntu software centre (if you don't know how) click the ubuntu logo in the very top left of the screen and start typing ubuntu. It should come up as one of the options.

The following dependencies need to be installed:
- pkg-config
- cmake
- FLTK 1.1.x
- OpenGL
- libpng
- ltdl (Libtool)
- boost threads
- boost signals
- STL Runtime libraries
In the top right of the ubuntu software centre there's a search bar. Start typing pkg-config in, that should give you the pkg-config installer. If it's not already installed, then click install.

Now type cmake and install the cmake package.
To install FLTK type libfltk into the search bar.

Click on and install from the list of options:
- Fast Light Toolkit - shared libraries, libfltk1.1
- Fast Light Toolkit - development files, libfltk1.1-dev
- IMPORTANT: there will be libfltk1.3-dev in the list of packages, but do not install it. Using the most recent library causes Stage 4.0.0 to give compile errors. See my previous ubuntu 11.10 entry for details.
Type freeglut into the search bar and install from the list:
- OpenGL Utility Toolkit - freeglut3
- OpenGL Utility Toolkit development files, freeglut3-dev
Type libpng into the search bar and install the following:
- PNG Library Runtime, libpng12-0 (or whatever is the latest version number)
- PNG Library Development, libpng12-dev
Type libtool into the search bar. What you need won't be shown, but if you click "show technical items" in the bottom left (see image) it will give you the options you need.
Install the following:
- Generic Library support script, libtool
- A system independent dlopen wrapper for GNU libtool, libltdl7
- A system independent dlopen wrapper for GNU libtool, libltdl-dev
Type boost thread into the search bar and install the following:
- Portable C++ multi-threading (default version), libboost-thread-dev
Type boost signals into the search bar and install the following:
- Managed signals and slots library for C++ (default version), libboost-signals-dev
Type libdb5 into the search bar and install the following:
- Berkeley v5.1 Database Libraries [stl runtime], libdb5.1-stl

Installing Player

This should work first time, even on a fresh install of Ubuntu.
Open a terminal and change directory (cd command) to the folder you extracted player into. This will probably be called something like "player-3.02" or whatever version you downloaded. Then enter the following commands:

mkdir build
cd build
cmake ..
sudo make install

But I don't have sudo!

Well then you'll have to install it into your home directory somewhere. This is a pretty similar process, you just have to change the install prefix.

mkdir build
cd build
ccmake ..

Note that's '''ccmake''' not cmake

in the terminal scroll menu thing that just opened scroll down to CMAKE_INSTALL_PREFIX. If nothing is listed press c, things should appear.

whilst it is selected press enter to edit the option and then change it to the folder you want player installed into.
press enter to confirm edit

press c to configure the settings
if the option appears, press g to generate the make files. If the option doesn't appear press c again until it does.
In the terminal now type make install

Installing Stage - Library Dependencies

First make sure that pkg-config can find player, otherwise there may be all sorts of troubles later when you try and use Stage. In a terminal type:

pkg-config --modversion playercore

If it gives you a version number it's properly installed. Otherwise, in your home folder make or edit the file called .bashrc, (it probably already exists). If you press ctrl+h while looking at the folder in nautilus it will show up if it's already there. At the end of this file write the following line IF YOU'RE USING A 64-BIT INSTALL:

export PKG_CONFIG_PATH+=/usr/local/lib64/pkgconfig

IF YOU'RE USING A 32-BIT INSTALL

export PKG_CONFIG_PATH+=/usr/local/lib/pkgconfig

Test this again in a new terminal with
- pkg-config --modversion playercore

Installing Stage - Updating a Compilation Script

Ubuntu 11.10 links differently to older versions of Ubuntu, and the Stage compilation code needs updating before it can be run.

In your install directory open libstage/CMakeLists.txt in your favourite text editor.
Completely delete the contents.
Go to http://pastebin.com/y2chM8fz and copy it into the CMakeLists.txt you have open.
Save the file.

Installing Stage

In a new terminal navigate to the stage folder you extracted earlier. this is probably called something like "Stage-4.0.0-src" or whatever Stage version you installed. In a terminal type the following commands:

mkdir build
cd build
cmake ..
sudo make install

But I don't have sudo!

The install is just the same as for Player if you need to install Stage in your home folder or somewhere.

Follow the steps above for updating the libraries and compilation script or this won't work.
Then in a terminal navigate to the Stage source code folder. this is probably called something like "Stage-4.0.0-src" or whatever Stage version you installed. In a terminal type the following commands:

mkdir build
cd build
ccmake ..

in the terminal menu thing that just opened scroll down to CMAKE_INSTALL_PREFIX. If nothing is listed press c, things should appear.
whilst it is selected press enter to edit the option and then change it to the folder you want player installed into.
press enter to confirm edit
press c to configure the settings
if the option appears, press g to generate the make files. If the option doesn't appear press c again until it does.
In the terminal now type:

make install

Testing it Works

The stage source code has some handy code that should work if you've got everything installed. To test your install in your terminal go to the /worlds directory in the Stage source code folder. Type player simple.cfg into the terminal. In the unlikely event that that works you've successfully installed Player/Stage!

I got the following error:

player: error while loading shared libraries: libplayerdrivers.so.3.0: cannot open shared object file: No such file or directory.

To fix this open up your .bashrc file and enter the following line IF YOU'RE USING A 64-BIT INSTALL:

export LD_LIBRARY_PATH+=/usr/local/lib64

Write the following line IF YOU'RE USING A 32-BIT INSTALL:

export LD_LIBRARY_PATH+=/usr/local/lib

If you changed CMAKE_INSTALL_PREFIX whilst installing player and or stage then do this:

export LD_LIBRARY_PATH+="whatever install prefix you made"

Now retest your install IN A NEW TERMINAL. I got the following error:
Registering driver Player v.3.0.2
* Part of the Player/Stage/Gazebo Project [http://playerstage.sourceforge.net].
* Copyright (C) 2000 - 2009 Brian Gerkey, Richard Vaughan, Andrew Howard,
* Nate Koenig, and contributors. Released under the GNU General Public License.
* Player comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it under certain conditions; see COPYING for details.

error : Failed to load plugin stageplugin.
error : libtool reports error: file not found
error : plugin search path: /home/robotlab/playerstage/Stage-4.0.0-src/worlds:.:/usr/local/lib64/
error : failed to load plugin: stageplugin error : failed to parse config file simple.cfg driver blocks

This is caused by the computer not being able to find Stage. Back to the .bashrc....

change export LD_LIBRARY_PATH+=/usr/local/lib64 to...
export LD_LIBRARY_PATH+=/usr/local/lib64:/usr/local/lib

HOWEVER. This is the error that Stage will give if you didn't set up the compilation script properly before installing. If you Googled your error and came to this page you'll need to completely uninstall and delete Stage and the stage source code. Re-download it and follow all the Stage installation instructions above.

Upgrading to Ubuntu 11.10 with player/stage

2011-12-02T16:14:00.002Z

Yesterday I thought it would be a good idea to upgrade my laptop to 64-bit Ubuntu 11.10 (Oneiric Ocelot), this turned out to be a TERRIBLE idea since I've now spent the last 7 hours trying to reinstall Player/Stage. JOY.

In this post I'll quickly go over what I did that was different to the install for Ubuntu 11.04 (a comparative breeze). A more user-friendly guide to installing Player/Stage can be found here.

Let's get to it!

This time round I installed Player version 3.0.2 and Stage version 4.0.0.

Dependencies

The list of dependencies is mostly the same. Download and install these (using ubuntu software centre or aptitude or whatever you like best):

pkg-config
cmake
Fast Light Toolkit - shared libraries, libfltk1.1
Fast Light Toolkit - development files, libfltk1.1-dev
OpenGL Utility Toolkit - freeglut3
OpenGL Utility Toolkit development files, freeglut3-dev
PNG Library Runtime, libpng12-0 (or whatever is the latest version number)
PNG Library Development, libpng12-dev
Generic Library support script, libtool
A system independent dlopen wrapper for GNU libtool, libltdl7
A system independent dlopen wrapper for GNU libtool, libltdl-dev
Generic Library support script, libtool

New dependencies for 11.10:

Portable C++ Multithreading (default version), libboost-thread-dev
Managed signals and slots library for C++ (default version), libboost-signals-dev
Berkeley v5.1 Database Libraries [stl runtime], libdb5.1-stl

Some dependency troubles

I found that if I installed the latest fltk development package (libfltk1.3-dev) it gave the following compile error in Stage:


[ 41%] Building CXX object libstage/CMakeFiles/stage.dir/region.o
/home/jenny/player/source/Stage-4.0.0-src/libstage/region.cc:10:1: error: reference to ‘Region’ is ambiguous
/usr/include/X11/Xutil.h:265:26: error: candidates are: typedef struct _XRegion* Region
/home/jenny/player/source/Stage-4.0.0-src/libstage/region.hh:54:9: error:                 class Stg::Region
/home/jenny/player/source/Stage-4.0.0-src/libstage/region.cc:10:1: error: ‘Region’ does not name a type
/home/jenny/player/source/Stage-4.0.0-src/libstage/region.cc:17:1: error: reference to ‘Region’ is ambiguous
/usr/include/X11/Xutil.h:265:26: error: candidates are: typedef struct _XRegion* Region
/home/jenny/player/source/Stage-4.0.0-src/libstage/region.hh:54:9: error: class Stg::Region
/home/jenny/player/source/Stage-4.0.0-src/libstage/region.cc:17:1: error: ‘Region’ does not name a type
make[2]: *** [libstage/CMakeFiles/stage.dir/region.o] Error 1
make[1]: *** [libstage/CMakeFiles/stage.dir/all] Error 2
make: *** [all] Error 2

If I used libfltk1.1-dev instead this problem doesn't happen.

Installation

Installing Player was the same as for Ubuntu 11.04. See: http://yorkroboticist.blogspot.com/2011/10/installing-playerstage-in-ubuntu-natty.html
Also, set up pkg-config as described in steps 1 to 3 of the 11.04 instructions.

Installing Stage 4.0.0 was DIFFICULT. The linking stage of C compiling seems to be done slightly differently in this version of Ubuntu, which meant that Stage's compile scripts don't fully work. So what you need to do is unpack the Stage download, then in a text editor open the libstage/CMakeLists.txt file. Completely replace the contents of the file with this:
new CMakeLists.txt
Now that's done you can configure and install Stage as described in point 4 of the natty instructions onwards.

Installing Player/Stage in Ubuntu (Natty Narwhal)

2011-10-03T10:14:00.005+01:00

A few months ago I wrote a guide to installing Player/Stage on a clean Natty Narwhal Ubuntu install for the robot lab I work at. This was on a protected wiki, but I think maybe it'd also be beneficial to the world in general, so I'll guide you through the installation process (with pictures!) in this blog entry.

I'm pretty sure this guide will work for any version of Ubuntu that has Ubuntu Software Centre on it, but I've only tested these instructions for Natty. If you followed these instructions to install Player/Stage on a non-Natty version of Ubuntu do leave a comment so that others can know whether it works.

A newer version of these instructions for Ubuntu 11.10 can be found here.

If you have any problems or questions that aren't addressed here then I recommend you email the playerstage users mailing list.

These instructions are for Player 3.0.2 and Stage 4.0.1 which are the most recent versions at the time of writing this guide.
It helps to have a computer which you have sudo rights to. If the computer is networked and you can't install stuff on it then ask the network administrator to install playerstage for you, alternatively you can install Player/Stage into your home director, this is also described below.

Setup

First download Player and Stage.
- Player
- Stage
extract the tar.gz files. Right click on the icon of the thing you just downloaded and select "extract here".

Install cmake. Open a terminal and type:
- sudo apt-get install cmake
- follow instructions on screen

Installing Dependencies

Player/Stage has a lot of dependencies, but they can be installed with Ubuntu software centre reasonably easily.

To open Ubuntu software centre (if you don't know how) click the ubuntu logo in the very top left of the screen and start typing ubuntu. It should come up as one of the options.

The following dependencies need to be installed:
- pkg-config
- FLTK 1.1.x
- OpenGL
- libpng
- ltdl (Libtool)
In the top right of the ubuntu software centre there's a search bar. Start typing pkg-config in, that should give you the pkg-config installer. If it's not already installed, then click install.

To install FLTK type FLTK into the search bar. This time the thing you want probably won't be an option. Click on "show technical items" (see picture)

Click on and install from the list of options:
- Fast Light Toolkit - shared libraries, libfltk1.1
- Fast Light Toolkit - development files, libfltk1.1-dev
Type opengl into the search bar and install from the list:
- OpenGL Utility Toolkit - freeglut3
- the OpenGL Utility Toolkit - libglut3
- OpenGL Utility Toolkit development files, freeglut3-dev
Type libpng into the search bar and install the following:
- PNG Library Runtime, libpng12-0 (or whatever is the latest version number)
- PNG Library Development, libpng12-dev
Type libtool into the search bar and install the following:
- Generic Library support script, libtool
- A system independent dlopen wrapper for GNU libtool, libltdl7
- A system independent dlopen wrapper for GNU libtool, libltdl-dev

Installing Player

mkdir build
cd build
cmake ..
sudo make install

But I don't have sudo!

Well then you'll have to install it into your home directory somewhere. This is a pretty similar process, you just have to change the install prefix.

mkdir build
cd build
ccmake ..

Note that's '''ccmake''' not cmake

in the terminal scroll menu thing that just opened scroll down to CMAKE_INSTALL_PREFIX. If nothing is listed press c, things should appear.

whilst it is selected press enter to edit the option and then change it to the folder you want player installed into.
press enter to confirm edit

press c to configure the settings
if the option appears, press g to generate the make files. If the option doesn't appear press c again until it does.
In the terminal now type make install

Installing Stage

Make sure that pkg-config can find player, otherwise there may be all sorts of troubles later when you try and use Stage. In a terminal type:

pkg-config --modversion playercore

If it gives you a version number it's properly installed. Otherwise, in your home folder make or edit the file called .bashrc, (it probably already exists). If you press ctrl+h while looking at the folder in nautilus it will show up if it's already there. At the end of this file write the following line IF YOU'RE USING A 64-BIT INSTALL:

export PKG_CONFIG_PATH+=/usr/local/lib64/pkgconfig

IF YOU'RE USING A 32-BIT INSTALL

export PKG_CONFIG_PATH+=/usr/local/lib/pkgconfig

Test this again in a new terminal with
- pkg-config --modversion playercore
In a new terminal navigate to the stage folder you extracted earlier. this is probably called something like "Stage-4.0.1-Source" or whatever Stage version you installed. In a terminal type the following commands:
- mkdir build
- cd build
- cmake ..
- sudo make install

But I don't have sudo!

The install is just the same as for Player if you need to install Stage in your home folder or somewhere.

Follow steps 1,2 and 3 above for configuring pkg-config (otherwise this will not work).
Then in a terminal navigate to the stage folder you extracted earlier. this is probably called something like "Stage-4.0.1-Source" or whatever Stage version you installed. In a terminal type the following commands:

mkdir build
cd build
ccmake ..

in the terminal menu thing that just opened scroll down to CMAKE_INSTALL_PREFIX. If nothing is listed press c, things should appear.
whilst it is selected press enter to edit the option and then change it to the folder you want player installed into.
press enter to confirm edit
press c to configure the settings
if the option appears, press g to generate the make files. If the option doesn't appear press c again until it does.
In the terminal now type:

make install

Testing it works

The stage source code has some handy code that should work if you've got everything installed. To test your install in your terminal go to the /worlds directory in the source code folder. Type player simple.cfg into the terminal. In the unlikely event that that works you've successfully installed Player/Stage!

I got the following error:

player: error while loading shared libraries: libplayerdrivers.so.3.0: cannot open shared object file: No such file or directory.

To fix this open up your .bashrc file and enter the following line IF YOU'RE USING A 64-BIT INSTALL:

export LD_LIBRARY_PATH+=/usr/local/lib64

Write the following line IF YOU'RE USING A 32-BIT INSTALL:

export LD_LIBRARY_PATH+=/usr/local/lib

If you changed CMAKE_INSTALL_PREFIX whilst installing player and or stage then do this:

export LD_LIBRARY_PATH+="whatever install prefix you made"

Now retest your install IN A NEW TERMINAL. I got the following error:
Registering driver Player v.3.0.2
* Part of the Player/Stage/Gazebo Project [http://playerstage.sourceforge.net].
* Copyright (C) 2000 - 2009 Brian Gerkey, Richard Vaughan, Andrew Howard,
* Nate Koenig, and contributors. Released under the GNU General Public License.
* Player comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it under certain conditions; see COPYING for details.

error : Failed to load plugin stageplugin.
error : libtool reports error: file not found
error : plugin search path: /home/robotlab/playerstage/Stage-3.2.2-Source/worlds:.:/usr/local/lib/
error : failed to load plugin: stageplugin error : failed to parse config file simple.cfg driver blocks

This is most likely caused by the computer not being able to find Stage. Back to the .bashrc....

change export LD_LIBRARY_PATH+=/usr/local/lib64 to...
export LD_LIBRARY_PATH+=/usr/local/lib64:/usr/local/lib

Microphone work: Finding out your sample rate.

2011-09-26T14:59:00.001+01:00

Goodness it's been a while since I updated my blog! This is mostly because I've spent the past year or so designing and building a new extension for the epuck robots. Details about that I'll leave for another time, although this blog entry is somewhat related.

I have a circuit which takes a signal from a microphone and feeds it into a PIC microcontroller. This PIC then performs Analogue-to-Digital conversion and stores the data in memory for me to mess with later.
The process of reading in the signal and storing it in memory is known as "sampling". A single piece of recorded data is called a "sample", the rate at which you record the information is called the "sample rate".

Are you following me so far?

The sample rate is super useful to know if you plan on doing anything clever with your data. For my work I need the sample rate to be as fast as possible so I have my PIC recording samples in a loop until its memory gets full. This means I don't actually know how fast this is happening, so I need to measure it.

Read on to find out how I did this, and for some handy MATLAB code!

The first thing I did was to sample something. My microphone/PIC system has a memory of 128 bytes and each sample uses 1 byte of memory. I played a 1kHz tone at it and sent the recorded data along a serial cable to my computer where I logged the results into a text file. When that'd finished I loaded it all into MATLAB so that I could visualise it properly.

Here's a graph of what was recorded:

I'll call the sample rate fs. The sample rate is measured in Hertz (Hz), which is the number of samples recorded per second. I'll call the frequency of the signal I played at the microphones fk, but it was actually 1000Hz in this example. Below is a really rubbish drawing of how these two values relate to the signal I recorded:

The x axis in the diagram is time and the graph shows a signal as it is sampled. Each sample lasts 1/fs seconds before the next sample is recorded. Over the course of one wavelength of our input signal -which lasts 1/fk seconds- there are n samples. SO...

n * 1/fs = 1/fk
or...
fs = n*fk

Now we just have the problem of finding what n is. There are several ways of doing this.
The first, and easiest, one is visual estimation. If we go back to the first picture there are just under 2 and a half wavelengths in our memory buffer, let's say 2.4 wavelengths. We also know there are 128 samples in the diagram so.. 128/2.4 will give us an estimation of n: 53.333. Multiplying that by fk gives us an estimated sample rate of 53,333Hz.

Alternatively we could use MATLAB's "data cursor" button, which becomes available when you plot data.

Use the data cursor to select the beginning of a waveform, note down the x coordinate, then select the end of a waveform and do the same. The difference will be the number of samples per waveform.

So here x = 10.

And here x = 69. So n = 69-10 = 59. It's worth doing this a few times to get an average value for n. If n=59 then our sample rate is n*fk = 59*1000 = 59,000Hz.

I thought this seemed rather large, so I wrote a MATLAB GUI which shows you the data you might expect if you sampled a signal fk at sample rate fs. In the GUI, fk and fs can be varied so have a play! There are 2 parts, the gui data and the gui code which need to be saved in the same folder before MATLAB can open them.

When I put in my values for the sample rate and the known frequency input it looks more or less like my original data, a good sign! The GUI can also be used to demonstrate a phenomenon called aliasing, which happens when the input frequency gets close to and above fs/2. Basically, because we're taking samples instead of recording the actual sound then signals start to resemble each other even though they're not the same. This wikipedia image of aliasing illustrates why this happens.

New Edition of the Manual Released!

2010-04-21T10:04:00.001+01:00

I'm pleased to announce that the latest version of the Player/Stage tutorial has been released on my website here:
player/stage manual
Hopefully it'll also be appearing on the official Player/Stage website soon.

After far too long I've updated the old manual to include stuff in the errata and I've also cleared up a few problems. Specifically, it has been pointed out that the manual code was crap and didn't actually work properly. Also the old manual was too ambiguous about movable objects.

Enjoy!

Cross Compilers for the lpuck

2010-04-14T08:50:00.010+01:00

Firstly, I should apologise for this blog post because it's not about the usual PlayerStage stuff. It's instead about how I made a cross compiler for a specific bit of hardware that we have in the York robot swarm and at BRL. It's not really useful for anyone but me...

Useless background information

In both these places we use epucks to do our research, however the processing power of the epuck is limited. To fix this Wenguo Liu at BRL designed an extension that runs linux (emDebian), which can be attached to the robots so that they can do all their processing onboard (so they can run Player!). The result is called an L-Puck.

Back to the point...

Anyway, these linux boards run emDebian on the AT91SAM9260 processor which is an ARM architecture. To compile stuff locally on the robots takes FOREVER, and some of our Player code is pretty big. Anyway, I've been trying to make a cross-compiler which can compile the player code on the computer so that we just have to copy over a binary. Much faster!

My Learnings About Cross Compilers

The stuff you use to turn code into an executable binary is called a toolchain. For linux systems this isn't just gcc but g++, ar, as, strip, ranlib and a whole bunch of other things too, all of which are important even if you don't think you use them.

Crosstools is a very useful tool for building cross-compiler toolchains, but it's not updated very often and I had to revert to an old version of gcc to get it to work. Not to mention numerous other troubles like stack overflows and stuff that running it caused. I did get it to build a generic ARM compiler, but it didn't work for me.

TomTom (the satnav company) provide a very useful pre-built version of the arm-linux- toolchain here, but that also didn't work for me.

This is the most important thing: if your processor is running some kind of embedded linux, stuff compiled for your processor to run just won't work. Your binary is going to be run by your OS not by the chip

Scratchbox and Qemu are useless because there's absolutely no information (that I could find anyway) about how to actually use them once they're installed.

The embedded debian project is very well documented and good!

How I actually built the cross compiler

After realising that compiling stuff for the ARM processor wasn't going to get me anywhere I looked at how to compile stuff for emDebian, and there's loads of information about making emdebian cross compilers for ARM chips. RESULT!
In a nutshell, I followed the instructions here: http://wiki.debian.org/EmdebianToolchain and it worked. Where they say $ARCH I used "armel". Doing $ apt-cross -a armel -u didn't update anything for me, and I skipped the $ apt-cross -a armel -i $LIBRARY step because I don't have any libraries that I want to install. Doing this will install the arm-linux-gnueabi toolchain, so to cross compile you use arm-linux-gnueabi-gcc instead of gcc. It should have installed the binaries (or symlinks to binaries) in the /usr/bin folder so you don't need to specify any kind of path.

I tested the arm-linux-gnueabi toolchain with a simple helloworld program, cross compiled it, copied it onto the robot and it worked!

Player/Stage on Eclipse

2010-03-10T12:19:00.011Z

Today I've found myself trying to set up Eclipse as my IDE for Player/Stage after moving some files and somehow deleting all the settings. I'm using an Eclipse specifically for C/C++ development, which you can get here: http://www.eclipse.org/downloads/

This is how I set it up for Player/Stage:

Open up Eclipse and select Project (from the top menubar) then Properties. Select the C/C++ Build >> settings from the left sidebar. Tool Settings should be the default tab that is open.
You should now have a window that looks like this (click to enbiggen):

Under the GCC C++ Compiler select the Miscellaneous tab and paste into the "other flags" box:
`pkg-config --cflags playerc++`

Similarly, under the GCC C Compiler select the Miscellaneous tab and paste into the "other flags" box:
`pkg-config --cflags playerc`

To set up the linker (which is what connects the object files together into a working binary which can then be executed) select the Miscellaneous tab under the GCC C++ Linker and into the Linker flags box paste:
`pkg-config --libs playerc++`

If you want to develop in C rather than C++ then paste `pkg-config --libs playerc` into the box instead.

It will probably work now if you have the PATH set on your computer properly. It didn't work for me so I told Eclipse where to look for all the Player libraries. Under the GCC C++ Compiler select the directories tab and paste the location of the folder containing the player headers. On my computer this was /usr/local/include/player-3.0/libplayerc++ it will probably be different on different computers. Do the same for the directories tab in the GCC C Compiler section.

Congratulations. You can now start working on some Player/Stage code in Eclipse! If you need to test your code it is still necessary to start a Stage simulation by opening a terminal and running $ player yourcfg.cfg. Then when you hit run in eclipse it'll compile and then start running your code on that simulation.

Player/Stage API

2010-03-09T13:57:00.004Z

Now I've finally found time to work on Player/Stage full time I've begun to make a handy API for the E-Puck robots we have here in York. The first part of this has been building a Stage model of the E-Puck and then writing an API to interact with all the device proxies.

The end goal is to have an API which can be used to communicate with simulated robots, but will also work with a real robot. The Player/Stage website is very insistent that this is possible!
Source code

The API can interact with a robot that has position2D, sonar and blobfinder devices. Those are all that are supported so far, I plan on adding some more soon. For example, I want to be able to simulate a swarm of robots that communicate with sound and wifi, so I need to somehow get the AudioProxy and WifiProxy working on Stage.
In the API code, EPuck.cc you can see how I'm made my code interact with the proxies and wrapped them in my own function names which are more suited to my needs. One thing I did was make a method called setDifferentialMotors(left, right) which takes speeds for the left and right wheels and converts them to values that can be understood by Player. The maths behind this I've discussed previously.

One major thing I've done to make the blob data more useful is to create a Blob class which contains all the data that the player_blobfinder_blob_t structure does, but instead of using uint32_t data types I mainly use int. This made it easier to work with the information but also meant that if I want to interact with blob data I don't need to include the playerc++ header.

What's in the file?

The source code file: epuckAPI.tar contains the Stage world which I made to test the API, as well as a model of an epuck and the cfg to run the simulation. The API is in EPuck.h and EPuck.cc, these contain source code that is helpful in learning how to use Player proxies. Finally there is some test code TestEpuck.cc which uses the API to command the robots and read some data.

Anyway to use the API you just #include EPuck.h at the top of your code and compile EPuck.cc along with all your other code to get a final program that (if all goes well) you can run.

York Doctoral Symposium

2010-02-25T15:09:00.007Z

It has been a while since my last blog update. Mostly this is because I've been preparing a paper for the ANTS 2010 conference.
What I want to mention in this blog entry is the symposium I'm helping to run!

It's a conference that's run annually by my department which is organised by the PhD students. The idea is to give us youths and young researchers an idea about what it's like to actually run a conference and review papers and select them to create a program. There's also the organisation of logistical stuff like location, food advertisment which is the side I'm more involved with.

The organisation process has only been going on since February but I've learnt a lot about interacting with people and just plain getting stuff done. Right now I'm having to NETWORK and find people in industry who are able to sponsor the event. If I can get that done well then the conference could be completely free for everybody. I have ideas anyway.

I encourage any PhD students reading this to submit their work to the conference anyway. Last year there were only 10 submissions and 8 presentation slots, I'm hoping this year we can do a bit better. I have plans for getting some really tasty prizes for papers, so it's worth submitting some work, preliminary results totally count as valid research (so long as the science is sound of course)!

SUBMIT.

Differential drive to forward/turnrate conversion

2009-12-16T13:06:00.012Z

When controlling a differential drive robot like the epuck, I like to be able to control the speeds of the left and right wheel with my code. This allows you to easily program simple things like Braitenberg vehicles because you can directly interact with the wheel speeds.

HOWEVER. With Player/Stage if you're using a differential drive robot you can only interact with the motors using the robot's forward speed (metres/sec) and its turning rate (radians/sec). In order for your left and right wheel speed controller to properly interact with Player/Stage you need to convert between the two. This involves some pretty horrible maths and kinematics type stuff. For the lazy, here is the conversion between differential wheel speeds in metres/sec into forward speed and turn rates for Player/Stage. Instead of left and right speeds though we use inner and outer wheel speeds because the wheel on the inside must be slower than the outer one because it travels less far and this affects the maths.

newspeed = Inner_wheel_speed
newturnrate = (Outer_wheel_speed - Inner_wheel_speed)/distance_between_wheels
All measures are given in metres/sec.

Explanation

In the Player example "laserobstacleavoid.cc" they use the following code to convert from differential wheel speeds to forward speed / turn rate:

newspeed = (r+l)/1e3;
newturnrate = dtor(r-l);

Where does 1e3 come from? Where do these formulas come from?

Since I'm no mathematician, so I used Google and came across this forum thread which discusses how to turn forward speeds and turn rates into left and right wheel speeds. This is the reverse of what we want to do here. I won't copy and paste the entire post here but these are the relevant formulae:

inner wheel speed (radians/second) = forward speed (metres/sec) / wheel radius (metres)
outer wheel speed (radians/second) = ( forward speed (metres/sec) + turn rate (radians/sec) * wheel separation )/wheel radius (metres)

The inner wheel is the one on the inside of the turn, and the outer wheel is the one on the outside. I want to provide wheel speeds in metres per second and convert these into a forward speed in metres/sec and a turn speed in radians/sec.
We'll shorted some of these terms to make the formulae sane. Ir is the inner wheel speed in radians/second, Im is the inner wheel speed in metres/second. Similarly Or and Om are the outer wheel speeds in radians and metres respectively. Newspeed will be the foward speed that we want to give Player, and newturnrate is the turning rate to give Player.

Let's start by looking at the inner wheel speed. The formula from the website says:
Ir = newspeed/wheel_radius
so...
newspeed = Ir*wheel_radius [1]

Let's convert Ir to Im:
We have the wheel speed Im in m/s as our fuction input, we should find out how many turns of the wheel we need to make in order to cover that distance. The circumference of the wheel is 2pi*wheel_radius so that it how far each wheel turn takes us. To find how many wheel turns are required per second we do:
number of wheel turns per sec = Im/2pi*wheel_radius
A whole wheel revolution is 2pi radians so we multiply our number of wheel revolutions by 2pi to get the number of radians/second we need to turn.
Ir = (2pi*Im)/(2pi*wheel_radius)
Ir = Im/wheel_radius [2]
substitute [2] into [1]:
newspeed = (Im*wheel_radius)/(wheel_radius)
newspeed = Im

That's easy enough to code! Now for the outer wheel. From the website:
Or = ( newspeed + newturnrate * wheel_separation )/wheel_radius
Now we convert Or to Om in the same way we did for the inner wheel in [2]
Or = Om/wheel_radius
so...
Om/wheel_radius = ( newspeed + newturnrate * wheel_separation )/wheel_radius
wheel radius cancels out on both sides:
Om = newspeed + (newturnrate * wheel_separation)
rearranging...
newturnrate = (Om - newspeed)/wheel_separation
newturnrate = (Om - Im)/wheel_separation

Finally we have a conversion! We can get the wheel separation by measuring the robot, Im and Om are our inputs.
Here's what you've all been waiting for, it's my code for converting wheel speeds to player commands:

/**
converts differential drive wheel speeds into a forward speed and turn rate that Player understands.
@param left speed of left wheel in metres/second
@param right speed of right wheel in metres/second
*/
setMotors(double left, double right)
{
/* conversion of differential drive values to 
forward and turn speeds from 
http://www.physicsforums.com/showthread.php?t=263149 */


/* wheel separation of an epuck. 
* Replace with correct value
* for your robot */
const double separation = 52*0.001; //52 mm
double newspeed, newturnrate;


//which is the outer wheel and which is the inner?
if(left > right) //if left is outer wheel
{
//newspeed is inner wheel speed
newspeed = right;
//newturnrate = (outer(m) - newspeed)/separation
newturnrate = (left - newspeed)/separation;
}
else if(right > left) //right is outer wheel
{
//newspeed is inner wheel speed
newspeed = left;
//newturnrate = (outer(m) - newspeed)/separation
newturnrate = (right - newspeed)/separation;
}
else
{
newspeed = left; //could also be right
newturnrate = 0;
}


p2dProxy.SetSpeed(newspeed, newturnrate);
}

Update of the Manual code from Stage 2.1.1 to 3.2.2

2009-11-30T12:31:00.007Z

The Stage models from my manual were written using Stage 2.1.1, since then Stage has been updated a few times and there have been significant changes to the way that models are created.

Here I'll go through the code that was developed in the manual and I'll make the changes necessary for running the world using the Stage 3.2.X.

The .cfg File

This is the old configuration file I won't bother reprinting the entire thing here.

This file begins with the following code to make Player use Stage instead of trying to connect to real robot devices:

driver
(
name "stage"
plugin "libstageplugin"

provides ["simulation:0"]

# load the named file into the simulator
worldfile "robots_and_junk.world"
)

The only thing that needs changing here is the line plugin "libstageplugin" to plugin "stageplugin". That is, delete the "lib" from the front.
If you don't do this Player will tell you that it can't find the stage library and nothing will happen.

The .world File

This is the old .world file.

This is the old bigbob.inc file.

If you try running Player with the revised .cfg file you'll probably encounter the following message:

err: Loading size. Need a vector of length 3: found 2.

In the latest version of Stage they upgraded the syntax that describes shapes and things to support 3D models. This included changing the size parameter, so size [x y] doesn't work any more, and the command is now size [x y z] values are still measured in metres. The error it gave means that it is looking for a height, which has not been declared.

In my file I make the world height and map height to be 3 (so changed size [15 15] to size [15 15 3]) which is a somewhat arbitary choice for a height. I also added a height to the orange and carton models in the .world file. The height also needs to be specified in the bigbob.inc file, although for some reason I'd already given that a height of 1 metre, the laser models also needs to be modified because that uses the size parameter too, the ranger model uses ssize which does not need to be 3 dimensional.

Once these corrections have been made, Player gives the following error:

err: Loading pose. Need a vector of length 4: found 3.

The move from 2D models to 3D models means that when you declare the model's pose you also need to tell Stage what height the robot is at.
The pose [x y yaw] parameter has been changed to pose [x y z yaw], so a value for z needs to be added. For non-flying robots (like the bigbob example) this will be 0.

In the .world file I set the z pose of all objects in the world to be 0.
In bigbob.inc the laser's pose needed to be set as it uses the pose parameter, again the ranger model doesn't need altering because it uses spose instead of pose.
Also, the origin parameter in the bigbob position model needs changing, for some reason this will cause the above "pose" error, even though it's the origin parameter. I don't know why.
Anyway, I changed origin [0.125 0 0] to origin [0.125 0 0 0] and that stopped the pose error.

Next Player gave me these errors:

err: Model type ptz not found in model typetable

err: Unknown model type ptz in world file.

Evidently the ptz model has been removed completely from Stage. This requires a complete rewrite of the blobfinder code, to update it to use the later syntax. Basically this means getting rid of the ptz stuff and renaming channels to colors. This is the old blobfinder code:

# bigbob's blobfinder
define bigbobs_eyes ptz
(
blobfinder
(
# number of colours to look for
channels_count 2

# which colours to look for
channels ["orange" "DarkBlue"]

# camera parameters
image [160 120]  #resolution
range_max 5.00
ptz [0 0 60]
)
)

Which is replaced with the following code:

# bigbob's blobfinder
define bigbobs_eyes blobfinder
(
# number of colours to look for
colors_count 2

# which colours to look for
colors ["orange" "DarkBlue"]

# camera parameters
image [160 120]  #resolution
)

Running Player on the world now will actually produce a simulation, although it's a bit useless:

To fix this the old map.inc is first replaced by the newest map.inc.
The map model has been renamed to floorplan in this newest map.inc so the .world file is changed accordingly. The resulting world still looks like the above picture though.
This is due to changes in the window model. Our code currently looks like this:

# size of the whole simulation
size [15 15 3]


# configure the GUI window
window
(
size [ 700.000 700.000]
scale 0.025
)

In Stage 3.2.0 it is no longer necessary to declare the size of the simulation outside the window, it's done instead using the scale parameter of the window. The window scale used to be calculated by doing map_size/window_size, now it is window_size/map_size. Since we want our window to be 700px by 700px and our map to be 15m by 15m this is 700/15, which works out as 46.6 reuccuring. This needs to be rounded down to fit in the window properly, after a little trial and error I found a scale of 40 worked ok, although sometimes it doesn't render the box surrounding the map, scrolling up and then down on the Stage window solves that problem or alternatively reducing the scale to 35.

The Stage simulation now looks like this:

Next the polygons parameter has been replaced with block. usage is similar though, let's look at the bigbob postion model that used polygons:

polygons 3
polygon[0].points 6
polygon[0].point[0] [0 0]
polygon[0].point[1] [0 1]
polygon[0].point[2] [0.75 1]
polygon[0].point[3] [1 0.75]
polygon[0].point[4] [1 0.25]
polygon[0].point[5] [0.75 0]

polygon[1].points 4
polygon[1].point[0] [1 0.75]
polygon[1].point[1] [1.25 0.75]
polygon[1].point[2] [1.25 0.625]
polygon[1].point[3] [1 0.625]

polygon[2].points 4
polygon[2].point[0] [1 0.375]
polygon[2].point[1] [1.25 0.375]
polygon[2].point[2] [1.25 0.25]
polygon[2].point[3] [1 0.25]

block
(
points 6
point[0] [0 0]
point[1] [0 1]
point[2] [0.75 1]
point[3] [1 0.75]
point[4] [1 0.25]
point[5] [0.75 0]
)

block
(
points 4
point[0] [1 0.75]
point[1] [1.25 0.75]
point[2] [1.25 0.625]
point[3] [1 0.625]
)

block
(
points 4
point[0] [1 0.375]
point[1] [1.25 0.375]
point[2] [1.25 0.25]
point[3] [1 0.25]
)

The same was done for the carton model, the simulation now looks like this:

The problem with this model is now that the bigbob robot is hollow! If we look at the simulation using Stage 3.2.X's perspective mode (press R) it looks like this:

Trying to work out how this code differs from the supplied example code where the robots aren't hollow is SADNESS. To save you the trouble of asking the Player/Stage mailing list the same question I did I can tell you the problem is that the points need to be declared anti-clockwise! If you look at the block code you can see that as you plot from points 0 to 5 the corners progress clockwise. I can't take credit for finding that out though. Finally with the blocks you have to declare where the block is in the z plane. This is done with z [height_from height_to], so if I wanted my block to be from the floor to 1m in height I'd do z [0 1], if I wanted it to be from 50cm off the ground to 1m then I'd use z [0.5 1].

Let's say that Bigbob is 1m tall (which was established earlier when I set the size) and the teeth to be 50cm tall and on the ground. Implementing these changes gives block code like so:

block
(
points 6
point[5] [0 0]
point[4] [0 1]
point[3] [0.75 1]
point[2] [1 0.75]
point[1] [1 0.25]
point[0] [0.75 0]
z [0 1]
)

block
(
points 4
point[3] [1 0.75]
point[2] [1.25 0.75]
point[1] [1.25 0.625]
point[0] [1 0.625]
z [0 0.5]
)

block
(
points 4
point[3] [1 0.375]
point[2] [1.25 0.375]
point[1] [1.25 0.25]
point[0] [1 0.25]
z [0 0.5]
)

You may note I've been somewhat lazy in converting the coordinates from clockwise to anti-clockwise. It still works fine though and the finished world looks like this:

This completed code can be downloaded from this link:

Player/Stage 3.2.X Bigbob example code

E-Pucks in Player/Stage: Building a Stage model

2009-10-21T10:32:00.005+01:00

My latest project using Player/Stage is to implement flocking on my university's swarm of epucks. To do this I'm first going to build a simulation of the flocking in Player/Stage, with the simulation I can check that my code works and that the flocking is performed reasonably well. Then I will transfer the code onto the epucks, which means the epucks will need calibration so that they work together in a way which is (ideally!) close to what the simulation showed they'd do.

The first thing I'm going to do is build a Stage model of an epuck which I can use for my simulation. This will be based partially on what Player/Stage drivers are written for the epucks, so far only the Position2d, IR, Camera and Blobfinder drivers are available for use. This means I don't need to add any other devices to my model.

This is Walter(1), he serves as a testing platform for all my code. This is what an e-puck looks like, and what we are trying to create a model of:

(The front side of the epuck is the end where the sticker is)

Now, happily, someone somewhere has actually already written a stage model for the epuck which I've uploaded here, I won't include a code listings because it's quite long and complicated. This is how it renders an epuck:

You might think that the work is done but no, I like code to be nice and I like it to make sense; this model description is neither. First we'll start on the ranger sensors. Their yaw values are all over the place, 342.8, 314.2, 270, 208.5, 151.5, 90, 405.8 and 377.2. I'll change these to be sensible values between -180 and 180. It's important to note the index that each ranger is given, the counting starts at 0 being the front right IR (that's the black blob above the clear LED in the second photo) and increasing around clockwise (looking down on the robot).
spose[0] [0.030 -0.010 -15] #fr right
spose[1] [0.022 -0.025 -45] #fr right 2
spose[2] [0.0 -0.031 -90] # right
spose[3] [-0.03 -0.015 -150] #back right
spose[4] [-0.03 0.015 150] #back left
spose[5] [0.0 0.031 90] #left
spose[6] [0.022 0.025 45] #fr left 2
spose[7] [0.03 0.01 15] #fr left

Next I got rid of all the complicated polygon specifications which make the epuck look nice. That includes the "turret" which is the Y shaped thing on top of their model, the wheels (the thick black lines on the model) and I changed the shape of the robot. In the original model the epuck is an 18 cornered polygon, I replaced this with a bitmap called "circle.png" which is just a black circle on a white background. This one in fact:

The final step is to fix their blobfinder code. In the original epuck model they do a weird thing where they define the epuck camera and blobfinder inside the position description. I completely re-wrote this so that it makes sense:

# epuck blobfinder
define epuck_cam ptz
(
blobfinder
(
# number of colours to look for
channels_count 1

# which colours to look for
channels ["red"]

# camera parameters
image [640 480] #resolution
range_max 5.00
ptz [0 0 0]
)
size [0.001 0.001]
)

I'm using Stage 2.1.1 on my computer, so the blobfinder has to be described within a ptz model. I will only use the blobfinder to look for red becuase the epucks have red LEDs around them, so looking for red will mean the epucks can detect each other. The camera on the epuck is fixed in position so it can't pan, tilt or zoom hence ptz [0 0 0]. The size of the camera is set to be 0.1mm x 0.1mm so that it doesn't show up on the stage simulation, the default camera size for the ptz model is much bigger than the epuck so the size parameter MUST be set.

That's basically it then for the model making! The final version of the epuck Stage model can be downloaded here: Epuck Stage model. The model doesn't look as impressive, but it is much easier to understand now. Enjoy!

(1) Why is he called Walter you ask? The answer is because Walter the Wobot is just about the cutest robot ever. Cwipes!

The Organisation of Complex Systems

2009-08-27T11:31:00.001+01:00

Simon, H.A. (1973) "The Organisation of Complex Systems". Book chapter in: Hierarchy Theory - The Challenge of Complex Systems , Pattee, H.H. eds. pp 1-27

This was quite an interesting paper which draws heavily from his "architecture of complexity" paper. This one is mostly about how complexity is present in pretty much everything. The reason for this is that it's easier to build a systems out of stable subsystems than by building it all at once. He goes into this in greater depth with lots of examples. One of which is a computer system and he suggests that computers will become the most useful experimental tool becuase they can think and we can easily do experiments on them.
Another point made in this paper is about "loose horizontal coupling" which is interactions between systems on the same hierarchic complexity level. He says that systems on one level can communicate with lower levels in a certain way, but those lower levels are independent and so long as they produce the same output they can be improved as much as they like without affecting the higher levels this also speeds up evolution because a system can be constantly improving on all levels at once. This idea also discredits the idea of reductionism because if levels are independent of each other then understanding a lower layer fully isn't going to tell you very much about the higher levels so why even bother?
Overall this is a good paper and there are some interesting issues discussed, there's a few handy quotes too!

My more detailed notes on the paper.

The Stone Age.

2009-07-24T11:40:00.001+01:00

I was having dinner with lots of computer sciencists last night, these things happen in academia (I love my job). The older scientists told us all stories about what it was like to do computer science in the olden days, particularly one of my supervisors, Professor Alan Winfield. He's a real engineer! I don't want to spoil his anecdotes, but this is amazing. When he was doing his PhD back in the 70s one of the academics very excitedly brought in their new (first generation) Intel processor. There was absolutely no software running on it (like y'know an operating system) it was just some hardware attached to a board. Without any support. So what him and a few others did is develop a compiler for it and a system for downloading code and a bootloader and all the stuff that's needed to just make the thing work (same story as told by Alan). These days just one of those things would be a phd worthy endeavor, they did it just because it was there! I wouldn't even know where to begin, I don't know what a bootloader even is. It's amazing, I have a Master's degree in electronic engineering and I know NOTHING about real engineering like that. How was it possible for me to get that degree? When I went to Aberystwyth there were guys there (specifically Mark Neal and Colin Sauze) and they could just knock together some stuff and it becomes a fully working robot!
Anyway, back to the point. Alan's mentioned that they transferred code between their giant processors and computers using punch cards. Punch cards! Really that's only one level up from bashing rocks together. To debug their code it was easier to edit it on the card than in the code on the processor, he would de-bug stuff using a hole punch and some white tape. He had another story about how he de-bugged a problem in his code using an oven! Computer science, it would seem, was difficult in the past. You wrote a program and the next day it would be compiled, the day after that you might be able to get time on the university computer to run your code. What discipline it must take to make your code perfect first time. How much dedication must you have needed to de-bug something on punch card or wait 2 days to find the results of your code?

The point I'm making here is that technology has come a LONG way since the late 70s / early 80s (hereafter refered to as "the stone age"). Even during my lifetime there's been a hell of an improvement. During the same time there's been a dumbing down of us as computer scientists. I don't think I know anyone (apart from Alan obviously) who is so very capable and dedicated that they could work with this old technology and remain motivated and sane. The sheer range of knowledge required is astounding! So much of this tedious, difficult work is done for us these days. It's easy to write something that doesn't quite work, there's no rigour. I don't need to read and re-read my code to check for syntax errors or memory leaks: it takes 2 seconds not 2 days to compile and run code. The level of dedication and perservance that was required to complete a computer science PhD in the stone age has been lost, what will things be like in the future when I'm Alan's age? Will I be telling the young students about how when I started university computers only had ONE core? Will the role of programmer be usurped altogether? Will robots assemble themselves out of a heap of compoent parts? Given the current rate of technology development the gulf will be even bigger than the current stuff and punch cards. A prospect both scary and exciting. Exciting in that we'll have new toys, but scary to consider how much lazier we'll have become.

Interactions Between Learning and Evolution

2009-07-14T15:23:00.001+01:00

David Ackley and Michael Littman (1991). "Interactions Between Learning and Evolution", In: Proceedings of the Second Conference on Artificial Life.

New paper added to my reading list.

This is a very interesting paper about some agents that can learn and also evolve. The learning happens over a short time span, the lifetime of an agent, the evolution happens as agents reproduce and populate the simulation. The agents use two neural networks as controllers, one of them is an 'action network' which controls how the agent reacts to a situation. The other is an 'evaluation network' which is how the agent decides what is a good situation and what is bad. The evaluation network and the initialisaiton for the action network are inherited from parent agents. So natural selection controls what the agents think is good or bad, and how they will initially react to stimuli in the environment, and over time the agent will adapt its action network to learn behaviours that result in situations it believes are good. The agents' aim is to live for as long as possible and to reproduce as often as possible.
The simulation they used was apparently very difficult to survive in, which skewed their results a bit (it made evolution a bit crappy for instance because agents, and most of the population, died before they could pass along genes). The results they presented of the one population that lasted over 9 million time steps were interestin though. They showed how having the population start out knowing that food is good eventually led to the agents instinctively getting food, it also showed that when the agents start off instinctively avoiding predators their evaluation of whether predators are good or bad had little effect. These results are somewhat contradictory but the experiment was successful in that the agents lasted a long time before going extinct.
Overall what they present is a very interesting control structure, and I think how they implement instinctive actions is quite clever (but smart people might think it was obvious) the paper leaves me wondering what would happen if it was easier to survive in the simulation, (probably there would be less adaption and the experiment would be much less interesting).

Finally, a Player/Stage Manual

2009-07-13T12:08:00.003+01:00

Well, the Player/Stage manual I've been talking about for so long has finally been released!
I've knocked together a basic web page about it on my work website:

Player/Stage manual

It's also been published on the official Player/Stage Website by Richard Vaughan. This makes me very happy! So far the only feedback I've had about it from people (these were the folks working from the first draft) was that it's great. Personally I just hope I haven't got things horribly wrong. The manual's been released a bit too late for this academic year (as far as students doing their final year projects are concerned) but I'm hoping it could be more widely read now.

Player/Stage Manual redux

2009-07-07T15:19:00.004+01:00

The Player/Stage manual is finished!
The rest of this week will be sent sending it people so they can check it for typos / errors and then I'll release it here, my website and (hopefully) to the Player/Stage website!
I'm very excited that I've actually seen this (very long) project through and I can really add something of value to the robotics community.
At the start of the AIR 2009 summer cam we had to make presentations about who we were and what we do, I mentioned that I'd written a Player/Stage manual and there was a collective sigh of relief and cries of "Publish! Publish now!". It really surprises me that no-one's done this earlier. There seems to be such a massive demand for it?
Anyway dear readers and people who search for "Player/Stage" in Google, wait until next Monday (the 13th July) and you'll be able to download my manual for yourselves!

ETA: see my next post about the manual.

AIR 2009 in retrospect

2009-07-03T14:20:00.003+01:00

After the first two days of lectures we then went on to work on a project in teams. My team were working on an autonomous sailing boat which uses an artificial endocrine system for fault tolerance. Our goal was to make the boat maintain a heading, so for instance it should always try and point towards north, if we can do this then the boat will move in a straight line. The difficulty was that the boat doesn't have a rudder, it steers with two sails, one at the front and one at the back. We only had 3 days to do this work in so although it doesn't sound ambitious it kept us very busy! The main problem came with communicating with the PIC on the boat since you can only receive information every so often without causing latency issues. We spent a long time solving this problem and cursing the PIC. I think it was a problem with the API or something. Anyway we managed to get it working and it can move in the direction we tell it to. It doesn't point the right way whilst doing it... it tends to oscillate around the goal heading and slows down a lot when it faces into the wind but it does move in the right direction.
Now the research camp is over my team (including me) are writing a paper for submission to UK Computational Intelligence in Nottingham. It'll be my first publication!

Overall the research camp has been a really good experience and I've learnt a lot about robotics and teamwork. The location, Aberystwyth, was also lovely and I miss the epic scenery and the beaches and lakes. I hope to go back soon! I would thoroughly recommend the summer camp to anyone who's interested in robotics as part of their PhD, there were even a couple of people there who knew nothing about robots and it was useful for them too. Very highly recommended, kudos to Martin Huelse for organising it.

AIR 2009 day 2

2009-06-27T23:27:00.003+01:00

The first talk this morning was by Guido Bugmann who talked about creating stimulus-response mappings. The benefits of which is that you can pre-plan what to do in a specific situation and then map that to an action, the point being that planning what to do is the slowest part of making the robots go and if you have some stuff that is pre-planned then the robot is much (much) quicker to react. One of the inspirations for this was tennis players, because they can decide on a course of action, like which way to run to get to the ball, in an incredibly short space of time ~200ms which is the quickest that a message can propagate through the brain (from seeing the ball being tossed to telling the muscles what to do). One of the things that he found interesting is that it is very very easy to program the brain. The example he used was to get us to raise our left hand if we saw a letter A on screen and our right hand if we see a B. That's a pretty straightforward task right? In the process of telling us what to do he's made us program our brain to do this simple task, which wouldn't have been evolved or taught we can just do it without practise. Psychologists haven't really investigated this phenomenon, they tell subjects to do something and then look at what the subject did, there's not really been any investigation of how long it takes a subject to be "programmed" to do a task.

The next talk was byDave Barnes about the challenges of putting robots into space. Basically it's incredibly difficult! Everything ideally has zero mass, volume and power consumption and it has to be resistant to radiation and the cold and the heat. They spend an enormous amount of time callibrating the robots and all other parts of it, that's most of what they seem to do in Aberystwyth actually. The guys here built the robot arm for the Beagle 2 mission, and there's a lot of work that's gone into it. They were also responsible for the colour callibration thing which is basically some colours on a square which the robot can photograph in order to check the colour correction on the lenses (the Mars atmosphere distorts colour in a different way to Earth's atmosphere apparently). It's nothing more than a square of colours with no mechanics or moving parts but they needed 3 teams of scientists to work on it to prevent colour fading, or dust sticking to it and getting exactly the right colour pigments etc etc. A lot of work! This was easily the most interesting talk of the week. It gave a real insight into the issues of space robotics, basically it's nigh impossible and absolutely everything is working against you. Good stuff.
Another talk was about Artificial Immune Systems, in no other field of research I've encountered have people been so adamant about stating that you should consider the pros and cons of their algorithms and that it won't solve everything. I think this is partially because Jon and Mark are very honest about it... mostly because they "haven't found their niche yet", but that's just my opinion and is probably nothing like reality.

After the talks were all over we were taken to Aberystwyth's Mars Lab, where they test the Mars rovers! They have a scale version of the next Mars rover which is half size in all dimensions (so the real one is 8x bigger) which I photographed here (click to enbiggen):

Pretty neat huh? The white blobs are things for tracking the robot's movements across the lab. There's a picture of me with this robot, but that's far too blurry to put online. The white stuff it's stood on is Mars sand D, which is basically sand which is the same consistency and has the same properties as some Mars sand (there are lots of different types of sand on Mars). This rover's job is to look for sedimentary rocks and analyse samples to see if Mars once supported life. It also has a drill on the side (although this model I think does not) which drills down into the Mars soil to take samples from below the surface, because Mars has little/no magnetic field so doesn't protect the surface from the sun's harmful radiation.

AIR 2009 day 1

2009-06-24T18:59:00.000+01:00

For this week (23rd - 30th June) I will be at the Autonomous Intelligent Robots Summer Camp. This is at the University of Wales, Aberystwyth. The website has lots of details about the specifics, including a timetable of stuff that's going on.

This morning was a talk by Jeremy Wyatt about reinforcement learning which is when you use rewards and punishments to make a robot learn about its environment and how to react to it and make predictions about the outcome of its actions. I didn't know very much about it before, I'd read something about game theory in draughts from one of John Holland's books which sounded very similar. Basically a robot can observe the state of the world, and it has a policy which control how it acts when given a particular world state. The robot gets given rewards based on what you want it to do, like if you want it to push a box you can reward it whenever it pushes something. The robot has to modify its policy in order to maximise the amount of rewards it gets for ALL world states. There are associated issues like it could come up with a behaviour you don't want in order to get lots of rewards (like the box pushing robot might try to push a wall) so you need to be careful when designing the reward system. Also if rewards are too infrequent then the robot can never really learn because it is not told when it does good. He briefly mentioned something called inverse reinforcement learning, which is when you develop a reward system somehow and then use that to teach a robot, then what you teach the robot is fed back into the reward system and modifies it based on the learning process. This is then iterated and so you get a good reward system and a good robot!

This was followed by some lectures by members of Aberystwyth's robotics department who were talking about the things that are going on in their lab.
The first of these was by Mark Lee who talked about developmental robotics. Which is all about teaching robots to do a task in stages, much like how children/babies learn to do stuff gradually. They have a robot arm which has developed hand-eye coordination, they started by developing an eye and teaching it to centre upon certain coordinates so that it can move quickly towards a point instead of circling around it or searching or whatever. They then taught the arm to understand how its motor movements and positions map to its position on a table (looking down) which uses the eye to look at the robot's actual position. Then they taught the robot how to move to coordinates or objects on the table, effectively hand-eye coordination, since the robot arm know what position it needs to be in to get to a place and it can make minor modifications to its position given what it observes with the eye. Good stuff! It makes sense because they don't try to run before they can walk. Often, problems are encountered because people try to do too much at once and it's good to try and increment the difficulty of a task. Humans develop hand-eye coordination in a similar manner and we've been doing that for thousands of years, so the system must be good!

Another talk was on using a 360 degree panoramic camera to navigate to a certain point. This assumes you have a starting picture of where you want to be, they then find the difference between the current camera's image and the one of the goal location. The place where the difference is least will be where you want to go, but as you near that place the difference gets smaller and smaller so it allows you to home in. The good thing about this is that it works better if you use it in a visually rich environment (ie there are lots of colours and blocks and stuff) because it's basically landmark navigation. This is cool because a lot of vision analysis stuff for robots involves putting the robots in an arena where there's not much to look at so interesting things are easy to pick out, this work is much more applicable to real life because the real world isn't painted white!

The final presentation was about the robot scientist they have in Aberystwyth. This has an understanding of yeast biology and uses that to perform and analyse tests on yeast. It's basically a way of automating science so that you can do a lot of tests in a repeatable manner. They use it for identifying what some yeast genes are responsible for and it's been quite successful in that regard! It can apparently run ~1000 experiments a day and can make over 200,000 observations. Good stuff! We went to see it acutally, and it looks very cool.

More fun stuff will happen tomorrow I hope, now I'm off for dinner with everyone.

Bristol Robotics Lab Visit 11/06/09 part two.

2009-06-18T14:50:00.003+01:00

The first thing I did when I got to the Robotics Lab was to meet up with Wenguo and their intern Jean-Charles. These guys have been putting linux onto the 50 or so epucks which they have there, Wenguo being the guy who designed the linux extension (and incidentally is incredibly knowledgable about pretty much everything), and Jean-Charles being the guy tasked with doing all the repetetive instalation work (so is an expert on how it should all be put together). I spend a good hour or so chatting about how the linux boards work and what I need to install them. Mostly this meant having things patiently explained to me, over and over again until I could understand.

After the session the three of us went for lunch and met up with my supervisor in Bristol Prof. Alan Winfield. If you have a passing interest in swarm robots (or robots in general) then you may have seen this video before:

Alan is the guy in the video!
The project they're talking about in the video is called SYMBRION, which aims to create swarming robots that can combine together to achieve some goal. In the video they show an example of this end goal with the robots forming an X and walking (1). Wenguo, Alan and one of my supervisors in York, Jon Timmis are important people on this project!

Anyway, after lunch I was given a small tour of the lab by Wenguo and Jean-Charles picutres and details about this will be included when I get the information from my camera. Unfortunately I didn't get to see EcoBot this time, which is a shame because it's really cool. EcoBot is a robot which has a digestive system, not a virtual or simulated digestive system a REAL one. It consumes dead insects (2) and converts their bodies into electricity to power its movement. There's a video of EcoBot moving around, as you may guess the little black blobs it leaves behind are poop! Robots like this are really interesting because it makes you wonder just what qualities make something alive. This robot moves and eats and excretes, it's sensitive to external stimuli (light) it only really lacks reproduction and growth. Does that make it alive?

After visiting BRL I now have a list of extra stuff we need to buy to get the linux boards working on the epucks. I'm hoping that it won't be too difficult. Jean-Charles has written a very thorough guide to installing them and since the boards haven't been officially released yet I'll probably be one of the first people to work from the manual. Hopefully I'll be able to give Jean-Charles some useful feedback about it, having written a manual recently I know how difficult it can be to get constructive feedback on that kind of thing. Since coming back from Bristol our technicians in York have had a lot of questions about building the boards and all the parts required. Hopefully this will help Wenguo to make a really thorough package to describe the PCB and components.

(1) sadly this hasn't actually been achieved yet and that video is stop-motion animation. The tiny robots just can't make a strong enough connection for that kind of thing yet.
(2) Don't worry animal right activists! They collect them from around the lab from windowsills and dusty corners they don't kill them especially.

Evolving an Artificial Homeostatic System

2009-06-16T15:28:00.003+01:00

New paper added to my reading list.

Moioli, R.C. Vargas, P.A. Von Zuben, F.J. and Husbands, P. (2008) “Evolving an Artificial Homeostatic System”. In: Lecture Notes in Artificial Intelligence vol. 5249 pp. 278–288.
LINK

In this paper they evolve a robotic controller which uses neural networks to control behaviours (they used something called NSGasNet which they never explain) and an artificial endocrine system to decide which behaviour should be followed at any one time. An artificial endocrine system is a thing which uses "hormones" to assess its internal conditions (battery level etc) and as these get worse more fake hormone is produced (a number gets bigger) until it gets big enough that some kind of action is required. In this experiment they monitored battery level and as battery level decreased hormone increased and when there was enough hormone then the robot would switch from wandering around to going to get more power.
In all it's a thorough(ish) experiment. The way they used to develop the artificial endocrine system seemed to be sound and their results show the robot is robust to changes in battery discharge rate an evolved artificial endocrine system sounds like a good thing. That said, this paper doesn't provide enough information to replicate the results and their measure of when the robot performs well is worryingly qualitative, we effectively have to take their word that the robots performed well (for whatever value of "well" they used).

Bristol Robotics Lab Visit 11/06/09 part one.

2009-06-15T14:06:00.001+01:00

Two weeks ago on the 1st of June York university received a shipment of ten epucks. The e-puck is a small and versatile little robot which is packed with sensors. It's got 8 IR sensors, microphones, a speaker, accelerometers, a camera, bluetooth and probably more stuff I haven't listed, all controlled by a PIC; there's a wikipedia article here. Anyway it is my job at the moment to get these robots up and running so that they can be used for swarming experiments by students at this uni, probably masters students and some PhD people like me. What I need to do is to set them up so that you can write a Player/Stage simulation, and the code for your simulation can also be used on the real robots. Now, Player/Stage drivers for the e-puck have already been written and are freely available here so surely my job is done?

Well no. For one thing, the existing Player drivers require that a small piece of code is loaded to the epuck and then your Player/Stage code is run on the computer, commands are sent to your robot via bluetooth. So far my experience with bluetooth and epucks has not been good, mostly this has been down to a lack of drivers, generally I find the connection between the computer and an epuck to be rather fragile. Mostly what I'm doing at the moment is installing Linux onto the robots. Yes that's right, I'm installing linux onto robots that are controlled by a PIC.
It turns out that most of the hard work has been done in this regard. My colleague Wenguo Liu at the Bristol Robotics Lab has designed an extension to the epuck which is basically a tiny computer which runs linux. It's my job to take these boards and to install them onto our epucks. The linux board technology is pretty new at the moment, so much so that they are waiting for a paper on them to be published before they make the board designs and information open source.

This is why, on the 11th of June 2009 I visited the Bristol Robotics Lab...

A Player/Stage Manual

2009-06-10T10:41:00.002+01:00

Player/Stage is an open source robot simulator, which has become pretty much industry standard (at least in academia). It's a really powerful program that allows you to design a model of your robot and then write controlling code to make it do things in your simulation.
The really good thing about it is that the code you write to control your robot in simulation can also be used to control a REAL robot. Think about that for a moment... you can write a simulation and the same code that you simulate you can then put on to the robot. That's a wonderful thing!

The downside to Player/Stage is that it's a complete pig to learn to use. The online documentation has a lot of information, but very little of it is in enough depth for you to actually implement it yourself. This is understandable of course, it's an open source project the people who contribute to it generally contribute in ways to add functionality or to iron out any bugs. Trawlling through pages of documentation is no fun and no-one would willingly give up their spare time to do it. This leaves Player/Stage learners like me something of a problem when it comes to actually learning how to get things done.

Well, I've been learning on and off for the past few months and as I went, I wrote a manual to make the process easier for others in the future. At the moment the first draft is complete and I have someone learning to make simulations from it. So far the feedback is good but I expect I'll need to add more as I learn, things I've missed out, things I got wrong etc. After another re-drafting I'm going to try and submit it to the Player/Stage project to get as many people benefitting from my work as possible!

Watch this space...

EDIT: as of 13th July 2009 this manual has been finished and published! Finally a Player/Stage manual

Introduction

2009-06-09T13:22:00.000+01:00

So what is this blog?

I'm a PhD student at the University of York, studying swarm robotics. this blog is where I will put information about stuff I've done with robots that maybe other people might want to repeat or use. Apart from that I'll also blog about things I've discovered which I thought were interesting, journal papers I've read and maybe even other stuff I've done.