ROS Answers: Open Source Q&A Forum - RSS feedhttps://answers.ros.org/questions/Open source question and answer forum written in Python and DjangoenROS Answers is licensed under Creative Commons Attribution 3.0Thu, 20 Jul 2017 04:16:27 -0500Move_base Parameters and lag in rvizhttps://answers.ros.org/question/231215/move_base-parameters-and-lag-in-rviz/ We are having an interesting problem with move_base interconnecting with our system. We are using RTABMAP and Robot_Localization (Stereo vision camera, IMU, 2d Lidar) to perceive where we are in space and to tell us where obstacles are around us. RTABMAP and RL are working well together when we don't run the move base node (We have move base running on a Nvidia Jetson TX1, RTABMAP running on a separate computer, and all the sensor nodes running on a little odroid). Meaning that when ever we take the sensor information then look at it with Rviz everything works fine with no real errors in localization and mapping. However wen we run Move_base and give the robot a 2d Navgoal it seems to drop updates to rviz while the robot is moving and tends to overshoot its goal then try to correct itself whilst moving around like crazy. It keeps overshooting then trying to correct then overshooting again.
Move_base isn't throwing any errors however this behavior is very strange. Any help will be greatly appreciated. I will attach our param files to see if there is something in there you see. Let me know if you need anything else.
base_local_planner.yaml
<pre>
DWAPlannerROS:
#
# Robot Configuration Parameters
#
acc_lim_x: 0.5 # The x acceleration limit of the robot in meters/sec^2
acc_lim_y: 0 # The y acceleration limit of the robot in meters/sec^2
acc_lim_th: 1.5 # The rotational acceleration limit of the robot in radians/sec^2
max_trans_vel: 0.25 # The absolute value of the maximum translational velocity for the robot in m/s
min_trans_vel: 0.0 # The absolute value of the minimum translational velocity for the robot in m/s
max_vel_x: 0.25 # The maximum x velocity for the robot in m/s.
min_vel_x: -0.25 # The minimum x velocity for the robot in m/s, negative for backwards motion.
max_vel_y: 0.0 # The maximum y velocity for the robot in m/s
min_vel_y: 0.0 # The minimum y velocity for the robot in m/s
max_rot_vel: 2.0 # The absolute value of the maximum rotational velocity for the robot in rad/s
min_rot_vel: 0.5 # The absolute value of the minimum rotational velocity for the robot in rad/s
# WARNING:
# These parameters may only be for TrajectoryPlannerROS... they may not work for DWAPlannerROS..
max_vel_theta: 2.0 # The maximum rotational velocity allowed for the base in radians/sec
min_vel_theta: -2.0 # The minimum rotational velocity allowed for the base in radians/sec
min_in_place_vel_theta: 0.6 # The minimum rotational velocity allowed for the base while performing in-place rotations in radians/sec
holonomic_robot: false # Determines whether velocity commands are generated for a holonomic or non-holonomic robot.
#
# Goal Tolerance Parameters
#
yaw_goal_tolerance: 0.20 # (11 degrees) The tolerance in radians for the controller in yaw/rotation when achieving its goal
xy_goal_tolerance: 0.30 # (30cm) The tolerance in meters for the controller in the x & y distance when achieving a goal
latch_xy_goal_tolerance: false #If goal tolerance is latched, if the robot ever reaches the goal xy location it will simply rotate in place, even if it ends up outside the goal tolerance while it is doing so.
#
# Forward Simulation Parameters
#
sim_time: 1.7 # The amount of time to forward-simulate trajectories in seconds
sim_granularity: 0.025 # The step size, in meters, to take between points on a given trajectory
vx_samples: 12 # The number of samples to use when exploring the x velocity space
vy_samples: 0 # The number of samples to use when exploring the y velocity space
vtheta_samples: 24 # The number of samples to use when exploring the theta velocity space
penalize_negative_x: false # Whether to penalize trajectories that have negative x velocities.
#
# Trajectory Scoring Parameters
#
path_distance_bias: 5.0 # The weighting for how much the controller should stay close to the path it was given
goal_distance_bias: 9.0 # The weighting for how much the controller should attempt to reach its local goal, also controls speed
occdist_scale: 0.01 # The weighting for how much the controller should attempt to avoid obstacles
forward_point_distance: 0.325 # The distance from the center point of the robot to place an additional scoring point, in meters
stop_time_buffer: 0.2 # The amount of time that the robot must stop before a collision in order for a trajectory to be considered valid in seconds
scaling_speed: 0.25 # The absolute value of the veolicty at which to start scaling the robot's footprint, in m/s
max_scaling_factor: 0.2 # The maximum factor to scale the robot's footprint by
#
# Global Plan Parameters
#
prune_plan: true # Defines whether or not to eat up the plan as the robot moves along the path. If set to true, points will fall off the end of the plan once the robot moves 1 meter past them.
oscillation_reset_dist: 0.05 # How far the robot must travel in meters before oscillation flags are reset
meter_scoring: true
</pre>
costmap_common_params.yaml
<pre>
#
# Common Configuration (local_costmap) & (global_costmap)
#
robot_base_frame: base_link
plugins:
- {name: obstacles_layer, type: "costmap_2d::ObstacleLayer"}
- {name: inflater_layer, type: "costmap_2d::InflationLayer"}
# Robot Specific
footprint: [[ 0.765, 0.765], [ -0.765, 0.765], [ -0.765, -0.765], [ 0.765, -0.765]] # corrected to include tires in the footprint
footprint_padding: 0.10 # 10cm buffer for safety. maybe change for more precision
inflation_radius: 1.5
transform_tolerance: 1.0 # Specifies the delay in transform (tf) data that is tolerable in seconds.
controller_patience: 2.0 # How long the controller will wait in seconds without receiving a valid control before space-clearing operations are performed.
#added
meter_scoring: true
# base global planner
NavfnROS:
allow_unknown: true # Specifies whether or not to allow navfn to create plans that traverse unknown space.
inflater_layer:
inflation_radius: 1.5
obstacles_layer:
observation_sources: laser zed_obstacles
laser: {
observation_persistence: 0.0,
sensor_frame: lidar_link,
data_type: LaserScan,
topic: /scan,
marking: true,
clearing: true,
inf_is_valid: true,
raytrace_range: 5.0,
obstacle_range: 5.0
}
zed_obstacles: {
data_type: PointCloud2,
topic: /obstacles,
marking: true,
clearing: true,
max_obstacle_height: 1.5,
min_obstacle_height: 0.0
}
</pre>
global_costmap_params.yaml
<pre>
global_costmap:
global_frame: map
robot_base_frame: base_link
update_frequency: 1
publish_frequency: 1
static_map: true
rolling_window: false
width: 40.0
height: 40.0
resolution: 0.125
origin_x: -20
origin_y: -20
plugins:
- {name: obstacles_layer, type: "costmap_2d::ObstacleLayer"}
- {name: inflater_layer, type: "costmap_2d::InflationLayer"}
</pre>
local_costmap_params.yaml
<pre>
local_costmap:
global_frame: odom
robot_base_frame: base_link
update_frequency: 5.0
publish_frequency: 8.0
static_map: false
rolling_window: true
width: 7.0
height: 7.0
resolution: 0.125
origin_x: -3.5
origin_y: -3.5
#plugins:
# - {name: obstacles_layer, type: "costmap_2d::ObstacleLayer"}
# - {name: inflater_layer, type: "costmap_2d::InflationLayer"}
</pre>
We are pretty sure this sporadic behavior in rviz has something to do with move_base however if you think otherwise we are open to suggestions. We can also supply any other set up files needed!
Let me know if you need any other information from me.....we are at a stand still with this project till we figure out this issue. We are continuing testing to try to solve this issue but have no idea what we are looking for!Wed, 06 Apr 2016 12:18:46 -0500https://answers.ros.org/question/231215/move_base-parameters-and-lag-in-rviz/Comment by Tom Moore for <div class="snippet"><p>We are having an interesting problem with move_base interconnecting with our system. We are using RTABMAP and Robot_Localization (Stereo vision camera, IMU, 2d Lidar) to perceive where we are in space and to tell us where obstacles are around us. RTABMAP and RL are working well together when we don't run the move base node (We have move base running on a Nvidia Jetson TX1, RTABMAP running on a separate computer, and all the sensor nodes running on a little odroid). Meaning that when ever we take the sensor information then look at it with Rviz everything works fine with no real errors in localization and mapping. However wen we run Move_base and give the robot a 2d Navgoal it seems to drop updates to rviz while the robot is moving and tends to overshoot its goal then try to correct itself whilst moving around like crazy. It keeps overshooting then trying to correct then overshooting again. </p>
<p>Move_base isn't throwing any errors however this behavior is very strange. Any help will be greatly appreciated. I will attach our param files to see if there is something in there you see. Let me know if you need anything else.</p>
<p>base_local_planner.yaml</p>
<pre>DWAPlannerROS:
#
# Robot Configuration Parameters
#
acc_lim_x: 0.5 # The x acceleration limit of the robot in meters/sec^2
acc_lim_y: 0 # The y acceleration limit of the robot in meters/sec^2
acc_lim_th: 1.5 # The rotational acceleration limit of the robot in radians/sec^2
max_trans_vel: 0.25 # The absolute value of the maximum translational velocity for the robot in m/s
min_trans_vel: 0.0 # The absolute value of the minimum translational velocity for the robot in m/s
max_vel_x: 0.25 # The maximum x velocity for the robot in m/s.
min_vel_x: -0.25 # The minimum x velocity for the robot in m/s, negative for backwards motion.
max_vel_y: 0.0 # The maximum y velocity for the robot in m/s
min_vel_y: 0.0 # The minimum y velocity for the robot in m/s
max_rot_vel: 2.0 # The absolute value of the maximum rotational velocity for the robot in rad/s
min_rot_vel: 0.5 # The absolute value of the minimum rotational velocity for the robot in rad/s
# WARNING:
# These parameters may only be for TrajectoryPlannerROS... they may not work for DWAPlannerROS..
max_vel_theta: 2.0 # The maximum rotational velocity allowed for the base in radians/sec
min_vel_theta: -2.0 # The minimum rotational velocity allowed for the base in radians/sec
min_in_place_vel_theta: 0.6 # The minimum rotational velocity allowed for the base while performing in-place rotations in radians/sec
holonomic_robot: false # Determines whether velocity commands are generated for a holonomic or non-holonomic robot.
#
# Goal Tolerance Parameters
#
yaw_goal_tolerance: 0.20 # (11 degrees) The tolerance in radians for the controller in yaw/rotation when achieving its goal
xy_goal_tolerance: 0.30 # (30cm) The tolerance in meters for the controller in the x & y distance when achieving a goal
latch_xy_goal_tolerance: false #If goal tolerance is latched, if the robot ever reaches the ...</pre><span class="expander"> <a>(more)</a></span></div>https://answers.ros.org/question/231215/move_base-parameters-and-lag-in-rviz/?comment=266905#post-id-266905Did you ever solve this?Thu, 20 Jul 2017 04:16:27 -0500https://answers.ros.org/question/231215/move_base-parameters-and-lag-in-rviz/?comment=266905#post-id-266905Comment by Tom Moore for <div class="snippet"><p>We are having an interesting problem with move_base interconnecting with our system. We are using RTABMAP and Robot_Localization (Stereo vision camera, IMU, 2d Lidar) to perceive where we are in space and to tell us where obstacles are around us. RTABMAP and RL are working well together when we don't run the move base node (We have move base running on a Nvidia Jetson TX1, RTABMAP running on a separate computer, and all the sensor nodes running on a little odroid). Meaning that when ever we take the sensor information then look at it with Rviz everything works fine with no real errors in localization and mapping. However wen we run Move_base and give the robot a 2d Navgoal it seems to drop updates to rviz while the robot is moving and tends to overshoot its goal then try to correct itself whilst moving around like crazy. It keeps overshooting then trying to correct then overshooting again. </p>
<p>Move_base isn't throwing any errors however this behavior is very strange. Any help will be greatly appreciated. I will attach our param files to see if there is something in there you see. Let me know if you need anything else.</p>
<p>base_local_planner.yaml</p>
<pre>DWAPlannerROS:
#
# Robot Configuration Parameters
#
acc_lim_x: 0.5 # The x acceleration limit of the robot in meters/sec^2
acc_lim_y: 0 # The y acceleration limit of the robot in meters/sec^2
acc_lim_th: 1.5 # The rotational acceleration limit of the robot in radians/sec^2
max_trans_vel: 0.25 # The absolute value of the maximum translational velocity for the robot in m/s
min_trans_vel: 0.0 # The absolute value of the minimum translational velocity for the robot in m/s
max_vel_x: 0.25 # The maximum x velocity for the robot in m/s.
min_vel_x: -0.25 # The minimum x velocity for the robot in m/s, negative for backwards motion.
max_vel_y: 0.0 # The maximum y velocity for the robot in m/s
min_vel_y: 0.0 # The minimum y velocity for the robot in m/s
max_rot_vel: 2.0 # The absolute value of the maximum rotational velocity for the robot in rad/s
min_rot_vel: 0.5 # The absolute value of the minimum rotational velocity for the robot in rad/s
# WARNING:
# These parameters may only be for TrajectoryPlannerROS... they may not work for DWAPlannerROS..
max_vel_theta: 2.0 # The maximum rotational velocity allowed for the base in radians/sec
min_vel_theta: -2.0 # The minimum rotational velocity allowed for the base in radians/sec
min_in_place_vel_theta: 0.6 # The minimum rotational velocity allowed for the base while performing in-place rotations in radians/sec
holonomic_robot: false # Determines whether velocity commands are generated for a holonomic or non-holonomic robot.
#
# Goal Tolerance Parameters
#
yaw_goal_tolerance: 0.20 # (11 degrees) The tolerance in radians for the controller in yaw/rotation when achieving its goal
xy_goal_tolerance: 0.30 # (30cm) The tolerance in meters for the controller in the x & y distance when achieving a goal
latch_xy_goal_tolerance: false #If goal tolerance is latched, if the robot ever reaches the ...</pre><span class="expander"> <a>(more)</a></span></div>https://answers.ros.org/question/231215/move_base-parameters-and-lag-in-rviz/?comment=233994#post-id-233994Have you tried profiling your CPU usage?Mon, 09 May 2016 19:50:06 -0500https://answers.ros.org/question/231215/move_base-parameters-and-lag-in-rviz/?comment=233994#post-id-233994