noeperez / indires_navigation

ROS packages for ground robot navigation and exploration
BSD 3-Clause "New" or "Revised" License
121 stars 30 forks source link

wall leaves everywhere #11

Closed FrancoisTMM closed 3 years ago

FrancoisTMM commented 3 years ago

Hello ! Thank you for this repo which looks great for 3D ground navigation.

I am an ingineering student, and I try to integrate your work for a project. I have some issues, and I need help to solve them.

First, this is my system :

-I run it under Ubuntu 18.04 with ros-melodic

-I work in a simulation (webots). I use a diff drive (4 wheels) robot named Sylvester, which perceive is environment from a LIDAR (Velodyne VLP-16). He reads command into /cmd_vel topic and produces LIDAR data via /sylvester/velodyne_pointcloud topic. LIDAR frame is "velodyne".

This is a picture of a part of my simulation : simulation_idires_issue

-I use Octomap to read LIDAR data and publish a PointCloud2 map under "odom_combined" frame (equal to "odom" frame) via /octomap_point_cloud_centers topic I give this topic to indires_navigation.

An example of point cloud map that I can perform map_indires_issue

This is a picture of my TF tree rqt_graph_indires_issue

-Now, I want use indires_navigation to explore robot's environment.

But, that is why I am here for now... I have some issues...

The one I have the most of time is when I try to use the exploration mode. After cumputation time RRT found wall leaves every where, ans some times, some frontier: (red = walls / yellow = frontier, as your default color configuration) wall_leaf_indires_issue

this is the features point cloud (which I think is used to compute wall and frontiers leaves): features_PC_indires_issue

the RRT sample pointcloud: rrt_sample_PC_indires_issue

and the local control pointcloud: local_control_PC_indires_issue

I tried to modify a lot of params to have a good behavior into several files : 3dfeatures_params.yaml / rrt_costmap_params.yaml / navigation_params.yaml (the one from adapted_move_base)... But this result is the best that I could perform. I tried to change frontier treshold, pcl method to compute pointclouds, different leaf size or minimal number of point... Futher more, after computing, a goal is given to controller, and adapted_move_base crash, after this error :

terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
[adapted_move_base_node-6] process has died [pid 6161, exit code -6, cmd /sylvester_indires_workspace/devel/lib/adapted_move_base/adapted_move_base_node __name:=adapted_move_base_node __log:=/root/.ros/log/a4996916-ae4c-11eb-80d9-d89ef338b879/adapted_move_base_node-6.log].

I don't figure what could turn wrong into my configuration, but I guess that should come from a wrong params tunning that don't fit correctly with my octomap point cloud. After some days of investigation, I finally think I need your help to solve that.

Best regards ! François

noeperez commented 3 years ago

Hello Francois,

firstly, thank you very much for your interest.

You are right, the system is really sensitive to the input pointcloud and it is not easy to find a fine tuning of the parameters. This is one of the main drawbacks of the system.

The computation of the wall leaves is done by the pcl_filters node. You can try to play with the parameters pitch_max_inclination, roll_max_inclination and max_roughness of the node pcl_filters_node_1 in the file pcl_filters.launch. You could also try to change the size of the VoxelGridCovarianceFilter in the file rrt_filter_params.yaml. Your general input pointcloud should be dense enough to obtain good results of this filtering.

On the other hand this sound unusual to me: "-I use Octomap to read LIDAR data and publish a PointCloud2 map under "odom_combined" frame (equal to "odom" frame) via /octomap_point_cloud_centers topic I give this topic to indires_navigation."

The system is waiting to receive a pointcloud map from a mapping system in a global frame (for instance: /map or /world), not in a odometry frame. The general TF tree should have a general structure similar to: map frame (poincloud frame) -> odom frame -> robot_frame -> robot_sensors, wheels, etc. I'm not sure if your structure could lead the system to fail.

My guess, it's that move_base is failing because of any computation with the pointcloud is not giving the expected results or even the TF structure.

I hope these comments can help you. Thank you Francois.

Best regards, Noé

El jue, 6 may 2021 a las 11:50, FrancoisTMM @.***>) escribió:

Hello ! Thank you for this repo which looks great for 3D ground navigation.

I am an ingineering student, and I try to integrate your work for a project. I have some issues, and I need help to solve them.

First, this is my system :

-I run it under Ubuntu 18.04 with ros-melodic

-I work in a simulation (webots). I use a diff drive (4 wheels) robot named Sylvester, which perceive is environment from a LIDAR (Velodyne VLP-16). He reads command into /cmd_vel topic and produces LIDAR data via /sylvester/velodyne_pointcloud topic. LIDAR frame is "velodyne".

This is a picture of a part of my simulation : [image: simulation_idires_issue] https://user-images.githubusercontent.com/45355784/117269595-b4e20b00-ae58-11eb-9c61-759b56c37ce0.png

-I use Octomap to read LIDAR data and publish a PointCloud2 map under "odom_combined" frame (equal to "odom" frame) via /octomap_point_cloud_centers topic I give this topic to indires_navigation.

