I2C issues? Lidar Lite v3HP and Pixhawk 2.1, poor althold and low res sonar data

Hi all,

Hi! Based on a recommendation from Robotshop that the LLv3HP was working well in I2C with ardupilot, I went ahead and bought one for an octocopter that requires terrain following. We are using Arducopter v3.5.7 on a DJI S1000+, previous loiter was great with TFMini on serial bus. However we needed greater sensor range to avoid terrain failsafe errors when passing over sudden deep ravines or boulders, which caused a vertical position variance and RTL. So the enhanced processing and temperature calibrated range of 40m on LLv3HP seemed perfect.

We installed the LLv3HP lidar using 1000uF 35V cap on power lines to a dedicated 5V 3A BEC, hooking up to the shared I2C wires of the M8N GPS/mag combo on the Pixhawk 2.1 Cube, and at first no additional pullup resistors on the lidar SDA/SCL lines. Loiter/althold over grass performance was awful, resulting in wide sweeping oscillations of over 1-2m from setpoint of 5m. After talking to some engineers they said that we should try adding the pullup resistors, even though the pixhawk probably already has an internal pullup (the gps/mag reads fine). We tried 4.7kohm, 8.1kohm, and 10kohm resistors between SDA+SCL and 5V, the variability indoors (pointing at wall) was still erratic, varying 3-5cm every few seconds at 3m, but we tested loiter/althold anyway. We settled on 4.7kohm resistors as suggested in the lidar manual and did another test flight. Still not stable at all, gradually increasing altitude oscillations of 1-2m after 10 seconds, unacceptable.

DSAlt+SAlt Graph: https://www.robotshop.com/forum/download/file.php?id=8245
full log here: https://www.robotshop.com/forum/download/file.php?id=8246

Looking at the logs we saw that the lidar was reading the correct altitude but there is something else wrong with the sensor or settings as it appears it is sampling every few seconds with low-res square data on the graph, weird. We used the lidar out of the box, we did not attempt to configure any settings besides in Mission Planner.

The logs show 4 flights outdoors with 15+ GPS satellites, over cement with small pebbles.

  1. RNGFND_GAIN 0.5, althold P 1.0
  2. Gain 1.3
  3. Gain 0.3
  4. Gain 0.8, althold P 1.3

RNGFND Params:
GAIN = 0.5
MAX_CM = 4000
MIN_CM = 20
PIN = -1


For reference here is my original post on Robotshop: https://www.robotshop.com/forum/lidar-lite-v3hp-and-pixhawk-2-1-squarish-readings-t19461

Any feedback or suggestions would be much appreciated, thanks in advance! Hopefully this helps others avoid our same issues with the LLv3HP.

You mentioned you have a dedicated BEC powering the Lidar and you have added a cap for power smoothing.
But you did not mention exactly how you connected the power and I2C.
What I mean is, did you share the earth between the BEC and the I2C bus?
Could it be a floating earth problem?

I have encountered this in the past as some of our builds can have 4 or 5 BEC’s installed.

Just a thought.

Hi Mike, thanks again for your advice. Right now we have 6S 22.2Ah lipo through an attopilot current sensor, and a 5v 3A bec coming out of that to power the pixhawk cube, m8n gps, telemetry, buzzer etc.

There is a separate 5V 3A BEC coming out of the attopilot with the 1000uF cap to the Lidar, though we did not hookup the ground coming out of the pixhawk’s shared m8n/lidar I2C port to the lidar’s BEC ground wire, didn’t consider that a floating ground could be contributing to our crappy sensor data. could it be a problem that we are running two I2C devices (GPS/mag and lidar) from different 5V power supplies, one from the pixhawk line and the other a separate BEC (with pullup resistors on SDA+SCL)?

When we hooked up the lidar ground to the shared I2C port ground just now, we get no lidar data and no battery monitor data, disconnecting this wire brings back all the sensors but our lidar signal is still choppy. I checked continuity and the I2C ground pin is definitely continuous with the battery and pixhawk servo ground pins. EDIT: I forgot we had the lidar’s 5V+ground hooked up to the POWER2 port as a backup BEC source for the pixhawk. When I disconnect POWER2 then we get lidar and current sensor data again. However the lidar resolution is still crap- while viewing the raw data from the tuning window while slowly moving a piece of paper closer and farther to the lidar, we get discontinuous square steps every 2 seconds. So much for 1kHz HP sampling rate!

Running out of ideas at this point, can’t rule out that the sensor itself is faulty… Don’t want to go through the trouble of running PWM as we would prefer a digital altitude reading, so unless someone else can chime in that they got the LL3HP working on I2C then I’m just gonna go cry in the corner. =(

I don’t think the v3HP has direct compatibility with the existing driver.

Look here what has been done to make it work with a pocket beagle

I made a PR for this driver, but they haven’t been merged to Ardupilot. You can find the change here:

On the log you mention, POWR.VServo:

Strange. Nothing supplied from the servo pins will work.

Thanks for the update ppoirier and Nghia, glad to know it wasn’t just us!! We will try PWM in the meantime and cross fingers we don’t get any EMI interference since our octocopter is pushing 70+ amps, hoping the I2C driver is updated sometime soon. Worst case we may return the HP and go with the regular v3.

Webillo, sorry for the confusion, I just meant that our ground was indeed continuous, we didn’t hook anything up to the servo pins as I know they don’t provide any power.


1 Like

I have a couple of questions regarding the Lidar Lite V3HP. I currently am bench-testing some hardware on I2C. The three of which are lidar lite v2, lidar lite v3hp and a ms 5525 airspeed sensor. I can get the Lidars to work with the airspeed sensor as long as only one of them is plugged into I2C splitter but when I plug in both lidars and the airspeed sensor it seems that none of them work. I also noticed that the lidar lite v2 also works when setting sensor type to 21 instead of sensor type 3, is this common? When I say works i at least get readings from it that seem valid.

Both lifar have the same address, you need to change address of one unit and specify this new address within the flight controler using mission planner and set the appropriate parameters

Please note that the I2C address will be restored to default after a power cycle.
Most use case are: v2 on PWM & v3 on I2C