Файл: Embedded Robotics (Thomas Braunl, 2 ed, 2006).pdf

13

SIM parameter file

Simulation Systems

Figure 13.6: Ball simulation

A number of parameter files are used for the EyeSim simulator, which determine simulation parameters, physical robot description, and robot sensor layout, as well as the simulation environment and graphical representation:

•myfile.sim

Main simulation description file, contains links to environment and robot application binary.

•myfile.c (or .cpp) and myfile.dll

Robot application source file and compiled binary as dynamic link library (DLL).

The following parameter files can be supplied by the application programmer, but do not have to be. A number of environment, as well as robot description and graphics files are available as a library:

•myenvironment.maz or myenvironment.wld

Environment file in maze or world format (see Section 13.5).

•myrobot.robi

Robot description file, physical dimensions, location of sensors, etc.

•myrobot.ms3d

Milkshape graphics description file for 3D robot shape (graphics representation only).

Program 13.2 shows an example for a “.sim” file. It specifies which environment file (here: “maze1.maz”) and which robot description file (here: S4.robi”) are being used.

The robot’s starting position and orientation may be specified in the “robi” line as optional parameters. This is required for environments that do not specify a robot starting position. E.g.:

robi S4.robi DriveDemo.dll 400 400 90

ROBI parameter file

There is a clear distinction between robot and simulation parameters, which is expressed by using different parameter files. This split allows the use of different robots with different physical dimensions and equipped with different sensors in the same simulation.

Physics simulation

Application programmer interface

of cross platform interface development. It also offers straightforward plug-in management and threading libraries.

•TinyXML [tinyxml 2006]

This XML parser was chosen because it is simple to use and small enough to distribute with the simulation.

•Newton Game Dynamics Engine [Newton 2006]

The physics simulation library is exchangeable and can be selected by the user. However, the Newton system, a fast and deterministic physics solver, is SubSim’s default physics engine.

The underlying low-level physics simulation library is responsible for calculating the position, orientation, forces, torques and velocities of all bodies and joints in the simulation. Since the low-level physics simulation library performs most of the physics calculations, the higher-level physics abstraction layer (PAL) is only required to simulate motors and sensors. The PAL allows custom plug-ins to be incorporated to the existing library, allowing custom sensor and motor models to replace, or supplement the existing implementations.

The simulation system implements two separate application programmer interfaces (APIs). The low-level API is the internal API, which is exposed to developers so that they can encapsulate the functionality of their own controller API. The high-level API is the RoBIOS API (see Appendix B.5), a user friendly API that mirrors the functionality present on the EyeBot controller used in both the Mako and USAL submarines.

The internal API consists of only five functions:

SSID InitDevice(char *device_name);

SSERROR QueryDevice (SSID device, void *data);

SSERROR SetData(SSID device, void *data);

SSERROR GetData(SSID device, void *data);

SSERROR GetTime(SSTIME time);

The function InitDevice initializes the device given by its name and stores it in the internal registry. It returns a unique handle that can be used to further reference the device (e.g. sensors, motors). QueryDevice stores the state of the device in the provided data structure and returns an error if the execution failed. GetTime returns a time stamp holding the execution time of the submarine’s program in ms. In case of failure an error code is returned.

The functions that are actually manipulating the sensors and actuators and therefore affect the interaction of the submarine with its environment are either the GetData or SetData function. While the first one retrieves the data (e.g. sensor readings) the latter one changes the internal state of a device by passing control and/or information data to the device. Both functions return appropriate error codes if the operation fails.

Sensor models

Environments

Error models

The PAL already simulates a number of sensors. Each sensor can be coupled with an error model to allow the user to simulate a sensor that returns data similar to the accuracy of the physical equipment they are trying to simulate. Many of the position and orientation sensors can be directly modeled from the data available from the lower level physics library. Every sensor is attached to a body that represents a physical component of an AUV.

The simulated inclinometer sensor calculates its orientation from the orientation of the body that it is attached to, relative to the inclinometers own initial orientation. Similarly, the simulated gyroscope calculates its orientation from the attached body’s angular velocity and its own axis of rotation. The velocimeter calculates the velocity in a given direction from its orientation axis and the velocity information from the attached body.

Contact sensors are simulated by querying the collision detection routines of the low-level physics library for the positions where collisions occurred. If the collisions queried occur within the domain of the contact sensors, then these collisions are recorded.

Distance measuring sensors, such as echo-sounders and Position Sensitive Devices (PSDs) are simulated by traditional ray casting techniques, provided the low level physics library supports the necessary data structures.

A realistic synthetic camera image is being generated by the simulation system as well. With this, user application programs can use image processing for navigating the simulated AUV. Camera user interface and implementation are similar to the EyeSim mobile robot simulation system.

Detailed modeling of the environment is necessary to recreate the complex tasks facing the simulated AUV. Dynamic conditions force the AUV to continually adjust its behavior. E.g. introducing (ocean) currents causes the submarine to permanently adapt its position, poor lighting and visibility decreases image quality and eventually adds noise to PSD and vision sensors. The terrain is an essential part of the environment as it defines the universe the simulation takes part in as well as physical obstacles the AUV may encounter.

Like all the other components of the simulation system, error models are provided as plug-in extensions. All models either apply characteristic, random, or statistically chosen noise to sensor readings or the actuators’ control signals. We can distinguish two different types of errors: Global errors and local errors. Global errors, such as voltage gain, affect all connected devices. Local errors only affect a certain device at a certain time. In general, local errors can be data dropouts, malfunctions or device specific errors that occur when the device constraints are violated. For example, the camera can be affected by a number of errors such as detector, Gaussian, and salt-and-pepper noise. Voltage gains (either constant or time dependent) can interfere with motor controls as well as sensor readings.

Also to be considered are any peculiarities of the simulated medium, e.g. refraction due to glass/water transitions and condensation due to temperature differences on optical instruments inside the hull.