Various false readings from Lego ultrasonic in legacy module

[zain]

Was helping kids today. they have a lego NXT (not EV) US sensor in one of the ports of the legacy module. There are two that support the US, and they have one of them.

Unlike their lego experience the US distance readings are unreliably messy. With a reasonable number of erroneous 0 and 255 distance returns. Once they "if-statement" those out and ignore them, they detect a reasonable number of fairly wrong values. Like 12 cm when the robot is really 30 cm away.

They've just started doing some basic histograms of the return data, but in watching this I have to say

1. These worked WAY better and more reliably when doing FLL with the lego kits
2. The returns are so all over the place that even simple things like averaging or other tricks to make the data less bad are only somewhat helpful. It really looks like outright dropped bits and communications failures happening and a reasonably high rate.

yes, they have tried more than one US sensor and more than one wire.

While it's been a good learning exercise for coding for a "noisy" sensor, I have to wonder if this is "normal" and I should add it to the really long list of difficult-to-the-point-of-wrong things about our new hardware this year.

Any advice or observations?

- Z

[mikets]

When the robot is moving, the US sensor's readings may vary sometimes because it is getting reflections from different objects, some could be within the robot's structure (if you mount the US sensor not clearing the frame structure completely. Also, like you said, you need to differentiate erroneous data from the normal ones. Discarding 0 is one valid way. Sometimes, using a low pass filter may be useful to throw out occasional "spikes" of the data.

[zain]

Yes. but here it is just moving straight toward a wall. With no other objects and a well positioned sensor. The kids went though all this in FLL of course, so it's not new to them. They are just surprised at how bad the signal looks and behaves in the supposedly more advanced FTC world. And frankly I am too...

[matrixguy]

I am having similar problems too. I just have my robot frame on my bench with the wheels off the ground in order to test autonomous code. I was wanting to do the same thing - have the robot go toward a wall and stop at a certain distance, but as you said the readings are not very consistent. I have my ultrasonic sensor pointing to the side and there isn't anything there. I was just going to use my hand to represent the wall.

I have used ultrasonic sensors before - LEGO, Third Party LEGO Compatible, and VEX - and I never had any problems like this before. They all worked very well and the robots were able to navigate around the room avoiding objects and my hand. The way the ultrasonic sensor is working with the new system right now, it isn't much good for anything.

I would really like to know if other teams are having similar problems or if they are able to use it reliably.

[Philbot]

I am having similar problems too. I just have my robot frame on my bench with the wheels off the ground in order to test autonomous code. I was wanting to do the same thing - have the robot go toward a wall and stop at a certain distance, but as you said the readings are not very consistent. I have my ultrasonic sensor pointing to the side and there isn't anything there. I was just going to use my hand to represent the wall.

I have used ultrasonic sensors before - LEGO, Third Party LEGO Compatible, and VEX - and I never had any problems like this before. They all worked very well and the robots were able to navigate around the room avoiding objects and my hand. The way the ultrasonic sensor is working with the new system right now, it isn't much good for anything.

I would really like to know if other teams are having similar problems or if they are able to use it reliably.

We've used the LEGO Ultrasoninc sensor on past years FTC robots.

I would characterize it's past performance as barely reliable.
We've used it to try and judge distance to goals several times.

After you filter out obvious low and high readings there are still lots of reasons why they give erroneous readings.

(Since it's still early, I'm not ready to fully trust the Android code, but that's not the only reason things are iffy)

Some things that I've noticed.

1) It's VERY easy to get reflections form other FTC items: Like the floor, other robot components, other robots, and other field elements.
Since the signal is acoustic, and is sent out in a repeated pattern, it's possible to get "past" pings returned from distant reflectors that confuse the range timing.
Field corners are perfect retro-reflectors, and can cause issues.

2) When running, our robots seem to generate just the right sort of noise to effect the sensors.
Perhaps it's the ultrasonic switching of the motor controllers, being transmitted by the motors, and being picked up by the sensor.

3) The transmit/receive cone of the sensor seems very large, so it's difficult to tell what's really in the beam path, which makes smaller, round object difficult to detect.

I think part of the problem is the NXT sensor is a plastic toy, designed for small LEGO robots. Our larger FTC robots generate more noise (mechanical and electrical) so they need a better sensor.

Phil.

[zain]

It's interesting to hear the take on ultrasonic (and other) sensors in FTC. These kids had to do a LOT more with sensors in FLL, on a mat covered in various objects and targets representing a more complicated environment than FTC. As they got to 7th grade they did little graphical histograms of the sonar sensor output. And I have to tell you it was WAY better than what they are seeing with the same sensor hooked up to the legacy module here. Especially since we're talking about a very basic test, like facing right at a wall with the robot not even necessarily moving.

