[BUG] Using local libusb build in ROS `kilted` branch?

[amarburg]

Describe the bug

I am trying to build a Docker image based on the ros:kilted image (based on Ubuntu 24.04) which contains depthai-core and depthai-ros.

My preferred solution is for depthai-core and depthai-ros to be built in a colcon workspace. Using the current kilted branch of both allows this.

However I've found most builds are unable to detect the USB device after boot (throws X_LINK_DEVICE_NOT_FOUND) from within Docker.

The only working solution I have found is to force the system to use the locally-built libusb. Since the kilted branch does not build this library, I build the develop branch from source outside of colcon, then copy the resulting local libusb in place of the system libusb:

sudo cp ./build/vcpkg_installed/x64-linux/lib/libusb-1.0.so /lib/x86_64-linux-gnu/libusb-1.0.so.0.4.0
sudo ldconfig

Which is clearly not a great idea.

At a high level, is this an issue with system libusb that necessitates using a custom version? Or an issue with the ROS2 build path for depthai-core where it is not building a local libusb when it should?

There's some connection to this forum post

Expected behavior

Expect a "straight path" to building depthai-core and depthai-ros with local libusb, either both within colcon, or depthai-core with cmake --target install and depthai-ros via colcon.

[moratom]

@amarburg can you try latest ROS release? It should have that fixed.

[amarburg]

@amarburg can you try latest ROS release? It should have that fixed.

That would be tag ros-v3.0.7 in this repo? And continue to use depthai-ros branch kilted?

[moratom]

That would be tag ros-v3.0.7 in this repo? And continue to use depthai-ros branch kilted?

Yes, correct on both.

[amarburg]

Unfortunately, this doesn't work for me. I've updated my workflow slightly.

(In the Dockerfile, building on ros:kilted as base image)

1. For efficiency and control, i have separated the libusb build from the depthai-core build. Replicating the process from depthai-core, build libusb from Luxonis fork, with ./configure --disable-udev --enable-shared. It is installed to /usr/local/...

2. Create ROS2 upstream_ws with:

   • depthai-core branch kilted (or as suggested, tag ros-v3.0.7)
   • depthai-ros branch kilted

Build workspace per standard procedure (rosdep, colon build)

3. Create ROS2 oakd_ws with my driver, overlay upstream_ws and colcon build.

If I do above, then:
libdepthai-core.so links to /usr/local/lib/libusb-1.0.so.0 (as expected) and my driver is able to find the OAKD.

If I omit #1 above (don't manually build libusb):
libdepthai-core.so links to /lib/x86_64-linux-gnu/libusb-1.0.so.0 (as expected) and my driver fails with X_LINK_DEVICE_NOT_FOUND

[Serafadam]

Hi @amarburg, are your udev rules set up correctly? Are you able to detect the camera using lsusb?

Here is some more information on that

[amarburg]

Yes, udev rules are set correctly (on the Docker host), and I am able to see the OAK re-enumerate as it is booting with lsusb (again, on the host)

Again, I think the questions are:

• Is the custom libusb essential for running inside a docker container based on 24.04?
• If so, why doesn't the kilted branch build the custom libusb either during the standard cmake build or when built as a colcon package?

[Serafadam]

Is the custom libusb essential for running inside a docker container based on 24.04?

They shouldn't be, in our ROS Docker image we use system libusb and the images themselves work without any modifications

[amarburg]

Interesting. I built your docker image from scratch:

git clone -b kilted https://github.com/luxonis/depthai-ros 
cd depthai-ros
docker build -t depthai-ros:test

Then started it with my code bind-mounted with a custom compose.yaml:

services:
  oakd:
    image: depthai-ros:test
    privileged: true
    tty: true
    network_mode: "host"
    volumes:
      - /dev/bus/usb:/dev/bus/usb
      - type: bind
        source: ../bluerov_oakd
        target: /ws/src/bluerov_oakd
    device_cgroup_rules:
      - 'c 189:* rmw'

Within the docker image, I then build my driver:

cd /ws/src
vcs import --recursive < bluerov_oakd/bluerov_oakd.repos
cd ..
rosdep install -i --from-paths src
colcon build --merge-install
source install/setup.bash

This does not work:

root@ws:/ws# ros2 launch bluerov_oakd oakd.launch.yaml
[INFO] [launch]: All log files can be found below /root/.ros/log/2025-10-22-18-14-12-186144-ws-6173
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [bluerov_oakd_driver-1]: process started with pid [6176]
[bluerov_oakd_driver-1] [INFO] [1761156852.386917847] [oakd.bluerov_oakd]: Attempting to auto-detect OAK device
[bluerov_oakd_driver-1] terminate called after throwing an instance of 'std::runtime_error'
[bluerov_oakd_driver-1]   what():  Failed to find device after booting, error message: X_LINK_DEVICE_NOT_FOUND

Attempting to run depthai_ros_driver also does not work:

root@ws:/ws# ros2 run depthai_ros_driver driver_node
[INFO] [1761156891.243165963] [driver]: Starting driver.
[INFO] [1761156891.244003848] [driver]: No ip/ID specified, connecting to the next available device.
[ERROR] [1761156907.435497279] [driver]: Failed to find device after booting, error message: X_LINK_DEVICE_NOT_FOUND

If I manually build and install libusb:

cd ~
git clone https://github.com/luxonis/libusb.git
cd libusb
./bootstrap.sh\
    && ./configure --disable-udev --enable-shared \
    && make -j install

Then rebuild libdepthai-core.so to ensure it is relinked:

root@ws:/ws# ldd ./install/depthai/lib/libdepthai-core.so | grep libusb
        libusb-1.0.so.0 => /usr/local/lib/libusb-1.0.so.0 (0x000074671fa6b000)

it then works with no other changes:

root@ws:/ws# ros2 run depthai_ros_driver driver_node
[INFO] [1761159139.712644256] [driver]: Starting driver.
[INFO] [1761159139.713571020] [driver]: No ip/ID specified, connecting to the next available device.
[INFO] [1761159141.836316720] [driver]: Driver with ID: 14442C1011ACD4D200 and Name: 5.1 connected!
...

This points to an issue with ... the host environment?