Too low update rate with Lidar Lite v3 HP

Help & Support Robot Parts
, , ,
1

Product: https://buy.garmin.com/en-US/US/p/578152/pn/010-01722-10#specs

Update rate of Lidar Lite v3 HP, according to instruction manual should be >1000hz. However, I couldn’t make it run faster than 450-470hz. I’m using example code “v3HP_I2C” from garmin arduino library.
Hardware: LLv3HP, Arduino Mega 2560, everything wired according to manual, with 1000uF capacitor close to lidar. Tested with 4,7k, 2,2k and without pull-up resistors on I2C. I have not observed any communication issues.
Update rate testing (2 ways):

  1. using millis() in code
  2. running continuous and timed measurement in original code, calculating number of results given in time of 10s.
    Both methods gave the same results.
    Configuration modes 0,1,3,4,5: 290-360hz
    Modes 2,6: 420-470hz at short ranges.
    Tested indoors, at distances 1-7m with lidar pointing at normal surfaces at small angles. I also tested it with custom configuration mode with 0x02 set to 0x01 (very low acquisition count) and 0x04 set to 0x00 (quick termination on). Results: up to 470hz. But as stated in manual, I should get >1,5khz with small acquisition count settings and using fast measurement algorithm (take range, read previous measurement, wait), which is used in this library. These results are not at all consistent with “rate = 1/n, where n is the number of acquisitions” equation. Disabling fast i2c resulted in speed reduction to 280-350hz. Measuring distance in standard way (wait, take range, wait, read) reduced speed to 200-300hz.
    What is the issue here? How can I achieve update rate >1000 hz with my lidar? Might it be an i2c problem (but connection is stable and if I just take range once and then read the same measurement in loop i can get ~2000hz)?
1 Like
3

Hey @marcelzmarsa,

Welcome to the RobotShop community!

Seems like you have a good setup and…

Did some good tests to figure things out, too.

Considering your last comment about simply reading the value getting you in the 2 kHz range, it seems like the process of creating and providing a measurement is what is slowing you down.

With that in mind, here are a few ideas:

  1. Your target surfaces are either nor very reflective to the IR wavelength used, super reflective but specular and pointing away or some other IR interference is causing an issue, forcing the sensor to create measurement at a slower rate than its maximum.
  2. Your setup of register values are not the right ones for your situation.

On point #1, I assume you’ve tried this against many targets and under many different conditions?

As for point #2, well, I recommend having a closer look in the library from Garmin. It has much information in it concerning settings and methods of use. You may also want to check the datasheet, page 10 (top-right corner). They discuss there how to approach fast scanning with the LLV3HP:

4

Thanks for response.

As for #1 I’ve tried a lot of surfaces: wall, wood, fabric, carpet etc. and different light conditions: sunlight, day, dim room, darkness. No significant differences.
As for #2: On start llv3hp sets all of its registers to defaults. configure(x) changes some of its registers (ones that should affect range and distance). According to manual, the most significant factor here is max aquisition count (0x02). But manual adjustment (in library files, LIDARLite_v3HP.cpp) of that value in the same test conditions gives the following results:
0x01 (1) 470hz
0x02-0x03 (2-3) 460hz
0x04-0x05 (4-5) 410hz
0x06-0x07 (6-7) 390hz
0x08-0x09 (8-9) 370hz
0x10 (16) 310 hz
0xff (255) 310 hz
Conclusion? My lidar does not have to do a lot of aquisitions in order to obtain measurement, so environment is ok and even just one aquisition takes a lot of time. Of course light is fast, so low speed must be caused by

a) takeRange(). but what could go wrong with

void LIDARLite_v3HP::takeRange(uint8_t lidarliteAddress) {
uint8_t dataByte = 0x01;
write(0x00, &dataByte, 1, lidarliteAddress);
}

b)lidar does something time-consuming while measuring distance other than measuring
distance. But what could it be and why does it do it by default so slowly?

Enabling fast termination in registry helps at short distances, but it is still in 300-500hz range.

The fast-scanning applications part of the manual:
That code, from garmin library, does what they want:
// 1. Trigger range measurement.
myLidarLite.takeRange();
// 2. Read previous distance data from device registers.
// After starting a measurement we can immediately read previous
// distance measurement while the current range acquisition is
// ongoing. This distance data is valid until the next
// measurement finishes. The I2C transaction finishes before new
// distance measurement data is acquired.
distance = myLidarLite.readDistance();
//3. wait for being busy
while(myLidarLite.getBusyFlag()!=0);

note: I’ve also tried garmin’s waitforbusy() - same effect.

I’m not sure about that part though:

This method uses slightly more I2C overhead, but it allows more
efficient polling if you know your measurement time, which
depends on maximum acquisition count settings. It also allows
you to know exactly when the measurement begins.

How am I meant to know the measurement time?

Any other ideas? What else could I change in the registry?

1 Like
5

Lots of good stuff here! Good job on all the heavy lifting here support-wise! :smiley:

It seems like the measurement speed issue would be squarely on the sensor itself and not the code or setup you are doing, then.

Please provide the following details concerning your LLV3HP:

  1. A picture showing the label on the side of it. Make sure the writing is legible
  2. Details on when you obtained this sensor

Sincerely,

6

Here they are:

Labels (side, back):

IMG_20200523_171652
IMG_20200523_1716523968×2976 2.36 MB
IMG_20200523_171516
IMG_20200523_1715163968×2976 2.83 MB

Purchased 22.05.2019 (I know it is a while ago, but other parts of my project had to be completed earlier)

1 Like
7

Hey @marcelzmarsa! Thanks for the great pics and details.

It is quite possible you have an issue with the physical filters in your sensor. There were some issues with some batches of this product stretching quite far back. Those issues were completely resolved late last year but unfortunately many batches were produced that have problems similar to what you are describing.

If you purchased this product through RobotShop please let me know and I will convert your forum topic to a support ticket to see if an RMA is possible (it has been over a year by a few days only, maybe something can be worked out). If not from RobotShop, please contact your supplier concerning this issue to obtain an RMA.

Sincerely,

8

I was thinking of ordering this device but on your forums there was a product post some batches were defective

It is quite possible you have an issue with the physical filters in your sensor. There were some issues with some batches of this product stretching quite far back. Those issues were completely resolved late last year but unfortunately many batches were produced that have problems similar to what you are describing.

If you purchased this product through RobotShop please let me know and I will convert your forum topic to a support ticket to see if an RMA is possible (it has been over a year by a few days only, maybe something can be worked out). If not from RobotShop, please contact your supplier concerning this issue to obtain an RMA.

I just want to make sure the ones you currently stock do not have this defect ?
thanks