Ask Your Question
1

ROS Navigation is flying into obstacles at altitude

asked 2018-02-22 11:39:26 -0500

acwatkins gravatar image

updated 2018-02-22 11:49:40 -0500

I'm trying to get 2D navigation working on a drone. I don't care about altitude, but I want to navigate at my current altitude in 2D. I have basically set this up using the tutorials but have tweaked along the way trying to debug this issue. I am using a single 360 lidar simulated in gazebo with urdf, so no point cloud abilities.

I made a single wall with a goal on the other side in gazebo. If I am at 5m altitude, it flies straight into the wall. If I'm at 3m altitude it tries to go around, but clips the corner. I have tried messing with the max_obstacle_height and min_obstacle height as well as voxel settings. However, I'm wondering if the voxel stuff requires a point cloud rather than my 2d laser scan traveling up the wall.

In rviz, there is a costmap for the wall. With voxel enabled, it draws a single line point cloud to the current altitude of the wall but no effect on flight. Without voxel it seems to decay off the map, even though I'm getting a live return from the wall via lidar.

local_costmap_params.yaml


local_costmap:
  global_frame: odom
  robot_base_frame: base_link
  update_frequency: 2.0
  publish_frequency: 2.0
  static_map: false
  rolling_window: true
  width: 50.0
  height: 50.0
  resolution: 0.1
  plugins:
    - {name: obstacle_layer, type: "costmap_2d::VoxelLayer"} 
    - {name: inflation_layer, type: "costmap_2d::InflationLayer"}

global_costmap_params.yaml


global_costmap:
  global_frame: /map
  robot_base_frame: base_link
  update_frequency: 2.0
  static_map: false
  rolling_window: true
  width: 500.0
  height: 500.0
  resolution: 0.1
  plugins:
    - {name: obstacle_layer, type: "costmap_2d::VoxelLayer"} 
    - {name: inflation_layer, type: "costmap_2d::InflationLayer"}

costmap_common_params.yaml


obstacle_range: 40.0
raytrace_range: 40.0
max_obstacle_height: 60
min_obstacle_height: 0
footprint: [ [0.5, 0.5], [-0.5, 0.5], [-0.5, -0.5], [0.5, -0.5] ]
#robot_radius: 0.5

#point_cloud_sensor: {sensor_frame: frame_name, data_type: PointCloud, topic: topic_name, marking: true, clearing: true}

obstacle_layer:
    laser_scan_sensor: 
        sensor_frame: lightware
        data_type: LaserScan
        topic: /theseus/lightware
        marking: true
        clearing: true
        max_obstacle_height: 60
        min_obstacle_height: 0
        obstacle_range: 100.0
        raytrace_range: 100.0
    observation_sources: laser_scan_sensor
    publish_voxel_map: true
    z_resolution: 0.5
    z_voxels: 120
    z_origin: 5

inflation_layer:
    inflation_radius: 5.0
    cost_scaling_factor: 10.0
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
1

answered 2018-03-08 00:22:53 -0500

ROS Navigation is built assuming a 2D model, the 3D interface here is not as it as written or intended so its not surprising that it doesn't work.

I don't think for this use-case is appropriate for the navigation stack, as it has a core assumption of 2D.

With that said, depending on how you have things configured, TF might know about the altitude you're flying at so your 2D LIDAR scan is looking over the marking at ground level. A 3D sensor in gazebo will certainly take this into account and try to avoid.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2018-02-22 11:39:26 -0500

Seen: 74 times

Last updated: Mar 08 '18