move_base in uneven terrain (slopes)

asked 2016-05-24 08:14:58 -0600

stfn
287 ●10 ●19 ●24

updated 2016-07-06 08:12:43 -0600

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/max_obstacle_height 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

edit retag flag offensive close merge delete

Comments

I don't think move_base is appropriate for non-flat terrain. I'm not sure about any other planners that are appropriate for non-planar motion planning.

ahendrix ( 2016-05-24 18:56:26 -0600 )edit

Would it theoretically be possible to filter scan data so only objects that are very close are marked as obstacles? That might stop slopes from appearing as such. Regarding 3D navigation, have you found a more effective solution than setting Z = 0 in the /odom frame?

M@t ( 2016-08-01 22:46:28 -0600 )edit

If your terrain is mostly flat you can try to add a preprocessing step to the sensor data which detects the ground and removes it. This should be documented in academic papers, but I have not tried to implement it myself.

ahendrix ( 2016-08-01 22:55:58 -0600 )edit

@M@t What worked best is a ground filter on the input data along with the flat obstacle grid (not voxel grid!) while setting min/max obstacle height to -large/+large. In case of VoxelGrid, the whole problem could be overcome if the running window would take the robots z-coordinate into account.

stfn ( 2016-08-02 10:55:50 -0600 )edit

@ahendrix Do you have some reference ? Thx

@stfn I'm facing the same issues with slopes. Could you detail a bit more what you did ? My rover is running the Navigation stack to follow a waypoints path while avoiding unpredictable obstacle. However, the rover is outdoor - no flat world !