some error in NAO slam
ysys98 opened this issue · 7 comments
Dear mbusy
when I set a 2D nav goal at rviz ,robot will move towards the target
but a strange phenomenon ：If the target point I set is approximately a straight line, the robot will walk towards the target point, but if the target point is in the oblique front of the robot, the robot will also walk but will not turn，the robot will not follow the globally planned path,robot just would walk sideways like a crab and will not avoid obstacles
What should I do？
Best wish
Hi @ysys98, I see that you closed the issue, did you solve your problem?
@mbusy Hi, thank you for your reply. The previous problem has been solved. I still have some problems now. When I set a 2D NAV goal for Nao, he will walk along the global path and local path, but there will be a strange phenomenon that Nao swings left and right in the process of walking, because my obstacle update completely depends on the camera above Nao, Swinging left and right will cause great errors in the location of new obstacles in the local cost map. How can I avoid the problem of Nao swinging left and right during navigation？
I'm afraid that it's a purely NAOqi related issue, if I understand correctly NAO's walk is responsible for the shaking of the camera? I guess you could use a different walk engine to generation joint trajectories allowing the robot to walk differently, but ultimately I think that you will still obtain some sort of shaking
I'm afraid that it's a purely NAOqi related issue, if I understand correctly NAO's walk is responsible for the shaking of the camera? I guess you could use a different walk engine to generation joint trajectories allowing the robot to walk differently, but ultimately I think that you will still obtain some sort of shaking
@mbusy Thank you for your help. Nao must shake when walking, causing the camera to shake slightly, which will not affect the accuracy of obstacles. In my experiment, the reason why Nao shakes left and right during navigation is because of the configuration problem of move_base caused Nao to swing left and right like a snake while walking towards the target point（2D nav goal）. I'm not sure which parameters are not configured well, which leads to this strange phenomenon
Ok got it, the "natural shaking" when walking is fine, but the one you're experiencing is too intense. Do you have elements that tie that extra shaking to the configuration problem of move_base? (I unfortunately don't have a NAO to perform tests, it might be hard to correct that)
Ok got it, the "natural shaking" when walking is fine, but the one you're experiencing is too intense. Do you have elements that tie that extra shaking to the configuration problem of move_base? (I unfortunately don't have a NAO to perform tests, it might be hard to correct that)
@mbusy I think it's related to my local planner param configuration. I'm a novice in this field, so I don't know which parameters are related. Here's my move_ base parameter configuration. and when I use Nao to build a slam map, because the odometer of Nao itself will cause the coordinate error of the map to increase with the increase of the map area, how can I avoid this problem？By the way, I have always wondered whether NAO is a differential robot or an omni-directional robot？
here is costmap_common_param.yaml
max_obstacle_height: 0.60 # assume something like an arm is mounted on top of the robot
footprint: [[ 0.3, 0.3], [-0.3, 0.3], [-0.3, -0.3], [ 0.3, -0.3]]
map_type: voxel
obstacle_layer:
enabled: true
max_obstacle_height: 0.6
origin_z: 0.0
z_resolution: 0.2
z_voxels: 2
unknown_threshold: 15
mark_threshold: 0
combination_method: 1
track_unknown_space: true #true needed for disabling global path planning through unknown space
obstacle_range: 2.5
raytrace_range: 3.0
origin_z: 0.0
z_resolution: 0.2
z_voxels: 2
publish_voxel_map: false
observation_sources: scan bump
scan:
data_type: LaserScan
topic: scan
marking: true
clearing: true
min_obstacle_height: 0.25
max_obstacle_height: 0.35
bump:
data_type: PointCloud2
topic: mobile_base/sensors/bumper_pointcloud
marking: true
clearing: false
min_obstacle_height: 0.0
max_obstacle_height: 0.15
inflation_layer:
enabled: true
cost_scaling_factor: 5.0 # exponential rate at which the obstacle cost drops off (default: 10)
inflation_radius: 0.5 # max. distance from an obstacle at which costs are incurred for planning paths.
static_layer:
enabled: true
here is global_costmap_param.yaml
global_costmap:
global_frame: /odom
robot_base_frame: /base_link
update_frequency: 1.0
publish_frequency: 0.5
static_map: true
transform_tolerance: 5
plugins:
- {name: static_layer, type: "costmap_2d::StaticLayer"}
- {name: obstacle_layer, type: "costmap_2d::VoxelLayer"}
- {name: inflation_layer, type: "costmap_2d::InflationLayer"}
here is local_costmap_param.yaml
local_costmap:
global_frame: odom
robot_base_frame: /base_link
update_frequency: 5.0
publish_frequency: 2.0
static_map: false
rolling_window: true
width: 4.0
height: 4.0
resolution: 0.05
transform_tolerance: 5
plugins:
- {name: obstacle_layer, type: "costmap_2d::VoxelLayer"}
- {name: inflation_layer, type: "costmap_2d::InflationLayer"}
here is local_planner.yaml
TebLocalPlannerROS:
teb_autosize: True
dt_ref: 0.3
dt_hysteresis: 0.1
max_samples: 500
global_plan_overwrite_orientation: True
allow_init_with_backwards_motion: False
max_global_plan_lookahead_dist: 3.0
global_plan_viapoint_sep: -1
global_plan_prune_distance: 1
exact_arc_length: False
feasibility_check_no_poses: 5
publish_feedback: False
max_vel_x: 0.2
max_vel_x_backwards: 0.2
max_vel_y: 0.1
max_vel_theta: 0.1
acc_lim_x: 0.5
acc_lim_y: 0.2
acc_lim_theta: 0.5
min_turning_radius: 0.0 # omni-drive robot (can turn on place!)
footprint_model:
type: "point"
xy_goal_tolerance: 0.2
yaw_goal_tolerance: 0.1
free_goal_vel: False
complete_global_plan: True
min_obstacle_dist: 0.25 # This value must also include our robot radius, since footprint_model is set to "point".
inflation_dist: 0.6
include_costmap_obstacles: True
costmap_obstacles_behind_robot_dist: 1.0
obstacle_poses_affected: 15
costmap_converter_plugin: ""
costmap_converter_spin_thread: True
costmap_converter_rate: 5
no_inner_iterations: 5
no_outer_iterations: 4
optimization_activate: True
optimization_verbose: False
penalty_epsilon: 0.1
obstacle_cost_exponent: 4
weight_max_vel_x: 2
weight_max_vel_y: 2
weight_max_vel_theta: 1
weight_acc_lim_x: 1
weight_acc_lim_y: 1
weight_acc_lim_theta: 1
weight_kinematics_nh: 1 # WE HAVE A HOLONOMIC ROBOT, JUST ADD A SMALL PENALTY
weight_kinematics_forward_drive: 1
weight_kinematics_turning_radius: 1
weight_optimaltime: 1 # must be > 0
weight_shortest_path: 0
weight_obstacle: 100
weight_inflation: 0.2
weight_dynamic_obstacle: 10
weight_dynamic_obstacle_inflation: 0.2
weight_viapoint: 1
weight_adapt_factor: 2
enable_homotopy_class_planning: True
enable_multithreading: True
max_number_classes: 4
selection_cost_hysteresis: 1.0
selection_prefer_initial_plan: 0.9
selection_obst_cost_scale: 1.0
selection_alternative_time_cost: False
roadmap_graph_no_samples: 15
roadmap_graph_area_width: 5
roadmap_graph_area_length_scale: 1.0
h_signature_prescaler: 0.5
h_signature_threshold: 0.1
obstacle_heading_threshold: 0.45
switching_blocking_period: 0.0
viapoints_all_candidates: True
delete_detours_backwards: True
max_ratio_detours_duration_best_duration: 3.0
visualize_hc_graph: False
visualize_with_time_as_z_axis_scale: False
shrink_horizon_backup: True
shrink_horizon_min_duration: 10
oscillation_recovery: True
oscillation_v_eps: 0.1
oscillation_omega_eps: 0.1
oscillation_recovery_min_duration: 10
oscillation_filter_duration: 10
`
Since the issue is probably not related to the driver in itself, but is rather a naoqi / mapping problem, I'll convert the issue to a discussion.
I still don't really understand why the planner would cause the robot to "shake", but then I guess that if it sends contradictory move commands at high speed you might eventually experience some shaking.
when I use Nao to build a slam map, because the odometer of Nao itself will cause the coordinate error of the map to increase with the increase of the map area, how can I avoid this problem？
I won't be able to give you a lot of information on mapping, but if only the odometry is used to localize the robot, its positioning error will increase with time, that's pretty much unavoidable. What you could do though is use a different approach to avoid the ever inflating localization error, using the cameras (visual slam) or a combination of vision and odometry (visual odometric slam)
By the way, I have always wondered whether NAO is a differential robot or an omni-directional robot?
NAO is a legged robot, its walk engine allows him to walk in any direction, making it omni directional (this rather old paper should give you more information)