Camera fps for fast object tracking in a robot game

You are building a table-hockey robot game: a camera watches the puck, and motorised figures — five players and a goalie — have to answer it. The one number that decides the camera budget is frame rate. Buy too little and the puck teleports between frames; buy a 1000 fps research camera and you pay for a link that cannot carry it. This guide fixes the number from physics: puck speed divided by the displacement you tolerate per frame, then exposure, shutter type, link bandwidth, and the split between vision controller and motion controller. You finish with a frame rate to order against, a lens, a strobe width and a parts list.

The frame rate to commit to

Commit to 250 fps for a full-speed puck, read by a global-shutter camera through a windowed region of interest, frozen with a 50 µs strobe. The number is arithmetic, not preference: at 10 m/s a puck travels 40 mm per frame at 250 fps, which keeps it inside a 200 mm search window with margin for prediction error while the figures move on the same table.

Standard inspection work runs 60-120 fps and specialised fast-motion work several hundred; a struck puck belongs in the second group. Scale the commit to your own top speed:

A 60 fps camera holds the 40 mm budget only below 2.4 m/s, because 60 × 40 mm = 2.4 m of travel per second. A 5 m/s table commits to 125 fps. Above 20 m/s you are into 500 fps-class hardware, and the link choice that goes with it.

The displacement rule that sets it

Pick the displacement budget from the tracking job, not from the camera. A 200 mm window — about three puck diameters — is large enough that figure motion and lighting changes cannot push the puck out of it in one step, and 40 mm per frame is 20% of that window, so a predicted search always contains the puck. People-tracking systems accept 25 fps for a 2 m/s walker because that is 80 mm per frame and nothing else in the scene looks like a walker; a shared table is harsher, which is why the budget tightens. The same speed-to-rate arithmetic drives camera fps and shutter speed on moving webs, where the product sets the rate instead of the puck.

Velocity quality follows from the same numbers. At 250 fps the step is 4 ms; ±0.5 px of centroid noise (±0.4 mm at the scale worked out below) on both ends of the step leaves a speed error near ±0.15 m/s, under 2% of 10 m/s. That is accurate enough to lead a goalie, which is the whole point of the measurement.

Exposure: freeze the puck before counting frames

Frame rate bounds how far the puck jumps between frames; exposure bounds how far it smears inside one frame. At the 0.86 mm per pixel scale worked out below, one pixel of blur allows:

Commit to a 50 µs strobe: smear = 10,000 mm/s × 50 µs = 0.5 mm, about 0.6 px, so the disc stays round and the centroid stays honest. At 250 Hz the duty cycle is 50 µs × 250 = 1.25%, and at that duty an LED strobe runs at roughly ten times its continuous current — how a short pulse buys brightness a continuous flood light cannot match thermally. Exposure time versus shutter speed carries the same rule for slower parts, and line scan light power covers how much light a fast exposure really demands.

Drive the strobe from a light channel on the vision controller, triggered by the camera's exposure-active signal, so every flash lands inside the exposure window.

Global shutter, or the geometry lies

A rolling shutter exposes rows in sequence, so the puck sits in a different place in every row. Shear = readout time × speed. A 60 fps full-frame rolling readout spans about 16.7 ms, and 10,000 mm/s × 16.7 ms = 167 mm of distortion from top row to bottom row — a fifth of the table. Even a 1 ms rolling readout shears the puck 10 mm, about 12 px, enough to bias the centroid and every velocity computed from it. Global shutter, full stop; the global versus rolling shutter comparison works the same choice for moving targets generally.

Bandwidth: getting 250 fps out of the camera

Mono8 is 1 byte per pixel. The windowed tracker from the worked example: 512 × 512 × 1 B × 250 fps = 65.5 MB/s, about 0.52 Gbps, which is 66% of the ~100 MB/s usable payload of a GigE link (125 MB/s raw). Size any link at 80% of usable payload or less. Full frames tell a different story: 2448 × 2048 × 1 B = 5.0 MB, and 5.0 MB × 250 fps = 1.25 GB/s — past the ~1.0 GB/s a 10GigE link delivers, so full-frame 250 fps moves to CoaXPress (about 1.2 GB/s per CXP-12 link, four links near 4.8 GB/s) or an XoF frame grabber. The GigE Vision frame-rate budget and the per-camera USB3 bandwidth budget run this arithmetic per link; cropping the region of interest is what makes the windowed rate possible at all.

Microcontroller or computer on the control side

The camera does not go on a microcontroller. An MCU has no GigE Vision or USB3 Vision stack, no SDK to unpack the stream, and cannot sink 65 MB/s of images; even a USB camera behind a microcontroller bridge drops frames at a tiny fraction of that rate. Put the camera on a vision controller with PoE camera ports, run the tracker there — blob, centroid and prediction are light work for an x86 core — and send puck position and velocity to the motion side once per 4 ms frame. The microcontroller or PLC keeps the motors.

Budget the loop in stages: exposure 50 µs (negligible), window readout on the order of 1 ms, transfer plus tracker about one frame, then the command to the actuator. Two frames end to end — 8 ms at 250 fps, 80 mm of puck travel — is the working target; the goalie must lead the puck, not chase it. The image based control latency budget splits the same loop stage by stage, closing a 4 ms EtherCAT cycle against 500 fps frames is ordinary PLC work once vision delivers on time, and acquisition outrunning processing is the failure mode when the tracker cannot hold 250 Hz.

Worked example: a 10 m/s puck on a 2 × 1 m table

Inputs, each with its origin:

