Embedded Robotics (Thomas Braunl, 2 ed, 2006)

13 Simulation Systems

Figure 13.3: Generated camera images

use a standard Gaussian distribution for fault values added to sensor readings or actuator positions. From the user interface, error percentages can be selected for each sensor/actuator. Error values are added to distance measurement sensors (infrared, encoders) or the robot’s [x, y] coordinates and orientation.

Simulated communication errors include also the partial or complete loss or corruption of a robot-to-robot data transmission.

For the generated camera images, some standard image noise methods have been implemented, which correspond to typical image transmission errors and dropouts (Figure 13.4):

•Salt-and-pepper noise

a percentage of random black and white pixels is inserted.

•100s&1000s noise

a percentage of random colored pixels is inserted.

•Gaussian noise

a percentage of pixels are changed by a zero mean random process.

Figure 13.4: Camera image, salt-and-pepper, 100s&1000s, Gaussian noise

176

Multiple Robot Simulation

13.3 Multiple Robot Simulation

177

13 Simulation Systems

13.4 EyeSim Application

The sample application in Program 13.1 lets a robot drive straight until it comes too close to an obstacle. It will then stop, back up, and turn by a random angle, before it continues driving in a straight line again. Each robot is equipped with three PSD sensors (infrared distance sensors). All three sensors plus the stall function of each robot are being monitored. Figure 13.5 shows simulation experiments with six robots driving concurrently.

Program 13.1: Random drive

1#include "eyebot.h"

2#include <stdlib.h>

3#include <math.h>

4#define SAFETY 300

6int main ()

7{ PSDHandle front, left, right;

10

11LCDPrintf("Random Drive\n\n");

12LCDMenu("", "", "", "END");

13vw=VWInit(VW_DRIVE,1);

14VWStartControl(vw, 7.0,0.3,10.0,0.1);

15front = PSDInit(PSD_FRONT);

16left = PSDInit(PSD_LEFT);

17right = PSDInit(PSD_RIGHT);

18PSDStart(front | left | right , TRUE);

20while(KEYRead() != KEY4)

21{ if ( PSDGet(left) >SAFETY && PSDGet(front)>SAFETY

22&& PSDGet(right)>SAFETY && !VWStalled(vw) )

24else

25{ LCDPutString("back up, ");

26VWDriveStraight(vw,-0.04,0.3);

27VWDriveWait(vw);

30VWDriveTurn(vw, dir, 0.6);

31VWDriveWait(vw);

32}

33OSWait(10);

34}

35VWRelease(vw);

36return 0;

37}

178

EyeSim Environment and Parameter Files

Figure 13.5: Random drive of six robots

13.5 EyeSim Environment and Parameter Files

All environments are modeled by 2D line segments and can be loaded from text files. Possible formats are either the world format used in the Saphira robot operating system [Konolige 2001] or the maze format developed by Bräunl following the widely used “Micro Mouse Contest” notation [Bräunl 1999].

179

13 Simulation Systems

World format The environment in world format is described by a text file. It specifies walls as straight line segments by their start and end points with dimensions in millimeters. An implicit stack allows the specification of a substructure in local coordinates, without having to translate and rotate line segments. Comments are allowed following a semicolon until the end of a line.

The world format starts by specifying the total world size in mm, for example:

width 4680 height 3240

Wall segments are specified as 2D lines [x1,y1, x2,y2], so four integers are required for each line, for example:

;rectangle 0 0 0 1440 0 0 2880 0

0 1440 2880 1440

2880 0 2880 1440

Through an implicit stack, local poses (position and orientation) can be set. This allows an easier description of an object in object coordinates, which may be offset and rotated in world coordinates. To do so, the definition of an object (a collection of line segments) is enclosed within a push and pop statement, which may be nested. Push requires the pose parameters [x, y, phi], while pop does not have any parameters. For example:

;two lines translated to [100,100] and rotated by 45 deg. push 100 100 45

The starting position and orientation of a robot may be specified by its pose [x, y, M], for example:

position 180 1260 -90

Maze format The maze format is a very simple input format for environments with orthogonal walls only, such as the Micro Mouse competitions. We wanted the simulator to be able to read typical natural graphics ASCII maze representations, which are available from the web, like the one below.

