A visual-inertial odometry module is a camera, an inertial sensor and just enough compute to fuse them into a pose stream. Every weakness in the output traces back to one of those three parts, so this guide commits to numbers rather than options: a sensor class, a focal length, an exposure cap, an IMU rate, a timestamp budget and a power budget, each with the arithmetic that produced it. It is written for engineers assembling such a module from catalog parts, and it ends with the order-time checks that stop a good design going wrong at the last step.
The parts list that works
The baseline module is a monochrome global-shutter board camera in the 1-2 MP class behind a wide M12 lens, a MEMS IMU on the same rigid board, and a low-power camera SoC that runs the odometry and ships pose instead of video. The worked example uses a 1280 × 800 sensor at 60 fps, a 94° horizontal field of view, a 0.8 ms exposure cap and a gyro at 400 Hz, with pose output at 15 Hz over USB or UART and peak power near 0.8 W.
| Component | Target for the example module | Why |
|---|---|---|
| Sensor | Mono, global shutter, 1280 × 800 | real pixel values, no rolling skew, light compute |
| Lens | M12, 2.1 mm focal length, 94° FOV | feature count versus distortion |
| Exposure | 0.8 ms cap | blur stays under 1 px at 90°/s |
| Frame rate | 60 fps | 20 px inter-frame motion at 90°/s |
| Gyro rate | 200 Hz minimum, 400 Hz in the example | samples between frames for interpolation |
| Camera-IMU sync | 100 μs or better | 0.12 px feature error at 90°/s |
| Power | 0.8 W peak | budget example later in this guide |
The sections below justify each row with its arithmetic, then name the catalog parts that meet the sensor row.
Sensor: monochrome, global shutter, small
Monochrome matters more than megapixels. A Bayer color sensor stores one color value per pixel and interpolates the rest, which softens exactly the corner points a tracker matches; the color filter array comparison shows the layout pixel by pixel. A mono sensor returns a true intensity at every pixel, and with no dye filters in the way roughly two to four times more photons reach the photodiode under the same lens. In a dim corridor that is the difference between tracking features and inventing them.
Global shutter matters because odometry assumes the frame describes one instant. A rolling sensor reads out over 5-10 ms typical for this class, and at a 90°/s turn that smears each frame across 90 × 0.005-0.010 s = 0.45-0.9°, which is 0.45-0.9° × 13.6 px/° = 6-12 px of direction-dependent skew on a 94° field. The global vs rolling shutter comparison works this through for moving targets; for a camera that is always moving, global shutter is the decision, and rolling shutter belongs on static inspection rigs.
Keep the resolution small on purpose. Angular resolution feeds the tracker: 1280 px across 94° gives 1280 / 94 = 13.6 px per degree. Doubling the pixel count doubles compute per frame and adds nothing to pose accuracy unless the lens resolves it, which wide M12 lenses rarely do. The board level camera selection guide covers the same trade for inspection machines.
The catalog part that anchors the worked example is the MV-CB016-10GM-M-W, a board camera you can hang on the same carrier board as the IMU.
The MV-CB016-10GM-M-W is a 1.6 MP monochrome global-shutter board camera with an IMX296 sensor, an M12 lens mount, a GigE interface and a 1/2.9-inch format.
- Sensor format
- 1/2.9"
- Lens mount
- M12
- Interface
- GigE
- Resolution
- Up to 3 MP
The worked arithmetic stays on the 1280 × 800 baseline; a larger sensor of the same format only tightens the pixel-per-degree figure. Order the variant without an IR-cut filter: odometry is grayscale work, so the filter only costs sensitivity, and if the route includes dark stretches you will want 850 nm illuminators, which the filter would block entirely. Cover-glass choice changes the spectral response too; cameras without sensor cover glass explains what to expect, and the IR LED and I2C proximity sensor guide shows how an illuminator hangs off the same board.
Lens: field of view first
The lens decision is field of view, not sharpness. More FOV puts more trackable features in every frame and keeps overlap between frames; less FOV reduces distortion and narrows the search. For indoor navigation the working range is 90-110° horizontal. W is sensor width and f is focal length, both in millimetres:
Worked example. A 1/2.9-inch sensor measures about 4.5 mm across (4:3 format). For a 90° horizontal FOV the focal length must be f = (4.5 mm / 2) / tan 45° = 2.25 mm. Standard M12 wide lenses come in 2.1 mm and 2.8 mm: the 2.1 mm gives FOV = 2 · atan(2.25 / 2.1) = 94°, and the 2.8 mm gives 2 · atan(2.25 / 2.8) = 77.5°. Decision: 2.1 mm for a corridor-and-rooms navigation module; 2.8 mm when the scene sits within a couple of metres and you want gentler distortion. Check the arithmetic in the lens focal length calculator:
Two lens details decide whether the geometry survives. First, the image circle must cover the sensor: a 1/2.9-inch format needs about a 5.5 mm circle, and an M12 lens rated for a smaller format vignettes the corners where features live. Second, wide lenses bend straight lines, so the odometry backend needs a calibrated distortion model; the M12 lens selection guide covers format matching and IR-cut together.
Exposure: keep blur under one pixel
A feature tracker matches corners, and corners lose precision once motion blur passes about one pixel. Blur is spin rate times exposure, converted through angular resolution:
The example module resolves 13.6 px per degree. At a 90°/s robot turn, a 2 ms exposure smears 90 × 0.002 × 13.6 = 2.4 px, too soft for reliable corner matching. A 0.8 ms cap gives 90 × 0.0008 × 13.6 = 1.0 px. Decision: hold exposure at 0.8 ms for spin rates up to 90°/s; at 30°/s you can relax to 2.4 ms.
Two consequences follow. At 60 fps the frame period is 16.7 ms, so a 0.8 ms exposure means running the sensor gain up; VIO tolerates gain noise far better than blur, so take the gain. And inter-frame motion is 90°/s ÷ 60 fps = 1.5° per frame, which is 1.5 × 13.6 = 20 px; the gyro prediction absorbs that so the feature search window stays near ±10 px. Visual odometry with sparse features covers validating that prediction against real logs.
IMU: rate, range and mounting
Run the gyro at 200 Hz minimum; 400 Hz where the part offers it costs little and smooths interpolation. At 60 fps each camera frame spans 16.7 ms, so 200 Hz yields three or more gyro samples per frame, enough to integrate rotation between exposures. Set the accelerometer to at least 200 Hz as well; ±4 g range suits a fixed robot, while ±8 to ±16 g survives handling and vehicle knocks at the cost of noise.
Mount the IMU rigidly, within roughly 10 mm of the sensor, with axes aligned to the camera frame so the camera-to-IMU rotation starts near identity. Estimate the residual transform once during calibration and fix it in firmware. Global shutter camera IMU modules covers parts that package the two sensors together, and an angle sensor design built around an accelerometer and an MCU shows the compact wiring end of the same problem.
Syncing camera and IMU
Clock offset between camera and IMU turns into fake rotation. During a 90°/s turn, 1 ms of timestamp error is 0.001 × 90 = 0.09° of unmodelled rotation, which is 0.09 × 13.6 = 1.2 px of feature misalignment feeding the filter every frame. Budget 100 μs or better and the same error drops to 0.12 px, below anything the tracker can see.
Do it in hardware. Trigger the camera exposure from the IMU's data-ready interrupt, or from the same MCU timer that latches the IMU sample, and timestamp the camera's flash output edge on that clock as the true exposure instant. The camera GPIO wiring guide covers protecting and triaging those lines, and the IMU timestamp diagnosis guide shows what clock jumps do to long recordings.
Fusion itself is bookkeeping once the timestamps are right: implementing a Kalman filter for IMU and camera fusion walks the predict-update structure these measurements feed.
Compute, power and the output
Ship pose, not video. The image stream stays on the module: 1280 × 800 × 60 fps × 1 byte = 61.4 MB/s, which a camera SoC's sensor interface and on-board memory handle without effort, and which stays well under the roughly 118 MB/s a GigE link carries if the sensor streams out for development. The product is the pose packet: position, velocity, orientation and status, about 64 bytes × 15 Hz = 960 B/s, over USB or UART.
The power budget that makes the module self-contained: SoC at 0.45 W, sensor and analog front end at 0.25 W, IMU at 0.005 W, memory and flash at 0.10 W. Peak is 0.45 + 0.25 + 0.005 + 0.10 = 0.81 W, matching the 0.8 W design target with a small margin. Measure peak on the assembled board, not the average.
For vetting boards against this list, the board camera evaluation checklist transfers directly: same sensor parameters, same bring-up discipline.
Buy the camera or build the board
You can design the carrier board, or order a board camera and spend the effort on the IMU and firmware. The board-level cameras category is the shelf this guide picks from, and the camera finder filters the range by shutter, mount and interface.
Where turns run hotter than the example, the LS-BCM-0003 lifts the ceiling: 3.1 MP, IMX252, 1/1.8-inch global shutter, 120 fps over USB3, C-mount.
- Sensor format
- 1/1.8"
- Lens mount
- C-mount
- Interface
- USB3
- Resolution
- 5 MP
For metric scale from a standstill, stereo shortens the wait. The LS-BCM-0043 is a binocular M12 board camera with global shutter, USB3 and 1/2-inch-format sensors. Its 1280 × 1024 output at 123 fps gives you headroom to run stereo odometry well above the 60 fps of the worked example.
- Sensor format
- 1/2"
- Lens mount
- M12
- Interface
- USB3
- Resolution
- Up to 3 MP
When this design is the wrong answer
Feature-poor buildings break it first: long untextured corridors and racking painted one colour starve a camera-only tracker no matter how good the sensor is. The right part there is a depth device; the 2D or 3D camera comparison weighs that choice, and the 3D sensors category lists ToF and structured-light cameras that keep working with no corners in view.
Scale from a standstill is the second limit: single-camera VIO observes scale only while the module accelerates, so a robot that starts still begins with a distance-scaled guess. Stereo or a depth sensor removes the wait.
Airframe-class dynamics are the third. At 200°/s the 60 fps example needs a 0.35 ms exposure (200 × 0.00035 × 13.6 = 1.0 px) and tolerates 200 ÷ 60 × 13.6 = 45 px of inter-frame motion, and the IMU grade starts to matter more than the camera. Move the budget toward the gyro and the frame rate before touching the lens.
Checks before you order
- Order code: confirm the monochrome, global-shutter variant; suffixes differ between colour and mono, and between shutter types on otherwise identical boards.
- Filter path: no IR-cut filter on the sensor, and the cover-glass option you actually want.
- Lens: image circle at or above the sensor format, about 5.5 mm for 1/2.9-inch, with a distortion model available.
- Trigger and flash: both lines brought out on the board connector, not just on the sensor die.
- IMU: gyro rate 200 Hz or better, data-ready interrupt pin exposed on its header.
- Mechanics: IMU bolted to the camera board, not tethered.
- Power: budget is peak, measured on the assembled board.
Start with the camera configurator to match sensor, mount and interface in one pass, or browse the cameras topic page for the companion guides on shutters, sensors and lenses. If the route includes feature-poor stretches, bring the depth options into the same decision early.
Questions
Can a color board camera work for VIO?
It runs, but it tracks worse and sees less. Demosaicing invents two of three color values per pixel, softening the corners the matcher scores, and the dye layer leaves a mono sensor with roughly two to four times more photons under the same lens and exposure. Choose color only when landmark colors are themselves the features you track.
What gyro rate does a VIO module need?
200 Hz minimum, 400 Hz where the sensor offers it. A 60 fps camera leaves 16.7 ms between frames, so 200 Hz gives three or more gyro samples to integrate across each frame. Below about 100 Hz, interpolation error at robot spin rates grows past a pixel-equivalent and the filter starts lagging real turns.
How accurate must camera-to-IMU time sync be?
Target 100 μs or less, implemented in hardware. Every millisecond of offset during a 90°/s turn is about 1.2 px of feature error at a 94° field of view. If a prototype must software-timestamp first, keep both devices on one oscillator and estimate the residual offset offline by sweeping the scene and correlating gyro and image motion.
Is one camera plus an IMU enough, or do you need stereo?
One camera plus an IMU is the standard indoor navigation build; it recovers metric scale from acceleration while the module moves. It cannot observe scale while stationary, so the first poses after a standstill are directionally right but distance-scaled. Add stereo or a depth sensor if the application must report absolute size from the moment it powers on.
What resolution and frame rate are enough for indoor navigation?
One to two megapixels at 30-60 fps covers it. Angular resolution sets tracking quality: at 1280 pixels across a 94° field, a 90°/s spin moves features 20 px between 60 fps frames, which gyro prediction keeps inside a normal search window. Extra pixels mostly raise compute cost, and high-resolution rolling-shutter sensors actively damage the geometry.


