SteveMacenski
commented
4 years ago A couple questions and a few comments. All pretty off the cuff.
Q: What way would you like to "utilize" the model? First I'd say the 2 (main) uses are for planning and control, but also for localization if you like, which seems like the most clear use-case for this type of information. Because this is VIO and not a SLAM, its going to be prone to drifting. If you're proposing to have this be the global-representation of your world youd like to plan in, you'll need to be aware that your positioning system will need to be based on the same warped coordinate system or else things will probably go out of wack (ei the positioning coordinates no longer map 1:1 to your odometric-3d-mesh coordinates). In doing so, I think your application will have problems and this won't scale to even moderately large spaces.
Q: Is your goal to navigate in 3d or 2d? If you're moving in more or less a plane, you may want to downsample this to 2D pixels or 3D voxels just to be more regular and then are able to use the normal toolset. I suppose from your explanation, your planning space (not really costmap, but another representation of C-space) I don't know you need to concern yourself with raycasting if you're not just going to check normals/gradients/heights for traversibility in your planning in 2D. 3D may be different. I'd say there are no planners right now in the ROS ecosystem that I'm aware of that uses the more graphics approaches you mention, but if you know of some feel free to point them out to me. I think the choice here seems use-case specific in what you're trying to accomplish. My feeling is that since these meshes are dense, and probably stored in memory, this method doesn't scale well to begin with, so the planning space is sufficiently small that all of the above would work fine. If you would like to use that information, my follow-up is "why"? I know you're throwing out good information, but I'm more asking if there's a genuine requirement making you have to think about these things or if its a case of "I have it so I want to use it" or the conventional methods aren't good enough based on some tangible requirement.
Q: Can you give more context on the project? This sounds interesting. We haven't yet done much work in Nav2 on other representations and the interfaces to algorithms for them. Mostly just haven't gotten to it yet.
C: I don't think that turning it into an elevation or gradient map would actually require you to throw out the normals or other related information. You can just create a struct containing it stored at each node. I think that's what grid_maps does anyhow.
ruffsl
ToniRV
Above is a 2D slice of the 3D ESDF and the skeleton map.
I'm working with a VIO SLAM pipeline (e.g. Kimera) that can be used to generate 3D meshes of the environment, and would like to ask the best approach to utilize this world model representation for the navigation planning layer. I can think of a few conventional approaches that I'll mention later, but would prefer to make full use of the mesh representation or avoid costly model transformations.
The most conventional approach I can think of is discretizing the world mesh into 3D voxels or an elevational projection into 2D occupancy grids by extrapolating the vertex coordinates in the mesh as if they where point clouds. However this throws away the plane/face information of the mesh that could be used in planners that can exploit ray-tracing or line-plane intersection, and could lead to approximation errors when vertices of the mesh are sparse or largely spaced apart.