SDK examples raise AttributeError: fix the version mismatch

You run an example script that came with your camera SDK, and it dies on the first real line of work: AttributeError, the SDK's camera object "has no attribute" the example clearly calls. Above the traceback sits a RequestsDependencyWarning complaining that urllib3 or chardet "doesn't match a supported version". The instinct is to chase the warning. Don't. The warning is an import-time notice from the HTTP library requests, and your own traceback proves the script ran past every import before failing in example code. The actual cause is almost always a version mismatch: the examples were written for a different SDK release than the one installed in the environment you launched from. Here you will learn to read the two messages, test the likely causes in order, and get example code and installed library back onto one release — on a bench board or a deployed controller.

Read the two messages before touching anything

Two independent prints appear, and they carry different weight.

The RequestsDependencyWarning comes from the requests package's own import check. When the urllib3, chardet or charset_normalizer copies inside the active environment fall outside the ranges that the installed requests release supports, it calls warnings.warn and carries on. Nothing is raised. In one real case, requests 2.26.0 printed the notice with urllib3 1.26.12, chardet 5.1.0 and charset_normalizer 2.0.12 in play — and execution continued into the example.

The AttributeError is raised by Python itself when a name does not exist on the object you called it on. Its text names the class and the missing attribute, and the traceback points at a line in your example — line 4, the first camera call, in that same case.

Two details prove the warning is innocent. The failing line is business code, not an import, so every import — requests included — had already succeeded. And the identical AttributeError appeared on a second machine whose terminal printed no warning at all. A message that differs between two machines while the failure is the same on both is not the failure.

Likely causes, ranked

1. Examples newer than the library. You cloned the examples folder from the repository's current state while the environment holds an older installed release. SDKs rename methods between minor releases; every rename made after your version becomes a missing attribute. This is the most likely cause when you built the environment first and fetched the examples later.
2. Examples older than the library. The reverse: the SDK was upgraded and the example folder was not. Same exception, opposite direction — common after a pip install --upgrade that was meant to fix something else.
3. Two copies of a package. The OS package manager installs into the system dist-packages directory; pip installs into the virtual environment. dpkg -l and pip list can then report different versions of the same library, and both are truthful. This mix-up produces confusing version reports and import-time warnings far more often than it produces AttributeErrors.
4. The wrong object. The attribute exists, but on a submodule or on the device handle rather than on the object you hold. Test this only after the versions match exactly.

Test each cause in order

Test 1 — what is installed. Run pip show on the SDK package and read the Version line, or import the package and print its version attribute:

pip show your-cam-sdk
python3 -c "import your_cam_sdk; print(your_cam_sdk.__version__)"

your-cam-sdk is a placeholder; substitute your SDK's package name everywhere below.

Test 2 — which copy imports. When version reports disagree, print the module's file path:

python3 -c "import your_cam_sdk; print(your_cam_sdk.__file__)"

A path ending in lib/python3.11/site-packages/ is your venv copy; one under /usr/lib/python3/dist-packages/ is the OS-managed copy. Python imports whichever comes first on its path, and the venv normally wins.

Test 3 — how old the examples are. If the examples folder is a git clone, run git log -1 inside it and read the commit date. Compare it with the release date of your installed version: examples from a repository's default branch track the newest release, not yours.

Test 4 — dependency consistency behind the warning. pip check reports any installed package whose dependency ranges are unsatisfied inside the venv. It explains the RequestsDependencyWarning; it will not fix your AttributeError.

Worked example: a 3D camera point-cloud script on Python 3.11

The case: a 3D camera's Python SDK on a single-board ARM Linux computer, inside a project virtual environment. The inputs, each with its source:

• Python 3.11.2, 64-bit ARM — from the environment log; the traceback path under lib/python3.11/site-packages/ agrees.
• Installed in the venv, from pip list: the SDK at 1.9.4, requests 2.26.0, urllib3 1.26.12, charset_normalizer 2.0.12.
• On the OS layer, outside the venv, from dpkg -l: chardet 5.1.0 and a package-manager charset-normalizer at 3.0.1 — a second, separate copy of a library the venv also carries.
• The failing script: four lines; line 4 is the first camera call; it raised AttributeError on the SDK's context object.

