Robotics StackExchange | Archived questions

Interpreting tf_monitor output

I have been tracking a bug all over town but still havent caught it. The problem's symptom is that when displaying /scan in rviz, I get this error:

image description

I first suspected the /scan messages. Then I suspected the transforms between /scanlink and /basefootprint. Then I suspected the clocks being off. Then I recompiled everything. Then I started studying the firmware. One mystery is that when I display the TF tree it looks correct. So my latest wild goose is the odom transforms. There may be something "wrong" with them that is preventing them to be used in the display of the /scan.

Looking at this output, does it look right? Or are there two different nodes publishing the same tf (which I suppose "would be bad"). 

$ rosrun tf tf_monitor odom base_footprint

RESULTS: for odom to base_footprint
Chain is: odom -> base_footprint
Net delay     avg = 0.00902034: max = 0.0432399

Frames:
Frame: base_footprint published by unknown_publisher Average Delay: 0.00669084 Max Delay: 0.0213569

All Broadcasters:
Node: unknown_publisher 43.9137 Hz, Average Delay: 0.00669084 Max Delay: 0.0213569
Node: unknown_publisher(static) 141381 Hz, Average Delay: 0 Max Delay: 0

I cannot find what the two publishers are. I have tried it two ways: commenting out all publishstatictransform calls in all my launch files and instead providing a .urdf.

One other question is who is "unknown publisher"? Is there a way to figure that out? Also how can I learn more about why rviz says "unknown reason for transform failure?

Here are some more bits of evidence:

[real:platform3]~$ rostopic info /tf
Type: tf2_msgs/TFMessage

Publishers: 
 * /imu_filter_madgwick (http://100.88.71.18:41183/)
 * /ekf_localization (http://100.88.71.18:39013/)
 * /robot_state_publisher (http://100.88.71.18:36373/)

Subscribers: 
 * /ekf_localization (http://100.88.71.18:39013/)
 * /rqt_gui_py_node_15336 (http://100.68.133.19:34465/)
 * /rviz_1684504299516832149 (http://100.68.133.19:38219/)


[real:platform3]~$ rostopic info /tf_static
Type: tf2_msgs/TFMessage

Publishers: 
 * /robot_state_publisher (http://100.88.71.18:36373/)

Subscribers: 
 * /ekf_localization (http://100.88.71.18:39013/)
 * /rqt_gui_py_node_15336 (http://100.68.133.19:34465/)
 * /rviz_1684504299516832149 (http://100.68.133.19:38219/)


[real:platform3]~$

image description

image description

Asked by pitosalas on 2023-05-18 19:48:37 UTC

Comments

Quick comment: from the output it's clear there are two broadcasters for the transform you're monitoring. That could be OK, but in this case, it's a static and a dynamic transform. That seems strange. I'd check you don't have a static_transform_broadcaster node somewhere which is started from a .launch file or similar.

Asked by gvdhoorn on 2023-05-19 06:02:07 UTC

That's what I suspected. I just didn't know exactly how to read the output. I am digging into it now.

Asked by pitosalas on 2023-05-19 06:51:23 UTC

Well I can't find it. I am adding more detail to the original post to see if some more insights can come to you

Asked by pitosalas on 2023-05-19 08:55:12 UTC

I'd perhaps see what the output is of rostopic info /tf and rostopic info /tf_static. That should give you an indication of what nodes are publishing to those topics.

Note: I'm not claiming this will lead to a solution to your problem. I just pointed out that having both a static and dynamic transform for the same transform is unusual.

Asked by gvdhoorn on 2023-05-19 09:05:16 UTC

Agreed. I put them into the main body of the question. I am studying them right now to see what i learn.

Asked by pitosalas on 2023-05-19 09:08:35 UTC

Answers