ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 13.06.2025
Просмотров: 4225
Скачиваний: 0
13 Simulation Systems
Figure 13.2: EyeSim interface
robot or even different models for different robots in the same simulation. However, these graphics object descriptions are for display purposes only. The geometric simulation model of a robot is always a cylinder.
Simulation execution can be halted via a “Pause” button and robots can be relocated or turned by a menu function. All parameter settings, including error levels, can be set via menu selections. All active robots are listed at the right of the robot environment window. Robots are assigned unique id-numbers and can run different programs.
Sensor–actuator Each robot of the EyeBot family is typically equipped with a number of modeling actuators:
•DC driving motors with differential steering
•Camera panning motor
•Object manipulation motor (“kicker”)
and sensors:
•Shaft encoders
•Tactile bumpers
•Infrared proximity sensors
•Infrared distance measurement sensors
•Digital grayscale or color camera
The real robot’s RoBIOS operating system provides library routines for all of these sensor types. For the EyeSim simulator, we selected a high-level subset to work with.
174
EyeSim Simulation System
Driving interfaces
Simulation of tactile sensors
Simulation of infrared sensors
Synthetic camera images
Error models
Identical to the RoBIOS operating system, two driving interfaces at different abstraction levels have been implemented:
•High-level linear and rotational velocity interface (vZ)
This interface provides simple driving commands for user programs without the need for specifying individual motor speeds. In addition, this simplifies the simulation process and speeds up execution.
•Low-level motor interface
EyeSim does not include a full physics engine, so it is not possible to place motors at arbitrary positions on a robot. However, the following three main drive mechanisms have been implemented and can be specified in the robot’s parameter file. Direct motor commands can then be given during the simulation.
•Differential drive
•Ackermann drive
•Mecanum wheel drive
All robots’ positions and orientations are updated by a periodic process according to their last driving commands and respective current velocities.
Tactile sensors are simulated by computing intersections between the robot (modeled as a cylinder) and any obstacle in the environment (modeled as line segments) or another robot. Bump sensors can be configured as a certain sector range around the robot. That way several bumpers can be used to determine the contact position. The VWStalled function of the driving interface can also be used to detect a collision, causing the robot’s wheels to stall.
The robot uses two different kinds of infrared sensors. One is a binary sensor (Proxy) which is activated if the distance to an obstacle is below a certain threshold, the other is a position sensitive device (PSD), which returns the distance value to the nearest obstacle. Sensors can be freely positioned and orientated around a robot as specified in the robot parameter file. This allows testing and comparing the performance of different sensor placements. For the simulation process, the distance between each infrared sensor at its current position and orientation toward the nearest obstacle is determined.
The simulation system generates artificially rendered camera images from each robot’s point of view. All robot and environment data is re-modeled in the object-oriented format required by the OpenInventor library and passed to the image generator of the Coin3D library [Coin3D 2006]. This allows testing, debugging, and optimizing programs for groups of robots including vision. EyeSim allows the generation of individual scene views for each of the simulated robots, while each robot receives its own camera image (Figure 13.3) and can use it for subsequent image processing tasks as in [Leclercq, Bräunl, 2001].
The simulator includes different error models, which allow to either run a simulation in a “perfect world” or to set an error rate in actuators, sensors, or communication for a more realistic simulation. This can be used for testing a robot application program’s robustness against sensor noise. The error models
175
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
Avoid global variables
A multi-robot simulation can be initiated by specifying several robots in the parameter file. Concurrency occurs at three levels:
•Each robot may contain several threads for local concurrent processing.
•Several robots interact concurrently in the same simulation environment.
•System updates of all robots’ positions and velocities are executed asynchronously in parallel with simulation display and user input.
Individual threads for each robot are created at run-time. Posix threads and semaphores are used for synchronization of the robots, with each robot receiving a unique id-number upon creation of its thread.
In a real robot scenario, each robot interacts with all other robots in two ways. Firstly, by moving around and thereby changing the environment it is part of. Secondly, by using its radio communication device to send messages to other robots. Both of these methods are also simulated in the EyeSim system.
Since the environment is defined in 2D, each line represents an obstacle of unspecified height. Each of the robot’s distance sensors measures the free space to the nearest obstacle in its orientation and then returns an appropriate signal value. This does not necessarily mean that a sensor will return the physically correct distance value. For example, the infrared sensors only work within a certain range. If a distance is above or below this range, the sensor will return out-of-bounds values and the same behavior has been modeled for the simulation.
Whenever several robots interact in an environment, their respective threads are executed concurrently. All robot position changes (through driving) are made by calling a library function and will so update the common environment. All subsequent sensor readings are also library calls, which now take into account the updated robot positions (for example a robot is detected as an obstacle by another robot’s sensor). Collisions between two robots or a robot and an obstacle are detected and reported on the console, while the robots involved are stopped.
Since we used the more efficient thread model to implement multiple robots as opposed to separate processes, this restricts the use of global (and static) variables. Global variables can be used when simulating a single robot; however, they can cause problems with multiple robots, i.e. only a single copy exists and will be accessible to threads from different robots. Therefore, whenever possible, global and static variables should be avoided.
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;
8 |
VWHandle |
vw; |
9 |
float |
dir; |
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) )
23 |
VWDriveStraight(vw, 0.5, 0.3); |
24else
25{ LCDPutString("back up, ");
26VWDriveStraight(vw,-0.04,0.3);
27VWDriveWait(vw);
28 |
LCDPutString("turn\n"); |
/* |
random |
angle */ |
|
29 |
dir = M_PI * (drand48() |
- 0.5); /* |
-90 .. |
+90 |
*/ |
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
0 |
0 |
200 |
0 |
0 |
0 |
200 |
200 |
pop |
|||
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).
| |
_____________________________________________________ |
| |
||
| |
r |
l |
| |
|
| |
| |
|||
| |
| |
|||
_| |
r |
l |
|_ |
|
| |
| |
|||
| |
r |
o |
l |
| |
| |
| |
|||
| |
r |
l |
| |
|
|_ |
_| |
|||
| |
| |
|||
| |
r |
l |
| |
|
| |
| |
|||
| |
| |
|||
|_____________________________________________________| 100
181