Navigation Tuning
Contents
References
- Navigation Tuning Guide
- ROS Navigation Tuning Guide by Kaiyu Zheng student at University of Washington.
- Using rviz with the Navigation Stack
Removing Warning Messages
meter_scoring
[ WARN] [1478392084.188946161]: Trajectory Rollout planner initialized with param meter_scoring not set.
Set it to true to make your settins robust against changes of costmap resolution.
Add the following to base_local_planner_params.yaml.
meter_scoring: true
~<name>/meter_scoring (bool, default: false)
Whether the gdist_scale and pdist_scale parameters should assume that goal_distance and
path_distance are expressed in units of meters or cells. Cells are assumed by default. New in
navigation 1.3.1
laser_link
[ WARN] [1478203082.270333593]: MessageFilter [target=map laser_link ]: Dropped 100.00% of messages so far.
Please turn the [ros.costmap_2d.message_notifier] rosconsole logger to DEBUG for more information.
Replaced laser_link in costmap_common_params.yaml with neato_laser. It should be:
scan: {sensor_frame: neato_laser, data_type: LaserScan, topic: /scan, marking: true, clearing: true}
This matches neato_laser link in the base_to_laser transform node launched in tf_laser.launch.
<launch>
<node pkg="tf" type="static_transform_publisher" name="base_to_laser"
args="0.202 0 0.111 0 0 0 1 base_link neato_laser 100" />
</launch>
loop missed its desired rate
[ WARN] [1472599582.846147341]: Map update loop missed its desired rate of 3.0000Hz...
the loop actually took 0.6902 seconds
[ WARN] [1472599583.225435205]: Control loop missed its desired rate of 20.0000Hz...
the loop actually took 0.0500 seconds
I believe these went away by specifying the following in the files below. Values were blindly taken from the Linorobot. The Linorobot is using an Arm processor. The NUC is an i5. So these values need to be tuned.
File global_costmap_params.yaml:
update_frequency: 1.0 publish_frequency: 0.5
File local_costmap_params.yaml:
update_frequency: 1.0 publish_frequency: 5.0
File move_base_params.yaml:
controller_frequency: 3.0 planner_frequency: 1.0
clearing costmap
Not Resolved with the current motor controller node. See attempts below. Multiplying the target velocity by 6 provided promising results. See link below.
I was never able to configure the motor controller to play well with odometry. So I did a motor controller rewrite.
[ WARN] [1478397424.655524100]: Clearing costmap to unstuck robot (0.200000m).
[ WARN] [1478397440.988817375]: Clearing costmap to unstuck robot (0.200000m).
[ WARN] [1478397451.655523284]: Rotate recovery behavior started.
[ WARN] [1478397476.989649728]: Clearing costmap to unstuck robot (1.840000m).
[ WARN] [1478397487.656283953]: Rotate recovery behavior started.
[ERROR] [1478397512.990517118]: Aborting because the robot appears to be oscillating over and over.
Even after executing all recovery behaviors
These have not yet been resolved. Here are some attempts based on section 3 on The Local Planner in Navigation Tuning Guide. See bullet 7.
"Trajectories are scored from their endpoints. This means that setting the sim_time parameter to different values can have a large affect on how the robot behaves. I normally set this parameter to between 1-2 seconds, where setting it higher can result in slightly smoother trajectories, making sure that the minimum velocity multiplied by the sim_period is less than twice my tolerance on a goal. Otherwise, the robot will prefer to rotate in place just outside of range of its target position rather than moving towards the goal."
Changes were made to base_local_planner_params.yaml.
- sim_time
- 1.0 is the default used above
- 0.5 completely failed without attempting recovery
- 2.0 no change from 1.0
- 4.0 moved real slow then went into a rotate recovery a longer distance from the goal
- xy_goal_tolerance
- 0.01 is the default but when entered explitily it move slooowly and attempted rotate recover after moving a short distance
- 0.2 no change in behaviour
- 1.0 no change in behaviour
- 5.0 did move because it was within 5 meters of the goal which is the expected behaviour.
map request failed
[ INFO] [1478392082.697004023]: Requesting the map... [ WARN] [1478392082.699439192]: Request for map failed; trying again...
Believed to be a race condition that resolves on next attempt.
Velocity Measurements
- Velocity: 0.37 m/sec
- Acceleration: 1.85 m/sec^2
- See Velocity Measurements for Navigation for details
Odometry (1.2)
Run
Terminal 1
roscore
Terminal 2
roslaunch floor_hugger keyboard_teleop.launch
Terminal 3
roslaunch floor_hugger active_mapping.launch
Used "d" to rotate the Floor Hugger slowly clockwise. The following is after four or more rotations. Edges look well defined.
