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

Robot Localization Package: Transform from base_link to odom was unavailable for the time requested. Using latest instead. (IMU+GPS)

asked 2018-08-11 19:41:23 -0600

jpde.lopes gravatar image

updated 2018-09-05 20:19:15 -0600

Hello, I want to record data from a tripod, so I started by creating a urdf file, where I say that laser_base is 1m above of base_link, like this:

<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"/>

After this, I want to move the tripod around, so I need to keep track of its XYZ position, as well as orientation, so that the data I record is properly located. For that, I am using an ArduPilot board for retrieving IMU and GPS information, which I am fusing with the robot_localization_package (Wiki) (ekf and navsat_transform_node).

The launch file for this is as follows:


<node pkg="robot_state_publisher" type="robot_state_publisher" name="robot_state_publisher" output="screen">
<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/apm2.launch">

    <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="$(arg fcu_protocol)" />
    <arg name="respawn_mavros" default="$(arg respawn_mavros)" />

<!-- EKF -->
<node pkg="robot_localization" type="ekf_localization_node" name="ekf_localization_local" clear_params="true">
    <param name="frequency" value="30 "/>
    <param name="sensor_timeout" value="2"/>

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

    <param name="map_frame" value="map"/>
    <param name="odom_frame" value="odom_combined"/>
    <param name="base_link_frame" value="base_link"/>
    <param name="world_frame" value="odom_combined"/>

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

    <param name="odom0" value="/odometry/gps"/>
    <param name="imu0" value="/mavros/imu/data"/>

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

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

    <param name="odom0_differential" value="false"/> 
    <param name="imu0_differential" value="false"/>
    <param name="odom0_relative" value="false"/>
    <param name="imu0_relative" value="false"/>
    <param name="imu0_remove_gravitational_acceleration" value="true"/>
    <param name="print_diagnostics" value="true"/>

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

<node pkg="robot_localization" type="navsat_transform_node" name="navsat_transform_node" respawn="true" output="screen">
    <param name="frequency" value="10"/>
    <param name="magnetic_declination_radians" value="0"/>
    <param name="yaw_offset" value="0"/>
    <param name="zero_altitude" value="false"/>
    <param name="broadcast_utm_transform" value="false"/>
    <param name="publish_filtered_gps" value="false"/>
    <param name="use_odometry_yaw" value="false"/>
    <param name="wait_for_datum" value="false"/>

    <remap from="/gps/fix" to="/mavros/global_position/raw/fix"/>
    <remap from="/imu/data" to="/mavros/imu/data"/>

So, I walked around with the ArduPilot board and recorded a bag file with the IMU and GPS topics (/mavros/imu/data and /mavros/global_position/raw/fix). I have also created another bag file where I ... (more)

edit retag flag offensive close merge delete



Tom would be the authoritative input on this, but in the meantime - for your 1st problem, what frequency are you expecting? GPS usually outputs at 1Hz so no discrepancy there; IMUs generally report many times a second... but again, what are your expectations? Did you run hz on the original topics?

autonomy gravatar image autonomy  ( 2018-08-13 13:07:14 -0600 )edit

For 2, did you try running view_frames to see how old your static transform is? ( ) From the source code: // The issue might be that the transforms that are available are not close // enough temporally to be used.

autonomy gravatar image autonomy  ( 2018-08-13 13:10:37 -0600 )edit

Thank you for your answer @autonomy. Yes, I tried to run hz on the original topics. Both the IMU and GPS are around 2Hz. I noticed some discrete jumps in RViz. Also, on almost every example of navsat transform node implementation I've seen 30Hz being used.

jpde.lopes gravatar image jpde.lopes  ( 2018-08-13 13:24:58 -0600 )edit

On my case, I've used 10Hz, but if I reduce it to 3Hz, for example, I see much less of those TF warnings.

jpde.lopes gravatar image jpde.lopes  ( 2018-08-13 13:25:58 -0600 )edit

I'll check that (view_frames) and will give feedback.

jpde.lopes gravatar image jpde.lopes  ( 2018-08-13 13:28:25 -0600 )edit

Everything seems fine with the frames. Sometimes I notice that the frequency drops from approximately 2Hz to 0.002Hz or something like that. It is momentaneous, but it may be enough to cause that warning, right?

jpde.lopes gravatar image jpde.lopes  ( 2018-08-13 15:54:28 -0600 )edit

2Hz seems low for an IMU. I worked with IMUs running anywhere between 30 to 100Hz. You are requesting robot_localization to run at 30Hz but your sensor readings, which are driving it, are only publishing at 2Hz. Increase IMU rate or try running everything at 2Hz and see if the warning goes away

autonomy gravatar image autonomy  ( 2018-08-13 16:17:30 -0600 )edit

Take a look here, maybe that can help increase the sensor frequency. Also, take care to set your magnetic_declination_radians correctly unless it really is 0

autonomy gravatar image autonomy  ( 2018-08-13 16:25:57 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2018-08-27 04:44:34 -0600

Tom Moore gravatar image

updated 2018-10-24 10:04:47 -0600

Please update the question by posting a sample message from each sensor input.

So, I have two problems: 1ST: When I do rostopic hz with the 2 topics above, it shows a rate of approximately 1Hz. That is very slow, isn't it?

For a GPS, that makes sense. For an IMU, that doesn't seem right.

2ND: When I use the launch file above, it starts by showing:

If you are getting transform warnings, it means that the transforms coming out of the EKF are older than the timestamps on the input messages going into navsat_transform_node. This is because the EKF only predicts up to the point of its most recent input message. Since the IMU and GPS data probably (?) have the same time stamps, navsat_transform_node receives a GPS message at the same time that the EKF receives its latest IMU data. That means the EKF will have to compute and publish the transform before navsat_transform_node can use it, but navsat_transform_node needs that transform at the time it receives the GPS message (which is at the time the EKF just receives the IMU message, so it won't be available).

You have two options:

  1. Change your transform_time_offset EKF parameter to some small positive value. This will future-date its transform it's generating.
  2. Set predict_to_current_time to true for the EKF. That will force the EKF to make a prediction to the current ROS time before publishing, rather than just publishing the state estimate at the time of the most recent measurement.
edit flag offensive delete link more


Thank you for your answer. I have updated my question with a sample of the sensors.

jpde.lopes gravatar image jpde.lopes  ( 2018-09-05 20:24:34 -0600 )edit

I have created another question w/ more significant data.

jpde.lopes gravatar image jpde.lopes  ( 2018-09-09 19:38:55 -0600 )edit

predict_to_current_time is not documented in the wiki.

andrestoga gravatar image andrestoga  ( 2019-08-04 20:54:00 -0600 )edit

@andrestoga If you have time, then I'd welcome a PR to fix that. :)

Tom Moore gravatar image Tom Moore  ( 2019-08-22 06:20:03 -0600 )edit

Question Tools



Asked: 2018-08-11 19:41:23 -0600

Seen: 5,950 times

Last updated: Oct 24 '18