PRBonn / kiss-icp

A LiDAR odometry pipeline that just works
https://www.ipb.uni-bonn.de/wp-content/papercite-data/pdf/vizzo2023ral.pdf
MIT License
1.6k stars 321 forks source link

Long pauses and constant velocity rotation cases #17

Closed bexcite closed 2 years ago

bexcite commented 2 years ago

I've been playing with kiss-icp package and testing it with some real-world data that people may have. And it performed well in most cases which is just amazing to see and kudos to the team to make such a great ICP. Two cases that I observe are not doing well during my tests.

NOTE1: I fully understand that paper is done, so if it's smth out of scope and not needed to be adressed it's ok.

NOTE2: I've made a custom data loader to read data from pcap for a specific sensor, and there maybe some errors there. However I see the great performance on majority of other cases, including the correct deskew results of a point clouds, so it gives me the clue that custom Dataloader maybe fine after all.

Case 1: Long pauses before the first non-zero movement.

Consider a vehicle with a sensor mounted on top (360 spinner, 64 beams) , and driver is preparing for a ride without any movement for a first 2 minutes, than a small movement like 10m forward, and then no movement for like another 3 minutes, and when the car finally started the movement it just completely lost for a while, until some time. (I may guess it's smth with an accumulated tau distance distributions, but maybe smth else...) After another 1-3 minutes of movement odometry kicks off more or less and then everything is fine.

Before movement: 20221018_150618_case1_before_move

Move about 10meters after a long pause: 20221018_150731_case1_move_10m

Long paus 20221018_151038_case1_after_long_pause e continues:

Movement after the long pause and recovery in 2-3 minutes: 20221018_151340_case1_recovery

Case 2: Constant velocity rotation (in a room or construction site)

It's not a single case and was also observed on other non-room cases.

Simple room with almost plain walls but multiple corners and indentation in a wall visible (180 degree, spinner, 20hz, 32 beams) and a sensor rotating very smoothly around Z axis (like on a turntable) (with some pauses without rotation for 10-30 seconds, so it's case1 here as well probably). Result is a jerky trajectory that if drawn smeared a lot of that room.

Before the move: 20221018_152755_case2_before

After some movements: 20221018_152830_case2_after

Tried things:

I tried to tune some params, but no luck, seems that min_motion_th should have had some impact, but don't see any improvements.

Will be happy to test the fully released version and contribute the data loader for running kiss-icp on real world pcap data easily for one of the sensors.

Cheers!

bexcite commented 2 years ago

Updated initial post with pictures.

bexcite commented 2 years ago

I think I figured out the problem and the solution. In both cases the voxel_size apparently was too big if one was assuming the max_range to be from the sensor spec, let's say 150m or even more, which caused the big voxel size and much worse registration in situation where lot's of feature are nearby. so decreasing the max_range for Case 1 to 50m and for Case 2 to 10m (because it was a room), made things significantly better.

So its probably makes sense to not just use the sensor spec but take into an account the data distribution, which can be done easily outside of kiss odometry by estimating the range distribution on some 10-100 scans to get an idea of what max_range parameter to set.

Again, super happy with the results! Great job!

nachovizzo commented 2 years ago

@bexcite great analysis. Actually for all the test runs we did for indoors we've setup a max range of 10m. We once had 2 config files, one for outdoor and other for indoor. But after removing almost all componentes of the pipeline we realized that the only difference was the max range, and therefore exposed it also through the CLI.

Once we release the full thing I plan to write some documentations on how to use, adapt and tune the system for non out-of-the-bxo working datasets.

I'll review your whole issue once I'm back at the office, I'm now away from my main pc.

Thanks for the patience

nachovizzo commented 2 years ago

@bexcite Should I close this for now, or do you need further assistance? I guess that until the real thing is released there is not much we can do, please let me know if you need additional help.

bexcite commented 2 years ago

Yes, we can consider it's done, because selecting a proper min/max range did a trick. Thanks!

Rotoslider commented 1 year ago

I've been playing with kiss-icp package and testing it with some real-world data that people may have. And it performed well in most cases which is just amazing to see and kudos to the team to make such a great ICP. Two cases that I observe are not doing well during my tests.

NOTE1: I fully understand that paper is done, so if it's smth out of scope and not needed to be adressed it's ok.

NOTE2: I've made a custom data loader to read data from pcap for a specific sensor, and there maybe some errors there. However I see the great performance on majority of other cases, including the correct deskew results of a point clouds, so it gives me the clue that custom Dataloader maybe fine after all.

Case 1: Long pauses before the first non-zero movement.

Consider a vehicle with a sensor mounted on top (360 spinner, 64 beams) , and driver is preparing for a ride without any movement for a first 2 minutes, than a small movement like 10m forward, and then no movement for like another 3 minutes, and when the car finally started the movement it just completely lost for a while, until some time. (I may guess it's smth with an accumulated tau distance distributions, but maybe smth else...) After another 1-3 minutes of movement odometry kicks off more or less and then everything is fine.

Before movement: 20221018_150618_case1_before_move

Move about 10meters after a long pause: 20221018_150731_case1_move_10m

Long paus 20221018_151038_case1_after_long_pause e continues:

Movement after the long pause and recovery in 2-3 minutes: 20221018_151340_case1_recovery

Case 2: Constant velocity rotation (in a room or construction site)

It's not a single case and was also observed on other non-room cases.

Simple room with almost plain walls but multiple corners and indentation in a wall visible (180 degree, spinner, 20hz, 32 beams) and a sensor rotating very smoothly around Z axis (like on a turntable) (with some pauses without rotation for 10-30 seconds, so it's case1 here as well probably). Result is a jerky trajectory that if drawn smeared a lot of that room.

Before the move: 20221018_152755_case2_before

After some movements: 20221018_152830_case2_after

Tried things:

I tried to tune some params, but no luck, seems that min_motion_th should have had some impact, but don't see any improvements.

Will be happy to test the fully released version and contribute the data loader for running kiss-icp on real world pcap data easily for one of the sensors.

Cheers!

@bexcite In Note 2 you mention a custom data loader. Is this available somewhere? I have a SLAM rig that uses a Ouster or Velodyne puck to capture data and would love to run some of it through Kiss ICP. I don't typically record in Rosbags.

bexcite commented 1 year ago

Yeah, I've need to add it on some branch and probably open an MR since now the code is public and we can do it. I'll try to make it next week.

bexcite commented 1 year ago

@Rotoslider here is an MR with an Ouster dataloader, if you could give it a try (from the MR, because I don't know how it will fly with the repo maintainers yet) it will help me to test it better. (it's not a big one, very simple actually, but do the job)