mobotica

WALLE@ROS

2012-01-28T18:34:00.002+05:30

WALLE@ROS

An interesting recreation in player/stage is walle, which was designed by Richard. I have made a ROS package of the same. The package can be downloaded here, http://mobotica.googlecode.com/files/walle_ros.tar.gz . The simulation may be run with the following command;

rosrun stage stageros `rospack find walle_ros`/world/simple.world

This stage window should pop-up,

The simulation script employs the stage wander controller, and the simulation starts off in the 'PAUSED' mode, left click on the stage window and press P to get things moving. Walle will wander around.

To have a closer look at walle, left click on the stage window and press R (Perspective camera).

NOTE

Tested on ROS diamondback, should work on ROS electric
Any issues with the ROS package, please write to me at arkapravobhaumik at gmail dot com

TELEOPERATION IN GAZEBO

2012-01-15T22:36:00.002+05:30

ROOMBA MODEL IN GAZEBO

We have met the roomba robot in one of my previous articles. Here, I work on some simple teleoperation on it, this time with a 3 dimensional model in gazebo.

I am grateful to Jeff for providing a URDF for the roomba icreate robot at http://code.google.com/p/aptima-ros-pkg/ .

TELEOPERATION

I used this roomba model with simple_office.world, which is one of the environments provided by the installation files for gazebo. I was able to move the robot around using teleoperation from teleop_base.

NOTE:

The simulations were done in ROS 1.4.10, Diamondback.
The URDF model is provided at Jeff's repository, I am not providing my codes - if you need them then write to me at arkapravobhaumik at gmail dot com

REFLEX MANAGEMENT AND THE SUBSUMPTION ARCHITECTURE

2011-12-14T19:06:00.004+05:30

~ A rap on an iterative idea-chain started by Rodney Brooks ~

The brain must allow not only the setting up of reflexes, but also their modification and control.

Initially speech and vocalisation seem reflexive in the infant, but then later as further development takes place speech can say anything it wants. So it is more than a reflex because, despite there being a finite limit on the number of reflexes, speech is unique nearly every time. Similarly many other intelligent behaviours are designed for context. How does this happen?

Is a reflex : “say something” like a frame or placeholder into whose blank space is inserted the results of speech design, which is originated in a separate process, perhaps also consisting of interacting reflexes?

There must be a level of reflex in behaviour but also a level of reflex management too, these two levels interacting. There are two possibilities, one a top-down control of reflexes, the other an emergent control where reflexes modify other reflexes and intelligent behaviour emerges from this melee. It was in Brooks' subsumption architecture that the small insect like behaviours I call reflexes were proposed, and robot design right now hasn't got that far into reflex management...but its to be hoped that the extra "rational" layers of reflex control and management will also be built in, or allowed to emerge.

How might a robot 'know' about all its possible reflexes and build this knowledge into its planning? This is suggested to me by the high connectivity of the brain where regions are multiply joined to other regions. In the top-down model the master controller might need to observe/study/predict its own behaviour as closely as the external world. If it has planning capability then it plans for its goals, first level, but it needs, second level, to plan for what its reflexes will cause too.

This looks like a kind of proto self-knowledge. The simplest reflex bypasses the frontal cortex or the brain altogether, like a knee jerk, but some reflexes may be initiated by higher functions, and that's what the tangled cortex is doing. What is the difference then between intelligent behaviour and a reflex? There may be many shades of grey.

The most necessary starting point for a robot may be to try lots of randomised behaviours and observe which cause successful change in the environment. If it has a picture in mind of a goal then it would need to look through its memories of what reflexes have given what results. Then it might know to try one or a combination of a few whose results may take it one step closer to finding itself in the environment it is aiming for.

If the movements of the vocal system start as reflexes learned through mirror neurons from mother giving baby talk, then real speech needs this kind of reflex management. There is basic emotional content in speech, and then there is the semantics of actual words. This can't be a single reflex because it's different every time. brain must have a meta-reflexive level that emerges from learning. I find it more believable that this doesn't work through totally centralised symbol/logic, the old paradigm, but that it emerges from reflex management, which is reflexes modifying reflexes.

Children badly need mirror neurons (in themselves and caregivers) for learning. This is not widely understood yet. I have observed it many times. the actual extent of mirroring is quite surprising. I believe in children that this approached the level of seeming telepathy, because I can remember much of my childhood and I could read the emotions and intentions of adults very clearly.

Reflexes (as actions) stimulate change in the physical environment, which is observed by the mind of a child or learning entity. But reflexes (as communication) also provoke changes in the minds of other humans, and the consequences of these are read partly by using mirror neurons to empathise and interpret emotions and states of mind. The amount of learning is huge, over decades, and given the slower pace of robot development this may mean the first learning robots need many years of childhood.

There may also be gradations of granularity. The reflex management function assembles composite behaviours out of granular collections of reflexes. This means that reflexes are aggregated into more complex behaviours, and therefore that something must be there from which the planning for this emerges. I am assuming this happens in the frontal cortex mainly. Maybe reflex management can build new reflexes out of collections of old ones. In generation of speech it might be that the finest granularity is the utterance of a single phoneme ? Other times a speech reflex may be larger, such as "I'm hungry mummy". The reflex management system assembles phonemes into utterances by modifying and combining the lowest level reflexes. But it also mashes these up with the emotional content of speech, intonation, breath and body language are added in to the final act of communication.

