RViz Pose Display does not move even though the published messages change
I am encountering the problem that the Pose Display occasionally freezes in RViz. More specifically, I have a node that publishes a sensor_msgs::PoseStamped
topic and I visualize this in Rviz. The pose display sometimes gets stuck after a while, i.e, it just does not move anymore, even though the published messages change (I monitor this using rostopic echo
). Strange enough, if I close and restart RViz (with the publishing node still running), the pose display works fine again until it gets stuck again eventually.
My setup is the following: The publishing node is on my desktop computer (Ubuntu on Virtualbox), which is also the ROS master. I run RViz on a laptop (Ubuntu on a VMware player), where the ROS_MASTER_URI
is set to the desktop computer's IP.
Does anybody have an idea, what could possibly go wrong here? Could it possibly be a timing issue? (Just a random guess).
Asked by takahashi on 2016-03-25 04:07:03 UTC
Answers
Given the rviz Pose display transforms pose data into the fixed frame (see here), there might be something going wrong there. Do you get a error message in the Display output on the left? There might be a timestamp problem that prevents conversion of the pose to the fixed frame.
Asked by Stefan Kohlbrecher on 2016-03-25 04:40:38 UTC
Comments
I get a warning in the Global Status No tf data. Actual error: Fixed Frame [odom] does not exist
. The Fixed Frame (in Global Options) is set to odom
and also the Pose message's frame_ids
are set to odom
. In the Display output, the Transform
is OK and the Topic
is continuously increasing.
Asked by takahashi on 2016-03-25 04:48:19 UTC
I think I found the problem (at least the problem hasn't occured again - yet). I am publishing the pose data at a high frequency of 50Hz and it seems that RViz somehow can't cope with that high publishing rate. Unfortunately, the problem was not reproducible - sometimes the pose visual got stuck sooner, sometimes later, and very rarely it didn't get stuck. I solved the problem by introducing an intermediate node, that receives the pose data at 50Hz and republishes it (under a different topic name) at a rate of 20Hz and now the pose display works like a charm.
I strongly believe that this is a timing issue, but unfortunately my understanding of how RViz internally works is too limited to deliver a tangible explanation.
Asked by takahashi on 2016-04-14 10:28:34 UTC
Comments
I've seen rviz handle multiple kHz of tf transforms, visualization markers, and even simple point clouds (when testing), so not being able to keep up with 50Hz sounds fishy to me. That was on a pretty decent desktop though, so YMMV. I could believe it is a race condition in rviz's code though.
Asked by William on 2016-04-15 21:36:23 UTC
Hmm, interesting. Did you run RViz on the same desktop computer? I am running my ROS master on a desktop (Ubuntu in a Virtualbox) and Rviz on a laptop (Ubuntu on a VMware player).
Asked by takahashi on 2016-04-17 10:30:13 UTC
Comments