Hey everyone, I’m trying to get the DepthAI demo running on my Raspberry Pi but hitting a wall right away.
I’m on Debian Trixie with Python 3.13 and when I run:
python3 depthai_demo.py
I get:
ModuleNotFoundError: No module named 'open3d'
So I tried running python3 install_requirements.py a few times but it just won’t install open3d. The rest of the packages seem to go through fine, but open3d never gets installed. Any ideas?
That’s going to be a Python version issue. open3d doesn’t have wheels for Python 3.13 yet — it’s too new. The install_requirements.py script is probably skipping it silently because there’s no compatible wheel available for your interpreter.
The DepthAI stack is tested against Python 3.9 through 3.11 on Raspberry Pi. Debian Trixie ships 3.13 by default which is going to cause problems beyond just open3d.
I’d recommend switching to Raspberry Pi OS ‘Bookworm’ (which is Debian 12 under the hood). That ships Python 3.11 and everything should resolve cleanly. After flashing Bookworm, just run python3 install_requirements.py again and it should pick up all the packages properly.
Alright, I took your advice and did a clean install of Debian Bookworm on the Pi. Here’s what I’m on now:
/home/dsh/.local/lib/python3.11/site-packages/pip)So the Python version should be fine now. But I ran the dependency installer:
./pinsight_install_dependencies.sh
And it’s still failing — this time with what looks like network/DNS errors. I’m seeing a bunch of these:
WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<pip._vendor.urllib3.connection.HTTPSConnection object at 0x7fff8fd262d0>: Failed to establish a new connection: [Errno -2] Name or service not known')': /simple/mcap/mcap-1.3.0-py3-none-any.whl
This repeats like 5 times and then dies with a fatal error about not being able to reach archive1.piwheels.org. The Pi definitely has internet — I can ping google and everything. Any clue what’s going on here?
That [Errno -2] Name or service not known points to a DNS resolution failure specifically for archive1.piwheels.org. The fact that you can reach the broader internet but piwheels archives are failing suggests either:
Can you try a quick test from the Pi?
nslookup archive1.piwheels.org
And also:
curl -v https://archive1.piwheels.org/simple/mcap/
That’ll tell us whether the hostname resolves at all and whether the connection completes. Also, do you see any other warnings in the output besides the mcap ones? Anything about send2trash or open3d being skipped?
So nslookup archive1.piwheels.org fails with:
server can't find archive1.piwheels.org: NXDOMAIN
Looks like that subdomain straight up doesn’t resolve from my network. The main piwheels.org resolves fine though.
And yeah, there’s actually quite a bit more going on in the log. Here’s a more complete picture:
WARNING: Error parsing dependencies of send2trash: Expected matching RIGHT_PARENTHESIS for LEFT_PARENTHESIS, after version specifier sys-platform (=="darwin") ; extra == 'objc' ~^
requests gets downgraded from 2.32.5 to 2.26.0 early in the install (looks like it’s pulling a cached piwheels wheel), then later gets upgraded back to 2.32.5.
Most concerning — open3d is still being completely ignored:
Ignoring open3d: markers 'platform_machine != "armv6l" and platform_machine != "armv7l" and python_version < "3.9" and platform_machine != "aarch64"' don't match your environment
Even though I’m on Python 3.11 now and this is an aarch64 board. Seems like the marker logic is backwards or the available wheel doesn’t actually cover aarch64?
/home/dsh/depthai-python/examples/models/.But the install dies hard on the mcap package because of that DNS failure to archive1.piwheels.org:
ERROR: Could not install packages due to an OSError: HTTPSConnectionPool(host='archive1.piwheels.org', port=443): Max retries exceeded with url: /simple/mcap/mcap-1.3.0-py3-none-any.whl (Caused by NewConnectionError('<pip._vendor.urllib3.connection.HTTPSConnection object at 0x7fff8fb34d50>: Failed to establish a new connection: [Errno -2] Name or service not known'))
Alright, so there are actually three separate issues tangled together here. Let me break them down:
1. The archive1.piwheels.org DNS failure (blocking issue):
This is the show-stopper right now. archive1.piwheels.org returning NXDOMAIN while piwheels.org resolves fine suggests that particular subdomain either no longer exists or has been decommissioned on the piwheels CDN side. The mcap package is pure Python (py3-none-any) so there’s no arch-specific reason it needs to come from piwheels at all.
Try forcing pip to use PyPI directly for this package:
pip install --index-url https://pypi.org/simple/ mcap==1.3.0
If that works, then run the full script again — or better yet, temporarily disable the piwheels extra index while running the install script:
PIP_EXTRA_INDEX_URL="" ./pinsight_install_dependencies.sh
2. The open3d marker issue:
That marker string is suspicious. Let me decode it:
platform_machine != "armv6l" and platform_machine != "armv7l" and python_version < "3.9" and platform_machine != "aarch64"
For this to evaluate to True (meaning “install this wheel”), ALL conditions must be true. Your board is aarch64, so platform_machine != "aarch64" is False — therefore the whole thing is False and the wheel is skipped. This looks like it’s an old piwheels-hosted wheel that was packaged before proper aarch64 open3d builds were available.
Once we get past the DNS issue, you’ll likely need to install open3d from a different source. On Bookworm aarch64, try:
pip install open3d
This should pull from PyPI where they have proper aarch64 wheels for Python 3.11.
3. The send2trash warning and requests ping-pong:
Those are cosmetic issues with cached/outdated piwheels metadata. The send2trash dependency parsing error is a known quirk with older piwheels metadata having malformed environment markers — it won’t affect functionality. The requests downgrade-then-upgrade is pip’s dependency resolver reconciling conflicting version constraints from different packages. Not harmful.
Start with the DNS workaround and let me know if you get past the mcap install.
Good call on bypassing piwheels — installing mcap directly from PyPI worked:
pip install --index-url https://pypi.org/simple/ mcap==1.3.0
Then I re-ran the install script with piwheels temporarily disabled and it got much further. The mcap DNS issue is gone.
open3d still didn’t install through the script though, just like you predicted. But running pip install open3d directly did pull down a proper aarch64 wheel from PyPI and it installed cleanly on Python 3.11.2.
So to summarize where I’m at:
Haven’t actually tried running depthai_demo.py yet, but at least the install side seems sorted. The real question is — is archive1.piwheels.org being down/decommissioned a known thing? Seems like that’s going to bite anyone running this on a fresh Bookworm install.
Glad you got it sorted. The archive1.piwheels.org issue isn’t something we control on our side — it’s a piwheels CDN endpoint, and it does appear that particular subdomain has been retired or restructured recently. We’ve had a handful of reports about it on fresh installs over the past few weeks.
A few things to keep in mind going forward:
The pinsight_install_dependencies.sh script relies on piwheels as an extra index for ARM-optimized wheels. When piwheels has gaps (missing subdomains, stale markers, etc.), pip falls back to PyPI — except in this case the DNS failure was a hard error that broke the fallback path entirely. That’s the real bug here.
For the open3d situation: the piwheels index has an old open3d entry with markers that explicitly exclude aarch64. Pip sees that, thinks “there’s a wheel but I can’t use it,” and skips it — without checking PyPI because piwheels already provided an answer (even if that answer was “not applicable”). Installing directly from PyPI sidesteps this. This might be worth adding as a post-install step if you’re on aarch64.
The send2trash warnings and the requests version dance are harmless noise. The send2trash one in particular is just a malformed metadata entry in the piwheels index for the nvidia-ml-py or objc extras — nothing that affects a Raspberry Pi.
Go ahead and run python3 depthai_demo.py when you’re ready. With Python 3.11.2 and all deps properly installed, you should be in good shape. Post back if you hit any runtime issues with the camera or model inference.