Handling large images in ROS2 via WiFi

[Sergei Grichine]

Hi All,

I want to revisit the issue discussed yesterday in the ROS focus group meeting.

It has been a major pain in the neck for me, resulting in expensive upgrades to my home and outdoor Wi-Fi, the addition of travel routers on my robots, and numerous configuration attempts. Some of these efforts are reflected in this guide.

At the moment, I am trying to tame RTAB-Map (Visual SLAM) on my outdoor robot, Dragger, which is putting everything to the test. Specifically, passing RGB, depth, and SLAM data around has proven difficult.

Dragger can be run in two configurations:

1. A single RPi5 running both the OAK-D Lite and the RTAB-Map node.
2. A primary RPi5 handling the robot and RTAB-Map node, while pulling visual data from a secondary RPi5 running the stereo node.

In both setups, RViz and the joystick node run on a separate Intel PC.

Hardware-wise, Dragger uses a 1 Gbps network hub to connect the Pis (yielding a 0.3 ms ping between them) and an uplink via a Wi-Fi 6 travel router. I am using the 2.4 GHz band for longer reach, which results in a 7–15 ms ping from the PC. The closest mesh access point is configured to prioritize the travel router and lock it to that specific AP.

Here is what I have added to the .bashrc file on all involved computers:

source /opt/ros/jazzy/setup.bash
export ROS_DOMAIN_ID=0
export ROS_AUTOMATIC_DISCOVERY_RANGE=SUBNET
export FASTDDS_BUILTIN_TRANSPORTS=LARGE_DATA

# this is just for monitoring RPi health:

env | grep ROS
uptime -p
cpuTemp0=$(cat /sys/class/thermal/thermal_zone0/temp)
cpuTemp1=$(($cpuTemp0/1000))
cpuTemp2=$(($cpuTemp0/100))
cpuTempM=$(($cpuTemp2 % $cpuTemp1))
echo CPU temp"="$cpuTemp1"."$cpuTempM"'C"
echo GPU $(/usr/bin/vcgencmd measure_temp)

Currently, I see a solid throughput of ~20 Mbits/s (nload eth0). My 820x616 uncompressed images are transferring successfully, even when opening both RGB and depth streams simultaneously. Trying to transfer more seems to result in throttling of some kind, so it tops at 20 Mbits/s.

Note that using compressed transport has never been a problem, given that consumers could handle that (RViz and RQT can't).

While this works, it is by no means ideal. If you have any relevant insights or optimization tips, please respond.

Best Regards,

-- Sergei

[Marco Walther]

On 8/5/26 12:07, Sergei Grichine wrote:
> Hi All,
> I want to revisit the issue discussed yesterday in the ROS focus group
> meeting.

Hello;-)

Did you by any chance look at https://arxiv.org/html/2508.11366v1 and
the related github repo?

> It has been a major pain in the neck for me, resulting in expensive
> upgrades to my home and outdoor Wi-Fi, the addition of travel routers on
> my robots, and numerous configuration attempts. Some of these efforts

> are reflected in this guide <https://github.com/slgrobotics/
> robots_bringup/blob/main/Docs/Sensors/WiFi_Logger_Visualizer.md>.
> At the moment, I am trying to tame RTAB-Map <https://github.com/
> slgrobotics/articubot_one/wiki/Visual-SLAM-with-RTAB%E2%80%90Map>

> (Visual SLAM) on my outdoor robot, Dragger, which is putting everything
> to the test. Specifically, passing RGB, depth, and SLAM data around has
> proven difficult.
> Dragger can be run in two configurations:
>

> 1. A single RPi5 running both the OAK-D Lite and the RTAB-Map node.
> 2. A primary RPi5 handling the robot and RTAB-Map node, while pulling
> visual data from a secondary RPi5 running the stereo <https://
> github.com/slgrobotics/ros2_inference_stereo> node.

>
> In both setups, RViz and the joystick node run on a separate Intel PC.
> Hardware-wise, Dragger uses a 1 Gbps network hub to connect the Pis
> (yielding a 0.3 ms ping between them) and an uplink via a Wi-Fi 6 travel
> router. I am using the 2.4 GHz band for longer reach, which results in a
> 7–15 ms ping from the PC. The closest mesh access point is configured to
> prioritize the travel router and lock it to that specific AP.
> Here is what I have added to the |.bashrc| file on all involved computers:
>
> source /opt/ros/jazzy/setup.bash
> export ROS_DOMAIN_ID=0
> export ROS_AUTOMATIC_DISCOVERY_RANGE=SUBNET
> export FASTDDS_BUILTIN_TRANSPORTS=LARGE_DATA
>
> # this is just for monitoring RPi health:
> env | grep ROS
> uptime -p
> cpuTemp0=$(cat /sys/class/thermal/thermal_zone0/temp)
> cpuTemp1=$(($cpuTemp0/1000))
> cpuTemp2=$(($cpuTemp0/100))
> cpuTempM=$(($cpuTemp2 % $cpuTemp1))
> echo CPU temp"="$cpuTemp1"."$cpuTempM"'C"
> echo GPU $(/usr/bin/vcgencmd measure_temp)
>

