@Jskim , maybe it's ok that the Device ID is increasing, however it could mean the USB device is not de-initializing properly (according to the Kernel). Perhaps the device is still open / in use by voxl-uvc-server when you power the camera off (switch to the SD card mode).
Please see some more information below that may be helpful.
Fix 1: Configure voxl-uvc-server to identify the camera by Vendor/Product ID
Instead of relying on the device index, tell voxl-uvc-server to always find your camera by its USB VID:PID. This is the most robust approach.
Step 1: Find your camera's Vendor ID and Product ID
lsusb
Look for your UVC webcam in the output. The ID is in VENDOR:PRODUCT hex format, e.g.:
Bus 001 Device 003: ID 090c:337b <-- vendor=090c, product=337b
You can also use the ModalAI helper script:
show-video-device-info.sh
Step 2: Update the voxl-uvc-server service to pass VID/PID
Edit the systemd service override so the server always targets your specific camera:
mkdir -p /etc/systemd/system/voxl-uvc-server.service.d/
cat > /etc/systemd/system/voxl-uvc-server.service.d/override.conf << EOF
[Service]
ExecStart=
ExecStart=/usr/bin/voxl-uvc-server -v <your-vendor-id> -p <your-product-id>
EOF
systemctl daemon-reload
systemctl restart voxl-uvc-server
Replace <your-vendor-id> and <your-product-id> with the hex values from lsusb. With this in place, voxl-uvc-server will find the camera by identity rather than by device node index, so it will survive power cycles without needing a manual restart.
Fix 2: Create a udev rule for a persistent /dev symlink
This assigns a stable name (e.g., /dev/uvc_cam) to your camera regardless of enumeration order:
cat > /etc/udev/rules.d/99-uvc-camera.rules << EOF
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="<your-vendor-id>", ATTRS{idProduct}=="<your-product-id>", SYMLINK+="uvc_cam", MODE="0660"
EOF
udevadm control --reload-rules
udevadm trigger
After this, /dev/uvc_cam will always point to your camera. You can reference this stable symlink in any configuration.
Fix 3: Check dmesg for resource leak warnings
If the device ID keeps incrementing (e.g., /dev/video0 → /dev/video1 → /dev/video2...) rather than re-using the same node, there may be an underlying resource leak from improper de-initialization:
dmesg | grep -i "uvc\|video\|usb" | tail -50
Look for warnings about disconnection or failed cleanup. If the ID increments indefinitely, this points to a kernel-side resource not being released properly on power-off — that may require a deeper fix or a systemctl stop voxl-uvc-server before powering down the camera.
Summary
| Step |
Action |
| 1 |
Run lsusb to get your camera's Vendor ID and Product ID |
| 2 |
Pass -v <vid> -p <pid> to voxl-uvc-server via a systemd override |
| 3 |
Optionally create a udev rule for a stable /dev/uvc_cam symlink |
| 4 |
Check dmesg for warnings if the device ID keeps incrementing |
The vendor/product ID approach (Fix 1) should eliminate the need for the manual systemctl restart workaround entirely.
then we have a trajectory calculation problem on the voxl-mapper side (I'll check our code, but our QA currently show that was working properly).
