Subject:
|
Re: Autonomous Robot
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 10 Aug 2000 01:36:50 GMT
|
Original-From:
|
Steve Baker <sjbaker1@airmail.*ihatespam*net>
|
Reply-To:
|
{sjbaker1@airmail}AvoidSpam{.net}
|
Viewed:
|
906 times
|
| |
|
|
Doug Weathers wrote:
> > 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!
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 *precise* position on the edge of the circle. (well within
the size of the barcode at least). The barcode would have to be
a grey-coded set of circular arcs or something.
> >
> > 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.
I wasn't suggesting that the robot follow the "train tracks" all the time.
Mostly, it would use odometry - but when it estimates that it's odometry
is "off" by an intolerable amount, it can drive in almost any direction until
it hits a "train track" and follow it to a place where a bar-code will tell
it where it is *unambiguously*. Then it resets it's odometer and goes
back to whatever its primary mission is.
> > 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.
Cool!
> >
> > 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.
Oh - yes - of course! I think real barcodes are done like that aren't they?
So you can read them in either direction (or when they are upside-down).
> > 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.
I just took a careful look at it - and it's way too small - and also has identical
looking arrows pointing N,S,E,W - so you wouldn't know which way to it was
really pointing.
> > 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.
Hmmm - yes.
> > 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.
Presumably if the robot stops briefly, most of the vibration and *dynamic*
magnetic effects will be gone. You could engineer the location of the compass
to minimise the effects of the permenant magnets in the motors. In any case,
we can calibrate the robot to take account of the errors in it's compass.
(A little lookup table - "When the compass says 0 degrees, we are really at
10 degrees - when the compass says 10 degrees, we are really at 27 degrees...")
> > 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.
Cool! ...and as you say "most instructive".
Hmmm - magnetic bar codes! A Lego floppy-disk with about 10 bytes
capacity!....OK - maybe not :-)
> > > 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.
I've found that with 'real world floors', you have to mount the thing quite
high up so that it doesn't keep hitting the ground - but your milage may vary.
> Even so, the chance of an ambiguous reading must be vanishingly small.
> Could it be neglected?
Maybe.
> 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.
Yes - but the larger target tells the robot less about its position. In a
3 inch target - you only know your position to within 3 or 4 inches.
Sounds like a zero-sum game.
> 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 so. There is also the problem of driving along the length of
a line - stuff like that. If you are making your lines VERY wide to
allow less-ambiguous WHITE/GREY detection - then this becomes quite
likely - and hard to detect.
> > 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.
Yes - I guess so - but the luminous/non-luminous approach should eliminate the
straddling-the-edge-of-a-bright-spot problem. If you get a larger-than-ambient
light return with your lamp turned off - it's luminous for sure - if you get nothing
(with or without light) then you are looking at the floor - and if you get returns
with your light on - but nothing with it off - then it's a normal reflective strip.
There shouldn't be any ambiguity when we cross the edge of a strip since all the
decisions are strictly binary.
...well, it's all rather impractical IMHO.
--
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 is in Reply To:
 | | Re: Autonomous Robot
|
| in article 398F84B6.F9AE89A8@airmail.net, Steve Baker at lego-robotics@crynwr.com wrote on 8/7/00 8:55 PM: (...) Of course, if odometry puts you inside the circle, you don't need bar codes because you already know where you are! (...) True, and I (...) (24 years ago, 9-Aug-00, to lugnet.robotics)
|
37 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
