Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RPLIDAR's filtering should be rethought #7

Open
GNSS-Stylist opened this issue Jan 15, 2021 · 1 comment
Open

RPLIDAR's filtering should be rethought #7

GNSS-Stylist opened this issue Jan 15, 2021 · 1 comment

Comments

@GNSS-Stylist
Copy link
Owner

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.

GNSS-Stylist added a commit that referenced this issue Sep 20, 2021
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"(?)
@GNSS-Stylist
Copy link
Owner Author

Read 9f233c8 for some more thoughts about this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant