# robot_localization failed to transform warning

I am incorporating gps into robot_localization by running two robot_localization nodes, the first one for continuous data and a second one that takes odom outputs of the first node as well as gps data. The output from the gps robot_localization seems to be working (although the pose jumps around a lot, I suppose that is gps noise, don't know) but I am getting warnings that occur about every couple seconds. They do not happen with every gps update:

[ WARN] [1439616317.672653784]: WARNING: failed to transform from ->base_footprint for odom0 message received at 1439616317.433094978. The message frame_id is empty.

[ WARN] [1439616320.672574210]: WARNING: failed to transform from ->base_footprint for odom0 message received at 1439616320.448824882. The message frame_id is empty.

[ WARN] [1439616322.672615913]: WARNING: failed to transform from ->base_footprint for odom0 message received at 1439616322.471970081. The message frame_id is empty.


In this case, odom0 corresponds to the gps input (as sent from navsat_transform via the topic /odom_navsat). odom1 is the odom from the first robot_localization node (sent via the topic /odom_ukf). The world frame for the gps robot_locaization is set to the map frame; this should be fine, since the first robot_localization broadcasts the transform from odom->base_footprint. As far as I can tell, the transform tree is good and all the transforms are getting broadcast correctly, including the one from gps -> odom that is being done by the gps robot_localization.

Here is a link to a bag file as well as both of the robot_localization launch files and also the navsat_transform launch file and the transform tree: data_folder

edit retag close merge delete

I'll look into this tonight. Just looking at the error makes me wonder if you turned on differential mode for odom0. Did you?

( 2015-08-17 08:26:36 -0600 )edit

No, odom0 (the gps feed) has both differential and relative = false

( 2015-08-18 11:49:14 -0600 )edit

I am also sometimes seeing vy run away to large values after a while. There are no vy inputs coming into the filter, so I don't know where it is coming from. The odom1 input (from the first robot_localization) has differential set to true. Bag file with "large_vy_component" is in the same folder.

( 2015-08-19 14:46:28 -0600 )edit

Sort by » oldest newest most voted

I pulled down your launch and bag file while I had DropBox access the other day, and am just now looking at them. Here are the problems I see. Note that I don't think I have your latest launch file, as the topic names appear to be very different.

1. Here is a sample IMU message from the bag file:

header:
seq: 756
stamp:
secs: 1439616291
nsecs: 130379310
orientation:
x: 1.0
y: 0.0
z: 0.0
w: 0.0
orientation_covariance: [0.01, 0.0, 0.0, 0.0, 0.01, 0.0, 0.0, 0.0, 100.0]
angular_velocity:
x: 0.0
y: 0.0
z: -0.05
angular_velocity_covariance: [1e-06, 0.0, 0.0, 0.0, 1e-06, 0.0, 0.0, 0.0, 1e-06]
linear_acceleration:
x: 0.0
y: 0.0
z: 0.0
linear_acceleration_covariance: [0.02, 0.0, 0.0, 0.0, 0.02, 0.0, 0.0, 0.0, 0.02]


First, the orientation appears to be the identity quaternion, but the identity quaternion should have x = 0.0 and w = 1.0. Second, if your IMU doesn't report orientation, navsat_transform_node will not function. See "Required Inputs" here. You'll need an earth-referenced heading, e.g., from a compass.

2. The launch file I'm looking at doesn't appear to show anything to do with the navsat_transform_node, but just looking at the error message above, I think you must have your GPS odometry configuration something like this:

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


First, make sure that your odom0 setting really is for the GPS odometry. Next, note that the GPS odometry data only has pose information (X, Y, and optionally Z) in it. The configuration settings above are incorrect, because they have X velocity set to true. In your case, the reason I think you have something akin to the configuration above is that the transform failure was from an empty frame_id to base_footprint. The only time the filter attempts to transform into the body frame is when it's attempting to fuse a velocity. Your GPS odometry message has a blank child_frame_id (for the velocity component of the message), and the filter is trying to transform it into the body frame.

In any case, you should first fix your IMU message, and we'll go from there.

EDIT in response to the comments below

We'll pretend for a moment that you have a compass in your IMU so that I can address your question.

The use_odometry_yaw parameter, when set to true, renders the IMU input to navsat_transform_node unnecessary, yes. However, if you were to turn on differential mode or relative mode for your yaw sensor within ekf_localization_node, then you wouldn't be able to use the use_odometry_yaw setting, and you'd have to use your IMU directly with navsat_transform_node. This is because the yaw that you feed to navsat_transform_node must be earth-referenced. In other words, if you ...

more

oops! I swapped the ROS quat calculations for my own and forgot one was (w,x,y,z) and the other (x,y,z,w). Fixed. For navsat, I thought any one of the 3 sources listed under 1.(default) was sufficient, I will now supply all 3. I had GPS odom set to true for X, Y, and vx. I will set vx false.

( 2015-08-19 17:03:13 -0600 )edit

launch and bag files updated--same folder. The warnings are gone (now that vx = false), but gps jumping remains. The position jumping may be just gps noise, but I'd like to fix the yaw jumping. I set "use_odometry_yaw" = true for navsat since the filtered yaw should be better than raw IMU yaw.

( 2015-08-19 17:52:26 -0600 )edit

(cont) because the IMU only measures angular velocity, IMU yaw is derived from that. The yaw from robot_localization should be better as we add multiple sensors to the filter. Similarly, why would I supply yaw from both robot_localization and IMU to navsat when they both come from the same data?

( 2015-08-19 23:24:21 -0600 )edit

I do have a compass on the IMU, but it is so easily led astray (local metal, motors starting) that I am reluctant to use it for absolute orientation. My thought was to get absolute orientation by tracking movement in GPS, as seems standard in phones and GPS devices.

( 2015-08-20 16:32:06 -0600 )edit

But that heading is only obtained through differentiation of GPS positions, so you'll have to have a separate node that is listening to the GPS and computing an absolute heading, then feeding that heading to navsat_transform_node as an absolute heading reference (in an IMU message).

( 2015-08-21 14:54:49 -0600 )edit

I am OK with writing a node that differentiates the GPS position to compute an absolute position if that is the best way to go. Did you get a chance to look at the bag files to see what is going on with the yaw jumping all around in odom_gps? Again, appreciate the help.

( 2015-08-22 14:21:31 -0600 )edit

comm check on yaw jumping with GPS.

( 2015-08-30 01:34:02 -0600 )edit

Your DropBox link is giving me 500 Internal Server errors at the moment.

( 2015-08-30 10:29:33 -0600 )edit