Concept

reflexes + reflex management = intelligent behaviour

So what if reflex management were itself merely a collection of reflexes ? Some reflexes have executive control or the power to hack and gain control over more primitive reflexes, like competing code in core-wars. So what we call intelligence seems to emerge from the collaboration of a swarm of reflexes. This makes a reflex like a Minskyan agent, and the society of reflexes emerges. This is an exciting synthesis that has been hinted at before.

Consider this famous quotation: "A clever man knows the right thing to say but a wise man knows whether or not to say it." Here wisdom corresponds to speech based reflex control, so in allowing some agents power of veto over lesser agents, behaviour is enriched.

The interaction of reflexes with each other could indeed get complex and tangled, but a small start can be made. Consider the following examples:

Define:

* reflex A : run forward until near object and outstretch arms to pick it up, then grasp

* reflex B: inhibit current reflex and freeze

behaviour 1: see toy, initiate A. result: "now I have the toy". Conclusion: this reflex is useful sometimes.

behaviour 2: see mummy, initiate A... then initiate B. result: run to mummy and outstretch arms then halt. Mummy also outstretches arms and hugs... consequence "I just learned to ask mummy for a hug". Conclusion: mark this as a new reflex to use again.

or this one

Define:

* reflex C : grasp object in front of me and raise to mouth to eat

* reflex B: inhibit current reflex and freeze

behaviour 3: see slice of banana, initiate C.

result: "I'm eating the banana"

behaviour 4: see flower in garden, initiate C...then initiate B.

result: "I can smell the flower now its under my nose".

consequence :"I learned to smell something"

conclusion: mark this as a new reflex to use again.

So it would be good for some reflexes to decompose into other behaviours when they are truncated. This allows the emergence of new behaviours when a given reflex is initiated but then inhibited before completion. Brain architecture thus may achieve a combinatorial explosion of possible behaviours with a small starting set of reflexes. Axioms breed theorems.

And for a robot:

Define:

* reflex A : follow another robot

* reflex B: inhibit current reflex and freeze

behaviour 1: see a robot moving. initiate A.

result "I am following another robot"

behaviour 2: see a robot moving. initiate A, then initiate B.

result "I followed another robot as far as the recharge station then he went on but I stayed put".

consequence: "you can go somewhere interesting if you follow someone - mark as new reflex"

So even merely aborting and freezing is a reflex management agent behaviour that is useful and potentially innovative. What about another agent behaviour that mashes together reflexes. Its easy to see that this combining meta-reflex would be useful. From above A + C would result in the ability to see something at a distance and then run to eat it. Note: I am now seeing how nerve racking parenthood may be for some!

Or maybe a meta-reflex that time-reverses another reflex or combination. I run backwards and remove what is in my mouth, then place it on the ground. or I run forwards, place a toy in my mouth and then run to mummy and ask for a hug, then spit the toy at her ;-) I am not a parent myself but I expect nearly all possible combinations may indeed play out in childhood at some time or another. Reversal is like an operator that can act on an existing reflex too: "I followed a robot to the charger and now I am going backwards. I got back to where I was before !"

Or a meta reflex to repeat another reflex. reflex D: take stick and smash it on the ground in front of you . reflex E: repeat current reflex... result: "I just smashed my toy into pieces and now it looks different and more interesting".

HELLO ROS

2011-12-11T18:28:00.001+05:30

ROOKIE'S GUIDE TO MAKING ROS PACKAGES

This article is a tutorial for accomodating a basic C++ 'Hello World' programme (helloROS.cpp) into ROS nodes.

Fig.1. helloROS.cpp program code

#.1 - Make the ros package, it should be in the ros path;

roscreate-pkg hello roscpp

That will create a 'hello' file with the following contents;

Fig.2. Files created by roscreate-pkg hello roscpp

#.2 - Make sure that it is in the ros path;

rospack find hello

If rospack can find the path to 'hello', then the package is 'visible' to ROS.

#.3 - Edit the CMakeLists.txt

At the end of the CMakeLists.txt file add;

rosbuild_add_executable(hello path/to/helloROS.cpp)

Where hello is the name of the executable to be made from the helloROS.cpp code. Usually it is a convention to keep helloROS.cpp etc files in the same folder- so the path/to/ is often not needed.

#.4 - Build the package

rosmake hello

#.5 - Run the code and confirm that it works !

rosrun hello hello

If that works then it should print Hello ROS and the C++ executable can be found in the bin folder, which is generated by the rosmake command. It is worth noting that since this is a very simple example, rosrun hello hello will work even without the master (roscore).

GRAFFITI : THE NEW AI

2011-12-02T12:24:00.001+05:30

BROOKS AND THE NEW AI

Cambrian Intelligence : The Early History Of The New AI, is a compilation of the best papers of Rodney Brooks and embody the principles of the new AI. In the preface Brooks uses a diagram - probably the best way to convey the new AI.

The New AI : The new model, where the perceptual and action subsystems are all that really is. Cognition is only in the eye of the observer

