ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A
Ask Your Question

Robot Localization Package: Transform was unavailable for the time requested. Using latest instead.

asked 2018-09-09 19:35:59 -0500

jpde.lopes gravatar image

updated 2018-09-10 02:47:21 -0500

Hello, I am using an ArduPilot board with an internal IMU connected to an external GPS+Compass module. I wanted to localize a frame base_link in relation to odom_combined. This base link is connected to other frames, so I have created a simple URDF file:

<link name="base_link">
    <origin xyz="0 0 0"/>
<link name="laser_base">
<joint name="laser_down" type="fixed">
    <origin xyz="0 0 1" rpy="0 0 1.57079632679"/>
    <parent link="base_link"/>
    <child link="laser_base"/>

So, I went outside and with the sensors, moved around making a rectangle (moving forwards + turn right + forwards ...). This the trajectory I did: Trajectory seen on a map.

If I plot the latitude and longitude from the NavsatFix data, I have the following:

GPS Data

(I recorded the data from two GPS modules, but the External Module is the one I am talking about).

Everything seems fine, but if I try to use the robot_localization_package with the navsat_transform_node to estimate IMU which will then be the input to the ekf_localization_node, it shows the error:

[ WARN] Transform from base_link to odom_combined was unavailable for the time requested. Using latest instead.

And the frame in RViz does not seems fine at all, with very aggressive discrete jumps. Based on another question I did, I set the predict_to_current_time parameter to true, but it did not solve the problem.

Also, the gps/filtered output (shown below) from navsat_transform_node is very different from the original gps data:


Yet, the gps output from navsat_transform_node that will be the input from ekf_localization_node is correct (makes a perfect rectangle). This means that the problem is related to the IMU, right?

I really do not know how I can solve this problem because, the information from the sensors seems correct. The IMU frequency is around 2Hz. I know that it is too low, but I can not figure why (the mavros launch is commented below).

Also, here is the result of $ rosrun tf view_frames:


Here is the bag recorded in the parking lot (containing the IMU and NavSat/fix data). Also, I have created a another bag which, not only contains the IMU+Navsat information, but also, the topics associated with the robot_localization_package, when running navsat_transform_node and ekf_localization_node.


<node pkg="robot_state_publisher" type="robot_state_publisher" name="robot_state_publisher" output="screen">
<node pkg="joint_state_publisher" type="joint_state_publisher" name="joint_state_publisher"/>
<param name="robot_description" textfile="$(find obstacle_detection)/description/tripod.urdf" />
<node name="modelvisualization" pkg="rviz" type="rviz" output="screen"/>

<!-- VR Brain Parameters -->
<!-- <arg name="fcu_url" default="/dev/ttyUSB0:57600" />
<arg name="gcs_url" default="" />
<arg name="tgt_system" default="1" />
<arg name="tgt_component" default="1" />
<arg name="log_output" default="screen" />
<arg name="fcu_protocol" default="v2.0" />
<arg name="respawn_mavros" default="false" />    -->

<!-- Launch VR Brain -->
<!-- <include file="$(find mavros)/launch/node.launch">
    <arg name="pluginlists_yaml" value="$(find obstacle_detection)/params/apm_pluginlists.yaml" /> -->
    <!-- <arg name="config_yaml" value="$(find obstacle_detection)/params/apm_config.yaml" /> -->

    <!-- <arg name="fcu_url" value="$(arg fcu_url)" />
    <arg name="gcs_url" value="$(arg gcs_url)" />
    <arg name="tgt_system" value="$(arg tgt_system)" />
    <arg name="tgt_component" value="$(arg tgt_component)" />
    <arg name="log_output" value="$(arg log_output)" />
    <arg name="fcu_protocol" value ...
edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2018-10-22 10:43:12 -0500

Tom Moore gravatar image

Thanks for including your full configuration and sample messages. That's very helpful. Also, apologies for the delay in responding.

Anyway, I note in your EKF configuration that you (obviously) are not using two_d_mode, but yet you don't have a measurement/reference for Z. You are measuring every other pose variable in 3D, but unless you have a reference for at _least_ Z velocity, I would expect your EKF state estimate to be unstable, due to the fact that (a) Z isn't measured, and (b) Z is correlated with other state variables in the kinematic model.

If you have an altitude sensor, add that input to the EKF. If you don't, maybe consider faking a fixed altitude estimate?

Also, my experience has been that the IMU/GPS combo alone doesn't perform especially well. If you have any kind of velocity reference (camera-based optical flow data, for example), that would be helpful.

edit flag offensive delete link more


Thank you very much for your reply. Instead of IMU and GPS, would adding an extra IMU help? Or is the optical flow preferable? Also, I am now using RTK, which I think will help with the xyz estimate.

jpde.lopes gravatar image jpde.lopes  ( 2018-10-22 11:10:40 -0500 )edit

I am currently not with the IMU and GPS setup to test, but on Wednesday, I will perform new tests having your answer in consideration and I will post the updates.

jpde.lopes gravatar image jpde.lopes  ( 2018-10-22 11:12:15 -0500 )edit

The reason why I have removed the Z measurement was because it was really unstable, going up and down, and I didnt know why. Even if I add the z measurement, the lack of z velocity would result in instabilities?, because I dont have that variable measured.

jpde.lopes gravatar image jpde.lopes  ( 2018-10-22 11:15:31 -0500 )edit

Every _pose_ variable (x, y, z, roll, pitch, and yaw) needs to either be measured directly, or as a velocity. If you have any pose variable that isn't, the filter won't behave.

If you want a smoother filter output, I'd recommend fusing in some optical flow 3D velocity data.

Tom Moore gravatar image Tom Moore  ( 2018-10-24 09:57:42 -0500 )edit

Hello,jpde.lopes,I encountered the same problem as you, did you solve it?

FeynH gravatar image FeynH  ( 2020-03-30 01:12:53 -0500 )edit

answered 2021-06-07 13:30:49 -0500

Debanik Roy gravatar image

in ekf_se_odom: transform_time_offset: 0.1 in ekf_se_map: transform_time_offset: 0.1

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2018-09-09 19:35:59 -0500

Seen: 1,787 times

Last updated: Jun 07 '21