Subject:
|
Re: Ultrasonic Sensor
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Wed, 6 Feb 2002 15:49:57 GMT
|
Original-From:
|
Steve Baker <sjbaker1@airmail.netNOMORESPAM>
|
Reply-To:
|
sjbaker1@airmail.NOMORESPAMnet
|
Viewed:
|
818 times
|
| |
|
|
Lee Wilson wrote:
> Thanks for that Steve. My circuit will be based on the latter of the two
> possibilities.
Yep - I thought so...for things like cameras where these things are in
common use, the need is only to know the range to the nearest object.
I don't even know if the other things (multiple object detection and
size/reflectance estimation) are feasible.
Thinking about it a little more, there may be some other things worth
investigating with the simpler interface. For one thing you may need
to calibrate the device based on air pressure, temperature and humidity -
which all affect the speed of sound in air.
I havn't had a *lot* of experience with acoustic ranging - but one anecdote
may prove valuable...I work in flight simulation - and we use an acoustic
device to measure the position and orientation of the pilot's head - so we
can tell where he's looking and concentrate more graphical scene details
in that region.
We found that on hot, humid days, the helmet would report wildly incorrect
numbers - but on dry, cool days it was pretty accurate. Someone put a
temperature and humidity probe into the cockpit and we were suprised to
find that the airconditioning in the simulator was keeping the temperature
and humidity pretty much constant - no matter the outside conditions.
We were all rather suprised because why would the sensor care a damn what
the *outside* conditions were. We puzzled for a long time before we realised
that the flow of air caused by the air conditioner kicking in was causing
a doppler shift in the acoustic tracker - enough to confuse it and generate
bogus readings!
It proved almost impossible to fix the problem in software - what with
turbulance and such. In the end, we opted to baffle the air conditioner
to reduce the speed of the air through the simulator.
I doubt you'll have to worry about that - we needed pretty precise readings
in our application.
> I would like to look at the data logging capabilities of the RCX for using
> the ultrasound device in a contour mapping system. I would imagine I would
> need to use legOS or something similar here as opposed to NQC?
NQC has the ability to record a limited amount of data into a "data log" which
your PC can request to have transmitted to it with an Infra-Red command.
I havn't a lot of experience with LegOS - but I think it has more sophisticated
facilities - at the very least, you can just read and write the IR port at
will rather than fighting your way past the Lego Firmware.
> An interesing
> application of a seperate trasmitter and reciever unit would be as a "homing
> beacon" where a robot would use the source as a guide to a docking bay or
> something similar.
Yes.
> I've been asked to show the sensor working on a robot as it navigates a
> maze.
Ahhhh...so there is a need to write some significant software for the
beast.
> I wouldn't think the control algorithm or robot construction will be
> too complex!
Not if you know the details of the maze's construction in advance...stuff
like the width of the corridors and whether all the walls are at right
angles. A simple "follow the left hand wall" algorithm is all you really
need. If you want to do something more sophisticated such as figuring
out that some turning *must* be a blind alley because you've already
driven all the way around it...then you'll *NEED* LegOS because NQC
doesn't allow you to have much storage for arrays - and you'll need
some largeish arrays to store that kind of information.
Construction can be very simple - just some kind of two-wheeled cart
with a motor on each wheel and a caster or glider to stop it falling
over...something like that. I think there is one of those in the RCX
constructopedia. Try to mount your sensor at the center between the
two wheels so that it doesn't change position as you rotate the robot
- you'll save yourself much grief if you do!
> If I recall correctly, in terms of software the circuit can be
> treated as a light sensor.
Yes - that essentially just reads a voltage - so NQC will just think it's
some kind of analog sensor. The RCX knows about the Lego temperature sensor,
and a couple of other odd-ball things they make - but there is also an NQC
command to just read the voltage 'raw' - that's probably the one you need.
> I guess the maze test, if not much else, will
> give a nice photo opportunity for a poster I will have to present on the
> project later in the year!
Yep. Fun, fun, fun!
----------------------------- Steve Baker -------------------------------
Mail : <sjbaker1@airmail.net> WorkMail: <sjbaker@link.com>
URLs : http://www.sjbaker.org
http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
http://prettypoly.sf.net http://freeglut.sf.net
http://toobular.sf.net http://lodestone.sf.net
|
|
1 Message in This Thread:
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
