Slightly unexpected behaviour from ultransonic sensors

Submitted by lars_the_bear on Tue, 03/01/2016 - 14:55

Forums:

Hi

I've just taken delivery of an Ultraborg (thanks) and sensors. I'm using a simple C program to poke the I2C bus and I'm reasonably sure I'm doing it properly (but not certain). I'm sending a byte between (decimal) 41-44 for sensors 1-4, and reading three bytes, of which the second and third give a time in usec. Following your Arduino example, I multiply this by 0.17 to get a distance in mm.

So all the sensors are pointing at a brick wall about four feet away, and all are showing distances of 1100-1300 mm, which is believable. But...

1. Every so often, one of the sensors will return a time value of 0xFFFF. I note in your Arduino code that you recognize this possibility, but what does it signifiy? I don't really understand why a completely stable condition would result in occasional odd measures. I tried swapping the sensors around, and it doesn't depend on the sensor; but it does depend on the order I poll the sensors. I'm polling all four in a batch at intervals of, say, 200msec, and it's generally the first one in a batch that goes astray. Incidentally, some channels that have no sensor connected occasionally return an 0xFFFF as well, although usually they say 0.

2. Generally the reported distance decreases as the sensors get closer to the wall, but closer than about 60cm and the readings start to go up, rather than down

3. There's a fair amount of variability (+/-50mm or so at a distance of > 50cm) between readings on the same channel.

I don't think any of this is particular problematic for my application, but I'm concerned that I'm doing something wrong.

Comments welcome.

Best wishes
Kevin

piborg's picture

piborg

Wed, 03/02/2016 - 11:13

From the sound of it the code you have written is all working.
I would expect most of this to be quirks with how the sensors and UltraBorg actually work.

  1. This is usually caused by the Raspberry Pi trying to read the reply data too fast from the UltraBorg.
    I would suggest putting a small delay between the write and read calls for the I2C bus.
    The reason you see 0xFFFF specifically is because the PIC on the UltraBorg missed the signal to start transmitting and did not put any out on the bus
  2. I cannot be entirely sure about this, but the problem may be related to echoes from other objects.
    The sensor effectively puts out a cone of sound, this can hit objects to the left or right of the sensor, reflect back towards the sensor and give odd readings.
    This problem also occurs if the object is at an angle from the sensor so that the sound does not bounce directly back to the sensor.
  3. Unfortunately this type of ultrasonic sensor is actually fairly noisy and do move around a fair amount.
    If you try the commands to read the unfiltered values (1 to 4) you can see just how noisy the sensor itself is.
    While the filtering done by the UltraBorg does help it cannot remove the problem entirely.

On a slightly different note are you using an external power supply, or are you using the 5V link jumper?
I ask because the sensors will work at voltages other than 5V, but they seem to get less stable the further from 5V the supply is.

lars_the_bear

Wed, 03/02/2016 - 13:48

Hi

Thanks. I will try the delay tactic. Are we talking about microseconds, here? Or seconds? I guess more like the former. I note that there is no delay (so far as I can see) in the Arduino code, but maybe the Raspberry Pi is faster to read from i2C than the Arduino would be? I note that the Arduino code has a check for 0xFFFF, so I guess the problem must have been noticed there as well.

Right now I'm using the 5V link, but in due course I will be using a separate 5V supply.

I am rather hoping to be able to get distance readings repeatable enough to be able to adjust the motor speed on approaching an object, rather than just stopping completely at a particular threshold. If that isn't possible, that's not the end of the world. However, I note that one of your code examples seems to do this (measure the approach speed, I mean) so I guess it should be possible.

Best wishes
Kevin

PS. Because the sound dispersion from the transducer is 15-20 degrees (according to the datasheet), I'm assuming that mounting position isn't terribly critical. That is, I'm assuming it doesn't make much difference whether the sensor is two inches off the ground, or ten inches. But am I dead wrong about that? Do you have any experience with testing this?

piborg's picture

piborg

Wed, 03/02/2016 - 14:13

We are talking microseconds, milliseconds in the worst possible case.

From memory the check is in the Arduino code as a 'just in case', but I am not sure if we actually saw a problem when using the Arduino.

With the Raspberry Pi the write call can return before the I2C has actually sent, causing the write and read to be buffered back-to-back.
This should not really be a problem, but there are two 'bugs' with the I2C driver on the Raspberry Pi:

  1. It does not seem to work with clock stretching enabled.
    This means we can not get the I2C bus to wait until we are ready.
  2. On occasion the I2C messages are written to the bus without a proper gap between the two.
    This can either cause the UltraBorg to miss the second message (the read) or simply it is not ready to respond and fails to send any data back.
    If you have an oscilloscope you can see this by looking at the SDA and SCL lines.

As for the ground a couple of inches should be fine.
I know we have used our mounts with the plate screwed to a table when testing the UltraBorg in the past.
The trouble tends to be more focused around the measured surface facing slightly downwards such that the return echo hits the ground and then the sensor, causing a longer delay than normal.

What we have seen before is some materials let the sound through and then had another echo later causing confusion.
For example measuring an empty plastic jug we would occasionally see readings from the other side of the jug.
This is basically how the ultrasound machines work after all.
A nice solid brick wall should not really have that effect though.

Subscribe to Comments for "Slightly unexpected behaviour from ultransonic sensors"