I’m trying to interface a Lidar Lite v3 with a pixhawk by I2C. So, I tried using copter 3.4.5 and 3.5 without results (I have the message in the attached image). I read that there is no support for Lidar Lite v3 in the latest firmware, and I tried using copter 3.3.
When I used the copter 3.3 I had some results (No error message about the driver and the display of only the first measure) but, there was a message of “ll40ls inmediate read failed: try again” when I tried using “ll40ls test i2c”.
- User issues should be posted at the forum (http://discuss.ardupilot.org) and not here. - We don’t use that PX4 driver anymore, we use our own drivers now. - Lidar Lite v3 isn’t supported yet.
My question is: Is it true what it says in the third point?
And if it is not true, can you help me to know how to work correctly with the sensor? My final goal is to work with several sensors by I2C
I’m pretty sure the LidarLite v3 is supported in master although I forget if support was added before or after AC3.5-rc1 went out. I think it may work if RNGFND_TYPE is set to “3” (remember to reboot the board after changing the param).
No, it doesn’t work. Patrick Poirier in Gitter has one and it needs modifications to our driver. It’s not hard to do it, but I’ve had no time (and I don’t have any of the Lidar Lite hardware to test it).
Unless Garmin’s documentation and Patrick are wrong, it’s impossible for it to be working. The documentation says both the hardware and software registers don’t exist anymore, at which point the code just returns false.
I added a couple of debug prinf to AP_RangeFinder_PulsedLightLRF.cpp to check the register contents. It’s returning 0x15 for the hardware version which I believe is unchanged from LidarLite v2.
Here’s the console output:
PulsedLightI2C initializing...
AP_I2C_4 on I2C bus 2 at 0x62 (bus: 100 KHz, max: 100 KHz)
PulsedLightI2C: bad version 0x00 0x00
I2C device bus 0 address 0x62 closed
PulsedLightI2C initializing...
AP_I2C_5 on I2C bus 1 at 0x62 (bus: 100 KHz, max: 100 KHz)
PulsedLightI2C: hw_version 0x15
PulsedLightI2C: sw_version 0x02
@tridge and I tested some new lidar-lite-v3 sent by Garmin and found that they weren’t working (as @OXINARF) suspected. Tridge has fixed the driver in master so this will go out with AC3.5-rc2. The RNGFND_TYPE will need to be set to 3 for the v2 (what people are using now) or 15 for the v3.
@Goro_Senzai, thanks for testing. Feel free to give master a try to see if it works for you in case you’re looking to test before -rc2 comes out. -rc2 will be out soon - tomorrow or Friday.
Thanks @OXINARF, @Goro_Senzai and @rmackay9. I’m almost a beginner as developer, and I spent almost two weeks searching information about drivers for the I2C interface of the Lidar (maybe in the wrong sites). Your answers are very helpful (sorry for the delay).
I’ll be waiting for the next release.
Thanks again.
Update:
I tried with the modifications,I built the .px4 file using “make”, I tested (using 15 for Lidar Lite v3) and it doesn’t work.
sonarrange and sonarvoltage display 0.
@marv3,
The pin order coming out of the LidarLite-v3 is a bit different than the older -v2. The connector is flipped upside-down and the wires are coloured differently. I plan to update the wiki.
The red and black wires remain the same but purple has become blue and yellow has become green. By the way, for -v3 at least, i don’t think that the various caps and the BEC are required. I’ve never used them… not even with the -v2.
It is interesting that my unit was working fine with AC3.5-rc1 without Tridge’s fix (as you can see in the debug output I posted above, it does return hw and sw versions stored in the registers), but the units you and tridge have were not working.
I just tried the master and I can confirm it’s working with RNGFIND_TYPE set to either 3 or 15 (both works, as it should since setting it to 15 makes it skip the detection process and forces v2_hardware = true).
I believe my unit is one of the very first batch of V3’s Garmin manufactured, back in August 2016, so maybe they changed the internals since then…
@Goro_Senzai, Tridge actually mentioned that it was possible for the driver (before this change) to work sometimes because we would read back somewhat random values for the missing registers used in making the decision as to whether it was v2 or v3.
Randy-san, thank you for the additional information.
I tested it some more, trying to figure out if there was anything that I’m doing that’s different from you. I tried to powered it both via an external 5V BEC with a capacitor, as well as plugging straight into the I2C bus without the cap, just to see if it made any difference.
In both cases, my unit consistently returns hw_version = 0x15 and sw_version = 0x02. I checked the documentation and indeed these registers were present in V2 docs but were omitted from the V3 docs as @OXINARF mentioned.
I’m starting to think maybe they just shipped me a v2 with the new v3 label slapped on it… but it does have the new JST GH connector instead of the Molex ClickMate that v2 units had. Unfortunately I don’t have a V2 anymore to do a comparison.
In any case, it’s working fine for me and it’s good to know that any new units I may purchase in the future would work with these changes, so thanks again!
BTW: I just came across this while searching for an answer. Seems to me that if they went out of their way to amend the wording on this, for whatever the reason, it might be a good idea to use a capacitor.
