Subject:
|
Re: Autonomous Robot
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Sun, 6 Aug 2000 17:17:25 GMT
|
Original-From:
|
Steve Baker <sjbaker1@airmail.*stopspammers*net>
|
Reply-To:
|
sjbaker1@airmail.netSTOPSPAM
|
Viewed:
|
951 times
|
| |
|
|
Mario Ferrari wrote:
>
> "Mauro Vianna" <mauro_vianna@hotmail.com> wrote:
> > > > Although the idea of vertical and horizontal lines seens good, I still
> > > > didn't figure out a good algoritm to deal with that. The light sensor
> > > > measures a mean light reflection. That means that if it over the edge of a
> > > > black light and a white paper, the reading could be the same as the one from
> > > > a gray line. I confess I still didn't try that. Sometimes you must see the
> > > > robot working to figure out a solution...
> > >
> > > You could measure transitions instead of single values. Sampling some reads
> > > at a specified time interval should help you to recognize the situation.
> It's true that when you're on the border of the tape your light sensor reads
> an average value, but if you continue in the same direction you will finally
> get into the middle of the tape and supposing the tape is large enough you
> will read the pure tape color (reflection intensity). So what you have to do
> is keep reading until you pass the maximum (minimum) value and store the
> latter to decode the tape.
Hmmm - but if the robot was driving nearly parallel to a white tape, then
hit the boundary (thus getting a prolonged mid-grey value) and then drifted
off just enough to get back over dark floor - then the input to the sensor
could exactly mimic the return from a grey stripe. What's worse is that
this would happen when the robot is heading in a direction when you'd
expect to be crossing grey tapes.
What's more, what happens at intersections of two tapes? If the tape is
wide (compared to the area the sensor can detect) then whichever tape
lies on top of the other could produce a constant reading as you cross
the intersection.
These kinds of tricks have been used in the old style optical mouse
technology you used to see on Silicon Graphics and Sun workstations.
They used a special mouse pad with embedded grid lines - but they always
had TWO LED/detector pairs, one of which used red light and the other
infra-red. I guess they tuned the reflectivity of the lines such that
each light would only produce a strong reflection from one of the two
sets of lines. Certainly if you covered up one of the LED's underneath
the mouse, your cursor would only move in one direction.
So, I wonder if you could use one photodetector - but TWO light sources
(say Red and Green LED's) - then have one set of red tape and one set of
green. The green tape should produce poor reflections under red light -
and hence appear much like the dark floor - the red tape however would
produce bright reflections under red light and also appear nearly black
under green light. At the intersections of the red and green tapes,
you'd want a yellow spot that both detectors would respond to.
In RCX terms, you could perhaps wire the red light in parallel with
one motor and the green with another and use short bursts of light
(too short to move the motors much) to sample the output. That
way, you could retain a single RCX solution without wasting outputs.
Lego lighting kits have coloured lenses to put over the white lights
- that might be good enough to give you two-coloured illumination
in a "pure Lego" solution.
Well, that may be a lot of hassle - and Mario's approach may work
"well enough" under practical circumstances where it's only used
to correct the results of odometry.
However, I think I'd be inclined to place some artificial landmarks
on the floor - bar codes perhaps. Every once in a while, use the
odometry to drive the robot to where a bar code *should* be found,
then execute a simple search pattern to find the bar code - then
once you are over the top of it, reset your odometers to the new,
exact known value.
You could probably devise one kind of "landmark" to fix position
accurately and another kind to fix direction.
Since we seem to have line-following down pat (building a robot
to follow the line on the track that comes with the Mindstorms
kit is the first thing I built - and it's a REALLY easy problem),
how about making some radial 'starburst' patterns of tape like this:
\ | /
___\|/___
/|\
/ | \
With a bar-code at the outside end of each tape. I understand
that people have written NQC code to read bar codes.
When the robot sees a white tape, it executes a simple line
following algorithm - looking out for a bar code.
So long as the odometry is accurate enough to position the robot
on any point on the star pattern, you'll end up oriented along
whichever line you hit.
Eventually - you'll hit the barcode at the end of one of the tapes
which can contain your exact X/Y position and the heading of the
line you just drove down to reach that barcode. Now your robot
knows exactly where it is and can use odometry to go back to
its main job of work.
You'd need to know how accurate your odometry is - what is your
worst case error after (say) a minute of doing real work - and
just make sure that the star pattern is large enough that you
can find it - even with worst-case odometry.
There would be a trade-off between the amount of odometry error
you are prepared to accumulate - versus the size of the
landmarks and the amount of travel time to find a landmark and
orient yourself on it.
Since I don't yet own any rotation sensors, I don't have a feel
for the precision of odometry - so I can't guess where those
trade-offs lie. If odometry is REALLY poor or the robot is
expected to do very precise things - then it might spend more
time doing odometry-correction than doing real work...at which
point, this mechanism breaks down.
In a large space, you could place many of these landmarks and
have the robot know where to look for them so that it can
go towards the nearest one...that would cut down on the travel
time.
If you want to have REALLY sloppy odometry - or perhaps just
rely on dead reckoning without odometry - then I have another
plan...
Another approach would be to trail winding lines of tape all
over the floor in a "space-filling curve" pattern (there are
some 'fractal snowflake' patterns that would be appropriate
for this).
Place barcodes at (say) 1 meter intervals along the winding
line of tape.
Whenever the robot feels the need to reset it's odometry, it
just drives in any old direction until it hits tape - then
executes a simple line follower until it hits a bar-code -
and once again, that bar code can contain precise heading
and location information.
eg: . .
.... ...... _
. .....|| ||| |||.... . _
. . . . _
..... . . _
... . . .
. .......... . .
. . . .
...||| || |||....... ..| ||| |.. .
. .
. .
(The bar codes would be smaller and further apart compared
to the curvature of the tapes in practice).
CONCLUSION:
If the "rules of the game" allow artificial landmarks such
as tape laid on the floor then I think this is a solvable
problem without resorting to recognising the brightness
of two different tapes.
--
Steve Baker HomeEmail: <sjbaker1@airmail.net>
WorkEmail: <sjbaker@link.com>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
|
|
Message has 1 Reply:
 | | Re: Autonomous Robot
|
| (...) still (...) of a (...) one from (...) see the (...) reads (...) situation. (...) reads (...) finally (...) you (...) to do (...) drifted (...) You're right. Some specific behaviour might improve the chances to understand the situation. For (...) (24 years ago, 7-Aug-00, to lugnet.robotics)
|
Message is in Reply To:
| | Re: Autonomous Robot
|
| (...) still (...) of (...) one (...) It's true that when you're on the border of the tape your light sensor reads an average value, but if you continue in the same direction you will finally get into the middle of the tape and supposing the tape is (...) (24 years ago, 6-Aug-00, to lugnet.robotics)
|
37 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
