Lazy Simulation Method

Recall from the section ?? the two standard approaches to simulation: discrete event simulation and continuous simulation. Continuous simulations apply to various dynamic systems. We are concerned with discrete actions and state changes occuring in the environment, thus we employ descrete event simulation. However, we make use a combination of next-event time advance with emulation of the controller (which follows the CPU clock, i.e. is a kind of fixed-increment time advance). The simulated controller generates events at discrete time units on the granularity of the CPU clock frequency of the simulating computer (for example, start the motor A, determine the value of sensor 1), but its environment is updated “continuously”, i.e. at any time the event occurs (an event can occur also for other reasons than due to an

action of the robot controller). Thus events in the environment can occur at an arbitrary time and place. Typical events include robot running against an obstacle, or over some pattern drawn on the floor, scheduled light switching, or robot entering monitored area of the environment.

Our lazy simulation approach (inspired by lazy evaluation in functional program- ming languages) updates the state of the simulated system only when the robot controller interacts with the robot hardware. At that time instant, we suspend the emulated program, compute the current exact state of the simulated system (environment and robot) by mathematical formulas, and determine the outcome of the interaction that triggered the update. The temporal granularity is thus limited only by the CPU or bus frequency of the simulating machine. The emulated program is not interpreted by the simulator. It runs almost independently within the operating system of the simulating computer, see Figure 2.10. Instead of accessing the robot hardware, it accesses the simulator that is waiting in the background. For example, the robot controller program might be computing without interacting with the robot hardware for some time, during which the robot crosses several lines on the floor, triggers switching of the light by entering an active area, passes below a light, and bounces to a wall, where it remains blocked for a while. At that point in time, the robot controller wants to read a value of its light sensor, for instance, and only at that point in time the simulator becomes active and computes the whole sequence of the previous events that occurred, and the current location and situation of the robot and the environment. Finally, the required value of the sensor reading is determined and returned to the program, which resumes its execution. To achieve better performance, the simulator pre-computes expected events before resuming the simulated program. The pre-computed information helps to test quickly whether the state of the robot or environment has changed since the last “interrupt”, without processing all the data structures of the simulator. We call this approach lazy simulation because it uses maximum possible abstraction from the environment and performs simulation computation only when very necessary.

None of the existing robot simulators satisfied our needs. We chose to implement our own simulator in language C, now available as open-source project [URL - Eval]. The simulator is designed to cope with any program written in LegOS (later renamed to BrickOS) system, which controls an experimental robot with a compatible topology (Figure 7.1, 8.4 right). This allows us to use it both with our controller architecture, and with virtually any C-program that can control the robot. Small modifications would allow simulating robots with different topologies.

There are several issues related to simulation. First of all, many researchers pointed out that simulating robotic systems accurately is almost impossible. Each sensor and motor part has somewhat different characteristics, and the outcome of each sensory or motor action depends on imperfect interactions with the real world. In order to achieve a comparable performance of the simulated and real robotic system, noise has to be applied both to sensory readings, and motor actions. In addition, the outcome of the motor action is hard to compute and it appears to be more feasible to measure it and construct a table of basic motor actions and their outcomes as proposed by Miglino et.al. [Miglino et al., 1995]. Figure 8.4 left shows a

7.1 Simulation Framework 159

light sensors: one pointing upwards (in the centre) one pointing downwards (in the front)

two wheels with differential drive "cylindrical" shape

bumper in the front high−lifting fork in the back

top view side view

front back

front

back

Figure 7.1: Simulated robot topology and features.

camera setup in the computer vision laboratory in Maersk institute in Odense that we used to measure the outcome of basic robotic actions in real-world. These values can be used to setup the simulator.

Another important issue is the execution speed of the simulated controller. By default, the controller runs at a real-time speed (1-to-1 ratio). Even though the CPU speed of the simulating hardware is higher than the CPU speed of RCX, the resulting behavior is compatible, since the modules of the controller are typically spending their time waiting for some event to occur to change their state in response. Obviously, the running speed on a fast simulating hardware can be increased. However, after some threshold, further speedup is impossible even though the CPU utilization remains about 0.0%. This threshold is reached when the frequency of events exceeds the response frequency of the controller. For instance, when the robot is crossing a line drawn on the floor, one of the modules must detect the line in order to turn the robot and make it follow the line. Once the controller misses the line, because the thread of the line follower module does not always get a time slice between the time the robot enters and leaves the line, the simulation speedup is too high – albeit the controller still spends most of the time waiting for some event, and keeping CPU utilization very low, i.e. the bottleneck is the size of the time-slice the OS scheduler is assigning to the threads and the time OS needs to switch between threads2_{. Even though the accuracy of the simulator was somewhat}

compromised due to different CPU and OS architectures between the HW of the real robotic system and the simulating computer, and some of the delay constants used in the controller had to be adjusted for different speed-up ratios, we find the simulator accuracy satisfiable. This is due to the fact that all behaviors in our controller are event-based: events trigger changes of the internal state or actions. Thus if the ratio (measured in simulation) between the emulation speed of the robot controller and the simulation speed of the environment is higher than the ratio between the real robot CPU and the real speed of the environment, the simulation is still accurate. More precisely, if the emulated program runs speedupemu-times

2

Here it is interesting to note that upgrading from the old LinuxThreads to new pthreads library (NPTL) and utilizing the round-robin real-time scheduling in superuser mode allowed a speedup of more than one order of magnitude (100-500-times faster than real-time as contrasted to 10-times faster with older LinuxThreads).

faster than on a real robot, and the simulated time is speedupsim-times faster, then

if speedupemu > speedupsim, the simulation is accurate. When we reach a simulation

speed when these ratios are about equal, we reach accurate timing, and the limit of how much the simulation can be speeded up. However, the simulated time can flow even faster, as many times as the real robot program can be slowed down while robot still performing the task successfully. If the simulated system would be more sensitive to correct timing of events, the emulation approach could not be used and the behavior of the controller with respect to its computational speed compared to the speed of environment would have to be simulated! This is an important issue when simulating any computer system performing in the real world. In order to simulate the real world environment, its time has to be simulated with respect to the CPU time of the computer system that is simulated. This applies to most ER experiments. Another issue with emulation in a multitasking OS (we used GNU Linux) is that the tasks are interrupted at any time by the scheduler. We minimized this disturbance by using the real-time scheduling mode. Even more precise simulations could be achieved using a real-time operating system, although it would make it even more difficult to run the simulations in a distributed cluster.