some error in NAO slam

[ysys98]

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

[mbusy]

Hi @ysys98, I see that you closed the issue, did you solve your problem?

[ysys98]

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？

[mbusy]

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

[ysys98]

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

[mbusy]

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)

[ysys98]

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 `

[mbusy]

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)