Troubleshooting ROS RGB Image Delay on Remote RViz

On the ROSbot 2.0 setup, RViz on a remote Linux desktop displays camera images with significant delay because the robot sends the image topic as uncompressed data over the network. The reported frame size is approximately 10 MB, so network throughput can dominate the display path; republishing through compressed image transport reduces the image data sent to the remote computer.

Check where the image delay enters the path

Trace the image from the Astra depth camera on the ROSbot to the local RViz display. The reported arrangement runs the camera drivers on the robot, uses the robot as the ROS master, and runs RViz on a Linux desktop connected remotely. SSH provides a way to access the robot, but it does not by itself establish that the image transfer has enough bandwidth.

1. Check 1 — Compare local and remote display. View the camera topic on the robot, then compare it with RViz on the desktop. If the local view is responsive and the remote view is delayed, focus first on the network transfer and remote display path. If both views are delayed, investigate camera publishing and local processing before changing the remote transport.
2. Check 2 — Identify the exact topic. Inspect the topic RViz subscribes to. The reported symptom names /camera/rgb/image_rect_color, while the supplied compression launch example takes /camera/rgb/image_raw as input. These are distinct topic names: determine which stream RViz actually needs, and do not substitute raw for rectified imagery without checking that it meets the application requirement.
3. Check 3 — Confirm image transport. Determine whether the selected stream is being transmitted uncompressed or through a compressed transport. The reported image topic used uncompressed transfer. If the delayed stream is still uncompressed across the network, proceed to compressed republishing; if it is already compressed, continue by checking the received stream and display path.

In ROS image transport, a publisher can offer an image in a transport format such as compressed, and a subscriber can consume that transport and expose a local image topic. This keeps the network transfer separate from the image topic RViz displays. The receiving computer can decompress locally, so RViz does not need to receive the large uncompressed frame over the remote link.

Relate frame size to network demand

A frame of approximately 10 MB represents a substantial data transfer when repeated for every camera update. For an estimated frame rate f frames per second, the uncompressed payload rate is approximately 10 MB × f per second, or 80 × f Mbit/s if MB is treated as decimal megabytes. This is a payload estimate, not a measured network rate; it excludes protocol overhead and does not account for pauses, contention, or other traffic.

Use this calculation to test whether the uncompressed stream can plausibly fit the measured link capacity. Read the actual frame rate and measure network throughput rather than assigning a frame rate from assumption. If the required payload rate approaches or exceeds available throughput, queueing and delayed display are expected. Compressing before network transfer is the relevant correction for that branch.

Choose the correct RGB input stream

The example below compresses /camera/rgb/image_raw. The reported slow topic is /camera/rgb/image_rect_color. Before copying the launch configuration, decide whether the display requires the raw camera image or the rectified color image. A rectified stream and a raw stream are not interchangeable merely because both contain RGB imagery.

Use the supplied raw input if that is the required view. If RViz must display the rectified stream, configure the republisher to consume the actual rectified topic and verify the resulting compressed and reconstructed topic names. Preserve the camera-processing path required for the intended view; do not route RViz to a different image variant only to reduce delay.

The depth example is separate from the RGB example. It uses the compressedDepth transport and sets PNG compression level to 1. Keep the RGB and depth transports matched to their corresponding data; do not apply the RGB transport selection to the depth image.

Run the compressed republishers on the ROSbot

Add the following nodes to rosbot_drivers.launch on the ROSbot. The RGB node subscribes to the raw RGB image and republishes it using compressed image transport. The depth node republishes depth using compressed-depth transport with PNG format.

<node pkg="image_transport" type="republish" name="rgb_compress" args="raw in:=/camera/rgb/image_raw compressed out:=/rgb_republish" />
<node pkg="image_transport" type="republish" name="depth_republish" args="raw in:=/camera/depth/image_raw compressedDepth out:=/depth_republish">
  <param name="compressedDepth/format" value="png"/>
  <param name="compressedDepth/png_level" value="1"/>
</node>

Launch the robot drivers with these republishers active. For rectified RGB, change the RGB republisher input to the exact rectified topic selected in the previous step, then verify that the remote subscriber receives the matching compressed stream. Do not change the output name without updating the corresponding local input.

Decompress on the desktop and direct RViz

Run the receiving launch file on the local desktop. It subscribes to the compressed RGB and depth transports, republishes locally as raw topics, and starts RViz.

<launch>
  <node name="rviz" pkg="rviz" type="rviz"/>
  <node pkg="image_transport" type="republish" name="rgb_decompress" args="compressed in:=/rgb_republish raw out:=/rgb_raw">
    <param name="compressed/mode" value="color"/>
  </node>
  <node pkg="image_transport" type="republish" name="depth_decompress" args="compressedDepth in:=/depth_republish raw out:=/depth_raw">
    <param name="compressed/mode" value="unchanged"/>
  </node>
</launch>

In RViz, add the image display and select /rgb_raw for RGB or /depth_raw for depth. These are the local reconstructed topics from the example. If the RGB republisher was changed to consume the rectified stream, confirm that /rgb_raw now represents that selected stream rather than the original raw camera input.

Verify transport, content, and display delay

1. Check 4 — Confirm robot-side compressed output. Inspect the active topics and verify the RGB and depth republishers are publishing their configured outputs. Expected: the corresponding compressed transports are available at the output names used in both launch files.
2. Check 5 — Confirm desktop reconstruction. Inspect the local /rgb_raw or /depth_raw topic and select it in RViz. Expected: the image display updates with the intended camera content, rather than an empty display or an unintended stream.
3. Check 6 — Compare latency and data path. Compare the remote RViz display before and after compressed republishing, while confirming that the local robot image remains responsive. Expected: the remote display delay is reduced when uncompressed network bandwidth was the bottleneck. If delay remains, measure the actual network throughput and image publication rate, then check that RViz subscribes to the reconstructed local topic and that the desktop is receiving the intended compressed stream.

Frequently asked questions