Costmap creation from 3D mapping
Hello, I will try to provide as much detail to my issue as I can in this post, but please feel free to ask for any more info if you can help me solve my problem.
I have a robot (clearpath Husky) with a 16 beam velodyne lidar and I am trying to do outdoor navigation with it. I am currently using 3D Cartographer to do my mapping with an occupancy grid. For my current creation of costmaps and planning I am using NAV2, however, since the global and local costmaps in NAV2 require laserscans (since they are meant for 2D) I am using a pointcloud to laserscan converter to create my costmaps.
Everything works perfectly on flat planes and even when I am outside and not going through big elevation changes, everything does what it's supposed to.
However, when I decrease elevation from where my robot first started, I begin to experience issues with creating costmaps. From what I observed and tested, this occurs when the laserscans converted from the lidar points fall below the plane that the map is on (wrt the map frame id through rviz). I know that NAV2 is only meant for 2D mapping, but this problem feels like it may be solvable, I just don't really know which direction to go in. My thoughts are that since 3D_Cartographer is still only making the map on a 2D plane, that it may be possible to move the map up and down in the z direction with respect to my robots movement (idk if this is something that cartographer supports though). My hopes for this would be that the map is always just in-sync with the robots elevation so that the laserscan points don't fall below the map frame.
I will upload a file showing the issue occur in a bag I took of my own data. In this bag the robot starts at a point around 3m higher then the lowest point it traverses to. At that lowest point you can see that all of the velodyne points along with the laserscan fall below the map, which causes the costmap to stop generating. I will play the bag at 3x speed just so it's not an absurdly long video. Also, sorry about the lag in the video, I hope you can still get the point from it though.
Here is a link to the video: https://drive.google.com/file/d/1ODX2uE_mZP-DBlrg82cqtxhOa_1QZ1v0/view?usp=sharing
Please let me know if you have any ideas or suggestions about how to approach this issue, or if it is just a lost cause.
Thanks!
Asked by koener on 2023-08-01 10:43:24 UTC
Comments
Did you try to fine-tuning the params, such as change the "z_origin" on nav2_params.yaml? Or increase the mapping capabilities Tuning the params from mapper_online_sync.yaml file?
Not sure if it is going to change something, but change the the altitude should not be an issue if the TF are correctly set. I've read in other posts that using the voxel grid for local costmap is very sensitive, and some developers use obstacle layer instead (more stable). I also had similar issues (but just fixed on simulation, never in real robot.
Other approachs I could think is ( filter pcd data, there are a lot of useless pcd data over and under certain height that overloads the processing units of your system), bad localization ( have you created a robot localization launch file with IMU + ODOM fused) ?
Hope you figure out the issue.
Asked by Vini71 on 2023-08-01 11:27:32 UTC
So I don't actually use the voxel grid/layer, I already am using the obstacle layer. I don't know if there is much I can change for mapping on the nav2 side of things because I am using cartographer to create a map which I have already fine-tuned to get a good quality map, but it doesn't help this issue.
Also, maybe I am misinterpreting what you mean by fusing the IMU+ODOM (like in a filter), because from what I know they are already fused and I am fairly content with my localization. In the video I am going down a hill when I begin to lose my costmap (but the localization is accurate). However, it is even at the bottom of the hill when the robot isn't on an incline that the costmap is not being created because I believe the laserscans require some sort of reference to the map plane.
Thank you for your suggestions though Vini
Asked by koener on 2023-08-01 12:10:09 UTC