Functional Requirements for the Simulator

In order to have a tool for experimenting with interesting tasks, we formulated the requirements for our simulator as follows:

• The simulator should update the location, heading and speed of one robot in compliance with the robot morphology shown in Figure 7.1. The morphology allows for different movement types, see Figure 7.5 for details.

The robot will be navigating in a rectangular area with movable rectangular objects (obstacles). The robot’s bumper sensor will indicate when robot pushes forward against an obstacle;

• It should be possible to define:

– marks on the floor of various shades of gray in the shape of lines of certain width or rectangles (or polygons), the robot’s bottom light sensor readings will depend on the marks;

– top-mounted light sources of various intensity, the robot’s top light sensor readings will depend on the accumulated light amount in the current position of the robot;

– cargo loading locations (loading stations), which are automated service points, which detect the robot on arrival and notify the robot by sending an IR message. The robot should respond with a navigation maneuver consisting of 1) turning, 2) setting the lifting fork down, 3) approaching the station thus moving the fork under the cargo, 4) lifting the fork with the cargo, and 5) leaving the station. See Figure 7.3 for an illustration. Loading stations are specified with the help of scripts and active locations (see below). In real setup (as described below), the conveyer belt, the loading and unloading stations are operated by a separate RCX unit that also sends the ‘welcome to (un)loading station’ IR messages to the robot after it has been detected by a photo cell sensor. This RCX unit is connected through the IR link also with a PC controlling the lamps through X10 modules.

– cargo unloading locations (unloading stations), another type of automated service points, which also notify the robot on arrival. The robot should

7.1 Simulation Framework 163

respond with 1) turning, 2) approaching the station, 3) moving the lifting fork with cargo down, and 4) leaving the station as it delivered the cargo it was carrying. See Figure 7.4 for an illustration. Unloading stations are specified with the help of scripts and active locations (see below).

• During the run, the simulator keeps and updates the values of several system registers: f ork state (up or down), f ork position (exact vertical position of the fork), carrying cargo (YES, NO, PUSHING, UNLOADING1, UNLOAD- ING2)2_{, and other 224 user registers.}

• The lights, loading and unloading stations can be dynamically controlled during the simulation by:

– timers – generating periodical or one-time events;

– active locations – which are rectangular areas that trigger an event on robot entry. They can be activated either one time only, or on each exclusive entry3_{. Activation of the active locations can be constrained by}

requiring certain value in one of the registers.

Both kinds of events can trigger a script consisting of a sequence of commands. The allowed commands are:

– turn a light on or off,

– reinitialize an active area (so that it can be activated again), – send an IR message,

– set the current register

– write a value to the current register

The scripts are used to model the loading and unloading stations, see Fig- ure 7.3, and Figure 7.4, and can be used to model other dynamic features of the environment. See the Appendix B for an example of a file that specifies a simulation run.

• The simulator computes and stores the trajectory of the robot (it can be used for replay of the simulation and logging).

• As the simulator can be used to compute the fitness, it should measure and update variables for the evolutionary objective function.

• The simulator should stop simulation after certain timeout or on another terminating condition (such as when the progress is unpromising).

2

When robot is pushing a cargo and moves forward (i.e. away from cargo), it looses it. The state UNLOADING1 changes to UNLOADING2 when the fork is moved down, and the register is updated accordingly to the robot and fork movements with expected interpretations of YES, NO, and PUSHING.

3

By exclusive entry we mean that the robot must leave the area completely and enter it again. In addition, it is possible to specify a minimum time period between two activations.

active area − activated when a) robot enters the area

b) the heading of the robot is towards the station (with some tolerance)

c) robot is not carrying cargo

and it triggers a script that sends message to the robot cargo ready

to be loaded

b) robot heading is away from the station

and it triggers a script that sets the carrying cargo to PUSHING c) fork is down and in the bottom third of its range

more cargo waiting on the conveyer belt

active area − activated when a) robot enters the area

d) robot is not carrying cargo

Figure 7.3: Loading station is specified using two active areas (top view).

cargo unloading location 000 000 000 000 000 000 000 000 000 000 000 000 000 111 111 111 111 111 111 111 111 111 111 111 111 111

active area − activated when a) robot enters the area

b) robot heading is towards the station c) fork is up (in upper two thirds of its range) d) robot is carrying cargo

and it triggers a script that sends an IR message to the robot

active area − activated when a) robot enters the area

b) robot heading is away from the station c) robot is carrying cargo

and it triggers a script that sets the register carrying_cargo to UNLOADING1

active area − activated when a) robot enters the area

b) robot heading is away from the station c) fork is down(in the bottom third)

d) carrying_cargo register contains value UNLOADING2 walls 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1

7.1 Simulation Framework 165