Robotics StackExchange | Archived questions

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

Comments

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