Robot Eksperimentarium: Tips ERSP Player

From ImageWiki

Jump to: navigation, search

Contents

Q: What are the differences between maximum IR ranges

A: The IR sensors on Scorpion robots have a range of 80 centimeter. When nothing is in range, ERSP will report the IR range as Inf, in Stage the range will be 0.80, and using the ERSP Player driver the range will be 1.60. The latter value was chosen to make it easier to distinguish in-range values from out-of-range values.

Discussion: The latter "threshold" should probably be changed to match that of Stage.

Q: How well has the Scorpion robot been modeled in Stage

A: The Stage model of the Scorpion robots have been made as accurate as possible. There are, however, some limitations that have been derived from the Stage simulation environment. Some features of the robots cannot be simulated; this includes the bumpers. Some parts of the model has been simplified, such as the definition of the robot's bounding box, since the added accuracy has little benefit on the result (The robot could more accurately have been described as a pentagon instead of the square). The IR range sensors have all been modeled according to the positions listed in the specs for the robot.

Q: What are the differences between the units used by ERSP and Player

A: ERSP uses cm as the main length unit and radian as the main unit for angles. Player uses meters and radians. In both systems, it is, however, possible to change the units read from the sensors.

From the Player on writing configuration files:

For convenience, the user may specify lengths and angles in the configuration using different units. By default, lengths are assumed to be given in meters, with angles in degrees. The units can be changed using the global (i.e., not inside a driver section) options unit_length and unit_angle; e.g.:

   unit_length "cm" # Change length units to centimeters
   unit_angle  "radians" # Change angle units to radians

These options should be added to the player/scorpion.cfg and stage/cave/cave.cfg files or whatever configuration files you are using.

Check the ERSP manual for more information about configuring ERSP to different units.

Q: What do I need to do to have IR sensors available in Stage

A: When implementation of the driver was initiated, Stage did not support simulation of IR interfaces. To make programs written for the Scorpion robots run with as few changes as possible in Stage a special driver called sonar2ir has been created. To use it simply compile the driver files (make driver-all) and the driver will be loaded by default when starting Stage via the Makefile.

As the name suggests, the sonar2ir driver simply maps the sonar interface supported by Stage to an IR interface. This is possible, because the underlying model used by Stage for simulating sonar fits that of IR very well.

Q: Why do I get old data when reading from sensors (IR and odometry)

A: The Player server samples the sensors with a fixed time interval, the data is then send to the client where it is buffered until you read it. Your robot control program is not reading the buffered sensor input fast enough and you may also experience a buffer overflow leading to lost sensor data.

There are two ways to solve this problem: Either you make your control loop faster so that you read sensor data faster, or you change the Player servers sampling rate.

You can change the sampling rate in the Player ERSP driver file driver/ersp/ersp.cfg by changing the value of the parameter sensor_interval. This sets the time between samples measured in miliseconds. Increase this value to get fewer samples.

Below you see a cut-out of the driver/ersp/ersp.cfg file:

 driver
 (
        name "ersp"
        plugin "libersp"
        provides [ "position2d:0" "bumper:::bumper:0" "ir:::bumper:1"  "ir:0" "power:0"]
        acceleration 0.2
        angular_acceleration 1.57
        sensor_interval 100
 )

Q: Can I use ResetOdometry?

No, ResetOdometry is not currently implemented in the erspplayerdriver. This means that you cannot count on being able to reset the odometry measurements to zero and you have to use odometry relative to a previous measurement. You could write your own odometry state handler, keeping track of how far the robot has driven and turned using the relative measurements from the robot.

Personal tools