|
DPRG: stereo sonar
Subject: DPRG: stereo sonar
From: David Philip Anderson
dpa at io.isem.smu.edu
Date: Mon Sep 21 15:16:01 CDT 1998
Howdy DPRG!
Matt Minnis writes:
> David,
>
> Could you explain your stereo sonar ranging system and how you are using it?
>
> I would be very interested to hear how you are doing this.
>
> Thanks,
>
> Matt Minnis
The Polaroid sonar units seem pretty popular among robot builders, and there
appear to be lots of different configurations and methods for using them. I
bought a couple a few years ago and have tried several different arrangements,
they are always "under construction" in some sense.
The method I'm now using is really quite simple and takes advantage of the
fact that the sonar beams are quite narrow, on the order of about 15 degrees
in the center (robust) part of the dispersion. The two Polaroid transducers
are mounted in the center of the front bumper about 4 inches from the
floor and about .75 inches left and right of the center line, like this:
+--------------------------------------+
| |
| ___ ___ |
| / \ / \ |
| | | | | |
| \ / \ / |
| --- --- |
| |
| |
| |
+--------------------------------------+
They are angled away from each other about 7.5 degrees, like this: (as viewed
>from the top of the bumper)
+-------------<\-------/>--------------+ |
+--------------\>-----</---------------+ V
/ | \ front
/ | \
/ | \
/ | \
/ o | o \
/ 7.5 | 7.5 \
(the angle is exaggerated here)
These are mounted in three-point ring mounts with springs and nylon
screws threaded into the bumper, so the actual angles can be adjusted
experimentally, both in azimuth and elevation. Using a standard shoe box
as a target, as well as an aluminum coke can, the beams were adjusted so that
the "inner" edge of the two beams were co-incident. This gives a total beam
spread of about 60 inches at a distance of 8 feet, each beam covering about
31 inches, with 1 inch of overlap.
The two sonar units are pinged alternately, the time-of-flight is measured in
milliseconds, and the distance is calculated in inches and printed on the
robot's LCD. I used a propagation speed of 1100 feet/sec, and then tweaked
that by actual measurements against a tape measure in my garage (Denton, Tx,
about 600 feet above sea level, on a hot and dry 1998 summer day). An offset
is added so that the returned measurements are calculated from the center of
the robot, rather than from the front bumper. This simplifies navigation.
Once the calculations were satisfactory, the calibration method was to use
the 1 foot square tiles on my work room floor for alignment. The robot was
pointed down the seam of the tiles eight feet from the wall, and checked
that the LCD values read 96 inches. Then the target shoe box or coke can was
slowly pushed into the inner and outer edge of the beam until the distance
registered on the LCD. At that point the distance from the edge of the target
to the center line was recorded. This was repeated at 1 foot intervals,
moving away from the 'bot. Using these data I adjusted the ring mount screws
until the two sonars gave symmetrical coverage with minimum overlap.
Now what? The normal navigation mode of the robot running under sonar control
is to turn toward whichever side returns the longer measurement, as long as
the difference between them is larger some percentage of their total. The
robot also turns more sharply as the detections get closer, in a geometric
fashion, so that it reacts mildly to objects 20 feet away, but aggressively
to objects 4 feet away. It also slows down as the objects get closer. It
does not turn away from objects that are detected by both sonars, unless they
are very close ( < 30 inches). In this case, it slows its forward speed to
zero, and can ONLY rotate around its center until one or both sonars are
greater that 30 inches.
How can this behavior be exploited to find and acquire a coke can target for
the DPRG Robofest contest? Remembering that coke cans are the only objects
within the contest walls, the task becomes, "How to differentiate a coke can
>from a wall?" The answer has two parts. First, as the 'bot rotates and scans
along a wall, the difference in distance between the two sonar will have a
constant relationship defined by the angle between the two sonar and the
angle between the robot and the wall. More simply put, the walls will always
be detected by both sonars, while the cans can only be seen by one at a time.
Second, if the navigation algorithm is reversed so that the robot rotates
toward the shorter rather than the longer measurement, it will home in on the
can in a waggling fashion, as the can is detected by first one sonar and then
the other.
wall -----------------------------------
. .
. .
Short . . Long
. .
\ . .
\ .
bot \
\
SDZ = a_tweakable_constant
DIF = Long - Short
PERCENT = (Long + Short) / SDZ
if (DIF > PERCENT) can_detect = TRUE; else can_detect = FALSE;
wall -----------------------------------
.
.
CAN .
. .
\ . .
\ .
bot \
\
In the case in which the robot is parallel with and very close to the wall,
it is possible to get a false can detect, because the nearer sonar will
read a very close distance and the other will see far down the wall. When
this happens the robot will rotate toward the "can," that is, toward the
wall, the far sonar will get a closer reading, the difference between the
two will decrease, and the false detection will go away.
Their is one pathological case in the DPRG contest, which is a "T" shaped
course and therefore has two outside corners. If the robot approaches these
at just the proper angle, it can fall within the can detection range and
attempt to acquire (and grab!) the corner. The robot uses its four IR
detectors to do navigation and collision avoidance when the sonar are in
can-seeking mode, and this behavior is normally suppressed when a target
is active. The solution arrived at for the outside corner false can detection
is to activate the forward IR during the seeking process if the sonar begins
to return a lot of common detects, which happens for corners but not for cans.
I got this to work quite robustly while running around my work room and my
office, but it failed in the actual contest, at this point I'm not sure why.
After locating, grasping, and returning to the starting area with 4 of the
6 cans, the robot zeroed in on the far outside corner and attempted to grasp
it. After a couple of tries it touched the wall with its bumper and the
collision recovery mechanism was activated, the robot maneuvered away from
the corner, and the other two cans were found and retrieved without incident.
I would add at this point that the sonars, by the nature of the reflected
sound energy that they utilize, get a lot of false readings. These seem to
be caused by multi-path reflections off walls and floors, and can be
easily demonstrated by slowly rotating the robot and watching the LCD readings.
In practice, this has not been a problem, and I have for the most part just
ignored it. Because the navigation algorithm depends on many detections
to steer the robot toward a target, and the false readings are usually random
and singular, they can be thought of as a background "noise" that is swamped
by the S/N ratio of the "real" signals, the walls and cans.
hope this is useful!
cheers,
dpa
------------------------------
More information about the DPRG mailing list
|