REFERENCES

(1) Cambrian Intelligence: The Early History Of The New AI

ECOLOGY BASED ROBOTICS - A SNEAK PEEK

2011-11-15T20:40:00.001+05:30

I come home, I find the automatic lawn mower mowing my lawn, as it is supposed to do when the grass grows more than 1.5 inches. At the door the face recognition system detects it is me and opens the door. My personal robot comes along and says "Good evening, tea and cookies will it be? " to which I smile and acknowledge. I enter my drawing room and the air conditioner realises my presence and starts cooling at 22 Degree Centigrade - as per my preference. Not long my personal robot gets me my cup of tea and cookies. Serves me and politely adds, "Just to remind, you have dinner with your collaborator, given the traffic and the distance a good time to start would be 7:33 PM".

This may not be too long into the future. A world which is dominated by automation and robotics may be just a couple of decades away. Since the 80s, researchers have realised the importance of applied AI, and away from the jargon laden ivory towers, AI has made its way to robots and intelligent machines which promise to bring the Clarkian world of science fiction to life.


Fig.1 Rosey the Robot Maid, from The Jetsons - An example of Personal Robot

ISSUES WITH BEHAVIOUR BASED APPROACHES

Brooks and Arkin enunciated the behaviour based approach, giving the robot its own sensory system so it can detect and respond to the environment coupled with a hierarchy of control laws which work in tandem. Thus if the higher level of control fails then the robot can 'subsume' to a lower level of the hierarchy thus preventing complete system failure. Adding on to this, anthropomorphising which has always been a great motivation to roboticists. The hunger for doing 'God like' and creating intelligence which reacts to external stimuli with concerted mechanical response; has been an ongoing effort for the last 3 decades.

An obvious problem to the Brooksian philosophy, which Brooks acknowledges to some extent in his paper (1991); is that the environment as perceived by the robot ,is what it appears to its sensors. Thus, for a mobile robot which has sensors with an angular span of 30 degrees, will see a chair as 4 metallic rods sticking out of the floor and also will have more appreciation of a 2D perception than a true 3D perception. Also, a sensor will have a finite range - so any world view will be an incremental endeavour, probably very slowly at times - this time lag may impair the robot's reactions. Maps may help till some extent - but real world is dynamic and thus not really 'mappable'.

Though, behaviour based approaches denounce analytical modeling, viz. the block world etc however, sensor based approaches clearly have their issues. As Brooks puts it, with a hint of sarcasm;

When we examine very simple level intelligence we find that explicit representations and models of the world simply get in the way. It turns out to be better to use the world as its own model.

I AND THE WORLD - THE ECOLOGICAL APPROACH

The idea to model the world and the agent as a single unit is probably most appealing to a software designer, such was discussed by Saffiotti (1998) in his doctoral research.

The philosophy that the world embodies the agent in itself, this ubique point of view is probably the starting point of Ecology based robotics, extending this idea leads to more potent conceptions; a number of interacting robots and devices all of which work in tandem and in explicit cooperation. The very idea being motivated from the concept of Biological notion of Ecology - where each creature's doing has a bearing on every other creature in the Ecology.

This approach is said to be the third revolution in robotics, the first being the industrial robot while second being mobile robots & personal robots.

One of the earliest proponent of Ecology based robotics was Duchon (1994), his work was an extension of Gibson's pioneering work, 'Ecological Approach to Visual Perception'. Duchon points to some basic principles;

Because of their inseparability, the agent and the environment together are treated as a system
The agent's behaviour emerges out of the dynamics of this system
Based on the direct relationship between perception and action, the task of the agent is to map available information to the control parameters at its disposal to achieve a desired state of the system.
The environment provides enough information to make adaptive behaviour possible.
Because the agent is in the environment, the environment need not be in the agent. That is, no central model is needed, but this does leave room for task-specific memory and learning.

However, Duchon's works were limited to Visual Perception and also being a research in the 90s, it lacked the new age technologies which came to fore in the next two decades. More in tune with current day; Arkin addresses Ecology (viz. Ecological Psychology) throughout his works while Saffiotti and his team has developed control software, PEIS (Physically Embedded Intelligent Systems) to implement Ecology based robotics.

Fig.2 Laying of the 'PEIS floor', the floor is networked using RFID chips

Fig.3 The Pedagogy leading to an ubiquitous point of view, modified from the works of Saffiotti and Broxvall

Thus, to progress into the realm of 'i-robot', 'Rosey the Robot Maid' and R2D2; a pragmatic society in which robots and automation work in tandem to support the human civilisation - we probably need to route it via Ecological Approaches.

All philosophies have short comings; as a criticism to Ecology based robotics, it can never be realised for sufficiently large environments - all sensors will have a physical limitation of range - a central model of some sort will always be needed to bridge this gap between the pristine theory and the practical applications.

UPCOMING POSTS

2011-11-08T22:10:00.001+05:30

Six upcoming article I have planned for the blog for the next three month;

'3 generations - shakey, flakey and erratic' - A brief discussion on the Saphira Architecture which has been responsible for these three very special mobile robots.

'Uncanny indeed' - A discussion on the uncanny valley hypothesis by Masahiro Mori

