I have recently upgraded to MP 1.3.30 and ArduPlane V3.3.0 on my Pixhawk to bench test LIDAR-Lite Functionality. The Lidar-Lite is connected to the Pixhawk using the recommended PWM solution. I get good sonarrange data in the MP Status screen, but I see a constant “Bad LIDAR Health” warning on the MP HUD screen.
The Pixhawk will not pass the new Arming Check with the LIDAR Lite connected, but basic Pixhawk functionality is ok with the Arming Check disabled. I get the same BAD LIDAR Health warning when I connect a later revision LIDAR-Lite. I suspect that fixing the Bad LIDAR Health issue will also fix the Arming Check problem.
Can anyone advise me on how to fix this Bad LIDAR Health issue?
Could you please send through a dataflash log.
Do you have your servo rail powered when you are running on the bench either by your ESC or an external BEC or equivalent?
That log file is of limited use as you never armed the plane and didn’t have log before arming enabled so there are no logs in the file. I’m seeing if I can replicate the issue anyway. If you could attach another log with the plane armed for a minute so the logs get generated that would be great.
Note the other way to put a dataflash log is to put it on dropbox or googledrive or any of the cloud storage and then just provide a link in here.
Here is the requested log with the Pixhawk armed. I get the same Bad LIDAR Health message. The initial sonarrange is about 2 metres. I varied the range by placing an object at heights from 20-50cm above the LIDAR. The LIDAR is inaccurate below 50cm and questionable above.
I will be travelling interstate for a week starting an hour from now, but I will take the test bed and my PC with me to stay in touch.
LIDAR is “Light Detection and Ranging”. It works on the same principal as RADAR, but uses light from a Laser. I have high hopes that it will enable me to accomplish more precise auto landings with my fixed wing plane. My previous auto landings have been ok, but the altitude above the target on the strip can vary up to plus 4 metres.
The Bad LiDAR Health in MP is caused because the LiDAR isn’t enabled for landing. This is done through the RNGFND_LANDING parameter. If you set this to 1 you should see the message disappear.
I have updated the wiki with this information as well.
Ironically this same thing happened to me today and I just installed the LIDAR today. It seems to be working now.
3 Questions about the LIDAR Lite.
Is I2C or PWM the better option for reliability and readings, or, does it not matter at all with the only advantage of the PWM Setup being that it can go into power saving mode?
Is the 680uf Capacitor required? I don’t have one installed right now as I dont have any around, but, it seems to be functioning perfectly. the BEC that is being used to power the LIDAR Lite is only powering that unit. Is it needed if that is the case or should I be ok as long as I am getting accurate readings?
We have a small tree right before our runway begins and I usually put a waypoint right above it at about 15m to ensure we don’t crash into it, with the LIDAR Lite, will the plane try to climb for a short moment as it passes over the tree? If so, what is the best solution to avoid a sudden climb during the landing approach as it passes over this object?
The follow-up tests were a success. Setting rngfnd_landing to 1 cured the Bad LIDAR Health warning. It should be noted that you will get a Bad LIDAR Health warning if you point the LIDAR to the sky. That warning takes 10 seconds to clear after pointing the LIDAR at a surface within range.
The better news is that I achieved some meaningful ranging data after resetting rngfnd_scaling to 1 and rng_fnd_offset to -32 centimetres, to compensate for a 0.32volt sonarvoltage reading that I was getting at near-zero range. I had previously attempted to cure oddball range readings by changing the rngfnd_scaling value and treating the rngfnd_offset value as volts when it should be centimetres for the Pixhawk PWM solution.
The initial production version LIDAR-Lite that I purchased did not appear to require any changes to the default rngfnd_offset and rngfnd_scaling values, but caused the GPS to lose lock. Both of the April-2015 units that I tested are GPS-friendly, but needed the rngfnd_offset change.
I may be able to improve the April-2015 version range accuracy with more testing, but the current results are very encouraging.
I realised that I needed to close the loop on this topic.
I resumed testing in July using a Boomerang 40 as my test bed. I achieved consistent successful Auto landings after some tuning to improve the plane’s waypoint tracking on final approach. Successful is an understatement. Every second landing was a greaser, with every other landing a near-greaser. Here is a video of one of the test Auto landings. Note the automated flare before touchdown.