Can't read "/tf" when used ROS 1 connection

Description When I used the ROS1 connection, the 3D panel can’t display anything. And the “Topics” list is normal, but the “TF” list is empty. And I found the “Connection” panel shows this information:

Error: Subscribing to /tf_static at http://LAPTOP-188K0BM3:43911/ failed (Error: requestTopic(“/tf_static”) from http://LAPTOP-188K0BM3:43911/ failed. err=TypeError: Failed to fetch), this connection will be dropped at x._subscribeToPublisher (file:///C:/Users/14535/AppData/Local/Programs/foxglove-studio/resources/app.asar/renderer/main.js:5:77173) at async file:///C:/Users/14535/AppData/Local/Programs/foxglove-studio/resources/app.asar/renderer/main.js:5:76335

• Version: 0.20.1
• OS: Windows 10

Steps To Reproduce

Expected Behavior

Actual Behavior

[defunctzombie]

We definitely rely on the “non-compliant” behavior of ros_comm for the publisher to send the message_definition. Without the message definition, we have no way to know how to deserialize the message. But I don’t think thats the problem described above.

The error above I am almost certain relates to misconfigured ROS_HOSTNAME between the computer running studio and the computer running ROS. The error message is somewhat misleading (or lacking full information) but likely the hostname of AGV_MCU is not resolvable from the computer running studio.

@jhurliman Ideas on what we can do to attempt detecting this and maybe presenting error text or message that is more obvious? Maybe one that links to our connection docs (https://foxglove.dev/docs/connection/native) or the ROS Network setup docs (http://wiki.ros.org/ROS/NetworkSetup) /cc @esthersweon

[defunctzombie]

My hypothesis is that the original error is due to hostname resolution when using ROS and studio across machines. There’s some useful info on the ROS network wiki page (http://wiki.ros.org/ROS/NetworkSetup). And I believe we’ve recently made some enhancements to the error messages when these name resolution issues happen (https://github.com/foxglove/studio/pull/2224) (will be in the next release).

Closing this. @iceuw if you believe the above comments are incorrect or need further help debugging feel free to re-open with more notes on steps to reproduce or hop in our slack and we can try debugging realtime.