Hi,

I'm confronted with the situation of a car-like robot driving in uneven terrain, i.e. the ground is not plain but there are (slight) hills and (slight) slopes. We are not operating in the Rocky Mountains, but it's not entirely flat either. Localization is done with GPS and odometry, obstacles come from lidar pointclouds or similar. There is no static map, rather are global and local costmap operating as rolling window.

When using ROS' navigation stack resp. move_base for planning and controlling, I observe some issues:

• When using GPS, one retrieves a fixed global frame that is originated at the robots start position (similar to /map). While driving over uneven terrain, the robot's z-position changes a lot, lets say within -10/10m relative to the starting position. The costmap, resp. the marking and clearing of obstacles stops working since it demands that the sensor origin (lidar) is within the operating height of the costmap (min/maxobstacleheight and some other parameters). The costmap's rolling window frame adapts to the robot's x and y position, but seems to completely ignore its z-position (and orientation!).

• A slight ramp, although perfectly fine for driving, is marked as obstacle.

I played a lot with different parameters of move_base, used VoxelGrids and flat ones but could not figure out a setting, that works in uneven terrain. The only thing that solved most issues (but generated some others) was to override the /odom frame's z position and setting it to zero.

So I guess my general question is: can move_base be tweaked to work beyond the flat-world-assumption? Or are there stacks that overcome those limitations?

Any hint is highly appreciated