New Sonar Range Sensor

Bob, Congrats on the new product! Looks very well done.

A suggestion: a deficiency of many of these types of offerings is the
lack of software examples for integrating the data from a sensor into
something meaningful. Single ping ranging is easy; actually "seeing"
surfaces and 3D objects, especially those not perpendicular to the
sensor) is much harder. As you know, there is a tremendous leap from
simple sensing to actual autonomous navigation.

Would you consider some code examples for a couple of popular platforms
-- a PIC or BASIC stamp, for example. Since your sensor has RS232
outputs (bravo!), interfacing to a PC is easy. How about a Windows DLL
for mapping that could be called from VB, C#, C++, or other compliant
language.

-- Gordon


Bob (Robot Wars Thumper 1997) wrote:

the reasons you don't see more hobbyists making maps out of sonar data
are that it requires:

1. more copies of a sensor than most are willing to buy
2. more memory and cpu power than most 8 bit cpus they use can provide
3. good enough dead reckoning to integrate readings over movement

navigation is admittedly a nontrivial problem but reducing sensor data
to local occupancy maps is old hat in cs research.  the key is that
unlike a lidar or machine vision system you can't make much of a map
with just readings from one location.  you need to have readings from
many locations in many directions and you need to combine them
sensibly.  i have done this with sensors like the one above and it is
certainly possible to get decent looking maps.

...which brings me to my next point.  rs-232 is nice but full coverage
with 40khz piezo sonar takes about 10 sensors and who has that many
extra serial ports on their robot?  i'm sort of cheap and didn't want
to buy 8 devantech sensors so the one robot sonar system i built had
one tranciever multiplexed to 8 transducer pairs.  that way you get
extra sensor data for basically the price of the transducers, which is
about $5 each.  this is standard for sonar on the big research robots.
i've only seen it done on homemade robots once or twice.  maybe that's
just because most people use prebuilt sonar sensors and there currently
aren't any multi-transducer types.

and as far as "seeing 3d objects" goes, it's certainly possibly but not
with 40khz narrowband.  building a 2d phased array broadband sonar is
#1 on my list for the next time i get stranded on a deserted island
with a dsp development suite...

anyway just my $0.02

-chris.

Got any pics or more info on the 8X x-ducer setup you made ?
I'm also curious why you state that one needs 10 sensors.
Do you have any links or info for a sonar newbie ?

-JSM

well, 10 is about what you get when you divide 360 degrees by the beam
width of piezo transducers.
if you're using electrostatic transducers you would want more since
they have tighter beams.

my robot's webpage is here:
http://www.jormungand.net/projects/crunch/

there isn't a schematic but if i recall the analog parts were based
somewhat on this robot:
http://www.wa4dsy.net/robot/sonar/index.html

-chris

Thank You : )

Buy one and stick in on the end of a stepper motor.  Then
sweep it back and forth.  I have never done this myself,
but I have seen it done this way.  Of course, it was not
a fast moving robot.


Take the price of an 8 bit CPU, add the price of a cup
of coffee, and you can buy a 32 bit CPU.  Check out the
latest ARM microcontrollers from Philips and Atmel.
32 bits, lots of I/O, up to 60 MHz, up to 256kB of
internal RAM, C compilers that actually generate good
code.  These days, using an 8-bitter as the main cpu
in a robot makes about as much sense as commuting with
a unicycle.  You can expect to see less and less of it
as all the nostalgic old farts die off.

Chris,
Check out www.eutectos.com. A new product is just about to come out
that addresses your array needs and cost.
Regards,
Larry

Larry,

On Mon, 09 Jan 2006 12:07:41 -0800, Larry wrote:


Just an FYI - most folks would consider it bad form to hijack someone
elses new product announcement with announcements of a similar product
of your own. You should create a new thread instead.

-Brian
--
Brian Dean
ATmega128 based MAVRIC controllers
http://www.bdmicro.com/


 Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
    ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------        
                http://www.usenet.com

Maybe not if it makes the original product look better.

Mitch

Thanks for the critical feedback.
The code examples are likely to go in this weekend or the next, right
now I have code for the basic stamp and for the basic atom.  The code
will be added into the FAQ section.

