Revision history [back]

This may or may not solve @francesco's issue, but I figured I'd revisit with a potential solution since this question has been revisited by others. I hesitate to offer this solution because the issue being solved below is often accompanied by a number of other warnings from RViz or TF that the OP didn't mention. But perhaps this will help others with similar issues all the same:

I've had issues in the past with mismatches between the clocks that different nodes are using. In the question above, the tf publisher and rviz appear to be using wall time (e.g. Most recent transform:1620729066.500792\nOldest transform: 1620729061.50394\n) and the published point cloud appears to be using sim time (e.g.

header:
  stamp:
    sec: 357
    nanosec: 835000000

This can cause issues when Rviz is trying to find transformations between frames as it would need to extrapolate waaaayy into the past or future, and that's generally a bad idea.

You can verify whether your nodes are using sim_time or wall_time by querying their param server.

ros2 param get /node_name use_sim_time

use_sim_time is part of the base node class so all nodes will have it, but it won't be set automatically. With a Gazebo simulation, ideally all the relevant publishers and plugins (robot_state_publisher, joint_state_publisher, etc) will have use_sim_time set to True.