Various false readings from Lego ultrasonic in legacy module

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

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?"

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

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

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

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

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

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