The rule, in words: an AttributeError that names the SDK's own class means the imported release does not define that name. A version reads major.minor.patch, so 1.9.4 sits on minor line 1.9; examples taken from a repository's current state were written for a strictly newer minor line.

The arithmetic. Because 1.9 is the lower minor line, every method renamed since 1.9.4 is absent from the package the interpreter imports — and the first renamed method the example touches, the camera call on line 4, raises. The warning's numbers describe the same untidy-but-working environment: requests 2.26.0's import check read charset_normalizer 2.0.12 from the venv and chardet 5.1.0 from the OS layer, printed its notice, and returned. The proof that it returned is the traceback itself — the failure sits at line 4, not in an import. On the second machine with no warning, the same line raised the same exception.

The result: example code ahead of the installed library, with the environment otherwise healthy and the camera and its USB link never involved.

The decision, with its threshold: whenever the installed minor line is lower than the one the examples were written for — here 1.9 against anything newer — do not edit the example. Check out the examples tag that matches the installed version and rerun. On a bench machine you may instead upgrade the SDK to the examples' release and rerun the same four lines; on a machine that already runs production code, take the tag, never the upgrade.

# Placeholder names; the pattern is what matters.
from your_cam_sdk import Rig

with Rig() as rig:
    color = rig.camera("color")   # line 4: AttributeError: 'Rig' object has no attribute 'camera'

git tag --list          # release tags follow vX.Y.Z in this project
git checkout v1.9.4     # examples now match the installed library
python3 your_example.py # runs; any requests warning still prints, harmlessly

The rerun is the test that proves the result: all four lines execute, the with-block opens the camera, and no AttributeError appears.

The fix: pair the examples with the release

Match the examples to the library — the choice for deployed machines:

1. Run pip show on the SDK package and read the Version line.
2. In the examples clone, list the release tags and pick the one equal to that version, or the nearest lower one.
3. Check out that tag.
4. Rerun the failing script.

Match the library to the examples — the choice for bench machines:

1. Upgrade the SDK package with pip install --upgrade.
2. Run pip check to catch any dependency break the upgrade introduced.
3. Rerun your own shortest script first, then the example.

Keep the pair together from now on

• Install examples and library as one unit, from the same release, and record both versions in the project notes.
• Keep one virtual environment per project. When dpkg -l and pip list disagree, trust the module's file: it names the copy Python actually imports.
• Pin exact versions in requirements.txt and save pip freeze output next to the test log, so any machine can reproduce the passing run.
• Pin the same way in containers and on edge inference boxes — see pinning one library version in Docker builds and the edge inference crash fixed by version pinning.

The camera is never the suspect. The same four-line failure hits a bench rig built on a 120 fps USB3 board camera and one built on a 3D depth camera alike; the defect lives in the environment, not in the device.

When versions match and it still fails

If pip show, the tag list and the example's git history all agree and the AttributeError persists, the cause is namespace, not version. The method may live on a submodule or on the device object rather than on the context object — search the installed package for it:

grep -rn "def camera" */lib/python3.11/site-packages/your_cam_sdk/

A wrapper library can also import its own copy of the SDK under a second name; print file for both names and compare the paths. From here the failure joins the API-mismatch family: a call signature that changed between SDK versions and a renamed API after a library update fail in closely related ways, and so do renamed settings in a robot launch file.

Moving the fixed environment onto shipping hardware

The same version discipline carries a project from bench to production. On the camera side, board-level cameras and 3D sensors both arrive with example code, and both get deployed against pinned environments; the board camera selection guide covers picking the camera. On the runtime side, a vision controller gives the pinned environment a permanent home: the MV-VC2140-128G40-1T, for example, carries 8 GB RAM, a 128 GB SSD plus a 1 TB HDD, and four built-in light channels.

Pick the camera side in the camera finder or start the configurator at the camera step. More bring-up fixes sit on the systems topic page. Expert support is free with every order, so if the version mess is tangled with hardware selection, talk to the applications team before you buy.