Bad LIDAR Health Message with RPLidar A2M8

Hi all, really appreciate everything this community has done and keeps doing. I was excited to try out the Bendy Ruler object avoidance with Rover 4.0 using a pixhawk Cube 2.1. I bought the RPLidar A2M8 which a lot of other developers seem to have had success with. I keep getting a “Bad Lidar Health” message during prearm checks, and I am at a loss on how to diagnose and resolve it.

At first I wasn’t even getting motor startup on the Lidar unit, but that was resolved by powering it with an external BEC. However I still get the Bad Lidar Health message. Unfortunately I don’t know how to diagnose the dataflash PRX log. Any help would be greatly appreciated. See my wiring diagram below and the Param and Dataflash BIN file attached also.

I tested the lidar unit using the framegrabber app from Slamtec and it works fine.

27 2-14-2020 8-17-54 PM.bin (674.4 KB)
UGV2_ParamList_2_02-15-2020.param (16.4 KB)

Any thoughts or help would be greatly appreciated!


Update: I saw on an old forum post that some users with pre-4.0 Rover firmware had to power on the Lidar before the Pixhawk. I did the same and now it seems to work - I see Lidar data on the proximity viewer.

Any thoughts on resolving this power-up sequence issue? Would love to have everything power up at the same time using one switch without timer delay circuits or separate switches, I have one master switch for power on the rover unit.


The A2M8 start current is 1200 to 1500 mA, so it must have an independent supply as you have done. You can check with an oscilloscope the evolution of its +5V and TX/RX at start, to see what is really happening (perhaps a faster rising supply…).

I have the same issue with the RPLidar A2.
I was getting crazy checking the params and connections, until I have read your post.
Then, I have powered the lidar first and then the FC and it worked.
I have cube black and a 5V bec to power the rplidar.

I don’t know if it could be possible to add a delay before initialising the sensor.

There are also different types of rplidar each one with different max distances. Maybe it would be worth to add a parameter with the maximum distance for the 360 lidars.


Thanks for the report.

I’ve created an issue here to enhance the driver to be more robust to the startup timing. It’s not clear what the issue is but hopefully we will get to it eventually.

It may be that the situation can be improved by adding a startup delay to the autopilot. Could you try setting BRD_BOOT_DELAY = 5000 (5 seconds) to see if this helps?

Yes, I agree we should have a parameter to specify the maximum range of the device. I’ve created another issue here.

Hi @rmackay9 - thanks for the response! Tried a 5000ms and then a 10000ms delay - did not work, still get the Bad Lidar Health message. When I apply power to the rover, the Here GPS LED lights up immediately, and the buzzer’s startup sound seems to come on a fair bit faster than the specified delay. Not sure if that indicates anything about the BRD_BOOT_DELAY functionality?

Also - I’m going to need to start testing outdoors soon so the RPLidar A2 unit is not going to cut it - how have you found the Lightware SF40C’s performance on blue sky days? I’m also considering the RPLidar A3 which seems to be marketed for daylight operations.


The Lightware SF40C works well outdoors. I don’t see any problem getting distances. It’s fairly large though and it provides so much data that I’d recommend getting a high powered autopilot like the Hex CubeOrange or Holybro Durandal.

Good to hear. Thank you for the heads up on the autopilot with the SF40C @rmackay9

How were you able to start up the lidar before the pixhawk. I purchased a second BEC to handle only the Lidar with its peak current. You mentioned timer delay circuits. Where did you place these? Is there somewhere that I can purchase one? My apologies I am new to circuits.

Do you have a link to the BEC you used. Mine isn’t providing enough power to start the lidar. I am assuming that it isn’t outputting its rated voltage