To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.roboticsOpen lugnet.robotics in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / 12053
12052  |  12054
Subject: 
Re: Autonomous Robot
Newsgroups: 
lugnet.robotics
Date: 
Wed, 9 Aug 2000 20:23:02 GMT
Viewed: 
778 times
  
in article 398F84B6.F9AE89A8@airmail.net, Steve Baker at
lego-robotics@crynwr.com wrote on 8/7/00 8:55 PM:

Doug Weathers wrote:

It would be nifty if you could detect bar codes without needing to follow a
line.  My initial thought was to make "bull's-eye barcodes" that put the
codes in concentric rings.  No matter which direction you approach one of
these targets you get the same code - as long as you pass straight through
the center.

The problem then becomes: suppose you don't go straight through the center
of the target? You'll get strange results as you pass through part of the
bar code.

Yes - that's where I started thinking.  It seemed to me that if the circle
was large enough, odometry would put you inside the circle - then driving
out of the circle in any direction would get you to cross all the bar codes.

Of course, if odometry puts you inside the circle, you don't need bar codes
because you already know where you are!


Presuming you use the RELATIVE sizes of the bars in the code as 1's and 0's
and not absolute sizes, you should be fairly immune to crossing the circle
at funny angles...so long as you started *roughly* in the center of the
circle and drove out in *roughly* a straight line.

However, it was at that point that I thought of following radial lines that
would lead you do the barcodes fairly unambiguously - and heading in about
the right direction to read them cleanly.

True, and I agree with you - it would probably work.  However, it's too much
like a railroad train to be terribly interesting to me.  The "train tracks"
are the lines drawn on the floor, and the robot can't leave them.


So my next idea is to put down an array of spots, perhaps in a hex pattern,
that will give a fairly constant pattern of light/dark no matter which angle
you travel through it.  The surface of the Logitech TrackMan Marble has such
a pattern on it.  You'd watch the sensor for a bunch of light/dark
transitions in a short period of time.  If you got them you'd know you are
on the target.  You could use different reflective values (colors) of the
spots to tell different landmarks apart.  You don't know what direction
you're facing, though.

But the detection of different brightnesses is the problem we started with.
A bright white spot will appear to be a darker grey spot if you drive
across the edge of it in just the wrong way.  The light detector is
sampling an area from the floor - and averaging the colour in that area.
No matter what you do, driving across the edge of a 'WHITE' spot/line/whatever
will look exactly like crossing a 'GREY' spot/line/whatever.

True.  Forget about using colors, then, and just look for a rapid modulation
of the light sensor to tell you that you're on a landmark.  All the
landmarks would be indistinguishable to the sensor, but odometry should tell
us which landmark we're on.


That's why I suggested using different colours - and different colour
illumination
sources...in principal, that's a better solution.

You could use a rotating color filter wheel in front of the light sensor to
give the effect of having lots of different sensors.  The Clementine lunar
mission used this trick for its multispectral imager to get pictures of the
lunar surface in 11 different colors, which gave us info about what the
rocks are made of.


I had another idea - which was to somehow use polarisation.

If you had a reflective spot on the floor - covered with one lens from a
cheap pair of polaroid sunglasses - then put the other lens under the light
source (or detector) on the robot - then you'd only get a bright reflection
when you were driving such that the two planes of polarization were parallel!

This would (theoretically) get you barcodes that could only be read when
heading
in the right direction (er - or completely 180 degrees in the wrong direction
- damn!)

That could be handled by careful bar code design.  Say, all bar codes start
with 1 1 and end with 0 0.  If your robot sees an initial 0 0 it knows it's
going backwards over the bar code.


I also wondered whether the compass that comes with some of the lego pirate
ships
could be used...if you could focus a photodetector onto it, you might be able
to steer such as to minimise the change in brightness of the detector and
hence
drive reliably in a straight line.

Yikes!  What an interesting idea!  Too bad I don't have one of those
compasses.


That might be insanely difficult with a lego compass - but a non-lego one
should be made easy to read.

Especially those hiking compasses with transparent cases.  Put a light
underneath and detect when the compass needle interrupts the beam.

Makes you glad we are doing this with Lego
and not an Erector Set - no metal to interfere with the compass!

We will still have to watch for interference from the magnets and magnetic
fields of the motors.  Plus vibration from the motion of the robot.


So my next next idea is to have a spot of the floor "feel" different from
the rest.  You could trail two wire feelers until they both touch a piece of
tinfoil and complete a circuit, triggering a touch sensor port.  If this
sensor is at the center of rotation of your robot, you could then spin in
place until you detect a mark or a bar code.  Now you know your location AND
your orientation.  If you don't want to use non-Lego feelers, you could
always drill a hole in the floor :) and have a fifth wheel sense when it
drops into the depression.