I get how there could be electrical or other noise issues. But a still robot producing cruddy data feels more like another design problem with the hardware we all went to this year. Ah well... more to do and learn for them I suppose. But a bummer to watch as they are going to spend a couple years getting back to where they were in FLL when it comes to using sensors and doing autonomous.

[zain]

I should also add that they used the lego US sensor successfully last year, where they servo'd to the distance from the wall after coming down the ramp to they were always on target to align with the rolling goals. Lego gyro feedback was running the whole time so if it slipped a little on the ramp it corrected, and after dropping the balls and capturing the goal they could reliably make arcing turns to within an inch of repeatability on landing the rolling goal in auto. This year... well not so much the same kinds of results with the same sensors...

[FTC6389]

I am having similar problems too. I just have my robot frame on my bench with the wheels off the ground in order to test autonomous code. I was wanting to do the same thing - have the robot go toward a wall and stop at a certain distance, but as you said the readings are not very consistent. I have my ultrasonic sensor pointing to the side and there isn't anything there. I was just going to use my hand to represent the wall.

I have used ultrasonic sensors before - LEGO, Third Party LEGO Compatible, and VEX - and I never had any problems like this before. They all worked very well and the robots were able to navigate around the room avoiding objects and my hand. The way the ultrasonic sensor is working with the new system right now, it isn't much good for anything.

I would really like to know if other teams are having similar problems or if they are able to use it reliably.

We have been using this sensor from Maxbotics hooked directly to the MR sensor interface module. There are several models to choose from. Many have a much greater range than the Lego sensors.

- The Lazybotts
www.lazybotts.com

[mikets]

We have been using this sensor from Maxbotics hooked directly to the MR sensor interface module. There are several models to choose from. Many have a much greater range than the Lego sensors.

- The Lazybotts
www.lazybotts.com

What scenario are you using it for? For us, we use ultrasonic to detect how close we are from the rescue beacon. Unfortunately, we want to be two inches away from it and the Maxbotix US sensor can only do 6 inches minimum. For the particular model you linked to, it can only do about 12 inches (30 cm). Any distance shorter than the spec'd minimum will be reported as minimum. So this particular sensor will report 12 inches no matter how close you are to the obstacle.

[FTC6389]

What scenario are you using it for? For us, we use ultrasonic to detect how close we are from the rescue beacon. Unfortunately, we want to be two inches away from it and the Maxbotix US sensor can only do 6 inches minimum. For the particular model you linked to, it can only do about 12 inches (30 cm). Any distance shorter than the spec'd minimum will be reported as minimum. So this particular sensor will report 12 inches no matter how close you are to the obstacle.

We use it for the same thing, but mount it farther back on our robot, not the front edge, so we are able to accommodate the minimum distance. It just took some time to mount it in a place where there was no interference from the robot.

- The Lazybotts
www.lazybotts.com

[zain]

We'll have to give that sensor a try. Fits with my suspicion that the MR legacy module is iffy at times and we'll be better off going analog into the MR sensor module. My kids have a set of simple potentiometers going into that module for set up (delays, red vs blue, other options) and those readings are always stable and bulletproof it would seem.

Sadly not really enough time to change things this year... Next year I suppose...

[ruhul]

My team's experience is very similar.
I am wondering, will it be any better if we try EV3 ultrasonic sensor?

[ruhul]

Zain: I wanted to understand your implementation for "going analog into the MR sensor module". Are you going to strip the end of ultrasonic sensor cable and connect to Analog port of MR sensor module? if so..Please let us know cable to pin map.

[FTC3805]

My team's experience is very similar.
I am wondering, will it be any better if we try EV3 ultrasonic sensor?

EV3 isn't compatible.

Zain: I wanted to understand your implementation for "going analog into the MR sensor module". Are you going to strip the end of ultrasonic sensor cable and connect to Analog port of MR sensor module? if so..Please let us know cable to pin map.

The Maxbotix sensor they linked doesn't come with a cable. You have to solder wires onto it. The pads are labeled and docs come with it. The Core Interface Module web page on the Modern Robotics site has the pinout for the ports.

[zain]

I have to say, it seems a lot like anything I2C based, either on the Legacy Module or the Core I/O modules seem kinda sketchy. As you can see from my post about the MR color sensor it seems to go AWOL from time to time too. With last season's hardware the sonar was more reliable than this - lego works with lego I suppose, be it FLL or FTC. Bummer but live and learn. Hopefully some future updates or community shared code will make available some robust I2C. Or... we can all work on finding analog interfaced sensors.

thanks for the tip on the maxbotics item. I'll see if I can get the kids to play with it between seasons. Assuming I haven't lost to many of them to this year's learning experience.