Open Akina2001 opened 1 week ago
Hello, @Akina2001,
The issue stems from the most recent pull request, which introduced changes related to uncertainty in plane estimation.
In the updated code, all points now have identical uncertainty values, meaning that the maximum and minimum uncertainties in the measurements are the same. Our implementation uses fixed interval conversion (FIC) to ensure measurements fall within a user-defined interval. During this process, the difference between the maximum and minimum uncertainties is calculated and used in the denominator term, as referenced in equation (13) of the MA-LIO journal.
However, since the maximum and minimum uncertainties are now the same, the denominator becomes zero, causing the error.
I have added new conditions to handle cases where the maximum and minimum uncertainties are identical. You can see the changes here.
Thank you for identifying this issue!
If you have any further questions, please feel free to open additional issues. I am currently quite busy, so I may not be able to respond immediately, but I will make sure to address your concerns as soon as possible.
Hello, I appreciate your quick response. I successfully run CityDataset and UrbanNav's multi-lidar in the latest version of the code, but I found a problem. The single-lidar configured according to README and Issue does not run properly for UrbanLoco_HK, Utbm and 2019-04-28-20-58-02.bag in UrbanNav with the same problem:
Hello, I found the key to the problem. I think MA-LIO's velodyne_handler lacks the necessary timestamp calculation step. Adding the following code can run UrbanLoco and other codes normally (copy from fastlio):
I would like to apologize for my previous incorrect solution approach. After conducting further experiments and gaining a deeper understanding, I have realized that merely following the modification "modified by fastlio2 for urbanloco utbm or no lidar times dataset" will lead to other conflicts.
I would like to ask why it cannot run according to the default city.xml.