Your odometry camera went end-of-life, and the drone build now has a hole where a tracked pose used to come from. That module packed a stereo pair, an IMU and a tracking processor into one housing; the pipeline behind it can be rebuilt from parts you can still buy. This guide gives the numbers that drive the swap — stream bandwidth, frame rates, IMU sync, CPU headroom, storage — and works the arithmetic through one concrete configuration at 848×480 and 30 fps. It is written for UAV builders wiring visual-inertial odometry into a flight stack, and it ends with the bench checks to run before ordering and the cases where the split architecture is the wrong answer.
What replaces a discontinued tracking camera for drone vSLAM?
A stereo depth camera with an IMU plus an onboard controller running a third-party VIO stack replaces it: the camera streams rectified frames and depth, the controller computes the 6-DOF pose at the camera's frame rate, and the flight stack consumes that pose exactly as before.
The discontinued camera was three devices in one housing: two synchronized mono imagers, a MEMS IMU, and a dedicated processor solving visual-inertial odometry on board. It shipped a finished pose over USB, so the flight computer idled through the hard part. Production stopped; the architecture did not. Split the three functions across a depth camera, a synced IMU and an industrial controller, run the VIO software of your choice on the controller, and the pipeline works again. The industrial shelf covers two of the three parts directly: the 3D sensors category holds the depth cameras (finder at /shop/cameras/), and the vision controllers category holds the compute. What each function looks like after the split:
| Function | In the tracking camera | In the split replacement |
|---|---|---|
| Stereo imaging | internal mono pair | the depth camera's stereo pair |
| IMU | internal, factory-fused | separate module, pulse-synced to the camera |
| Odometry solver | on-module processor | your VIO stack on the controller |
| Output | finished pose | VIO pose republished in the same units |
| Flight-computer load | near zero | 1-2 cores at the camera frame rate |
How a VIO module is put together — sensor, lens and IMU — is laid out in VIO camera module components: sensor, lens and IMU choices.
Which numbers decide the replacement camera choice?
Four numbers decide it: global-shutter stereo frames at 30 fps or more, an IMU sampling at 200 Hz or faster, a hardware time-sync between camera and IMU, and a field of view near 90° — odometry runs on the wide grey pair, not on the depth map.
- Frame rate. 30 fps is the working baseline for odometry; a faster stream helps aggressive flight and costs CPU and bandwidth in direct proportion.
- IMU rate. The gyro and accelerometer fill the 33 ms between video frames, so VIO stacks expect 200-400 Hz from the IMU; a slow IMU shows up as drift in fast yaw.
- Sync. Camera and IMU need a shared clock; a free-running IMU drifts against frame timestamps, and the pose lags during rotation.
- Shutter. Global shutter, because a rolling shutter smears frames on a vibrating airframe and feature matching suffers.
- Field of view. Near 90° survives rotation and motion blur better than a narrow optic; narrow lenses lose the track in fast yaw.
IMU selection is a sub-project of its own; Global shutter camera IMU modules for fast motion tracking walks the module options.
How much onboard compute does the SLAM stack need?
Budget the stream first and the algorithm second: 848×480 stereo plus depth at 30 fps moves about 49 MB/s over USB 3, and a feature-based VIO stack needs at least one full core of a low-power controller at that rate, with the rest left for flight control and logging.
Raising resolution taxes the CPU in proportion to the pixels: 848 × 480 × 30 fps = 12.2 Mpix/s, while 1,280 × 720 × 30 fps = 27.6 Mpix/s, a 2.3× jump, and feature-based odometry cost tracks pixel count. Run odometry at 848×480 or 640×480 (9.2 Mpix/s at 30 fps) and spend the headroom on flight control, logging and obstacle depth.
Can a depth camera and a separate IMU still deliver a tight pose?
Yes, when camera and IMU share a clock and a measured extrinsic: sync both on one hardware pulse, hand the VIO stack the camera-to-IMU rotation and translation, and the pose stays good to the camera frame interval — about 33 ms at 30 fps.
The discontinued module fused its sensors in the factory; your stack now does the fusion, and two set-ups decide whether the result is as tight. Timing first: a free-running IMU drifts against frame timestamps, and the error peaks in fast rotation. Syncing both devices on one external pulse is the documented fix — Sync a depth camera and a third-party camera on one external pulse shows the wiring and the wait for lock.
Extrinsics second: where the module ships with factory camera-to-IMU values, use them; otherwise calibrate your own and keep the values with the rig. The trade between factory defaults and your own calibration is covered in Camera-IMU extrinsics: factory defaults versus your own calibration. The initial pose your estimator needs on a self-built rig is set out in Stereo SLAM initial camera pose: what to supply for your own rig.
Which vision controller runs VIO onboard a drone?
Take the lowest-power controller that leaves a core free after VIO: an Intel N-series box with 8 GB carries odometry, the bridge and logging on a small UAV; a 12th-generation Core i5 with 32 GB earns its payload only when you add detection or 3D mapping.
x86 keeps the VIO stack portable from bench to airframe, a LAN port talks to the flight computer, and USB 3 takes the camera. Passive cooling matters on an airframe: there is no fan to clog or shake apart. The category, with the finder:
Vision computers and fanless industrial PCs
190 models · from $1,119.00The small-airframe pick:
- LAN ports
- 3-4 LAN ports
- USB 3 ports
- 2 USB 3 ports
- Light outputs
- 4 built-in channels
- Memory
- 8 GB
The MV-VC2140-128G40-1T pairs an Intel N97 with 8 GB of RAM, a 128 GB SSD and a 1 TB HDD. Two USB 3 ports take camera and IMU, three to four LAN ports link the flight computer, and the 4 built-in light channels simply sit idle in the air.
When the airframe also carries detection or a mapping payload, the step-up:
- LAN ports
- 5+ LAN ports
- USB 3 ports
- 3-4 USB 3 ports
- PoE
- PoE camera ports
- Light outputs
- 8 built-in channels
The MV-VC5525-256G70-NN moves up to a 12th-generation Core i5 with 32 GB of RAM and a 256 GB SSD, with PoE camera ports and 8 built-in light channels. It is the bench-and-heavy-airframe class: more than a 250-class quadcopter needs, about right for a mapping octocopter or a rover.
What changes in your flight-stack software?
The pose source moves from the camera SDK to your VIO node: republish the VIO output under the pose format your bridge already parses, in meters and quaternion, and the flight controller sees one continuous estimate with no retuning.
Keep the message names, coordinate frames and units your bridge already consumed, and point them at the estimator's output; the flight side never knows the hardware changed. The error class you will meet in the SLAM configuration is a mismatched intrinsics type — Monocular vSLAM error: fix the loop closure intrinsics type shows the failure and the fix, and the same check applies to stereo parameter blocks. When odometry and obstacle depth share one camera, the stream doubles and the CPU bill follows it; 2D and 3D capture strategy: combine or split RGB and point cloud helps you decide whether to combine or split the capture.
Splitting is the leaner answer here: odometry on the stereo pair, dense obstacle depth on a second sensor. A ToF camera fills that role:
- Type
- Depth / ToF camera
The MV-DT01WMU is a ToF sensing camera: it supplies the dense depth map for obstacle sensing while the stereo pair drives odometry. Two sensors, two streams, each sized for its own job.
What do you check before you order?
Recompute the stream for the camera you actually picked, measure a free core on the bench before the first flight, and size storage from the stream: at the example settings, 49 MB/s writes about 29 GB per 10-minute flight.
- Stream arithmetic. width × height × bytes per pixel × fps × streams; compare the result with USB 3's 5 Gbit/s and keep at least 2× headroom.
- CPU, measured. Run the VIO stack at the target frame rate on the bench and read the core usage; one core must stay free for the flight stack.
- IMU sync. Confirm the pulse path exists on both devices before you design the mount; re-plumbing sync after integration costs a teardown.
- Power. A sagging rail shows up as dropped frames first, and the USB port budget is the usual suspect: Depth camera detected but no image: check USB power budget first, then Depth camera stream read errors on a drone: power and link checks for the airframe-specific checks.
- Thermal. Depth range falls as the sensor heats on a sunlit airframe; the derating fixes are in 3D camera range drops when hot: thermal derating fixes.
- Mounting. Camera and IMU must move as one rigid body; a soft mount invalidates the extrinsics you calibrated.
When is the camera-plus-controller split the wrong replacement?
When nothing onboard can carry the compute: if the flight controller alone must produce the pose, no depth camera fixes that, and the honest alternatives are optical flow, GNSS-compass fusion outdoors, or motion capture indoors.
The second case is pose rate. A video-rate estimator refreshes the pose at 30 Hz, and the flight controller's inner loop is inertial anyway; if you need centimeter-grade pose updates in hard real time above that rate, you are specifying a dedicated navigation unit, not a camera swap. For the space between — a payload budget of a few hundred grams and USB 3 on the companion computer — the split architecture is the direct replacement.
Where do you start the swap?
Start on the bench: point the VIO stack at recorded streams, measure the CPU it consumes at your frame rate, then order the controller that fits that measurement and the camera whose stream arithmetic you have already run.
Once the bench numbers exist, a quote request listing the camera, the controller and the target frame rate gets the configuration checked, and the contact page reaches the applications team for layout and mounting questions. The rest of the depth-camera practice, from capture strategy to thermal derating, sits on the 3D topic page.
Questions
How many flights fit on the example controller's storage?
At 49 MB/s, a 10-minute flight writes 29.4 GB (49 MB/s × 600 s). The 128 GB SSD in the example build therefore holds about four flights (128 ÷ 29.4 ≈ 4.4). The 1 TB HDD extends raw logging to roughly 5.7 hours (1,000,000 MB ÷ 48.8 MB/s ≈ 20,400 s), and logging poses plus decimated depth instead of full frames stretches that roughly tenfold.
Can odometry run on the depth map instead of the raw stereo pair?
Some RGB-D odometry stacks accept it, but expect a step down in accuracy: depth maps quantize the scene at the sensor's depth resolution and drop textureless regions where stereo still finds features. Feature-based VIO on the grey pair is the standard for flight, so treat depth as the output for obstacle sensing and mapping, and keep both grey frames in the stream for odometry.
Does PoE on a vision controller help a drone build?
Not in the air. PoE's benefit is delivering power to the camera over the LAN cable, but on a UAV every watt passes through the flight battery anyway, and the PoE path adds a conversion stage. Short USB 3 runs for the camera and plain LAN to the flight computer are the leaner wiring; the PoE ports on the step-up controller come into their own on the bench rig or a ground robot.
What pose rate should reach the flight controller?
The camera's frame rate — 30 Hz in the worked example — is enough: the flight controller fuses it with its own inertial data, which runs far faster, so the pose acts as a position correction rather than the inner loop. If your guidance code wants updates between frames, interpolate with the IMU samples instead of pushing the camera to 60 fps, which would double both the CPU bill and the stream.
Do you still need the old camera's SDK after the swap?
Only as a format reference. Keep the pose message names, units and coordinate frames your bridge already parsed — position in meters, orientation as a quaternion — and feed them from the VIO node instead. The vendor runtime itself can be deleted, which is the point of the swap: the estimator now runs on hardware and software you can still source in a year.