You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
RPLIDAR (A3M1) returns erroneous measurements when there's rapid change in measured distances. This is especially true when the nearer object's width is narrow (probably threshold of width being the distance between the laser and the "triangulating" receiver when the unit can "see though" (laser shooting and receiver seeing the "laser dot" on other sides of the nearer object) the nearer object). This causes artifacts into the point cloud.
It should also be checked and taken into account if RPLIDAR returns out-of-order measurements (= not monotonically increasing angles). If measurements are not monotonically increasing, this might also be used as a some kind of clue in filtering. This may also be related to "Distance delta limit" and "Distance slope limit"-parameters not working as expected.
Might also be worth considering using some other type of unit, maybe preferably giving more raw measurements so that the filtering could be done in "deeper lever".
TL;DR: Check what the lidar does and make the filtering better.
The text was updated successfully, but these errors were encountered:
Testing if scanmode could be used to better detect tires etc.
Also testing if the strange "tails" (when there is an object nearby, objects farther away get some measurement nearer or farther than they are (hard to explain in words...)) as mentioned in #7 could be somehow prevented. Quick tests showed very strange behavior:
- If using "standard" (4 ksps)-mode and 20 rpm, there are no tails.
- Lowering RPM to about 5 the tails appear
- If using "express" (8 ksps)-mode and 20 rpm there are no tails
- Lowering RPM to 10 the tails appear
- Any 16 ksps mode seems to have tails whatever the RPM (can not get more than 20 RPM)
Doesn't make much sense. Seems like the RPLIDAR starts to mangle the measured points if "angular resolution" is good enough... But anyway, using "express" (8 ksps)-mode and 20 RPM there are no tails. So maybe use that and forget the strangeness...
Scanmode affects sampling rate and max distance (found from https://download.slamtec.com/api/download/rplidar-protocol/2.2?lang=en , page 12):
Standard: 4 ksps, 16m
Express: 8 ksps, 25m
Boost: 16 ksps, 25m
Sensitivity: 16 ksps, 25m
Stability: 16 ksps, 25m
"Sensitivity" mode does not work. "Stability" seems to be 10 ksps so maybe it is the so much advertised "outdoor-mode"(?)
RPLIDAR (A3M1) returns erroneous measurements when there's rapid change in measured distances. This is especially true when the nearer object's width is narrow (probably threshold of width being the distance between the laser and the "triangulating" receiver when the unit can "see though" (laser shooting and receiver seeing the "laser dot" on other sides of the nearer object) the nearer object). This causes artifacts into the point cloud.
It should also be checked and taken into account if RPLIDAR returns out-of-order measurements (= not monotonically increasing angles). If measurements are not monotonically increasing, this might also be used as a some kind of clue in filtering. This may also be related to "Distance delta limit" and "Distance slope limit"-parameters not working as expected.
Might also be worth considering using some other type of unit, maybe preferably giving more raw measurements so that the filtering could be done in "deeper lever".
TL;DR: Check what the lidar does and make the filtering better.
The text was updated successfully, but these errors were encountered: