search

minwoo0611 / MA-LIO

Asynchronous Multiple LiDAR-Inertial Odometry using Point-wise Inter-LiDAR Uncertainty Propagation
GNU General Public License v2.0
287 stars 36 forks source link

Argument must be non-negative (Error process has died) #30

Open cmakelabs opened 2 weeks ago

cmakelabs commented 2 weeks ago

Trying to run on my own rosbag, I got this error

malio_mapping: /home/noetic/maLIO_ws/src/MA-LIO/MA_LIO/include/IKFoM_toolkit/esekfom/../mtk/types/../src/mtkmath.hpp:151: std::pair<_FIter, _FIter> MTK::cos_sinc_sqrt(const scalar&) [with scalar = double]: Assertion `x2>=0 && "argument must be non-negative and must not be nan/-nan"' failed.
[laserMapping-2] process has died [pid 538969, exit code -6, cmd /home/noetic/maLIO_ws/devel/lib/ma_lio/malio_mapping __name:=laserMapping __log:=/home/noetic/.ros/log/c4c48244-2cd3-11ef-a22b-6b3260c4d878/laserMapping-2.log].
log file: /home/noetic/.ros/log/c4c48244-2cd3-11ef-a22b-6b3260c4d878/laserMapping-2*.log

I have tried the same rosbag, with single LIDAR and it worked without any issues on FAST-LIO. I note that I have found a similar issue in a different package on the internet (FASTER-LIO), at this link, which was later fixed by the authors.

Akina2001 commented 1 week ago

Hello, I would like to ask if you have solved this problem?

cmakelabs commented 1 week ago

Unfortunately not yet, I would be really glad if the authors could answer

minwoo0611 commented 1 week ago

Hello, @cmakelabs,

Similar to issue 31, there was an error introduced in our recent pull request update.

While I cannot confirm that your error source is the same as the one in the previous issue (since your issue involves your own rosbag file and the previous one involved our city dataset), I believe the source of the problem may be similar.

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 additional issues, feel free to contact me.