Lidar lite v3 offset value issue

Iron_Donkey · November 13, 2018, 5:11pm

So I tried flying my quad yesterday with the lidar lite v3 on it, I had no issues flying it last week but then when I tried to fly today, I started getting the “bad LiDar health” message again, and my quad started rolling and pitching violently on it’s own, almost like I was slamming the controller sticks and then releasing them. I had to flip to stabilize mode and land it, and once I unplugged the Lidar and switched the lidar type to “0” in the params, I didn’t have that issue again.

It was super weird, I hadn’t had this issue before

rmackay9 · November 14, 2018, 1:29am

@Iron_Donkey,

If you have a log that would be great. If not… I’m afraid it’s all guesswork.

Iron_Donkey · November 14, 2018, 6:03pm

I’ll try and get a log for you here in just a bit!

Iron_Donkey · November 14, 2018, 6:59pm

hey @rmackay9 here is the flight log (I believe) from that flight where the aircraft got crazy with the Lidar and bad lidar health message, I can see that I flipped to stabilize during the flight so i believe this is one of the correct logs. Let me know what you think

rmackay9 · November 15, 2018, 2:27am

@Iron_Donkey,

Thanks for the logs. It looks like it switched to the secondary EKF and then back to the primary within a couple of seconds. The image below shows the desired and actual roll and pitch and the moments that the switches happened (the left edge of the red “Err: EKF_PRIMARY” messages).

In the first EKF switch it looks like the desired pitch changed from -4.62 deg (i.e. leaning forward) to +5.40 degrees (leaning backwards) so a total desired change of about 9degrees. The pitch controller looks like it overshot the request by about 7degrees.

On the switch back it is a bit worse with the desired pitch changing by about 12 degrees but the controller overshot by about 17degrees (i.e. pitch angle went more than twice as far as it should have).

A few questions come out of this:

why did it switch EKFs? We will need to as @priseborough or another EKF expert (if we can find one) to tell us this. By the way, worst case it is possible to turn off one of the EKF cores by setting the EK2_IMU_MASK = 1 as described here on the wiki although I wouldn’t recommend it immediately.
test EKF switching in Loiter mode to make sure we handle it as best we can.
test this vehicle’s pitch tuning under more extreme disturbances. Could you try flying it around more aggressively (especially in pitch) to make sure that it can handle it OK?

By the way, I think it’s not important but to ensure the EKF isn’t using the range finder I think it would be good to set EK2_RNG_USE_HGT = -1 (the default)

Max_Drougge · November 15, 2018, 8:34am

Do you think this is something that will get fixed in the near future or should I just simply buy another LiDAR? If so, do you recommend any in particular?

Iron_Donkey · November 15, 2018, 5:35pm

@Max_Drougge I am wondering if I should do the same

@rmackay9 the drone pitches totally fine while flying around, I haven’t seen this EKF issue except for this once while I had the LIDAR enabled, otherwise the aircraft flies totally fine from what I can see.

ppoirier · November 15, 2018, 6:00pm

We will certainly get a fix, it is just a matter of time, there has been a lot of refactoring on rangefinder code recently. Take a look on other sensors on this forum, you will see that some other sensors are problematic as well.

ppoirier · November 17, 2018, 2:13am

I fixed my problem, this is an issue related to bus on the BeagleBone , not on the lidar.
So getting latest master working , I report a steady error of 35 cm
There is no method for correction for the moment and I agree that i would be pretty simple to adapt the existing analog .
If it is really critical for your application you can apply a quick and dirty patch by setting the offset manually , like a 35 cm correction like this
state.distance_cm = _distance_cm-35;
here

github.com

ArduPilot/ardupilot/blob/master/libraries/AP_RangeFinder/AP_RangeFinder_PulsedLightLRF.cpp#L97


}


