Problem with Lidar Lite v3

[bazooka_joe]

***** Related to this topic *****

Hello
I also wanted to add comment about the V3 accuracy at short range.
I am using the different Lidar Lite devices for about 3 years. and I got new devices a month ago that has the 2018/04 date on them.
For strange reason they behaves different at short range. At ranges less then 30cm the readings are very unstable, while they used be be stable at all working ranges on the past.
Attached link to video that I have compared two devices.
Top Plot is Lidar from 2016/09
Bottom plot is the 2018/04
the Scope has been configured to show persist reading of 2 seconeds and you can see the noise on the bottom plot, where the 2018/04 is attached.

What has been changed???

That been tested on at leat 5 “2018/04” and 3 older Lidars.
Also tested on different surfaces, that behaves differently

youtube.com/watch?v=KiBi-CS … e=youtu.be

[scharette]

Hi,

Well, all LIDAR-Lite have issues with measurement readings at very short distances since they have optics configured for mid-long range distance measurements (typical distances are in meters).

As you may realize, without a more complex assembly, one set of lenses cannot be both good for very short distances (i.e. < 50 cm) and also long distances (up to 40 m).

It is possible that some minor improvements to long range distance measurements in the signal processing or optics have made the very short distances worse off.

It is very likely the processing chip and algorithm have changed since the first V3 model was shipped in 2016, but all of this kind of info is proprietary, so your guess is as good as ours.

Sincerely,

[bazooka_joe]

@scharette Thanks for the replay.
In my case i need the short range values, more than the longer range.
btw I also have newer lidars than 2016, I have 2017 lidars that don’t have the issue.
Can’t we get from Garmin the product changes that might lead to that behavior change?

[scharette]

Hi,

We’ve contacted Garmin to request more information about this and we’ll post here again once we have an update.

If you are more interested in short distances, you may want to consider the following instead:

]RB-Pol-332; 0-10 cm/:m]
]RB-Pol-455; up to 2 m/:m]
]RB-Pol-633; up to 4-400 cm/:m]

Sincerely,

[bazooka_joe]

@scharette thanks again.
I actually need both short and long ranges, short is more critical and need to be accurate . the longer is more to avoid hitting the ground while descending wiht the drone and can be less accurate (its AGL Above Ground Level).
The range finder you advised look great, I will check them too, but still need the longer range Lidar too.

[scharette]

I’d recommend using both, then! http://https//www.robotshop.com/forum/images/smilies/icon_smile.gif
You can never have too many sensors*! http://https//www.robotshop.com/forum/images/smilies/icon_biggrin.gif

Here are some notes concerning the LL3 from the manufacturer:

@manufacturer

I suspect that the observations your customer are making may be more coincidental than due to any changes in the LLv3 hardware or software. They may have gotten sensors from a production run that had a small difference in a component tolerance, however we do screen the units so that everything falls within a predetermined performance specification. It’s possible that these may have been on the opposite end of the spec from the units he previously received.

To my knowledge no changes have been implemented in the design since Garmin started manufacturing LIDAR-Lite v3. The observed short-range non-linearity has always been there, although it can vary between units and is partly due to parallax in the optical system. However, this is mainly the result of a signal overflow condition at these distances that introduces variabilities in the correlation record. In other words, in the presence of a very strong return signal, which is typically seen at short distances, can create errors in the readings.

One way to counteract this effect is to simply place an attenuator over the receiver optics. This attenuator can be a piece of electrical tape or card stock with a small, 1mm hole, in it or they can experiment with neutral density filters until they obtain the desired consistency in the readings. Also, reducing the maximum acquisition count (I believe it’s register 0x02) is another way to reduce sensitivity, but this may not be as effective a solution since the sensor already automatically stops taking acquisitions during a measurement when the correlation record reaches maximum signal strength. So, it’s possible for the acquisitions to stop after a count of 1.

