Various false readings from Lego ultrasonic in legacy module

[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

[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...

[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.

[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.

[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.

[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...

[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]

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