5
$\begingroup$

I use ROS2/Python/Gazebo. I need navigation (and mapping) for a tractor on a hill: a rugged surface, so to speak. I can of course project everything on a flat map, but distances will shrink and I think localization and path planning will begin making errors. So, questions:

  1. What the 2.5d map should be? Triangles mesh instead of plane? Is there a standard?
  2. How to SLAM it all (and again, what is the output format)?
  3. And how to navigate it?

Thank you.

Improve this question
$\endgroup$
3
  • 1
    $\begingroup$ Why not going full 3D? Yes, you'd lose the whole nav2 stack, but it isn't that difficult to write something basic that works well for you. We used direct planning on pointclouds with success (even Dijkstra's algorithm was good enough even on kilometer-scale clouds). Usually, the most complicated part is deciding what is traversable or not, and that would be the same level of difficulty in 2D and 3D. To make 3D SLAM, there are lots of packages around, you could start e.g. with rtabmap or some simple ICP-based SLAM. Or elevation_mapping could be a good 2.5D mapper. $\endgroup$
    – Martin Pecka
    Sep 28 at 9:49
  • $\begingroup$ Thank you. I was thinking about this approach, but hesitating. So, the data format is raw point cloud? Or a voxelized one? I mean, do I have to navigate on point cloud, and where can I look for algorithms? I don't mean algorithms like A* etc, but rather tricks to apply them to 3d... $\endgroup$
    – Steve Brown
    Sep 28 at 17:04
  • 1
    $\begingroup$ You can look into my colleague's ROS 1 C++ implementation: github.com/tpet/naex . What I know is it works on downsampled clouds, but definitely not voxelized (i.e. density-limited, but each point represent a real point position, not a virtual point in the middle of a voxel). You then just build the vertex connectivity graph (i.e. mark neigbors) and compute traversability. Untraversable edges can be removed from the graph. And the rest is plain graph search suitable for Dijkstra. $\endgroup$
    – Martin Pecka
    Sep 28 at 18:49

1 Answer 1

Reset to default
3
$\begingroup$

The map input is generally a mesh, gradient, or 3d costmap (per the nav2 'concepts' doc). There's some discussion on how to bring this functionality to ROS 2 into the widely-used Nav2 stack (e.g., here), and potentially some third-party support via Kimera here. But it doesn't look like it's fully integrated/implemented at this point in time.

In ROS 1, there isn't official support, but there is a community-driven alternative to move_base called move_base_flex. They take mesh maps as an input, and are backwards-compatible with move_base. It's documented here, source code for move_base_flex is here, the mesh_navigation package is here, and tutorials are here. There's talk of bringing move_base_flex to ROS 2 here, but nothing concrete just yet.

Improve this answer
$\endgroup$
1
  • $\begingroup$ Thank you. I guess, what I really mean is - how to do it at all? Like, are there formats, approaches? Not the final solutions, but at least the way to go? $\endgroup$
    – Steve Brown
    Sep 22 at 15:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.