Which depth cameras output a pose stream and why most do not

A stream type named pose appears in several 3D camera SDKs, and it is tempting to enable it on the depth camera already mounted over the bench. No frames arrive. The enumeration is not broken and neither is the camera: a pose stream is 6-DOF tracking data, and an ordinary depth camera carries no hardware that produces it. This guide separates the two stream families, works the bandwidth and rate numbers so you can tell which one a task needs, and gives you three checks to run before ordering a camera for tracking work or for a fixed inspection cell.

What a pose stream actually carries

A pose stream publishes the camera's own position and orientation in a reference frame, one sample per timestamp. Six degrees of freedom means three translation values and three rotation values, and SDKs ship the rotation as a four-component quaternion, so one pose sample is seven numbers plus a time.

Tracking hardware publishes pose fast — 100-300 Hz in published visual-inertial odometry systems — because the consumer is a fusion loop or a controller that interpolates between samples. At 200 Hz and 28 B per sample that is 5,600 B/s, about 45 kbit/s: noise on a gigabit link.

Depth trades the other way. A 640 × 480 depth frame at 30 fps moves 614,400 B per frame, or 18.4 MB/s, so depth dominates bandwidth while pose dominates rate. Neither stream substitutes for the other, which is why they exist as separate types in the first place.

Why the SDK lists a stream type the camera cannot fill

One SDK usually serves a whole device family, and the stream-type enumeration in its header covers every model that family has shipped or announced. When a product line contains depth cameras and tracking modules, the pose entry belongs to the tracking module. Select it on a depth camera and the runtime either returns an error or sits at zero frames, because the sensor head carries depth, infrared and color pipelines and nothing else.

This is a hardware boundary, not a firmware gap. Pose requires an inertial measurement unit fused with camera images by a dedicated tracking engine, and no firmware release adds that silicon to a sensor that never had it. For a model whose data sheet lists only image streams, the answer to "will an update add pose" is no.

The hardware that makes pose: a tracking module

A tracking camera is a different product in a similar housing. Inside sit wide-angle cameras, an IMU sampled at a few hundred hertz, and a dedicated processor running visual-inertial SLAM. The IMU carries fast motion between frames; the cameras watch the scene and correct the inertial drift. That fusion needs tight, hardware-level time synchronization between the inertial and image data, which is why tracking units integrate the whole pipeline instead of bolting a generic IMU onto a depth camera.

Tracking modules exist for payloads that move: AR and VR headsets, drones, handheld scanners, mobile robots. Their output is the trajectory of the device itself, and in many such products tracking is the entire product, with no depth pipeline behind it at all.

An IMU sample stream is not a pose stream

Some depth cameras do expose inertial data, and this is where the confusion usually starts. A motion stream carries raw accelerometer and gyroscope readings at a few hundred hertz — useful for a gravity vector, for anchoring the camera's optical frame, and for discarding frames captured during shock or vibration. It is not pose. Fusing those samples into a trajectory is your software's job unless the vendor ships a tracking engine in firmware.

Mind the frame conventions if you use inertial samples: the IMU frame and the optical frame are not the same, and swapping them puts a right-angle error into everything downstream. We walk through the check in IMU optical frame transform: verify depth camera IMU frames.

What machine-vision 3D sensors output instead

Inspection cells invert the problem. The camera is bolted to a frame or hung over a conveyor at the working distance the sensor is sized for — the 3D camera working distance and positioning guide covers that geometry — so its pose is one constant transform captured at commissioning, and the motion in the cell comes from the robot controller, not from any camera. The 3D camera robot integration check lists what to confirm before wiring that up. What you buy, then, is a sensor that measures the part: depth maps, point clouds, laser profiles. The 3D sensors range splits into four families, all static-mount.

Structured light projects a known pattern and triangulates depth per pixel, which suits bin picking, volume and deformation work from a fixed mount.

The MV-DPS200P-02 is that family's projected-pattern representative.

Time of flight answers the same per-pixel question by timing light instead of triangulating it, at range windows set for the station.

The MV-DT01WMU is a ToF sensing camera in that family.

Profile sensors and laser galvanometer stereo scanners cover the dimensional end.

The MIS-DP3850-01P reads height along a laser profile and the MV-DLS300P-04 steers its laser with a galvanometer — both measurement engines for a fixed station.

Whichever family you pick, depth arrives as a stream whose layout and intrinsics decide how it becomes XYZ points — the aligned depth streams guide shows which matrix applies to which stream. Narrow the field with the 3D camera finder.

Worked example: pose and depth on the same wire

Take a modest depth configuration: 640 × 480 pixels, 16-bit depth, 30 fps. That is 640 × 480 × 2 B = 614,400 B per frame, and 614,400 × 30 = 18,432,000 B/s ≈ 18.4 MB/s ≈ 147 Mbit/s. The pose side, at 200 Hz and 28 B per sample, is 5,600 B/s ≈ 45 kbit/s. The depth stream outweighs pose by a factor of about 3,300, so bandwidth is never the reason to avoid a pose stream — and a pose stream never saves bandwidth.

Three checks before you order

1. Read the model's data sheet, not the SDK header. Pose needs a tracking module — an IMU plus a fusion engine — listed as hardware. A sheet promising depth, infrared and color image streams describes a camera with no pose output at any firmware version.
2. Enumerate what the device itself reports. After connecting, list the stream types the runtime reports as supported for that exact model. The depth camera SDK support check walks the full pre-buy routine.
3. Bench-test the demo unit. Enable the pose and depth streams together from a known device state — leftover settings are a classic source of flaky counts, as in start from a known state — then capture for ten seconds and count: a 200 Hz pose stream yields about 2,000 samples and a 30 fps depth stream about 300 frames. Zero pose samples means no tracking hardware; spec a tracking camera instead.

The decision, per case

The camera moves and the world is the map — handheld scanning, drone or AGV navigation, AR. Buy a tracking camera with pose in its supported streams, confirm it with the three checks above, and budget fusion work on your side: pose arrives in the tracker's own reference frame, and anchoring that frame to your world is the first engineering task after capture.

The camera is fixed and the part moves — the standard machine-vision cell. No pose stream is needed. One hand-eye transform plus the robot controller's joint data covers position, and the sensor is chosen by measurement type: point clouds for bin picking and volume, laser profiles for dimensional work, ToF for range at scale. The 2D or 3D camera decision for conveyor pick and place is the closest read for that choice. A cell that later puts the camera on a mobile base wants two cameras — a tracker for navigation, a depth sensor on the arm — not one compromise.

For a fixed cell, send the station sketch through the system configurator or write to us via the contact page with the part, the cycle rate and what moves. The 3D vision topic page collects the stream-level mechanics behind this one.