> Currently, I see a solid throughput of ~20 Mbits/s (|nload eth0|). My

> 820x616 uncompressed images are transferring successfully, even when
> opening both RGB and depth streams simultaneously. Trying to transfer
> more seems to result in throttling of some kind, so it tops at 20 Mbits/s.

> Note that using compressed <https://github.com/slgrobotics/
> ros2_inference_stereo#image-transport-raw-vs-compressed> transport has

> never been a problem, given that consumers could handle that (RViz and
> RQT can't).

Rviz2 seems to get support eventually;-) It looks like the PR made it at
least into Rolling;-)

https://github.com/ros2/rviz/issues/738

Have fun,
-- Marco

> While this works, it is by no means ideal. If you have any relevant
> insights or optimization tips, please respond.
> Best Regards,
> -- Sergei
>

> --
> You received this message because you are subscribed to the Google
> Groups "HomeBrew Robotics Club" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to hbrobotics+...@googlegroups.com
> <mailto:hbrobotics+...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> hbrobotics/CA%2BKVXVNYs52x%3Do5YPwW7MkM8no-
> Cv4Q8CvW95cWsn0iJHQa6YQ%40mail.gmail.com <https://groups.google.com/d/
> msgid/hbrobotics/CA%2BKVXVNYs52x%3Do5YPwW7MkM8no-
> Cv4Q8CvW95cWsn0iJHQa6YQ%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

[Sergei Grichine]

Marco,

Thanks for the link to the deep-dive DDS paper: https://arxiv.org/html/2508.11366v1

The paper highlights the limitations of standard DDS configurations, echoing a conclusion many of us in the ROS SIG have already reached:

"...These results indicate that standard DDS is fundamentally incapable of supporting real-time, large-payload transmission over wireless networks. The ROS community has also acknowledged this limitation..."

However the authors achieved stable, real-time wireless transmission of large payloads by optimizing XML-based QoS parameters - by preventing IP fragmentation, adjusting retransmission timing, and limiting the HistoryCache size.

I haven't tried these optimizations yet, that's on my TODO list.

Based on that and my own experience, here is a practical checklist for my wireless robots: 

• Test your network thoroughly, especially the Wi-Fi links; iperf3 and Wi-Fi mapper tools are essential here. 
• Use a high-quality Gigabit switch to connect multiple on-board machines into a local mini-LAN (for more than one RPi configurations). 
• Avoid relying on the Raspberry Pi's built-in Wi-Fi hardware inside a robot chassis, as it is generally inadequate for any traffic, but can be used for WiFi mapping. 
• Use a dedicated, high-performance Wi-Fi travel router that matches your access point's capabilities (e.g., Wi-Fi 6, mesh) and lock it to a specific AP if possible. 
• Never send uncompressed images over Wi-Fi; keep raw streams confined to the on-board Gigabit LAN (or a single machine). 
• Note that RQT and RViz do not natively accept compressed images yet, though the upcoming Lyrical release might introduce a fix. 

Compressed images can be viewed by a dedicated tool:

    ros2 run image_view image_view --ros-args -r image:=/camera/image_raw -p image_transport:=compressed

The "export FASTDDS_BUILTIN_TRANSPORTS=LARGE_DATA" may serve as a temporary fix, but it fundamentally changes the transmission mode from UDP to TCP and is generally a bad idea.

I hope this helps. Feel free to add your own findings to the list.

Best Regards,

-- Sergei

[Chris Albertson]

About large images.   I was always told the only practical solution was to do the preliminary image processing on the same computer the camera was connected to and then only put the reduced data over the network.      

So for example, you need to send the camera data to an image recognizer, first to get the image, down sample to 256x256 or 512x512, convert to grayscale, and normalize it, and ONLY then send it off over the network.   8-bit greyscale is easy to send.

If trying to do lane following or just keep a robot on the sidewalk, you would do the Hough transform locally, then only send the vectors to a neural network that controls steering. 

Never send raw images.

This is why they sell things like “depth cameras” so the processing is done locally to reduce the amount of data sent over the interface.

Sometimes for debugging, you want to see a full RGB image, don’t use ROS for that, simply stream the images as if it were a webcam.

To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/CA%2BKVXVPSRuqtXHv0WwWcbjBSo_4ud0cmCyqs%2B_J3egMfpS8WTQ%40mail.gmail.com.