Global shutter camera IMU modules for fast motion tracking

Track a platform that moves faster than walking pace and two camera choices stop being details: the shutter type, and how the IMU's samples relate to the frames. A rolling shutter reads the sensor line by line, so a fast image arrives skewed; a global shutter grabs every pixel at one instant, so each frame maps to a single moment you can match against the gyro. This guide gives you the numbers that decide it — readout skew, the exposure cap set by motion blur, and the bandwidth each interface really carries — then three concrete builds from the shop: board-level global shutter modules for a host-side rig, a vision sensor made for guided vehicles, and higher-resolution globals for inspection in motion. The worked example is a platform at 1 m/s; the calculators embedded below rescale it to yours.

When a global shutter and an IMU earn their place

Start from one number: how fast the image sweeps across the sensor, in pixels per millisecond. A rolling shutter exposes its first line, works down the frame, and finishes about one frame period later — 16.7 ms of readout at 60 fps. Any feature on the move is displaced by t_readout × v_image between the top of the frame and the bottom, so the tracker sees geometry that never existed: edges leaned, corners sheared, code rows bent.

Turn your position budget into a skew budget. If the tracker must place features to ±0.5 mm and the optics give 0.11 mm per pixel, you can afford 0.5 / 0.11 ≈ 4.5 px of skew, which at 60 fps means an image speed of 4.5 / 16.7 ≈ 0.27 px/ms. A platform at 1 m/s sweeps about 9 px/ms at that pixel size — more than thirty times the budget. That is the whole decision: global shutter, and spend the saved afternoon on lighting. The shutter theory behind this sits in Global vs rolling shutter sensors: choosing for moving targets; this page stays on selection and sync.

The IMU half is simpler to justify. Frames alone give position samples at frame rate; the gyro and accelerometer fill in rotation and everything that happened between frames. Fusion pays for itself the moment the platform rotates or the frame rate drops below the motion — both normal on a vehicle.

The skew number a rolling shutter charges you

Take a 720-line rolling sensor at 60 fps. Its last line finishes up to 16.7 ms after its first, and a feature crossing the sensor at 5 px/ms lands 5 × 16.7 ≈ 84 px displaced between top and bottom — on a 1440 px wide frame, nearly 6% of the image leaning for no physical reason. Exposure cannot fix this: a 50 µs flash freezes the light for every line but still cannot re-align the lines with each other.

Vibration produces the same artifact with zero net travel. A camera bolted near a running drive shows wobble or jelly on every frame, and the usual response — shorten the exposure — does not touch it. Shear that flips with the direction of travel, wobble that follows the machine's vibration: that is readout, not the part.

Exposure comes from velocity, not from brightness

Blur in pixels is velocity times exposure divided by pixel size. Set the blur budget — 1 px is a sensible default for tracking, 0.5 px for measurement — and the platform speed fixes the exposure ceiling. Brightness then has to come from aperture, strobe and gain, in that order.

Worked example: 1 m/s platform, 160 mm field

