# Revision history [back]

### Robot_Localization not publishing transform to odom

We are using robot_localization to filter some of our sensor outputs. We are running two instances of RL but the one that takes care of the transform from map to the odom frame is not publishing the transform. For the instance of RL that is responsible for the transform between the map frame to the odom frame the diagnostics say /odom/filtered: no events recorded.

here are our launch files:

https://github.com/mantraes/ROS-Launch-Files.git

The original launch file is robo_loco.launch however we found something on the internet claiming that the order in which the instances of RL happen may effect how RL publishes its transforms so we made 2 separate launch files to try to see if that worked and those are called ekf_localization_map and ekf_localization_odom

Thanks for the help and let me know if you need anything else!

### Robot_Localization not publishing transform to odom

We are using robot_localization to filter some of our sensor outputs. We are running two instances of RL but the one that takes care of the transform from map to the odom frame is not publishing the transform. For the instance of RL that is responsible for the transform between the map frame to the odom frame the diagnostics say /odom/filtered: no events recorded.

here are our launch files:files:  <launch> <node pkg="robot_localization" type="ekf_localization_node" name="ekf_localization_odom" clear_params="true">

 <!-- ======== STANDARD PARAMETERS ======== --> <param name="frequency" value="30"/> <param name="sensor_timeout" value="0.1"/> <!-- If this is set to true, no 3D information will be used in your state estimate. Use this if you are operating in a planar environment and want to ignore the effect of small variations in the ground plane that might otherwise be detected by, for example, an IMU. Defaults to false if unspecified. --> <param name="two_d_mode" value="true"/> <!-- REP-105 (http://www.ros.org/reps/rep-0105.html) specifies three principal coordinate frames: map, odom, and base_link. base_link is the coordinate frame that is affixed to the robot. The robot's position in the odom frame will drift over time, but is accurate in the short term and should be continuous. The odom frame is therefore the best frame for executing local motion plans. The map frame, like the odom frame, is a world-fixed coordinate frame, and while it contains the most globally accurate position estimate for your robot, it is subject to discrete jumps, e.g., due to the fusion of GPS data. Here is how to use the following settings: 1. Set the map_frame, odom_frame, and base_link frames to the appropriate frame names for your system. * If your system does not have a map_frame, just remove it, and make sure "world_frame" is set to the value of odom_frame. 2. If you are fusing continuous position data such as wheel encoder odometry, visual odometry, or IMU data, set "world_frame" to your odom_frame value. This is the default behavior for robot_localization's state estimation nodes. 3. If you are fusing global absolute position data that is subject to discrete jumps (e.g., GPS or position updates from landmark observations) then: 3a. Set your "world_frame" to your map_frame value 3b. MAKE SURE something else is generating the odom->base_link transform. Note that this can even be another instance of robot_localization! However, that instance should *not* fuse the global data. --> <param name="map_frame" value="map"/> <param name="odom_frame" value="odom"/> <param name="base_link_frame" value="base_link"/> <param name="world_frame" value="odom"/> <!-- Use this parameter to provide an offset to the transform generated by ekf_localization_node. This can be used for future dating the transform, which is required for interaction with some other packages. Defaults to 0.0 if unspecified. --> <param name="transform_time_offset" value="0.0"/> <!-- The filter accepts an arbitrary number of inputs from each input message type (Odometry, PoseStamped, TwistStamped, Imu). To add a new one, simply append the next number in the sequence to its base name, e.g., odom0, odom1, twist0, twist1, imu0, imu1, imu2, etc. The value should be the topic name. These parameters obviously have no default values, and must be specified. --> <param name="odom0" value="/rtabmap/odom"/> <param name="imu0" value="/imu/data"/> <!-- Each sensor reading updates some or all of the filter's state. These options give you greater control over which values from each measurement are fed to the filter. For example, if you have an odometry message as input, but only want to use its Z position value, then set the entire vector to false, except for the third entry. The order of the values is x, y, z, roll, pitch, yaw, vx, vy, vz, vroll, vpitch, vyaw, ax, ay, az. Note that not some message types lack certain variables. For example, a TwistWithCovarianceStamped message has no pose information, so the first six values would be meaningless in that case. Each vector defaults to all false if unspecified, effectively making this parameter required for each sensor. --> <rosparam param="odom0_config">[true, true, true, true, true, true, false, false, false, false, false, false, false, false, false]</rosparam> <rosparam param="imu0_config">[false, false, false, false, false, false, false, false, false, true, true, true, true, true, true]</rosparam> <!-- The best practice for including new sensors in robot_localization's state estimation nodes is to pass in velocity measurements and let the nodes integrate them. However, this isn't always feasible, and so the state estimation nodes support fusion of absolute measurements. If you have more than one sensor providing absolute measurements, however, you may run into problems if your covariances are not large enough, as the sensors will inevitably diverge from one another, causing the filter to jump back and forth rapidly. To combat this situation, you can either increase the covariances for the variables in question, or you can simply set the sensor's differential parameter to true. When differential mode is enabled, all absolute pose data is converted to velocity data by differentiating the absolute pose measurements. These velocities are then integrated as usual. NOTE: this only applies to sensors that provide absolute measurements, so setting differential to true for twit measurements has no effect. Users should take care when setting this to true for orientation variables: if you have only one source of absolute orientation data, you should not set the differential parameter to true. This is due to the fact that integration of velocities leads to slowly increasing error in the absolute (pose) variable. For position variables, this is acceptable. For orientation variables, it can lead to trouble. Users should make sure that all orientation variables have at least one source of absolute measurement. --> <param name="odom0_differential" value="false"/> <param name="imu0_differential" value="false"/> <!-- When the node starts, if this parameter is true, then the first measurement is treated as a "zero point" for all future measurements. While you can achieve the same effect with the differential paremeter, the key difference is that the relative parameter doesn't cause the measurement to be converted to a velocity before integrating it. If you simply want your measurements to start at 0 for a given sensor, set this to true. --> <param name="odom0_relative" value="true"/> <param name="imu0_relative" value="true"/> <!-- If we're including accelerations in our state estimate, then we'll probably want to remove any acceleration that is due to gravity for each IMU. If you don't want to, then set this to false. Defaults to false if unspecified. --> <param name="imu0_remove_gravitational_acceleration" value="true"/> <!-- If you're having trouble, try setting this to true, and then echo the /diagnostics_agg topic to see if the node is unhappy with any settings or data. --> <param name="print_diagnostics" value="true"/> <!-- ======== ADVANCED PARAMETERS ======== --> <!-- Most users will be able to remove these parameters from the launch file without any consequences. We recommend that users do not set values for these parameters without having a thorough understanding of the parameters do. --> <!-- By default, the subscription queue size for each message type is 1. If you wish to increase that so as not miss any messages (even if your frequency is set to a relatively small value), increase these. --> <param name="odom0_queue_size" value="10"/> <param name="imu0_queue_size" value="10"/> <!-- If your data is subject to outliers, use these threshold settings, expressed as Mahalanobis distances, to control how far away from the current vehicle state a sensor measurement is permitted to be. Each defaults to numeric_limits<double>::max() if unspecified. --> <param name="odom0_pose_rejection_threshold" value="5"/> <param name="odom0_twist_rejection_threshold" value="1"/> <param name="imu0_pose_rejection_threshold" value="0.3"/> <param name="imu0_twist_rejection_threshold" value="0.1"/> <param name="imu0_linear_acceleration_rejection_threshold" value="0.1"/> <!-- Debug settings. Not for the faint of heart. Outputs a ludicrous amount of information to the file specified by debug_out_file. I hope you like matrices! Defaults to false if unspecified. --> <param name="debug" value="false"/> <!-- Defaults to "robot_localization_debug.txt" if unspecified. --> <param name="debug_out_file" value="debug_ekf_localization_odom.txt"/> <!-- The process noise covariance matrix can be difficult to tune, and can vary for each application, so it is exposed as a configuration parameter. 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. --> <rosparam param="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]</rosparam> <!-- This represents the initial value for the state estimate error covariance matrix. Setting a diagonal value (a variance) to a large value will result in early measurements for that variable being accepted quickly. 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. --> <rosparam param="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]</rosparam> <!-- Placeholder for output topic remapping <remap from="odometry/filtered" to=""/> --> </node> 

#  <node pkg="robot_localization" type="ekf_localization_node" name="ekf_localization_map" clear_params="true"> <param name="frequency" value="30"/> <param name="sensor_timeout" value="0.1"/> <param name="two_d_mode" value="true"/> <param name="map_frame" value="map"/> <param name="odom_frame" value="odom"/> <param name="base_link_frame" value="base_link"/> <param name="world_frame" value="map"/> <param name="transform_time_offset" value="0.0"/> <param name="odom0" value="/rtabmap/odom"/> <!-- x y z roll pitch yaw vx vy vz vroll vpitch vyaw ax ay az --> <rosparam param="odom0_config">[true, true, true, true, true, true, false, false, false, false, false, false, false, false, false]</rosparam> <param name="odom0_differential" value="false"/> <param name="odom0_relative" value="true"/> <param name="print_diagnostics" value="true"/> <!-- ======== ADVANCED PARAMETERS ======== --> <param name="odom0_queue_size" value="10"/> <!-- If your data is subject to outliers, use these threshold settings, expressed as Mahalanobis distances, to control how far away from the current vehicle state a sensor measurement is permitted to be. Each defaults to numeric_limits<double>::max() if unspecified. --> <param name="odom0_pose_rejection_threshold" value="5"/> <param name="odom0_twist_rejection_threshold" value="1"/> <param name="debug" value="false"/> <param name="debug_out_file" value="debug_ekf_localization_map.txt"/> <rosparam param="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]</rosparam> <rosparam param="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]</rosparam> </node> </launch> https://github.com/mantraes/ROS-Launch-Files.gitThe original launch file is robo_loco.launch however we found something on the internet claiming that the order in which the instances of RL happen may effect how RL publishes its transforms so we made 2 separate launch files to try to see if that worked and those are called ekf_localization_map and ekf_localization_odomThanks for the help and let me know if you need anything else!

### Robot_Localization not publishing transform to odom

We are using robot_localization to filter some of our sensor outputs. We are running two instances of RL but the one that takes care of the transform from map to the odom frame is not publishing the transform. For the instance of RL that is responsible for the transform between the map frame to the odom frame the diagnostics say /odom/filtered: no events recorded.

here are our launch files: files:


<launch>

<node pkg="robot_localization" type="ekf_localization_node" name="ekf_localization_odom" clear_params="true">   <!-- ======== STANDARD PARAMETERS ======== -->

<param name="frequency" value="30"/>
<param name="sensor_timeout" value="0.1"/>

<!-- If this is set to true, no 3D information will be used in your state estimate. Use this if you
are operating in a planar environment and want to ignore the effect of small variations in the
ground plane that might otherwise be detected by, for example, an IMU. Defaults to false if
unspecified. -->
<param name="two_d_mode" value="true"/>

<!-- REP-105 (http://www.ros.org/reps/rep-0105.html) specifies three principal coordinate frames: map,
odom, and base_link. base_link is the coordinate frame that is affixed to the robot. The robot's
position in the odom frame will drift over time, but is accurate in the short term and should be
continuous. The odom frame is therefore the best frame for executing local motion plans. The map
frame, like the odom frame, is a world-fixed coordinate frame, and while it contains the most
globally accurate position estimate for your robot, it is subject to discrete jumps, e.g., due to
the fusion of GPS data. Here is how to use the following settings:
1. Set the map_frame, odom_frame, and base_link frames to the appropriate frame names for your system.
* If your system does not have a map_frame, just remove it, and make sure "world_frame" is set
to the value of odom_frame.
2. If you are fusing continuous position data such as wheel encoder odometry, visual odometry, or IMU data,
set "world_frame" to your odom_frame value. This is the default behavior for robot_localization's state
estimation nodes.
3. If you are fusing global absolute position data that is subject to discrete jumps (e.g., GPS or position
3b. MAKE SURE something else is generating the odom->base_link transform. Note that this can even be
another instance of robot_localization! However, that instance should *not* fuse the global data. -->

<param name="map_frame" value="map"/>
<param name="odom_frame" value="odom"/>
<param name="world_frame" value="odom"/>

<!-- Use this parameter to provide an offset to the transform generated by ekf_localization_node. This
can be used for future dating the transform, which is required for interaction with some other
packages. Defaults to 0.0 if unspecified. -->
<param name="transform_time_offset" value="0.0"/>

<!-- The filter accepts an arbitrary number of inputs from each input message type (Odometry, PoseStamped,
TwistStamped, Imu). To add a new one, simply append the next number in the sequence to its base name,
e.g., odom0, odom1, twist0, twist1, imu0, imu1, imu2, etc. The value should be the topic name. These
parameters obviously have no default values, and must be specified. -->
<param name="odom0" value="/rtabmap/odom"/>
<param name="imu0" value="/imu/data"/>

<!-- Each sensor reading updates some or all of the filter's state. These options give you greater control over
which values from each measurement are fed to the filter. For example, if you have an odometry message as input,
but only want to use its Z position value, then set the entire vector to false, except for the third entry.
The order of the values is x, y, z, roll, pitch, yaw, vx, vy, vz, vroll, vpitch, vyaw, ax, ay, az. Note that not some
message types lack certain variables. For example, a TwistWithCovarianceStamped message has no pose information, so
the first six values would be meaningless in that case. Each vector defaults to all false if unspecified, effectively
making this parameter required for each sensor. -->
clear_params="true">

<rosparam param="odom0_config">[true, true, true,
true, true, true,
false, false, false,
false, false, false,
false, false, false]</rosparam>

<rosparam param="imu0_config">[false, false, false,
false, false, false,
false, false, false,
true,  true,  true,
true,  true,  true]</rosparam>

<!-- The best practice for including new sensors in robot_localization's state estimation nodes is to pass in velocity
measurements and let the nodes integrate them. However, this isn't always feasible, and so the state estimation
nodes support fusion of absolute measurements. If you have more than one sensor providing absolute measurements,
however, you may run into problems if your covariances are not large enough, as the sensors will inevitably
diverge from one another, causing the filter to jump back and forth rapidly. To combat this situation, you can
either increase the covariances for the variables in question, or you can simply set the sensor's differential
parameter to true. When differential mode is enabled, all absolute pose data is converted to velocity data by
differentiating the absolute pose measurements. These velocities are then integrated as usual. NOTE: this only
applies to sensors that provide absolute measurements, so setting differential to true for twit measurements has
no effect.

Users should take care when setting this to true for orientation variables: if you have only one source of
absolute orientation data, you should not set the differential parameter to true. This is due to the fact that
integration of velocities leads to slowly increasing error in the absolute (pose) variable. For position variables,
this is acceptable. For orientation variables, it can lead to trouble. Users should make sure that all orientation
variables have at least one source of absolute measurement. -->
<param name="odom0_differential" value="false"/>
<param name="imu0_differential" value="false"/>

<!-- When the node starts, if this parameter is true, then the first measurement is treated as a "zero point" for all
future measurements. While you can achieve the same effect with the differential paremeter, the key difference is
that the relative parameter doesn't cause the measurement to be converted to a velocity before integrating it. If
you simply want your measurements to start at 0 for a given sensor, set this to true. -->
<param name="odom0_relative" value="true"/>
<param name="imu0_relative" value="true"/>

<!-- If we're including accelerations in our state estimate, then we'll probably want to remove any acceleration that
is due to gravity for each IMU. If you don't want to, then set this to false. Defaults to false if unspecified. -->
<param name="imu0_remove_gravitational_acceleration" value="true"/>

<!-- If you're having trouble, try setting this to true, and then echo the /diagnostics_agg topic to see
if the node is unhappy with any settings or data. -->
<param name="print_diagnostics" value="true"/>

<!-- ======== ADVANCED PARAMETERS ======== -->

<!-- Most users will be able to remove these parameters from the launch file without any consequences. We recommend
that users do not set values for these parameters without having a thorough understanding of
the parameters do. -->

<!-- By default, the subscription queue size for each message type is 1. If you wish to increase that so as not
miss any messages (even if your frequency is set to a relatively small value), increase these. -->
<param name="odom0_queue_size" value="10"/>
<param name="imu0_queue_size" value="10"/>

<!-- If your data is subject to outliers, use these threshold settings, expressed as Mahalanobis distances, to control
how far away from the current vehicle state a sensor measurement is permitted to be. Each defaults to
numeric_limits<double>::max() if unspecified. -->
<param name="odom0_pose_rejection_threshold" value="5"/>
<param name="odom0_twist_rejection_threshold" value="1"/>
<param name="imu0_pose_rejection_threshold" value="0.3"/>
<param name="imu0_twist_rejection_threshold" value="0.1"/>
<param name="imu0_linear_acceleration_rejection_threshold" value="0.1"/>

<!-- Debug settings. Not for the faint of heart. Outputs a ludicrous amount of information to the file
specified by debug_out_file. I hope you like matrices! Defaults to false if unspecified. -->
<param name="debug"           value="false"/>
<!-- Defaults to "robot_localization_debug.txt" if unspecified. -->
<param name="debug_out_file"  value="debug_ekf_localization_odom.txt"/>

<!-- The process noise covariance matrix can be difficult to tune, and can vary for each application, so it
is exposed as a configuration parameter. 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. -->
<rosparam param="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]</rosparam>

<!-- This represents the initial value for the state estimate error covariance matrix. Setting a diagonal value (a
variance) to a large value will result in early measurements for that variable being accepted quickly. 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. -->
<rosparam param="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]</rosparam>

<!--  Placeholder for output topic remapping
<remap from="odometry/filtered" to=""/>
-->

</node>

<node pkg="robot_localization" type="ekf_localization_node" name="ekf_localization_map" clear_params="true">   <param name="frequency" value="30"/>
<param name="sensor_timeout" value="0.1"/>
<param name="two_d_mode" value="true"/>

<param name="map_frame" value="map"/>
<param name="odom_frame" value="odom"/>
<param name="world_frame" value="map"/>

<param name="transform_time_offset" value="0.0"/>

<param name="odom0" value="/rtabmap/odom"/>

<!--      x   y   z
roll    pitch   yaw
vx  vy  vz
vroll   vpitch  vyaw
ax  ay  az
-->
clear_params="true">

<rosparam param="odom0_config">[true, true, true,
true, true, true,
false, false, false,
false, false, false,
false, false, false]</rosparam>

<param name="odom0_differential" value="false"/>

<param name="odom0_relative" value="true"/>

<param name="print_diagnostics" value="true"/>

<!-- ======== ADVANCED PARAMETERS ======== -->

<param name="odom0_queue_size" value="10"/>

<!-- If your data is subject to outliers, use these threshold settings, expressed as Mahalanobis distances, to control
how far away from the current vehicle state a sensor measurement is permitted to be. Each defaults to
numeric_limits<double>::max() if unspecified. -->
<param name="odom0_pose_rejection_threshold" value="5"/>

<param name="odom0_twist_rejection_threshold" value="1"/>

<param name="debug"           value="false"/>
<param name="debug_out_file"  value="debug_ekf_localization_map.txt"/>

<rosparam param="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]</rosparam>

<rosparam param="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]</rosparam>

</node>

</launch>
</launch>
https://github.com/mantraes/ROS-Launch-Files.git The original launch file is robo_loco.launch however we found something on the internet claiming that the order in which the instances of RL happen may effect how RL publishes its transforms so we made 2 separate launch files to try to see if that worked and those are called ekf_localization_map and ekf_localization_odom Thanks for the help and let me know if you need anything else! 


 4 No.4 Revision updated 2016-02-09 08:58:26 -0500 Robot_Localization not publishing transform to odom We are using robot_localization to filter some of our sensor outputs. We are running two instances of RL but the one that takes care of the transform from map to the odom frame is not publishing the transform. For the instance of RL that is responsible for the transform between the map frame to the odom frame the diagnostics say /odom/filtered: no events recorded. here are our launch files:files: <launch> <launch> <node pkg="robot_localization" type="ekf_localization_node" name="ekf_localization_odom" clear_params="true"> <!-- ======== STANDARD PARAMETERS ======== --> <param name="frequency" value="30"/> <param name="sensor_timeout" value="0.1"/> <!-- If this is set to true, no 3D information will be used in your state estimate. Use this if you are operating in a planar environment and want to ignore the effect of small variations in the ground plane that might otherwise be detected by, for example, an IMU. Defaults to false if unspecified. --> <param name="two_d_mode" value="true"/> <!-- REP-105 (http://www.ros.org/reps/rep-0105.html) specifies three principal coordinate frames: map, odom, and base_link. base_link is the coordinate frame that is affixed to the robot. The robot's position in the odom frame will drift over time, but is accurate in the short term and should be continuous. The odom frame is therefore the best frame for executing local motion plans. The map frame, like the odom frame, is a world-fixed coordinate frame, and while it contains the most globally accurate position estimate for your robot, it is subject to discrete jumps, e.g., due to the fusion of GPS data. Here is how to use the following settings: 1. Set the map_frame, odom_frame, and base_link frames to the appropriate frame names for your system. * If your system does not have a map_frame, just remove it, and make sure "world_frame" is set to the value of odom_frame. 2. If you are fusing continuous position data such as wheel encoder odometry, visual odometry, or IMU data, set "world_frame" to your odom_frame value. This is the default behavior for robot_localization's state estimation nodes. 3. If you are fusing global absolute position data that is subject to discrete jumps (e.g., GPS or position updates from landmark observations) then: 3a. Set your "world_frame" to your map_frame value 3b. MAKE SURE something else is generating the odom->base_link transform. Note that this can even be another instance of robot_localization! However, that instance should *not* fuse the global data. --> <param name="map_frame" value="map"/> <param name="odom_frame" value="odom"/> <param name="base_link_frame" value="base_link"/> <param name="world_frame" value="odom"/> <!-- Use this parameter to provide an offset to the transform generated by ekf_localization_node. This can be used for future dating the transform, which is required for interaction with some other packages. Defaults to 0.0 if unspecified. --> <param name="transform_time_offset" value="0.0"/> <!-- The filter accepts an arbitrary number of inputs from each input message type (Odometry, PoseStamped, TwistStamped, Imu). To add a new one, simply append the next number in the sequence to its base name, e.g., odom0, odom1, twist0, twist1, imu0, imu1, imu2, etc. The value should be the topic name. These parameters obviously have no default values, and must be specified. --> <param name="odom0" value="/rtabmap/odom"/> <param name="imu0" value="/imu/data"/> <!-- Each sensor reading updates some or all of the filter's state. These options give you greater control over which values from each measurement are fed to the filter. For example, if you have an odometry message as input, but only want to use its Z position value, then set the entire vector to false, except for the third entry. The order of the values is x, y, z, roll, pitch, yaw, vx, vy, vz, vroll, vpitch, vyaw, ax, ay, az. Note that not some message types lack certain variables. For example, a TwistWithCovarianceStamped message has no pose information, so the first six values would be meaningless in that case. Each vector defaults to all false if unspecified, effectively making this parameter required for each sensor. --> <rosparam param="odom0_config">[true, true, true, true, true, true, false, false, false, false, false, false, false, false, false]</rosparam> <rosparam param="imu0_config">[false, false, false, false, false, false, false, false, false, true, true, true, true, true, true]</rosparam> <!-- The best practice for including new sensors in robot_localization's state estimation nodes is to pass in velocity measurements and let the nodes integrate them. However, this isn't always feasible, and so the state estimation nodes support fusion of absolute measurements. If you have more than one sensor providing absolute measurements, however, you may run into problems if your covariances are not large enough, as the sensors will inevitably diverge from one another, causing the filter to jump back and forth rapidly. To combat this situation, you can either increase the covariances for the variables in question, or you can simply set the sensor's differential parameter to true. When differential mode is enabled, all absolute pose data is converted to velocity data by differentiating the absolute pose measurements. These velocities are then integrated as usual. NOTE: this only applies to sensors that provide absolute measurements, so setting differential to true for twit measurements has no effect. Users should take care when setting this to true for orientation variables: if you have only one source of absolute orientation data, you should not set the differential parameter to true. This is due to the fact that integration of velocities leads to slowly increasing error in the absolute (pose) variable. For position variables, this is acceptable. For orientation variables, it can lead to trouble. Users should make sure that all orientation variables have at least one source of absolute measurement. --> <param name="odom0_differential" value="false"/> <param name="imu0_differential" value="false"/> <!-- When the node starts, if this parameter is true, then the first measurement is treated as a "zero point" for all future measurements. While you can achieve the same effect with the differential paremeter, the key difference is that the relative parameter doesn't cause the measurement to be converted to a velocity before integrating it. If you simply want your measurements to start at 0 for a given sensor, set this to true. --> <param name="odom0_relative" value="true"/> <param name="imu0_relative" value="true"/> <!-- If we're including accelerations in our state estimate, then we'll probably want to remove any acceleration that is due to gravity for each IMU. If you don't want to, then set this to false. Defaults to false if unspecified. --> <param name="imu0_remove_gravitational_acceleration" value="true"/> <!-- If you're having trouble, try setting this to true, and then echo the /diagnostics_agg topic to see if the node is unhappy with any settings or data. --> <param name="print_diagnostics" value="true"/> <!-- ======== ADVANCED PARAMETERS ======== --> <!-- Most users will be able to remove these parameters from the launch file without any consequences. We recommend that users do not set values for these parameters without having a thorough understanding of the parameters do. --> <!-- By default, the subscription queue size for each message type is 1. If you wish to increase that so as not miss any messages (even if your frequency is set to a relatively small value), increase these. --> <param name="odom0_queue_size" value="10"/> <param name="imu0_queue_size" value="10"/> <!-- If your data is subject to outliers, use these threshold settings, expressed as Mahalanobis distances, to control how far away from the current vehicle state a sensor measurement is permitted to be. Each defaults to numeric_limits<double>::max() if unspecified. --> <param name="odom0_pose_rejection_threshold" value="5"/> <param name="odom0_twist_rejection_threshold" value="1"/> <param name="imu0_pose_rejection_threshold" value="0.3"/> <param name="imu0_twist_rejection_threshold" value="0.1"/> <param name="imu0_linear_acceleration_rejection_threshold" value="0.1"/> <!-- Debug settings. Not for the faint of heart. Outputs a ludicrous amount of information to the file specified by debug_out_file. I hope you like matrices! Defaults to false if unspecified. --> <param name="debug" value="false"/> <!-- Defaults to "robot_localization_debug.txt" if unspecified. --> <param name="debug_out_file" value="debug_ekf_localization_odom.txt"/> <!-- The process noise covariance matrix can be difficult to tune, and can vary for each application, so it is exposed as a configuration parameter. 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. --> <rosparam param="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]</rosparam> <!-- This represents the initial value for the state estimate error covariance matrix. Setting a diagonal value (a variance) to a large value will result in early measurements for that variable being accepted quickly. 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. --> <rosparam param="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]</rosparam> </node> <node pkg="robot_localization" type="ekf_localization_node" name="ekf_localization_map" clear_params="true"> <param name="frequency" value="30"/> <param name="sensor_timeout" value="0.1"/> <param name="two_d_mode" value="true"/> <param name="map_frame" value="map"/> <param name="odom_frame" value="odom"/> <param name="base_link_frame" value="base_link"/> <param name="world_frame" value="map"/> <param name="transform_time_offset" value="0.0"/> <param name="odom0" value="/rtabmap/odom"/> <!-- x y z roll pitch yaw vx vy vz vroll vpitch vyaw ax ay az --> <rosparam param="odom0_config">[true, true, true, true, true, true, false, false, false, false, false, false, false, false, false]</rosparam> <param name="odom0_differential" value="false"/> <param name="odom0_relative" value="true"/> <param name="print_diagnostics" value="true"/> <!-- ======== ADVANCED PARAMETERS ======== --> <param name="odom0_queue_size" value="10"/> <!-- If your data is subject to outliers, use these threshold settings, expressed as Mahalanobis distances, to control how far away from the current vehicle state a sensor measurement is permitted to be. Each defaults to numeric_limits<double>::max() if unspecified. --> <param name="odom0_pose_rejection_threshold" value="5"/> <param name="odom0_twist_rejection_threshold" value="1"/> <param name="debug" value="false"/> <param name="debug_out_file" value="debug_ekf_localization_map.txt"/> <rosparam param="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]</rosparam> <rosparam param="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]</rosparam> </node> </launch> </launch> https://github.com/mantraes/ROS-Launch-Files.git The original launch file is robo_loco.launch however we found something on the internet claiming that the order in which the instances of RL happen may effect how RL publishes its transforms so we made 2 separate launch files to try to see if that worked and those are called ekf_localization_map and ekf_localization_odom Thanks for the help and let me know if you need anything else! 5 No.5 Revision updated 2016-02-09 09:05:49 -0500 Robot_Localization not publishing transform to odom We are using robot_localization to filter some of our sensor outputs. We are running two instances of RL but the one that takes care of the transform from map to the odom frame is not publishing the transform. For the instance of RL that is responsible for the transform between the map frame to the odom frame the diagnostics say /odom/filtered: no events recorded. here are our launch files: <launch> <node pkg="robot_localization" type="ekf_localization_node" name="ekf_localization_odom" clear_params="true"> <!-- ======== STANDARD PARAMETERS ======== --> <param name="frequency" value="30"/> <param name="sensor_timeout" value="0.1"/> <!-- If this is set to true, no 3D information will be used in your state estimate. Use this if you are operating in a planar environment and want to ignore the effect of small variations in the ground plane that might otherwise be detected by, for example, an IMU. Defaults to false if unspecified. --> <param name="two_d_mode" value="true"/> <!-- REP-105 (http://www.ros.org/reps/rep-0105.html) specifies three principal coordinate frames: map, odom, and base_link. base_link is the coordinate frame that is affixed to the robot. The robot's position in the odom frame will drift over time, but is accurate in the short term and should be continuous. The odom frame is therefore the best frame for executing local motion plans. The map frame, like the odom frame, is a world-fixed coordinate frame, and while it contains the most globally accurate position estimate for your robot, it is subject to discrete jumps, e.g., due to the fusion of GPS data. Here is how to use the following settings: 1. Set the map_frame, odom_frame, and base_link frames to the appropriate frame names for your system. * If your system does not have a map_frame, just remove it, and make sure "world_frame" is set to the value of odom_frame. 2. If you are fusing continuous position data such as wheel encoder odometry, visual odometry, or IMU data, set "world_frame" to your odom_frame value. This is the default behavior for robot_localization's state estimation nodes. 3. If you are fusing global absolute position data that is subject to discrete jumps (e.g., GPS or position updates from landmark observations) then: 3a. Set your "world_frame" to your map_frame value 3b. MAKE SURE something else is generating the odom->base_link transform. Note that this can even be another instance of robot_localization! However, that instance should *not* fuse the global data. --> <param name="map_frame" value="map"/> <param name="odom_frame" value="odom"/> <param name="base_link_frame" value="base_link"/> <param name="world_frame" value="odom"/> <!-- Use this parameter to provide an offset to the transform generated by ekf_localization_node. This can be used for future dating the transform, which is required for interaction with some other packages. Defaults to 0.0 if unspecified. --> <param name="transform_time_offset" value="0.0"/> <!-- The filter accepts an arbitrary number of inputs from each input message type (Odometry, PoseStamped, TwistStamped, Imu). To add a new one, simply append the next number in the sequence to its base name, e.g., odom0, odom1, twist0, twist1, imu0, imu1, imu2, etc. The value should be the topic name. These parameters obviously have no default values, and must be specified. --> <param name="odom0" value="/rtabmap/odom"/> <param name="imu0" value="/imu/data"/> <!-- Each sensor reading updates some or all of the filter's state. These options give you greater control over which values from each measurement are fed to the filter. For example, if you have an odometry message as input, but only want to use its Z position value, then set the entire vector to false, except for the third entry. The order of the values is x, y, z, roll, pitch, yaw, vx, vy, vz, vroll, vpitch, vyaw, ax, ay, az. Note that not some message types lack certain variables. For example, a TwistWithCovarianceStamped message has no pose information, so the first six values would be meaningless in that case. Each vector defaults to all false if unspecified, effectively making this parameter required for each sensor. --> <rosparam param="odom0_config">[true, true, true, true, true, true, false, false, false, false, false, false, false, false, false]</rosparam> <rosparam param="imu0_config">[false, false, false, false, false, false, false, false, false, true, true, true, true, true, true]</rosparam> <!-- The best practice for including new sensors in robot_localization's state estimation nodes is to pass in velocity measurements and let the nodes integrate them. However, this isn't always feasible, and so the state estimation nodes support fusion of absolute measurements. If you have more than one sensor providing absolute measurements, however, you may run into problems if your covariances are not large enough, as the sensors will inevitably diverge from one another, causing the filter to jump back and forth rapidly. To combat this situation, you can either increase the covariances for the variables in question, or you can simply set the sensor's differential parameter to true. When differential mode is enabled, all absolute pose data is converted to velocity data by differentiating the absolute pose measurements. These velocities are then integrated as usual. NOTE: this only applies to sensors that provide absolute measurements, so setting differential to true for twit measurements has no effect. Users should take care when setting this to true for orientation variables: if you have only one source of absolute orientation data, you should not set the differential parameter to true. This is due to the fact that integration of velocities leads to slowly increasing error in the absolute (pose) variable. For position variables, this is acceptable. For orientation variables, it can lead to trouble. Users should make sure that all orientation variables have at least one source of absolute measurement. --> <param name="odom0_differential" value="false"/> <param name="imu0_differential" value="false"/> <!-- When the node starts, if this parameter is true, then the first measurement is treated as a "zero point" for all future measurements. While you can achieve the same effect with the differential paremeter, the key difference is that the relative parameter doesn't cause the measurement to be converted to a velocity before integrating it. If you simply want your measurements to start at 0 for a given sensor, set this to true. --> <param name="odom0_relative" value="true"/> <param name="imu0_relative" value="true"/> <!-- If we're including accelerations in our state estimate, then we'll probably want to remove any acceleration that is due to gravity for each IMU. If you don't want to, then set this to false. Defaults to false if unspecified. --> <param name="imu0_remove_gravitational_acceleration" value="true"/> <!-- If you're having trouble, try setting this to true, and then echo the /diagnostics_agg topic to see if the node is unhappy with any settings or data. --> <param name="print_diagnostics" value="true"/> <!-- ======== ADVANCED PARAMETERS ======== --> <!-- Most users will be able to remove these parameters from the launch file without any consequences. We recommend that users do not set values for these parameters without having a thorough understanding of the parameters do. --> <!-- By default, the subscription queue size for each message type is 1. If you wish to increase that so as not miss any messages (even if your frequency is set to a relatively small value), increase these. --> <param name="odom0_queue_size" value="10"/> <param name="imu0_queue_size" value="10"/> <!-- If your data is subject to outliers, use these threshold settings, expressed as Mahalanobis distances, to control how far away from the current vehicle state a sensor measurement is permitted to be. Each defaults to numeric_limits<double>::max() if unspecified. --> <param name="odom0_pose_rejection_threshold" value="5"/> <param name="odom0_twist_rejection_threshold" value="1"/> <param name="imu0_pose_rejection_threshold" value="0.3"/> <param name="imu0_twist_rejection_threshold" value="0.1"/> <param name="imu0_linear_acceleration_rejection_threshold" value="0.1"/> <!-- Debug settings. Not for the faint of heart. Outputs a ludicrous amount of information to the file specified by debug_out_file. I hope you like matrices! Defaults to false if unspecified. --> <param name="debug" value="false"/> <!-- Defaults to "robot_localization_debug.txt" if unspecified. --> <param name="debug_out_file" value="debug_ekf_localization_odom.txt"/> <!-- The process noise covariance matrix can be difficult to tune, and can vary for each application, so it is exposed as a configuration parameter. 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. --> <rosparam param="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]</rosparam> <!-- This represents the initial value for the state estimate error covariance matrix. Setting a diagonal value (a variance) to a large value will result in early measurements for that variable being accepted quickly. 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. --> <rosparam param="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]</rosparam> </node> <node pkg="robot_localization" type="ekf_localization_node" name="ekf_localization_map" clear_params="true"> <param name="frequency" value="30"/> <param name="sensor_timeout" value="0.1"/> <param name="two_d_mode" value="true"/> <param name="map_frame" value="map"/> <param name="odom_frame" value="odom"/> <param name="base_link_frame" value="base_link"/> <param name="world_frame" value="map"/> <param name="transform_time_offset" value="0.0"/> <param name="odom0" value="/rtabmap/odom"/> <!-- x y z roll pitch yaw vx vy vz vroll vpitch vyaw ax ay az --> <rosparam param="odom0_config">[true, true, true, true, true, true, false, false, false, false, false, false, false, false, false]</rosparam> <param name="odom0_differential" value="false"/> <param name="odom0_relative" value="true"/> <param name="print_diagnostics" value="true"/> <!-- ======== ADVANCED PARAMETERS ======== --> <param name="odom0_queue_size" value="10"/> <!-- If your data is subject to outliers, use these threshold settings, expressed as Mahalanobis distances, to control how far away from the current vehicle state a sensor measurement is permitted to be. Each defaults to numeric_limits<double>::max() if unspecified. --> <param name="odom0_pose_rejection_threshold" value="5"/> <param name="odom0_twist_rejection_threshold" value="1"/> <param name="debug" value="false"/> <param name="debug_out_file" value="debug_ekf_localization_map.txt"/> <rosparam param="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]</rosparam> <rosparam param="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]</rosparam> </node> </launch> https://github.com/mantraes/ROS-Launch-Files.git The original launch file is robo_loco.launch however we found something on the internet claiming that the order in which the instances of RL happen may effect how RL publishes its transforms so we made 2 separate launch files to try to see if that worked and those are called ekf_localization_map and ekf_localization_odom Thanks for the help and let me know if you need anything else! 6 No.6 Revision updated 2016-02-09 09:54:08 -0500 Robot_Localization not publishing transform to odom We are using robot_localization to filter some of our sensor outputs. We are running two instances of RL but the one that takes care of the transform from map to the odom frame is not publishing the transform. For the instance of RL that is responsible for the transform between the map frame to the odom frame the diagnostics say /odom/filtered: no events recorded. here are our launch files: <launch> <node pkg="robot_localization" type="ekf_localization_node" name="ekf_localization_odom" clear_params="true"> <!-- ======== STANDARD PARAMETERS ======== --> <param name="frequency" value="30"/> <param name="sensor_timeout" value="0.1"/> <!-- If this is set to true, no 3D information will be used in your state estimate. Use this if you are operating in a planar environment and want to ignore the effect of small variations in the ground plane that might otherwise be detected by, for example, an IMU. Defaults to false if unspecified. --> <param name="two_d_mode" value="true"/> <!-- REP-105 (http://www.ros.org/reps/rep-0105.html) specifies three principal coordinate frames: map, odom, and base_link. base_link is the coordinate frame that is affixed to the robot. The robot's position in the odom frame will drift over time, but is accurate in the short term and should be continuous. The odom frame is therefore the best frame for executing local motion plans. The map frame, like the odom frame, is a world-fixed coordinate frame, and while it contains the most globally accurate position estimate for your robot, it is subject to discrete jumps, e.g., due to the fusion of GPS data. Here is how to use the following settings: 1. Set the map_frame, odom_frame, and base_link frames to the appropriate frame names for your system. * If your system does not have a map_frame, just remove it, and make sure "world_frame" is set to the value of odom_frame. 2. If you are fusing continuous position data such as wheel encoder odometry, visual odometry, or IMU data, set "world_frame" to your odom_frame value. This is the default behavior for robot_localization's state estimation nodes. 3. If you are fusing global absolute position data that is subject to discrete jumps (e.g., GPS or position updates from landmark observations) then: 3a. Set your "world_frame" to your map_frame value 3b. MAKE SURE something else is generating the odom->base_link transform. Note that this can even be another instance of robot_localization! However, that instance should *not* fuse the global data. --> <param name="map_frame" value="map"/> <param name="odom_frame" value="odom"/> <param name="base_link_frame" value="base_link"/> <param name="world_frame" value="odom"/> <!-- Use this parameter to provide an offset to the transform generated by ekf_localization_node. This can be used for future dating the transform, which is required for interaction with some other packages. Defaults to 0.0 if unspecified. --> <param name="transform_time_offset" value="0.0"/> <!-- The filter accepts an arbitrary number of inputs from each input message type (Odometry, PoseStamped, TwistStamped, Imu). To add a new one, simply append the next number in the sequence to its base name, e.g., odom0, odom1, twist0, twist1, imu0, imu1, imu2, etc. The value should be the topic name. These parameters obviously have no default values, and must be specified. --> <param name="odom0" value="/rtabmap/odom"/> <param name="imu0" value="/imu/data"/> <!-- Each sensor reading updates some or all of the filter's state. These options give you greater control over which values from each measurement are fed to the filter. For example, if you have an odometry message as input, but only want to use its Z position value, then set the entire vector to false, except for the third entry. The order of the values is x, y, z, roll, pitch, yaw, vx, vy, vz, vroll, vpitch, vyaw, ax, ay, az. Note that not some message types lack certain variables. For example, a TwistWithCovarianceStamped message has no pose information, so the first six values would be meaningless in that case. Each vector defaults to all false if unspecified, effectively making this parameter required for each sensor. --> <rosparam param="odom0_config">[true, true, true, true, true, true, false, false, false, false, false, false, false, false, false]</rosparam> <rosparam param="imu0_config">[false, false, false, false, false, false, false, false, false, true, true, true, true, true, true]</rosparam> <!-- The best practice for including new sensors in robot_localization's state estimation nodes is to pass in velocity measurements and let the nodes integrate them. However, this isn't always feasible, and so the state estimation nodes support fusion of absolute measurements. If you have more than one sensor providing absolute measurements, however, you may run into problems if your covariances are not large enough, as the sensors will inevitably diverge from one another, causing the filter to jump back and forth rapidly. To combat this situation, you can either increase the covariances for the variables in question, or you can simply set the sensor's differential parameter to true. When differential mode is enabled, all absolute pose data is converted to velocity data by differentiating the absolute pose measurements. These velocities are then integrated as usual. NOTE: this only applies to sensors that provide absolute measurements, so setting differential to true for twit measurements has no effect. Users should take care when setting this to true for orientation variables: if you have only one source of absolute orientation data, you should not set the differential parameter to true. This is due to the fact that integration of velocities leads to slowly increasing error in the absolute (pose) variable. For position variables, this is acceptable. For orientation variables, it can lead to trouble. Users should make sure that all orientation variables have at least one source of absolute measurement. --> <param name="odom0_differential" value="false"/> <param name="imu0_differential" value="false"/> <!-- When the node starts, if this parameter is true, then the first measurement is treated as a "zero point" for all future measurements. While you can achieve the same effect with the differential paremeter, the key difference is that the relative parameter doesn't cause the measurement to be converted to a velocity before integrating it. If you simply want your measurements to start at 0 for a given sensor, set this to true. --> <param name="odom0_relative" value="true"/> <param name="imu0_relative" value="true"/> <!-- If we're including accelerations in our state estimate, then we'll probably want to remove any acceleration that is due to gravity for each IMU. If you don't want to, then set this to false. Defaults to false if unspecified. --> <param name="imu0_remove_gravitational_acceleration" value="true"/> <!-- If you're having trouble, try setting this to true, and then echo the /diagnostics_agg topic to see if the node is unhappy with any settings or data. --> <param name="print_diagnostics" value="true"/> <!-- ======== ADVANCED PARAMETERS ======== --> <!-- Most users will be able to remove these parameters from the launch file without any consequences. We recommend that users do not set values for these parameters without having a thorough understanding of the parameters do. --> <!-- By default, the subscription queue size for each message type is 1. If you wish to increase that so as not miss any messages (even if your frequency is set to a relatively small value), increase these. --> <param name="odom0_queue_size" value="10"/> <param name="imu0_queue_size" value="10"/> <!-- If your data is subject to outliers, use these threshold settings, expressed as Mahalanobis distances, to control how far away from the current vehicle state a sensor measurement is permitted to be. Each defaults to numeric_limits<double>::max() if unspecified. --> <param name="odom0_pose_rejection_threshold" value="5"/> <param name="odom0_twist_rejection_threshold" value="1"/> <param name="imu0_pose_rejection_threshold" value="0.3"/> <param name="imu0_twist_rejection_threshold" value="0.1"/> <param name="imu0_linear_acceleration_rejection_threshold" value="0.1"/> <!-- Debug settings. Not for the faint of heart. Outputs a ludicrous amount of information to the file specified by debug_out_file. I hope you like matrices! Defaults to false if unspecified. --> <param name="debug" value="false"/> <!-- Defaults to "robot_localization_debug.txt" if unspecified. --> <param name="debug_out_file" value="debug_ekf_localization_odom.txt"/> <!-- The process noise covariance matrix can be difficult to tune, and can vary for each application, so it is exposed as a configuration parameter. 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. --> <rosparam param="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]</rosparam> <!-- This represents the initial value for the state estimate error covariance matrix. Setting a diagonal value (a variance) to a large value will result in early measurements for that variable being accepted quickly. 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. --> <rosparam param="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]</rosparam> </node> <node pkg="robot_localization" type="ekf_localization_node" name="ekf_localization_map" clear_params="true"> <param name="frequency" value="30"/> <param name="sensor_timeout" value="0.1"/> <param name="two_d_mode" value="true"/> <param name="map_frame" value="map"/> <param name="odom_frame" value="odom"/> <param name="base_link_frame" value="base_link"/> <param name="world_frame" value="map"/> <param name="transform_time_offset" value="0.0"/> <param name="odom0" value="/rtabmap/odom"/> <!-- x y z roll pitch yaw vx vy vz vroll vpitch vyaw ax ay az --> <rosparam param="odom0_config">[true, true, true, true, true, true, false, false, false, false, false, false, false, false, false]</rosparam> <param name="odom0_differential" value="false"/> <param name="odom0_relative" value="true"/> <param name="print_diagnostics" value="true"/> <!-- ======== ADVANCED PARAMETERS ======== --> <param name="odom0_queue_size" value="10"/> <!-- If your data is subject to outliers, use these threshold settings, expressed as Mahalanobis distances, to control how far away from the current vehicle state a sensor measurement is permitted to be. Each defaults to numeric_limits<double>::max() if unspecified. --> <param name="odom0_pose_rejection_threshold" value="5"/> <param name="odom0_twist_rejection_threshold" value="1"/> <param name="debug" value="false"/> <param name="debug_out_file" value="debug_ekf_localization_map.txt"/> <rosparam param="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]</rosparam> <rosparam param="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]</rosparam> </node> </launch> https://github.com/mantraes/ROS-Launch-Files.git The original launch file is robo_loco.launch however we found something on the internet claiming that the order in which the instances of RL happen may effect how RL publishes its transforms so we made 2 separate launch files to try to see if that worked and those are called ekf_localization_map and ekf_localization_odom Thanks for the help and let me know if you need anything else! 7 No.7 Revision updated 2016-02-09 10:00:48 -0500 Robot_Localization not publishing transform to odom We are using robot_localization to filter some of our sensor outputs. We are running two instances of RL but the one that takes care of the transform from map to the odom frame is not publishing the transform. For the instance of RL that is responsible for the transform between the map frame to the odom frame the diagnostics say /odom/filtered: no events recorded. here are our launch files: <launch> <node pkg="robot_localization" type="ekf_localization_node" name="ekf_localization_odom" clear_params="true"> <param name="frequency" value="30"/> <param name="sensor_timeout" value="0.1"/> <param name="two_d_mode" value="true"/> <param name="map_frame" value="map"/> <param name="odom_frame" value="odom"/> <param name="base_link_frame" value="base_link"/> <param name="world_frame" value="odom"/> <param name="transform_time_offset" value="0.0"/> <param name="odom0" value="/rtabmap/odom"/> <param name="imu0" value="/imu/data"/> <rosparam param="odom0_config">[true, true, true, true, true, true, false, false, false, false, false, false, false, false, false]</rosparam> <rosparam param="imu0_config">[false, false, false, false, false, false, false, false, false, true, true, true, true, true, true]</rosparam> <param name="odom0_differential" value="false"/> <param name="imu0_differential" value="false"/> <param name="odom0_relative" value="true"/> <param name="imu0_relative" value="true"/> <param name="imu0_remove_gravitational_acceleration" value="true"/> <param name="print_diagnostics" value="true"/> <param name="odom0_queue_size" value="10"/> <param name="imu0_queue_size" value="10"/> <param name="odom0_pose_rejection_threshold" value="5"/> <param name="odom0_twist_rejection_threshold" value="1"/> <param name="imu0_pose_rejection_threshold" value="0.3"/> <param name="imu0_twist_rejection_threshold" value="0.1"/> <param name="imu0_linear_acceleration_rejection_threshold" value="0.1"/> <param name="debug" value="false"/> <param name="debug_out_file" value="debug_ekf_localization_odom.txt"/> <rosparam param="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]</rosparam> <rosparam param="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]</rosparam> </node> <node pkg="robot_localization" type="ekf_localization_node" name="ekf_localization_map" clear_params="true"> <param name="frequency" value="30"/> <param name="sensor_timeout" value="0.1"/> <param name="two_d_mode" value="true"/> <param name="map_frame" value="map"/> <param name="odom_frame" value="odom"/> <param name="base_link_frame" value="base_link"/> <param name="world_frame" value="map"/> <param name="transform_time_offset" value="0.0"/> <param name="odom0" value="/rtabmap/odom"/> <rosparam param="odom0_config">[true, true, true, true, true, true, false, false, false, false, false, false, false, false, false]</rosparam> <param name="odom0_differential" value="false"/> <param name="odom0_relative" value="true"/> <param name="print_diagnostics" value="true"/> <param name="odom0_queue_size" value="10"/> <param name="odom0_pose_rejection_threshold" value="5"/> <param name="odom0_twist_rejection_threshold" value="1"/> <param name="debug" value="false"/> <param name="debug_out_file" value="debug_ekf_localization_map.txt"/> <rosparam param="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]</rosparam> <rosparam param="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]</rosparam> </node> </launch> https://github.com/mantraes/ROS-Launch-Files.git The original launch file is robo_loco.launch however we found something on the internet claiming that the order in which the instances of RL happen may effect how RL publishes its transforms so we made 2 separate launch files to try to see if that worked and those are called ekf_localization_map and ekf_localization_odom Thanks for the help and let me know if you need anything else! Here are inputs from the visual odometrey from RTabMap and the UM7 imu we are using: 8 No.8 Revision updated 2016-02-09 10:04:41 -0500 Robot_Localization not publishing transform to odom We are using robot_localization to filter some of our sensor outputs. We are running two instances of RL but the one that takes care of the transform from map to the odom frame is not publishing the transform. For the instance of RL that is responsible for the transform between the map frame to the odom frame the diagnostics say /odom/filtered: no events recorded. here are our launch files: <launch> <node pkg="robot_localization" type="ekf_localization_node" name="ekf_localization_odom" clear_params="true"> <param name="frequency" value="30"/> <param name="sensor_timeout" value="0.1"/> <param name="two_d_mode" value="true"/> <param name="map_frame" value="map"/> <param name="odom_frame" value="odom"/> <param name="base_link_frame" value="base_link"/> <param name="world_frame" value="odom"/> <param name="transform_time_offset" value="0.0"/> <param name="odom0" value="/rtabmap/odom"/> <param name="imu0" value="/imu/data"/> <rosparam param="odom0_config">[true, true, true, true, true, true, false, false, false, false, false, false, false, false, false]</rosparam> <rosparam param="imu0_config">[false, false, false, false, false, false, false, false, false, true, true, true, true, true, true]</rosparam> <param name="odom0_differential" value="false"/> <param name="imu0_differential" value="false"/> <param name="odom0_relative" value="true"/> <param name="imu0_relative" value="true"/> <param name="imu0_remove_gravitational_acceleration" value="true"/> <param name="print_diagnostics" value="true"/> <param name="odom0_queue_size" value="10"/> <param name="imu0_queue_size" value="10"/> <param name="odom0_pose_rejection_threshold" value="5"/> <param name="odom0_twist_rejection_threshold" value="1"/> <param name="imu0_pose_rejection_threshold" value="0.3"/> <param name="imu0_twist_rejection_threshold" value="0.1"/> <param name="imu0_linear_acceleration_rejection_threshold" value="0.1"/> <param name="debug" value="false"/> <param name="debug_out_file" value="debug_ekf_localization_odom.txt"/> <rosparam param="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]</rosparam> <rosparam param="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]</rosparam> </node> <node pkg="robot_localization" type="ekf_localization_node" name="ekf_localization_map" clear_params="true"> <param name="frequency" value="30"/> <param name="sensor_timeout" value="0.1"/> <param name="two_d_mode" value="true"/> <param name="map_frame" value="map"/> <param name="odom_frame" value="odom"/> <param name="base_link_frame" value="base_link"/> <param name="world_frame" value="map"/> <param name="transform_time_offset" value="0.0"/> <param name="odom0" value="/rtabmap/odom"/> <rosparam param="odom0_config">[true, true, true, true, true, true, false, false, false, false, false, false, false, false, false]</rosparam> <param name="odom0_differential" value="false"/> <param name="odom0_relative" value="true"/> <param name="print_diagnostics" value="true"/> <param name="odom0_queue_size" value="10"/> <param name="odom0_pose_rejection_threshold" value="5"/> <param name="odom0_twist_rejection_threshold" value="1"/> <param name="debug" value="false"/> <param name="debug_out_file" value="debug_ekf_localization_map.txt"/> <rosparam param="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]</rosparam> <rosparam param="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]</rosparam> </node> </launch> https://github.com/mantraes/ROS-Launch-Files.git The original launch file is robo_loco.launch however we found something on the internet claiming that the order in which the instances of RL happen may effect how RL publishes its transforms so we made 2 separate launch files to try to see if that worked and those are called ekf_localization_map and ekf_localization_odom Thanks for the help and let me know if you need anything else! Here are inputs from the visual odometrey from RTabMap and the UM7 imu we are using: 


 ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license. about | faq | help | privacy policy | terms of service Powered by Askbot version 0.10.2 Please note: ROS Answers requires javascript to work properly, please enable javascript in your browser, here is how //IE fix to hide the red margin var noscript = document.getElementsByTagName('noscript')[0]; noscript.style.padding = '0px'; noscript.style.backgroundColor = 'transparent'; askbot['urls']['mark_read_message'] = '/s/messages/markread/'; askbot['urls']['get_tags_by_wildcard'] = '/s/get-tags-by-wildcard/'; askbot['urls']['get_tag_list'] = '/s/get-tag-list/'; askbot['urls']['follow_user'] = '/followit/follow/user/{{userId}}/'; askbot['urls']['unfollow_user'] = '/followit/unfollow/user/{{userId}}/'; askbot['urls']['user_signin'] = '/account/signin/'; askbot['urls']['getEditor'] = '/s/get-editor/'; askbot['urls']['apiGetQuestions'] = '/s/api/get_questions/'; askbot['urls']['ask'] = '/questions/ask/'; askbot['urls']['questions'] = '/questions/'; askbot['settings']['groupsEnabled'] = false; askbot['settings']['static_url'] = '/m/'; askbot['settings']['minSearchWordLength'] = 3; askbot['settings']['mathjaxEnabled'] = false; askbot['settings']['sharingSuffixText'] = ''; askbot['settings']['errorPlacement'] = 'after-label'; askbot['data']['maxCommentLength'] = 1000; askbot['settings']['editorType'] = 'markdown'; askbot['settings']['commentsEditorType'] = 'rich\u002Dtext'; askbot['messages']['askYourQuestion'] = 'Ask Your Question'; askbot['messages']['acceptOwnAnswer'] = 'accept or unaccept your own answer'; askbot['messages']['followQuestions'] = 'follow questions'; askbot['settings']['allowedUploadFileTypes'] = [ "jpg", "jpeg", "gif", "bmp", "png", "tiff" ]; askbot['data']['haveFlashNotifications'] = true; askbot['data']['activeTab'] = 'questions'; askbot['settings']['csrfCookieName'] = 'csrftoken'; askbot['data']['searchUrl'] = ''; /*<![CDATA[*/ $('.mceStatusbar').remove();//a hack to remove the tinyMCE status bar$(document).ready(function(){ // focus input on the search bar endcomment var activeTab = askbot['data']['activeTab']; if (inArray(activeTab, ['users', 'questions', 'tags', 'badges'])) { var searchInput = $('#keywords'); } else if (activeTab === 'ask') { var searchInput =$('#id_title'); } else { var searchInput = undefined; animateHashes(); } var wasScrolled = $('#scroll-mem').val(); if (searchInput && !wasScrolled) { searchInput.focus(); putCursorAtEnd(searchInput); } var haveFullTextSearchTab = inArray(activeTab, ['questions', 'badges', 'ask']); var haveUserProfilePage =$('body').hasClass('user-profile-page'); if ((haveUserProfilePage || haveFullTextSearchTab) && searchInput && searchInput.length) { var search = new FullTextSearch(); askbot['controllers'] = askbot['controllers'] || {}; askbot['controllers']['fullTextSearch'] = search; search.setSearchUrl(askbot['data']['searchUrl']); if (activeTab === 'ask') { search.setAskButtonEnabled(false); } search.decorate(searchInput); } else if (activeTab === 'tags') { var search = new TagSearch(); search.decorate(searchInput); } if (askbot['data']['userIsAdminOrMod']) { $('body').addClass('admin'); } if (askbot['settings']['groupsEnabled']) { askbot['urls']['add_group'] = "/s/add-group/"; var group_dropdown = new GroupDropdown();$('.groups-dropdown').append(group_dropdown.getElement()); } var userRep = $('#userToolsNav .reputation'); if (userRep.length) { var showPermsTrigger = new ShowPermsTrigger(); showPermsTrigger.decorate(userRep); } }); if (askbot['data']['haveFlashNotifications']) {$('#validate_email_alert').click(function(){notify.close(true)}) notify.show(); } var langNav = $('.lang-nav'); if (langNav.length) { var nav = new LangNav(); nav.decorate(langNav); } /*]]>*/ var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www."); document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E")); try { var pageTracker = _gat._getTracker('UA-17821189-3'); pageTracker._trackPageview(); } catch(err) {} //todo - take this out into .js file$(document).ready(function(){ $('div.revision div[id^=rev-header-]').bind('click', function(){ var revId = this.id.substr(11); toggleRev(revId); }); lanai.highlightSyntax(); }); function toggleRev(id) { var arrow =$("#rev-arrow-" + id); var visible = arrow.attr("src").indexOf("hide") > -1; if (visible) { var image_path = '/m/default/media/images/expander-arrow-show.gif?v=28'; } else { var image_path = '/m/default/media/images/expander-arrow-hide.gif?v=28'; } image_path = image_path + "?v=28"; arrow.attr("src", image_path); \$("#rev-body-" + id).slideToggle("fast"); } for (url_name in askbot['urls']){ askbot['urls'][url_name] = cleanUrl(askbot['urls'][url_name]); }