Depth camera SDK support check: verify stereo cameras before you buy

A new stereo depth camera is only as supported as the SDK release you can actually deploy. New 3D models routinely land in the development branch of an open SDK first and reach a stable, tagged release weeks later, so a product page that names an SDK does not prove the camera and your deployment will meet. The check takes an afternoon: match the exact model string against the supported-device list, confirm the branch, OS and CPU build, then size the stereo depth error before the purchase order goes out. This is written for integrators specifying bin picking, dimensioning or measurement cells, and it ends with a decision rule for each case.

The decision rule: model string, SDK version, OS

Depth camera support is a property of a triple: the exact model string, the SDK version, and the OS and CPU it runs on. A camera is supported only where all three intersect, and the decision follows directly:

• Model string listed in a stable, tagged release for your deployment OS: order it.
• Model string only in the development branch: prototype on a pinned commit, and schedule production for the tag that carries the model.
• Model string absent from both: pick another model, or plan your own pipeline on standards-based cameras.

Naming an open-source SDK on a product page tells you who writes the code, not whether your model is in the release your line pins. That question is answered by the supported-device list and the release tags, and it is answered per model, per OS.

If the camera is already on your bench and failing to enumerate, the fault is probably not the list. Start with diagnosing stereo camera platform compatibility instead.

Where SDK support actually lives

An SDK admits a camera by identifier, not by product family. For USB3 cameras the match is usually the USB vendor and product ID; for GigE devices it is the device description and the GenICam XML it serves. Three consequences follow.

Revisions change the identifier. A sensor family sold as a V2.0 revision can carry a different device ID from the original even though the product name is unchanged, and the catalog itself lists several 3D sensors as V2.0 hardware revisions. Match the full string, suffix included.

New models arrive in the development branch. Support for a new camera is typically written against the development branch first and lands in the next tagged release, so the gap between a product launch and stable support is measured in release cycles, not days.

The backend is per OS. Windows and Linux enumerate the same camera through different drivers, and Linux adds device permissions that can block your process while the vendor viewer still runs. Camera SDK cannot find device: isolate Linux access errors covers that layer. On ARM boards the SDK may need a source build, which is where cross-platform claims quietly end; the CMake Boost failures when building a 3D camera SDK on ARM article shows the typical break.

Standards-based cameras move the question entirely: a GigE Vision or USB3 Vision camera that serves GenICam is enumerated by any compliant GenTL producer, so you check the producer rather than a vendor device list. GenTL producer GigE Vision support works through that path.

The five-point check before the purchase order

Run these five checks in order; each one has stopped a real order at some point.

1. Pin the deployment stack first. Write down the OS, CPU architecture, SDK version or commit, and driver before looking at cameras. The camera must be supported on that stack, not on the vendor demo laptop.
2. Match the exact model string. Search the supported-device list of that pinned version for the full string with its revision suffix. If the list is not public, ask for it in writing alongside the quote.
3. Confirm the branch. Stable tag for production hosts. Development branch for prototypes only, with the commit hash recorded in your build.
4. Check every host the camera will touch. A real-time controller has its own driver gate, and the GigE Vision camera on an RT controller driver check is the pattern to follow. A ROS 2 deployment adds a wrapper as a second dependency: why NITROS negotiation fails in Isaac ROS stereo depth documents a stream the SDK delivers but the wrapper drops.
5. Prove it in your own binary. Enumerate the camera and pull one depth frame from your code during the evaluation. The vendor viewer exercises a different path, and 3D camera capture time slower in the API than in the viewer shows one way the two diverge.

Worked example: 700 mm bin, 800 mm stand-off, ±3 mm tolerance

The task: guide a gripper into a 700 mm wide bin of parts, with the camera on a frame 800 mm above the parts and a grasp planner that needs depth good to ±3 mm. Two stereo modules are on the shortlist, a compact one with a 50 mm baseline and a long-baseline one with 120 mm. Both quote a 1.9 mm focal length and 3.0 µm pixels; substitute your model's own figures at this step. Disparity error is taken as 0.25 px, the middle of the 0.2–0.5 px band typical of subpixel stereo matching.

Inputs:

• Working distance z = 800 mm
• Bin width 700 mm, half-width 350 mm
• Depth tolerance ±3 mm
• Disparity error δd = 0.25 px
• Baselines B = 50 mm and B = 120 mm
• Focal length f = 1.9 mm, pixel size p = 3.0 µm

Stereo depth error grows with the square of distance and shrinks with baseline and focal length:

Focal length in pixels first: f_px = 1.9 mm ÷ 3.0 µm = 1900 µm ÷ 3.0 µm = 633 px.

Compact module, B = 50 mm: δz = (800 mm)² × 0.25 px ÷ (633 px × 50 mm) = 160,000 mm²·px ÷ 31,650 px·mm ≈ 5.1 mm. That is 70 percent over the ±3 mm tolerance: fail.

Long-baseline module, B = 120 mm: δz = 160,000 ÷ (633 × 120) = 160,000 ÷ 75,960 ≈ 2.1 mm. Inside tolerance with margin: pass.

Two follow-ons from the same equation. Closing the distance helps fast: at 600 mm the 50 mm module gives 90,000 ÷ 31,650 ≈ 2.8 mm, marginal against the tolerance. Distance hurts faster: the 120 mm module stays under 3 mm only to about 950 mm, since at 1,000 mm it gives 250,000 ÷ 75,960 ≈ 3.3 mm.

Field of view is not the limiter here. Covering a 350 mm half-width at 800 mm needs atan(350 ÷ 800) ≈ 23.6° per side, about 47° horizontal, and compact stereo modules are built wide, typically 65–90°. Depth error is the constraint, not coverage; for mounting geometry, the 3D camera working distance and positioning guide goes deeper.

Decision: order the 120 mm baseline module, conditional on its exact string appearing in the stable supported-device list for your OS. If it sits in the development branch only, prototype on a pinned commit and gate the production date on the tag that carries it.

Three hardware routes and their support risk

A camera that computes depth onboard hands you a point cloud through the vendor SDK, which is the fastest route to a working cell and the one most exposed to the device-list gaps above. The 3D sensors category covers all three routes:

The two-camera route removes the vendor device list entirely: standards-compliant cameras enumerate through any GenTL producer, and the depth math, calibration and trigger sync become your code. The camera finder filters area scan cameras by interface and shutter, and the camera step of the system configurator sizes the pair against your field of view. A pair of compact global-shutter cameras is the usual starting point, for example the MV-CU020-90GC, a 2.5 MP GigE camera with a global shutter and a C-mount:

For help weighing the routes against a moving line, 2D or 3D camera for conveyor pick and place works through the same decision on a conveyor.

When the usual answer is wrong

It worked in the viewer is not support. Viewers ship their own backends and settings; your application does not. The same camera can pass a vendor viewer and fail a second viewer over a GenTL producer, which is the pattern in frame grabber SDK support: why one viewer works and another fails, and it can enumerate yet return no depth because your code never requests the depth stream.

Stable SDK, wrong firmware. The device list is per SDK version, and the camera firmware has its own version line. Mismatched pairs surface as context-creation or header errors rather than a clean refusal; the 3D camera header version mismatch fix covers aligning them.

The demo was x86, the line is ARM. Cross-platform means every platform you actually ship. Budget the source build and its dependencies for ARM hosts before the order, not after.

Support was promised, not tagged. A roadmap entry or a development-branch commit is a promise. If production starts in three months and the model is not in a tag today, order a model that is.

The order-day checklist

• Exact model string, revision suffix included, found in the supported-device list of the pinned SDK version — the identifier is how the SDK admits the camera.
• Stable tag on production hosts; pinned commit only on prototypes — branch interfaces move between tags.
• OS and CPU build confirmed for every host, including any ARM board — source builds are where cross-platform claims end.
• Driver and backend named for your OS, with device rules baked into the deployment image — Linux permission errors hit your process, not the viewer.
• Your own binary enumerated the camera and pulled a depth frame during evaluation — the viewer proves only half the path.
• Datasheet baseline and focal length give the depth error you need at your stand-off — run the worked example with your figures.
• IR projector eye-safety class recorded in the machine file — the classification ships with the cell.
• Robot interface and hand-eye support checked — 3D camera robot integration compatibility lists what to confirm.

When the checks pass, send the model string, OS and SDK version to our applications desk with the quote request and we will confirm the supported-device list entry with you. More set-up guides are on the 3D topic page.