Issue Description:
When connected to the flight controller, the RPLIDAR C1 exhibits erratic behavior. In the Mission Planner’s proximity view, the data appears random and inconsistent. However, when I connect the same LIDAR unit to a PC via USB and use SLAMTEC’s RoboStudio, it functions perfectly, displaying accurate and stable scans.
Videos:
Troubleshooting Steps Taken:
Tested different wiring configurations and UART ports.
Used various power sources to ensure adequate and stable power supply.
Verified all connections and configurations multiple times.
Despite these efforts, the issue persists. I came across a similar discussion where users experienced erratic data with the RPLIDAR C1 on different flight controllers .
Attachments:
Video demonstrating erratic data in Mission Planner’s proximity view.
Video showing correct operation in SLAMTEC’s RoboStudio.
Photo of the rover setup with the RPLIDAR C1 installed.
Has anyone encountered similar issues or have suggestions on potential solutions? Any guidance would be greatly appreciated.
The reason is because the lidar puts out WAY more data than the flight controller can handle.
I messed with this for way too long and discovered that to be the cause. I went as far as building a custom firmware to debug it. The serial read buffers quickly overflow.
It might be possible with a separate coprocessor like ESP32 or something to handle the gobs of data from the lidar and send a simple obstacle signal to the flight controller.
Yes that looks similar to what I was considering. Even with very precise lidar echos it would take some significant coding to reasonably determine obstacles.
On top of that I have seen users saying they have issues working out in daylight which would be my use case.
They are now shelf decorations unfortunately.
Thanks for the clarification! Do you happen to still have the code you used for the MAVLink conversion?
Do you think it would also work on an ESP32, or is it something specific to the RP2040?
Yes I tinkered with the scheduler too. There simply isn’t enough time slice available to process the data, at least for the FC I used which is otherwise fairly hefty.
Just wondering—have you also tried lowering the scan frequency of the RPLIDAR from the default 10Hz to something lower?
If so, did that help improve the data stability?