An example of point cloud map that I can perform [image: map_indires_issue] https://user-images.githubusercontent.com/45355784/117271444-7cdbc780-ae5a-11eb-9f44-e0d6e82a93ae.png

This is a picture of my TF tree [image: rqt_graph_indires_issue] https://user-images.githubusercontent.com/45355784/117270306-5d906a80-ae59-11eb-93e8-ac1eb4b249b3.png

-Now, I want use indires_navigation to explore robot's environment.

But, that is why I am here for now... I have some issues...

The one I have the most of time is when I try to use the exploration mode. After cumputation time RRT found wall leaves every where, ans some times, some frontier: (red = walls / yellow = frontier, as your default color configuration) [image: wall_leaf_indires_issue] https://user-images.githubusercontent.com/45355784/117275142-0640c900-ae5e-11eb-8c95-10fc76129128.png

this is the features point cloud (which I think is used to compute wall and frontiers leaves): [image: features_PC_indires_issue] https://user-images.githubusercontent.com/45355784/117275663-8d8e3c80-ae5e-11eb-9dfb-1bf54f407f22.png

the RRT sample pointcloud: [image: rrt_sample_PC_indires_issue] https://user-images.githubusercontent.com/45355784/117275706-9aab2b80-ae5e-11eb-93ac-db0c4c3146cb.png

and the local control pointcloud: [image: local_control_PC_indires_issue] https://user-images.githubusercontent.com/45355784/117275794-aeef2880-ae5e-11eb-98dc-c942f5e1c75d.png

I tried to modify a lot of params to have a good behavior into several files : 3dfeatures_params.yaml / rrt_costmap_params.yaml / navigation_params.yaml (the one from adapted_move_base)... But this result is the best that I could perform. I tried to change frontier treshold, pcl method to compute pointclouds, different leaf size or minimal number of point... Futher more, after computing, a goal is given to controller, and adapted_move_base crash, after this error :

terminate called after throwing an instance of 'std::bad_alloc'

what(): std::bad_alloc

[adapted_move_base_node-6] process has died [pid 6161, exit code -6, cmd /sylvester_indires_workspace/devel/lib/adapted_move_base/adapted_move_base_node __name:=adapted_move_base_node __log:=/root/.ros/log/a4996916-ae4c-11eb-80d9-d89ef338b879/adapted_move_base_node-6.log].

I don't figure what could turn wrong into my configuration, but I guess that should come from a wrong params tunning that don't fit correctly with my octomap point cloud. After some days of investigation, I finally think I need your help to solve that.

Best regards ! François

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/noeperez/indires_navigation/issues/11, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADUK36DIPM6ESTCIJBXBN5TTMJQ47ANCNFSM44GWKWNA .

FrancoisTMM commented 3 years ago

Thank you for your answer.

If I use the odom_combined frame to my point cloud, it's because octomap publish it under this frame. I cheked topic's frames published by octomap and it looks as he publish all this data under odom_combined frame. Should I concider this frame equal to map frame instead of odom frame ?

I will try to play with params that you point.

Futher more, I have a question about PCL. Why it's need of 1.9 specific version ? Should I reinstall ros melodic from source to build it with PCL 1.9 ? ( I tried to install 1.9 but that bring conflict with PCL 1.8 which look to be native ros melodic PCL version )

Best regards

noeperez commented 3 years ago

Hi,

PCl 1.9 is required for some methods that are not available in version 1.8 included with ROS Melodic. You can install pcl version 1.9 outside ROS ( https://pcl-tutorials.readthedocs.io/en/latest/compiling_pcl_posix.html). This new installed version can coexist with the 1.8 version included in ROS with no problem. Then, just the indires_packages look for the binaries of the version 1.9 as you can see in the different CMakeLists.txt files.

Best regards, Noé

El vie, 7 may 2021 a las 11:56, FrancoisTMM @.***>) escribió:

Thank you for your answer.

If I use the odom_combined frame to my point cloud, it's because octomap publish it under this frame. I cheked topic's frames published by octomap and it looks as he publish all this data under odom_combined frame. Should I concider this frame equal to map frame instead of odom frame ?

I will try to play with params that you point.

Futher more, I have a question about PCL. Why it's need of 1.9 specific version ? Should I reinstall ros melodic from source to build it with PCL 1.9 ? ( I tried to install 1.9 but that bring conflict with PCL 1.8 which look to be native ros melodic PCL version )

Best regards

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/noeperez/indires_navigation/issues/11#issuecomment-834227452, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADUK36AUJNNXNVN2C3R6M6LTMO2LTANCNFSM44GWKWNA .

FrancoisTMM commented 3 years ago

Hello Noé.

After a small period of debugging, I come here to make a small point.

I haven't been able to test too much the exploration with your code, but I finally manage to use adapted_move_base to calculate paths and follow them.

I had to fix several memory addressing issues that were leading my system to segfault, but the simple_rrt_star is now working properly. I would have to debug a bit more to be able to use the exploration mode, but I can at least test the 3D navigation algorithm for my project.

Thanks again.

François