Ultrasonic Help

[Jogo]

Our team has been trying to use the XL-MaxSonar EZ4 in order to determine the height of our manipulator (by placing the sensor on the floor and pointing it vertically upwards at a 1 sq. foot piece of lexan on the bottom of our elevator). However, we are having trouble getting consistent data. We have the sensor detecting objects at distances of 20 feet accurately straight ahead, but when looking up at our manipulator it loses accuracy and claims that the manipulator is much closer than it really is. We've tried placing a felt cone around the sensor, which seemed to improve the data a little but not consistently.

Any advice? If you don't think ultrasonic is a viable solution, maybe you could suggest an alternate method/sensor? Would rather not use encoder but probably will if there is no (easy) way to measure absolute height.

[davidalln]

What's wrong with using an encoder? We use it to run our positioning and it works very predictably every time.

I really don't have any advice on the ultrasonic issue. Theoretically it should work, but I could also see a lot going wrong as well. To be perfectly honest, that seems like an extremely dicey way to measure height.

[Mark McLeod]

At a range of 5 feet the detection cone on an E4 is almost 3.5 feet wide.

I'd imagine after a couple of feet it will see the superstructure of your robot before it sees the 1 sq ft lexan target.
Possibly, angling the sensor to catch the arm as far from the superstructure as possible might help.
It'll probably see the bottom of any tube you're carrying, so take that into account.

Look at the comparison chart on page 5 to see the relative shapes of the detection cones.

[Jogo]

Thanks, Mark, I didn't look at that diagram close enough. Does anyone have any advice with the "dowel", as far as material, diameter, and placement? The "A" beam pattern looks great, however, how is a .25" cylinder possible when the sensor itself is larger than .25"?

[DonRotolo]

This is the EZ4 data sheet. At 5 feet the detection path is about 2 feet wide.

How can one sense a 1/4" dowel? Remember, it is not the size of the object you are detecting, but the ultrasonic sound waves that reflect from it. If you could get a 0.001" wire to reflect enough sound energy, you can detect it. Of course, the larger the object, the further away you can 'hear' the reflected sound.

Instead of a felt cone, try a piece of pipe about 6 inches long, just large enough to fit over the sensor head. Plastic or metal, something with some density (not cardboard). That should narrow the detection width quite a lot, the issue is whether the sensor can handle the interference this will set up.

EDIT: D'oh! As a few have pointed out, I got the data sheet wrong. See below.

[Mark McLeod]

Originally Posted by DonRotolo

This is the EZ4 data sheet. At 5 feet the detection path is about 2 feet wide.

That's the LV datasheet. They have an XL (datasheet).

[theprgramerdude]

Just angle the sensor away from your robot, or place a rubber cone (with small holes) behind and around the sensor. The rubber will be able to cancel out any side acoustics, in my experience. Are you stuck with using that model of XL? If possible, I'd reccomend switching over to the AE version, rather than the EZ, and looking for the reflected signal of the target on the AE output; it's a lot less prone to interference, although it requires a very significant amount of programming expertise.


Don, that's the datasheet for the LV model of sensor. The two models are quite a bit different in regards to how they can operate.

[Gdeaver]

Sharp makes an IR distance sensor that is good out to 5'. They have a narrow detection cone. They have served us well over the years. There is a problem with long leads. A 100 uf cap across the gnd and 5 volts will help. If you try them, don't forget to buy the matching JST pig tail. They do not like clear poly. A different sensing plate would be needed.
http://www.pololu.com/catalog/product/1137

[Matt Krass]

I've used these sensors many times, and I don't think they're going to reliably give you the feedback you're looking for. I think an encoder with some limit switches to 'zero' the position (or set it to whatever encoder value makes sense for where the limit switch is) would probably be much more reliable. Depending on the mechanism, it may also be feasible to have a multi-turn pot where the encoder would mount, so it has sufficient travel range to sense the full movement of the elevator. This would always give you an absolute reading.

Matt

[apalrd]

We have a 10-turn pot sensing drum rotations. The drum rotates slightly more than 10 times, so it is chained (with plastic sprockets) to the drum shaft, providing a slight reduction. We now use about 8 turns of the pot over the entire travel distance.

We don't like encoders for absolute positioning because we don't know exactly where we are, only where we think we should be based on where we assumed (or sensed, with another sensor) we started. The largest issue is that, if we don't start at home, we have to move to home to reset. If we have a practice robot and we don't fold it up into the start position before running it, or we stop running deployed code to change something without folding up into start position, we no longer know exactly where we are. That said, for some mechanisms, it's the best way to do it.

[DonRotolo]

Indeed that's the wrong datasheet, sorry everyone & thanks for the correction.

[Matt Krass]

Originally Posted by apalrd

We have a 10-turn pot sensing drum rotations. The drum rotates slightly more than 10 times, so it is chained (with plastic sprockets) to the drum shaft, providing a slight reduction. We now use about 8 turns of the pot over the entire travel distance.

We don't like encoders for absolute positioning because we don't know exactly where we are, only where we think we should be based on where we assumed (or sensed, with another sensor) we started. The largest issue is that, if we don't start at home, we have to move to home to reset. If we have a practice robot and we don't fold it up into the start position before running it, or we stop running deployed code to change something without folding up into start position, we no longer know exactly where we are. That said, for some mechanisms, it's the best way to do it.

I share your concerns, and I agree a multiturn pot is probably the right way to go for this.

Matt