Lightware I2C Range Spikes with IR-LOCK (can cause crash)

[brentmit2010]

Bug report

Issue details

During precision landing with IR-LOCK, the Lightware LW20 connected via I2C pointing down can suffer from large spikes in detected height as it passes over the IR-LOCK MarkOne Beacon. In our experience, this tends to happen ~1m above the beacon with the detected range from the Lidar spiking to 25+ meters. This spike results in the the vehicle aggressively attempting to correct its position, which is not only a dangerous maneuver but has resulted in a crash as the vehicle was too low when it tried to make the adjustment.

We reached out to Lightware for assistance in this and they conducted a series of tests to reproduce the issue. Their report is attached below. Their conclusion is that a change was made moving from 3.6.x to 4.0.x that results in the Lost Signal Timer being changed from 20 to 1 for the Lightware devices when connected via I2C to the Pixhawk. Our best guess is that this line is the culprit: https://github.com/ArduPilot/ardupilot/blob/Copter-4.0/libraries/AP_RangeFinder/AP_RangeFinder_LightWareI2C.cpp#L267

Version Copter v4.0.3, Copter v4.0.4

Platform [ ] All [ ] AntennaTracker [x] Copter [ ] Plane [ ] Rover [ ] Submarine

Airframe type Quadcopter

Hardware type CubeBlack, LW20 Lidar

Logs LiDAR Spike investigation.pdf .bin log file

[brentmit2010]

I ran a series of tests where I changed the lost signal timer and attempted to replicate the spike in a lab setting. I tested the timer set to 1, 5, 20, and 30. The report can be accessed here: https://docs.google.com/document/d/16oY3fFUQ_slIvYyMOraZ-ky1spmsNByzt2_3UdlHchQ/edit?usp=sharing

I observed a significant decrease in spikes as the timer was increased.

[brentmit2010]

I modified a version of Copter-4.0.4 to have the lost signal timer set to 20 and we conducted a series of test landings using one of our drones. Across ~14 land attempts, we saw one instance of a rangefinder spike:

Weather here is pretty poor, but we hope to test again in the coming days with the lost signal timer set to 30 to see if we can replicate the rangefinder spike.

[brentmit2010]

I modified a version of Copter-4.0.3 and Copter-4.0.4 to have the lost signal timer set to 30 and our team ran the following tests:

CubeBlack, Copter-4.0.3: ~40 landings CubeOrange, Copter-4.0.4: ~40 landings

Across the ~90 landing tests, we saw 0 rangefinder spikes with the lost signal timer set to 30. Here is an example plot from one of our logs:

[brentmit2010]

So I have bad news and good news. First, the bad news: despite doing 90+ tests, after pushing the lost signal timer to 30 to vehicles in the field, we still had reports of rangefinder spikes on landing causing overly aggressive maneuvers during precision landing.

The good news is that I went ahead and tried a fix that Randy mentioned on the partners' call which was to change the PL code to use the glitch protected rangefinder reading. We now have at least 3 landings that had range spikes but no aggressive maneuvering.

Specifically, I changed this line to be height_above_ground_cm = rangefinder_state.alt_cm_glitch_protected;

The result is quite nice:

The operator also mentioned that the landing appeared much smoother than before, too, for whatever that might be worth.

I still think increasing the lost signal timer to 20 or 30 is appropriate, but I'm still unsure what change happened here to cause this to be a sudden issue. Regardless, we are pleased with the results of using the glitch protected range thus far and plan to continue using it in the field.

I've put together a couple PRs: #15847 (lost signal timer) and #15846 (glitch-protected range)

[rmackay9]

@brentmit2010 thank you so much! This is really fantastic!

[RickReeser]

Which LightWare device and which version of the MarkOne are you using? Versions 2.0 and 3.0 of the MarkOne have a photosensor on the board which is meant to help ensure that the beacon doesn't interfere with Lightware rangefinders. I don't know which Lightware devices are compatible with this feature besides the SF20C, though.

Granted, this glitch-protected reading is a good idea to use anyways.

[brentmit2010]

We've seen this with the LW-20/C ( https://lightwarelidar.com/products/lw20-c-100-m ) and v3.0 of the MarkOne.

[RickReeser]

Interesting. For what it's worth, we use MarkOne 2.0 and the 20/C extensively, but we use serial communication instead of I2C. We don't see these low altitude glitches at all.

[IamPete1]

Looks like both the PRs mentioned have now been merged, so this should be resolved?

[rmackay9]

yes i think we can close this now.