Each wall is specified by single characters within a line. A “_” (at odd positions in a line, 1, 3, 5, ..) denotes a wall segment in the y-direction, a “B” (at even positions in a line, 2, 4, 6, ..) is a wall segment in the x-direction. So, each line contains in fact the horizontal walls of its coordinate and the vertical wall segments of the line above it.

180

EyeSim Environment and Parameter Files

_________________

|S|_____|_______|_|

The example below defines a rectangle with two dividing walls:

The following shows the same example in a slightly different notation, which avoids gaps in horizontal lines (in the ASCII representation) and therefore looks nicer:

_____

| _| |_|___|

Extra characters may be added to a maze to indicate starting positions of one or multiple robots. Upper-case characters assume a wall below the character, while lower-case letters do not. The letters U (or S), D, L, R may be used in the maze to indicate a robot’s start position and orientation: up (equal to start), down, left, or right. In the last line of the maze file, the size of a wall segment can be specified in mm (default value 360mm) as a single integer number.

A ball can be inserted by using the symbol “o”, a box can be inserted with the symbol “x”. The robots can then interact with the ball or box by pushing or kicking it (see Figure 13.6).

|_____________________________________________________| 100

181

182

EyeSim Environment and Parameter Files

Program 13.2: EyeSim parameter file “.sim”

4# robot description file

5robi S4.robi DriveDemo.dll

Program 13.3: Robot parameter file “.robi” for S4 soccer robot

1# the name of the robi

2name S4

3

4# robot diameter in mm

5diameter 186

16# psd sensor definition: (id-number from "hdt_sem.h")

17# "psd", name, id, relative position to robi center(x,y,z)

18# in mm, angle in x-y plane in deg

23# color camera sensor definition:

24# "camera", relative position to robi center (x,y,z),

25# pan-tilt-angle (pan, tilt), max image resolution

28# wheel diameter [mm], max. rotational velocity [deg/s],

29# encoder ticks/rev., wheel-base distance [mm]

32# motors and encoders for low level drive routines

33# Diff.-drive: left motor, l. enc, right motor, r. enc

183

13 Simulation Systems

Each robot type is described by two files: the “.robi” parameter file, which contains all parameters of a robot relevant to the simulation, and the default Milkshape “.ms3d” graphics file, which contains the robot visualization as a colored 3D model (see next section). With this distinction, we can have a number of physically identical robots with different shapes or color representation in the simulation visualization. Program 13.3 shows an example of a typical “.robi” file, which contains:

•Robot type name

•Physical size

•Maximum speed and rotational speed

•Default visualization file (may be changed in “.sim” file)

•PSD sensor placement

•Digital camera placement and camera resolution in pixels

•Wheel velocity and dimension

•Drive system to enable low-level (motoror wheel-level) driving, supported drive systems are DIFFERENTIAL_DRIVE, ACKERMANN_

DRIVE, and OMNI_DRIVE

With the help of the robot parameter file, we can run the same simulation with different robot sensor settings. For example, we can change the sensor mounting positions in the parameter file and find the optimal solution for a given problem by repeated simulation runs.

13.6 SubSim Simulation System

SubSim is a simulation system for Autonomous Underwater Vehicles (AUVs) and therefore requires a full 3D physics simulation engine. The simulation software is designed to address a broad variety of users with different needs, such as the structure of the user interface, levels of abstraction, and the complexity of physics and sensor models. As a result, the most important design goal for the software is to produce a simulation tool that is as extensible and flexible as possible. The entire system was designed with a plug-in based architecture. Entire components, such as the end-user API, the user interface and the physics simulation library can be exchanged to accommodate the users’ needs. This allows the user to easily extend the simulation system by adding custom plug-ins written in any language supporting dynamic libraries, such as standard C or C++.

The simulation system provides a software developer kit (SDK) that contains the framework for plug-in development, and tools for designing and visualizing the submarine. The software packages used to create the simulator include:

•wxWidgets [wxWidgets 2006] (formerly wxWindows)

A mature and comprehensive open source cross platform C++ GUI framework. This package was selected as it greatly simplifies the task

184

SubSim Simulation System

185