New Sonar Range Sensor

All, I have been working on an ultrasonic sensor since 1994. About two years ago I decided to package the sensor for everyone.
It is avaible now. Data sheet is avaiable at the web site.
www.maxbotix.com
The MaxSonar-EZ1: is very low cost, uses just one trasnducer, detects to zero (yes even pressing against the front face), detects to 254 inches (6.45 meters), is the smallest size (smallest PCB & includes mounting holes), is the lowest power (just 2 mA typical at 5V), has a controlled narrow long-range beam,
has a very easy user interface including RS232C, pulse width, and analog votlage.
I posted this because this really is a break through product and I would have wanted one in 1997.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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:

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@gmail.com wrote:

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@gmail.com wrote:

Thank You : )
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@gmail.com wrote:

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.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Chris, Check out www.eutectos.com. A new product is just about to come out that addresses your array needs and cost. Regards, Larry
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Brian Dean wrote:

Maybe not if it makes the original product look better.
Mitch
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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!
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Bob (Robot Wars Thumper 1997) wrote:

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 /
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
D. Jay Newman wrote:

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Wayne C. Gramlich wrote:

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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?

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
blueeyedpop wrote:

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]
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Wayne C. Gramlich wrote:

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Wayne,
Check out the PSR-1 at www.eutectos.com and give me your comments.
Larry
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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:

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.