RPLIDAR C1 Erratic Data on ArduRover 4.6.0 with Matek H743 Slim V1.5

Hello everyone,
I’m currently experiencing issues integrating the RPLIDAR C1 from SLAMTEC with my ArduRover setup.

Hardware & Firmware:

  • Flight Controller: Matek H743 Slim V1.5
  • Firmware: ArduRover V4.6.0
  • LIDAR: RPLIDAR C1

Configuration Parameters:

  • SERIAL6_PROTOCOL = 11 (Lidar360)
  • SERIAL6_BAUD = 460800
  • PRX1_TYPE = 5 (RPLIDAR)
  • PRX1_ORIENT = 0

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.

Best regards,
Johan Rocha

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.

1 Like

Here a RP2040 communicates with the lidar and does the conversion to MAVLink towards the FC. I think data rates used were 1.5Mbps.

Note that the yellow radar reflects the surroundings of the rooms, but MP crashes easily with it.

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?

Note: I also modified the scheduler loop rate parameter:

SCHED_LOOP_RATE = 400

This adjustment was made in an attempt to improve the responsiveness of the system and potentially stabilize the LIDAR data flow.

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.

1 Like

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?