Hey I want to use the Navigation Stack on my robot with a laser scanner and wheel odometry. Everything is working fine but when I send goals it doesnt work. The problem is that the laser scanner is just in front of the robot, so behind the laserscanner there are some points detected and the navigation stack interprets them as obstacles. Therefore I have always some obstacles in front of my robot and it doenst move anymore. How can I tell my robot that these data are no obstacles and it should ignore them? Do I have to adjust the raytrace_range? What exactly is the raytrace range about?
Thanks in advance :)
↧
ignore obstacles behind the laser
↧
how to set-up /tf_static ?
I’m setting up the move_base on our robot to allow autonomous navigation.
In order to publish the static transform between base_laser and base_link and reduce the load on the “communication” link, I want to use the tf_static topic of tf2 instead of the tf:broadcaster. I don’t understand how to do that. Could you help me?
Is it possible for move_base to use transform publish on tf_static topic?
Best regards,
↧
↧
how to remove forward bias in move_base
I have a robot that senses and moves in reverse just as well as in forward. However, move_base trajectories are highly biased toward turning the robot around and moving forward. I tried setting prefer_forward_cost_function to 0.0 and also tied turning on and off DWA, but these have no apparent effect.
Is there some way to remove the forward bias in move_base?
↧
Is AMCL mandatory for outdoor robots?
Dear all,
I'm new in the ROS world and I have a question that would seem to be stupid for most of you but we all have to start somewhere.
I have trouble to understand the role of AMCL. I believe that AMCL is used by indoor robots to find a localization of the robot on a pre-loaded map (made with laserscan). Am I wrong?
My robot will be used outdoor with GPS, IMU, Wheel odometer and a laser scan. So I don’t need to include AMCL in the move_base node? Could you confirm that I can use the navigation stack without the AMCL node?
All the transformations from odom to map (publish initially by AMCL) will be managed by localization stack (ukf_localization_node or ekf_localization_node). Am I right?
Best regards
↧
Sequence of execution of move_base
Hi,
I have a mobile robot and would like it to navigate around the building. I already have a map of the building. I am using Wheel Encoders to generate odometry. I am feeding the output of Wheel encoders and IMU to robot_pose_ekf (http://wiki.ros.org/robot_pose_ekf) and then using AMCL for localization. Finally, I have the move_base package which plans the path and sends command velocities to the motors.
Assuming robot is at its starting position and it knows its path to the goal, my question is what is the sequence of steps after that:: ?
1. Local planner generates command velocities and sends its to the motors and then Wheel encoders start and generate odometry message which is fed into move_base. But again move_base needs some input odometry message, will that be just NULL to begin with?
2. Or, you give some initial default odometry message from wheel encoders to move_base which is used by move_base to generate command velocities and the cycle continues?
Hope I have made myself clear.
Thanks in advance.
Naman
↧
↧
How to add move_base node in a crowd simulator
A simulator for crowded Pedestrian in ROS is [pedsim_ros](https://github.com/srl-freiburg/pedsim_ros) . However, this simulator doesn't have navigation package for a robot. So I am considering to add one into it. To do this, another simulator [navigation_stage](http://wiki.ros.org/navigation_stage) using move_base and stage_ros is referred.
A figure from rqt_graph that shows running nodes from navigation_stage is shown below.
From above figure, stageros will be replaced with pedsim_ros.
I think some topics /odom /base_pose_ground_truth /tf can be simulated in Pedsim_ros. So now I have two questions:
1, how to simulate topic /base_scan and sensor information is not need in pedsim_ros for now. Can I simulate the movement of a robot using move_base without /base_scan.
2, how the move_base get the simulate robot in Rviz. The pedsim_ros depends on the rviz. A .dae file is used as 3D shape of the robot. Unlike a simulated turtlebot which has its own tf tree, this simulated robot doesn't has its own tf tree. Then how the move_base drives this 3D shap move? Is a 2D postion (x, y) within frame like "base_footprint" enougth?
Looking forwards to any advices. Thanks
Hopefully, one of the authors of pedsim_ros @makokal and @Procópio Silveira Stein who also found pedsim_ros could give me advices. Thank!
↧
robot starts drifiting/rotating in RVIZ, issues with odometry data or amcl
Hi all,
I have a mobile robot and I would like it to navigate around the building and I already have a map of the building. I am using wheel encoders to generate [odometry message](http://wiki.ros.org/navigation/Tutorials/RobotSetup/Odom), [robot_pose_ekf](http://wiki.ros.org/robot_pose_ekf) to fuse data from IMU and wheel_encoders, [amcl](http://wiki.ros.org/amcl) for localization and [move_base](http://wiki.ros.org/move_base) for planning. I am using hokuyo laser for navigation. The transformations and tf tree seems to be correct.
Once I start the robot (initial pose of the robot is specified using the parameters of amcl), everything looks good, I have attached the RVIZ image below:
Now, when I rotate the robot at its initial position manually just to see whether the odometry data and localization is working properly, say I rotate the robot by 90 degrees in clockwise direction and then again 90 degrees in anticlockwise direction manually to bring it to the original position, it seems to be working at first but after some time, the robot in RVIZ starts drifting although the actual robot is stationary. It will keep on drifting and will stop at some random and wrong position. I have attached images below (the actual position of the robot is same as the above image):
Also, when I give a goal to the robot, it is able to go towards the goal position but once it is close to the goal position, it again starts behaving in a weird manner (starts rotating in a random way which messes up the localization of the robot).
I am not able to figure out whether the problem lies in the odometry data or amcl localization. If anyone has any idea about how to solve such an issue, any help will be greatly appreciated. Let me know if you need more information from my side.
Thanks in advance.
Naman Kumar
↧
Using the estimated robot pose from robot_pose_ekf with amcl
Hi all,
I am using [robot_pose_ekf](http://wiki.ros.org/robot_pose_ekf) to fuse data from Wheel encoders and IMU to estimate the 3D pose of the robot. Then, I am using [amcl](http://wiki.ros.org/amcl) to take care of odometry drift and finally the [move_base](http://wiki.ros.org/move_base) package does the navigation. I am generating the odom message of the type `nav_msgs/Odometry` from the wheel encoders which is used by the [base_local_planner](http://wiki.ros.org/base_local_planner?distro=indigo). I know robot_pose_ekf provides odom_combined to base_link transformation which is used by amcl.
My question is after robot_pose_ekf fuses the data from wheel encoders and IMU and generates the estimated 3D pose of the robot of the type `geometry_msgs/PoseWithCovarianceStamped` on the topic `robot_pose_ekf/odom_combined`, how and where is this output used in the navigation package as a whole (move_base or amcl)?
Thanks in advance.
Naman Kumar
↧
robot_base_frame parameter in move_base
Hi all,
I have a mobile robot with IMU, wheel encoders and hokuyo laser. I am following [this](http://answers.ros.org/question/11682/robot_pose_ekf-with-an-external-sensor/) to set up the transformations and all the frames. I am using robot_pose_ekf to fuse data from IMU and wheel encoders and get the `odom_combined -> base_footprint` transformation. As suggested in the above link, in wheel_odometry, `odom_combined` is the header frame id and `base_footprint` is the child_frame_id and I have a fixed transformation from `base_footprint->base_link` . Now my question is what should be the robot_base_frame parameter in `global_costmap_params.yaml` and `local_costmap_params.yaml` in move_base? Should it be base_link(this is the default) or base_footprint and why?
Thanks in advance.
Naman Kumar
↧
↧
Control Loop with dwa_local_planner is too slow due to overhead... Help needed
I'm using move_base with dwa_local_planner, and I'm trying to figure out why the speed of my control loop is so far from 10Hz (Is it normal to have only ~2Hz?).
To learn which step took most of the time, I simply printed out time stamps while executing the function DWAPlannerROS::computeVelocityCommands (see the bottom of the post for the locations of these messages). It seems that the two function calls that take most of the time are getLocalPlan() and isPositionReached().
Does anyone know how to reduce the time on these functions? e.g., reduce map size (257kb currently), or some parameters to be set? Thank you
[ INFO] [1430424280.160307012]: get robot pose timed at 0.000026195 seconds
[ INFO] [1430424280.352760701]: get local plan timed at 0.192470976 seconds
[ INFO] [1430424280.352834558]: transform plan timed at 0.192578670 seconds
[ INFO] [1430424280.353093892]: update plan and local cost timed at 0.192832470 seconds
[ INFO] [1430424280.474545370]: check whether we are at the goal. timed at 0.314256730 seconds
[ INFO] [1430424280.496985218]: Cycle time: 0.022304058 (this is printed out from dwaComputeVelocityCommands() )
[ INFO] [1430424280.497108855]: dwa compute velocity commands timed at 0.336858770 seconds
[ INFO] [1430424280.497170723]: publish plan timed at 0.336922393 seconds
......
[ WARN] [1430424280.497311207]: Control loop missed its desired rate of 2.0000Hz... the loop actually took 0.5629 seconds
Below is the original DWAPlannerROS::computeVelocityCommands. You can see the locations of ROS_INFO I added to print out time stamps.
bool DWAPlannerROS::computeVelocityCommands(geometry_msgs::Twist& cmd_vel) {
ros::WallTime start = ros::WallTime::now();
// dispatches to either dwa sampling control or stop and rotate control, depending on whether we have been close enough to goal
if ( ! costmap_ros_->getRobotPose(current_pose_)) {
ROS_ERROR("Could not get robot pose");
return false;
}
ROS_INFO("get robot pose timed at %.9f seconds", (ros::WallTime::now()-start).toSec());
std::vector transformed_plan;
if ( ! planner_util_.getLocalPlan(current_pose_, transformed_plan)) {
ROS_ERROR("Could not get local plan");
return false;
}
ROS_INFO("get local plan timed at %.9f seconds", (ros::WallTime::now()-start).toSec());
//if the global plan passed in is empty... we won't do anything
if(transformed_plan.empty()) {
ROS_WARN_NAMED("dwa_local_planner", "Received an empty transformed plan.");
return false;
}
ROS_DEBUG_NAMED("dwa_local_planner", "Received a transformed plan with %zu points.", transformed_plan.size());
ROS_INFO("transform plan timed at %.9f seconds", (ros::WallTime::now()-start).toSec());
// update plan in dwa_planner even if we just stop and rotate, to allow checkTrajectory
dp_->updatePlanAndLocalCosts(current_pose_, transformed_plan);
ROS_INFO("update plan and local cost timed at %.9f seconds", (ros::WallTime::now()-start).toSec());
if (latchedStopRotateController_.isPositionReached(&planner_util_, current_pose_)) {
ROS_INFO("check whether we're at the goal (yes) timed at %.9f seconds", (ros::WallTime::now()-start).toSec());
//publish an empty plan because we've reached our goal position
std::vector local_plan;
std::vector transformed_plan;
publishGlobalPlan(transformed_plan);
publishLocalPlan(local_plan);
base_local_planner::LocalPlannerLimits limits = planner_util_.getCurrentLimits();
return latchedStopRotateController_.computeVelocityCommandsStopRotate(
cmd_vel,
limits.getAccLimits(),
dp_->getSimPeriod(),&planner_util_,
odom_helper_,
current_pose_,
boost::bind(&DWAPlanner::checkTrajectory, dp_, _1, _2, _3));
} else {
ROS_INFO("check whether we're at the goal (no) timed at %.9f seconds", (ros::WallTime::now()-start).toSec());
bool isOk = dwaComputeVelocityCommands(current_pose_, cmd_vel);
ROS_INFO("dwa compute velocity commands timed at %.9f seconds", (ros::WallTime::now()-start).toSec());
if (isOk) {
publishGlobalPlan(transformed_plan);
} else {
ROS_WARN_NAMED("dwa_local_planner", "DWA planner failed to produce path.");
std::vector empty_plan;
publishGlobalPlan(empty_plan);
}
ROS_INFO("publish plan timed at %.9f seconds", (ros::WallTime::now()-start).toSec());
return isOk;
}
}
↧
problem with robot localization using amcl
Hi all,
I have a mobile robot and I would like it to navigate in a room, I already have a map of the room. I am using wheel encoders for the odometry, [robot_pose_ekf](http://wiki.ros.org/robot_pose_ekf) for fusing data from wheel encoders and IMU and to get the `odom_combined -> base_footprint` transformation. Then , I have [amcl](http://wiki.ros.org/amcl) for localization and [move_base](http://wiki.ros.org/move_base) is doing the planning.
I am able to start everything smoothly and give the goal through RVIZ and the tf tree looks correct:
After I give the goal, robot starts moving towards it and on the way, its localization gets messed up. Once, it is close to the goal it starts rotating in a random manner which also messes up the localization of the robot. The problem is more common when it is near to the goal, it starts rotating randomly and gets lost. Also sometimes, I get the warning:
Clearing costmap to unstuck robot (3.000000m).
Rotate recovery behavior started.
but I dont see the robot being stuck. I think there is some issue with amcl but I am not sure.
I saved all the data in a bag file and ran it and made two videos for two different goal positions. In both cases, the correct orientation should be pi/2 (south direction):
[Video - 1](https://www.youtube.com/watch?v=sImBoaYiECs)
[Video - 2](https://www.youtube.com/watch?v=_OELo4rNPU8)
The parameters for amcl is shown below:
**amcl.launch**
↧
Move_base with non-rotational robot
Hello,
I'm using move_base with a non-holonomic, non-rotational robot. Everything is working as it should but i have a big problem and it's that my robot can't make in-place rotations. It's a robot sphere as you can see in the following links:
https://www.youtube.com/watch?v=1DlGnla-klk
https://www.youtube.com/watch?v=XrpZtsQ1wac
I set the following base local planner parameters:
## Base local planner parameters.
TrajectoryPlannerROS:
acc_lim_x: 1.0
acc_lim_y: 0.0
acc_lim_theta: 0.1
max_vel_x: 2.2
min_vel_x: 0.55
max_vel_theta: 0.2
min_vel_theta: -0.2
min_in_place_vel_theta: 0.0
escape_vel: -0.55
holonomic_robot: false
yaw_goal_tolerance: 0.1
xy_goal_tolerance: 5.0
sim_granularity: 0.1
angular_sim_granularity: 0.04
vx_samples: 5
vtheta_samples: 8
meter_scoring: true
pdist_scale: 0.6
gdist_scale: 0.8
occdist_scale: 0.01
dwa: false
global_frame_id: odom_combined
oscillation_reset_dist: 0.0
Is there a way to set off the in-place rotations? The other thing is that every time the program send an in-place rotation into the /cmd_vel topic, it puts a value of 1.0 or -1.0 on the angular z as shown below
---
linear:
x: 0.0
y: 0.0
z: 0.0
angular:
x: 0.0
y: 0.0
z: -1.0
---
Why is it doing this if i have set the max_vel_theta to 0.2 and the min_vel_theta to -0.2?
Also, when passing short distancies to move form base_footprint it send commands to cmd_vel like the following:
---
linear:
x: 0.414027588531
y: 0.0
z: 0.0
angular:
x: 0.0
y: 0.0
z: 0.894736842105
---
being this unrelated to the values set in the base_local_planner_params.yaml where min_vel_x is 0.55 and max_vel_theta is 0.2.
I've tried changing the min_in_place_vel_theta from 0.0 to 0.5 to see if it takes it as the in-place rotational value but it keep showing me the same thing. Tried setting from true to false the dwa for small values of vel_theta and got the same thing.
If anyone have an answer to all of the questions or even a single one it'd be really good!. If you need some more information just ask. Thanks for your time.
Salvador
↧
wrong robot orientation at the goal
Hi all,
You must have seen lot of posts saying that robot keeps on rotating when it is near the goal but I have an opposite problem. In my case, when the robot reaches the goal within `xy_goal_tolerance`, it turns slowly to correct its orientation but then it stops outside the `yaw_goal_tolerance` at the goal. When I did `rostopic echo /cmd_vel`, the angular velocity (`angular.z`) is getting published (0.5 in my case) but the robot is not rotating. I am using wheel_encoders for odometry, amcl for localization and move_base for navigation with local planner as TrajectoryPlanner. I am not able to figure out what is causing such a behavior. Has anyone encountered such an issue before? Let me know if you need more information from my side.
base_local_planner_params.yaml
#For full documentation of the parameters in this file, and a list of all the
#parameters available for TrajectoryPlannerROS, please see
#http://www.ros.org/wiki/base_local_planner
TrajectoryPlannerROS:
#Set the acceleration limits of the robot
acc_lim_th: 2.5
acc_lim_x: 2.0
acc_lim_y: 0
#Set the velocity limits of the robot
max_vel_x: 1.0
min_vel_x: 0.1
max_vel_theta: 1.0
min_vel_theta: -1.0
min_in_place_vel_theta: 0.4
#The velocity the robot will command when trying to escape from a stuck situation
escape_vel: -0.1
#For this example, we'll use a holonomic robot
holonomic_robot: false
#Set the tolerance on achieving a goal
xy_goal_tolerance: 0.2
yaw_goal_tolerance: 0.2
latch_xy_goal_tolerance: false
#We'll configure how long and with what granularity we'll forward simulate trajectories
sim_time: 1.5
sim_granularity: 0.025
angular_sim_granularity: 0.025
vx_samples: 8
vtheta_samples: 20
#Parameters for scoring trajectories
goal_distance_bias: 0.8
path_distance_bias: 1.0
gdist_scale: 0.8
pdist_scale: 1.0
occdist_scale: 0.01
heading_lookahead: 0.325
#We'll use the Dynamic Window Approach to control instead of Trajectory Rollout for this example
dwa: false
#How far the robot must travel before oscillation flags are reset
oscillation_reset_dist: 0.05
#Eat up the plan as the robot moves along it
prune_plan: false
# Global Frame id
global_frame_id: odom_combined
Thanks in advance.
Naman Kumar
↧
↧
robot thinks its rotating when it reaches the goal
Hi all,
I have a mobile robot which is navigating around a room. I am using Wheel encoders to generate odometry, amcl for localization and move_base for planning with TrajecotryPlanner as the local planner. The problem which I am having is that once the robot reaches the goal and stops, the robot footprint in RVIZ starts rotating in place although the real robot is stationary which messes up the localization of the robot. The odom message shows 0 velocity in the `geometry_msgs/TwistWithCovariance` part. I feel there is some problem with how odometry is generated but I am not sure.
Does anyone have any idea why is such a thing happening? Let me know if you need more information from me.
Thanks in advance.
Naman Kumar
↧
how set a circlular footprint? move_base planner's "Stuck" issue
Hi,
probably a silly question, but how can one set a circular Footprint for the robot? couldn't find a useful explanation online. I also tried `robot_radius` parameter (i read that its not the way to go) but i still see a rectangle footprint in RVIZ. can someone please show me an example on how to set a circular footprint? (I use a Turtlebot).
One reason that i want to set this circular footprint is that because move_base (DWA planner) sends the robot too close to the sharp corners while planning a path and gets STUCK. then it needs to execute an in-place rotation (recovery) to clear Costmap and it sends Warnings to the console, saying that (There is a chance to hit an obstacle if the robot rotates). obviously this should not be the case for a circular footprint base.
PS: is there an out of the box escape solution for when the robot is STUCK. so it move a bit backwards and re-plan the path?
thank you for the help.
↧
meter_scoring: move_ base navigation
Hi all,
I'm using move_base for 2D navigation and it's working.the only thing is that i keep getting the a warn about having meter_scoring not set. the warn is the following:
Trajectory Rollout planner initialized with param meter_scoring not set. Set it to true to make your settings robust against changes of costmap resolution
And in my base_local_planner_params i set it to true. I'm having good and bad results from time to time, could this be the problem? what can i do to stop having this warn??
Thank you for your time,
Salvador
↧
For frame[base_link]: No transform to fixed frame using IMU
Hi all,
I have a mobile robot and I would like it to navigate around a room and I already have a map of the room. I am using rotary encoders for odometry. I am using [robot_pose_ekf](http://wiki.ros.org/robot_pose_ekf) to merge data from rotary encoders and IMU. I am using [amcl](http://wiki.ros.org/amcl) for localization and [move_base](http://wiki.ros.org/move_base) for planning. Now the problem is, when I set the fixed frame in RVIZ as map, the status of IMU keeps on oscillating from `Status:OK` to following:
The tf tree is shown which looks good to me:
[C:\fakepath\tf_tree.png](/upfiles/14313589068939156.png)
**IMU part of the Code**
For IMU, I am using http://wiki.ros.org/phidgets_imu and http://wiki.ros.org/imu_filter_madgwick.
↧
↧
unable to clear obstaces in the costmap
Hi all,
I have a mobile robot and I would like it to navigate around a room. I already have a map of the room. I am using Rotary Encoders for Odometry, [robot_pose_ekf](http://wiki.ros.org/robot_pose_ekf) to merge data from Rotary encoders and IMU, [amcl](http://wiki.ros.org/amcl) for localization, [move_base](http://wiki.ros.org/move_base) for planning with Trajectory Planner as a local planner. I seem to have a problem with clearing obstacles from the costmap in certain cases (not all cases, in some cases, obstacles are cleared without any issue). As seen in the following images, the obstacle on the left of the robot was successfully cleared whereas it is not the case for obstacles in front of the robot. Although the laser scan is coming from a far away obstacle but the obstacles on the way are not cleared (in front of the robot).
**Before**
**After**
Also, I have changed all the inf readings from the [hokuyo_node](http://wiki.ros.org/hokuyo_node) to max_range + 1. The only reason which I can think of is the obstacles are cleared only if the laser scan comes from an obstacle behind it which is part of the original static map but I am not able to see the reason behind this. I am not able to figure out how to make sure that all obstacles are successfully cleared. Does anyone have any idea about how to solve such an issue?
**Update 1** : I am using [this hokuyo sensor](http://www.robotshop.com/en/hokuyo-urg-04lx-ug01-scanning-laser-rangefinder.html?gclid=CjwKEAjwycaqBRCSorjE7ZewsmUSJABWzM54eLZeeXucDTwSlGNd8QC_63i-M_1uGP7LmuArXrVFSxoCAlXw_wcB) and the max_range for this is 5.6 m. So, when I change all the inf readings from the hokuyo_node to 5.59 m (< max_range), all obstacles are cleared successfully but when I make all the inf readings 5.6 m (>= max_range), I again have the same problem mentioned in the original question. I have attached an image for the case when all inf readings are changed to 5.59 m:
**Update 2** :
#Configuration for the sensors that the costmap will use to update a map
obstacle_layer:
observation_sources: laser_scan_sensor
laser_scan_sensor: {data_type: LaserScan, sensor_frame: /laser, topic: /scan, expected_update_rate: 0.4,
observation_persistence: 0.0, marking: true, clearing: true, max_obstacle_height: 2.0, min_obstacle_height: 0.0}
# All other parameters have default values
Thanks in advance.
Naman Kumar
↧
min_in_place_vel_theta parameter in base_local_planner
Hi all,
I am having some issues with the orientation of the robot once it reaches the goal (within `xy_goal_tolerance`). Once it is at the goal, robot tries to rotate to correct its orientation but sometimes, it fails. Although the base_local_planner is sending the velocity (`angular.z =0.4` when `min_in_place_vel_theta = 0.4`), the robot is not able to rotate but that is because this velocity is less. When I increase the `min_in_place_vel_theta` to 0.8, still sometimes, `angular.z = 0.4` when the robot is near the goal and the robot fails to correct its orientation. I feel the robot is not able to turn in place and because of that it fails to correct its orientation. I thought the local planner will always send at least min_in_place_vel_theta when it wants the robot to turn in place but that is not happening in my case. What else is needed to make sure the robot turns without any issues once it is at the goal? I hope I have made it clear.
base_local_planner_params.yaml
TrajectoryPlannerROS:
#Set the acceleration limits of the robot
acc_lim_th: 3.2
acc_lim_x: 2.0
acc_lim_y: 0
#Set the velocity limits of the robot
max_vel_x: 0.8
min_vel_x: 0.1
max_vel_theta: 1.5
min_vel_theta: -1.5
min_in_place_vel_theta: 0.8
#The velocity the robot will command when trying to escape from a stuck situation
escape_vel: -0.1
#For this example, we'll use a holonomic robot
holonomic_robot: false
#Set the tolerance on achieving a goal
xy_goal_tolerance: 0.15
yaw_goal_tolerance: 0.17
latch_xy_goal_tolerance: false
#We'll configure how long and with what granularity we'll forward simulate trajectories
sim_time: 1.5
sim_granularity: 0.025
angular_sim_granularity: 0.025
vx_samples: 5
vtheta_samples: 20
#Parameters for scoring trajectories
goal_distance_bias: 0.8
path_distance_bias: 1.0
gdist_scale: 0.8
pdist_scale: 1.0
occdist_scale: 0.01
heading_lookahead: 0.325
#We'll use the Dynamic Window Approach to control instead of Trajectory Rollout for this example
dwa: false
#How far the robot must travel before oscillation flags are reset
oscillation_reset_dist: 0.05
#Eat up the plan as the robot moves along it
prune_plan: false
# Global Frame id
global_frame_id: odom_combined
Thanks in advance.
Naman Kumar
↧
no range readings received warning while using range_sensor_layer
Hi all,
I am using Ultrasound sensors and Hokuyo laser for navigation. I am using [range_sensor_layer](http://wiki.ros.org/range_sensor_layer) for ultrasound sensors. The problem is when I publish the `sensor_msgs/Range` message and use the range_sensor_layer, I get the following warning and therefore `range_sensor_layer` is not able to modify the costmap:
[ WARN] [1431715266.304546076]: No range readings received for 389.80 seconds, while expected at least every 1.00 seconds.
I am not able to see why am I getting this warning, everything seems to be set up and working properly (described below).
`sensor_msgs/Range` message is published by the arduino on topic `/US1` with `frame_id: /us1` and the `move_base_node` is subscribing to it:
>> rostopic info /US1
Type: sensor_msgs/Range
Publishers:
* /serial_node (http://namankumar-Inspiron-5521:33329/)
Subscribers:
* /move_base_node (http://namankumar-Inspiron-5521:53748/)
* /rviz_1431714908738859698 (http://namankumar-Inspiron-5521:59073/)
Also, when I do `rostopic echo /US1`, I get the correct range values:
header:
seq: 6186
stamp:
secs: 1431715507
nsecs: 646532096
frame_id: /us1
radiation_type: 0
field_of_view: 0.34999999404
min_range: 0.019999999553
max_range: 3.0
range: 184.0
The **tf tree** is properly set up:
**global_costmap_params.yaml**
plugins:
- {name: static_layer, type: "costmap_2d::StaticLayer"}
- {name: obstacle_layer, type: "costmap_2d::ObstacleLayer"}
- {name: sonar_layer, type: "range_sensor_layer::RangeSensorLayer"}
- {name: inflation_layer, type: "costmap_2d::InflationLayer"}
#Configuration for the sensors that the costmap will use to update a map
obstacle_layer:
observation_sources: laser_scan_sensor
laser_scan_sensor: {data_type: LaserScan, sensor_frame: /laser, topic: /scan, expected_update_rate: 0.4,
observation_persistence: 0.0, marking: true, clearing: true, max_obstacle_height: 2.0, min_obstacle_height: 0.0, inf_is_valid: true}
sonar_layer:
topics: ['/US1']
no_readings_timeout: 1.0
clear_threshold: 0.2
mark_threshold: 0.8
clear_on_max_reading: true
**local_costmap_params.yaml**
plugins:
- {name: obstacle_layer, type: "costmap_2d::ObstacleLayer"}
- {name: sonar_layer, type: "range_sensor_layer::RangeSensorLayer"}
- {name: inflation_layer, type: "costmap_2d::InflationLayer"}
#Configuration for the sensors that the costmap will use to update a map
obstacle_layer:
observation_sources: laser_scan_sensor
laser_scan_sensor: {data_type: LaserScan, sensor_frame: /laser, topic: /scan, expected_update_rate: 0.4,
observation_persistence: 0.0, marking: true, clearing: true, max_obstacle_height: 2.0, min_obstacle_height: 0.0, inf_is_valid: true}
sonar_layer:
topics: ['/US1']
no_readings_timeout: 1.0
clear_threshold: 0.2
mark_threshold: 0.8
clear_on_max_reading: true
Does anyone have any idea what is going wrong here? Any help will be appreciated.
Thanks a lot.
Naman Kumar
↧