[ros-users] Best way to view RViz remotely?
niemueller at kbsg.rwth-aachen.de
Sat Nov 6 18:53:23 UTC 2010
On 06.11.2010 11:12, Patrick Goebel wrote:
> Is there a better way to view the robot data in RViz?
We had the very same problem and explored several possibilities. We have
two graphical applications which have a graphical display we want to
access from a desktop machine at run-time: rviz (visualization) and
OpenRAVE (manipulation monitoring and possibly interaction).
Here are some numbers from our throughput tests on our robot HERB,
running OpenRAVE and rviz using different transmission methods. Note
that the number also include a remotely running SSH connection to gather
the data at about 40kbit/sec and 30packets/sec which is basically a
constant to subtract.
1. Run OpenRAVE on herb3, display output via VNC
2. Run OpenRAVE on herb3, display output via remote X
3. Run OpenRAVE on pr-sift2, get data via ROS
4. Run rviz on pr-sift2, get data via ROS
5. Rnu rviz on herb3, display output via VNC
1. ~500 kbit/sec at ~200 packets/sec
2. ~1500 to ~4000 kbit/sec at ~1200 packets/sec
(depends on screen content)
3. ~7000 kbit/sec at ~2600 packets/sec, spikes at 3000 packets/sec
4. ~9000 kbit/sec at ~2500 packets/sec
5. the same as 1.
With only headless processes running: ~150 kbit/sec at ~90 packets/sec.
Usability is about inversely proportional to bandwidth. For display only
rviz VNC is fine and seems fast enough. For OpenRAVE it wasn't very
usable, but already with remote X we get a large number of packets that
might cause problems. Additionally, this option has the highest
potential for failure, because if the network connection is down, the
manipulation applet ceases working. So it does for option 3, but it is
likely (though untested) that re-establishing ROS connections is faster
than recovering the remote X connection.
So as soon as you have to transmit lots of data, the remote ROS
connections are unfeasible. In our case we transmitted 3D laser data,
and the highest traffic topic were the transforms (/tf).
On wifi you have to take into account that small packets harm your
bandwidth badly, because they always will a full transmission window,
wasting bandwidth. So the tf situation could be improved by aggregating
data and sending it in one (or at least fewer) messages. But that may
come at a cost in latency, so again a tradeoff to make. An idea we had
but did not try: a compressing tunnel, for example with SSH or OpenVPN,
possibly unencrypted and only compressed.
We went with VNC in the end, because network performance was crucial and
there were other robots and people using the network at the same time,
and usability is sufficient. You should try out different VNC servers,
we have experienced very varyin results. We ended up using good ol'
x11vnc, which provides acceptable 3D display performance.
AllemaniACs RoboCup Team KBSG - Knowledge-Based Systems Group
http://robocup.rwth-aachen.de RWTH Aachen University
http://www.kbsg.rwth-aachen.de Ahornstrasse 55
http://www.fawkesrobotics.org D-52056 Aachen
Carnegie Mellon University, Intel Research Pittsburgh, Personal Robotics
More information about the ros-users