Robot_localization and Hector mapping

Hi guys, I am trying to run `hector_mapping` in concomitant with `robot_localization`. I think all my configurations are correct, but for more clarity here the conf: and then # For parameter descriptions, please refer to the template parameter files for each node. ekf_se_odom: frequency: 30 sensor_timeout: 0.1 two_d_mode: true transform_time_offset: 0.0 transform_timeout: 0.0 print_diagnostics: true debug: true debug_out_file: /home/matteo/rover_ws/ekf_se_odom.txt map_frame: map odom_frame: odom base_link_frame: base_link world_frame: odom odom0: odom odom0_config: [true, true, false, false, false, false, false, false, false, false, false, true, false, false, false] odom0_queue_size: 10 odom0_nodelay: true odom0_differential: false odom0_relative: true odom0_pose_rejection_threshold: 5 odom0_twist_rejection_threshold: 1 twist0: gps/fix_velocity twist0_config: [false, false, false, false, false, false, true, true, true, false, false, false, false, false, false] twist0_queue_size: 10 twist0_nodelay: true twist0_differential: false twist0_relative: true imu0: imu/data imu0_config: [false, false, false, true, true, true, false, false, false, true, true, true, true, true, true] imu0_nodelay: false imu0_differential: false imu0_relative: true imu0_queue_size: 10 imu0_pose_rejection_threshold: 0.8 # Note the difference in parameter names imu0_twist_rejection_threshold: 0.8 # imu0_linear_acceleration_rejection_threshold: 0.8 # imu0_remove_gravitational_acceleration: true use_control: false process_noise_covariance: [...] initial_estimate_covariance: [...] ekf_se_map: frequency: 30 sensor_timeout: 0.1 two_d_mode: true transform_time_offset: 0.0 transform_timeout: 0.0 print_diagnostics: true debug: true debug_out_file: /home/matteo/rover_ws/ekf_se_map.txt map_frame: map odom_frame: odom base_link_frame: base_link world_frame: map odom0: odom odom0_config: [true, true, false, false, false, false, false, false, false, false, false, true, false, false, false] odom0_queue_size: 10 odom0_nodelay: true odom0_differential: false odom0_relative: true odom0_pose_rejection_threshold: 5 odom0_twist_rejection_threshold: 1 odom1: odometry/gps odom1_config: [true, true, true, false, false, false, false, false, false, false, false, false, false, false, false] odom1_queue_size: 10 odom1_nodelay: true odom1_differential: false odom1_relative: false twist0: gps/fix_velocity twist0_config: [false, false, false, false, false, false, true, true, true, false, false, false, false, false, false] twist0_queue_size: 10 twist0_nodelay: true twist0_differential: false twist0_relative: true imu0: imu/data imu0_config: [false, false, false, true, true, true, false, false, false, true, true, true, true, true, true] imu0_nodelay: true imu0_differential: false imu0_relative: false imu0_queue_size: 10 imu0_remove_gravitational_acceleration: true use_control: false process_noise_covariance: [...] initial_estimate_covariance: [...] Finally navsat conf frequency: 30 delay: 3.0 magnetic_declination_radians: 0.0539 # For lat/long 45.2266641° N , 11.9843053° E yaw_offset: 0.0 # IMU reads 0 facing magnetic north, not east # If this is true, the altitude is set to 0 in the output odometry message. Defaults to false. zero_altitude: true # If this is true, the transform world_frame->utm transform is broadcast for use by other nodes. Defaults to false. broadcast_utm_transform: true # If this is true, the utm->world_frame transform will be published instead of the world_frame->utm transform. # Note that broadcast_utm_transform still has to be enabled. Defaults to false. broadcast_utm_transform_as_parent_frame: true # If this is true, all received odometry data is converted back to a lat/lon and published as a NavSatFix message as # /gps/filtered. Defaults to false. publish_filtered_gps: false # If this is true, the node ignores the IMU data and gets its heading from the odometry source (typically the # /odometry/filtered topic coming from one of robot_localization's state estimation nodes). BE CAREFUL when using this! # The yaw value in your odometry source *must* be world-referenced, e.g., you cannot use your odometry source for yaw # if your yaw data is based purely on integrated velocities. Defaults to false. use_odometry_yaw: false # If true, will retrieve the datum from the 'datum' parameter below, if available. If no 'datum' parameter exists, # navsat_transform_node will wait until the user calls the 'datum' service with the SetDatum service message. wait_for_datum: true # Instead of using the first GPS location and IMU-based heading for the local-frame origin, users can specify the # origin (datum) using this parameter. The fields in the parameter represent latitude and longitude in decimal degrees, # and heading in radians. As navsat_transform_node assumes an ENU standard, a 0 heading corresponds to east. #datum: [55.944904, -3.186693, 0.0] datum: [45.2266143, 11.9842207, 0.0] But I have a problem when running `hector_mapping` seems there is a default error between map and laser scanner. i think it is related to the tf `/map` generated by `navsat_transform_node`. I cannot see the matching between laserscan data and hector map. In the following a picture:  Can someone help me out?