Subject:
|
Re: Autonomous Robot
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Fri, 11 Aug 2000 06:15:14 GMT
|
Original-From:
|
Steve Baker <sjbaker1@airmail./spamcake/net>
|
Reply-To:
|
sjbaker1@airmail.net(AvoidSpam)
|
Viewed:
|
738 times
|
| |
|
|
Doug Weathers wrote:
> > > 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.
> >
> > But if the robot isn't accurately pointed at the laser, it won't be able to
> > do that calculation since the ANGULAR separation of the detectors (subtended
> > at the laser) won't be known.
>
> You can handle this two ways.
>
> 1) omnidirectional laser sensor with cylindrical cross-section, which always
> has the same width no matter the heading of the robot
Yep - that would work - but we don't have an omni-directional sensor. I guess a
conical diffuser with a regular lego sensor pointing straight upwards would
work OK though.
> 2) have the process of acquiring the laser beam end up with the robot
> accurately pointing at the laser (or perhaps accurately pointing 90 degrees
> away from the beam because the sensor is on the side of the robot; this idea
> from an email from John Barnes)
Yes - I wanted to avoid having to continually distract the robot from it's
task in order to find out where it is. All this rotating to point towards
rotating lasers sounds REALLY time-consuming. I want my robots to get on
with doing a real task - and not spend minutes at a time figuring out
where they are - and then using odometry for about 30 seconds before they
have to do it all over again!
> > The ACCURACY of the SPEED of the laser becomes an issue. Since motors vary,
> > the actual speed of rotation is unknown unless you measure it continually
> > and pass that information to the robot. Since the precision of measurement
> > of angle is the thing you are trying to get rid of, this is a self-defeating
> > mechanism.
>
> In a sense, you are correct. But measuring the angle of a single particular
> pointing operation, as in your tower idea, seems to me to be more prone to
> error than measuring the speed of rotation of a turntable where all you
> really need is the average speed.
I suppose so - but is the average speed enough? Are lego gears smooth enough
and motors uniform enough to get you good angular rates? Maybe.
> Of course you could make several scans
> from top to bottom and from bottom to top and average your results, like the
> trick the Mars Pathfinder boffins used to increase the resolution of the
> camera on the base station.
Yes.
> > > But my main concern is the issue of the orientation of the robot.
> >
> > If the tower were the active component though (with all the brains), it
> > could measure the position of two or more retro-reflectors on the robot
> > and deduce the orientation from that. That might not be terribly accurate
> > though. I favor doing *only* position measurement - using consecutive
> > readings to deduce the direction the robot is moving - and therefore
> > pointing. If you drive in straight-ish lines for reasonable distances,
> > you can get this information to an arbitarily good precision. Use
> > odometry to cope with going around corners and to fill-in when you don't
> > read IR from the tower or if it loses the robot and has to re-aquire it.
>
> Sure, that would work, at the expense of having to move the robot to
> determine its heading.
Yes - but I wasn't planning on just running this system every few minutes,
I would expect to give the robot it's new position every second or two.
Hence, when the robot isn't moving, it's heading isn't changing so we
really don't need an update from the last known heading. Whenever the
robot happens to be moving in a straight line, it'll get a heading value
and use odometry when it isn't. You could also do planned straight line
motions to get the heading updated if you really need to know - but I
guess this all starts to depend a lot on the robot's mission.
If you are working in confined spaces and doing a lot of rotation, then
my scheme for getting heading from motion won't work. On the other hand
if this is a "Go get me a beer out of the fridge" robot, I would expect:
a) That there would be some nice long straightline motion.
b) In navigation, you are only really concerned with heading when
you need to get somewhere. Since this scheme delivers absolute
positions continually, and headings during forward motion, that
may well be good enough.
c) Robots that are doing lots of little rotations in confined areas
will be the ones that are least able to do complex gyrations in
order to intercept rotating ground-level lasers.
Well, this could all be B.S - but I think a lot depends on what your
robot is *for*.
> You'd have to worry about running into something
> because you're not quite sure of your heading, though. Not likely to be a
> big problem, since odometry is unlikely to be off by 180 degrees between
> calibrations.
And short runs will give you approximate headings - long runs, accurate ones.
So if you are hopelessly unaware of your heading, even a few inches of run
will get you a heading accurate to within perhaps 45 degrees. If you have
any kind of approximate cognitive map of your area, you should be able to
use that to predict a good direction to drive a foot or two...which gets your
heading down to (say) 5 degrees - which is enough to get you a really long
accurate measuring route.
However, I maintain that for many tasks, simply knowing where you are in
absolute terms means that accurate heading information is only useful
for bringing tools to bear on tasks (like opening the fridge and grabbing
the CORRECT beer). I doubt that all these spinning techniques are very
good for that because once you have gotten a really accurate heading, you
then have to trash it again by doing a big rotation to point in the
direction you actually wanted to go.
Well - like I said - it depends on the application I think.
> > If you are going to go for a tower-based system - and admit to non-Lego
> > laser pointers - then doing all the work in the tower is just monumentally
> > easier *and* faster than all these spinning robots, spinning lasers, wide
> > and narrow beams, etc, etc.
> >
> > The scheme I'm imagining would consume 2 scanning motors, two angle
> > sensors, one photo-detector and a $5 laser pointer (ALL in the tower)
> > plus *NOTHING* in the robot other than a retro-reflector mounted on
> > it's roof somewhere. It'll be fast - you could probably update the
> > robot with it's position once a second - and best of all, the robot
> > doesn't have to stop doing it's work to spin in place in order to
> > know where it is. The robot can use all three RCX inputs for doing
> > it's real job of work - and I can have multiple robots if I want.
>
> I missed how you can get by with only one laser. Ian Warfield's original
> idea used a ground-level laser to find out the robot's bearing from the
> tower, so that the tower-top laser knows that when it scans down it will hit
> the robot. How will you ensure that when the tower-top laser does its sweep
> that it will hit the robot? Do you just scan the whole room all the time,
> like the laser terrain scanner on the Dante II robot? If so, it seems that
> it would take more time than one second to complete one scan.
Yes - exactly. I'd do an initial cartesian grid scan of the entire room looking
for the robot. That'll take a LONG time...especially if the retroreflector on
the robot is small - so I have to scan a very fine grid.
However, once I know where the robot is, and I know it can only move (say) 10cm
per second - then in my next scan (one second later) - I only scan the region
within a 10cm radius of the last known position - and I'm guaranteed to find
the robot again. (Unless my dog grabbed it and ran off with it at 3 meters per
second - which is actually quite likely).
If I don't find it in that first scan then I gradually widen my search area
by 10cm in each consecutive scan. If I don't find it after (say) five
scans, I go off and scan the entire room again. Meanwhile, the robot is
patiently waiting for a position update - and if it hears the tower say
"I can't find you" - or if it doesn't hear from the tower at all, it can
stop to give the tower a better chance...or some other strategy - like
using approximate odometry to back up to the last place the tower said
it was at. That would allow you to navigate around chairs and tables
where the laser can't see you.
This kind of 'adaptive search' is not a new idea. In days gone by
before the invention of the mouse, computers used 'light pens' and
'vector scan' CRT's (no raster graphics back then). Lightpens were
located on the screen by those kinds of strategies.
Finally, you could refine your search still further if the robot would
tell you what it was doing. ("I'm turning left", "I'm reversing at
5cm/sec")...in the end, the robot could send odometry information to
the laser - whose job becomes one of fine alignment only. ("The robot
thinks it's 'here' - let's go see...nope it's 3cm to the right of 'here'")
Once you start thinking about bidirectional communications between robot
and tower, you can use software 'smarts' to replace a TON of mechanical
complexity...but then I've been programming since 1972 and playing with
Lego technics since July 17th 2000...so you see where my inclinations lie!
> Although once the robot is acquired, you can stop scanning the other parts
> of the room, I guess.
Yes - exactly.
I'd also like to extend the idea to multiple robots. The tower could know
the approximate positions of several robots - and just check up on each one
in turn. Those robots that are in most need of odometric-correction could
plead for higher priority in the queue of places to search. We'd have to
be VERY careful when two robots were close to each other though - if the
tower ever got them mixed up, things would get QUITE confusing. :-)
> > Now, I just need to figure out how to make a corner reflector instead
> > of using a bicycle reflector so that I don't get spurious laser light
> > flashing around the room - potentially damaging people's eyesight.
>
> The spurious reflections may be due to the fact that bicycle reflectors
> aren't mirror finished on the back, and the little corner reflectors
> probably also act as prisms, bending the light rays around and shining them
> back into other prisms unpredictably.
Yes. Also, the reflector has quite a lot of plastic around the edges
that reflects - but not as we'd hope. Possibly, masking out the edges
would help too.
I think using a bunch of mirrors to build a corner reflector by hand
would be better. I'd also like to *consider* giving the robot the
ability to change from a large reflector that the tower can find
quickly - but without much precision - and a smaller reflector that
it can deploy when the tower knows roughly where the robot is and
needs a small target in order to make a high-precision 'fix'. In the
'beer fetching' example, the robot needs a good fix at the start of it's
trip - but may only need very rough feedback while on the LONG trip across
the kitchen floor. Once it thinks it's getting close and has to latch
onto the door frame to open the fridge, it'll want REALLY good data and
won't care so much about how long the tower takes to scan that small
area.
> You might be able to fix this by cracking open a bicycle reflector and
> spray-painting the back. Ideally, you'd want to mirror-finish the back, but
> I haven't got a clue how you would do that. Can you buy paint that you can
> put on glass to turn it into a mirror? I don't think so, but it would be
> handy if such a product existed.
Yes - but getting three 1" planar mirrors at right angles seems easier.
> > If the tower can track a robot reasonably well, the laser will always
> > go down from the ceiling somewhere and shine within an inch or two of
> > the robot - then reflected back into the ceiling fitting. It would
> > be hard to get that shone in your face unexpectedly.
>
> Ceiling fitting? Where did the ceiling enter into your scheme?
Well, mostly, to minimise errors:
* The angle down to the robot needs to be steep because of the
nature of the 'tan()' function.
* I know that corner reflectors only work over 45 degrees and you have
to glue many of them together to increase the spread. If the laser
is in the center of the room on the ceiling, it can see pretty much
all of the room at 45 degrees or better.
* There are less obstacles when looking DOWN on the robot then
across a crowded room.
* The 'grid' that the laser paints to track the robot will have
better linearity if the laser is in the center of the grid.
* If the robot is going up and down small obstacles, the error in
positioning due to that would be much reduced with a 'look down'
sensor that is seeing a plan view of the action.
* The floor is more uniform in colour than the walls. Better for
light sensor calibration.
* There is no chance of firing the laser at a window or some other
reflective surface that would result in a retro-reflection from
a robot inside the room that would *APPEAR* to be sitting outside
the window as far as the scanner was concerned!
* I can do laser light shows onto the floor in the middle of the room!
* I'd want the laser to be pointing DOWN - rather than HORIZONTALLY
so it won't shine in my eyes by mistake.
> You could get the effect of a really tall tower by fastening your laser
> scanner to the ceiling.
Yes.
It would also be cool to mount them in several rooms so that they can
hand-off control of the robots as they go from one room to the next.
> If you don't want to fasten Lego stuff to the ceiling (look out below!), you
> might try mounting it on the wall with picture-hanging technology. More
> likely to shine into people's eyeballs this way, though.
Exactly - I think that's a major concern. Hopefully, everyone is admiring the
clever robots down on the floor!
> Some suggestions for safety signs follow. :)
>
> Sign on door of dining room, next to goggles on wall hook:
>
> "WARNING: All diners must wear eye protection!"
>
> Sign on the base station (wherever it is): "WARNING: Do not look directly
> into laser with remaining eye"
<giggle>
> > My two rotation sensors are on order :-)
>
> Good luck. We won't know how well these ideas will work until we start
> building them.
Indeed. Right now, I have a LOT of OpenSource software that I'm
committed to doing - so I don't have as much time as I'd like to
just *play*.
--
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 3991FAAF.A8D0FDBA@airmail.net, Steve Baker at lego-robotics@crynwr.com wrote on 8/9/00 5:43 PM: (...) <snip> (...) You can handle this two ways. 1) omnidirectional laser sensor with cylindrical cross-section, which always has the same (...) (24 years ago, 10-Aug-00, to lugnet.robotics)
|
37 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
