search

hyye / lio-mapping

Implementation of Tightly Coupled 3D Lidar Inertial Odometry and Mapping (LIO-mapping)
https://sites.google.com/view/lio-mapping
GNU General Public License v3.0
898 stars 320 forks source link

Playing my data set after 20 secs lio_processor died #14

Closed llu0120 closed 4 years ago

llu0120 commented 5 years ago

Hi author, I run the open source on my own data, first I run roslaunch lio test_indoor.launch & and then run roslaunch lio map_4D_indoor.launch &. After these command, I play my bag by adding --clock at the end and after running for 20 sec, the process is died like below. Selection_006 However, if I don't add --clock at the end, the process will not died in the whole bag, but the terminal of roslaunch lio test_indoor.launch & didn't show anything and also nothing shown in rviz as well. Any suggestions for this bug? Thank you!

hyye commented 5 years ago

Did you use self-collected data?

I didn't meet this problem. I don't think it is a common "bug". With only error information from the terminal, it is tough to say where the problem is. As I said before, using gdb to find out where the program dies can help us to locate the problem.

llu0120 commented 5 years ago

Thanks for your reply! Yeah, I use self-collected data. I use gdb and the result looks like below: Selection_008 Selection_009

hyye commented 5 years ago

Does the provided dataset work? It seems some problems with PointProcess. Is there any NAN data in your point cloud? If yes, maybe try to filter the NAN data.

But, I believe it is a problem with some libraries. My suggestion is to clean and rebuild the project first.

BTW, what is your PCL, Eigen and gcc version?

llu0120 commented 5 years ago

The provided dataset printed out the messages without errors like below Selection_010

However, Rviz didn't show any topics visualization like below Selection_011

and my PCLversion is 1.8.0, Eigen is 3.2.92, gcc is 5.4.0.

hyye commented 5 years ago

There are no results since it was not built with Release option. See https://github.com/hyye/lio-mapping/issues/2#issuecomment-508306469 and https://github.com/hyye/lio-mapping/issues/10#issuecomment-508308072.

llu0120 commented 5 years ago

But if I build with Release option, the process estimator will died like below Selection_012

hyye commented 5 years ago

Then, I am not sure where the problem is, potentially related to some libraries. My final recommendation is to use docker or another computer to see if the same problem exists.

llu0120 commented 5 years ago

Thanks for the suggestion! I’ll try to use docker. However, because of being new to using docker, are there any instruction to setup the environment?

hyye commented 5 years ago

I suggest to follow docker docs and nvidia-docker wiki to setup the basic docker environment.

Then, use the commands I provided in the README to build and run docker. I hope this can help you.

llu0120 commented 5 years ago

Now my docker version is Docker version 18.09.7, build 2d0083d and I have install nvidia-docker2 by sudo apt-get install -y nvidia-docker2 and pkill -SIGHUP dockerd successfully. Selection_020

What are the next steps? How to run your Readme command docker/build_docker.sh, I run like below but it didn't pass. Selection_019

hyye commented 5 years ago

Well, you need to run the command in the directory lio-mapping.

llu0120 commented 5 years ago

Hi thanks for your instruction, I successfully run your provided dataset with docker. But now I try to plugin my dataset, but the process died again like below. How to use gdb to debug in this case or any solution for this? Thank you! Selection_021

hyye commented 5 years ago

Does the provided dataset work? Maybe try to check the NAN values or incompatible data first. The default rate of 3D lidar is 10Hz.

In docker, you can still use some commands like docker exec to enable gdb. It seems a problem related to memory corruption.

llu0120 commented 5 years ago

Yeah it works. But my dataset doesn't, does this mean I need to change the default rate of the 3D lidar compatible to my dataset? I enable the removeNaNFromPointCloud first to avoid nan values.

hyye commented 4 years ago

If it is standard 3D lidar, like Velodyne, with default settings and drivers. The data should be OK. It should be a sweep of points (> ten thousand points) in one point cloud with update rate around 10Hz.

llu0120 commented 4 years ago

I use gdb to debug and found that after confronting this line curvature_idx_pairs_.resize(region_size); in the PrepareSubregion function many times, it will crash with the memory corruption error. Any idea why this happened?

hyye commented 4 years ago

Can you check the region_size? Is it too large or invalid?

llu0120 commented 4 years ago

Thanks for your reply. The value of the region_size were around 200 for the first few scan, but then it has suddenly increase to 633 (looks too large but this depends on the scan_size), which also corrupt at this point. As the region_size is define by ep sp and those two are define by scan_size, but the scan_size are the data grab from my lidar, so I don't think I can change that. Any suggestion? By the way, my lidar is not a Velodyne, it is a Pandar.

hyye commented 4 years ago

BTW, what is your platform? Does it have enough memory to run the program? One suggestion is to add some exception handling to enclose the line causing the problem.

But it can still relate to the driver or data. I haven't tried Pandar. The current version does not directly support lidars that are not with 16, 32, or 64 scans.

llu0120 commented 4 years ago

Thanks Author, I have solve this problem for changing the computation of ElevationToRing since my lidar is different than yours.