1. Sensor and field of view. A 1.6 MP-class sensor at 1440 × 1080 px, about 4.9 mm wide (1/2.9" class). Target FOV 160 mm at a 200 mm working distance: f ≈ 200 × 4.9 / 160 ≈ 6.1 mm, so a 6 mm M12 lens. The lens focal length calculator runs this either direction.
2. Pixel size on the object. s_px = 160 mm / 1440 px = 0.11 mm/px.
3. Exposure cap for 1 px of blur. t_exp ≤ 0.11 × 1 / 1000 = 0.11 ms. Set 100 µs; drop to 50 µs if the tracker wants 0.5 px.
4. Light budget. 100 µs integrates 16.7 / 0.1 ≈ 170× less light than a full 16.7 ms frame. Opening the lens from f/8 to f/2.8 returns (8 / 2.8)² ≈ 8×; the remaining ~20× comes from strobe output and gain.
5. Frame overlap. At 60 fps the platform travels 1000 / 60 ≈ 16.7 mm per frame, about 10% of the 160 mm field — 90% of the view repeats frame to frame, which is what corner and template matching wants. The matching side of that trade is covered in Visual odometry with sparse features: validate sensor fusion.

Rescale those five lines to your own speed and field — the resolution half is a two-field calculation:

One follow-up at the bench: confirm the exposure the camera reports matches the one you set, because auto modes will move it quietly — Per-frame exposure and gain: verifying camera metadata shows how to read it back per frame.

Syncing IMU samples to frames

Fusion holds only if both streams speak the same clock. Three things do it:

1. Frames stamped once, by you. Take timestamps from the driver or your grab callback on one host clock, never from file-write times.
2. A hardware pulse to anchor exposure. Latch a host timer or the IMU's sample index on the camera's strobe output, so every frame carries a known mid-exposure instant. If the camera only offers a trigger input, divide the IMU's data-ready line down to the frame rate and let it drive acquisition.
3. Rigid mounting, one transform. Bolt the IMU to the camera carrier, measure the offset once, and apply the IMU-to-optical-frame rotation as in IMU optical frame transform: verify depth camera IMU frames.

Free-running clocks drift apart faster than intuition suggests. Two crystals at a typical ±50 ppm separate by 50 ppm × 600 s = 30 ms over ten minutes — two full frame periods at 60 fps — which is why periodic re-sync or a shared trigger outranks raw IMU sample rate. The failure signatures and fixes live in Image timestamps out of order: frames and IMU data scramble and Camera IMU timestamp clock domains at lower frame rates.

Keep the residual offset near 1 ms and interpolation covers the rest: typical MEMS gyro modules sample 200-1000 Hz, so a 60 fps frame always sits between samples, and a 1 ms error at a 90°/s yaw rate costs 90 × 0.001 = 0.09° of attitude. Wire the trigger and strobe lines inside the camera's I/O ratings; Camera GPIO wiring: prevent damage and triage power faults covers levels and failure triage.

Three builds and what to buy for each

On a host-side build the camera stays deliberately dumb: it streams frames, your code owns timestamps and fusion. The board-level cameras category is where those modules live, and two cover the rate extremes:

The MV-CB016-10GM-M-W pairs an IMX296 mono sensor with an M12 mount and a GigE link. The LS-BCM-0003 takes the fast lane: 3.1 MP at 120 fps over USB3, behind a C-mount. Either board wants a compact host rather than a tower — an industrial mini PC is the usual carrier for the camera link, the IMU and the tracker.

For guidance work, keep the inspection on the device and hand positions to the PLC — that is the whole point of the smart cameras and vision sensors category. The AGV guide sensor is its purpose-made member:

The MV-SC2005AC-03WBN is a 0.5 MP colour guide sensor with a 3.4 mm M12 lens focused at 100 mm, global shutter over Fast Ethernet — built to ride on the vehicle while the IMU and odometry stay on the vehicle controller, which is where the fusion should run anyway.

When the job is real detail in motion — small text, fine defects — step up in resolution but keep the global shutter. Both of these are Fast Ethernet vision sensors with global shutters; the table shows what the resolution step changes:

All 2 share: Sensor type CMOS, global shutter; Pixel size 3.45 μm × 3.45 μm; Data interface Fast Ethernet (100 Mbit/s); Humidity 20% RH to 95% RH (no condensation); Client software SCMVS; Certification CE, KC. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

The MV-SC3050XC-16M-ATN-H carries 5 MP of colour on a 1/1.45" sensor; the HK-TD032-12-WBN keeps 1.6 MP of mono on a 1/2.9" sensor. More pixels mean a smaller pixel size at the same field, and the blur cap shortens with it — run the exposure formula again before committing.

Bandwidth: will the link carry the frame rate?

Work the stream budget before ordering, because the interface caps the frame rate harder than the sensor does. An 8-bit mono frame is one byte per pixel: 1.6 MP ≈ 1.6 MB, and at 60 fps that is 1.6 × 60 = 96 MB/s ≈ 768 Mbps, comfortably inside the roughly 950 Mbps a GigE link delivers in practice. Push the same sensor to 120 fps and it wants 1.54 Gbps — GigE is done.

USB3 offers roughly 3.2 Gbps of usable payload. The 120 fps route above runs 3.1 MP × 120 = 372 MB/s ≈ 3.0 Gbps, which fits with thin margin: stream 8-bit mono, and keep ROI cropping in reserve — Camera ROI cropping at the source: reduce bandwidth before the host shows the levers. If the camera delivers raw Bayer, colour still costs one byte per pixel like mono; decoded RGB triples the count.

When the usual answer is wrong

• Slow belts. Below the ~0.3 px/ms budget from the first section, rolling shutter plus a short exposure is the correct, cheaper answer — spend the difference on optics.
• Extreme speed. When 1 px of blur needs under 10 µs — 10 m/s past a 0.11 mm pixel — no exposure rescues a frame camera alone: add a strobe that freezes the motion, or move the geometry to line scan with an encoder.
• Frames stop helping. At angular rates where features vanish between frames, leave frame cameras behind; Event based vision vs frame cameras for fast motion covers that trade.
• Geometry, not position. Heights, volumes and dents need depth, not a faster 2D shutter — the 3D sensors category starts at laser profilers and stereo.
• Vibration without travel. Zero net speed, pure wobble: global shutter still wins, for the readout reasons above.

Checks before you order

• Shutter reads Global on the exact model page, not just the series; the camera finder filters Shutter: Global directly.
• Trigger input and strobe output exist on the I/O connector for the sync plan you drew.
• Frame rate × pixel count × bytes per pixel sits inside the interface budget from the bandwidth section.
• Mono 8-bit streaming is available at the target rate; colour only if hue carries the feature.
• Lens mount matches the optics (M12 versus C-mount), and the field-of-view and focal-length numbers come from the calculators, not from hope.
• Light plan covers the 100 µs-class exposure: strobe with a suitable controller, or continuous output bright enough at that duty.
• IMU rigid to the camera, transform measured, trigger wiring inside the I/O ratings.

That is the decision set: shutter from image speed, exposure from the blur cap, interface from the stream budget, sync from a trigger you own. More on moving targets sits on the cameras topic page. Put your speed, field and rate into the configurator and it filters to the cameras that survive the arithmetic:

If the platform is unusual — outrigger kinematics, washdown, a moving arm — contact us with the speed and field numbers and we will work the budget with you.