'Ecology based robotics' - A peek into Ecology based robotics

'GSSP' - Tutorial and discussion on Graphical State Space Programming

'Behave !' - A study of contrast - on the various definitions of 'behaviour' in mobile robotics

ROS@HacDC - It may be fun to review HacDC Robotics Class 2011

________________

Any suggestions ? - If you think that there is any topic that may suit the theme of this blog, then please leave a message to this post.

MAPS FROM STAGE SIMULATIONS IN ROS : PART DEUX

2011-11-08T21:28:00.002+05:30

SLAM USING TELEOPERATION IN STAGEROS

In my previous article, I discussed realising SLAM using stage's wander controller. Now, I discuss about an alternative method where the robot can be driven around by human participation and thus realising SLAM.

Such can be done in ROS using stage/stageros and teleoperation.

#.1 - Start an instance of the master in a terminal window

roscore

#.2 - Start the stage/stageros simulation in a new terminal window

rosrun stage stageros /path/to/.world file 

This world file must not employ the wander controller. The idea is to drive the robot around not let it wander.

#.3 - Start keyboard based teleoperation

rosrun teleop_base teleop_base_keyboard base_controller/command:=cmd_vel 

 

#.4 - Start gmapping in a new terminal window

rosrun gmapping slam_gmapping scan:=base_scan

#.5 - Start map server in a new terminal window

rosrun map_server map_saver 

The map will get saved in the directory from where the command for map_server is issued as a pgm file.

Drive the robot around using u,i,k,l etc and check the map as it starts to develop. Drive it around a few times across the whole environment that should give a sufficiently good map.

The rxgraph for this simulation is as shown;

The pros and cons with the previous method can be seen in contrast;

NOTE : Simulations done in ROS 1.4.10 diamondback

MAPS FROM STAGE SIMULATIONS IN ROS

2011-10-30T13:38:00.000+05:30

SLAM USING STAGE'S WANDER CONTROLLER IN ROS

SLAM, Simultaneous Localisation and Mapping; using simulations in stage/stageros to map the environment based on sensor readings from a mobile robot in the 'wandering' mode may be done as follows;

#.1 - Start an instance of the master in a terminal window

roscore

#.2 - Start the stage/stageros simulation in a new terminal window

rosrun stage stageros /path/to/.world file 

The world file employs stage controller 'wander' hence the robot starts moving immediately and is in a wandering mode.  

#.3 - Start gmapping in a new terminal window

rosrun gmapping slam_gmapping scan:=base_scan

#.4 - Start map server in a new terminal window

rosrun map_server map_saver 

The map will get saved in the directory from where the command for map_server is issued as a pgm file.

Run the simulation sufficiently long enough for a good map. While the simulation is running, on running rxgraph in a new terminal window one may see the following graph for the ROS nodes.

SAMPLE OUTPUTS

#.1

#.2

#.3

NOTE : Simulations done in ROS 1.4.9 diamondback

REFERENCES
1) I thank Mac at ROS for his suggestions
2) This blogpost went to be motivation for a ROS tutorial - http://www.ros.org/wiki/stage/Tutorials/MakingMapsUsingStagesWanderController

ROS TUTORIAL, STAGE CONTROLLERS

2011-10-28T02:22:00.002+05:30

My first contribution to the ROS community, Tutorial on Introduction to Stage Controllers

Codes for the tutorial are available here

VOLKSBOT

2011-10-26T13:17:00.001+05:30

VOLKSBOT@PLAYER/STAGE

While browsing the web, I came across a very interesting model in player/stage, Volksbot. The sheer complication of the robot and its depiction in the stage model impressed me.

The model was designed for Stage 4.X.X, Brian was kind enough to send the model through to my email and I was able to modify it to suit Stage 3.X.X.

CODES

The codes for the simulation are available here

STAGE-ING THE COUP

2011-10-16T16:00:00.002+05:30

USING STAGE WITH A SINGLE WORLD FILE

Stage 3.0.0 onwards, there is facility of 'Stage Controllers' and simulations can be realised with a single world file (and an image file). Thus instead of using inc, cfg and world files, a single world file will suffice for most simulations. Information about the robot design, sensors, environment etc are all included in the world file.

As an example I try to get the default simulation in Player/Stage down to a single world file. Thus instead of using 6 scripts; simple.world, simple.cfg, map.inc, sick.inc and pioneer.inc, I use only one script simple-standalone.world.

On running the world file;

stage simple-standalone.world

and the well know window with the little red robot pops up ! .....

This simulation uses wander controller. One of the lopsides to this is that the C++ programs (and Python scripts) for robot motion planning and behaviour, i.e. laserobstacleavoid, sonarobstacleavoid cannot be used. However, stage behaves as autonomous - no coding - no player.

NOTE

Simulations done on Stage 3.2.2

CODES

Codes for the simulation can be found here

EVA

2011-09-26T19:59:00.003+05:30

EVA@PLAYER/STAGE

After some effort, I was able to put together an inc file in Player/Stage which resembled eva, walle's love interest.

CAPTURE BY A SWARM

2011-09-08T22:04:00.001+05:30

CAPTURE BY A SWARM

