Trouble measuring distance


#1

I have the following setup, which uses two JSN-SR04T waterproof ultrasonic sensors:

image

image

Using the following code, each individual sensor takes 21 measurements, sort the results, and select the median value.

   for (i=0; i<21; i++) {
        digitalWrite(TRIG1, LOW);
        delayMicroseconds(2);
        digitalWrite(TRIG1, HIGH);
        delayMicroseconds(15);
        digitalWrite(TRIG1, LOW);
        d1[i] = pulseIn(ECHO1, HIGH);
        d1[i] = d1[i]/58;
        delay(50);
        }    
    for (i=0; i<21; i++) {
        digitalWrite(TRIG2, LOW);
        delayMicroseconds(2);
        digitalWrite(TRIG2, HIGH);
        delayMicroseconds(15);
        digitalWrite(TRIG2, LOW);
        d2[i] = pulseIn(ECHO2, HIGH);
        d2[i] = d2[i]/58;
        delay(50);
        }
    d1len = sizeof(d1) / sizeof(d1[0]);
    d2len = sizeof(d2) / sizeof(d2[0]);
    qsort(d1, d1len, sizeof(d1[0]), sort_desc);
    qsort(d2, d2len, sizeof(d2[0]), sort_desc);
    fd1 = d1[10];
    fd2 = d2[10];

The device is located 140cm above the ground, at a 52-degree angle - the maximum distance it should measure (empty container) therefore would be around 230cm. I’m really struggling with getting these things to detect anything though - they return distances as high as 300cm even when there are a bunch of bags inside the container. When I test it indoor at a flat surface it seems to fine, but anything else seems to return subpar results.

Is there anything I’m doing wrong? Would the code above lead to cross-interference from the two sensors?
Or is the sensor just not up to the task? This is virtually the only usable sensor for me, as virtually all other ultrasonic sensors aren’t waterproof.


#2

If you’re getting good results in a controlled environment (indoors on a flat surface) I would think your code is fine. I would take that control environment and mix it with your container, meaning take a flat piece of material, put it a known distance from the sensors inside the container and see what you get.

Is there any chance your bracket is moving while it is taking readings? I know it wouldn’t move 70cm, but it might mess with your readings.


#3

Are the cheap sensors just not that good performance wise?

What kind of reviews do these sensors get from what you have seen online?

The metal container may be causing the wave to bounce and which provides the wrong readings.

Have you tried this with the more expensive sensors in the same fashion?


#4

Ultrasonic sound waves propagate in a very directional way (that’s why they are used) and also reflect that way, so when your “sound beam” hits a surface non-orthogonally the reflection will not return to your source back the same direction it came in from.

Also reflection on a soft surface is considerably dampened if the impulse isn’t even absorbed completely.


#5

Are you using the original or 2.0 board? If 2.0 then I saw there was some problem with it. Have a look on youtube for don’t buy JSN-SR04T-2.0


#6

Well, one thing I know for sure will happen is that the metal walls of the container will create a tremendous number of ECHOs, so my first course of action was to decrease the ping frequency to let those ECHOs dissipate first. Perhaps there’s another factor in play that I’m unaware of.

The bracket shouldn’t move - it’s tightly secured onto the wall of the container, so it can’t move.

They’re cheap sensors indeed - unfortunately they’re also the only ones that are weatherproof and aren’t super expensive. The readings tend to over-estimate the distance a lot - e.g. I am expecting a 100cm reading, but instead I will get readings ranging between 180 and 250cm. Very infrequently, it does report the accurate range, so I’m considering letting it take a lot more measurements (I do 21/sensor right now) and try to find a way to filter out the correct one. I haven’t tried using the more expensive sensor with this as frankly, it just wouldn’t be a cost-efficient device anymore with them.

I understand if a surface is flat, and the signal hits it at an angle, it will bounce away from the sensor - however, with waste bags, shouldn’t at least part of the signal be reflected straight back into the sensor? Is this ECHO signal too weak to be picked up on by the sensor? When I test this sensor indoor at random objects, it usually tends to work fairly reliably.

Yes I’m using the 2.0 board. I do recall seeing some criticism on that particular board as well, although this sensor isn’t well-documented and I’m not sure what the actual differences are. I have both the regular and 2.0 boards, and I couldn’t spot any notable differences between the two in controlled-environment tests.

I believe a lot of criticism about this sensor also stems from the fact it is being promoted by some vendors as a 3 to 5.5V sensor, but it really does need at least 5.0V to take its measurements correctly.

My plan for now - increase the readings from 21 to 50. Instead of selecting the median value, selecting the lowest-value, as I find the sensors rarely under-estimate a distance.


#7

