ethz-asl / mav_active_3d_planning

Modular framework for online informative path planning.
BSD 3-Clause "New" or "Revised" License
552 stars 110 forks source link

Exploration converging upwards #30

Closed aseligmann closed 3 years ago

aseligmann commented 3 years ago

Thank you for publishing a great package and framework.

I am trying to use your exploration planner for exploration in confined spaces, and I am seeing some odd results, which might be due to my configuration.

Specifically, I am testing the exploration planner in a world much like the below screenshot.

Screenshot from 2021-02-01 21-25-12

The world consists of several compartments connected by doorways (can be seen in the lower left corner of the mesh), basically a straight row of several compartments. I have confirmed that the planner can navigate through the doorways using the parameters that I am using at the moment, and it occasionally does.

However, most of the time the planner converges upwards in the compartment, much like you can see on the screenshot, and does not navigate towards the next compartment.

I would love to hear your feedback on what I can do to improve this behavior.

The behavior that I am looking for, is that the planner navigates upwards in the compartment, maps the surfaces, and then moves downwards to the next compartment to repeat the process.

I have run the planner with ascent_angle: 0.0, where it navigates in the plane through all the compartments, but obviously does not ascend to map the full compartment.

(I'm not sure it is relevant, but I should note that I am running the planner without Unreal.)


I am using the following planner_config:

# General parameters for the planner node
replan_pos_threshold: 0.25
replan_yaw_threshold: 0.15

max_new_segments: 0
min_new_segments: 0
max_new_tries: 0
min_new_tries: 0
min_new_value: 0

# Verbosity and visualization
verbose: true
verbose_modules: true
build_modules_on_init: true
visualize: true
highlight_executed_trajectory: true

# Specify a map representation
map:
  type: "VoxbloxMap"

# System constraints
system_constraints:
  v_max: 1.0
  a_max: 1.0
  yaw_rate_max: 1.6
  yaw_accel_max: 1.6
  collision_radius: 0.3

# Specifying a trajectory generator
trajectory_generator:
  type: "Uniform"
  collision_optimistic: false
  bounding_volume_args: "/map_bounding_volume"
  clearing_radius: 0.75

  # Generator Params
  n_segments: 5
  distance: 0.5
  yaw_angle: 1.2
  ascent_angle: 0.523
  # ascent_angle: 0.0
  sampling_rate: 20

  # Expansion site selection policy
  segment_selector:
    type: "RandomWeighted"
    revisit: false
    factor: 2.0
    leaf_probability: 1.0
    uniform_probability: 0.2

  # Generator Update step
  generator_updater:
    type: "RecheckCollision"

# Specifying a trajectory evaluator
trajectory_evaluator:
  type: "NaiveEvaluator"

  # Evaluator params and sensor model for simulated sensor evaluators
  clear_from_parents: false
  camera_params_ns: "/unreal/unreal_ros_client/camera_params"
  visualize_sensor_view: true
  bounding_volume_args: "/target_bounding_volume"
  sensor_model:
    type: "IterativeRayCaster"
    sampling_time: 0.0
    ray_length: 5.0
    focal_length: 320.0
    resolution_x: 640
    resolution_y: 480
    downsampling_factor: 3.0

  # Choose a cost
  cost_computer:
    type: "SegmentTime"

  # How to compute the values
  value_computer:
    type: "AccumulateValue"
    following_value_computer:
      type: "LinearValue"
      cost_weight: 1.0
      gain_weight: 0.1

  # Execution policy for available segments
  next_selector:
    type: "SubsequentBest"

  # Evaluator Update step
  evaluator_updater:
    type: "UpdateAll"
    update_gain: false
    update_cost: false
    update_value: true

# Specify a backtracker if the planner gets stuck
back_tracker:
  type: "RotateReverse"
  turn_rate: 1.6
  update_rate: 2.0
  sampling_rate: 20.0
  n_rotations: 1
  stack_size: 10

And this is my experiment_config:

# Experiment (Ballast Tank) specific parameters

# Bounding boxes (in initialization frame, relative to PlayerStart)
map_bounding_volume:
  x_min: -3.0
  x_max: 30.0
  y_min: -5.0
  y_max: 5.0
  z_min: -0.1
  z_max: 15.0

target_bounding_volume:
  x_min: -3.0
  x_max: 30.0
  y_min: -5.0
  y_max: 5.0
  z_min: -0.1
  z_max: 15.0

# System Constraints
planner:
  system_constraints:
    v_max: 1.0
    a_max: 1.0
    yaw_rate_max: 1.57
Schmluk commented 3 years ago

Hi @aseligmann

Thank you very much for your interest. Primarily I'd recommend using the RRT*-based planner given in active_3d_planning_app_reconstruction/cfg/planners/reconstruction_planner.yaml, as it is generally much more flexible and capable than the demo planner which uses motion primitives.

If the behavior of the RRT*-based planner still does not match your expectations, one could e.g. add a Cost-Module that incurs a cost for paths that end on a different height, thus incentivizing the planner to cover one compartment fully before moving on.

Not using Unreal does not make a difference, the planner should work on any simulator. The only thing to take care of is that the planner camera configuration matches the simulated one, otherwise it might expect to see things which it never can given the sensor.

Let us know if this helps.

aseligmann commented 3 years ago

Hi @Schmluk,

I had been running the reconstruction planner prior to testing the exploration planner, and I was indeed not encountering the same issue when using the reconstruction planner. At first glance it seemed a bit optimistic in it's trajectory selection, as it occasionally collided with the walls and got stuck, but this is more likely due to my lack of tuning and adjusting the correct parameters.

I will try out your suggestions, along with delving deeper into the various parameters and modules.

Thank you for the feedback.