Hmmm...or make a 'bump' by dropping a large lego baseplate on the floor and
build a small pyramid for the wheel to ride up over.  That would be a pure
lego solution - and not entail destruction of your home!

By using a rotation sensor and a linear-motion-to-rotation conversion you
could
theoretically measure the height of the bump you just drove over and decode
different heights with a single RCX input.  In practice though I think you'd
have the same problem as with the optical detector.  Driving over the edge of
a BIG bump would look the same as driving exactly over the middle of a small
bump.

When you start looking for this kind of solution, there are *lots* of ways to
do
it.  How about using the Lego magnet to pull down on metal objects embedded in
the floor to activate a switch?

If you taped some of those thin fridge magnets to the floor, then you could
have
two kinds of landmark - North-poles-up and South-poles-up.  One attracts the
magnet on the robot - the other repels it...which can activate one of two
switches I guess.

If you're thinking of those flexible magnets, they don't seem to have
defined north-south poles.  They're actually more like a bunch of very
narrow bar magnets laid down next to each other with the poles alternating.
Try sticking two of them together and then sliding them past each other -
they "ratchet" past each other in a most instructive way.


Alternatively you could use a second light
sensor looking down for the shiny tinfoil.

Nope - the same argument applies as for a white spot.  If you clip the
edge of the shiney spot, the reflection will be (say) half as much and it'll
look like your regular white spot.

You know, I'm not too sure about this.  If the sensor is mounted very close
to the floor, and you pay attention to how fast the value climbs, you should
be able to tell the difference between very bright and slightly bright.

Even so, the chance of an ambiguous reading must be vanishingly small.
Could it be neglected?  The robot would have to just "graze" the target so
the sensor never ends up completely over the target.  If the targets are
reasonably large, the ratio of ambiguous target edge to unambiguous target
area gets pretty small.

If you can't accept an occasional error, try this.  Make the targets two or
three inches in diameter.  Watch the sensor value as you move.  When you hit
a target, the sensor should rise and then settle on a value within a short
distance.  If it rises and then drops right away, you grazed the target and
should back up, turn, and try it again.  Supposedly, you're doing this to
recalibrate your odometer anyway, so you're executing a search pattern.
Keep it up until you get an unambiguous reading.

Going back to the original idea of a grid of horizontal black stripes and
vertical white stripes against a medium floor, the problem was intersections
and what happens there.  You could avoid the whole problem by never having
the tapes intersect.  Have them stop before they touch each other, with
enough separation that the sensor never has both black and white in view at
the same time.

Now it's just barely possible that the robot might be travelling exactly
along a line connecting the empty intersections and so will never see the
lines.  That's easy to fix - if the robot hasn't seen a line in a while,
have it turn.


I guess you could have a light source that you can turn on and off from the
RCX (in parallel with one of the motors to save an output) - and have one
kind of spot that's reflective and another that shines by it's own light
(luminous tape?) - then if you can see light with your own lamp turned off,
it's a luminous dot - but if you can only see it with your light turned on
then it's a simple reflective dot.

That's quite sneaky - I like it.  You probably don't need it to be luminous
- the light sensor has a light on it already.  The two different readings
(while moving with two light sources, and while stopped with one light
source) might be enough to let you distinguish more colors.


Big Huge Disclaimer: I haven't tried ANY of this stuff out yet.  It's much
faster to think up ideas than it is to test them.

Yes - *very* true.

Besides I'm currently
working on a legged robot, and it's hard enough without worrying about
navigation!

I guess that's the kind of design that you have to take
one step at a time <giggle>

Ow!

--
Doug Weathers, http://www.rdrop.com/~dougw
Portland, Oregon, USA
Don't spam me - I know how to use http://www.spamcop.net
"On a clear disk you can seek forever"



Message has 1 Reply:
  Re: Autonomous Robot
 
(...) No - the idea is that the odometry only has to be accurate enough to get you ANYWHERE within (say) a 1 foot radius circle. Then you drive away and read whichever section of the barcode you happen to cross on the way out - which tells you your (...) (24 years ago, 10-Aug-00, to lugnet.robotics)

Message is in Reply To:
  Re: Autonomous Robot
 
(...) a (...) the (...) reads (...) Sorry, Mario, I still didn't figure out your proposal. Could you explain that better? Did you (or anybody else?) already did that? Maybe if I can understand better looking at the code, if available... (...) that. (...) (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
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR