Subject:
|
Re: Autonomous Robot
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Mon, 7 Aug 2000 06:22:50 GMT
|
Viewed:
|
1572 times
|
| |
|
|
"Steve Baker" <lego-robotics@crynwr.com> wrote:
> 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.
You're right. Some specific behaviour might improve the chances to
understand the situation. For example, to perform a 360° turn in place while
reading the sensor.
> 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.
Very interesting approach. Didn't know SG and Sun mouses worked that way.
> 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.
That's actually the solution Giulio Ferrari, Marco Beri and I used for our
tic-tac-toe robot showed last year at the Mindfest! A Lego train light brick
connected to a motor, used to lighten the board (with short bursts) and get
more consistend readings: http://www.geocities.com/~marioferrari/ttt.html
It works, but Lego lamps require a time not too short to provide maximum
light. Probably some LEDs would work better.
> 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.
For my experience odometry is very reliable on short distances. During my
experiments I estimated the error was inside 2 to 5 parts every thousand,
that means 1 to 2.5cm every 5m. Actual error depends not only on the
distance travelled but on the number of turns performed.
> 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.
Your thoughts are very interesting and filled with good ideas. Probably
you're right and the bar-code approach is better than the two tape colors
approach. But re-thinking the whole thing more doubts come to my mind.
What mainly affect odometry is the estimate of the direction (heading). If
we don't find a way to reset heading to a true value, the robot will rapidly
accumulate heading errors and odometry will lead to totally wrong
predictions. The point is I don't see any way bar-coded or colored tapes can
help us in detecting the true heading. You said line-following is an easy
task, and we can read bar codes in the while, but line-following always
requires some direction adjustments, and I fear these are large enough to
make the heading estimate too wrong for reliable navigation.
Ciao
Mario
|
|
Message is in Reply To:
 | | Re: Autonomous Robot
|
| (...) 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 (...) (25 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
|
|
|
|
