Servers by jDrones

Lidar lite v3 offset value issue


(Max Drougge) #9

@Max_Drougge, could you try it using Copter-3.6.0 under NuttX? If it works under NuttX but not under ChibiOS then that would point to the Garmin guys being correct.

@rmackay9
I will try this. Is there a guide how to install NuttX?


(Max Drougge) #10

Alright. I’ve tried the sensor with NuttX OS with copter 3.6.0. It’s pretty much the same result, but slightly different values. So I suppose the problem lies else where? However, it seems as the problem must be somewhere in mission planner or the code in the AP since the arduino shows the correct values?


(rmackay9) #11

@Max_Drougge,

Great, thanks for testing that. This makes it clear that it’s not a NuttX vs ChibiOS issue which narrows down the problem to either the sensor itself or the driver.

Do you have a dataflash log of it misbehaving?


(Max Drougge) #12

I just did a test with range from 1 m to roughly 75 cm. 3 1970-01-01 01-00-00.bin (178.2 KB)

Attaching the data flash log. Note that I am using a second pixhawk (the cube) with only the lidar connected to it. It still behaves the same as on the other fully connected pixhawk though.


(rmackay9) #13

@Max_Drougge,

You said you’ve tested with an Arduino Uno as well and do not see the offset. I guess i could find it by googling but could you point me at the software that is on the Uno? I’d like to see if it does anything differently than we do. I guess it uses I2C as well?

@ppoirier,
I guess you’re saying that you’ve got the same sensor as @Max_Drougge but you’re not seeing a large offset? (just a small offset of about 15cm).


(Max Drougge) #14

Yes I used the arduino with i2c as well. I used the example code from Garmin. I2C lidarlitev3.txt (1.2 KB)
Attaching a copy of it.


(ppoirier) #15

I will test with latest releases this week end and report


(Nik Barkley) #16

Subscribing to this as I am also seeing the same offset values with my Garmin lidar lite v3, also keep getting “Bad LiDar health” errors intermittently while flying or on the ground.


(rmackay9) #17

@Iron_Donkey,

It’s possible that the “bad lidar health” messages are caused by the lidar going out-of-range and an (incorrect) change in how we report the lidar health. We will fix this bad-reporting issue in 3.6.2.


(Nik Barkley) #18

Thanks Randy, I’ll double check my range settings but I am pretty certain the max is set to 4000cm and I don’t fly over 30-50 feet AGL at my current zone since I’m only allowed 100’ by LAANC, being near an airport.


(Max Drougge) #19

Did you get a chance to test it this week end?


(ppoirier) #20

@Max_Drougge
I tested with master code and I could not get my V3 started. From what I can see, the V3 and V3hp are sharing the same code… Need more testing


(Nik Barkley) #21

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) #22

@Iron_Donkey,

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


(Nik Barkley) #23

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


(Nik Barkley) #24

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) #25

@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:

  1. 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.
  2. test EKF switching in Loiter mode to make sure we handle it as best we can.
  3. 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) #26

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?


(Nik Barkley) #27

@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) #28

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.