Flocking behaviour in Stage (3.2.2) can be realised by using 'pioneer_flocking' Stage controller. The default settings simulates 100 robots which exhibit swarm behaviour by forming flocks.

A interesting feature of a swarm is that it can 'capture' other robots in its path. The captured robots behave as a part of the swarm.

A DEMONSTRATION

1/3 - Initially there are 100 red robots and 3 yellow robots. On starting simulation the red robots start to move, triggered by sonars bouncing off the wall, while the yellow robots are stationary.

2/3 - The red swarm on reaching the yellow robots 'capture' them.

3/3 - The captured yellow robots behave as a part of the swarm.

CODES
Codes for the simulation are available here

REFERENCES

(1) Richard Vaughan, "Massively Multiple Robot Simulations in Stage"

USING GAZEBO

2011-09-04T14:19:00.000+05:30

GAZEBO

Gazebo is a part of the Player Project. It is a 3D simulator utilising ODE and OGRE. ROS has incorporated Gazebo into their distributions with some minor modification.

GAZEBO@ROS WITH WORLD FILES - A DETOUR FROM THE USUAL

Gazebo, while it is a part of Player Project is usually used with world files. However, ROS tutorials recommend using Gazebo with launch files - these launch file scripts identify the corresponding world file.

However in the spirit of Player/Stage/Gazebo it is possible to run Gazebo with world files from its executable, located at /opt/ros/diamondback/stacks/simulator_gazebo/gazebo/bin .

Thus using ./gazebo with pioneer2dx.world, which is a well known Player Project world file;

Start an instance of roscore - gazebo is built with slight modification, so an instance of master (roscore) is needed. The later scripts search for the master.
Navigate to the gazebo executables directory ( cd /opt/ros/diamondback/stacks/simulator_gazebo/gazebo/bin)
Start Gazebo with pioneer2dx.world file (./gazebo /path/to/pioneer2dx.world)
The following window should pop up,

Trying the rxgraph to check the ROS nodes at work;

Trying with pioneer2at.world file;

The same works for Stage, the executables at /opt/ros/diamondback/stacks/simulator_stage/stage/bin can be used in a similar manner. The executables, stage and stageros work same with a world file giving 2D simulations. However stage is the primitive Player Project executable and doesn't need a roscore master while stageros is more 'ROS like', needs roscore and works with ROS nodes.

NOTE

Tested on ROS 1.4.9 Diamondback (Gazebo 0.10.0 and Stage 3.2.2)
pioneer2dx.world and pioneer2at.world files can be found in Gazebo installation files (viz. gazebo-0.10.0/worlds)
An alternative is to use, roscore and rosrun gazebo gazebo /path/to/pioneer2dx.world file

REFERENCES

(1) I thank John Hsu for his help

(2) stage vs. stageros

(3) launch files for gazebo

(4) N.Koenig, A.Howard,"Design and Use Paradigms for Gazebo, An Open-Source Multi-Robot Simulator"

THE KHEPERA

2011-08-20T01:48:00.092+05:30

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

2011-08-14T13:06:00.006+05:30

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.

ROOMBA@ROS

Roomba also has a ROS package.

EMERGENT BEHAVIOUR - A DEMONSTRATION

2011-08-02T13:52:00.069+05:30

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

2011-07-31T20:31:00.005+05:30

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

2011-07-30T18:25:00.012+05:30

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/java3d-1_5_1-linux-i586.bin

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.

BEST BOOKS FOR MOBILE ROBOTICS

2011-06-04T14:25:00.023+05:30

BEST BOOKS FOR MOBILE ROBOTICS

An near exhaustive list of books for mobile robots.

1) Classics

a) Behavior-Based Robotics

b) Robot Motion Planning

c) Computational Principles of Mobile Robotics

d) Planning Algorithms

e) Probabilistic Robotics

2) For The Newbie

a) Introduction to Autonomous Mobile Robots

      b) Principles of Robot Motion: Theory, Algorithms, and Implementations
c) Introduction to Robotics: Analysis, Systems, Applications
      d) Introduction to Robotics: Mechanics and Control
e) Mobile Robotics: A Practical Introduction
      f) The Robotics Primer

3) Particular Topics

3.1) Behaviour Based Approaches

a) Robot Programming : A Practical Guide to Behavior-Based Robotics
b) Designing Autonomous Agents

3.2) Robot Vision

a) Learning OpenCV

3.3) Bio-inspired

      a) Bio-Inspired Artificial Intelligence: Theories, Methods, and Technologies
b) Flying Insects and Robots

3.4) Multiagent Systems/ Robot Societies
     a) Robot Colonies
     b) Swarm Robotics: SAB 2004 International Workshop
   c) Swarm Intelligence: From Natural to Artificial Systems

3.5) Fuzzy logic route to robots

     a) Fuzzy Logic Techniques for Autonomous Vehicle Navigation

3.6) Building Robots
     a) Arduino Cookbook
     b) Getting Started with Arduino

4) Related - but not really Mobile Robots

4.1) Robot Manipulator

a) Robotics: Control, Sensing, Vision, and Intelligence

4.2) AI related

a) The Society of Mind

4.3) Philosophical

a) Gödel, Escher, Bach: An Eternal Golden Braid

