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.

Scenarios:
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

Values:
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.

Regards,
	Tim

-- 
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
Currently at:
Carnegie Mellon University, Intel Research Pittsburgh, Personal Robotics