why the kiss-icp could make the system simple and other reference with also little params to tune [Cannot reopen, so open new one]

[Kin-Zhang]

I open a new issue since I don't know why I cannot reopen the previous one. Link to previous also

    Thanks for the reply.

As explained in the paper, we do not implement loop-closure

Without this one, I think maybe it may fail a lots of suitation. Did you also do some experiments on the how long will make the odom not so accurate and how to reduce this effect?

---

Sorry in advance because the following may be considered an offense. Actually not, just my confusion.

I rechecked the paper, and after reading it (but not so detailed sorry), I was still confused about why the kiss-icp could make the system simple. It's pretty much similar core-method to years ago papers like icp and ndt

for the discussion of the parameters. Maybe A-LOAM only has two parameters in their launch file to change:

    <param name="mapping_line_resolution" type="double" value="0.2"/>
    <param name="mapping_plane_resolution" type="double" value="0.4"/>

also autoware.ai 1.13 who open-sourced at 2019 also involved with ndt methods and their parameters could also not so many for 7/8 if you set same resolution all the time.

And there are also many methods (of course you mentioned some in the paper) like with only one LiDAR could also get the odom/pose for point cloud: hdl_graph_slam, BLAM, RAL2022 VoxelMap

Through all these comparisons (all methods I mentioned above could run only on one LiDAR without IMU, camera etc), maybe you could explain more on how your method could be simple without tuning so many params, and also which part makes the result better than others or above methods.

And of course, and still, you did really great thing to make the icp method open for everyone through python pip install. I also learned a lot from your other works.

Originally posted in #12 (comment)

[nachovizzo]

Hello @Kin-Zhang . Lots of questions! I will try to summarize a bit:

Loop-closures

Without this one, I think maybe it may fail a lots of suitation. Did you also do some experiments on the how long will make the odom not so accurate and how to reduce this effect?

So, we should first define what is a “failure”. An odometry system should provide incremental pose estimates, meaning that there is no need to be globally accurate, as long as the local estimation is doing a "decent" job. You can check the evaluation where use the MulRan dataset on really long sequences (22km). On the worst sequence, the average absolute trajectory error is about 1.3km. Odometry drifts, no matter if it's coming from a wheel odometer, visual odometry, or KISS-ICP. This means that every centimeter you "drift" is going to be accumulated forever. But this does not turn the Odometry system into a total failure, since it was never the intention. ;)

About simplicity

I was still confused about why the kiss-icp could make the system simple. It's pretty much similar core-method to years ago papers like icp and ndt

Believe me that at some point we were also confused about the results, that's why we spend extra time trying to make sure we were not making any mistake in the evaluation, because we could simply not believe it at the beginning. Turns out that it's working so well, due to a mixture of good decisions. Which I won't explain now. But we did thousands of experiments trying to understand what components were really helping the estimation and which ones didn't. Just in the aim of looking for the bare minimum ICP system for robots. Believe that most of the time, we had to remove components that were actually improving the results, but scarifying simplicity, reproducibility, and readability of the implementation. So, at some point we had a much better working system, which we decided to chop-down to extract the real core. Most of the time in the research community, all the conclusions are taken “by guess”, we decided to do exhaustive experiments. You will find all the time in research papers sentences like “Our systems works so well because or map representation”, turns out that if you change the map representation is also working as well or even better. In general, it is quite hard to completely analyze and reason about the very last bit of each of those systems, because they are quite complex in general.

In our case, it is working so well with so few parameters because we designed it to work like this. And never looked for this ultimate-fancy-trick that makes the system perform better on 2 sequences and add 2000 lines of code.

About number of parameters

for the discussion of the parameters. Maybe A-LOAM only has two parameters in their launch file to change:

What is the definition of parameter for you? The ones that are exposed in a config file? By just clicking in one of the translation units from A-LOAM I can count hundreds of magic-numbers, which are indeed parameters. You should do the same exercise, so you don't get fooled easily by a config file ;).
We tried to be as “precise” as possible and claim to have only 7 parameters. Where indeed, we only have one, the max_range, and that's why we have exposed only that parameter in the CLI interface. The other are also parameters, but indeed we never change it or touch, but you could. That's why we also exposed it through the config.yaml file.

About comparison with other systems

I guess I already reply this. But just to summarize, the philosophy of such systems is typically different from the approach we took. We don't even claim to be the best approach, and I'm 100% sure that in many cases other systems will perform much better than ours (although on the KITTI-benchmark we still rank 2nd amongst open-source systems). Although we believe that such systems will indeed outperform, we like to feel like KISS-ICP will be the next generation Odometry baseline to use it when you need something that "just works". When you have a given robotics platform, a specific application. Then it's going to be too simplistic, and indeed, you should perhaps engineer a better solution that fits your needs. But knowing you are leaving generalization on the side. We also approach some projects like this, but not for KISS-ICP.

Hope this somehow evacuated all your doubts.

[Kin-Zhang]

Thanks for such detail answers.

---

we should first define what is a “failure.”

Odometry drifts, no matter if it's coming from a wheel odometer, visual odometry, or KISS-ICP.

What I mean here is exactly because of without loop closure (we assume that we have some loops in the long distance dataset), it's hard to deal with the incremental error. That's the beginning question: Without this one, maybe long-term Odom will be not so accurate and how to reduce this effect?

But you also answered it: it's just local Odom not for the global result.

---

Which I won't explain now.

Let's wait for that.

What is the definition of a parameter for you? The ones that are exposed in a config file?

I think it is also the potential definition on the kiss-icp paper, which is the parameter for user to tune. (so normally we assume it's in the config file

You should do the same exercise, so you don't get fooled easily by a config file ;).

I did some experiments in A-LOAM, and it works great without tunning anything but only the topic name of course that (LiDAR-16), and that's why I mentioned it here. But some new work I mentioned above also did a great job. (What I mentioned above are also tried in my dataset I didn't pay much attention to their detail code but only the config/launch file is enough.

---

About comparison with other systems

Maybe it's my fault for not asking the question in a clear way. My question is in theory or mathematics novel in kiss-icp: which part makes the result better than others or above methods. But you just mentioned above also: Turns out that it's working so well, due to a mixture of good decisions. Which I won't explain now.

---

All above questions are one main core: Because the core mathematics/theory is based on icp, no new factor (optimization) no new defined feature (feature extraction) to match etc, and that comes a question: which part makes it better than others?

Still, your replies already solved a lot of confusion in my mind. THANK YOU!

[Kin-Zhang]

And another GitHub question: why is there no reopen issue button for issues I propose.. weird. But hope we have the notifications still.