• Playfield 2.0 m × 1.0 m, camera on axis overhead — a full-size table.
• Puck 60 mm diameter, top speed 10 m/s — a hard-struck puck; measure yours from two frames and scale.
• Search window 200 mm; travel budget 40 mm per frame.
• Sensor: 1/1.8" 5 MP class, 2448 × 2048 px, 3.45 µm pitch, 8.45 × 7.07 mm active area — a common machine-vision format.
• Working distance 1.5 m above the playfield; Mono8 at 1 byte per pixel.

1. Frame rate: 10,000 mm/s ÷ 40 mm = 250 fps, frame period 1 ÷ 250 = 4 ms. Cross-check: the puck crosses the table in 2000 ÷ 10,000 = 0.2 s, so you get 50 frames per crossing.
2. Lens: magnification m = sensor width ÷ field of view = 8.45 ÷ 2000 = 0.0042. Focal length f = WD × m ÷ (1 + m) = 1500 × 0.0042 ÷ 1.0042 = 6.3 mm, so fit a 6 mm C-mount lens. Check the fit: with 6 mm mounted, m = 6 ÷ (1500 − 6) = 0.0040, field of view = 8.45 ÷ 0.0040 = 2100 mm by 7.07 ÷ 0.0040 = 1760 mm. The 2000 × 1000 mm playfield sits inside with margin.

3. Scale: 2100 mm ÷ 2448 px = 0.86 mm per pixel; the 60 mm puck spans 60 ÷ 0.86 = 70 px, ample for a centroid.
4. Depth of field at f/2.8 with a 2 px blur circle (6.9 µm): DOF = 2 × 2.8 × 0.0069 × (1 + 0.0040) ÷ 0.0040² = 2.4 m. Puck and rods are both in focus; there is no focus staging to automate.
5. Exposure: ceiling 86 µs from step arithmetic above; commit the 50 µs strobe (0.5 mm smear, 0.6 px) at 1.25% duty.
6. Readout and link: window the sensor to 512 × 512 px — 512 × 0.86 = 440 mm at the table, twice the search window — and let the window follow the prediction. Data rate 512 × 512 × 1 B × 250 fps = 65.5 MB/s, 66% of GigE's usable payload. Full frames on the same link give 100 ÷ 5.0 = 20 fps for the figures and for re-acquisition after a lost track.
7. Decision: order against 250 fps global shutter with windowed readout over GigE, a 6 mm f/2.8 lens at 1.5 m, and a 50 µs strobe at 250 Hz. The trigger to leave GigE is full-frame rate: above 1.0 GB/s (5.0 MB from about 200 fps upward), budget CoaXPress or XoF instead.

Swap your measured table width, puck diameter and top speed into the same seven steps; every other number follows.

Parts that carry these numbers

Three global-shutter options from the area scan cameras range, small sensor to large:

All 3 share: Sensor type CMOS, global shutter; Exposure mode Off/Once/Continuous exposure mode; Certification CE, RoHS, KC; Mono/color Color. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

The MV-CU020-90GC is a 2.5 MP GigE camera on a 1/1.7" global-shutter sensor with a C-mount — the small-format end of the range. The MV-CH120-11UC carries a 12 MP 1.1" sensor over USB3 with a global shutter, for a bigger window or a second full-field camera. The MV-CH250-25TC-F-NF moves 25 MP over 10GigE from an APS-H global-shutter sensor behind an F-mount. When the arithmetic pushes you past Ethernet, the MV-CH250-90YC-M58S-NN sends 25 MP over CoaXPress CXP-12 from a 1.1" global-shutter sensor with an M58 mount.

For the full-frame CoaXPress or XoF route you want a grabber in the controller:

The MV-GS1104F-DF is a 4-port XoF frame grabber with an SFP+ slot and 40G of total supported bandwidth. The 1.25 GB/s of full-frame 250 fps sits far inside that figure.

A controller with PoE camera ports and built-in light channels keeps the wiring to one box:

The MV-VC5525-256G70-NN is a VC5000-class controller: a 12th-generation i5, 32 GB of memory, supported PCIe for a grabber, PoE camera ports and 8 built-in light channels for the strobe. More camera selection writing sits on the cameras topic page.

When the usual answer is wrong

• A 60 fps camera plus interpolation. Between frames the puck is unmeasured for 16.7 ms — 167 mm. A collision with a figure starts and ends inside one gap, and no filter recreates it.
• Buying 500 fps and running full frame. 5.0 MB × 500 fps = 2.5 GB/s. No common single link carries that; frame rate without a bandwidth plan buys a slideshow.
• A fast rolling-shutter camera. Speed does not fix shear — readout time does. One millisecond of rolling readout still shears a 10 m/s puck by 10 mm.
• Continuous light with a short exposure. A 50 µs exposure needs the same peak brightness whether the source is continuous or pulsed; only the strobe's 1.25% duty lets the LED deliver it.
• An event camera below its home ground. Per-pixel event sensors with microsecond latency win above roughly 30 m/s or on a vibrating mount; at 10 m/s on a fixed table, event based vision versus frame cameras comes out in favour of frames for simplicity and for measuring the puck's size.

Checks before ordering

• Global shutter, and the camera's frame rate at the window size you will run — not its full-frame figure.
• Exposure control reaching 50 µs or below, and a strobe output or controller light channel that pulses 50 µs at 250 Hz.
• Link budget: fps × window bytes at or under 80% of usable payload — GigE about 100 MB/s, 10GigE about 1.0 GB/s, CXP-12 about 1.2 GB/s per link.
• Lens focal length from your working distance and playfield, with the window covering the search region at your scale.
• PoE camera ports and light channels on the controller; a PCIe slot if a grabber goes in.
• Latency path from exposure to command at or under two frames — 8 ms at 250 fps.
• Strobe light mounted above the table, aimed down, never at eye level.

Next step: put your table's numbers through the camera configurator, compare models in the camera finder, or send the measurements to our applications desk and we will check the arithmetic with you.