Hello We are using the robot_localization package to provide a state estimate by fusing IMU-data in 1 ekf_localization_node. We want to use gmapping for slam but we don't exactly know how to configure this in combination with the robot_localization package. In the presentation from Tom Moore on roscon, he told that the output data from gmapping can be fused with IMU-data in a second ekf_localization_node (https://www.osrfoundation.org/tom-moore-working-with-the-robot-localization-package/) but this is the part that I don't get. What I was thinking is that the output from the first ekf_localization_node (Odometry message) can be used as input for the gmapping package, so that there is only 1 ekf_localization_node. If it is possible to fuse IMU-data with data from gmapping, how is it exactly done? Extra: We also have GPS available, is it recommended to fuse this with gmapping because it was more like an OR story(or navsad, or amcl or gmapping) told in the presentation? Kind regards, Stef

I am trying to set up an Extended Kalman Filter, but I probably have some form of simple error. With a single Twist and a single Odometry input, the output Odometry shows the vehicle moving even when stationary, then steadily accelerating as the vehicle begins to move; it is like there is some hidden velocity component in my model. My `twist0` Twist data starts at all zeros (including covariance, although I have valid values in the `ekf_template.yaml` file), in the frame_id `dr`, which is my vehicle zero point on start-up relative to the `map`, which RViz says is (-24762, -53804) - I've set `two_d_mode`. My `odom0` data starts with a pose position of (-24762, -53804) and a twist of all zeros, with frame_id `map` and child_frame_id `dr`. The vehicle is not moving, but I see the `odometry/filtered` topic moving forward, and with both the yellow and purple areas growing as it moves. The topic has a pose growing away from zero, and a linear x twist of 2.6. frame_id is `dr` and child_frame_id of `base_link`. I'm sure I've got something obvious wrong; this is part of a larger system so I have turned off the `publish_tf` option.

