prcess died

[LandauR]

Hi Carlos,

I am implementing this project with stage simulation environment. But I found when I launched all nodes, system would stuck and died after few minutes.

Here are the messages in terminal.

Hope you can offer your help, and I will be appreciated.

[carlosmccosta]

Good afternoon,

Looking at the console output it looks like the normal estimator probably had a search radius too low for the data it received.

I pushed a commit with higher search radius for trying to make the default configuration as generic as possible: https://github.com/carlosmccosta/dynamic_robot_localization/commit/b404b4280fe9601b5ce5dbace618b7a66e2a7156

Please do git pull and test if it solved your issue. But you might need to confirm that the configurations below are adequate to your hardware (the most important being the lidar resolution and the map cell size, which affect the search radius / distance thresholds / k_neighbors of the algorithms):

• filters
• initial_pose_estimation
• pose_tracking
• pose_recovery

In drl_configs you can find an overview of the parameters of each algorithms.

For finding out what caused the crash and helping making the code more robust to sensor input, please change the rosconsole logging verbosity to DEBUG here (if necessary also change the pcl logging verbosity)

For knowing exactly which line of code caused the crash, you can:

• Run drl inside a debugger (clion / eclipse) -> First run the dynamic_robot_localization.launch for loading the configurations to the parameter server and starting the nodes, then run the debugger (if you configure the name and ns correctly (same as specified in the launch file), the debugger should kill the drl process from the roslaunch and run a new drl process controlled by the debugger
• Run drl in gdb

Let me known if the latest commit with the new configurations avoided the crash and if not, please try to help identify the cause of the crash.

Thank you for your help :) Have a nice day :)

[LandauR]

Thanks so much for your kind help! I will try soon. And now I have understood more about the system and also have some other problems and really hope you can help me with them.

When I use AMCL with one Pepperl r2000 laser sensor, with 20 meters range and 180 degrees fov. I am facing with the problem of laser deformation. When I rotate my robot in place with angular velocity of 1.0 rad/s, the scan points can not match with the reference map well.

Picture above shows the static laser scan when robot is static.

Picture above shows the matching problem when I rotated robot in place clockwise.

Picture above shows the matching problem when I rotated robot in place counter clockwise.

As you can see when I used AMCL to do localization, high speed motion of robot especially rotation would cause matching problem. In my opinion I think this is caused by delay of tf update while the laser data update is faster.

I have read your article about drl system and I found you have used spherical linear interpolation to solve the problem of laser deformation caused by robot moving and rotation. That is remarkable and I wondered if this can help me solve the problem shown above. So I implemented laserscan_to_pointcloud alone and the result was not good. And I think the reason is that some parameters were not tuned properly.

So I am wondering if you have faced with this problem in drl system？ If so, how did you solve this problem?

Thanks again for your patience and help.

[LandauR]

Hi Carlos,

I have tried new parameters you mentioned above. It turned out that the program would not die anymore. But now I am facing with the problem of initial pose recovery failure. I have checked some of the topics. I found there is no message in topic /dynamic_robot_localization/reference_pointcloud. Dose that mean that there is no reference pointcloud generated by the given map?

[carlosmccosta]

Good afternoon,

I improved the documentation of the laserscan_to_pointcloud package for explaining how to properly use it.

Please check the README.md and laserscan_to_pointcloud_assembler.launch.

Be aware that for the deformation correction to work correctly it needs reliable and accurate motion estimation of the laser in the environment. If your robot has a lot of wheel slippage, the odometry may not be reliable enough.

The reference_pointcloud should have the map that you provided. Are you publishing the map in the same topic that drl is subscribing it ? If so, change the rosconsole verbosity to DEBUG here and see if a given filter / processing stage is removing the points.

Have a nice day :)

[LandauR]

Hi Carlos,

Thanks for your previous kind help. I have tried your suggestions, and now I have found where the problems are. Shown in the picture below.

It seems that node process died when it tried to describe the keypoints.

Thanks again for you help!

[LandauR]

Hi Carlos,

I ran the launch in gdb and the output is shown below.

It seems to be a segmentation fault in eigen library. And the error occurred when pcl library calculating the descriptors for the given keypoints.

In addition, this error doses not always occur, and it dose not only occur when generating reference point cloud keypoints descriptors. Sometimes there is no error processing reference point cloud but same error occurred when processing keypoints descriptors for ambient point cloud.

[carlosmccosta]

Good night,

The PCL algorithms that rely on search radius sometimes do not deal well when a given point has no neighbors within the search radius.

For avoiding this problem, I changed the FPFH descriptor to use a k neighborhood instead of a search radius. Please do git pull and test. In my tests from rosbags, drl was working well and pcl should now be more robust to this issue.

I was using a search radius because it is more intuitive than specifying a number of neighbors. But both work well when tuned properly to the map and sensor data.

P.S. Be careful about the search radius for estimating the normals and curvature. You can visualize then by activating a pcl visualizer with these flags:

• https://github.com/carlosmccosta/dynamic_robot_localization/blob/melodic-devel/yaml/configs/pose_estimation/initial_pose_estimation_large_map_2d.yaml#L46
• https://github.com/carlosmccosta/dynamic_robot_localization/blob/melodic-devel/yaml/configs/pose_estimation/initial_pose_estimation_large_map_2d.yaml#L56

P.S. In the future, when using gdb, please include the backtrace. It gives information about the call stack, which is extremely useful for debugging.

You can retrieve the backtrace using bt:

• https://github.com/carlosmccosta/ros_development_tools/blob/master/debugging_profiling/gdb_overview.txt#L20
• https://www-zeuthen.desy.de/unix/unixguide/infohtml/gdb/Backtrace.html

Thank you for your help improving drl :+1: Have a nice day :)