TF being published at insane rate

[davidoort]

According to the TF tree below, the tf between fsds/FSCar and fsds/LidarCustom is being published at 10000Hz which is probably saturating a simulator CPU

[davidoort]

This observation does not match the output of rostopic hz /tf however

[SijmenHuizenga]

The 'Most recent transform' of fsds/FSCar to fsds/LidarCustom is 0.0. This implies the timestmap of the transform is not set correctly and thus causes the rate to max out.

[SijmenHuizenga]

sijmen@bloempje:~/Formula-Student-Driverless-Simulator$ rosrun tf tf_echo /fsds/FSCar /fsds/LidarCustom
At time 0.000
- Translation: [0.000, 0.000, -1.000]
- Rotation: in Quaternion [0.000, 0.000, 0.000, 1.000]
            in RPY (radian) [0.000, -0.000, 0.000]
            in RPY (degree) [0.000, -0.000, 0.000]
At time 0.000
- Translation: [0.000, 0.000, -1.000]
- Rotation: in Quaternion [0.000, 0.000, 0.000, 1.000]
            in RPY (radian) [0.000, -0.000, 0.000]
            in RPY (degree) [0.000, -0.000, 0.000]

[SijmenHuizenga]

sijmen@bloempje:~/Formula-Student-Driverless-Simulator$ rosrun tf tf_monitor

RESULTS: for all Frames

Frames:
Frame: /fsds/cam1 published by unknown_publisher Average Delay: -0.99983 Max Delay: 0
Frame: /fsds/cam2 published by unknown_publisher Average Delay: -0.999786 Max Delay: 0
Frame: fsds/FSCar/enu published by unknown_publisher Average Delay: -0.0998375 Max Delay: 0
Frame: fsds/LidarCustom published by unknown_publisher(static) Average Delay: 0 Max Delay: 0

All Broadcasters:
Node: unknown_publisher 12.18 Hz, Average Delay: -0.251945 Max Delay: 0
Node: unknown_publisher(static) 1e+08 Hz, Average Delay: 0 Max Delay: 0

That 1e+08 Hz looks weird.

[SijmenHuizenga]

Running rostopic hz /tf and rostopic hz /tf_static show that there are just around 20 messages a second being sent. This confirms my suspicion that it has something to do with the way we use transforms. Like all analyzing tools are complaining about the timestamps, so something is wrong.

I have started reading about static transforms. There is actually real difference between static and non-static transforms. Static transforms are supposed to be latched on the /tf_static topic. Source

The lidar transform was sent using the StaticTransformBroadcaster. That class latches the messages. We were sending messages every second, which is just not the way to do it. So in 141dd0cc657993d6eaa35a00ada1cffa068c800d i changed the wrapper to publish the lidar transform once.

When using view_frame.py in the tf2_tools (tf is deprecated in favor of tf2.) it still shows the following tree:

I think this is some improvement in the long way towards correct tf's but this does not solve the problem of the huge frequency reported by the analytics tools.

[SijmenHuizenga]

With above research we can conclude that the transform is working, although probably not it is not perfect. There are no functional or performance impacts, so this has a low priority to fix.

[davidoort]

I've realized that this is just an artifact of tf2_ros static transforms which publishes the transform once and latches the message. Since the message is available at all times, the rate is technically infinitely high, but this doesn't cause performance issues