Hi, I try to use the acceleration x,y,z from IMU and position x,y,z from VIO to estimate linear velocity x,y,z(on the drone). At first, when the drone is put on the ground, the result of the estimated linear velocity is normal(linear velocity x, y and z are all approximately zero.) But when I move the drone, the linear velocity starts to jump to large value. And the estimated linear velocity is no longer correct. However, I try to only use x and z dimensions, and it works well. I also try to only use y dimension, it works well, too. Is there anything wrong with my data or parameters? The following is my sensor data and parameters: IMU: [IMU](https://imgur.com/WykmkmB) VIO: [Pose](https://imgur.com/Be40hce) Params:[parameters](https://github.com/virtualclone/robot_localization_param/blob/master/ukf_template.yaml)

Im running a simulation in Gazebo combining the odomery data (coming from the differential drive plugin) and the imu data (from GazeboRosImuSensor plugin). Im quite new to ROS and im totally confused with the ENU and NED frames .. This is what I did 1)placed the IMU in its neutral position 2)setup a static transform broadcaster which broadcasts my base_link to odom frame here i made the rotation. this is the code snippet in my launch file I have rolled it by 180 and yaw by 90 I tested the IMU and it shows correct accelerations as shown (http://docs.ros.org/lunar/api/robot_localization/html/preparing_sensor_data.html) But when i visualise my odometrydatas, the unfiltered odometry data(from diffdrive plugin) and the filtered odometry data(from robot_localization) are in opposite orientation. This happens only when include my imu as an input to the robot_localization package.

Hi there, I'm using the robot_localization package for fusing several data inputs. I have a theorical model that estimates an ideal odometry for my robot only based on my commands and the robot model. On the other hand, I have a SLAM estimation system as input for the EKF too. My robot is a quadcopter and it has a yaw drift. I mean, its yaw value changes slowly over the time; and that is not registered by the theoretical model estimation. So model a slam orientation diverge very fast (in a minute or so). With enough time, there would be even 90º between their orientations, so it would be like one of them were not accomplishing the rep 105.. The question is: What would be the best way to fuse those estimations? Should I associate the "model yaw" to the estimated pose or is the EFK robust against orientation differences? Maybe I shloud do some reset over the theoretical pose estimated? Thank you in advance, Juan.

Im running a simulation in Gazebo combining the odomery data (coming from the differential drive plugin) and the imu data (from GazeboRosImuSensor plugin). Im quite new to ROS and im totally confused with the ENU and NED frames .. This is what I did 1)placed the IMU in its neutral position 2)setup a static transform broadcaster which broadcasts my base_link to odom frame here i made the rotation. I have rolled it by 180 and yaw by 90 . this is the code snippet in my launch file I tested the IMU and it shows correct accelerations as shown ( http://docs.ros.org/lunar/api/robot_l... ) This is my paramter config file for the robot_localization package odom0_config: [false, false, false, false, false, false, true, true, false, false, false, true, false, false, false] imu0_config: [false, false, false, false, false, true, false, false, false, false, false, true, true, true, false] odom0_queue_size: 2 imu0_queue_size: 5 odom0_nodelay: false imu0_nodelay: false odom0_differential: false imu0_differential: false odom0_relative: false imu0_relative: false The problem is that the filtered odometry data is moving at 90 degees to original raw odometry data 

HI, I would like to ask you if it's worth using [robot_localization](http://wiki.ros.org/robot_localization) for UAVs running on px4 firmware. I want to make my position estimation more precise and maybe one day do some localization in GPS denied spaces with more sensors such as LIDAR or camera. My question is whether it's still beneficial to use robot_localization package with basic sensors like IMU, GPS and barometer since px4 already does the sensor fusion internally using ekf as described [here](https://dev.px4.io/en/tutorials/tuning_the_ecl_ekf.html). Thank you for any advice.

Hi, I want to fuse two localization methods, odometry and a PoseWithCovariance sensor. When the robot "starts" it already has a location and rotation from the PoseWithCovariance sensor (like x=4 and y=3 etc) But the odometry is (0,0,0, etc), how do I make sure that both systems start at the same position? Of course, the two coordinates will change and be different from each other as time goes, which is expected. To get an accurate position I'm going to use an EKF from robot_localization. So I don't need a constant transform between the two, just only at the start. My odometry uses the odom and base_link frames (as the standard) and the Pose messages has the frame_id odom. What is the best way to do this?

Hello I am planning to use robot_localization to localize my boat, equipped with a 2D laser scanner, 9 dof IMU and GPS. My plan was to use 1 kf_localization_node that has, as inputs, the output of the gmapping node and the IMU data. If there is no laser data available (the boat may be floating in water without close walls), I would close that node and I would use another kf_localization_node to fuse GPS data (with navsat_transform_node) with IMU data. So GPS and Gmapping would never work at the same time. Is this a good approach? Or is there an easy way to use gmapping, GPS and IMU data at the same time? Thanks in advance!

Hi, My system description is as follows: Turtlebot - ros-kinetic - Ubuntu 16.04 I am running two instances of robot_localization, odometry in the first instance and 'odometry and global pose' in the second. 1) odom--> base_footprint (this is my equivalent of base_link). I'm adding a high noise (std_dev = 1) to the /odom and publishing it as /odom_noisy : frequency: 100 two_d_mode: true map_frame: map # Defaults to "map" if unspecified odom_frame: odom # Defaults to "odom" if unspecified base_link_frame: base_footprint # Defaults to "base_link" if unspecified world_frame: odom # Defaults to the value of odom_frame if unspecified odom0: /odom_noisy odom0_config: [false, false, false, false, false, false, true, true, false, false, false, true, false, false, false] odom0_queue_size: 5 odom0_nodelay: false odom0_differential: false odom0_relative: false use_control: true # Whether the input (assumed to be cmd_vel) is a geometry_msgs/Twist or geometry_msgs/TwistStamped message. Defaults to # false. stamped_control: false # The last issued control command will be used in prediction for this period. Defaults to 0.2. control_timeout: 0.1 # Which velocities are being controlled. Order is vx, vy, vz, vroll, vpitch, vyaw. control_config: [true, false, false, false, false, true] # Places limits on how large the acceleration term will be. Should match your robot's kinematics. acceleration_limits: [1.3, 0.0, 0.0, 0.0, 0.0, 3.4] # Acceleration and deceleration limits are not always the same for robots. deceleration_limits: [1.3, 0.0, 0.0, 0.0, 0.0, 4.5] # If your robot cannot instantaneously reach its acceleration limit, the permitted change can be controlled with these # gains acceleration_gains: [0.8, 0.0, 0.0, 0.0, 0.0, 0.9] # If your robot cannot instantaneously reach its deceleration limit, the permitted change can be controlled with these # gains deceleration_gains: [1.0, 0.0, 0.0, 0.0, 0.0, 1.0] process_noise_covariance: [0.05, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.05, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.5, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.05, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.05, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.005, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.05, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.05, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.05, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.05, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.05, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.04, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.01, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.01, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.015] # [ADVANCED] This represents the initial value for the state estimate error covariance matrix. Setting a diagonal # value (variance) to a large value will result in rapid convergence for initial measurements of the variable in # question. Users should take care not to use large values for variables that will not be measured directly. The values # are ordered as x, y, z, roll, pitch, yaw, vx, vy, vz, vroll, vpitch, vyaw, ax, ay, az. Defaults to the matrix below #if unspecified. initial_estimate_covariance: [1e-2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9] 2) map-> base_footprint (or map-> odom). The pose data (which is the global absolute orientation) has a std_dev of .01 degrees. Given a high level of accuracy in pose data and very noisy /odom_noisy, I expect the EKF to almost completely trust the pose data and output reasonably accurate data. What I'm seeing is a highly oscillating (especially the yaw) output, similar to that of /odom_noisy. As such, removing /abs_orientation doesn't seem to make any difference. The corresponding yaml file is as follows: frequency: 100 two_d_mode: true map_frame: map # Defaults to "map" if unspecified odom_frame: odom # Defaults to "odom" if unspecified base_link_frame: base_footprint # Defaults to "base_link" if unspecified world_frame: map # Defaults to the value of odom_frame if unspecified odom0: /odom_noisy odom0_config: [false, false, false, false, false, false, true, true, false, false, false, true, false, false, false] odom0_queue_size: 5 odom0_nodelay: false odom0_differential: false odom0_relative: false pose0: abs_orientation pose0_config: [false, false, false, false, false, true, false, false, false, false, false, false, false, false, false] pose0_differential: false pose0_relative: false pose0_queue_size: 5 pose0_rejection_threshold: 2 # Note the difference in parameter name pose0_nodelay: false use_control: true # Whether the input (assumed to be cmd_vel) is a geometry_msgs/Twist or geometry_msgs/TwistStamped message. Defaults to # false. stamped_control: false # The last issued control command will be used in prediction for this period. Defaults to 0.2. control_timeout: 0.1 # Which velocities are being controlled. Order is vx, vy, vz, vroll, vpitch, vyaw. control_config: [true, false, false, false, false, true] # Places limits on how large the acceleration term will be. Should match your robot's kinematics. acceleration_limits: [1.3, 0.0, 0.0, 0.0, 0.0, 3.4] # Acceleration and deceleration limits are not always the same for robots. deceleration_limits: [1.3, 0.0, 0.0, 0.0, 0.0, 4.5] # If your robot cannot instantaneously reach its acceleration limit, the permitted change can be controlled with these # gains acceleration_gains: [0.8, 0.0, 0.0, 0.0, 0.0, 0.9] # If your robot cannot instantaneously reach its deceleration limit, the permitted change can be controlled with these # gains deceleration_gains: [1.0, 0.0, 0.0, 0.0, 0.0, 1.0] process_noise_covariance: [0.05, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.05, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.5, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.05, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.05, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.005, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.05, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.05, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.05, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.05, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.05, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.04, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.01, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.01, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.015] # [ADVANCED] This represents the initial value for the state estimate error covariance matrix. Setting a diagonal # value (variance) to a large value will result in rapid convergence for initial measurements of the variable in # question. Users should take care not to use large values for variables that will not be measured directly. The values # are ordered as x, y, z, roll, pitch, yaw, vx, vy, vz, vroll, vpitch, vyaw, ax, ay, az. Defaults to the matrix below #if unspecified. initial_estimate_covariance: [1e-2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9] Below are the outputs: 1) /odometry_map/filtered - published by the second instance robot_localization header: seq: 5253 stamp: secs: 760 nsecs: 663000000 frame_id: "map" child_frame_id: "base_footprint" pose: pose: position: x: 0.0442575591845 y: 0.0155869558694 z: 0.0 orientation: x: 0.0 y: 0.0 z: 0.384538862254 w: 0.923108803672 covariance: [2.663882074729417, 0.0008610832095776304, 0.0, 0.0, 0.0, 0.026921653227594575, 0.0008610832095776344, 2.6635865448664076, 0.0, 0.0, 0.0, 0.026110560973774358, 0.0, 0.0, 9.993342210219859e-07, 6.797855885527078e-16, 4.2373098980630226e-16, 0.0, 0.0, 0.0, 6.797855885527075e-16, 9.934210138929739e-07, -4.326463119371932e-22, 0.0, 0.0, 0.0, 4.2373098980630226e-16, -4.326463124267019e-22, 9.934210138929745e-07, 0.0, 0.026921653227594475, 0.026110560973774316, 0.0, 0.0, 0.0, 0.9468182423951728] twist: twist: linear: x: 0.0101380887639 y: 0.0387535834841 z: 0.0 angular: x: 0.0 y: 0.0 z: -0.0794096879414 covariance: [0.0009540229033699445, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0009540229033699445, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 9.934210328992857e-07, 3.0421620013966033e-25, -6.746667100726666e-26, 0.0, 0.0, 0.0, 3.0421620013966033e-25, 9.934210325162797e-07, 7.921164614905649e-32, 0.0, 0.0, 0.0, -6.746667100726666e-26, 7.9257534448641e-32, 9.934210325162797e-07, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.023089536420008897] 2) /odometry/filtered header: seq: 5215 stamp: secs: 760 nsecs: 297000000 frame_id: "odom" child_frame_id: "base_footprint" pose: pose: position: x: 0.0481059004207 y: 0.0277482869621 z: 0.0 orientation: x: 0.0 y: 0.0 z: 0.477356029252 w: 0.878709975667 covariance: [2.644794104685194, 0.0007909579721065899, 0.0, 0.0, 0.0, 0.017066758856500826, 0.0007909579721065879, 2.645671616728246, 0.0, 0.0, 0.0, 0.03529150350258051, 0.0, 0.0, 9.995004994888809e-07, 5.3017097166727106e-17, 1.6334620670616377e-16, 0.0, 0.0, 0.0, 5.3017097166727094e-17, 9.95049485090448e-07, -1.7337851303703824e-23, 0.0, 0.0, 0.0, 1.633462067061637e-16, -1.733785070966406e-23, 9.95049485090448e-07, 0.0, 0.017066758856500774, 0.03529150350258047, 0.0, 0.0, 0.0, 0.9383404560967562] twist: twist: linear: x: -0.0149190117811 y: -0.0123008162423 z: 0.0 angular: x: 0.0 y: 0.0 z: -0.0450499681531 covariance: [0.000921183130561197, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.000921183130561197, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 9.950494900372747e-07, 6.507436387617446e-26, 1.682587054280008e-26, 0.0, 0.0, 0.0, 6.507436387617443e-26, 9.950494896505053e-07, -5.429910242222473e-33, 0.0, 0.0, 0.0, 1.682587054280008e-26, -5.82064332144405e-33, 9.950494896505053e-07, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.022759494263694245] 3) /abs_orientation header: seq: 552 stamp: secs: 0 nsecs: 0 frame_id: "world" pose: pose: position: x: 0.0 y: 0.0 z: 0.0 orientation: x: 0.0 y: 0.0 z: 0.000459218843978 w: 0.999999894559 covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 3.046174061692489e-08] Edit-1 : There is a static_transform from world to map.

I'm fusing the wheel odom and imu on the Husky, with robot_localization's UKF. What I'm wondering is the following: I don't really want to rely on the magnetometer output for bounding yaw from the IMU, but I also don't want to orient my yaw around my wheel encoder yaw. So, I'd like to just fuse both as angular velocities, and let it slowly drift with gyro bias. However, when I do this (fuse YawRate from odom, YawRate from IMU) the covariance for YawYaw (/odometry/filtered/pose/covariance[35]) grows slowly. After a few hours, it will be very large. Is this a significant issue? I assume the filter will become unstable (I'm using the UKF currently). Thus, do I have to fuse an absolute yaw from somewhere in order to keep the filter stable? As a side note, the covariance for ZZ is also growing (/odometry/filtered/pose/covariance[14]), but I don't think that matters as much.

Hello, I'm using robot_localization to doing EKF. And I want to output the debug file, but when I set the parameter in .yaml like this debug: true debug_out_file: ~/debug/file.txt and run the lauch. But I don't see any file in ~/debug Why is that?

Hello All, I have asked a question before about using a RTK GPS + IMU + Wheel Encoder Setup and received good feedback. Now i ask about a system with 2 RTK GPS units + Wheel Encoder. The RTK units are mounted on opposite ends of the robot frame. I am able to obtain position and orientation from this setup. I want to clarify my settings of the frames for the robot_localization package. I plan on publishing 2 Odometry messages from the RTK system, one for the position, the other for the orientation. The frame_id in the Odometry message from the RTK system was originally "gps". Since the gps is mounted on the side of the robot, i have defined a static transform from gps->base_link. 1. For the first Odometry message (in which only the linear positions and linear velocities are populated), i changed the frame_id of the message to "map", as well as set the child_frame_id to "gps". In this way, the RTK solution gives me a transform from map to gps, and the defined static transform gives me gps to base-link, therefore i obtain the map-> base-link transform. 2. For the second Odometry message (in which only the yaw is obtained, none of the velocities, and none of linear positions), this is provided relative to true north, which is a world fixed frame. So for that i was thinking having frame_id map, and child_frame_id as base_link, because the yaw described in this message is relative to true north.. This would be published as a separate Odometry message. 3. For the wheel encoder node, i have it publishing Odometry message with frame_id being odom, and child frame id being base_link. All the fields are populated (pose, twist). And now, i fuse them with one instance of EKF in robot_localization package. From each odometry message, i fuse the following: 1. only xyz position and linear velocity xyz (map->gps + gps->base_link static transform = map->base_link) 2. yaw and only yaw (relative to earth and so map->base_link) 3. linear and angular velocity (odom->base_link) Does this setup make sense? Thank you, Jad

Hey guys, I have a small issue here. I am running `r_l` with a fusion of GPS RTK, imu and wheel odometry. However, I encounter a small problem when GPS data is not available. Let me explain: my GPS package publishes GPS coordinates if and only if RTK is FIXED if it is not id does not, actually that make sense. My `r_l` configuration works really great when I have RTK the only problem I have, as mentioned in the title, is that the state estimation does not publish any x,y data if GPS does not publish and that is a small problem whenever I will lose GPS fix for some seconds or I will start my system with no clear sky view. Any hints on how to solve that? Launch file: navsat transform: frequency: 30 delay: 3.0 magnetic_declination_radians: 0.0539 # For lat/long 45.2266641° N , 11.9843053° E yaw_offset: -0.031 #-0.031 # 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: false # 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.2266646, 11.984309, 0.0] gps_odom.yaml: # 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: false debug_out_file: /home/matteo/rover_ws/ekf_se_odom.txt # initial_state: [-0.286, -1.69, 0.0, # 0.0, 0.0, 0.0, # 0.0, 0.0, 0.0, # 0.0, 0.0, 0.0, # 0.0, 0.0, 0.0] map_frame: map odom_frame: odom base_link_frame: base_link world_frame: odom odom0: odom odom0_config: [true, true, true, false, false, false, false, false, false, false, false, false, false, false, false] odom0_queue_size: 10 odom0_nodelay: true odom0_differential: true 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, false, false, true, false, false, false, false, false, true, false, false, false] 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: [1e-3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.01, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.5, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.5, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.3] initial_estimate_covariance: [1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.0] 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: false debug_out_file: /home/matteo/rover_ws/ekf_se_map.txt # initial_state: [-0.286, -1.69, 0.0, # 0.0, 0.0, 0.0, # 0.0, 0.0, 0.0, # 0.0, 0.0, 0.0, # 0.0, 0.0, 0.0] map_frame: map odom_frame: odom base_link_frame: base_link world_frame: map odom0: odom odom0_config: [true, true, true, false, false, false, false, false, false, false, false, false, false, false, false] odom0_queue_size: 10 odom0_nodelay: true odom0_differential: true 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, false, false, true, false, false, false, false, false, true, false, false, false] imu0_nodelay: true imu0_differential: false imu0_relative: false imu0_queue_size: 10 imu0_remove_gravitational_acceleration: true use_control: false process_noise_covariance: [1.0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.01, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.5, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.5, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.3] initial_estimate_covariance: [1.0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.0] And finally bag file: [bag file](https://drive.google.com/open?id=16V35uC-xNNWyf5t5V3O8fS0EwkNcay8y) Thanks! Matteo

Hello ROS community, I'm currently attempting to fuse GPS, IMU, and Odometry data as detailed on the Robot Localization docs([See Here](http://docs.ros.org/lunar/api/robot_localization/html/integrating_gps.html). I used the dual_ekf_navsat_example.launch ([Available Here](https://github.com/cra-ros-pkg/robot_localization/blob/kinetic-devel/launch/dual_ekf_navsat_example.launch)) from the robot_localization GitHub as an example. The parameters are the same, with the names of the topics changed match my publishers. The problem I am having is the robot starts "shaking" in Rviz whenever I start-up the ekfs and navsat transform. The shaking only grows worse as the robot begins to move causing the robot jump all around the Rviz visualization. I've recorded a video of this behavior, you can watch it [here.](https://drive.google.com/open?id=1XwA2ZNqBkW_gzRkTJgzMEae8j-UHc9U3) (Please excuse the window flickering, I think it's a side effect of VLC) I am curious if anyone else has experience with this issue, and has some solutions that may help in remedying the problem. The GPS is using RTK corrections and is extremely accurate. In reading through ROS answers, [this](https://answers.ros.org/question/257541/strange-results-with-robot_localization-and-navsat_transform_node/) issue seems similar, but I have accounted for magnetic declination and the orientation of the IMU. I have a strong hunch the IMU is at least partially responsible for the erratic behavior. Though I have tried IMU recalibration to no improvement. This issue is not present in the simulated robot, but has been a road block for weeks now. The ROS driver we're using for the IMU is available [here](http://wiki.ros.org/microstrain_3dm_gx5_45). I would appreciate any support and would be happy to provide any further information needed. Thank you in advance! Robot's System: - x86 64-Bit - 4.13.0-38-generic Kernal - Ubuntu 16.04.1 - ROS Kinetic Hardware: - IMU - [Lord MicroStrain 3DM-GX5-25](https://www.microstrain.com/inertial/3dm-gx5-25) - GPS - Trimble BD930

I have troubles with robot_localization. So I decided to test only data from the Madgwick filter obtained from my IMU. However, results provided by robot_localization are far from these data. [Here is the bagfile](http://guhur.net/2018-05-03-18-39-05.bag) Here is the launch file: [false, false, false, true, true, true, false, false, false, true, true, true, true, true, true] [1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 100, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 100, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 100, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 100, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 100, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 100, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 100, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 100, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 100] Here is what I get from /imu/data: --- header: seq: 13861 stamp: secs: 1525363752 nsecs: 950200058 frame_id: "imu" orientation: x: -0.348316741047 y: -0.602712667954 z: 0.590834173906 w: 0.407833135901 orientation_covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0] angular_velocity: x: 0.00855211333477 y: 0.0 z: 0.00366519142919 angular_velocity_covariance: [1.2184696791468346e-07, 0.0, 0.0, 0.0, 1.2184696791468346e-07, 0.0, 0.0, 0.0, 1.2184696791468346e-07] linear_acceleration: x: 0.79510053401 y: -9.81000041962 z: 0.335305814342 linear_acceleration_covariance: [8.66124974095918e-06, 0.0, 0.0, 0.0, 8.66124974095918e-06, 0.0, 0.0, 0.0, 8.66124974095918e-06] --- header: seq: 13862 stamp: secs: 1525363752 nsecs: 954200057 frame_id: "imu" orientation: x: -0.34803859812 y: -0.602742822373 z: 0.590816249998 w: 0.408051936688 orientation_covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0] angular_velocity: x: 0.0158824961931 y: -0.00855211333477 z: 0.00855211333477 angular_velocity_covariance: [1.2184696791468346e-07, 0.0, 0.0, 0.0, 1.2184696791468346e-07, 0.0, 0.0, 0.0, 1.2184696791468346e-07] linear_acceleration: x: 0.843071436062 y: -9.82912992043 z: 0.364049115572 linear_acceleration_covariance: [8.66124974095918e-06, 0.0, 0.0, 0.0, 8.66124974095918e-06, 0.0, 0.0, 0.0, 8.66124974095918e-06] Here is what robot_localization provides: --- header: seq: 146 stamp: secs: 1525364518 nsecs: 892152786 frame_id: "odom" child_frame_id: "base_link" pose: pose: position: x: -13.0690016277 y: -8.18444181075 z: 16.9989781404 orientation: x: 1.82640882884e-10 y: -8.21966344865e-11 z: -2.7356857487e-11 w: 1.0 covariance: [207.07713413156662, -5.7040178257204794e-08, 9.978910872831822e-05, 1.3102045021365689e-21, 4.1645675393512735e-17, 1.4459932078618483e-17, -5.704017825734225e-08, 207.07713405057194, 0.0001962525991995146, -4.160335680928879e-17, -7.457008449868983e-20, -1.0761677687587693e-17, 9.97891087283185e-05, 0.00019625259919951504, 330.7305333288588, -2.902514949722296e-17, 2.1545306969450206e-17, -9.325915435424517e-21, 1.3102045021365702e-21, -4.1603356809288805e-17, -2.902514949722295e-17, 9.999998333333653e-10, 6.005231329050467e-29, 1.9990604350031187e-29, 4.1645675393512753e-17, -7.457008449868983e-20, 2.1545306969450218e-17, 6.005231328314847e-29, 9.999998333333655e-10, -8.992601293026998e-30, 1.445993207861848e-17, -1.0761677687587693e-17, -9.325915435424517e-21, 1.9990604350031024e-29, -8.992601293028158e-30, 9.99999916666635e-10] twist: twist: linear: x: -0.647882420202 y: -0.873556625097 z: 1.24957340025 angular: x: -0.0029128103884 y: -0.00787242437575 z: 0.00751005609254 covariance: [0.7303506208018974, -1.4272838998438906e-21, 1.0127882802417763e-21, 0.0, 0.0, 0.0, -1.3771337690910615e-21, 0.7303506208018974, 3.0187169563261866e-21, 0.0, 0.0, 0.0, 1.076997012037841e-21, 2.9401315399900294e-21, 1.1685306196944716, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.2183954547018434e-07, -6.616638657608997e-24, 1.0083689631110166e-32, 0.0, 0.0, 0.0, -6.616638682161806e-24, 1.2183954547018434e-07, -3.308420170891388e-24, 0.0, 0.0, 0.0, 1.6542100692899256e-24, -3.3084201708913884e-24, 1.2184325646635733e-07] --- In /data/imu, I have correct values when I move the robot (and I can clearly see it in RViz. In /odometry/filtered, position: x and y are going nowhere, while the other values remain almost constant). Finally, /diagnostics provide: level: 2 name: "ekf_localization: Filter diagnostic updater" message: "Erroneous data or settings detected for a robot_localization state estimation node." hardware_id: "none" values: - key: "X_configuration" value: "Neither X nor its velocity is being measured. This will result in unbounded error\ \ growth and erratic filter behavior." - key: "Y_configuration" value: "Neither Y nor its velocity is being measured. This will result in unbounded error\ \ growth and erratic filter behavior." - key: "Z_configuration" value: "Neither Z nor its velocity is being measured. This will result in unbounded error\ \ growth and erratic filter behavior." - key: "imu0_pose_covariance" value: "The covariance at position (35), which corresponds to YAW variance, was zero. This\ \ will be replaced with a small value to maintain filter stability, but should be\ \ corrected at the message origin node." -

Hello, I use robot localization with 3 input sensor: IMU - Wheel_odometry - GPS_odometry using a static map from google maps. But sometimes GPS isn't very accurate. I use 2D lidars for detection that outputs a laser scan message to ROS navigation stack. I want to use a set of lidars as an extra source of localization with the same static google maps. So any help, How can I use a static map and 2D lidars to output a pose message to robot localization?

Hi, I'm using robot_localization package to fuse wheel odometry and IMU of a robot with the EKF node. The ekf node outputs the odometry to /odom topic. When inspecting the rate of this output I spotted weird peaks of the publish rate (see screen shots below). Frequency parameter is set to 100 Hz. It looks as if there are sudden bursts of odometry messages. Some consecutive messages have the exact same time stamp but different pose (second screen shot). That leads to problems with some other nodes. Any idea why this happens?   Configuration: frequency: 100 sensor_timeout: 0.05 two_d_mode: true transform_time_offset: 0.0 transform_timeout: 0.0 print_diagnostics: true debug: false debug_out_file: /path/to/debug/file.txt publish_tf: true publish_acceleration: false #map_frame: map # Defaults to "map" if unspecified odom_frame: odom # Defaults to "odom" if unspecified base_link_frame: base_link # Defaults to "base_link" if unspecified world_frame: odom # Defaults to the value of odom_frame if unspecified odom0: /wheel_odom imu0: /imu odom0_config: [false, false, false, # x y z false, false, false, # r p y true, true, false, # vx vy vz false, false, true, # vr vp vy false, false, false] # ax ay az imu0_config: [false, false, false, # x y z false, false, false, # r p y false, false, false, # vx vy vz false, false, true, # vr vp vy true, false, false] # ax ay az odom0_queue_size: 10 imu0_queue_size: 10 odom0_nodelay: false imu0_nodelay: false odom0_differential: false imu0_differential: false odom0_relative: false imu0_relative: false imu0_remove_gravitational_acceleration: true use_control: false stamped_control: false control_timeout: 0.2 control_config: [true, false, false, false, false, true] acceleration_limits: [0.15, 0.0, 0.0, 0.0, 0.0, 0.1] deceleration_limits: [0.9, 0.0, 0.0, 0.0, 0.0, 1.0] acceleration_gains: [0.9, 0.0, 0.0, 0.0, 0.0, 0.5] deceleration_gains: [1.0, 0.0, 0.0, 0.0, 0.0, 1.0] process_noise_covariance: [0.05, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.05, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.06, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.03, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.03, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.06, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.025, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.025, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.04, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.01, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.01, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.02, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.01, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.01, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.015] initial_estimate_covariance: [1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9] Best, Jacob Seibert

I am investigating the drift of an imu, so launching the rtimulib_ros and robot_localization packages on a kinetic distribution. The imu data is coming out the /imu topic properly but the robot_localization package is giving error 'Could not obtain transform from map to base_link. How do I satisfy this mapping?

I'm using adafruit bn055 imu board serviced by rtimulib_ros package feeding the robot_localization package. The imu output frame is showing the linear acceleration along the z-axis is around positive 1 when the imu is at rest flat on a level surface. After 60 seconds, the robot_localization /odometry/filtered output is showing the location along z-axis as about the expected `negative` 17K meters. The parameter `imu0_remove_gravitational_acceleration` is `true` in the ekf yaml file. When I change it to `false` the location along the z-axis changes sign to a `positive` 17K meters, instead of the expected 0 meters. Any ideas on how to fix this?