Greetings
Is there any effort on upgrading move_base to handle ramps/inclines ? I have searched answers.ros.org for probable answers. Nearest answer is [move_base in uneven terrain (slopes)](http://answers.ros.org/question/235106/move_base-in-uneven-terrain-slopes/), but it do not solve the problem.
I will be interested in implementing specific behaviour of movement as soon as robot detects a decline/incline. This will require transfer of control by move_base to another node, lets call, Node_A. After moving down the ramp, Node_A passes control back to move_base. Has similar behaviour implemented by any node?
Is there a way to store state of robot in move_base or I need to infect move_base with my code to implement state and transition memories? I am hoping to establish commn. between move_base and Node_A using actionLib interface. Is this correct approach to implement?
Rgds
↧
move_base on incline/ramps
↧
How does navigation get base_link information from stage
Hey can anyone tell me how does navigation(move_base) get base_link information when i simulate mobile robot in stage. When I move the robot position manually in stage window, the position of base_link will not align the robot position in stage. So i would like to know where come form the base_link information to navigation stack.
thank you.
↧
↧
whether gmapping is used in move_base?
Please tell, whether gmapping is used in move_base
↧
whether move_base use gmapping?
whether move_base use gmapping?
↧
Error in move base : Aborting because the robot appears to be oscillating over and over. Even after executing all recovery behaviors"
I have created my navigating tracked mobile robot. When i give a simple goal to the robot in RVIZ path planning was done successfully. But the robot did not move. Instead of moving the error message was prompted after few seconds as Aborting because the robot appears to be oscillating over and over. Even after executing all recovery behaviors". Can anyone give me a proper solution for this. In here i have attached all parameter files, rqt graph of active topics and some screenshots in RVIZ.
local_costmap_params.ymail
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: 1.0
height: 1.0
resolution: 0.05
transform_tolerance: 0.5
plugins:
- {name: obstacles, type: "costmap_2d::VoxelLayer"}
- {name: inflater, type: "costmap_2d::InflationLayer"}
global_costmap_params.yaml
global_costmap:
global_frame: /map
robot_base_frame: base_link
update_frequency: 1.0
publish_frequency: 0.5
static_map: true
transform_tolerance: 0.5
costmap_common_params.yaml
obstacle_range: 2.5
raytrace_range: 3.0
#footprint: [[x0, y0], [x1, y1], ... [xn, yn]]
footprint: [[-0.2,-0.2],[-0.2,0.2], [0.2, 0.2], [0.2,-0.2]]
#robot_radius: 0.22545
robot_radius: 0.4002
#cost_scaling_factor and inflation_radius were now moved to the inflation_layer ns
inflation_layer:
enabled: true
cost_scaling_factor: 10.0 # exponential rate at which the obstacle cost drops off (default: 10)
inflation_radius: 0.30 # max. distance from an obstacle at which costs are incurred for planning paths.
obstacle_layer:
enabled: true
min_obstacle_height: 0.0
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
observation_sources: laser_scan_sensor
laser_scan_sensor: {sensor_frame: laser, data_type: LaserScan, topic: scan, marking: true, clearing: true}
dwa_local_planner_params.yaml
DWAPlannerROS:
# Robot Configuration Parameters - Kobuki
max_vel_x: 0.55 # 0.55
min_vel_x: 0.0
max_vel_y: 0.4 # diff drive robot
min_vel_y: 0.0 # diff drive robot
max_trans_vel: 0.38 # choose slightly less than the base's capability
min_trans_vel: 0.10 # this is the min trans velocity when there is negligible rotational velocity
trans_stopped_vel: 0.1
# Warning!
# do not set min_trans_vel to 0.0 otherwise dwa will always think translational velocities
# are non-negligible and small in place rotational velocities will be created.
#max_rot_vel: 5.0 # choose slightly less than the base's capability
max_rot_vel: 2.0 # Very slow for exploration!
min_rot_vel: 0.4 # this is the min angular velocity when there is negligible translational velocity
rot_stopped_vel: 0.4
acc_lim_x: 0.5 # maximum is theoretically 2.0, but we
acc_lim_theta: 2.0
acc_lim_y: 0.0 # diff drive robot
# Goal Tolerance Parameters
yaw_goal_tolerance: 0.1 # 0.05
xy_goal_tolerance: 0.15 # 0.10
# latch_xy_goal_tolerance: false
# Forward Simulation Parameters
sim_time: 1.0 # 1.7
vx_samples: 6 # 3
vy_samples: 1 # diff drive robot, there is only one sample
vtheta_samples: 20 # 20
# Trajectory Scoring Parameters
path_distance_bias: 32.0 # 32.0 - weighting for how much it should stick to the global path plan
goal_distance_bias: 24.0 # 24.0 - wighting for how much it should attempt to reach its goal
occdist_scale: 0.50 # 0.01 - weighting for how much the controller should avoid obstacles
forward_point_distance: 0.325 # 0.325 - how far along to place an additional scoring point
stop_time_buffer: 0.2 # 0.2 - amount of time a robot must stop in before colliding for a valid traj.
scaling_speed: 0.25 # 0.25 - absolute velocity at which to start scaling the robot's footprint
max_scaling_factor: 0.2 # 0.2 - how much to scale the robot's footprint when at speed.
# Oscillation Prevention Parameters
oscillation_reset_dist: 0.05 # 0.05 - how far to travel before resetting oscillation flags
# Debugging
publish_traj_pc : true
publish_cost_grid_pc: true
global_frame_id: odom
# Differential-drive robot configuration - necessary?
holonomic_robot: false
prune_plan: true # May help with Auto Explore.
**move_base.launch.xml**
↧
↧
Move_base: cannot cancel while executing recovery behavior
Hi all, I'm using move_base action client to send goals to my robot and cancel if necessary. It works fine, but I have realized that cancelGoal doesn't work while executing recovery behavior. That is, if I call cancelGoal or cancelAllGoals, the subsequent call to waitForResult doesn't return until all recovery fails. I have tried to disable recovery behavior with:>rosrun dynamic_reconfigure dynparam set move_base recovery_behavior_enabled false
Again, this doesn't returns until recovery fails (more than 2 minutes!). I suppose move_base gets somehow blocked when running recovery behavior and don't even attend reconfigure requests.
Btw, I'm using hydro-devel code navigation stack, but experienced the same with groovy package installation.
Thanks
↧
move_base tuning
Whats are the variables that go into determining what cmd_vel move_base will output. I have a robot thats capable of 4m/s but during autonomous navigation the maximum that it ever chooses to go is 0.75m/s.
Here is my current understanding.
**min_vel_x** and **max_vel_x** bound the possible cmd_vel that move_base will output
I also read somewhere that **gdist** will also affect cmd_vel but in testing I have tweaked this value a lot using rqt_reconfigure and it doesn't show a noticeable difference.
Are there any other parameters that I can tweek in order to make my robot move closer to its full speed (just talking about x direction)?
TrajectoryPlannerROS:
max_vel_x: 4.0
min_vel_x: 0.4
max_vel_theta: 3.0
min_vel_theta: -3.0
min_in_place_vel_theta: 1.0
acc_lim_theta: 6.0
acc_lim_x: 6.0
acc_lim_y: 6.0
yaw_goal_tolerance: 0.3
xy_goal_tolerance: 0.5
sim_time: 1.0
sim_granularity: 0.025
angular_sim_granularity: 0.025
vx_samples: 3
vtheta_samples: 20
controller_frequency: 20
# Cost Function Parameters
# cost = pdist_scale * (distance to path from the endpoint of the trajectory in map cells) + gdist_scale * (distance to local goal from the endpoint of the trajectory in map cells) + occdist_scale * (maximum obstacle cost along the trajectory in obstacle cost (0-254))
# Local cost map resolution: 0.05 meters/cell
pdist_scale: 0.6
gdist_scale: 0.3 # Also controls speed
occdist_scale: 0.01
dwa: true
publish_cost_grid_pc: true
prune_plan: false
holonomic_robot: false # Robot cannot move sideways without turning first
↧
Use navigation to correct robot's path
Till now I was using Gazebo to simulation. Now I am trying to implement that on a real robot. I have been successful in doing so but there is one problem in following the path.
When the path is straight, the robot **fails to follow a perfectly straight path (like it followed in Gazebo)**. This maybe due to **limitations of odometer** based speed control of motors.
So will the navigation stack correct the bot path by giving an alternate **path or speed as a feedback** if it finds out (*by the encoder values that is computed and published as odom*) that the robot is not following the correct path that it previously published?
So, does the navigation stack does that or is there any way to do it?
↧
Why so much spinning in place with move_base?
Hello,
I'm trying to tune move_base under fairly ideal circumstances so I did not think it would be this hard. I am using the [arbotix_python](http://www.ros.org/wiki/arbotix_python) base controller in "fake" mode which basically just moves the simulated robot exactly as it's told on /cmd_vel. So I am treating it as an "ideal" test case with no physics.
I then have a Python script that moves a simulated TurtleBot to the four corners of a 1 meter square on a blank map using the simple move_base action server.
I've run through the [Navigation Tuning Guide](http://www.ros.org/wiki/navigation/Tutorials/Navigation%20Tuning%20Guide) and spent many hours of trial and error tweaking the various parameters using dynamic_reconfigure but I still can't figure out why the robot has such a tendency to spin in place before it gets to a goal even when there are no obstacles and I have the recovery and clearing behaviors disabled. The problem gets worse as I make the goal tolerances smaller--for example, setting the xy_goal_tolerance to 0.05 tends to guarantee spinning and often timing out before getting to the goal.
I'm wondering if others have figured out any secrets behind this spinning behavior. I'm also wondering if not having any real or simulated observation sources could be causing it?
I get the same results whether I use the latest Electric or Fuerte debian install under Ubuntu 11.10.
**EDIT 1:**
My navigation config files can be [found here](http://code.google.com/p/ros-by-example/source/browse/#svn%2Ftrunk%2Frbx_vol_1%2Frbx1_nav%2Fconfig%2Ffake).
And the script that moves the robot in a square can be [found here](http://code.google.com/p/ros-by-example/source/browse/trunk/rbx_vol_1/rbx1_nav/nodes/move_base_square.py).
Thanks!
patrick
patrick
↧
↧
Some help required using the range_sensor_layer in costmap
Hi all,
I'm having some issues adding ultrasonic sensors to my costmap. My robot was set up using the move_base setup guide, and uses a single Hokuyo lidar for SLAM with hector_mapping. It uses three costmaps: local_costmap_params.yaml, global_costmap_params.yaml and costmap_common_params.yaml.
To help get the ultrasonic data into the costmap(s) I made a simplified URDF model (instead of manually adding static transform publishers to launch files, as I did with the laser scanner). I've got data from a SRF05 into ROS and displaying as a cone from the front of my model in RVIZ, and after a bit of playing with the costmaps I've managed to get ultrasonic range data to register as inflated obstacles in the local costmap.
The problem is that when I add the sonar sensor to the costmap, I no longer have any lidar data in the costmap. Before I added the range_layer to the params.yaml file I could see a global and local costmap in rviz. Now that the sonar settings are in there too I only see the ultrasonic range costmap stuff inside the local costmap, and the global costmap is empty. I am getting errors out of the move_base terminal which read:
[ERROR] [1486152698.562581761]: Range sensor layer can't transform from map to /ultrasound at 1486152698.395551
However there must be at least an intermittent transformation between map and /ultrasound because I can see the obstacles being added to the costmap in RVIZ, [as you can see here](https://s24.postimg.org/hvlqz37zp/range_Finder_RVIZ.png). For comparison, [this is what I get](https://s27.postimg.org/9bx6bltn7/range_Finder_RVIZNOSONIC.png) when I remove the "sonar_layer:" section and the "plugins:" section from costmap_common_params.yaml.
I'm not too sure what I'm doing in general with setting all this up (figuring it all out as I go along), so any advice or pointers from anyone would be greatly appreciated.
Here are my costmap parameter files:
local_costmap_params.yaml:
local_costmap:
global_frame: /map
robot_base_frame: base_link
update_frequency: 6.0
publish_frequency: 1.0
static_map: false
rolling_window: true
width: 6.0
height: 6.0
resolution: 0.05
transform_tolerance: 0.5
obstacle_layer:
observation_sources: laser_scan_sensor sonar_layer
laser_scan_sensor: {sensor_frame: laser, data_type: LaserScan, topic: scan, marking: true, clearing: true}
global_costmap_params.yaml:
global_costmap:
global_frame: /map
robot_base_frame: base_link
update_frequency: 6.0
static_map: true
costmap_common_params.yaml:
plugins:
- {name: sonar_layer, type: "range_sensor_layer::RangeSensorLayer"}
- {name: inflation_layer, type: "costmap_2d::InflationLayer"}
obstacle_range: 3
raytrace_range: 9
footprint: [[-0.162, -0.206], [-0.162, 0.206], [0.162, 0.206], [0.162, -0.206]]
#old footprint: [[-0.12, -0.18], [-0.12, 0.18], [0.12, 0.18], [0.12, -0.18]]
#robot_radius: ir_of_robot
inflation_radius: 0.4
transform_tolerance: 1.3
observation_sources: laser_scan_sensor
laser_scan_sensor: {sensor_frame: laser, data_type: LaserScan, topic: scan, marking: true, clearing: true}
sonar_layer:
frame: ultrasound
topics: ["/ultrasound"]
no_readings_timeout: 1.0
clear_on_max_reading: true
And [here is my URDF model](https://s28.postimg.org/s9lppfg65/RDFtree.png).
Please let me know if there's any more information that I should add to this question.
Many thanks,
Tom
↧
Global planner behavior upon planning failure
Hi,
I am using navigation stack and wondering what is the expected behavior of global planner upon the local planner fails to control robot according to thewaypoints.
According to a test that I ran ([link](https://github.com/gergia/multiple_turtlebots_stage_amcl/blob/replanning/README.md)), it seems that it enters the global planner over and over again (without taking into account any info from sensors).
That is not what I would expect - I expected it to return *impossible to find a plan* the second time it enters the planner.
Is it really so, or did I make a mistake in the setup?
EDIT:
I found suitable parameters to control number of time global planner is called - those are *planner\_patience* and *max\_planning\_retries* (the latter one is exactly what I was looking for, as found [here](https://github.com/ros-planning/navigation/issues/496) ).
**However**, even with this parameters set to smaller values (2 seconds or 4 attempts), makePlan is still invoked multiple times. It seems as if that happens in separate threads, because I get the info that *max\_planning\_retries* is exceeded, but makePlan is being called over and over again.
I have no idea how to detect which function or which node calls it multiple times. Does somebody know better? EDIT2: Additionally, it is clear that infinite loop of calling makePlan starts once the *max\_planning\_retries* is exceeded and afterwards it does not check that condition. EDIT3: disabling recovery behaviors all together keeps number of calls to makePlan lower (although, still higher than *max\_planning\_retries*)
**However**, even with this parameters set to smaller values (2 seconds or 4 attempts), makePlan is still invoked multiple times. It seems as if that happens in separate threads, because I get the info that *max\_planning\_retries* is exceeded, but makePlan is being called over and over again.
I have no idea how to detect which function or which node calls it multiple times. Does somebody know better? EDIT2: Additionally, it is clear that infinite loop of calling makePlan starts once the *max\_planning\_retries* is exceeded and afterwards it does not check that condition. EDIT3: disabling recovery behaviors all together keeps number of calls to makePlan lower (although, still higher than *max\_planning\_retries*)
↧
move_base takes longer time to update the Goal Status why ?
Hello
I am doing an experiments on Navigation Stack by referring the Link ( http://wiki.ros.org/navigation ) But While doing experiment I am facing one Issue.
I am using Rtabmap ( Localization ) + visual odometry + move_base ( with teb_local_planner ).
I am sending goal to the move_base by Cpp APIs, The myprogram.cpp( CPP code ) sends 5 goals to the robot one after the other but after reaching each goal the Robot waits for the GOAL STATUS for more than 2 minutes or it takes longer time than this .Please can you suggest me why the Status takes much longer time to update. Is their any parameter in move_base pkg or in the teb_local_planner which affect this ?
↧
StaticLayer map-resize erases all obstacles from ObstacleLayer
Hello @David Lu
I am using Google Cartographer as SLAM component, and move_base for navigation. In the config of the global costmap, I have setup costmap_2d::StaticLayer to subscribe to the /map topic published by cartographer. There is also an ObstacleLayer and an InflationLayer. My problem is that each time cartographer dynamically adjusts the map size, all obstacles which have been added to the global costmap get erased.
Looking at the code of [static_layer.cpp](https://github.com/ros-planning/navigation/blob/53087ca5242fb40f06c84a6bcc74057c3470eff7/costmap_2d/plugins/static_layer.cpp) I can see that StaticLayer::incomingMap() is executed when a map with new dimensions is received. In this function, there is a section that [initializes the costmap with static data](https://github.com/ros-planning/navigation/blob/53087ca5242fb40f06c84a6bcc74057c3470eff7/costmap_2d/plugins/static_layer.cpp#L197-L206).
How can I prevent the StaticLayer from erasing previously discovered obstacles from the ObstacleLayer to get erased from the master costmap (i.e. global costmap)?
Thanks
↧
↧
Dynamic footprint support
Hello @David Lu
My robot runs on four tracks whose angle can be adjusted during runtime. To account for the change of the robots' footprint, I use the dynamic recunfigure callback mechanism by calling the /move_base/global_costmap/set_parameters and /move_base/local_costmap/set_parameters services, passing a new footprint string.
My problem is that each footprint change while move_base navigation is active causes the global costmap to be reset. When digging into the code of the costmap_2d layer plugins, I discovered that setting the parameter footprint_clearing_enabled=false prevents this from happening, see this [code section in obstacle_layer.cpp](https://github.com/ros-planning/navigation/blob/53087ca5242fb40f06c84a6bcc74057c3470eff7/costmap_2d/plugins/obstacle_layer.cpp#L418).
However, setting footprint_clearing_enabled=false is not what I want, as this causes these errors when navigation starts and the robot has not moved yet:
The origin for the sensor at (-0.00, 0.00, 0.00) is out of map bounds. So, the costmap cannot raytrace for it.
What do you suggest how to keep footprint_clearing_enabled but without resetting the costmaps each time?
Thanks
↧
Move_base: replanning issue
Hello:
I'm trying to configure move_base with my mobile robot platform and i am facing a serious issue. I am using ROS Hydro and navigation stack 1.11.15
I have configured the navigation package to follow the generated path as close as possible and when an unexpected obstacle appears in the path from outside the local window, the navfn and global_path is replanned and everything works OK. But if the obstacle appear near the robot (where the global path is already planned) it is not able to replan and approaches the obstacle until the robot stop.
If I configure the global planner to replan at a certain ratio, it is able to replan avoiding the obstacle, but this is not the behaviour (periodic planning) we want in the real application, only replanning when the path is blocked.
My configuration files are as following:
Base local planner params:
base_global_planner: navfn/NavfnROS
base_local_planner: base_local_planner/TrajectoryPlannerROS
recovery_behaviors: [{name: conservative_reset, type: clear_costmap_recovery/ClearCostmapRecovery}, {name: rotate_recovery, type: rotate_recovery/RotateRecovery}, {name: aggressive_reset, type: clear_costmap_recovery/ClearCostmapRecovery}]
controller_frequency: 10.0
planner_patience: 3.0
controller_patience: 5.0
conservative_reset_dist: 3.0
recovery_behavior_enabled: true
clearing_rotation_allowed: true
shutdown_costmaps: false
oscillation_timeout: 0.0
oscillation_distance: 0.5
planner_frequency: 0.0
global_frame_id: map_navigation
TrajectoryPlannerROS:
acc_lim_x: 0.4
acc_lim_y: 0.4
acc_lim_theta: 0.8
max_vel_x: 0.2
min_vel_x: 0.1
max_trans_vel: 0.2
min_trans_vel: 0.1
max_rotational_vel: 0.6
max_vel_theta: 0.6
min_vel_theta: -0.6
min_in_place_vel_theta: 0.3
escape_vel: 0.0
holonomic_robot: false
y_vels: []
xy_goal_tolerance: 0.5
yaw_goal_tolerance: 0.3
latch_xy_goal_tolerance: true
sim_time: 1.0
sim_granularity: 0.025
angular_sim_granularity: 0.025
vx_samples: 3
vtheta_samples: 20
controller_frequency: 10
public_cost_grid_pc: true
meter_scoring: true
#DWA
heading_scoring: false
dwa: false
forward_point_distance: 0.325
path_distance_bias: 32
goal_distance_bias: 24
#TRAJECTORY PLANNER
pdist_scale: 0.9
gdist_scale: 0.8
occdist_scale: 0.01
heading_lookahead: 0.325
publish_cost_grid_pc: false
global_frame_id: map_navigation
oscillation_reset_dist: 0.05
prune_plan: true
NavfnROS:
allow_unknown: false
planner_window_x: 0.0
planner_window_y: 0.0
default_tolerance: 0.0
visualize_potential: false
Local costmap params:
local_costmap:
# Coordinate frame and TF parameters
global_frame: map_navigation
robot_base_frame: base_link
transform_tolerance: 1.0
# Rate parameters
update_frequency: 2.0
publish_frequency: 2.0
#Map management parameters
rolling_window: true
width: 8.0
height: 8.0
resolution: 0.05
origin_x: 0.0
origin_y: 0.0
static_map: false
obstacle_layer:
observation_sources: laser_scan_sensor
laser_scan_sensor: {sensor_frame: hokuyo_link, data_type: LaserScan, topic: hokuyo/scan, marking: true, clearing: true, observation_persistence: 0.0, expected_update_rate: 0.0, max_obstacle_height: 2.0, min_obstacle_height: -2.0, obstacle_range: 4.0, raytrace_range: 5.0, inf_is_valid: false}
max_obstacle_height: 2.0
obstacle_range: 4.0
raytrace_range: 5.0
track_unknown_space: false
inflation_layer:
inflation_radius: 5.52
cost_scaling_factor: 2.0
plugins:
-
name: obstacle_layer
type: "costmap_2d::ObstacleLayer"
-
name: inflation_layer
type: "costmap_2d::InflationLayer"
Global costmap params:
global_costmap:
# Coordinate frame and TF parameters
global_frame: map_navigation
robot_base_frame: base_link
transform_tolerance: 1.0
# Rate parameters
update_frequency: 5.0
publish_frequency: 2.0
#Map management parameters
rolling_window: false
resolution: 0.05
static_map: true
#Static Layer
static_layer:
unknown_cost_value: -1
lethal_cost_threshold: 100
map_topic: map_navigation
obstacle_layer:
observation_sources: laser_scan_sensor
laser_scan_sensor: {sensor_frame: hokuyo_link, data_type: LaserScan, topic: hokuyo/scan, marking: true, clearing: true, observation_persistence: 0.0, expected_update_rate: 0.0, max_obstacle_height: 2.0, min_obstacle_height: -2.0, obstacle_range: 4.0, raytrace_range: 5.0, inf_is_valid: false}
max_obstacle_height: 2.0
obstacle_range: 4.0
raytrace_range: 5.0
track_unknown_space: false
inflation_layer:
inflation_radius: 5.52
cost_scaling_factor: 2.0
plugins:
- name: static_layer
type: "costmap_2d::StaticLayer"
-
name: obstacle_layer
type: "costmap_2d::ObstacleLayer"
-
name: inflation_layer
type: "costmap_2d::InflationLayer"
Thank you in advance for any idea about how to solve it.
↧
Robot Unable to track path - (tf2 empty frame id warning)
I am currently running a differential drive setup robot configured to run on GMapping, custom made odometry publisher and navigation stack(move_base, costmap_2d).
I have the following errors and warnings with the param settings given below:
1. I get the following error when giving a goal on the map (map and current position are perfect ).( I created a map from recording /scan topic on a bag file)
`[ WARN] [1487352631.099260113]: MessageFilter [target=map ]: Discarding message from [/move_base] due to empty frame_id. This message will only print once.`
`[ WARN] [1487352631.099750851]: Invalid argument passed to canTransform argument source_frame in tf2 frame_ids cannot be empty`
2. move_base linear and angular velocities aren't getting tracked. The robot just weirdly rotates at full speed and performs in place rotation, and goes away from the goal given. **BUT** , using keyboard to publish cmd_vel works and the robot moves around perfectly. Which suggests the move_base isn't configured properly.
3. Sometimes, the above two problems
don't come up but the robot veers
away just as it reaches the goal at
a high speed(away from the goal).
The robot has a square base with motors kept at either centres of sides of square with a castor wheel at center.
My setup files are:
TrajectoryPlannerROS:
acc_lim_x: 0.09
acc_lim_y: 0.0
acc_lim_theta: .05
max_vel_x: 0.6
min_vel_x: 0.3
max_vel_theta: 0.2
min_vel_theta: 0.1
min_in_place_vel_theta: 0.2
holonomic_robot: false
yaw_goal_tolerance: .2
xy_goal_tolerance: .2
sim_time: 1.0
vx_samples: 12
meter_scoring: true
pdist_scale: 15
heading_lookahead: 0.325
heading_scoring: true
dwa: true
global_frame_id: map
global_costmap:
global_frame: /map
robot_base_frame: /base_link
update_frequency: 1.0 #before: 5.0
publish_frequency: 0.5 #before 0.5
static_map: true
transform_tolerance: 0.5
local_costmap:
global_frame: /map
robot_base_frame: /base_link
update_frequency: 1.0 #before 5.0
publish_frequency: 2.0 #before 2.0
static_map: false
rolling_window: true
width: 5
height: 5
resolution: 0.025 #before 0.05
transform_tolerance: 0.5
common_costmap:
obstacle_range: 2.5
raytrace_range: 3.0
footprint: [[0.15, 0.15], [-0.15, 0.15], [-0.15, -0.15], [0.15, -0.15]]
inflation_radius: 0.15
transform_tolerance: 0.13
meter_scoring: true
observation_sources: scan
scan:
data_type: LaserScan
topic: scan
marking: true
clearing: true
map_type: costmap
move_base_params
shutdown_costmaps: false
controller_frequency: 5.0 #before 5.0
controller_patience: 15
planner_frequency: 5.0
planner_patience: 5.0
oscillation_timeout: 10.0
oscillation_distance: 0.2
conservative_reset_dist: 0.10 #distance from an obstacle at which it will unstuck itself
recovery_behavior_enabled: false
clearing_rotation_allowed: false
↧
How to set yaw offset in robot_pose_ekf/robot_localization?
Hi,
I am planning to use odmetry x,y, yaw as well as imu yaw data in robot_pose_ekf package. Since the imu will start at some yaw value relative to magnetic north? Do I have to programatically set that yaw value as 0 and pass the relative yaw to robot_pose_ekf or will it set the yaw offset itself. Thanks
↧
↧
tf2 warning when setting a goal
I am currently running a differential drive setup robot configured to run on amcl, custom made odometry publisher and navigation stack(move_base, costmap_2d).
I get the following continuous warnings on terminal running rviz:
Invalid argument passed to canTransform argument source_frame in tf2 frame_ids cannot be empty
Any possible solution to the warning? The robot just goes straight when setting a goal with a turn and absolutely straight goal it easily follows. Also, I have a odometry publisher I wrote using the navigation odom setup tutorials from [here](http://wiki.ros.org/navigation/Tutorials/RobotSetup/Odom)
Here's the tf tree:
↧
move_base: does not publish/subscribe anything when roslaunch from local catkin workspace
Hello all. I'm having trouble getting my own local nodes (in a catkin workspace called arc_ws) to run with the navigation stack.
I have a slightly modified launch file from navigation_stage/launch. It looks as follows:
arc_ws/src/arc_navigation/launch/default.launch:
↧
Clearing of obstacle layer in the layered_costmap
Hi all,
I have a `layered_costmap` with `static_layer`, `obstacle_layer` (for Lidar and Kinect) and `inflation_layer` and there are situations when I need to clear out the `obstacle_layers` manually in the code. I am working on full coverage and I want to clear out the obstacle layer when the robot reaches the goal and starts going to the next goal so that it can cover more area. What is the best way to clear out the entire obstacle layer and remove all obstacles (which are not in the static_map) manually in the code (maybe in `move_base.cpp`) ? I don't want to make any changes to the `static_layer`, just want to clear the `obstacle_layer`.
**Update 1 :**
I tried using `/move_base/clearCostmapsService` for which I added a piece of code in `move_base.cpp` itself (for now) so that I can test it by giving goals from RVIZ. I added the code in the `executeCb` function of `move_base.cpp` which gets called when a goal is received. Here is the code snippet :
void MoveBase::executeCb(const move_base_msgs::MoveBaseGoalConstPtr& move_base_goal)
{
if(!isQuaternionValid(move_base_goal->target_pose.pose.orientation)){
as_->setAborted(move_base_msgs::MoveBaseResult(), "Aborting on goal because it was sent with an invalid quaternion");
return;
}
///// Added on 01/13/2016
boost::unique_lock lock1(planner_mutex_);
runPlanner_ = false;
std_srvs::Empty srv;
if(clear_costmaps_client.call(srv))
ROS_INFO("I got the goal and the costmap layers are reset!!!!!"); // It prints this and continues but the costmap is not reset properly, it takes some time after this for the costmap to properly reset
lock1.unlock();
/////
geometry_msgs::PoseStamped goal = goalToGlobalFrame(move_base_goal->target_pose);
//we have a goal so start the planner
boost::unique_lock lock(planner_mutex_);
planner_goal_ = goal;
runPlanner_ = true;
planner_cond_.notify_one();
lock.unlock();
current_goal_pub_.publish(goal);
std::vector global_plan;
Using the `clearCostmapsService`, the map is successfully cleared but the problem is that path planning is done before the map can filled with the `static_layer` (at this time, the map is basically empty and contains no obstacles) so the path is planned through the obstacles in the `static_layer` which I don't want. I want the costmap should be cleared and then filled again with static_layer and sensor_data and then path planning should be done. Does anyone have any idea what can be the issue in calling `clearCostmapService` shown in the code snippet above?
Thanks in advance.
Naman
↧