Good to hear about your interest. Your robot sounds interesting; what sort
is it? Homemade?
On Sat, 4 Oct 2003, Dafydd Walters wrote:
> The twelve sonars are each fired sequentially, 25ms apart, so a full scan
> takes 300ms. When queried by the host, the microcontroller in the sonar
> array module reports the exact time of the most recent reading for any
> given sonar, along with that sonar's ping time. The sonar module also has
> a single power control to put all the sonars "to sleep" to conserve power
> when the host is not interested in sensor readings.
> The two problems I have in trying to come up with an implementation that
> fits in the with the sonar interface are timing and geometry.
> The timing dilemma:
> Each and every sonar reading has a timestamp associated with it, and yet
> if I use the sonar interface to report the readings of the whole array in
> one packet, I can only have one sensor timestamp associated with all
That's an interesting point. The Pioneer 2 has a similar situation: the
sonars are pinged 4 at a time, and you get 4 readings per microcontroller
cycle, which runs at 10Hz. With 16 sonars, it takes 400ms to get
readings from all the transducers, but each Player sonar data packet
contains the latest reading from each transducer, all of them stamped
with time at which the last four (who knows which ones?) were gathered.
I don't see any elegant solution to this problem right off. Then again,
I'm not certain as to whether it needs to be solved. I don't work on
estimation problems, so I don't care terribly as to exactly when my
sonar readings came in. For those of you who work on such problems,
what do you think? Is this issue significant enough that we need to
think about more sophisticated/fine-grained timestamp mechanisms?
> I proposed to implement the sonar capability as three interfaces: two
> sonar interfaces, and a bumper interface.
> One of the sonar interfaces will be for the ring of eight conventional
> outward-facing fixed sonars. The sensor timestamp will be the time of the
> first of the eight sensor readings, and it will be assumed that either the
> client doesn't care too much about the timing, or the client knows the
> firing sequence, and will therefore be able to deduce the times of the
> other seven readings. The advantage of keeping this interface separate is
> that since it is "conventional", it can be used by clients and algorithms
> that make assumptions about fixed geometry.
Sounds good, modulo timestamping issues mentioned above.
> The second sonar interface will be for the single "head mounted" sonar.
> PLAYER_SONAR_GET_GEOM_REQ will just return dummy data, and it will be up
> to the client to know which way the sonar was facing by querying the ptz
> interface. Only clients that know how to use the data from this special
> sensor will use this interface.
Alternatively, maybe we can expand an existing interface to deal with
this situtation. For instance, the 'blobfinder' interface includes a
'range' field for each blob, presumably to handle stereo blobfinding rigs.
Depending on what you're doing with your PTZ unit, maybe we could work
up some specialized solution. Or maybe the 'ptz' interface could also
contain a range reading; how general would that be?
> The driver will respond to PLAYER_SONAR_POWER_REQ requests on the two
> interfaces as follows: Power is initally assumed to be Off. The driver
> will internally maintain a "virtual state" of the power status (on or off)
> for each of the two sonar interfaces from the client's viewpoint. If the
> power is On for either one of the interfaces, the sonar array will be
> powered up. Only if the power is Off for both interfaces, will be sonar
> array be powered down.
Don't worry about this one. We can easily implement a single underlying
driver, to which the other drivers subscribe; power (and any other
configurations ) will be handled appropriately. There are currently at
least two existing models of how to do this (e.g., p2os and segwayrmp),
and then a third model that I think is best, but hasn't yet been
implemented. We can discuss this in more detail.
> The three downward facing, precipice-detecting sonars that detect floor
> discontinuities will look like bump sensors to the client. In other words,
> if the driver detects that the robot is about to "drive over a cliff", it
> reports that it has bumped into something. Of course, if the sonar array
> is powered down (see above), the bump sensors will not be able to report
Is that all that you want to do with those sensors? That is, are the
range readings really only useful in binary? If so, good thinking,
great idea. If not, then we need another solution so as to not
under-utilize your robot.