neato & ros : Waiting on transform from base_link to map to become available before running costmap, tf error
Hi, I'm trying to make ROS working with my neato :
This command work perfectly, the laser start rotating:
roslaunch neato_node bringup.launch
started roslaunch server http://micka-VirtualBox:53652/
> SUMMARY
> ========
>
> PARAMETERS * /neato/port:
> /dev/ttyUSB0 * /rosdistro: indigo *
> /rosversion: 1.11.10
>
> NODES /
> laser_to_base (tf/static_transform_publisher)
> neato (neato_node/neato.py)
>
> auto-starting new master
> process[master]: started with pid
> [19892]
> ROS_MASTER_URI=http://localhost:11311
>
> setting /run_id to
> ad462950-d559-11e4-9cd8-0800270465f1
> process[rosout-1]: started with pid
> [19905] started core service [/rosout]
> process[laser_to_base-2]: started with
> pid [19922] process[neato-3]: started
> with pid [19933] [INFO] [WallTime:
> 1427554187.619410] Using port: /dev/ttyUSB0
But this command :
roslaunch 2dnav_neato move_base.launch
give me an error I suppose :
started roslaunch server http://micka-VirtualBox:33789/
SUMMARY
========
PARAMETERS
* /move_base/TrajectoryPlannerROS/acc_lim_th: 0.5
* /move_base/TrajectoryPlannerROS/acc_lim_x: 0.5
* /move_base/TrajectoryPlannerROS/acc_lim_y: 0.0
* /move_base/TrajectoryPlannerROS/dwa: False
* /move_base/TrajectoryPlannerROS/goal_distance_bias: 0.8
* /move_base/TrajectoryPlannerROS/heading_lookahead: 0.325
* /move_base/TrajectoryPlannerROS/holonomic_robot: False
* /move_base/TrajectoryPlannerROS/max_rotational_vel: 0.4
* /move_base/TrajectoryPlannerROS/max_vel_x: 0.15
* /move_base/TrajectoryPlannerROS/min_in_place_rotational_vel: 0.3
* /move_base/TrajectoryPlannerROS/min_vel_x: 0.01
* /move_base/TrajectoryPlannerROS/path_distance_bias: 0.6
* /move_base/TrajectoryPlannerROS/sim_time: 1.5
* /move_base/TrajectoryPlannerROS/vtheta_samples: 20
* /move_base/TrajectoryPlannerROS/vx_samples: 6
* /move_base/TrajectoryPlannerROS/xy_goal_tolerance: 0.1
* /move_base/TrajectoryPlannerROS/yaw_goal_tolerance: 0.05
* /move_base/controller_frequency: 5.0
* /move_base/global_costmap/base_scan/clearing: True
* /move_base/global_costmap/base_scan/data_type: LaserScan
* /move_base/global_costmap/base_scan/marking: True
* /move_base/global_costmap/base_scan/sensor_frame: base_laser
* /move_base/global_costmap/base_scan/topic: base_scan
* /move_base/global_costmap/footprint: [[0.1, 0.1], [0.1...
* /move_base/global_costmap/global_frame: /map
* /move_base/global_costmap/inflation_radius: 0.42
* /move_base/global_costmap/observation_sources: base_scan
* /move_base/global_costmap/obstacle_range: 2.5
* /move_base/global_costmap/publish_frequency: 0.0
* /move_base/global_costmap/raytrace_range: 5.0
* /move_base/global_costmap/robot_base_frame: base_link
* /move_base/global_costmap/robot_radius: 0.3
* /move_base/global_costmap/static_map: True
* /move_base/global_costmap/transform_tolerance: 1.0
* /move_base/global_costmap/update_frequency: 1.0
* /move_base/local_costmap/base_scan/clearing: True
* /move_base/local_costmap/base_scan/data_type: LaserScan
* /move_base/local_costmap/base_scan/marking: True
* /move_base/local_costmap/base_scan/sensor_frame: base_laser
* /move_base/local_costmap/base_scan/topic: base_scan
* /move_base/local_costmap/footprint: [[0.1, 0.1], [0.1...
* /move_base/local_costmap/global_frame: odom
* /move_base/local_costmap/height: 2.5
* /move_base/local_costmap/inflation_radius: 0.42
* /move_base/local_costmap/observation_sources: base_scan
* /move_base/local_costmap/obstacle_range: 2.5
* /move_base/local_costmap/publish_frequency: 1.0
* /move_base/local_costmap/raytrace_range: 5.0
* /move_base/local_costmap/resolution: 0.025
* /move_base/local_costmap/robot_base_frame: base_link
* /move_base/local_costmap/robot_radius: 0.3
* /move_base/local_costmap/rolling_window: True
* /move_base/local_costmap/static_map: False
* /move_base/local_costmap/transform_tolerance: 1.0
* /move_base/local_costmap/update_frequency: 2.0
* /move_base/local_costmap/width: 2.5
* /rosdistro: indigo
* /rosversion: 1.11.10
* /use_sim_time: False
NODES
/
amcl (amcl/amcl)
map_server (map_server/map_server)
move_base (move_base/move_base)
ROS_MASTER_URI=http://localhost:11311
core service [/rosout] found
process[map_server-1]: started with pid [20963]
process[amcl-2]: started with pid [20978]
process[move_base-3]: started with pid [21020]
[ WARN] [1427554455.665988562]: Waiting on transform from base_link to map to become available before running costmap, tf error:
[1427554455.665988562]: Waiting on transform from base_link to map to become available before running costmap, tf error:
Asked by mickae1 on 2015-03-28 10:43:34 UTC
Answers
The logs are quite clear: your global cost map is waiting for map -> base_link transformation available. Usually this transformation need two others to be calculated:
- map -> odom, broadcasted by amcl;
- odom -> base_link, broadcasted by odometry.
Run
rosrun tf view_frames
to check your tf tree.
UPDATE
As I supposed odom -> base_link transformation is missing!!
And why I can't see the laser scan ?
This is crucial since you set RViz to use map as fixed frame. Laser scan is attached to base_laser_link and, in order to show it in map frame, a transformation is needed but, as you can see from the tree, there is no linkage from base_laser_link and map.
Next question should be: why odom -> base_link is missing? I have no experience with neato robot but from you log I can see:
NODES
/
amcl (amcl/amcl)
map_server (map_server/map_server)
move_base (move_base/move_base)
It seems that the neato node (who have to publish odom -> base_link transformation, odom and laser data) was not started! Please use
rqt_graph
and post the result (this tool will show all running node and published/subscribed topic). Try also:
rostopic list
to check all published topics.
UPDATE
neato node is running, this is ok. base_scan is published too but not subscribed by gmapping (as shown by rqt_graph) since it expect it as scan topic. You have to remap base_scan to scan when launch gmapping.
Furthermore try:
rostopic echo base_scan
This will print out the published laser scan data. With this command we can be sure some data is published and you can also check (in the printed message header) to which frame the laser data is attached to. Set this frame as fixed frame in RViz and you should be able to see scan data.
Asked by afranceson on 2015-03-29 05:40:16 UTC
Comments
Thx for the answer. This is the result of the command : http://postimg.org/image/rbytdrfs7/
Asked by mickae1 on 2015-03-29 07:37:12 UTC
And why I can't see the laser scan ? http://postimg.org/image/oteei4pxf/
Asked by mickae1 on 2015-03-29 07:55:45 UTC
http://postimg.org/image/pvd3edcyl/ /amcl/parameter_descriptions /amcl/parameter_updates /amcl_pose /base_scan /cmd_vel /initialpose /map /map_metadata /move_base/current_goal /move_base/goal /move_base_simple/goal /odom /particlecloud /rosout /rosout_agg /slam_gmapping/entropy /tf /tf_static
Asked by mickae1 on 2015-03-29 11:45:50 UTC
I tried to see the laser scan with other fixed frame, but didn't work (_(
Asked by mickae1 on 2015-03-29 11:51:06 UTC
Thx for the help ! I managed to understand better ros and I discovered that the neato driver was waiting for data ....My problems come from a different driver in my neato !
Asked by mickae1 on 2015-03-31 06:26:57 UTC
Glad to have been helpful!
Asked by afranceson on 2015-04-01 02:08:36 UTC
Comments