Subject:
|
Re: Autonomous Robot
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Wed, 9 Aug 2000 20:16:36 GMT
|
Original-From:
|
Andy Gombos <gombos_2000@yahoo.com^StopSpammers^>
|
Viewed:
|
629 times
|
| |
|
|
As a sensor, you could have the laser go into a large piece of quartz or some
other rock. When these rocks are hit they make the whole rock glow very
brightly, enough that a sensor could detect. You can get pieces for around $1
US, or you should be able to find similar rocks along the road.
Andy
Sattler Chris-QA1406 wrote:
> > -----Original Message-----
> > From: Doug Weathers [mailto:weathersd@metro.dst.or.us]
> > Sent: Wednesday, August 09, 2000 1:53 PM
> > To: lego-robotics@crynwr.com
> > Subject: Re: Autonomous Robot
> >
> >
> > in article FyyAqy.5zy@lugnet.com, Ian Warfield at
> > ipw47@hotmail.com wrote on
> > 8/7/00 6:56 PM:
> >
> > > I thought of another possibility for robot coordinate • recognition. It's
> > > rather unorthodox, however, and requires some special • equipment and setup to
> > > make it work. Still, in the interest of creative discussion...
> >
> > That's what this is all about, after all. Type on!
> >
> > >
> > > Building off the base station idea mentioned earlier, set • up a single station
> > > in the middle of the room/arena/whatever. This station • incorporates an extra
> > > RCX, two motors, two rotation sensors, and two laser • pointers, one mounted on
> > > the tower at ground level and one mounted about two feet • high. The robot
> > > itself sports a laser detection sensor.
> >
> > There are two ways to design a laser sensor - directional or
> > omnidirectional. Either way creates problems with your
> > approach, see below.
> >
> > >
> > > Here's the tricky part... use polar coordinates. Suppose • the robot wants to
> > > know where it is relative to the tower. It stops, sends • out an IR call for
> > > help,
> >
> > Hopefully, the base station is within IR range of the robot,
> > and the robot
> > is facing towards the base station. Perhaps the base station
> > should be
> > stuck in a corner so its IR window faces the whole room.
> >
> > > and enables its laser detection sensor. The base station • receives the
> > > call, turns on the ground-level laser pointer, and starts • rotating the tower.
> > > As soon as the robot detects the ground-level laser it • signals again, and the
> > > tower stops rotating. Next the base station switches off • the ground-level
> > > laser and switches on the high-level laser. The high-level • laser zeroes
> > > itself perpendicular to the floor and starts sweeping upward towards
> > > parallel. When the robot detects this laser, it signals • again, and the tower-
> > > based laser stops.
> > >
> > > Now the base station records the orientation of the tower • via the turntable
> > > rotation sensor and the angle of the high-level laser via • the laser rotation
> > > sensor. The base RCX stores the turntable orientation • provides the angle
> > > reference. It then multiplies the height of the tower (two • feet in this case)
> > > by the tangent of the angle of the tower-based laser to get • the distance from
> > > the base station to the robot. Finally, it sends the • ordered coordinate pair
> > > to the robot, which updates its internal odometry and • continues on its way.
> > >
> >
> > This is a really cool idea. I wonder if it will be accurate
> > enough at large
> > distances from the tower, where small changes in angle of the
> > laser create a
> > large movement of the laser spot.
> >
> > One way to get around this is to use an internal RCX timer with its
> > millisecond (?) resolution. The base station will have only
> > one laser, at
> > ground level. First it does a fast scan to discover the
> > approximate angle
> > of the robot. Then it does a slower scan across the robot
> > again, which does
> > two things: gets a better fix on the location of the robot,
> > and gives the
> > robot a chance to measure HOW LONG it takes for the beam to
> > transit the
> > detector. The knowledge of how wide the detector is, combined with
> > knowledge of how fast the tower was rotating (angle sensor
> > and IR broadcast
> > from tower), should allow the robot to calculate its distance from the
> > tower. The accuracy limitation here is not the resolution of
> > the angle
> > sensor, but the latency issues of the RCX firmware and your
> > code. (And the
> > smoothness with which the base station can rotate. Oil your
> > turntable!)
>
> Rather than use the width of the sensor as one leg of your triangulation
> calculation, another way to do this is to collect two angle measurements
> from the tower to the robot, having the robot move slightly between
> measurements. You could then triangulate the robots location. I'm concerned
> that the width of the sensor is an awfully small delta if the robot is
> far away from the tower. If you move the robot you coul move it a little,
> and if the delta in the angle is very small you could then move it some more
> to get a more accurate reading.
> >
> > But my main concern is the issue of the orientation of the
> > robot. If it has
> > a directional sensor, the robot has to be pointed right at
> > the base station
> > to see its laser. If you solve that problem by using an
> > omnidirectional
> > sensor (shaped like a cylinder, for example), then your robot
> > doesn't know
> > which direction it's pointing! (Of course if your robot uses
> > synchro drive,
> > perhaps this isn't much of a problem.)
> >
> > I think the robot needs a way to be able to point itself at the base
> > station. I like the previously-posted idea of a strobe
> > light, flashing at a
> > particular frequency. Or perhaps you could have the base
> > station constantly
> > sweep the laser beam around like a radar. When the robot
> > gets confused it
> > starts rotating slowly until it sees the laser sweep past.
> > Now the laser
> > sensor has two different and incompatible tasks - precise
> > determination of
> > the direction to the base station (which requires a narrow
> > aperture) and
> > precise determination of the time it takes for a beam to
> > transit the sensor
> > (which requires a wider aperture). Two sensors? A moveable
> > shade or "gun
> > barrel"? Something else, more clever than I can come up
> > with? Or back to
> > the two-laser base station you describe above?
> >
> > How about this: both the robot and the base station have an
> > omnidirectional
> > sensor and a laser. The base station can rotate, sweeping
> > the laser across
> > the room. Also, the base station's RCX rotates with the
> > laser so that the
> > IR window always looks out at where the laser is pointing.
> >
> > When the robot wants a position update, it starts sweeping
> > the room with its
> > laser by rotating in place.
> >
> > Now when the base station detects the robot's beam, it knows
> > that the robot
> > is pointing at it and it sends out an IR broadcast. If the
> > robot sees the
> > IR broadcast, it knows it's pointing at the base station, so it stops
> > rotating and sends its own IR broadcast to the base station.
> > Now the base
> > station starts doing its magic to determine distance and orientation.
> >
> > If the base station is in a corner, or some other trick is
> > used to ensure IR
> > connectivity, we're OK. However, if not, then what?
> >
> > Well, each unit will start scanning for the other one. Every
> > time one of
> > them sees the other's laser beam but fails to get an IR
> > handshake, a portion
> > of its own 360 degree field of view is marked as "empty" in memory.
> > Eventually they will find each other by preferentially looking in the
> > unmarked portions of their field of view. It shouldn't take
> > too long - I'd
> > expect that with the wide field of view of the IR windows
> > that each circle
> > only needs to be divided up into four or eight pieces.
> >
> > >
> > > In lugnet.robotics, Doug Weathers writes:
> > > > [snip lots of interesting thoughts of Cartesian coordinate • recognition]
> > > > OK, let's look at the robot.
> > > >
> > > > [...]
> > > >
> > > > It may be possible to do good odometry with only a single • angle sensor. Set
> > > > up a Dorst adder/subtracter and hook the angle sensor to • it. Normally this
> > > > would be used to correct the robot's course while it's • travelling in a
> > > > straight line, but this loses information about how far • it's traveled.
> > > > However, you could adopt a policy of only running one • motor at a time if you
> > > > need to know how far you've moved - if you can live with • your robot lurching
> > > > along left/right/left/right. Of course if you don't care • how far you're
> > > > going you can run both motors and go straight, such as • when you're following
> > > > a line or headed for a landmark.
> > >
> > >
> > > It *is* possible to use a single rotation sensor with an • adder/subtractor, but
> > > not quite like that. I have a robot driven by a • differential transmission
> > > (one motor fd/bk, one motor lt/rt) that has a rotation • sensor attached to one
> > > of the output shafts just before it drives the wheel. The • transmission allows
> > > precise maneuvering in any direction, and therefore • eliminates uncertainty
> > > about what the rotation sensor is saying.
> > >
> > > For example - when the robot is moving straight, the • rotation sensor is
> > > recording the straight motion of one wheel. Since the • transmission drives
> > > both wheels equally, you can safely extend the sensor to • the other wheel too.
> > > When the robot is turning in place, the rotation sensor is • recording the
> > > turning of one wheel, which is an exact mirror image of the • other wheel, again
> > > eliminating the need to check the status of the other • wheel. You can set up a
> > > formula that relates the number of turns of the wheel • (varies with wheel
> > > diameter) to the number of degrees turned.
> >
> > Duh - of course. <smacks own forehead>
> >
> > What a great way to solve that particular problem!
> >
> > Now we might want to turn our attention to the design of an
> > omnidirectional
> > laser sensor. I have some ideas but of course haven't tried
> > any of them out
> > yet. Sensor looking inside paper cylinder? Sensor looking
> > down at white
> > Lego "rocket nosecone" piece, or a shiny tinfoil cone?
> >
> > >
> > > HTH,
> > >
> > > Ian
> >
> > Thanks for the great ideas, and thanks everyone for reading
> > such a long
> > post.
> >
> > --
> > 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 is in Reply To:
 | | RE: Autonomous Robot
|
| (...) Rather than use the width of the sensor as one leg of your triangulation calculation, another way to do this is to collect two angle measurements from the tower to the robot, having the robot move slightly between measurements. You could then (...) (24 years ago, 9-Aug-00, to lugnet.robotics)
|
3 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
