ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
1

robot_localization asking for map to odom transform

asked 2018-03-15 20:27:30 -0600

emilyfy gravatar image

updated 2019-07-05 10:56:48 -0600

jayess gravatar image

So I just recently migrated from robot_pose_ekf to robot_localization as I heard it's better. I'm fusing data from wheel odometry, imu and laser_scan_matcher as odom0, imu0 and pose0 respectively. I followed the instructions in configuring the parameters and set the frames as such:

map_frame: map
odom_frame: odom
base_link_frame: base_link
world_frame: map

The documentation tells me this should make the ekf_localization node publish the transform from map to odom if the publish_tf param is set to true. Sure, it does, but I also keep getting this warning:

[ WARN] [1521163510.296212370]: Transform from odom to map was unavailable for the time requested. Using latest instead.

And once in a while this warning:

[ WARN] [1521163517.010447912]: Failed to meet update rate! Took 0.035404531000000002972 seconds. Try decreasing the rate, limiting sensor output frequency, or limiting the number of sensors.

Why would it be looking up the transform of what it's supposed to be broadcasting instead? It's still doing its job, but I'm just concerned somewhere it ignores some data because of this warning and curious why the warning comes up in the first place. Thanks in advance for any insight on the matter!

Here's my TF tree: image description

edit retag flag offensive close merge delete

Comments

Can you post your TF tree?

stevejp gravatar image stevejp  ( 2018-03-16 06:24:55 -0600 )edit

2 Answers

Sort by ยป oldest newest most voted
0

answered 2018-03-16 03:33:54 -0600

tuandl gravatar image

It seems like you are trying to localize your robot globally. Hence, according to the document, you should have something else publishes the transformation from odm->base_link. You may want to refer to this #q258330

edit flag offensive delete link more

Comments

1

Yeah, I do have a node doing that. It seems like I have a different problem from the one you referred me to though, my output is correct but I'm just wondering why the warning.

emilyfy gravatar image emilyfy  ( 2018-03-17 19:09:11 -0600 )edit

@emilyfy I have this exact same problem, where I want the robot_localization to calculate map->odom but it also shows me that look up warning of the same transform being unavailable.

As per my knowledge, the robot_localization is trying to convert odometry data to map frame before fusion in every iteration, hence it needs this transform, where in fact it is publishing the transform itself.

Did you find any solution for this? I am worried that my odometry data is not being transformed to the map frame correctly in every iteration before fusion leading to bad results. is it possible to share your launch file?

indraneel gravatar image indraneel  ( 2019-06-25 06:03:11 -0600 )edit
1

answered 2019-07-01 06:52:05 -0600

indraneel gravatar image

updated 2019-07-05 10:57:19 -0600

jayess gravatar image

A more appropriate answer to this issue is that, there is a mismatch in timestamps between when the ekf_localization is making that map->odom transform available and when the package is requesting for the same transform.

This solves the issue : We need to tell robot_localization package to publish the transform T seconds into the future so that the next iteration of fusion can use it where T depends on frequency of the robot_localization package. We used the transform time offset parameter to introduce this offset in the timestamps published by the robot_localization node. The new tf_tree after introducing the offset should reflect this change. In our case :

<?xml version="1.0"?>
<launch>

  <arg name="id" default="0"/> 

  <node pkg="robot_localization" type="ekf_localization_node" name="ekf" output="screen" > 

    <!-- Frequency of the main run loop. -->
    <param name="frequency" value="50"/>
    <!-- <param name="sensor_timeout" value="0.1"/> -->
    <!-- <param name="transform_timeout" value="0.1"/> -->
    <param name="odom_frame" value="base_link_origin"/>
    <param name="base_link_frame" value="base_link"/>
    <param name="world_frame" value="world"/>
    <param name="map_frame" value="world"/>
    <param name="two_d_mode" value="false"/>
    <param name="print_diagnostics" value="true"/>
    <param name="publish_tf" value="true"/>
    <param name="transform_time_offset" value="0.05"/> 

    <remap from="odometry/filtered" to="odometry/filtered"/>

    <!-- If the odometry provides both position and linear velocity, fuse the linear velocity.If the odometry provides both orientation angular velocity, fuse the orientation. -->

    <param name="odom0" value="tracker_odom"/>                           
    <rosparam param="odom0_config">[true, true,true,                <!-- x, y, z position -->
                                    false, false, true,                <!-- roll, pitch, yaw angles-->
                                    true, true, true,                   <!-- x/y/z velocity -->
                                    true, true, true,                   <!-- roll/pitch/yaw velocity -->
                                    false, false, false]</rosparam>     <!-- Acceleration -->
    <param name="odom0_differential" value="false"/>
    <param name="odom0_relative" value="false"/>

    <param name="odom1" value="jv_pose_new"/>
    <rosparam param="odom1_config">[true,  true,  true,
                                  false, true, true,
                                  false, false, false,
                                  false, false, false,
                                  false, false, false]</rosparam>
    <param name="odom1_differential" value="false"/>
    <param name="odom1_relative" value="false"/>



     <rosparam param="process_noise_covariance">[0.5, 0,    0,    0,    0,    0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                           0,    0.5, 0,    0,    0,    0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                           0,    0,    0.6, 0,    0,    0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                           0,    0,    0,    0.3, 0,    0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                           0,    0,    0,    0,    0.3, 0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                           0,    0,    0,    0,    0,    0.6, 0,     0,     0,    0,    0,    0,    0,    0,    0,
                           0,    0,    0,    0,    0,    0,    0.25, 0,     0,    0,    0,    0,    0,    0,    0,
                           0,    0,    0,    0,    0,    0,    0,     0.25, 0,    0,    0,    0,    0,    0,    0,
                           0,    0,    0,    0,    0,    0,    0,     0,     0.4, 0,    0,    0,    0,    0,    0,
                           0,    0,    0,    0 ...
(more)
edit flag offensive delete link more

Comments

Hello all, we have been having the same exact problem for quite a while now. Can you please post your XML solution code .launch file for the robot_localization node?

RayROS gravatar image RayROS  ( 2019-07-01 15:24:11 -0600 )edit

@RayROS I have edited my answer. Hope it helps.

indraneel gravatar image indraneel  ( 2019-07-05 01:21:30 -0600 )edit

@indraneel, thanks that helps a lot, we understand what the problem is now! :)

RayROS gravatar image RayROS  ( 2019-07-05 11:12:50 -0600 )edit

Question Tools

Stats

Asked: 2018-03-15 20:27:30 -0600

Seen: 3,953 times

Last updated: Jul 05 '19