b) Metamagical Themas

Feel free to suggest any more ...... I will keep adding as I find them ..... !

HANDY COMMAND LINE FOR ROS

2011-01-22T12:00:00.041+05:30

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

DABBLING WITH THE I-BOT

2010-12-07T14:18:00.020+05:30

I-BOT@BIT RANCHI

At BIT, Ranchi there are 11 I-Bot Robot

These robots are made by triindia and build on a Philips 8051 microcontroller. However much to my annoyance, each robot is merely equipped with 2 light sensors and can only be used for very simple experiments (i.e. obstacle avoidance and line following).

The programming is done in C

These experiments are often included as a introductory robotics lab for Master of Engineering (ME) students.

2 CARTOONS

2010-11-01T09:46:00.013+05:30

2 CARTOONS

I came across 2 cartoons while documenting various different algorithms for mobile robot path planning. Both these cartoons makes an agile researcher of this field squint and follow it up with a smirk (or script a LOL !) .

The first one is from willowgarage .

While the second one is from Arkin's book .

Both these cartoons succinctly illustrate the issues in the 'apparently simple' philosophy of path planning.

MAPS AFTER VACATION

2010-08-19T13:59:00.021+05:30

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 & EVA - 2.0

2010-08-16T10:41:00.011+05:30

WALL-E & EVA - 2.0

If robots could have romantic mushy chit-chat, how would it be ? The idea is given a comical angle with a python script utilising the random module and the time module.

A script which gives output as the following,

and on other times as,

.... still other occasions,

Guess romance has its own odds !

Many thanks Luke, this mushy program works nice !

The Python script is available here.

WALL-E LOOKS FOR EVA

2010-07-24T12:06:00.014+05:30

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 ! :)

WALL-E

2010-07-05T09:12:00.016+05:30

WALL-E@PLAYER-STAGE

While going through the stage installations files, I found a walle include file at Stage-3.2.0-Source/worlds/walle.inc.

Marrying walle.inc file with the 'usual' simple.world, simple.cfg and sick.inc files I got wall-e to move around in the 'caves' environment !

Somehow this appealed to the child in me ! :)

The following video is by talk2aswin;

MULTIPLE SENSORS FOR A MOBILE ROBOT

2010-05-27T17:21:00.010+05:30

SUBSUMPTION ARCHITECTURE

In a seminal paper in AI which introduced a the paradigm of 'Subsumption Architecture', 'Robust Layered Control System for a Mobile Robot' by Rodney Brooks; Brooks argues that a mobile robot should be equipped with multiple sensors as that adds to the robustness of the control of the robot. The robot can respond efficiently to a dynamic environment thus the behaviours are apparently more 'smoother'.

To come up with examples to illustrate Brook's theory led me to this simple experiment in Player-Stage.

I. A robot with sonars, STUCK

II. Introducing lasers, VOILA it is unstuck and on its way

WHAT IS HAPPENING ?

Here the simulation starts off with a robot equipped with long-ranged sonars, the robot is stuck.

Introducing a short-ranged laser (SICK LASER) unstuck the robot.

Other solutions can be by modifying the code (sonarobstacleavoid.cc) or changing the geometry of the placement of the sonars. However, the idea of this demonstration is to illustrate the robustness gained by the use of two sensors.

REFERENCES

(1) R.A Brooks, "A Robust Layered Control System for a Mobile Robot"

(2) 6 Architectures

PLAYER STAGE: PLAYERV

2010-05-15T12:15:00.003+05:30

PLAYERV
playerv is a GUI tool in stage which enables to the field of view of the robot.

Playerv is to be used when player stage is operating, however a different terminal window has to be used.

PLAYER STAGE : HELLO WORLD

2010-05-03T16:37:00.004+05:30

Every programming paradigm has a 'Hello World' program. I try out something similar in Player-Stage and in process acquaint myself with various newer aspects of Player-Stage. After trying out player simple.cfg to check out Player-Stage installation, here I try to understand the involved working principles.

'HELLO WORLD'

Files needed to create the hello world (copied from Stage-3.2.0-Source/worlds and modified) are;
These 6 files contains information and configuration of the simulation.

1. cave.png

This file contains the 'picture' of the environment.

2. map.inc

This file contains a floor plan and is included (.inc file) in simple.world.

3. pioneer.inc

This file contains the information about the robot model, the geometry, wheels etc of the robot. This file is included in simple.world

4. sick.inc

This file contains SICK LMS 200 configurations, factory settings and geometry. This file is included in simple.world

5. simple.cfg

The configuration (.cfg) file tells the player that there is a driver called stage in stageplugin library. This file enables player to 'talk' to the driver.

For real robots the drivers are build into player, for a simulation the driver is always stage.

6. simple.world

It contains the environment details,

and also the robot coordinates and robot behaviour

The 'pose' is the robot coordinates (x,y,z) and the heading angle (also called yaw). 'wander' is the default behaviour (this is new plugin API to Stage, earlier versions did not have it).

Any robot (or autonomous vehicle) navigation can be defined completely by the 3 coordinates and the heading a angle.

ON RUNNING THE SIMULATION

Before the screen with the little red robot pops up, loads of command flashes across the terminal window.

2 important aspects ;

