This is for discussion with @Fayeli re issues with RPLidar S1 distance reliability issues.
First of all, thanks for the report re erratic distances when using the RPLidarS1 with Rover.
We’ve recently learned that on the Rover firmware the driver may not be updated quickly enough to consume all the data from the RPLidar. I’ve created a branch here that increases the receive buffer and also updates the maximum rate that the driver can be called to be 200hz (was 50hz). If you tell me which flight controller you’re using I’ll create at least one Rover binary and maybe you can help us test that it resolves the problem?
BTW, a few relevant points:
The distances shown in MP’s radar view are the minimum distances for the 45deg sector shown
Despite what RPLidar may say about the S1, I have tested it outside and observed that it is affected by sunlight. It may require brighter sunlight that you’ve seen in your testing but I am completely certain that it can show incorrect distances in bright sunlight.
Hi
My flight controller is CUAV V5.
The problem is that when it is in sunlight and indoors, the red lines in the Radius diagram are constantly jumping (when the ambient object and the rover are both stationary)
I had already done an outdoor AUTO mode driving test the afternoon before yesterday. The performance is the same as that of a stationary test. As long as an object is detected on the radius map (whether it is a real obstacle or a false obstacle that is incorrectly detected). ROVER will execute the reversing command (I set it to reverse when encountering obstacles)
RPLidar driver’s receive buffer size is increased to 1K
Rover calls the proximity driver at up to 200hz. The maximum is limited by the SCHED_LOOP_RATE though so you might need to increase this from 50 to 200.
Could you try installing this on your autopilot and see if it makes any difference? For the first test just install it as-is without any additional parameter changes. If that doesn’t resolve the problem then update the SCHED_LOOP_RATE to 200 (and reboot) and see if that fixes it.
If this resolves the issue then I’m sure we can get the fix included in 4.5.1 (it’s probably too late to get into 4.5.0).
Any luck trying the new binary? Sorry to be pushy but we have so many outstanding issues for 4.5.0 I would like to clear at least some of them off the list.
hi Rmakay9
New binary is stable operation indoors. There may be false alarms at a specific angle outdoors. (When the LiDAR scanning direction is facing the sky, it shows an obstacle 0.5m away from the radar). Due to the continuous rain and cloudy weather recently till today, I did not find any opportunity to conduct outdoor tests in strong sunlight. Unfortunately, we all need to wait for weather with strong sunlight.
Please believe me, I am even more anxious than you！
Once there is a chance to test, I will immediately reply to you with the results.
Actually, I need to ask you one more thing.
I previously created a post to discuss the issue of ordinary GPS drift (non RTK). The advice from others is to replace it with a better GPS (not RTK). But I remain skeptical about this.
I think GPS drift may not be resolved through software. However, for rovers, a drift of 5-10m is unacceptable. For example, when it is driving on a road, a 10m drift will cause it to directly locate outside the road.
I have read a lot of explanations about dual GPS and am trying to solve this problem through dual GPS. But I think it may fail because dual GPS is only used as a backup. It’s not about fusing or correcting signals.
Do you have any better methods or suggestions for this? (Not considering RTK)
5 to 10m of position error from the GPS sounds quite high. It does depend upon where you are in the world and what GPS you’re using but I think with a modern Ublox F9P GPS you should be able to get that down to 1m to 2m fairly easily. It’s also possible that something on the vehicle is causing interference at the 1.5Ghz that GPSs use so perhaps try temporarily removing all radios, companion computer, etc from the vehicle and re-test the GPS accuracy.
AP does support GPS blending which could lead to a more accurate GPS position than either GPS can provide.
hello
Today, the lidar function was tested under brlight sunlight. Unfortunately, I tested the SCHED-LOOP_DATE from 50-100-200 and did not achieve the expected stable effect (better than before, but the radar image still continuously detects false obstacles and causes the ROVER to constantly retreat and avoid obstacles).
During this period, there was a disconnection of lidar (the Rudis diagram shows a distance of 13 meters from the left, front, and right angles, and these three red arcs did not jump. The obstacle avoidance function failed, and the MP ground station did not have a BAD LIDAR HEALTH prompt). After restarting, it returned to normal.
https://discuss.ardupilot.org/t/position-drift-problem-on-rover/110411?u=fayeli
what I mean is this post.
The phenomenon is as follows: after the rover completes driving along the planned path (a rectangle with 4 waypoints) and returns to the starting point (keep arming, keep power on). After waiting for 10 minutes I drove again along the same planned path and I saw that the four actual waypoints of the vehicle had shifted in one direction by 5-10 meters（Rectangle drift as a whole, with no change in the angles of the four corners of the rectangle）by my eyes. But Mission Planner shows the path points of the vehicle’s movement are still the same, without any drift or shifted. Sometimes after 5 or 10 minutes when driving the same path again.The actual driving trajectory of the rover will return to the original correct path（back to the first time path)
We need to separate communication issues from the Lidar’s inability to work outdoors well.
Any chance you could just test indoors and confirm that the distances are correct? From a driver point of view, it doesn’t matter if the lidar is indoors or outdoors. We just need to be sure that the data is being transmitted correctly.
I think you confirmed that it did work indoors a couple of days ago. During those tests what was the SCHED_LOOP_RATE set to?
BTW, make sure to reboot the autopilot after changing the SCHED_LOOP_RATE parameter.
There is no GPS signal indoors and testing cannot be conducted in AUTO mode. However, I have tested it in manual mode and the indoor radar display is normal There is no difference when SCHED-LOOP_DATE is set to 50-100-200 indoors, and the radar image displayed on Rudias is normal. The three red arcs did not jump.
And im sure I rebooted the autopilot after changing the SCHED_LOOP_RATE parameter.
hi
Hi
I continued my outdoor testing today (cloudy with no strong sunlight) and also conducted indoor testing (completely without sunlight)
The radius diagram is completely abnormal both indoors and outdoors, becoming the same as before, with the red arc constantly jumping (identifying false obstacles). Then I took off the S1 lidar and connected it to the manufacturer’s Slamtec RoboStudio software for inspection. The scanned images were completely normal and the device properties were displayed normally.
I completely cannot understand what the problem is. I did not modify the parameters, the SCHED-LOOP_DATE value is 200
Thank you very much and looking forward to your testing. Could you please let me know the results here after the testing is completed.
Please pay attention to the changes in test results caused by different radar installation environments (I suggest you can find two white and black cardboard boxes with LIDAR inside each, with only one opening. To test whether different colored installation environments will cause changes in test results)
Hello @Fayeli can I request if you could please share what parameters you used to get the S1 lidar working and how did you connect the sensor to the flight controller?
S1 lidar is not responding and giving me PRX1 no sensor error.