Difference between revisions of "Navigation Tuning"
From wikidb
(→loop missed its desired rate) |
(→loop missed its desired rate) |
||
Line 36: | Line 36: | ||
the loop actually took 0.0500 seconds | the loop actually took 0.0500 seconds | ||
− | I believe | + | 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: | File global_costmap_params.yaml: | ||
Line 47: | Line 47: | ||
controller_frequency: 3.0 | controller_frequency: 3.0 | ||
planner_frequency: 1.0 | planner_frequency: 1.0 | ||
+ | |||
+ | == clearing costmap == | ||
+ | |||
+ | [ 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 been yet resolved. | ||
= Odometry (1.2) = | = Odometry (1.2) = |
Revision as of 21:37, 6 November 2016
Contents
References
- Navigation Tuning Guide
- ROS Navigation Tuning Guide by Kaiyu Zheng student at University of Washington.
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
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
[ 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 been yet resolved.
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.