False-positives on bumpy roads

[gluap]

When driving on a (even slightly) bumpy road both side ultrasonic sensors measure false-positives with a random distance even when no obstacles/cars are in sight - at least with our subset of two OBS devices in the household behave like this. They are mounted on two very different bike models (one recumbent one cargobike). My working hypothesis is that the bumps lead to high frequency vibrations either in the bike or in the OBS mount which in turn trick the sensor into thinking it has received an echo. The problem is that on a bumpy road with cars overtaking one can never be sure whether the minimum distance measured is a false positive or an actual overtaking event.

A suggested remedy would be to only accept distance measurements if two consecutive measurements do not differ by more than some ε - say 10cm or so. As the false-positives are random, chances are small that two consecutive random values will fall into one ε interval, whereas real measurements are expected to not deviate by more than a few cm within 1/20th of a second.

Video of the issue - Be aware that the road is not actually very bumpy and the bendy shaky look of my handlebar comes from the video de-shake. My hand holding the camera wasn't very steady and steadying the video makes the display readable but also lets it look like the handlebar is deforming horribly. The road was asphalt with minor bumps of 1-2 cm at most.

This is already the case with 0.7.596 and probably not related to #262

[amandel]

@gluap - can you try to put something between the 2 tof-sensorboards so that they can not change the distance to each other when the road gets bumpy. I used a end of a zip tie and placed it between the boards (don't push to hard). Might be this helps - might be the cause is different.
BTW: The value displayed is already the media of the last 3 measures. Plan is to get a better filter based on the raw data (each measurement) stored in the csv file.

[gluap]

@amandel I have wedged the two sensors against each other now, but the problem persists. I can also demonstrate that the device reacts to sounds by scraping the outside of the OBS case (not the actual ultrasonic sensor of course!) with a screw while it sits firmly on the table. (I could imagine that some are reluctant to do this to theirs so I'll upload a video later edit: here).

Regarding the media displayed by the sensor currently. If these are media of three values, it may make sense to also compute the standard deviation and reject media of value sets that exceed a certain threshold standard deviation- on the grounds that a median of vastly different measurements is problematic in any case in the presence of noise. Alternatively one could increaseMEDIAN_DISTANCE_MEASURES to increase the time span over which the mean is taken. This could be argued on the assumption that noise due to bumpy road will only be present for short intervals of time and medianing over long intervals can compensate for it.

edit: After reading the code I noticed that I read "mean" instead of "median" at first. Adapted the text to discuss median.

The problematic case is the case of multiply noisy values - If only one measurement is noise the median will be able to compensate for it. But as soon as two noise values fall into the three-bin median, one of the noise values is the output of the median function. I'd argue that the noise values always have a shorter distance value than the real measurement. Once the actual echo is detected the measurement is over and no signal misinterpretation will happen after the echo has been received.

The problem worries me because the overtaking distance displayed for the left sensor is (if I understand the process correctly) taken as the minimum distance measured over 5 seconds - therefore any valid measurement that has noisy medians inbetween the overtaking and the button press will have a chance of displaying (and recording) some arbitrary, shorter overtaking distance. While this can be filtered in post, users will look at their display and - think "whoah that was close". They will also look at their sensor on the open road with nothing to the left and worry that their device may be broken if it displays a random overtaking distance.

Of course much more number gymnastics can be done in postprocessing of the csv. But for laymen using the sensor I guess it is also important that the sensor displays plausible values.

final edit: sorry for editing this so heavily ;)

[amandel]

Thanks for all the details! Better than a filter is to find a way not to get these false measurements at all. For me I only see this measures if a tram or very loud motorcycle is close to me. Please note that I consider this different cases:

• vibration
• sound

For me - I could mitigate false measurements likely caused vibration, by stabilizing the 2 sensor boards against each other as described above.

In the software we can increase the median 3 to be a median 5. We can also "reset" the collected values in the median buffer to not hold values below the currently measured values (wrong measurement values are always below or equal to the real value, never > ). But before getting fancy with the software filter we should try to eliminate the hardware effects as far as possible.

I've to concentrate on one aspect at a time - so lets try to find a way against the false measurements you see in 0.8 and not in 0.7. (Un)fortunately I do not see this effect so your input is very valuable there too.

[gluap]

@amandel unsure if i was unclear about that: the demo video scratching the case is with the sensor boards stabilized according to your description. I believe the false measurements on bumps can are actual ultrasound picked up by the piezo which I attribute to creacking in the bike frame and the OBS mount and transferring via solid matter to the pickups. The issue may depend on the bike at hand (tire inflation, suspension or not). It may also depend on the sensor sensitivity.

I can repeat the demo with a long sensor cable and the sensor in another obs case to exclude board vibration in case there are doubts whether the false positives come from board vibration or piezo signals.

No hurry though, I fully agree to do one issue at a time and #262 is clearly more pressing.

If the issue is piezo- or bike dependent it may also make sense to have it adjustable (the number of samples for the median or the noisy measurement threshold)

[gluap]

I have now experimented a bit and my feeling is that the "harder" the bike is, the more of this noise I get. With less air in the tires the noise gets less. Saddlebags attached to the bike rack (with obs on bike rack mount) - Increases the amount of noisy measurements (also audible noise). Rattling bike lock attached to bike frame - More noise.

Measurements were done with latest 0.8.x release.

While I still think an adjustable software filter would make things better I'm going to experiment with dampening. My gut feeling is that a bit of rubber should damp the sound frequencies used by the ultrasonic sensors substantially.

[amandel]

When trying to establish a software filter. you can use the raw measurement data which is also stored in the csv file. There had been plans to synchronize recordings with video to be able to see and analyze the recorded measurements in context. I'm not aware of progress in this area.

For sure I would prefer, if it is possible to adjust the hardware (dampening). As explained earlier I could get rid of a mayor part of false measurements caused by vibrations by making sure that the boards can not move against each other.

[gluap]

I tried wedging them as you describe to no avail. I also tried aluminum foil shielding. Do you consider that this has to be an electronic effect of interference between the boards? One could test disabling one board then. I've seen some cases of electronic interference when sensor cables were running close to the inductance of the other sensors board. Same when the power cable was routed near or around the sensor boards. But these were avoidable by canle management.