switch (phase) {
case PHASE_COLLECT: {
    be16_t val;
    // read the high and low byte distance registers
    if (_dev->read_registers(LL40LS_DISTHIGH_REG | LL40LS_AUTO_INCREMENT, (uint8_t*)&val, sizeof(val))) {
        uint16_t _distance_cm = be16toh(val);
        // remove momentary spikes
        if (abs(_distance_cm - last_distance_cm) < 100) {
            state.distance_cm = _distance_cm;
            state.last_reading_ms = AP_HAL::millis();
            update_status();                
        }
        last_distance_cm = _distance_cm;
    } else {
        set_status(RangeFinder::RangeFinder_NoData);
    }
    if (!v2_hardware) {
        // for v2 hw we use continuous mode
        phase = PHASE_MEASURE;

ppoirier · November 17, 2018, 1:15pm

Just tested using the existing analog offset using this patch and it works fine
I submitted a PR so it can be merged to the code

    uint16_t _distance_cm = be16toh(val);
    float offset  = state.offset;
    // remove momentary spikes
    if (abs(_distance_cm - last_distance_cm) < 100) {
        state.distance_cm = (_distance_cm-offset);

Max_Drougge · November 21, 2018, 3:47pm

Do you know when this update will be released?

ppoirier · November 21, 2018, 4:02pm

Here is the PR

huttonsoftware · November 23, 2018, 10:03pm

Try setting RNGFND_TYPE to 21, Max_Drougge.

I had the same offset problem as you, seeing about 9.5 meters on the ground using Lidar-Lite v3 rangefinder with I2C protocol with Ardupilot Copter on a Pixhawk, using RNGFND_TYPE=15. I looked through the Ardupilot source code, and when RNGFND_TYPE is set to 15, it uses some of the settings related to Lidar-Lite v2. RNGFND_TYPE=21 is for Lidar-Lite v3HP, so I tried that and it worked; the offset is around 2 centimeters now. I tried up to 3 meters here in my garage with good results, and I’ll try a test flight soon.

ppoirier · November 24, 2018, 1:12am

The Garmin Lidar Lite V3 has the same functionally as the ‘‘original’’ PulseLight Lidar Lite V2 and it is measure distance in continuous (free running ) mode.
With the V3HP we had to revert to the 2 stage acquisition collct-measure ( like the Pulse Light V1 used to work).
Please note that the V3 can work in 2 stages mode as well, so if switching to HP mode works OK then we might experience time-out issues in the continuous mode.

According to manual to section https://static.garmin.com/pumac/LIDAR_Lite_v3_Operation_Manual_and_Technical_Specifications.pdf
The value of register 0x45 should be 0x14 for 100hz,
in ardupilot lidarlite driver the value is
{ LL40LS_INTERVAL, 0x28 }, // 0x28 == 50Hz ,

In the same section of Garmin tech specification, ther is some info about the the variation of delay that may vary depending on signal strength. So me might be really ‘‘on the edge’’ with the 0x28 value.

huttonsoftware · December 24, 2018, 9:18pm

I’ve tried some flights with the Lidar Lite V3 in the 2-stage acquisition mode. It gives good data most of the time, but the distance measured occasionally drops to zero during flight. I’ve been looking at the health status bits coming from the rangefinder, and when the distance drops to zero, the Invalid Signal Flag bit also goes high. The description of the flag in the V3 manual says "1: Peak not detected in correlation record, measurement is invalid.” I’ve gotten good results so far from checking that flag and not using the measurement if the Invalid Signal Flag is high.

I worry about using free-running mode if it gives an offset of 9.5 meters; an offset that big is an indication of a problem, and I cannot trust it will stay at that value. If a 2-stage acquisition process with a check on health bits works, it may a good way to use the Lidar Lite V3 as a matter of course.

What has other people’s experience with the Lidar Lite V3 been? Is it worthwhile for me to put my code together for a pull request?

iang · April 4, 2019, 10:16pm

Currently working on a copter build using several Lidar Lite V3’s. One for altitude hold on the aircraft and one to measure distances independently. Im running into the same problems described above with a V3 hooked up via I2C giving a reading of 9-10m when it should be closer to 2-3m. Was there ever a solution or permanent fix found?

Thanks

Ian

Hquarter · April 5, 2019, 11:43am

I recently changed my Lidar Lite V2 from pwm to I2c and encountered the offset problem. My observation is that this unit is very sensitive to the supplied voltage. 3.6v resulted in the offset, 3.7v did not result in an offset, 5.1v provided very good results, but 5.2v caused a lock up and continuous display of 0.05

huttonsoftware · May 18, 2019, 8:53pm

I made some modifications to the rangefinder driver in Ardupilot to use Lidar Lite V3 in 2 stage acquisition mode, and with a check to its status bits to avoid sudden drops to zero range, and that seemed to eliminate the offset problem. If there’s interest I can post that code to my pull request on github for other people to use.

Marc_Dornan · May 18, 2019, 9:38pm

Yes please. I have one I am going to use and this seems like a good idea.

huttonsoftware · May 28, 2019, 12:32am

I finished testing my update to the code that uses dual-phase operation and checks the invalid signal status bit for Lidar-Lite V3 and pushed it to github. I put in a pull request with the code update, including plots from testing.

https://github.com/ArduPilot/ardupilot/pull/11424.