(a) wander the wander is the default behaviour, via the simple.world file. There are other Stage controllers which can be used to obtain other behaviours and informations.

(b) port 6665

port 6665 is the default port for Player and Stage.Player and Stage communicate through this port.

REFERENCES

(1) Player/Stage Manual
(2) Richard Vaughan. "Massively Multiple Robot Simulations in Stage"

SNAIL : MY FIRST ROBOT

2010-04-13T11:23:00.002+05:30

MY FIRST ROBOT

My first robot got made not due to a sense of creativity, but rather for securing good grades. SNAIL, my first robot was the first part of Group Design Project at King's College London and it got made in Nov-Dec 2007. It was a simple line follower which was made from LEGO Mindstorms RCX 1.0 & Robotics Invention System software.

Fig 1. SNAIL

SNAIL was not quiet the snail when it came to speed ! and could complete a square of 100 cm (25cm x 4) in 4-5 seconds.

Fig 2. SNAIL'S flowchart

It would be unfair not to mention my group and people who made it happen. Rest of my team mates were, Boubacar Barry (Abu), Aparajithan Sivanathan (Siva), Vasileios Lahanas (Vaz) and Preetanat Kewcharoenwong (Kang).

INSTALLING PLAYER-STAGE : WHAT WORKED FOR ME

2010-03-29T13:05:00.070+05:30

PLAYER-STAGE

Player-Stage or as it is now know, Player Project is a very versatile software for robot simulation and hardware control interface. It primarily uses FLTK and OpenGL.

After trying various means and hopelessly failing, I successfully installed Player-Stage in Ubuntu 9.04 (and much later also on Ubuntu 10.04 - scroll down for that).

The following is a succinct of my efforts.

INSTALLING PLAYER/STAGE IN UBUNTU 9.04 AND UBUNTU 10.04 LTS

The post primarily deals with installation in Ubuntu 9.04, for installation in Ubuntu 10.04 LTS scroll down, close to the end of this post.

THE INSTALLATION : IN 8 SIMPLE STEPS

#1.Update Ubuntu

A fresh installation of the OS (Ubuntu 9.04 ) is preferred.

Update Ubuntu 9.04 completely using sudo apt-get update and sudo apt-get upgrade. (Do not do a distribution update to Ubuntu 9.10 or higher)

#2.Install the dependencies

Dependencies for installation in Ubuntu 9.04;

sudo apt-get install autotools-dev build-essential cmake cpp libboost-signals1.35.0 libboost-signals1.35-dev libboost-thread1.35.0 libboost-thread1.35-dev libcv1 libcv-dev libgdk-pixbuf2 libgdk-pixbuf-dev libgnomecanvas2-0 libgnomecanvas2-dev libgsl0-dev libgtk2.0-dev libjpeg62-dev libtool libxmu-dev swig freeglut3 freeglut3-dev libfltk1.1 libfltk1.1-dev libltdl7 libltdl7-dev libpng12-0-dev libpng12-0

Make sure all these packages (or any alternative packages (hardly one or two) offered by Ubuntu 9.04 repositories, i.e. in case If libpng12-dev or any such package is not installed by apt-get, then install it manually) are installed. Run the above commands 2 to 3 times to confirm that these packages are indeed installed.

#3.Download the sources

Download Player-3.0.0 and Stage-3.2.0-Source and extract the files. Restart the computer for dependencies to come to effect.

#4.Configure and install player and stage in the $usr/local directory

Do not try to install Stage before installing Player. Stage installation script 'looks for' player installation

Installing Player

execute each of these commands (5 in total) one at a time in the same order as shown

cd player-3.0.0
mkdir build
cd build
cmake ../
make
sudo make install

Installing Stage

An Error in Stage files : Before installation, there is an error in Stage files that should be corrected, in the source code in the file Stage-3.2.0-Source/libstageplugin/p_driver.cc closer to the end of the file, Change the line : "world->Update();" to "Fl::wait();" . This error has been rectified in later versions of Stage (i.e. Stage-3.2.2 etc).

Now install, much like Player, execute each of these commands (4 in total) one at a time in the same order as shown.

cd Stage-3.2.0-Source
mkdir build
cd build
cmake ../
make
sudo make install

#5.Confirming the installation

#6.Setting the 'PATH'

In the 'home' folder enable 'show hidden files' and locate the .bashrc file.

At the end of the .bashrc file append the following.

PATH=$PATH:/usr/local/bin
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig

export PATH
export LD_LIBRARY_PATH
export PKG_CONFIG_PATH

Then run the command source ~/.bashrc from the terminal, restart the computer

#7. Check !

In the Stage installation files

cd Stage-3.2.0-Source/worlds

Start the simulation with, player simple.cfg

If the following screen with a little red robot, pops up then everything is set up nicely !

#8. Check for compilation

In Player installation files, cd player-3.0.0/examples/libplayerc++

compilation command for sonarobstacleavoid.cc

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

If it compiles without any errors then all is good ! .....

SMORGASBORD FOR PLAYER-STAGE

(i) 2.5 Dimension

To see your robot do a 2.5 Dimension, press 'R' (Perspective Camera) while the 2 Dimensional simulation is on !