Also, there is no factory calibration step in the manufacture of the sensor. This is because the sensors are effectively “self-calibrating”. Every measurement starts with an internal reference step followed by a series of acquisitions that results in a distance reading. The reference not only lets the signal processing know what pattern to look for in the return signal, but also effectively sets a “zero” measurement reference point. While this provides good performance under normal operating conditions, in the case of a strong signal, the results can be affected by that condition resulting in the non-linearities.

We hope those extra details help!

Sincerely,

*: OK, totally not true… but still… you get the idea

[bazooka_joe]

Its helps on some way, saying that the lidars has not been changed.
That is strange… like i Sayed it happens in at least 6 out of 6 sensors I tested (from batch of 20…)
I will ask my supplier to replace my batch, maybe the other batch will be “as before” if it won’t i will probably stop using that sensor…

[scharette]

You may want to try the attenuator or filter trick on the receiver part, though. The goal would be to effectively reduce the signal strength to a level where non-linearity no longer happens. Of course, that would most likely reduce the maximum range.

[bazooka_joe]

I try not to change the device, as you say it may lead to other side effects.
I basically try to understand what has been changed, is that hardware change? or firmware?
In order to check that I have saved the registers from the devices. i found differences on registers that probably should be different (readings) and found differances on registers that I don’t know what they are, because they are not documented.

I did notice that registeres 41 (H=W ver) and 4f (SW Ver) are equal (I got the register number from some github repo, because they are not documented too)
This is partial list of the registers: (Is there a way to attach full file?)
[table] [tr][td]Reg[/td] [td][/td] [td][/td] [td][/td][/tr] [tr][td]41[/td] [td]15[/td] [td]15[/td] [td]HW Version[/td][/tr] [tr][td]42[/td] [td]b5[/td] [td]bb[/td] [td]N/A - Note There is diff here![/td][/tr] [tr][td]43[/td] [td]6a[/td] [td]6a[/td] [td]N/A[/td][/tr] [tr][td]44[/td] [td]6a[/td] [td]6a[/td] [td]N/A[/td][/tr] [tr][td]45[/td] [td]14[/td] [td]14[/td] [td]MEASURE_DELAY[/td][/tr] [tr][td]46[/td] [td]14[/td] [td]14[/td] [td]N/A[/td][/tr] [tr][td]47[/td] [td]14[/td] [td]14[/td] [td]N/A[/td][/tr] [tr][td]48[/td] [td]0f[/td] [td]0f[/td] [td]N/A[/td][/tr] [tr][td]49[/td] [td]92[/td] [td]68[/td] [td]N/A[/td][/tr] [tr][td]4a[/td] [td]60[/td] [td]65[/td] [td]N/A[/td][/tr] [tr][td]4b[/td] [td]10[/td] [td]10[/td] [td]N/A[/td][/tr] [tr][td]4c[/td] [td]0[/td] [td]44[/td] [td]PEAK_BCK[/td][/tr] [tr][td]4d[/td] [td]80[/td] [td]80[/td] [td]N/A[/td][/tr] [tr][td]4e[/td] [td]26[/td] [td]26[/td] [td]N/A[/td][/tr] [tr][td]4f[/td] [td]2[/td] [td]2[/td] [td]SW_Version[/td][/tr] [tr][td]50[/td] [td]2[/td] [td]2[/td] [td]N/A[/td][/tr] [tr][td]51[/td] [td]71[/td] [td]71[/td] [td]N/A[/td][/tr][/table]

[scharette]

See attached image for attachments!

[bazooka_joe]

Now Attached the full register list
Lidar Registers.txt (1.75 KB)

[bazooka_joe]

I am wondering if the issue exist on the HP version. but I don’t have one to check that

[scharette]

Interesting list!
That being said, it most likely won’t do either of us any good and here’s why:

@manufacturer

At the risk of being blunt, if the registers are undocumented it’s probably because they are not relevant to the operation of the sensor by the user. I think we’re going down a rabbit hole that is not going to yield any useful information for this person or materially change anything for them.
Nothing’s been changed with the v3 sensor since 2016 and I can assure them that the performance below 30cm has never been what I would refer to as “stable”. While we try to maintain consistency in performance through our screening process during production, there’s always going to be some difference in between individual v3 sensors, especially in the sub-30cm range.

