Interpreting tf_monitor output

asked 2023-05-18 19:48:37 -0500

pitosalas gravatar image

updated 2023-05-19 09:07:54 -0500

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 /scan_link and /base_footprint. 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 publish_static_transform 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

edit retag flag offensive close merge delete

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.

gvdhoorn gravatar image gvdhoorn  ( 2023-05-19 06:02:07 -0500 )edit

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

pitosalas gravatar image pitosalas  ( 2023-05-19 06:51:23 -0500 )edit

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

pitosalas gravatar image pitosalas  ( 2023-05-19 08:55:12 -0500 )edit

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.

gvdhoorn gravatar image gvdhoorn  ( 2023-05-19 09:05:16 -0500 )edit

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

pitosalas gravatar image pitosalas  ( 2023-05-19 09:08:35 -0500 )edit