Hi everyone, I’m trying to get the Arducam RGBD ToF Depth Camera Kit set up. I need the customized image for it — the default password for user “pi” didn’t work for me, though the image does boot up without asking for a password at all. Can anyone point me to the right image download? I want to make sure I’m starting from the correct base.
I’ve sent you the download link for the customized image via private message. Please check your inbox — it should have what you need. Give it a try and let us know how it goes.
Got the image, thanks. The examples are all running again now. But here’s what I’m really after: I want to use the ToF sensor in my own application with as few dependencies as possible. I just need to grab a single ToF depth image on demand from my own Linux setup on the Raspberry Pi. Is there a way to pull a depth frame directly through GStreamer or OpenCV without dragging in the entire SDK? Basically — can I bypass the SDK and talk to the sensor directly?
Digging into this a bit more — it looks like the depth frame is actually the result of processing through Arducam’s driver and SDK pipeline, not something the sensor outputs natively. If I’m going to use this on a custom Linux image, I’d need to cross-compile the driver and SDK for that environment. The SDK source is here:
git clone https://github.com/ArduCAM/Arducam_tof_camera.git
Does this repository also contain the camera driver itself, or is that a separate component I need to track down?
Good catch — you’re on the right track. The ToF sensor outputs raw phase data, not anything resembling a standard video feed. There’s no way around it: the Arducam ToF SDK is mandatory for turning that raw phase data into a depth image that OpenCV or anything else can work with. GStreamer and OpenCV alone cannot talk to the sensor directly.
There are two distinct components you need on any Linux system:
- Kernel Driver — The Pivariety driver (kernel space). This is what talks to the hardware.
- SDK — The user-space software that processes the raw phase data and calculates the depth map. This is what’s in that GitHub repo you linked.
The SDK repository does not contain the kernel driver. They’re separate pieces, and critically, they must match the kernel version exactly or the driver won’t load at all.
A few important realities:
- The RGBD All-in-One Kit is designed and optimized exclusively for the official Raspberry Pi OS (Bookworm).
- Porting the Pivariety driver stack to a custom Linux distribution is complex. The custom OS will almost certainly lack the compatible Pivariety kernel modules that ship with the official RPi OS (Bookworm).
- This kind of porting is not something Arducam supports.
My strong recommendation: use the official Raspberry Pi OS (Bookworm) as your base. That ensures the kernel modules, SDK versions, and all dependencies line up. Trying to cross-compile the Pivariety driver for a custom kernel is going to be a world of pain.
That makes sense — I’ll stick with the official Bookworm image then. On a related note, I’m now developing a C++ application directly on the device and I need some kind of user interface. Qt doesn’t seem to be installed, no wxWidgets either. GTK appears to be present but I’m missing the developer headers and libraries (can’t compile against it). I’m not sure what packages are safe to apt install without breaking the existing camera setup. I’m even considering just switching to Python if C++ UI is going to be a headache.
What’s actually intended to be used on this device for application development? And is it generally safe to apt install additional packages on top of the customized image?
Quick update — I just stumbled across Qt5 headers already on the device:
/usr/include/aarch64-linux-gnu/qt5
/usr/include/aarch64-linux-gnu/qt5/QtPlatformHeaders
/usr/include/aarch64-linux-gnu/qt5/QtPlatformHeaders/QtPlatformHeaders
/usr/include/aarch64-linux-gnu/qt5/QtPlatformHeaders/qtplatformheadersversion.h
/usr/include/aarch64-linux-gnu/qt5/QtPlatformHeaders/QtPlatformHeadersDepends
/usr/include/aarch64-linux-gnu/qt5/QtPlatformHeaders/QtPlatformHeadersVersion
... and more
I’m currently working in ~/tof-examples/example/cpp for my development. Looks like I can adapt the examples to use Qt for the UI layer. Going to give this a shot unless anyone sees a reason not to.
Qt5 is actually what the examples are built around, so you’re in good shape there. The headers being present on the device means the Qt5 development packages are already installed — you should be able to compile against them directly. No need to switch to Python unless you prefer it.
As for apt install — yes, it’s generally safe to install standard packages from the Raspberry Pi OS repositories on top of the customized image. The camera-specific components (Pivariety driver, ToF SDK) live outside the normal package management, so regular apt operations won’t touch them. Just avoid anything that would upgrade the kernel or kernel headers, since that could break the driver compatibility I mentioned earlier. Standard dev libraries, build tools, and UI packages should all be fine.
If you’re working in ~/tof-examples/example/cpp, you’re in the right place. The existing examples are Qt-based and you can use them as a reference for your own application.
Just confirming back — building with Qt directly on the device works perfectly. I’ve got my C++ application compiling and linking against the ToF SDK and Qt5 without issues. Thanks for the guidance on all of this.