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

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

64 ●12 ●14 ●18

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>
<link name="laser_base">
</link>
<joint name="laser_down" type="fixed">
    <origin xyz="0 0 1" rpy="0 0 1.57079632679"/>
    <parent link="base_link"/>
    <child link="laser_base"/>
</joint>

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:

gps/filtered

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:

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.

<launch>     

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

(more)

edit retag flag offensive close merge delete

add a comment

2

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

Tom Moore

flag of United Kingdom of Great Britain and Northern Ireland

13689 ●74 ●240 ●232 http://github.com/ayrton04

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

Comments

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 ( 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 ( 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 ( 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.