Here’s a graph showing the outcome when I translate the sensor readings into a fill-rate (0 to 100%) of the container (taking into account container dimensions, device height etc.). The actual fill-rate in this container started off around at about 30-40% yesterday morning, peaked at 90-100% this morning, and was just emptied (so 0% currently). Measurements are taken once an hour between 7am and 5pm (one at 12am)

Looking at it, only a few accurate measurements were posted - the one at 11am (23%), 3pm (48%) and 7am this morning (92%). The rest is considerably under-estimating the fill-rate.

So what I can conclude so far, is that the sensor CAN detect the bags and can be used to approximate the fill-rate of a container, but the reliability is pretty poor.


#8

Just a thought - have you looked at the current draw on Vcc when it is operating and are you sure that the power supply can support the current. In others words, in your controlled test were you powering the sensor from a USB port or PSU and are you in this case using a battery? The transmission of the pulses requires a high voltage which why there is a step-up transformer on the board.

Of course it could be that the ultra sound sensor is being defeated by the environment you are asking it to work in. There is a new dedicated IC to drive these types of transceivers - PGA460 - which I understand can give you a lot more information about what it is seeing than just distance via serial or I2C interface.


#9

It should be fine - the battery I’m using can handle up to 3A peaks. The sensors are connected to the 3V3 pin, where I’m using a step-up booster to convert it to 5V (max. 350mA). Besides these two sensors, nothing else is hooked up to this booster.


#10

As you’ve said, off-target reflections only increase the distance. They never reduce the measured distance.
Modify your code to concentrate on the shortest measurements in each series of range events, not the median…and give it a try.


#11

I guess it technically could be possible if the interval between pings is too short - and the ECHO from the previous ping is still bouncing around the container and hits the ultrasonic sensor - but I guess that’s easily mitigated by not making it send pings too fast.

I had some materials come in today so I can make another 10 of these devices - so it will be very interesting to analyze all that data soon :slight_smile:


#12

Which 3V3 pin? I thought that was only good to source 100mA!


#13

That’s the figure for the Photon.
For the Electron the docs state


#14

@vitesze - have you managed to get the readings accurate? I was curious about using this sensor for another use and ordered one to try it out. From some very initial testing I have noticed that the ultra sound is absorbed by certain materials - office carpet, soft furnishings, etc. and more so when measuring non orthogonally. So as @scruffr explained the ‘odd’ readings could be down to the soft plastic bags not reflecting the sound waves.

A couple of thoughts how you might overcome these constraints for your application.

  1. Try separating the 2 sensors and have them “look” at different angles and on different walls of the container. Use the reading that is most relevant or use both (see idea 3).
  2. Try processing the readings with a linear regression algorithm or another suitable statistical method that would ignore or un-weight out lying readings.
  3. Try using a ML technique to the readings (linear regression is one) to categorise them into fill level. The more sensors you have and the more ‘training’ you can do the best the results will become.

Linear regression or even double linear regression is something that can be feasibly run on the electron. Other techniques can be used as well but I can’t confirm as I have not yet ported any from python to C for use on the particle devices - they certainly have the CPU power.


#15

@armor Funny you ask, I was just about to get started on the reading-accuracy today - I take about 20 readings right now per ultrasonic. A lot of the time the signal bounces away from the sensor so I get bad readings, so I sort out all the readings and take the closest recorded one (as by nature it’s almost impossible to have it underestimate the distance).

For sure it’s possible to make it work - although I’m looking for some ways to optimize it further today without having it take an infinite amount of readings. I wouldn’t recommend using this sensor when the readings are critical (e.g. human safety, or when measurement accuracy is otherwise very important) as you’re probably better off with one of the devices from MaxBotix.


#16

The beauty of MCUs and digital signal processing is that you can turn cheap sensors into very effective sensors!


#17

I can no longer find the reference, but in a nutshell there is a good analysis floating around which shows that in a rectangular room the total energy received at the sensor is far higher from secondary reflections than the primary one. Basically, the energy hits the walls and makes its way back to the sensor. It’s spread out and delayed, so you want to

  • have the minimum power you need to get a primary reflection
  • use a threshold so that any later reflections are rejected
  • increase time between measurements to allow for all reflections to die down
  • ensure that if you have multiple sensors that each sensor wait its turn before emitting. (This is a frequently overlooked nuance when doing active sensing.)

#18

@Vitesze How are things going with the project?


#19

Pretty well - I spent the last few days getting used to PCB design in Eagle, so today I’m finally creating my PCB again from scratch. It’s pretty essential for me to go with a PCBA service if I want a larger quantity of this device :slight_smile: Fritzing wasn’t so suited for that purpose.


#20

Cool.

What made you choose Eagle over KiCad?