I can also confirm from our own tests of all the different versions that very short distances will not be reliable. From the information we have available at this time, it really just seems like the non-linear results at very short distances are very much tied to randomness in the various manufacturing processes and will never lead valuable data between batches and therefore should be considered useless.

Of course, you could always map out the results for one sensor against various surfaces and situations, but that seems like a lot of work for data that will be sub-par. We strongly recommend instead using two sensors for your use case: one for short ranges (ex: 4-400 cm, like the RB-Pol-633) and the LIDAR-Lite for the longer ranges.

Sincerely,

[bazooka_joe]

Hi Sébastien,
The issue is that we need the lidar (and used it, so far) between the ranges of 30cm-30m.
The non-linearity is less critical for us.

[scharette]

If that is the case, then the LLV3HP (RB-Pli-17) might be a better fit for you.
It still has non-linearity issues < 30 cm (signal strength too strong ), but it performs much better and typically provides data that is offset in only one direction when at very short ranges (instead of all over the place like the regular LLV3).

[bazooka_joe]

Hello,
Is there new info about the issue?
Does anyone tried the HP vs the regular version?

[bazooka_joe]

Hi Sébastien,
I got an HP Lidar -
Final raw, the HP version doesn’t looks good, even worse in many levels:

• There is still noise in ranges between 10cm to 30cm.
• Even in 50cm reading seems noisier
• For unknown reason there is “pulse” of ~1V for ~50uSec after the PWM pulse. Its on every reading. (I am nut sure how to add picture of that)
• The behavior of the sensor on very close reading has changed. (SCR06) C1 is the HP, C2 is 2018/04 version and C3 is older version Lidar. I am not sure what my Flight control logic will do in that change of behavior.

Do you know if there are more complaints about the Lidar behaviors from other costumers?

[scharette]

Hey,

@Bazooka_Joe

Do you know if there are more complaints about the Lidar behaviors from other costumers?

Actually, you seem to be the only one we are aware of that has such issues at this point in time. Considering the quantity that we sale of these regularly, it would seem like your situation is unique. That being said, most of our customers seem to use the I2C interface, which is far more reliable especially at long distances, where the pulse length becomes quite long.

Here are details from the manufacturer:

@manufacturer

We’ve discussed the LLv3HP PWM voltage spike with our engineers and they couldn’t recreate the problem, but did offer that perhaps there was no driver on the line (unlikely) or multiple drivers on the line (possible) that were causing that spike. But, they didn’t feel it was an issue with the sensor.

In our investigation into the older v3 vs. the newer versions, the only change to the sensor was the addition of a matte finish to the transmit optical tube. We tested the sensors in multiple configurations, (matte in both tubes, no matte, matte only in the RX tube) and saw no change in the sensor behavior vs. the existing design. Aside from that opto-mechanical change, there haven’t been any other updates.

We know that with all versions of the LIDAR-Lite there can be some non-linearity in the measurements below 1 m. With the v3HP we made efforts to compensate for this through hardware/signal processing updates and a factory calibration step. There is a noticeable improvement in this are between the v3HP vs. the v3, but at very short range, <30 cm, there is still going to be some slight variability, under 10cm, despite our best efforts. This is not a problem that is unique to our technology, most conventional optical sensor technologies won’t even provide a reading at these distances or have similar variability, unless they are specifically designed for short-range applications.

We find using I2C that the measurement data is inherently more consistent and accurate than PWM and we encourage users to implement I2C in their designs. In the past for drone applications, PWM was implemented only because the SW drivers for the flight control systems had not been developed or were not entirely bug free. Since then, the most popular flight control systems have drivers that allow the sensors to be used in an I2C mode. My recommendation to this user would be to implement I2C in their application. I would also suggest that if short-range accuracy is the most critical concern, they either add a second short-range specific device to the system or use measurement averaging (if I2C is in use) to improve performance in this area.

In short, the sensor works best above 1 m and the main recommendation is that you should use I2C for more reliable data.

Sincerely,