ROS2 topics not visible on PC from OAK4-D driver app running via oakctl

sanjit

Hi Luxonis team,

I'm running the com.luxonis.ros.driver.spatial_bb_example app on my OAK4-D Pro W via Luxonis hub and I am starting via oakctl. The app starts successfully and logs show Driver ready! with Pipeline type: RGBD.

My setup:

OAK4-D Pro W connected via PoE (IP: 172.19.1.22)
External PC running ROS2 Kilted on Ubuntu 24.04 (WSL2, IP: 172.19.1.23)
ros-kilted-depthai-ros-driver installed via apt
Camera reachable — ping works fine

Problem: ros2 topic list on my PC only shows /parameter_events and /rosout — no /oak/... topics visible.

What I've tried:

I tried FastDDS unicast peer config and CycloneDDS both pointing at the camera IP — no luck. I also noticed zenoh_router.json5 in the example configs pointing to a separate router IP, which made me wonder if Zenoh is the intended transport for OAK4.

Questions:

What RMW does the on-device ROS2 app use by default?
What DDS/network config is needed on the external PC to discover topics published by the on-device app?
Is there a recommended FastDDS XML or CycloneDDS config for PC-to-OAK4 communication over PoE?
Is Zenoh the intended transport? I see zenoh_router.json5 referenced in example configs.

Are we doing this the right way — installing the driver as an OAK App via Hub and trying to subscribe from an external PC? Or is there a different recommended workflow for OAK4 + external ROS2 PC?

Any help is appreciated.

Thanks!

Oskar-Luxonis

Hey sanjit - this is a supported workflow. Running the ROS driver as an OAK App on OAK4 and subscribing from an external ROS2 machine on the same network is the intended setup.

A few points that should help narrow it down:

The on-device app is based on ROS 2 Kilted and does not explicitly override the middleware, so it is most likely using the default ROS 2 RMW, which is Fast DDS.
Zenoh is not the intended/default transport for spatial_bb_example. That example launches the standard ROS driver/filter stack directly, not a Zenoh-specific path.

The first thing I would try on the PC side is CycloneDDS, since our OAK4 ROS app examples explicitly recommend it when discovery is problematic:

  sudo apt install ros-$ROS_DISTRO-rmw-cyclonedds-cpp
  export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp

Also verify that ROS_DOMAIN_ID matches on both sides and that ROS_LOCALHOST_ONLY is unset or 0.

One important caveat: because your ROS host is running in WSL2, DDS discovery can fail there depending on the WSL2 network mode, especially if multicast is not working properly. If possible, test once from a native Ubuntu host, or at least verify multicast/discovery from WSL2 before going deeper.

Best,
Oskar

sanjit

Hey Oskar-Luxonis Thanks for your quick response. An update — made good progress on your checklist:

CycloneDDS installed, ROS_DOMAIN_ID matches (both default/empty), ROS_LOCALHOST_ONLY unset on both sides
Switched PC to FastDDS (matching camera default) + opened Windows Firewall for the camera's IP — this fixed discovery completely. ros2 topic list and ros2 node info /oak now show everything correctly.
But actual data still doesn't flow for most topics. /oak/imu/data works perfectly (live data). /oak/rgb/camera_info and /oak/rgb/image_raw both hang forever on ros2 topic echo/hz, even with Windows Firewall fully disabled.
Ruled out WSL2's fragmentation bug separately (ping tests with various sizes work fine).

So discovery works, IMU data works, but camera/image topics don't — even though topic info --verbose shows identical QoS (RELIABLE/VOLATILE) for both.

For context, I'm starting the app on the camera via oakctl app start <app_id> (Hub-deployed app), not building from source.

Two questions:

Any idea why IMU would flow but camera_info/image wouldn't, given matching QoS?
I see rgb.i_low_bandwidth in the docs for PoE — is there a way to pass that into an app started via oakctl/Hub (not building from source)?

Thanks for the help so far!

Oskar-Luxonis

sanjit - Thanks for the update, that narrows it down a lot.

At this point it looks like discovery is fixed and the remaining issue is specific to larger image streams, not the ROS graph itself. The fact that /oak/imu/data flows but /oak/rgb/image_raw does not strongly suggests a transport/payload issue rather than QoS mismatch. One extra detail here: camera_info may also appear “stuck” because the driver uses lazy image publishing, so camera_info is often tied to the image stream rather than publishing independently.

On rgb.i_low_bandwidth: yes, that is the right thing to try for PoE/network-constrained image topics. The catch is that for the Hub-deployed spatial_bb app started with oakctl app start <app_id>, there is not currently a simple runtime flag to inject ROS params like rgb.i_low_bandwidth:=true. That app is packaged with its own launch/config, so changing those driver params generally means building a custom app variant with a modified params file. The reference driver docs are here: DepthAI ROS Driver and the OAK app workflow here: Hub Integration.

Best,
Oskar