(ii) Command line check for version

Simple command lines, to confirm the versions of Player and Stage;

(iii) robot-player from ubuntu repositories

In Ubuntu 9.10, one can install robot-player (sudo apt-get install robot-player) from the repositories, however I faced compilation issues with it.

(iv) Working with a virtual OS

If you are working in a virtual box virtual machine then there may be issues in controlling the robot hardware as hardware layer abstraction is not fully supported. However, simulation in stage is fine.

If you are working on Virtual Box then do Install Guest Additions (This will help to maximise the screen and seamlessly integrate the guest OS with host OS).

(v) 'flickering' in Stage

If Stage starts to flicker too much, then put the 'Visual Effects' in Ubuntu 9.04 to None.

(vi) Recording a video of the simulation

If required, the simulation may be recorded as a video using tools as Record MyDesktop MEncoder. and then converting to to avi using

(vii) Mailing list and support

As Player-Stage newbie, one may consider joining the official mailing list and/or the facebook page.

(viii) Any other success story ?

This installation also works with Player-3.0.1 and Stage-3.2.0.

I recently tried an overwrite of the player with the latest svn, revision 8767 (3.1.0-svn) and that worked.

However, do not try an overwrite of Stage.

(ix) Gazebo installation

I have got a few enquiries about Gazebo ! .... and here is my response !

I could not install Gazebo, few attempts with version 0.10.0 conflicted with my Stage installation.

I installed ROS in order to work with Gazebo (version 0.9.0). ROS is a another Robotics suite and it uses Stage, Gazebo and a host of other softwares. However the working and command structure are much different from Player-Stage.

ROS is a way to use Gazebo without the hassles of bindings etc. A word of advice, ROS recommends Ubuntu 9.10 for installation. So this installation (recommended for Ubuntu 9.04) of Player-Stage may not work in tandem with ROS.

In Ubuntu 10.04, ROS may be installable side by side with Player/Stage without any issues of conflict etc.

For more on ROS and Gazebo - see my article on using gazebo.

(x) New drivers

For the adventurous coders, who plans to design new player drivers; have a look at these tutorials,

#. Player wiki

#. Tutorial at Pennsylvania State University

#. Tutorial at University of Copenhagen

#. Tutorial at Aalborg University

(xi) New home for the project at github

The project has found a new home at github. Stage 4.0.0 was released on 26 November 2010.

Stage 4.X.X has back compatibility issues with Stage 3.X.X. Have a look at, Moving from Stage 3 to Stage 4: laser and ranger .

(xii) Installation on Ubuntu 10.04 LTS

I was able to install Player-3.02 and Stage-3.2.2 on Ubuntu 10.04 LTS, I used the following tutorials;

#. Tutorial 1 - in German

#. Tutorial 2 - more suited to Ubuntu 10.10, but some tips well apply to Ubuntu 10.04

#. Tutorial 3

Dependencies for installation in Ubuntu 10.04;

sudo apt-get install autotools-dev build-essential cmake cpp libboost-python1.40.0 libboost-python1.40-dev libboost-thread-dev libboost-signals1.40.0 libboost-signals1.40-dev libcv4 libcv-dev libgdk-pixbuf2-ruby libhighgui-dev libgnomecanvas2-0 libgnomecanvas2-dev libgsl0ldbl libgsl0-dev libjpeg62-dev libtool libxmu-dev swig freeglut3 freeglut3-dev libfltk1.1 libfltk1.1-dev libgtk2.0-dev libltdl7 libltdl7-dev libpng12-0 libpng12-dev libcvaux4 libcvaux-dev libltdl-dev libguile-ltdl-1 fluid glutg3-dev freeglut3 freeglut3-dev libart-2.0-2 libatk1.0-0 libboost-thread1.40.0 libboost-thread1.40-dev libc6 libcairo2 libcv4 libcv-dev libcvaux4 libfontconfig1 libfreetype6 libgcc1 libgl1-mesa-glx libglib2.0-0 libglu1-mesa libglu1 libgnomecanvas2-0 libgsl0ldbl libgsl0-dev libgtk2.0-0 libhighgui4 libjpeg62 libjpeg62-dev liblodo0 libltdl7 libpango1.0-0 libplayerc++2 libplayerc2 libplayercore2 libplayerdrivers2 libplayererror2 libplayertcp2 libplayerxdr2 libpmap0 libstdc++6 zlib1g libxmu-dev

(xiii) Any issues !

If there is any issues with the installation in Ubuntu 9.04 or Ubuntu 10.04 then please leave me a message and I will try to sort it out.

If anyone has installed Player-Stage / Player-Stage-Gazebo in any other OS (Windows, Mac, SUSE, Fedora etc) then please do inform me - I would be happy to add your reference below.

REFERENCES
(1) Aalborg University Wiki
(2) Aalborg University Script
(3) Player-Project
(4) Standard UNIX installations
(5) Player-Stage, openSUSE installation
(6) Jennifer Owen's page
(7) i-phone player/stage
(8) Mac (10.6.2) installation
(9) Playing with Player Project
(10) github page
(11) Ubuntu 10.10 installation
(12) Ubuntu 11.04 installation
(13) Ubuntu 11.10 installation