API review

Proposer: Eitan Marder-Eppstein

See: http://pr.willowgarage.com/pr-docs/ros-packages/base_local_planner/html/index.html

Present at review:

• Eric, Brian, Ken

ROS Paramaters, Doxygen wasn't cooperating with me so I moved to the wiki for now:

• ~prune_plan, true, defines whether or not to eat up the plan as the robot moves along the path
• ~yaw_goal_tolerance, 0.05, the tolerance for the controller in yaw when achieving its goal

• ~xy_goal_tolerance_, 0.10, the tolerance for the controller in the x & y distance when achieving a goal

• ~odom_topic, odom, the topic to listen for odometry data
• ~acc_lim_x, 2.5, the x acceleration limit of the robot
• ~acc_lim_y, 2.5, the y acceleration limit of the robot
• ~acc_lim_th, 3.2, the yaw acceleration limit of the robot
• ~sim_time, 1.0, the amount of time to forward-simulate trajectories
• ~sim_granularity, 0.025, the step size, in meters, to take between points on a given trajectory
• ~vx_samples, 3, the number of samples to use when exploring the x velocity space
• ~vtheta_samples, 20, the number of samples to use when exploring the theta velocity space
• ~path_distance_bias, 0.6, the weighting for how much the controller should stay close to the path it was given
• ~goal_distance_bias, 0.8, the weighting for how much the controller should attempt to reach its local goal, also controls speed
• ~occdist_scale, 0.2, the weighting for how much the controller should attempt to avoid obstacles
• ~heading_lookahead, 0.325, how far to look ahead in meters when scoring different in-place-rotation trajectories
• ~oscillation_reset_dist, 0.05, how far the robot must travel in meters before oscillation flags are reset
• ~escape_reset_dist, 0.10, how far the robot must travel in meters before it is allowed to exit escape mode, meaning it is allowed to move forward again
• ~escape_reset_theta, M_PI_4, how far the robot must rotate in radians before it is allowed to exit escape mode, meaning it is allowed to move forward again
• ~holonomic_robot, true, determines whether velocity commands are generated for a holonomic or non-holonomic robot
• ~max_vel_x, 0.5, the maximum velocity allowed
• ~min_vel_x, 0.1, the minimum velocity allowed
• ~max_vel_th, 1.0, the maximum theta velocity allowed
• ~min_vel_th, -1.0, the minimum theta velocity allowed
• ~min_in_place_vel_th, 0.4, the minimum rotational velocity allowed
• ~backup_vel, -0.1, speed used for backing up during escapes

• ~world_model, string("costmap"), what world model to use (point_grid or costmap)

we don't really use point grid anymore though... perhaps this should go away?

• ~dwa, dwa, true, whether to use the Dynamic Window Approach or whether to use Trajectory Rollout
• ~heading_scoring, false, whether to score based on the robot's heading to the path or its distance from the path
• ~heading_scoring_timestep, 0.1, how far to look ahead in time in seconds along the simulated trajectory when using heading scoring
• ~simple_attractor, false, whether or not to attempt to be drawn to a point even if the goal is in an obstacle

Question / concerns / comments

Enter your thoughts on the API and any questions / concerns you have here. Please sign your name. Anything you want to address in the API review should be marked down here before the start of the meeting.

base_local_planner documentation

• Roland

  • WorldModel::footprintCost() should only take the robot position as parameter, all the rest is constant for a given robot and thus be passed as constructor args. This would also make it easier to implement caching of the footprint cost in subclasses of WorldModel.

  • VoxelGridModel::updateWorld() seems to be a refactoring leftover that can be removed

  • Clarify "path" vs "trajectory" semantics: TrajectoryPlanner::findBestPath() returns a "Trajectory" object... which does not have a velocity for each point so it actually should be called "Path".

Meeting agenda

To be filled out by proposer based on comments gathered during API review period

Conclusion

Package status change mark change manifest)

• Action items that need to be taken.

• Major issues that need to be resolved

• In TrajectoryPlannerROS:

  • updatePlan(orig_global_plan) -> setPlan(global_plan)

  • make drawFootprint() private

  • Remove getLocalGoal(x,y); start publishing local goal as PoseStamped; stop publishing VisualizationMarker of local goal pose

  • goalReached() -> isGoalReached()

• Document all topics that are published, including those that are primarily used for visualization

• Move away from message types that are being deprecated, e.g., Polyline2D

• Params:

  • Group parameters functionally, both in the documentation and the code (amcl does this)

  • Remove ~world_model

  • Add a note to dwa saying, "True is recommended in most cases."

• Related point: nav interfaces (i.e., C++ headers) should move from nav_robot_actions nav_core