Swarm Robots and Data Mining

My current work is about extracting some "Higher Knowledge" using Data Mining on the log data collect from external sensors like a camera. Before going any further, let me tell you about the kind of robots I am using here.

1. The price of one robot is around 20K JPY or US$ 200. 
2. It runs on a 6V battery. It has two motors to control its motion.
3. It uses only 3 IR sensors to detect obstacles.
4. There is no way, we can store on-board signals (for instance, IR readings) and analyse it off-line using a computer. 
5. It does not have any communication capabilities (like wireless, radio or blue tooth) with which it can communicate with other agents or with a central computer.

Hence the controller design completely depends on the designer who 'observes' the robot behaviour during its motion (say using his eyes, or a camera) and then based on his understanding, he modifies the controller to improve its performance  while achieving certain goals.

Now, our purpose is to build a system, where behaviour of several robots are analysed using data mining methods and useful hints are derived which could be used by the designer to improve the controller. The story is like this ...

A designer (a person) writes an algorithm for the swarm robots to perform a task and then goes away at night for sleep. During his absence, robot behaviour is recorded through an external sensory system (say multiple camera system in a building).  An autonomous data mining system (ADMS) analyses these logs and finds out if any robot manifested any kind of anomalous behaviour. It also enumerates the possible causes for such a behaviour and suggests some improvements that could be incorporated to overcome this anomaly. So in the morning, the designer comes back and analyses the results. He either incorporates the suggestion made by the ADMS in improving the controller or rejects its suggestions. 

This sounds more like science fiction at this stage. However, we have just started working on it ... Following video shows the motion of 4 robots which have been programmed to avoid obstacles (walls or other agents) while navigating the workspace. In this task, the robots are to be designed to increase the patrol rate which is the rate at which robot explores the workspace.

Making your own Swarm Robot ... where to start.

Many labs in big universities make their own robots. For instance, S-bot (Swarm-bot) is being developed and maintained by LIS at EPFL. Here I would list  few commercial companies which provide you cheaper ready-to-use components to build your own robots :

1. Lego Mindstorm Nxt 2.0. The third party C interface could be obtained easily. Mindstorm Nxt 2.0 provides advanced capabilities like bluetooth or wireless communication, color detection.

2. Robot Designer by Japan Robotech Ltd. One of the good thing about this product is that they provide an integrated development environment for writting codes in C which can transferred on to robot by serial port. So, complicated algorithms can be implemented on it.However, it can not support more than 5 sensor inputs.


With Arduino boards, the capabilities of your robot could be increased to a great extent.For instance, it can support nearly 50 sensors ( I need to check this one, though!)

With time, I would try to update this information ....

Installing Player/Stage on Ubuntu Jaunty64bit

My system:

$ uname -a
Linux swg-desktop 2.6.28-14-generic #47-Ubuntu SMP Sat Jul 25 01:19:55 UTC 2009 x86_64 GNU/Linux


First install following packages using synaptic packet manager:

python-gdal netcdfg-dev libpq-dev libhdf4g-dev libgeos-dev libatk1.0-0 lib3ds-dev freeglut3-dev

Apart from this, you would need following more packages:

1. Opencv
2. Gtk
3. libtool
4. libboost
5. GDKpixbuf
6. G++
7. Glut/OpenGL
8. GSL
9. libdevice
10. Gnomecanvas
11. imagemagick
12. Swig
13. Ruby
14. libstatgrab
15. libXmu
16. xmms

Don't forget to install development packages (-dev) for these packages.


In order to install xmms, follow the instructions given here .

I downloaded the player-3.0.0-rc1 and stage-3.1.0-Sources packages from sourceforge site .

Untar these packages and follow the instructions given in README.txt and INSTALL.txt files. Once you have installed the files correctly, you should check if you are able to execute simple commands as mentioned in the player/stage homepage. Instructions for installing Player is given here . Follow this link to find out if player/stage is installed correctly and instructions for Stage installing is given here .

Basically, you should be able to the run the following command successfully. Go to the stage source folder.

$ which stage
/usr/local/bin/stage

$ cd Stage-3.1.0-Source
$ stage worlds/simple.world

This should give you following animation screen :

In case you get an error saying shared library could not be loaded, you need to include the folder containing player/stage libraries (/usr/local/lib) into the file /etc/ld.so.conf and then run following command on terminal :

$ sudo ldconfig

for Stage 3.1.0, install libfltk1.1.x, libpng, libtool (libtdl) and opengl libraries. Read the INSTALL.txt file inside the source package.

I also tried installing it on a 32 bit Jaunty and it works fine. The configuration is as follows:

Linux swg-laptop 2.6.28-14-generic #47-Ubuntu SMP Sat Jul 25 00:28:35 UTC 2009 i686 GNU/Linux

I faced problem while installing this on Ubuntu Intrepid (8.10). While everything compiled properly, it gave me an error like "Insufficient GL support" when I tried to execute the stage command. The problem was allegedly with unsupported ATI drivers.

Real life robot applications

I just came across this amazing blog which posts the recent developments in robotics.


http://www.botjunkie.com/

It has some amazing robot videos ... starting from squeezing robot to dish-washer to wagging tails ....

Jargon

Since several terms are in use, it is better to get familiar with the some of the commonly used jargon in this domain:

1. Visual-motor coordination (VMC) basically makes use of techniques that try to establish a map between the end-effector position (or pose) with the joint angle vector (theta). In this aspect, it can be considered as a static mapping between the task space and the configuration space. Most of the time, it makes use of forward kinematics map of the manipulator.
   
   
2. Visual Servoing (VS): Visual servoing tries to establish a map between the end-effector velocities and the joint angle velocities. It necessitates the knowledge manipulator Jacobian and in some cases may involve manipulator dynamics as well.
   
   
3. Task space (workspace) of the manipulator is the 3-dimensional Cartesian, real world space or volume where the manipulator is supposed to move about and carry out the task.
   
   
4. Configuration space (or joint angle space) of the manipulator is the set of all valid joint angle vectors that would lead to a end-effector position and orientation within the workspace.
   
   
5. Pose of a manipulator is the end-effector position and orientation with respect to a global reference frame. Usually, base frame of manipulator is taken as the global reference frame for all kinds of measurements.
   

Introduction

It is the coordination between the motors of a robot manipulator and the vision system. Just recall how our eyes are indispensable when we move around or do various things with our limbs. The idea is to get the real world coordinates using a stereo-camera and then feeding these coordinates to the robot so that it can move to the desired target (viewed by camera). Technically speaking this entire field of integrating of vision with robot motion is known as Visual Servoing. A nice introduction in this regard is available here.

We can divide entire problem into two parts:

1. First extracting useful features from the camera images that gives a description of the manipulator workspace.
2. Once the workspace description is available, how to guide the manipulator to carry out a desired task in this workspace.

When a camera model is used to convert the features obtained in image plane or space are converted to some useful quantities in Cartesian space and then the second problem is solved, we call it PBVS (position-based visual servoing). But most of the times it is useful to solve the problem directly in the image plane itself obviating the need for a precise camera model. This leads to image-based visual servoing (IBVS).


Another distinction can be made based on the location of camera relative to robot base.

1. Eye-to-hand configuration: Cameras are mounted over the workspace so that its position relative to robot base is always fixed through out the operation.
   
2. Eye-in-hand configuration: If the cameras are mounted on the manipulator end-effector itself, so that its relative position changes with respect to the robot base the manipulator moves.