Unable to start costmaps in navigation stack

edit

Hello everyone. I am now working with the Create 2 robot - Roomba 600 platform - with the driver from AutonomyLab and a Hokuyo LRF. Everything is running perfect, but when I try to enable the navigation stack, the terminal does not log activation of obstacle layer and inflation layer, meaning the costmaps are not enabled on Rviz.

Meanwhile in Gazebo everithing works smoothly with the same parameters settings, so I have two computers connected in the same wireless, this is the procedure I take*

1. launch create and hokuyo driver with scan:=base_scan frame_id:="same name written in urdf file"
2. rosrun gmapping slam_gmapping scan:=base_scan _linearUpdate:=0 _angularUpdate:=0 - starts LiveSlam()
3. start move_base node with all the parameters of global and local planner, global and local costmap

Communications is realized with a local VPN, port 1194 over UDP.

I tried many possible solutions but no one seems to work in a stable way, so I would like to ask for your help here. One thing that made me think is about the view_frames output that is very different from gazebo case, which uses use_sim_time = true, so a possible cause I was thinking is about time synchronization.

Il'post here some important screenshot and config settings and outputs:

In common_costmap_params.yaml:

 #Configuration for the sensors that the costmap will use to update a map
observation_sources: base_scan
base_scan: {sensor_frame: hokuyo_link, data_type: LaserScan, topic: /base_scan, expected_update_rate: 0.4,observation_persistence: 0.0, marking: true, clearing: true, max_obstacle_height: 0.4, min_obstacle_height: 0.08}

From navigation stack logging:

[ WARN] [1518088865.446447100]: Timed out waiting for transform from base_footprint to map to become available before running costmap, tf error: Lookup would require extrapolation into the past.  Requested time 1518088839.115352594 but the earliest data is at time 1518088855.527055015, when looking up transform from frame [base_footprint] to frame [map]. canTransform returned after 0.100919 timeout was 0.1.

From view frames:

map->odom->base_footprint->base_link-> to everyone published by robot_state_publisher related to urdf tree

It's showing 20 Hz on slam_gmapping, robot driver and LRF sensor with also:

Most recent transform: 1518088979.565 ( 26.377 sec old)
Buffer length: 4.900 sec

The tf parts published by robot_state_publisher are posting: average rate = 10000 Hz

And in these components of the frames at "most recent transform" I have:

Most recent transform: 0.000 ( 1518089005.943 sec old)
Buffer length: 0.000 sec

The important effect of all of this is that move_base_node ends up to not be a subscriber of /base_scan, so the obstacle plugins cannot enable.

I think wrote the most important effects for me, but if you suggest to post something else i will be happy to. I would be very grateful to the ones who want to give suggestions or ideas.