MULTIPLE SENSORS FOR A MOBILE ROBOT

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'.

Fig.1 Control schematics for multiple sensors, from Brooks

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.

Obviously, 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

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

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"