Visualize pointcloud2 on rviz2
I am trying to visualize a pointcloud published from the gazebo depth camera plugin, but rviz complains with the following:
[INFO] [1620727112.970424552] [rviz]: Message Filter dropping message: frame 'camera_link' at time 619.835 for reason 'Unknown'
The message (published on /camera/points) is:
header:
stamp:
sec: 357
nanosec: 835000000
frame_id: camera_link
height: 1
width: 76800
fields: '<sequence type: sensor_msgs/msg/PointField, length: 4>'
is_bigendian: false
point_step: 32
row_step: 2457600
data: '<sequence type: uint8, length: 2457600>'
is_dense: true
camera_link exists in tf, and I tried all different kind of QoS setting in the rviz PointCloud2 plugin.
EDIT: If I set the global frame in rviz to cameralink, the pointcloud is visualized, but not using any other frame, even though the tf tree is correct. Output of tf viewframes is:
digraph G { "link6" -> "cameralink"[label=" Broadcaster: defaultauthority\nAverage rate: 10000.0\nBuffer length: 0.0\nMost recent transform: 0.0\nOldest transform: 0.0\n"]; "link5" -> "link6"[label=" Broadcaster: defaultauthority\nAverage rate: 20.013\nBuffer length: 4.997\nMost recent transform: 1620729066.500792\nOldest transform: 1620729061.50394\n"]; "world" -> "baselink"[label=" Broadcaster: defaultauthority\nAverage rate: 10000.0\nBuffer length: 0.0\nMost recent transform: 0.0\nOldest transform: 0.0\n"]; "link6" -> "lasermountlink"[label=" Broadcaster: defaultauthority\nAverage rate: 10000.0\nBuffer length: 0.0\nMost recent transform: 0.0\nOldest transform: 0.0\n"]; "baselink" -> "base0"[label=" Broadcaster: defaultauthority\nAverage rate: 10000.0\nBuffer length: 0.0\nMost recent transform: 0.0\nOldest transform: 0.0\n"]; "base0" -> "link1"[label=" Broadcaster: defaultauthority\nAverage rate: 20.013\nBuffer length: 4.997\nMost recent transform: 1620729066.500792\nOldest transform: 1620729061.50394\n"]; "link1" -> "link2"[label=" Broadcaster: defaultauthority\nAverage rate: 20.013\nBuffer length: 4.997\nMost recent transform: 1620729066.500792\nOldest transform: 1620729061.50394\n"]; "link2" -> "link3"[label=" Broadcaster: defaultauthority\nAverage rate: 20.013\nBuffer length: 4.997\nMost recent transform: 1620729066.500792\nOldest transform: 1620729061.50394\n"]; "link3" -> "link4"[label=" Broadcaster: defaultauthority\nAverage rate: 20.013\nBuffer length: 4.997\nMost recent transform: 1620729066.500792\nOldest transform: 1620729061.50394\n"]; "link4" -> "link5"[label=" Broadcaster: defaultauthority\nAverage rate: 20.013\nBuffer length: 4.997\nMost recent transform: 1620729066.500792\nOldest transform: 1620729061.50394\n"]; edge [style=invis]; subgraph clusterlegend { style=bold; color=black; label ="view_frames Result"; "Recorded at time: 1620729066.5162456"[ shape=plaintext ] ; }->"world";
I am using ros2 foxy on ubuntu 20.04 and rviz2. Details on version:
librviz-dev/focal 1.13.7+dfsg-1build2 amd64
librviz4d/focal 1.13.7+dfsg-1build2 amd64
python3-rviz/focal 1.13.7+dfsg-1build2 amd64
ros-foxy-nav2-rviz-plugins-dbgsym/focal 0.4.7-1focal.20210423.031243 amd64
ros-foxy-nav2-rviz-plugins/focal 0.4.7-1focal.20210423.031243 amd64
ros-foxy-rviz-assimp-vendor/focal,now 8.2.1-1focal.20210422.235601 amd64 [installed,automatic]
ros-foxy-rviz-common-dbgsym/focal 8.2.1-1focal.20210423.021136 amd64
ros-foxy-rviz-common/focal,now 8.2.1-1focal.20210423.021136 amd64 [installed,automatic]
ros-foxy-rviz-default-plugins-dbgsym/focal 8.2.1-1focal.20210423.023030 amd64
ros-foxy-rviz-default-plugins/focal,now 8.2.1-1focal.20210423.023030 amd64 [installed,automatic]
ros-foxy-rviz-ogre-vendor-dbgsym/focal 8.2.1-1focal.20210422.235609 amd64
ros-foxy-rviz-ogre-vendor/focal,now 8.2.1-1focal.20210422.235609 amd64 [installed,automatic]
ros-foxy-rviz-rendering-dbgsym/focal 8.2.1-1focal.20210423.002207 amd64
ros-foxy-rviz-rendering-tests/focal 8.2.1-1focal.20210423.002810 amd64
ros-foxy-rviz-rendering/focal,now 8.2.1-1focal.20210423.002207 amd64 [installed,automatic]
ros-foxy-rviz-visual-testing-framework/focal 8.2.1-1focal.20210423.022658 amd64
ros-foxy-rviz2-dbgsym/focal 8.2.1-1focal.20210423.031240 amd64
ros-foxy-rviz2/focal,now 8.2.1-1focal.20210423.031240 amd64 [installed,automatic]
ros-rolling-rviz-assimp-vendor/focal 8.5.0-1focal.20210406.185318 amd64
ros-rolling-rviz-common-dbgsym/focal 8.5.0-1focal.20210413.164113 amd64
ros-rolling-rviz-common/focal 8.5.0-1focal.20210413.164113 amd64
ros-rolling-rviz-default-plugins-dbgsym/focal 8.5.0-1focal.20210413.170343 amd64
ros-rolling-rviz-default-plugins/focal 8.5.0-1focal.20210413.170343 amd64
ros-rolling-rviz-ogre-vendor-dbgsym/focal 8.5.0-1focal.20210406.185328 amd64
ros-rolling-rviz-ogre-vendor/focal 8.5.0-1focal.20210406.185328 amd64
ros-rolling-rviz-rendering-dbgsym/focal 8.5.0-1focal.20210406.193056 amd64
ros-rolling-rviz-rendering-tests/focal 8.5.0-1focal.20210406.193732 amd64
ros-rolling-rviz-rendering/focal 8.5.0-1focal.20210406.193056 amd64
ros-rolling-rviz-visual-testing-framework/focal 8.5.0-1focal.20210413.165853 amd64
ros-rolling-rviz2-dbgsym/focal 8.5.0-1focal.20210413.180346 amd64
ros-rolling-rviz2/focal 8.5.0-1focal.20210413.180346 amd64
rviz/focal 1.13.7+dfsg-1build2 amd64
Asked by francesco on 2021-05-11 05:07:27 UTC
Answers
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
.
Asked by shonigmann on 2022-03-02 12:26:58 UTC
Comments
After 2-3 days of struggle, this post solved my issue. Thanks.
Asked by elanius on 2022-12-06 04:45:56 UTC
Comments
In rviz, if you add a TF display and look in the Status are there any warnings or errors for the relevant transformations?
Asked by shonigmann on 2021-05-11 13:12:48 UTC
No, all fine. From both the tf plugin on rviz and the view_frame tool the tf tree seems well connected all the way from world frame to camera_link through the robot arm (doosan-robot2 m0609). I tried to increase the publish frequency of the robot_state_publisher from 20 to 100hz, in case of a problem of timings in the tf lookup, but no difference.
Asked by francesco on 2021-05-11 17:27:10 UTC
Have you verified that your QoS settings (e.g. the Reliability Policy) in RVIZ match your publisher's settings?
Asked by shonigmann on 2021-05-11 17:31:14 UTC
I tried all the possible reliability policy options. It doesn't make a difference. the message gets discarded unless i set the global frame to camera_link.
Asked by francesco on 2021-05-11 17:37:38 UTC
Hi there, having the same issue here. Did you find a solution ?
Asked by BlaiseLebreton on 2022-03-02 03:09:36 UTC
What does
ros2 doctor
output?Asked by Serafadam on 2022-03-02 19:15:56 UTC