A collaborative robot that stops in an odd configuration leaves you one question: how did it get there? A camera that records every shift continuously answers it, and it takes neither a high-speed camera nor a monitoring subscription. This guide sizes the recorder with three numbers: 15-30 frames per second for a slow fault, 8.1-16.2 GB per hour for a 12 MP H.264 stream, and 0.026 mm per pixel for a 100 mm macro window. It is written for the manufacturing or integration engineer who keeps re-running a fault nobody saw. You will leave with a frame-rate rule, the drive size to order, a two-camera layout with one clock, and exposure settings that keep the pixels readable.
Frame rate: 30 fps is enough for a slow fault
The fault you are replaying unfolds over seconds, not milliseconds. A cobot in collaborative mode moves its flange at a few hundred millimeters per second; plan on 250 mm/s. At 30 fps the frames are 33 ms apart, so the flange covers 250 ÷ 30 ≈ 8 mm between frames. At 15 fps it covers about 17 mm, and at 60 fps about 4 mm. Eight millimeters of travel per frame is enough to watch a deviation develop and see which axis moved first.
Commit to a rule: frames per second = approach speed ÷ tolerated travel per frame. At 250 mm/s with a 10 mm budget you need 25 fps, so a 30 fps recorder carries margin. Drop the overview camera to 15 fps when only the end position matters. Playback stretches too: stepping 30 fps footage at 10 fps turns one second of motion into three, which is usually slow enough to read the sequence.
Storage: three multiplications size the drive
Every storage figure comes from one formula:
The 0.45 factor converts bits to bytes across an hour: × 3600 s ÷ 8 ÷ 1000. Bits per pixel (bpp) is the only judgment in the chain. Surveillance-grade H.264 on a moderate-motion scene lands at 0.05-0.1 bpp at 4K-class resolutions; budget with 0.1 and treat 0.05 as the reward for a calm scene. H.265 roughly halves either figure.
The relationship is linear, so double the frame rate doubles the gigabytes, and each extra camera adds its own stream at its own rate. You can also pin the rate at the camera instead of the recorder: GigE timed acquisition controls frame rate and bit depth from the camera side, which fixes the storage number before the first byte lands.
Worked example: a 12 MP camera over one 8-hour shift
Take a 4000 × 3000 sensor recording H.264 at 30 fps:
- Pixels per frame: 4000 × 3000 = 12,000,000
- Bit rate: 12,000,000 × 30 × 0.1 = 36 Mbit/s; at 0.05, 18 Mbit/s
- Storage: 36 × 0.45 = 16.2 GB per hour; 18 × 0.45 = 8.1 GB per hour
- One 8-hour shift: 65-130 GB
- A 1 TB drive with about 900 GB usable holds 900 ÷ 16.2 ≈ 55 hours at the high setting and 900 ÷ 8.1 ≈ 111 hours at the low one
Two cameras change the total, not the method. Wide overview at 15 fps: 4.1-8.1 GB per hour. Near camera at 30 fps: 8.1-16.2 GB per hour. Together that is 292-583 GB per day, call it 300-600. The worst case burns 24.3 GB/h × 72 h = 1.75 TB, so a 2 TB drive with 1.8 TB usable is exactly a 72-hour rolling buffer for the pair. A 4 TB drive holds six to twelve days of the pair. Order 2 TB for fault replay; order 4 TB when you want shift history.
- Sensor format
- 1/1.7"
- Interface
- USB3
- Resolution
- 12 MP
- Shutter
- Rolling
The LS-CMR-0166 records 4000 × 3000 at 30 fps over USB3, with IMX226 pixels on a 1/1.7-inch rolling-shutter sensor; the lens you fit sets the window. Raw capture is the trap: a 12 MP Bayer stream at 30 fps runs 12,000,000 × 30 × 8 = 2.88 Gbit/s, about 1.3 TB per hour, which fills a 1 TB drive in under 45 minutes. USB3 carries roughly 3-4 Gbit/s of payload in practice, so uncompressed 12 MP at 30 fps barely fits and stores terribly. Record H.264 for replay, and save raw clips of a few seconds when you need to measure off the pixels. Fitting several streams into one recorder is the same arithmetic; USB3 bandwidth planning for a multi-stream pipeline works it stream by stream.
Detail: pixels per millimeter decides the zoom
Detail is pixels per millimeter, not zoom level. A sensor N pixels wide across a window W millimeters wide resolves W ÷ N mm per pixel, and a feature needs about 3 pixels across to read with confidence.
| Window width | 1600 px sensor | 4000 px sensor | Smallest readable feature (4000 px) |
|---|---|---|---|
| 102 mm (4 in) | 0.064 mm/px | 0.026 mm/px | ~0.08 mm |
| 300 mm | 0.19 mm/px | 0.075 mm/px | ~0.23 mm |
| 1830 mm (6 ft) | 1.14 mm/px | 0.46 mm/px | ~1.4 mm |
The 1830 mm overview at 0.46 mm/px shows arm pose, gripper open and close, and gross part position, but a 0.2 mm part shift is invisible there. The 102 mm macro window at 0.026 mm/px shows jaw gaps, label edges and shifts of a few hundredths of a millimeter. Digital zoom cannot rescue the overview: a 4× zoom crops 4000 pixels to 1000, which is 1.8 mm per pixel, worse than aiming a second camera at the spot.
Size the near window from the smallest thing you must see. Needed resolution is feature ÷ 3, and window width is sensor pixels × that value. Watching a 0.1 mm shift on a 4000-pixel sensor needs 0.033 mm/px, so keep the window under 4000 × 0.033 ≈ 133 mm. The camera resolution calculator runs the same check from window to pixels.
Where the near view sits in a cramped spot, a board-level module carries the sensor in without a full camera body; the board-level cameras category lists M12 and C-mount modules on GigE and USB3.
The set-up that finds faults: two cameras and one clock
The layout integrators converge on is one wide camera over the cell and one tight camera on the most common failure point, both recording continuously against a single clock. When the controller faults at 14:32:07.4, you open both recordings at that timestamp: the wide view shows which approach led in, and the near view shows what the gripper and part did at that moment.
Three habits keep the pair useful:
- Run cameras, recorder and controller log from one NTP source, so a fault timestamp lands within half a frame, 17 ms at 30 fps.
- Store each frame's device timestamp beside the video, and measure the delivered rate from those timestamps; encoders drop frames silently.
- Export the two minutes before and thirty seconds after every fault to a permanent folder, and let the rest roll off the buffer.
For a timeline beyond video, pair the footage with the controller's own signals: recording robot-cell cycle times from PLC I/O turns "it moved oddly" into a sequence you can replay against the log.
On hardware, a 12 MP GigE stream at 9 fps runs 12,000,000 × 9 × 8 = 864 Mbit/s raw, close to the 1 Gbit/s link rate, so give each GigE camera its own interface or record compressed. The 9 fps overview still tracks a 250 mm/s arm in 28 mm steps (250 ÷ 9), enough to reconstruct pose; keep 30 fps on the near camera where the fine motion happens. The pair below covers both ends, and a small acquisition script is enough to drive them: recording video from a machine-vision camera in Python shows the capture side.
- Sensor format
- 1/1.7"
- Lens mount
- C-mount
- Sensor format
- 1/2.9"
- Lens mount
- M12
When 30 fps is not enough
Gravity ignores the robot's speed limit. A part that slips and falls 200 mm lands in √(2 × 0.2 ÷ 9.81) = 0.20 s, hitting at √(2 × 9.81 × 0.2) ≈ 2 m/s. At 30 fps that is six frames of fall and 66 mm of travel per frame at impact: you will see that it fell, not how. Spring returns and ejections behave the same way.
For those events record 120 fps, about 24 frames over the same fall, and budget four times the storage: 12 MP at 120 fps and 0.1 bpp is 144 Mbit/s, or 64.8 GB per hour. Fast motion also exposes rolling shutter, which reads the sensor row by row and skews anything crossing the frame quickly. If the event crosses the view in under 50 ms, put a global-shutter camera on that view.
- Sensor format
- 1.1"
- Lens mount
- C-mount
- Interface
- USB3
- Resolution
- 12 MP
The MV-CH120-11UC is the high-speed 12 MP USB3 option with a global shutter, for any view where the motion snaps. The same three multiplications scale to the extreme case: planning data rates for 2000 fps recording runs the identical math at terabytes per hour.
Machine-vision camera, security camera or action camera
An action camera taped to the frame records, and for a one-off investigation that is fine. As a fixture it falls short: the lens is fixed, a battery and a small body fight a 6-8 hour continuous run, and the clock drifts, so two of them never align frame to frame. Tape one on for the first look, then mount a real camera.
A consumer security kit records continuously to H.264 with wall-clock timestamps and remote access, which is most of the job. Its limits are a fixed field of view and a modest delivered frame rate, often 10-15 fps. If the camera has to migrate around the floor and cable runs are the problem, choosing a wireless camera for robot-cell viewing walks through that trade.
A machine-vision camera earns its place with four things: you choose the lens, so window and pixels per millimeter are design inputs; exposure sits at 0.1-2 ms so frames stay sharp under motion; frames carry device timestamps your recorder stores; and GigE spans 100 m to a recorder outside the cell. Pick from the area scan cameras. Where the recorder itself lives at the cell, a fanless industrial mini PC takes two streams in a housing the size of a book.
Mounting, exposure and light
Aim and repeatability come from the stand, not from luck. The LS-MNT-0040 slide-table stand carries the camera on a 700 mm column over a 400 × 450 mm base, which covers bench-side macro positions, and the camera stands category holds smaller brackets and tilt stages for tighter spots.
- Type
- Camera stands
Exposure sets sharpness, and the arithmetic is blur = speed × exposure time. At 250 mm/s, which is 0.25 mm per millisecond:
- Wide camera, one pixel of smear: 0.46 ÷ 0.25 ≈ 2 ms
- Near camera, one pixel of smear: 0.026 ÷ 0.25 ≈ 0.1 ms
- Near camera at 0.5 ms: 0.125 mm ≈ 5 pixels of smear, fine for replay, too soft for measuring
Set 1-2 ms on the wide view and 0.1-0.5 ms on the near view, then raise gain or add lighting when frames go dark; the lights finder sorts machine-vision lighting by type. The 30 fps cadence allows 33 ms exposures, but you will never use them on a moving arm.
Checks before you order
- Compute your own gigabytes per hour from your resolution, frame rate and 0.1 bpp: GB/h = Mbit/s × 0.45.
- Measure the delivered frame rate for an hour before trusting the plan.
- Size the near window against feature ÷ 3: a 0.1 mm feature needs 0.033 mm/px, so 133 mm or less on a 4000-pixel sensor.
- Put cameras, recorder and controller log on one NTP source.
- Set exposures at 1-2 ms wide and 0.1-0.5 ms near; add light if the frames are dark.
- Size the drive: 2 TB for a 72-hour two-camera buffer, 4 TB for six to twelve days of pair history.
- Mount both cameras out of the robot's reach.
- Trigger a dry fault, export the clip, and read the feature you sized the system for.
Next step
Size the two windows first and let the numbers pick the hardware: the camera finder filters area scan cameras by resolution, interface and shutter, and the camera configurator pairs lens and camera in one pass. For a quoted multi-camera cell, send the window sizes and shift length through the quote form and we will size the storage and interfaces with you. More set-up guides live on the applications topic page, and the applications team answers layout questions through the contact page.
Questions
How much storage does one 8-hour shift of robot cell video need?
A 12 MP (4000 × 3000) camera at 30 fps writes 16.2 GB per hour in H.264 at 0.1 bits per pixel, so budget about 130 GB per shift; a calm scene at 0.05 bpp needs 65 GB. For two cameras with the overview at 15 fps and the near view at 30 fps, plan on 300-600 GB per day, which a 2 TB drive buffers for three to six days.
What frame rate should I record a collaborative robot at?
Use 30 fps, set as a fixed rate rather than as fast as the camera will go: a constant rate keeps timestamps evenly spaced and the storage figure predictable. At a 250 mm/s collaborative speed the flange moves about 8 mm between frames. Halve to 15 fps for the overview camera; raise to 120 fps only for falls or snaps, where a 200 mm drop lasts 0.2 s.
Should I record raw camera data or H.264 for fault replay?
Record H.264. A raw 12 MP Bayer stream at 30 fps runs 2.88 Gbit/s, about 1.3 TB per hour, which fills a 1 TB drive in under 45 minutes, while H.264 needs about one eightieth of that. Save short raw clips only when you must measure from the pixels: a 10-second raw clip at that rate is about 3.6 GB.
Do I need a global shutter camera to record robot motion?
Not for a slow cobot. Rolling-shutter skew only appears when the scene crosses the frame within the row-by-row readout, which a 250 mm/s arm at 1-2 ms exposures does not produce. Blur is a separate limit: blur equals speed times exposure, so 0.5 ms at 250 mm/s smears 0.125 mm. Choose global shutter for snap events: falls, spring returns and ejections that cross the view in under 50 ms.
How do I keep two camera recordings aligned with the robot's fault log?
Run cameras, recorder and controller log from one NTP source, and store each frame's device timestamp beside the video. A fault timestamp then lands within half a frame, about 17 ms at 30 fps. If a device cannot use NTP, measure its offset once and correct by that constant; offset matters less than drift. Export the two minutes before each fault so the clip survives buffer roll-off.
Will a 4K security camera work instead of a machine-vision camera?
For the wide view, often yes. A 4K stream is 3840 pixels wide, about 0.48 mm per pixel over a 6 ft window, and many kits deliver 10-15 fps into H.264, roughly 5.6 GB per hour at 15 fps, so a 2 TB drive holds about two weeks. They give up lens choice and exposure control, so keep the machine-vision camera for the macro window.