SIMULATIONS IN OLFACTORY, MANY ROBOTS

This blog post describes a player/stage simulation for multiple robot mapping with goals or reference points as odor sources. Let's think of a situation where we need to explore large environment and generate its map which can be used later on for navigation and localization. In this scenario, instead of single robot exploring such a large environment, its always beneficial and effective (in terms of processor usage and time) to allow multiple robots to explore different parts of the environment and merge the maps finally whether topologically or based on overlap regions in occupancy grid. 

This idea is based on Mobile Robot Olfactory experiments performed by ISR Embedded Systems Lab, details of which can be found here: (http://ftp.isr.ist.utl.pt/pub/roswiki/simulator_plumesim.html). 

The idea of using PlumeSim library for this purpose came from this interesting project of PlumeSim framework which simulates odor transport in the environment. The basis of this project is that olfaction is a key sense in the survival of many biological species. 

This article deals with the process of installing PlumeSim plugin driver initially followed by multiple robot mapping simulation in player/ stage. This driver is capable of introducing simulated chemical plumes into a simulated/ real robot from broad range of sources to CFD (computer fluid dynamics) software. Based on data collected from real world experiments, its also able to playback recorded plume in future periodically. 

Below are the steps involved in setting up the driver for this purpose:

1. The driver library can be downloaded at this link or at this github
    link: https://github.com/DevasenaInupakutika/PlumeSim-1.0

2. Clone to your local repository through terminal as below:
    
    git clone https://github.com/DevasenaInupakutika/PlumeSim-1.0

3. Enter the directory: 

     cd PlumeSim-1.0

4. Build the library using below command which will create the required driver
    (libPlumeSim.so):

    make

This plug-in driver in player/ stage brings plume simulation into the world of mobile robotics. This can be used as a great tool for developing odor search algorithms providing smooth path from simulated robot to real environment.

Sample output, the blue dots show the plume of the gas

In this article, we have taken use-case of this driver in multi-robot map merging. For this purpose, please follow below steps:

Note:  Make sure all the path corresponding to player/ stage packages and library are at same location.

1. The player/ stage package can be downloaded from here using below 

    command:

    git clone  https://github.com/DevasenaInupakutika/Player_Plumsim 

2. cd Player_Plumsim and Use make clean command to clean if package is  

    already built.

3. Built the package as below:

   

   g++ -o main`pkg-config --cflags playerc++` main.cc `pkg-config --libs  

   playerc++`

4. Run the program as below:

    player map_square.cfg

    Open another terminal (in a separate tab):

    
    ./main -p 6665 -r 1 

    (which means robot 1 will start moving where 1 is robot id    and 6665 is port 

    number)

The configuration file (map_square.cfg) contains description of robots and 

corresponding ports. The prime important thing so as make multiple robots to move is to assign either separate port numbers for each robot or use separate robot ids on same port number.

5. In order to run another robot, open another terminal tab and type below   

    command:

    ./main -p 6665 -r 2

   and so on. This has maximum of 12 robots.

After executing all the above steps, you get results similar to the ones shown in the below screen shots and corresponding robot text files (robot<id>.txt) files get updated based on which robot is traversing the environment and it's distance from odor source. The emanating gas is shown in red while the robots from top view are circles of various colours.

The files being updated contains simulation environment's map topological data (in terms of coordinates).

This work has also been implemented on ROS - occupancy grid map merging where in robots generate local maps by exploring separate areas of environment and merge based on overlap regions into a final global map which will be discussed in separate article.

This can be implemented on real robots as well using the player server of the player/stage suit.

OBSTACLE AVOID FOR PR2

LASER OBSTACLE AVOIDANCE FOR PR2

One of the basic behaviour a budding roboticist often starts with is obstacle avoidance using sonar or laser scan. While playing with gazebo simulations, we realised that we are yet to try out a very basic laser obstacle avoidance behaviour in the PR2 robot employing the SICK laser. It was not long that we wrote our codes and made our ROS package and started with simulations in gazebo. A surprise awaited us ........

WHAT THE HELL !!!! 

We got an empty world with PR2 and then filled it up with boxes and set our code into action. Much to our surprise the PR2 robot did not try to avoid those boxes, but push them rather awkwardly. 

BOX PUSHING INSTEAD OF OBSTACLE AVOIDANCE

It was after few such 'failed attempts' and cursing our code incessantly that we realised that the issue is with the stretched out arms of the PR2. The distance for the obstacle avoidance to work is at min_range<=0.5, however we never had accounted for the PR2's arms while coding so the obstacle avoidance code is not coming to fore and is restricted by the arm lengths. Thus when the PR2 reaches the obstacle it continues to move and 'push' the obstacles, since gazebo is a physics based simulator thus in a box world it reflects such as a 'box pushing' behaviour. It may be said that such a behaviour arises in the 'emergent' context. Playing around with the code, we finally set it to, min_range<=1.2 which sorted out the issue.

The codes discussed here can be found at, https://github.com/Arkapravo/laser_obstacle_avoidance_pr2, feel free to write to us at Arkapravo Bhaumik (arkapravobhaumik at gmail dot com) and Koushik Kabiraj (koushik dot atti at gmail dot com).

MORSE CODE PART - I

MORSE 0.6

I installed MORSE 0.6 and linked it up with ROS on Ubuntu 12.04 and  it was fun to try out simulations of PR2 and ATRVs. I was interested in simulating a 2 robot system where one robot was guided by ROS nodes while the other was controlled by MORSE. This article is a brief on how I got that working ! 

THE kb_control CODE

Koushik and I have been tying to use kbhit() function to model teleoperation in ROS, however lack of a conio.h  in gcc made us channel our efforts differently (fcntl.h), and develop our codes.

SETTING IT UP IN MORSE

Instead of a single ATRV, I put in 2 ATRVs in my simulation, Castor and Pollux. Castor controlled by ROS nodes while Pollux was by MORSE keyboard. In the Python script (two_atrv.py) it was easy to 'connect up' Castor to ROS and Pollux to MORSE;

To link up ROS nodes with MORSE, remapping of the launch file (kb_control_morse.launch) is done,

The remapping is done by checking the rxgraph and enabling publisher/subscriber connectivity to ensure the interconnectivity of all the nodes. A working rxgraph for this simulation is as shown,

THE SIMULATION

Download the kb_control package from https://github.com/Arkapravo/kb_control and install it, rosmake kb_control

Place the file kb_control/morse/two_atrv.py at /opt/ros/morse/share/morse/examples/scenarii/

Start an instance of the master

Start the morse simulation, cd /opt/ros/morse/share/morse/examples/scenarii/ && morse run two_atrv

Start the kb_node, roslaunch kb_control kb_control_morse.launch

Now you should be able to control Castor with ROS and Pollux with MORSE.Click on the blender screen, the arrow keys will move Pollux around.Click on the kb_control terminal window, the arrow keys will move Castor around.

MORSE 1.0

MORSE 1.0 is slated for release in February 2013, with various improvements and newer features.

ACKNOWLEDGEMENTS

I am thankful to the morse-user mailing list (morse-users at laas dot fr) particularly, Florian Lier (flier at techfak dot uni-bielefeld dot de), Michael Karg (kargm at in dot tum dot de) and Séverin Lemaignan (severin dot lemaignan at laas dot fr). I am also thankful to my friend Vasileios Lahanas (vasileios dot lahanas at hotmail dot com) for his suggestions regarding kbhit() function. 

The codes discussed here can be found at, https://github.com/Arkapravo/kb_control, any issues with the simulation then feel free to write to us, Arkapravo Bhaumik (arkapravobhaumik at gmail dot com) and Koushik Kabiraj (koushik dot atti at gmail dot com).

THE KHEPERA

ORIGINS

The Khepera is a small mobile robot developed at the EPFL (École polytechnique fédérale de Lausanne) by Prof. Jean-Daniel Nicoud and his team. The Khepera has been developed and manufactured as a commercial product by the K-Team Corporation, for use in education and research. 

In Egyptian mythology, Khepera is the name of a beetle looking god, symbolizing the forces moving the sun. Khepera is more widely associated with “rebirth”, “resurrection”, “renewal”, and the general idea of “coming into being”: it might have inspired the looks and the name of the robot!

The main purpose of the Khepera is to provide a platform allowing training and experiments, involving local navigation, artificial intelligence, collective behavior, and real time programming.

It is widely acknowledge that the Khepera played a non negligible part in the emergence of evolutionary robotics.

ORIGINAL VERSION

The original Khepera is a 55mm diameter and 3cm high robot, constructed around a 16 MHz Motorola 68331 processor. Its motion and steering is achieved via 2 DC brushed servo motors with incremental encoders, and obstacles are detected thanks to 8 infrared proximity and ambient light sensors. The robot can be remotely operated, as the previous Kheperas, via a Personal Computer. 

Released 10 years ago, it has received a significant processor and firmware update before been discontinued. Let’s note that the sensors work pretty much like contact switches: the mobile robot could only detect very close obstacles.

K-2.0 VERSION

The Khepera II solved many shortcomings of the original, such as the reach of the distance sensors, swappable battery pack system for optimal autonomy, and a better differential drive odometry, allowing more precision on awkward surfaces. The khepera is now also capable of embarking additional modules increasing the versatility of the system. However, the most notable improvement is the added processing power improving the robot’s computing autonomy. 

K-3.0 VERSION

The third iteration of the Khepera is almost a revolution from the hardware point of view. On top of an array of 9 infrared sensors, two ground oriented sensors allowing line following and edge detection, the Khepera also embarks five ultrasonic sensors. 

An additional module allows Linux support, Flash extension cards, Wi-Fi, Bluetooth, 2D cameras, and extra storage space to complete the Khepera’s arsenal. The mobile robot also provides the user with improved quality motors and odometers to work with.

KHEPERA, PROGRAMMING AND CONTROL

Remote operation programs can be written with Matlab, LabView, or with any programming language supporting serial port communication. Here are the interesting ones; 

#.1. KiKS

KiKS means "KiKS is a Khepera Simulator", and runs under Matlab. It was developed by Theodor Storm as a Master’s degree year long project. KiKS emulates one or more Khepera robots connected to the computer by simulating motors, proximity/light sensor, and behaviours. 

 #.2. KHEPERA SIMULATOR

Khepera Simulator is a freeware package allowing to develop controllers for the mobile robot Khepera using C or C++ languages. It includes an environment editor and a graphical user interface. Moreover, if you own a Khepera robot, you will be able to switch very easily between the simulated robot and the real one. It is mainly directed at teaching and research in autonomous agents.

#.3. KHEPERA IN PLAYER/STAGE

Khepera can be simulated in Player/Stage;

#.4. KHEPERA IN WEBOTS

Khepera in Webots simulator;

 

ROOMBA@PLAYER/STAGE

ROOMBA ROBOT

The roomba series of robots were designed by iRobot Corporation, primarily for vacuum cleaning and floor washing purposes. However, they are excellent and inexpensive tools to study robotics.

ROOMBA@PLAYERSTAGE

In Player/Stage installation files, one can find the irobot.inc file at; Stage-3.2.2-Source/worlds/irobot.inc

Making the irobot.inc file work with the sick laser one can get simple simulations.

ROOMBA@ROS

Roomba also has a  ROS package

ROOMBA@WEBOTS

Roomba icreate is  ready design in the the robot simulator webots. Though webots is not a free software, but it finds popularity in various universities. 

ROOMBA@GAZEBO 

For some samples of Roomba simulation in Gazebo simulator see my post, http://mobotica.blogspot.in/2012/01/teleoperation-in-gazebo.html

EMERGENT BEHAVIOUR - A DEMONSTRATION

EMERGENT BEHAVIOURS

Emergent behaviour; the system behaves in a novel way, unlike the way it was designed to do. Such behaviours have always been viewed with a sense of mysticism. 

Here are some opinions expressed by AI researchers and system technologists;

• Emergence is “the appearance of novel properties in whole systems” (Moravec 1988)

• “Global functionality emerges from the parallel interaction of local behaviors” (Steels 1990)

• “Intelligence emerges from the interaction of the components of the system” (Brooks 1991)

• “Emergent functionality arises by virtue of interaction between components not themselves designed with the particular function in mind” (McFarland & Bosser 1993)

• “They are a consequence underlying the complexity of the world in which the robotic agent resides and the additional complexity of perceiving that world” (Arkin 1998)

• “....the arising of novel and coherent structures, patterns and properties during the process of self-organization in complex systems”(Goldstein 1999)

• “.... where the agent appears to do something fairly complex, but is really just the result of interaction between simple modules” (Murphy 2000)

• “Behaviors serve as the basic building blocks for robotic actions, and the overall behavior of the robot is emergent” (Murphy 2000)

• “Emergence is ubiquitous” (de Haan 2007)

Steels mentions two advantages of emergent behavior when compared to directly programmed behavior;

• No additional structure is needed inside an agent to get additional capabilities. Therefore, we do not need any special explanations on how the behavior may come about.

• Emergent behavior tends to be more robust because it is less dependent on accurate sensing or action and because it makes less environmental assumptions.

Goldstein points out to the generic characteristics of emergence;

• Radical novelty (features not previously observed in the system)

• Coherence or correlation (meaning integrated wholes that maintain themselves over some period of time

• A global or macro “level” (i.e., there is some property of “wholeness”)

• It is the product of a dynamical process (it evolves)

• It is “ostensive” - it can be perceived. 

Brooks demonstrates how walking can emerge from a network of rather simple reflexes with little central control. Murphy provides an excellent insight into the topic in her book, 'Introduction to AI Robotics'.

 

..... away from the apparent magic, such behaviours are observed due to interaction of the system components.

OBSTACLE AVOIDANCE == WALL FOLLOWING  

In mobile robotics, a well known emergent behaviour is seen when the agent  may exhibit 'wall following', when it is programmed to 'obstacle avoidance'. 

Simple experiments in Player/Stage demonstrate this;

It is also seen that other behaviours as, 'wander' and 'random walk' fails to have a 'wall following' emergence of behaviour. 

 REFERENCE

(1) Brooks, R.A. "Intelligence without reason", Computers and Thought, IJCAI-91 ; also MIT AI Lab Memo 1293, April 1991.

(2) Steels, L. "The Artificial Life Roots of Artificial Intelligence", Artificial Life, Volume 1 Issue 1-2, Fall 1993/Winter 1994.

(3) An entertaining discussion on 'Ant Bridge' by Pedro Bittencourt 

(4) de Haan, J. "How emergence arises", Ecological Complexity 3 (2006) 293 – 301
(5) Goldstein, Jeffrey (1999), "Emergence as a Construct: History and Issues", Emergence: Complexity and Organization 1 (1): 49–72

(6) Youtube videos, 'Emergence - Complexity from Simplicity, Order from Chaos'; Part-1 & Part-2

(7) Brooks, R.A. "A Robot that Walks; Emergent Behaviors from a Carefully Evolved Network",  MIT AI Lab Memo 1091, February 1989

(8) Ackerman, E. "Swarmanoid Robot Teams Up with Itself to Steal Your Book" - article in IEEE Spectrum, Aug 2011
(9) Wikipedia page on Emergence

 

BIG BOB

JENNY'S BIG BOB

One of the lovable robots you are likely meet while learning Player/Stage is Jenny's Big Bob. Jenny has written some excellent tutorials for the Player/Stage newbie. Lot more can be found at her blogspot.

 

SIMBAD - THE ROBOT SIMULATOR

SIMBAD

Simbad is a mobile robot simulator for simulations in 3 dimensions and can be programmed in Java and Jython.  To use the simulator, one needs to install Java 3D.
 

JAVA 3D INSTALLATION

Java 3D can be a messy installation in Linux, the Java 3D bin file has to be installed into the jvm folder.

I am on Ubuntu 10.04 LTS this worked for me;

:~$ cd /usr/lib/jvm/java-1.6.0-openjdk/jre

:/usr/lib/jvm/java-1.6.0-openjdk/jre$ sudo sh /home/acer/j3d-1_5_2-linux-i586.bin

After a long EULA agreement, if something like the following comes up then we are through with the Java 3D installation.

STARTING OFF WITH SIMBAD

Running the Simbad bin file can be done as;

:~$ java -jar simbad-1.4.jar

If Java 3D is properly installed, then the following window should pop up;

Playing around with the robot ! ....

SIMBAD WITH JYTHON

If you are a python enthusiast like me, then you may prefer to use jython than java.

ROS, TURTLES AND ROSVERSION

COMMAND LINE CHECK FOR ROS VERSION

A command line to check ROS version installed,

......1.4.9 makes it a diamondback release 

TURTLE REFERENCE 

All ROS distributions have a Turtle reference. Box Turtle, C Turtle, Diamondback .....

 

The reasons cited for such are;

• Reference to one of the first mobile robots made; William Grey Walter's Elmer and Elsie - they looked like turtles.

• LOGO Turtle, probably the simplest GUI based simulations for navigation. ROS also has a package very similar to the LOGO Turtle and it is often recommended as a tutorial for newbies.

• Other interesting reasons are, Turtle World and "It's turtles all the way down"

REFERENCES
(1) ROS Distributions

(2) I thank Gonçalo Cabrita and Ken Conley at ros-users@code.ros.org

MAPS AFTER VACATION

MAPS AFTER VACATION

Back from vacation and time to pick were my work was left off ..

Using player log to create a map ..... never knew that player/stage comes with inbuilt utility pmap utility.

on running the command $pmaptest -g "logname" -g non gui mode  

this produces a pretty neat map make sure pmaptest is built and linked and give a log file ... there are other options too 

I used writelog driver to generate the log

driver
(
name "writelog" log_directory "/home/iis-tainee/Downloads/logs"
basename "mydata"
requires ["laser:0" "position2d:0"]
provides ["log:0"]
alwayson 1
autorecord 1
)

WALL-E LOOKS FOR EVA

SPEECH IN PLAYER-STAGE 

We had met WALL-E@PLAYER-STAGE earlier this month. Now, WALL-E looks for EVA as he roams around.

Using the speech.cc file found in player installation files at player-3.0.0/examples/libplayerc++/speech.cc, modifying that file so slightly !

Using this script while WALL-E is set to 'wander' (Stage Controller) creates a fair animation, nicely combining the 2 behaviours; wandering and speech.

Lets hope WALL-E meets EVA soon ! :)