Quite inaccurate LiDAR Lite V3 measurements

[mateo_glowinski]

Hi,

some time ago I’ve bought a [LiDAR Lite V3HP and I made it work by using the code from [here.

I’m trying to measure a distance between sensor and movable part of an automatic external blinds.

See picture:

.

In this position it is quite inaccurate (around +/- 6cm), which is 3 times higer than in documentation.

It’s connected to the RaspberryPi Controller via [QWIICBus Kit, but even without this extender the distance reads are quite disparate.

I’ve tried to attach various types of materials to the bottom of the blinds, such as white paper, grey paper, cardboard, milk-colored plexiglas, gray plexiglas, milk-colored plexiglas. Best result I’ve got with cardboard.

See picture:

Question is: Do you have some idea how could i improve the distance read or maybe idea for more accurate sensor working on I2C bus?](SparkFun QwiicBus Kit - KIT-17250 - SparkFun Electronics)](https://files.pythonhosted.org/packages/08/aa/681899b1b5f93cb04d31b190a0b0d60aeed321b95110d8e045e3a0bec8a9/LiDAR_Lite-0.1.0.tar.gz)](https://www.sparkfun.com/products/14599)

[KansasBot]

There are several things I would consider in troubleshooting this system. Can you provide more information for the questions below?

1. How are you setting up your control measurement? Is it from the ground, base of the lidar, or edge of the lidar? I can’t tell if the lidar is “on” the ground, flush with the bottom bar, or is above the bottom bar.

2. Are you able to control the slant of the measured surface? I see it at a slight angle, but this could cause a very negligible error.

3. How are you sampling the data values? Are you using example functions found [here? Are you doing single measurements or are you taking averages of set sample sizes?](LIDARLite_Arduino_Library/examples/v3HP/v3HP_I2C/v3HP_I2C.ino at master · garmin/LIDARLite_Arduino_Library · GitHub)

[jremington]

Averaging a bunch of measurements should help a lot, and does not take that much time. Try with 100.

[mateo_glowinski]

KansasBot:
There are several things I would consider in troubleshooting this system. Can you provide more information for the questions below?

1. How are you setting up your control measurement? Is it from the ground, base of the lidar, or edge of the lidar? I can’t tell if the lidar is “on” the ground, flush with the bottom bar, or is above the bottom bar.

2. Are you able to control the slant of the measured surface? I see it at a slight angle, but this could cause a very negligible error.

3. How are you sampling the data values? Are you using example functions found [here? Are you doing single measurements or are you taking averages of set sample sizes?[/quote]

1. LiDAR Lite is mounted to the bottom bar.

See picture:

I don’t understand second part of the question.

Is there a setting that allows me to choose whether the measurement is from the bottom or the top of the sensor? If so, I have that setting as default because I haven’t changed it.

2. No, i don’t. The angle is always the same. I’ve checked that and in my case it does not have almost any impact (+/- 1cm which is acceptable).

3. No, but I’m using quite similar functions from [here.

My project is running on RaspberryPi4, not on Arduino.

I’m taking average from set of samples.

Here is my function:

    def get_distance(self, retrigger_count=10) -> int:

    distance_sum = 0
    for _ in range(retrigger_count):
        self.write_reg("ACQ_COMMAND", 0x04)
        self.wait_until_not_busy()
        distance_sum += self.read_reg2("FULL_DELAY")
        time.sleep(0.01)
    return int(distance_sum / retrigger_count)

](https://pypi.org/project/LiDAR-Lite/#files)](https://github.com/garmin/LIDARLite_Arduino_Library/blob/master/examples/v3HP/v3HP_I2C/v3HP_I2C.ino)

[mateo_glowinski]

jremington:
Averaging a bunch of measurements should help a lot, and does not take that much time. Try with 100.

Thanks for a tip, I’m already doing that for 10 samples.

100 is too much in my case, since the measurement will be distorted when the blinds move.

[mateo_glowinski]

I’ve checked I2C signal with oscilloscope and everything seems to be fine there.

Nevertheless, real distance is 80cm and LiDAR is returning 74.

[mateo_glowinski]

Here is more accurate oscilloscope graph:

[mateo_glowinski]

I have noticed that just after reboot the distance reading are quite fine.

They are more divergent after the passage of time in which LiDAR works. Is there a setting that could affect this behavior?

[KansasBot]

mateo_glowinski:
I don’t understand second part of the question.

Is there a setting that allows me to choose whether the measurement is from the bottom or the top of the sensor? If so, I have that setting as default because I haven’t changed it.

I was intending for where you’re placing the beginning of your measurement distance. For instance, if you put a physical ruler on the system, where is your ruler’s edge lined up.

The datasheet doesn’t seem to clarify at all unfortunately. I would reasonably assume that the beam is initially calculated at the exact distance of absorption with the optical receiver underneath the lens. However, most likely the processing unit accounts for this offset without reporting it in the datasheet. I would double check your comparative measuring setup.

Also double checking the datasheet, for distances <2m the typical error margin is +/- 5cm and at distance >2m the error margin is +/-2.5cm. At what distance ranges are your readings the most inaccurate?

As for the drift you’re suggesting, I would recommend probably reaching out Garmin because that’s probably above SparkFun’s head since they didn’t design this product.

[mateo_glowinski]

I was intending for where you’re placing the beginning of your measurement distance. For instance, if you put a physical ruler on the system, where is your ruler’s edge lined up.

I assumed it was a LiDAR lens.

I would double check your comparative measuring setup.

What do you mean:)?

If you are asking about register values, I set them like in the code, which you have sent for Arduino.

SIG_COUNT_VAL → 0x1D

THRESHOLD_BYPASS → 0x00

Also double checking the datasheet, for distances <2m the typical error margin is +/- 5cm and at distance >2m the error margin is +/-2.5cm. At what distance ranges are your readings the most inaccurate?

I'm totally fine with +/- 5cm discrepancy, but problem is that measurement changes within time.

Friday afternoon it is 100cm, Monday morning it is 90cm.

The most inaccurate readings are at 70cm distance.

As for the drift you’re suggesting, I would recommend probably reaching out Garmin because that’s probably above SparkFun’s head since they didn’t design this product.

I've already contacted Garmin last Monday, but they did not reply yet. I will write here, if i get response from Garmin team.

[wiseman]

When powered, the LIDAR-Lite v3 performs a zero range calibration using an internal optical path of known length. This same zero range calibration occurs automatically after some number (around 50?) distance measurements. This goal of this ongoing measurement strategy is to avoid the drift in position estimates that would otherwise result from changes in temperature of the hardware. Most applications will hit 50 measurements in under a second because they are continuously measuring distance.

[mateo_glowinski]

In my case reading were a lite bit improved by:

1. disabling reference filter (bit 4 in ACQ_CONFIG_REG)

2. using reference acquisition count from REF_COUNT_VAL (bit 2 in ACQ_CONFIG_REG)

3. setting reference acquisition count to max value (REF_COUNT_VAL to 0xFF)