A depth camera plus an ARM single-board computer looks like the simplest route to 3D vision in a compact machine. The first question in every build thread is whether the SDK compiles. The question that decides the project arrives earlier: can the board's ports carry the stream, and can its cores or GPU process it. This guide gives you the numbers for both. You will compute the USB bandwidth a depth plus colour pair really needs, see why a 2.0-only board fails at useful settings, budget headroom on a 3.0 bus, and choose between a depth camera and a plain USB3 board camera for the task in front of you. The arithmetic takes five minutes and saves an order.
Will a 3D depth camera run on an ARM board at all?
The software side has been shown to work: the open-source SDK behind this class of depth cameras builds and runs on ARM Linux boards. The hardware decides first, because the example below needs 369 Mbps. A USB 3.0 port carries that; a USB 2.0 port does not.
That history tells you where to spend the afternoon. The ARM port of the SDK is not the barrier. The port wiring, the CPU load and the power budget are. Work the three budgets in that order — link, compute, power — and the feasibility question closes before you install a single package. The host-side picks then follow the guide to choosing an ARM board for USB3 camera acquisition. Once the hardware is settled, the 3D camera SDK on ARM compile fixes take over the build.
Depth cameras to feed from such a board:
- Type
- Depth / ToF camera
- Type
- Stereo / structured light
How much USB bandwidth does a depth plus colour stream need?
Add both streams with one formula, width × height × bytes per pixel × fps. The example pair is 640 × 480 depth at 2 bytes plus 640 × 480 colour at 3 bytes, at 30 fps. That totals 46.1 MB/s, or about 369 Mbps.
The 640 × 480 resolution, the 30 fps and the 2 and 3 bytes per pixel are illustrative inputs; substitute the width, height, bit depth and frame rate printed for your camera and the formula does the rest.
- Depth: 640 × 480 px × 2 B = 614,400 B per frame, × 30 fps = 18,432,000 B/s = 18.4 MB/s = 147 Mbps
- Colour: 640 × 480 px × 3 B = 921,600 B per frame, × 30 fps = 27,648,000 B/s = 27.6 MB/s = 221 Mbps
- Pair total: 46.1 MB/s = 369 Mbps
Multiply MB/s by eight for Mbps and keep both units in your notes: cameras quote frames and bytes, USB links quote bits. When more cameras join the cell, the per-camera USB3 bandwidth budget math extends this same table.
Can a USB 2.0 port carry that stream?
No. 369 Mbps is 77% of the 480 Mbps a USB 2.0 bus offers in theory, and the theoretical figure is a ceiling no real host reaches. A colour plus depth pair at these settings is out of budget before overhead and your own code are counted.
The paper numbers show what would have to shrink. A 320 × 240 pair at 30 fps needs 92 Mbps, 19% of the bus; a depth-only 640 × 480 stream at 30 fps needs 147 Mbps, 31%. Both fit on paper. The blocker is firmware, not arithmetic: this camera class is engineered around the 5 Gbps SuperSpeed link, and a 2.0 socket is not a reduced mode it falls back to. The device may enumerate, but the depth and colour pair does not stream, because shipping that mode would take dedicated firmware the product line does not carry. Plan a 2.0 port only for a camera specified to stream over 2.0.
| Link | Theoretical rate | Example pair (369 Mbps) |
|---|---|---|
| USB 2.0 port | 480 Mbps (60 MB/s) | 77% before overhead — no |
| GigE | 1,000 Mbps (125 MB/s) | 37% — fits where the camera has a network port |
| USB 3.0 port | 5,000 Mbps (625 MB/s) | 7% — fits with room to spare |
When a stream that ran on the bench starts timing out in the cell, the depth and colour stream timeout check covers the symptom side of this budget.
How much USB 3.0 headroom does an ARM board need?
Keep every camera on one USB 3.0 bus under about 70% of its 5 Gbps, which leaves roughly 3,500 Mbps. One example RGB-D pair takes 7% of that bus, so the same port also absorbs a second 3D camera at 15% or a stack of 2D streams.
The 70% figure is a planning rule of thumb, not a bus limit: bursts, retries and anything else on the controller consume the rest. Two cautions make the budget real. First, the budget belongs to the controller, not the plug — two sockets behind one internal hub share a single 5 Gbps upstream. Second, 5 Gbps is 10.4 times the 2.0 bus, which is why the pair that squeezed 2.0 disappears into 3.0. The USB hub frame-rate drop guide shows the shared-upstream failure in detail. The multi-camera USB bandwidth and power budget adds the current draw to the same table.
Which steps load the ARM cores hardest?
Colour unpacking and point-cloud generation dominate the CPU. The example stream turns 9.2 million depth pixels into 3D points every second, a 110 MB/s write of point data. Every colour frame also needs unpacking to RGB before fusing.
Each point carries three 4-byte floats, so 12 B: the example produces 9,216,000 points per second, which is 110 MB/s of point writes before your own code touches them. Unpacking the colour frames is a second full-bandwidth loop across the same pixels. This is why the SDK guidance for this camera class is to offload colour unpacking and point-cloud generation to a GPU even on boards that ship one. On a board without one, the same loops compete with your detection code for every core. The GPU point-cloud memory layout guide shows how the offloaded buffers should be shaped, and the point-cloud camera processing load diagnostics help when the stream stalls under load.
What can you do when the board only has USB 2.0?
Change the hardware rather than the stream: pick a board with a native USB 3.x controller, move the 2D cameras to GigE, or run depth only at a reduced rate. At 15 fps that needs about 74 Mbps of a 480 Mbps bus.
Ranked by cost: a carrier or SoC upgrade with a native 3.x controller is the only route that keeps the RGB-D pair at full rate. GigE moves the 2D views off the USB controller entirely. The MV-CB016-10GM-M-W is a compact GigE board camera built for exactly that role:
- Sensor format
- 1/2.9"
- Lens mount
- M12
- Interface
- GigE
- Resolution
- Up to 3 MP
Depth-only at 15 fps is the one configuration that fits a 2.0 port with margin: 74 Mbps is 15% of the bus, which suits a slow palletising or level-check cycle. One condition decides it — the camera must ship a 2.0 streaming mode, and much of this class does not.
How do you check a board's ports before you order the camera?
Read the SoC or carrier data sheet rather than the product photo. The number that decides the budget is how many connectors hang off a native USB 3.x host controller, not how many USB sockets the board has moulded onto it.
Work down the same four checks every time:
- Port speed from the SoC block diagram or the carrier schematic: 480 Mbps marks a 2.0 controller, 5 Gbps marks a 3.x controller.
- The controller behind each connector: a board can expose six sockets and still carry a single 5 Gbps upstream behind an internal hub.
- Power per port: the USB 3.0 specification sets a 900 mA unit load at 5 V, 4.5 W, against 2.5 W from a 2.0 port — structured-light depth cameras drive an IR projector on top of the sensor, and 2.5 W does not cover that draw.
- Host buffers last: once the ports check out, the Linux usbfs and file-limit tuning for USB3 Vision cameras is the usual next fix.
One symptom closes the port audit: a known-3.0 camera that enumerates at 480 Mbps has fallen back. The USB3 camera fallback troubleshooting guide walks cable, port and power causes in order.
When is a USB3 board camera the better ARM pick?
When one calibrated 2D view answers the question, a mono USB3 board camera needs about 147 Mbps at 640 × 480 and 60 fps against the RGB-D pair's 369 Mbps. It leaves the depth camera off the order entirely and keeps the ARM CPU free of point-cloud work.
Presence or absence, label position, a dimension in one calibrated plane, a pick offset from a single view — none of these needs a depth map, and the depth map from a single image: what it can measure article draws that line in detail. Height, volume, pose in clutter and anything partially hidden need the depth head and its 369 Mbps. Two USB3 board modules cover the 2D side. The LS-BCM-0003 is a 3.1 MP USB3 board camera with a global shutter, rated to 120 fps. The MV-CB060-10UM-B is a 6 MP USB3 mono module supplied as a bare board:
- Sensor format
- 1/1.8"
- Lens mount
- C-mount
- Sensor format
- 1/1.8"
- Interface
- USB3
Either module at 640 × 480, 8-bit mono and 60 fps runs about 147 Mbps, 3% of the 3.0 link, leaving the depth budget untouched. For mounts, interfaces and the rest of the module decision, the board-level camera selection guide for embedded vision machines continues from here.
Which combination should you order for an ARM cell?
Order an ARM board with at least one native USB 3.x port per depth camera. Budget each at roughly 370 Mbps of the 5 Gbps link, keep planned load under 70%, put point generation on a GPU where one exists, and move 2D views to GigE board cameras.
The decision per case:
- 2.0-only board and RGB-D required: change the board; the budget does not close on 480 Mbps.
- Native 3.0 port and a GPU: one depth pair per port, total planned load under 70%, point generation offloaded.
- Depth-only and a slow cycle: 15 fps at 74 Mbps runs on a 2.0 port with margin, when the camera ships that mode.
- Single-view 2D task: a mono USB3 board camera at roughly 3% of the link, no depth head on the order.
Start from the 3D sensors category to pick the depth head, filter the rest in the camera finder, or hand the resolution, frame rate and host to the camera configurator. The remaining integration pieces sit on the 3D vision topic and across the board-level cameras range.
Laser profilers and stereo 3D cameras
170 models · from $699.00Questions
How much data is one depth frame before any colour is added?
At the illustrative 640 × 480 setting with 16-bit depth, one frame is 640 × 480 × 2 B = 614,400 bytes, roughly 0.6 MB. At 30 fps that alone is 18.4 MB/s, or 147 Mbps. Halve the frame rate and the number halves with it, which makes per-frame arithmetic the quickest way to sanity-check any resolution or rate change.
Does OpenCV work with depth camera frames on an ARM board?
Yes. The SDK hands each frame to your process as an ordinary pixel buffer, and your code wraps that buffer in an OpenCV matrix as it would any image. The bandwidth and CPU budgets here get the buffer to you at full rate; OpenCV itself adds no transport cost.
Can a second depth camera share the same ARM board?
Yes, with one native 3.0 port each. Two example pairs take 738 Mbps, about 15% of a 5 Gbps controller and still under the 70% planning cap. Two pairs on a single 2.0 bus fail outright, because 738 Mbps exceeds the 480 Mbps link before overhead.
How much power does a depth camera draw from the board?
The USB 3.0 specification allows a 900 mA unit load at 5 V, 4.5 W per port, against 2.5 W from USB 2.0. Structured-light depth cameras run an active IR projector on top of the sensor, so prefer a 3.0 port, or the camera's own auxiliary power input where the model provides one.