As for RS232, I have one very positive feedback from someone
(http://www.roboticsgroup.com/ ) who connected to a PC using
hyper-terminal.  I need to add this to the site also.  It was hard for
them to believe that this type of sensor would have such a narrow beam!

Only so much time and so much to do!

If it had either TTL-level coms or RS485 I might be interested.

I just don't think that RS232 has enough noise-immunity for robotic
use. IMHO.
--
D. Jay Newman
http://enerd.ws/robots/

Jay:

 From reading the schematic of the Maxbotix spec. sheet, the RX/TX
is signalling is connected directly to the pins on the PIC16F676.
Thus, the Maxbotix sonar is using 0-5V signalling (i.e. TTL),
not RS-232 signal voltages.

The signalling voltages for RS-232 are typically +/- 12 volts with
a no mans land of +/- 3 volts.  I have been in environments where
we've run 100's of RS-232 cabels for 100's of meters side-by-side
without any problems.  Thus, my experience with RS-232 noise immunity
is that it is excellent.  My experience with running TTL over much
shorter distances has not been nearly has pleasant (I used to live
across the Charles river from the Boston University radio station
broadcast station, and very short pieces of wire picked up a great
deal of signal.)  I agree with your assessment about differential
signalling (e.g. RS-422, RS-485, CAN, etc.), differential signalling
tends to have excellent noise immunity.

I'm curious what experience you have with RS-232 that makes you
dislike it in a robotics environment?

Any insight would be greatly appreciated,

-Wayne

That's good news for me. I took the OP at his word.


You must be using better cable than I do. Or perhaps a better source
of RS232 transmissions (mine are PCs or microprocessors used in robots.


Yes. I was planning on immediately converting the TTL-level to
RS485.


I've had too many communications breakdown within robots before
I gave up on RS232. Perhaps I've had bad luck and bad cables.

On small robots RS232 has worked fine for me, but when I raised
the size of the robots and the speed of the communications bad
things happened.
--
D. Jay Newman
http://enerd.ws/robots

There are a few deep evils in robotics.

Non-differential runs off the PCB
Step/Direction control of motors

Sure, if you are building things that run around the carpet for your own
jollies, but if it needs to be bullet proof, go differential.

On the subject of TTL serial, isn't RS-232C a specification for voltage
levels and comms spec?

No real arguments from me.


The RS-232 spec. (now EIA-232) is often referred to, but rarely actually
read.  Part of the reason for this is because EIA (Electronics Industries
Alliance) <http://www.eia.org/>  does not make it particularly easy
to get your hands on a copy of the bloody specification.  You are welcome
to purchase a copy from Global Engineering Documents for $100.00 (US)
<http://global.ihs.com> .  Frankly, I would rather spend $100 on my various
robotics projects.

I had a photocopy of a photocopy of the actual EIA-232 specification some
number of years back and it was not terribly exciting.  From my possibly
foggy memory, EIA-232 specifies the voltages levels (+/- 12V) and the
pin-outs for DCE (Data Communications Equipment) and DTE (Data Terminal
equipment.)  To first approximation DCE=modem and DTE=teletype.  The
pin-out outs are for 25-pin D connector.  To the best of my recollection
(I could be wrong) the spec. did not specify the asynchronous signalling
protocol of a start bit, 7 or 8 data bits, optionial parity bit, and 1,
1.5, or 2 stop bits.  I do not know if that is written down in a different
spec. somewhere.  I also remember that the maximum cable length was
specified as around 50 feet, even though people regularly exceeded that
specification.

If anybody has the actual EIA-232 specification and can quote from it
please feel free correct any errors in the text above.

-Wayne

[snip]

On Mon, 09 Jan 2006 03:57:38 GMT, "Wayne C. Gramlich"


I've actually read it as well, & even wrote a book once, using RS-232C
as a major source, although it's been a long time...

50 ft is a rule of thumb.  The actual specification is 2500 pF
capacitance of the leads.  With 50 pF/ft "typical" for most cables, 50
ft also becomes theoretical max. length to stay within the limit.
Lower speeds can get you longer runs because the capacitance (&
therefore length) affects the rise times of signal states & there's
more room for slop if the speed is slow than if it were fast.

IIRC,  the difference between RS-232C & RS-232D was the introduction
of the 9-pin cable/connector into the accepted standard (although it
had been used in the field for years).

Other specs covering the same topic are CCITT V.24 & V.28 (different
organization than EIA, basically "splits" the spec.).

JM

We have the spec and have been reading it recently to support efforts
on a project. You are correct, the RS232 spec only specifies voltages
and signal names/uses. That's all. No protocols. Originally the spec
was written to support communication between two devices, each using a
modem. So, back then, you did not connect a PC and a printer or a PC to
another PC, it was a terminal (DTE) to a modem (DCE), on each end of a
dial up or leased (analog) line. This explains a lot of the signals and
their naming conventions, which don't particularly make sense now
between non-modem devices, using digital (non-carrier) links. So the
RTS/CTS and DTR/DSR handshake lines were originally developed for and
intended for communication over a modem connection. Since that time
they have been commonly abused as hardware flow control (something
never contemplated in the RS232 spec) to the point that there are "de
facto" standards for such use, and such use/abuse is now more common
than the original modem use.

There are also some newer versions of the spec which do allow for
hardware flow control, but I'm not sure we have the official document
for that.

Regards
Bruce Boyes

Wayne,

Check out the PSR-1 at www.eutectos.com and give me your comments.

Larry

Larry:

You should probably announce your product in a new thread
rather than tailgate on this one.

Are there any pictures of your PicoSonic Ranger-1 on the
web site?  I use Mozilla running on Linux and I all I got
was some text, no pictures.  When I read the page HTML,
it looked like a bunch of <Div>'s and <Table>'s, but I saw
no <Src> directives.

I'd also recommend that you post your manual in .pdf format
so that anybody can download it and read it.

Just my thoughts,

-Wayne

Larry wrote: