An o-pi Pioneer sensor library

Bindings for a fair bit of a vanilla Pioneer3

Making sense of sensors

The Pioneer3 has a number of sensors available; while Player/Stage provides a way to access them directly, we have wrapped t hem up, as well as provided a number of processes to manage the data flowing out from those sensors. In particular, we've tried to provide some common, useful functions you might want to perform on the different sensors available.

The laser rangefinder

The LMS200 (or SICK, as we like to call it) laser rangefinder has a range of 8 meters; in the library, we've converted this to an integer value from 0 to 800cm (therefore, limiting the resolution of the laser to 1cm). We've tried to anticipate a few w ays you might want to use this data. Note that the laser data is indexed from 0 (leftmost) to 180 (rightmost).

The ultrasonic rangefinders

The Pioneer has a number of ultrasonic rangefinders arrayed around the chassis. There are six in the front and back, and two on each of the sides. We have provided accessors for each of these sides. They have a range of 5m, which we scale to a value f rom 0 to 500, meaning we force them to a maximum resolution of 1cm. They are far less precise than the LMS200, although tend to behave perfectly in our virtual machine.

As the sonar functions all mirror the laser functions, we will not describe them in detail. Valid constants for side include sonar.front (0), sonar.left (2), sonar.right (3), and sonar.back (1).

If you wish to access the sonars individually, you can write code like:

INT the.value:
SONAR array:
SEQ
  in ? array
  the.value := array[3]

Assuming you had an incoming channel of type SONAR called in, this would read the rangefinder data into a variable called array, and then assign the value of the third ultrasound rangefinder to the variable the.value.

<p>The sonar on the Pioneer, as provided by Player (and therefore our library) is indexed as diagrammed below:

sonar-indexing_1.png

Misc. Utilities

Coming soon...

How to use the blobfinder (once we implement it), the power sensor (ibid), and anything else we can provide a sane wrapper f or.