Various false readings from Lego ultrasonic in legacy module

[zain]

Thanks you guys. I'll see if the kids want to try this or learn from it, or just keep pivoting to dropping the legacy module and using MR sensors and I2C things they can make work with the interface module alone.

[Cheer4FTC]

I incorporated the single-shot code provided by skatefriday (thanks, skatefriday!) into a simple, thread-based project that doesn't use the rest of Team25's sophisticated codebase. It only has 3 files: skatefriday's Team25 ultrasonic single-shot driver class, an UltrasonicThread class, and a test OpMode class. The project is available at the link below for anybody who wants to use this in their OpModes:

https://github.com/cheer4ftc/Ultrasonic1Shot

It essentially starts a thread in init() that repeatedly does single-shot Ultrasonic pings with the appropriate delays between the pings and the reads. During loop(), the most recently read ultrasonic level can be accessed. There are also a few methods for returning Median, Min, and Max levels in a small buffer. During stop(), the thread is interrupted which makes it stop. This code can also be used in LinearOpModes by starting, reading, and interrupting the thread at appropriate times in the runOpMode method.

I tested this informally and never saw readings of 0. It seemed to give stable readings when the reflection surface was large. I would still occasionally see readings of 255 when moving my hand in front of the sensors, but this may be because the actual ultrasonic ping wasn't received cleanly.

Thanks again, Steve, skatefriday, and Team25 for the insights and code!

[skatefriday]

The most likely reason you are getting bad values from the legacy ultrasonic is because of a design "deficiency" in the LEGO ultrasonic sensor itself. Read requests sent to the sensor must be at least 50ms apart. If a second read request is received by the sensor less than 50ms from the previous read, then bad data will be returned. This is a known issue with the LEGO sensor and in NIs implementation of the Ultrasonic block for LEGO NXT-G there is code that saves a good read value and if a subsequent read fails then the last good known value is returned to the user, masking the problem in the NXT. When you first plug in the sensor or start your program and reference to ultrasonic sensor port, leave a period of time for the sensor to “settle”, at least 250ms before issuing the first read command.

After struggling to get reliable data ourselves I did some googling and found the
datasheet for the US sensor and discovered that it has a single shot mode which
makes it possible to control when it pings. Note that the sensor's default mode
is continuous. Neither RobotC, nor the SDK supports turning off the sensor, so
as soon as it has power it will ping constantly.

https://github.com/TKJElectronics/NXTShield/blob/master/Appendix%207-LEGO%20MINDSTORMS%20NXT%20Ultrasonic%20Sensor%20I2C%20communication%20protocol.pdf

We then implemented a driver that supports single shot mode.

https://github.com/cmacfarl/FTC-Team-25/blob/swerve/java/team25core/Team25UltrasonicSensor.java

Note that when you ping, as Steve suggests you should wait for the result after a
call to doPing() before reading the distance data.

[Steve Barker]

The most likely reason you are getting bad values from the legacy ultrasonic is because of a design "deficiency" in the LEGO ultrasonic sensor itself. Read requests sent to the sensor must be at least 50ms apart. If a second read request is received by the sensor less than 50ms from the previous read, then bad data will be returned. This is a known issue with the LEGO sensor and in NIs implementation of the Ultrasonic block for LEGO NXT-G there is code that saves a good read value and if a subsequent read fails then the last good known value is returned to the user, masking the problem in the NXT. When you first plug in the sensor or start your program and reference to ultrasonic sensor port, leave a period of time for the sensor to “settle”, at least 250ms before issuing the first read command.

[stian]

Update: doing lots of testing, lego sonar on legacy will not only toss some erroneous values, it will also 10-20% of the time on startups exhibit its own version of the various USB failed-to-map problems the new system has. In this state, the legacy module and the sonar never seem to "pair" and you get a stuck value between 0 and 255 (and not always 0 or 255). Which is also bad for autonomous software. If you unplug-plug the sonar, it will tend to recover the situation, so the kids added a readout during init_loop so they could tell if this sensor connection didn't happen. Doesn't fix the erroneous 0's or 255's that come off the thing when it *is* "working" but at least makes it sorta usable.

this coach is missing lego FLL a bit right now...

Our team has been experiencing similar problems. Does anyone know why this happens/how we could fix it?

[zain]

Update: doing lots of testing, lego sonar on legacy will not only toss some erroneous values, it will also 10-20% of the time on startups exhibit its own version of the various USB failed-to-map problems the new system has. In this state, the legacy module and the sonar never seem to "pair" and you get a stuck value between 0 and 255 (and not always 0 or 255). Which is also bad for autonomous software. If you unplug-plug the sonar, it will tend to recover the situation, so the kids added a readout during init_loop so they could tell if this sensor connection didn't happen. Doesn't fix the erroneous 0's or 255's that come off the thing when it *is* "working" but at least makes it sorta usable.

this coach is missing lego FLL a bit right now...

[zain]

You know. I feel like I'm seeing the same kind of thing helping the kids debug stuff. The are using regular opmode. But even so, it seems like there a instances where a value or mode isnt updated when you think. I wonder if some of these method calls are not blocking properly and somehow need time, or a whole loop cycle, to be valid? And if you read or try to use them right away they are not yet "done?"

[korimako]

We've used both the maxbotics & lego sensors successfully in the past. I have to agree that in the FLL/NXT world these sensors were very well behaved - if you have a nxt brick still available, hook it up and you can read the output without any programming involved. They were very reliable for us during the past two seasons with HiTechnic platform.

After figuring out the hard way that the linear op mode needs 1,2,3..several cycles to clear motor encoders, or reset the motor run mode, I just wonder if there might be some timing issues with these (and other) sensors on the legacy module? Sort of like the multiplexer used to divy up the throughput, so putting a gyroscope on the multiplexer never worked as well. Just my 2c, but maybe someone else can comment with a bit more experience on the new platform?

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.

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

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

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

[ruhul]

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

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

[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

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