Record a camera view following a moving component in robot simulation

You built the cycle in your robot simulator, hit record, and got a fixed view while the robot TCP swept out of frame. The view you want rides on the moving component itself. The gripper stays centred while the cell turns around it. That recording is standard practice: a camera-tracking add-on locks the simulation camera to a component, and the recorder captures what that camera sees. Here is how to attach the camera, how to set the recording frame rate from the TCP speed — 90°/s across a 45° view needs 60 fps — and how to carry those numbers onto a real wrist camera.

Can a simulation camera ride on a moving robot TCP?

Yes: a camera-tracking add-on locks the simulation camera to any moving component, including the robot TCP. The built-in recorder then captures that camera's view for the whole run, holding the gripper centred through every move.

A fixed view is anchored to the room, which works until the robot leaves the frame. A tracking view is anchored to a coordinate frame that moves with the component. The camera is parented to the TCP, inherits its translation and rotation on every rendered frame, and the image changes even when the robot is the only thing moving. The recorder is indifferent — it captures whatever the active camera sees.

The companion build of a wrist mounted 2D camera simulation for a robot gripper tool covers creating and aiming the virtual camera on the gripper. This guide covers the recording half: the frame rate, the export, and the bridge to physical hardware. When that wrist camera becomes real, which tool-frame offsets work on a gripper-mounted camera decides where the image lives in your robot program.

How do you lock the camera to the moving component?

Extract the tracking add-on into your simulator's My Commands folder and restart the application. A Tracking button appears in the Camera group on the Home ribbon tab; from there the lock is two clicks.

1. Download the camera-tracking add-on from your simulator's official add-on samples — the manufacturer's own download page, never a shared copy — and extract the archive into the My Commands folder.
2. Restart the simulator and confirm the Tracking button now sits in the Camera group on the Home ribbon tab.
3. Place the camera where you want it relative to the TCP before locking; 300-500 mm back along the tool axis is a workable wrist view.
4. Open the tracking command, select the TCP or the flange geometry as the tracked component, and read the confirmation message.
5. Match the simulated camera's field of view to the real lens you intend to buy — the steps are in configuring a robot camera's field of view in simulation.
6. Run the cycle once at full speed without recording and watch the view through acceleration, deceleration and any workpiece swap; then start the recorder.

What recording frame rate does the TCP speed demand?

Record at least 30 frames per full field-of-view crossing. Divide the speed at which the scene sweeps the view by the horizontal field of view, and multiply by 30 — that product is your minimum recording rate.

The rule comes from playback, not from the robot. Motion reads as continuous when consecutive frames shift the content a small fraction of the screen. 30 frames across one full field is the smooth standard, 10 frames across the field is reviewable, and below that the eye sees steps. Cinema at 24-30 fps looks right for the same reason — each frame moves the scene a few percent of the screen width.

Here v is how fast the scene sweeps across the view — degrees per second for a rotation, mm/s for a translation — and FOV is the horizontal field in the matching unit. f_rec is the minimum recording rate in frames per second.

How fast must you record a 90°/s TCP sweep?

60 fps: a 45° view swept at 90°/s crosses in 0.5 s, and 30 frames across that half-second is 60 frames per second. 30 fps stays reviewable, 15 fps is a slideshow.

The arithmetic for a wrist rotating at 90°/s:

• Crossing time: 45° ÷ 90°/s = 0.5 s
• Smooth rate: 30 frames ÷ 0.5 s = 60 fps
• Rotation per frame at 60 fps: 90°/s ÷ 60 fps = 1.5°
• At 30 fps the view turns 3° per frame over 15 frames per crossing — fine for your own review, visibly steppy in a handover video
• At 15 fps it turns 6° per frame over 7.5 frames per crossing

Translation runs the same way. A TCP moving 250 mm/s across a 300 mm field crosses in 300 ÷ 250 = 1.2 s, so 30 ÷ 1.2 = 25 fps — set the recorder to 30 and you have margin. Commit: 60 fps for anything you show anyone else, 30 fps for engineering review, nothing slower for a moving TCP.

How do you size the real wrist camera the simulation stands in for?

Match the real camera's pixels and frame rate to what you simulated, then pick the lens from geometry: at a 500 mm working distance, a 12 mm lens frames about 300 mm on a 1/1.7" sensor.

The simulated camera is a rehearsal for hardware, so shop by the two numbers you just watched: resolution and frame rate. Among area scan cameras, two 12 MP options bracket this job. The LS-CMR-0166 records 4000 × 3000 pixels over USB3 at 30 fps. The LS-CMR-0053 carries the same 12 MP sensor on GigE at 9 fps — right for a slow inspection sweep.

All 2 share: Sensor size 1/1.7". Values as printed in each product's data sheet; open a part for its drawing and full specifications.

A 1/1.7" sensor has an active width of about 7.4 mm, so 4000 pixels across works out to 7.4 ÷ 4000 = 1.85 µm per pixel. Against the 90°/s wrist rotation from earlier, 9 fps turns the view 10° per frame — the reason the faster part wins this job. To frame a 300 mm scene from 500 mm:

• Magnification: m = 7.4 ÷ 300 = 0.025
• Focal length: f = WD × m ÷ (1 + m) = 500 × 0.025 ÷ 1.025 = 12.2 mm, so a 12 mm C-mount lens
• Check: with 12 mm at 500 mm, m = 12 ÷ (500 − 12) = 0.0246, and the field is 7.4 ÷ 0.0246 = 301 mm
• Horizontal angle: 2 × atan(150 ÷ 500) = 33.4°

Run your own working distance and field of view through the calculator before you order the lens:

Cross-check the rate against that angle: a 90°/s rotation crosses 33.4° in 33.4 ÷ 90 = 0.37 s, and 30 fps delivers 30 × 0.37 = 11 frames per crossing — review quality, not smooth. Decision: a 30 fps, 12 MP wrist camera documents grip timing on fast rotations. When the video itself is the deliverable, record a smaller region of interest so the sensor reads out faster, or move to a camera whose full-frame rate reaches 60 fps.

How short an exposure does a moving TCP need?

One pixel of motion or less: with a 300 mm field spread over 4000 pixels and a TCP moving 250 mm/s, the exposure limit is 1/3333 s, so set 1/4000 s and strobe the light.

• One pixel at the part: 300 mm ÷ 4000 px = 0.075 mm per pixel
• Exposure limit: 0.075 mm ÷ 250 mm/s = 0.0003 s, about 1/3333 s
• At 1/4000 s (0.25 ms) the blur is 250 × 0.00025 = 0.063 mm, or 0.8 pixels
• The frame period at 30 fps is 33 ms, so the shutter is open under 1% of the time

A continuous light restricted to 0.25 ms needs roughly 130 times the power of one sized for the full 33 ms frame (33 ÷ 0.25 = 132), which is why moving-part cells strobe. The light controller fires an overdriven pulse synchronized to the exposure. On the lens, f/2.8 passes four times the light of f/5.6 (5.6² ÷ 2.8² = 4.0), so start fast and stop down only when the light has power to spare.

Where does the recording land, and how do you export it?

Export at the capture rate and count the frames: a 60 fps capture written into a 30 fps container plays at half speed, and 60 fps for 30 s must produce 1800 frames before any edit.

Size the pipe first. A 12 MP monochrome frame at 8 bits is 4000 × 3000 × 1 byte = 12 MB; at 30 fps that is 360 MB/s, or 21.6 GB per minute. USB3's 5 Gbit/s link yields about 400 MB/s of usable payload, so full-frame 12 MP at 30 fps sits at the ceiling with no headroom. Record a region of interest or a compressed stream, or the recorder drops frames exactly during the fast move. Sizing long runs is covered in continuous camera recording in a robot cell; the link-budget side is laid out in high frame rate camera data rate planning, and recording without dropped frames covers the failure mode itself.

In the physical cell, keep footage off the system disk. The MV-VC2140-128G40-1T runs its system on an SSD and stores footage on a separate HDD, with 4 built-in light channels for the strobe:

For reports, one sharp frame is often enough, and saving the active simulation view as a PNG keeps full resolution with no codec in the way. Browse vision controllers when the cell needs camera ports and light channels in one box.

When is a camera locked to the TCP the wrong view?

Lock the view to the TCP when the question is how the gripper behaves, and record a fixed scene camera when the question is where anything is. The locked view measures every distance in a moving frame.

The locked view throws away the geometry of the cell: clearances to fixtures, the approach angle to the conveyor, the drop zone. Placement accuracy, tolerance checks and collision review all need the fixed view — where a conveyor-tracking camera sits relative to the robot matters more there than any tracking lock. The honest workflow records both: the locked view for end-effector behaviour, the fixed view for position. In hardware that second camera lives on camera stands; the LS-MNT-0040 holds a scene camera at a 700 mm height on a 400 × 450 mm slide-table base.

What should you check before trusting the recording?

Run the cycle once with the recorder off and once with it on, then compare wall time to simulation time. 30 s of simulation that takes 45 s of wall time still yields correct motion, only a slower session.

• Frame count: recorded fps × seconds of simulation. 60 × 30 = 1800; a short count means the renderer dropped frames.
• Worst-case rotation per frame: at most FOV ÷ 30 — 1.5° for a 45° view, 3° for a 60° view.
• The lock holds through acceleration and through every component swap; scrub to the fastest move and the load event.
• Exposure redone from the measured TCP speed before the first physical shot — 0.075 mm per pixel and the speed set the limit.
• Export rate equals capture rate; spot-check by counting frames across a one-second event in the player.
• Treat the video as a record of intent — real-cell timing comes from the physical cell, not from the render.

When the recording has settled the camera position, the rate and the light, build the hardware from those numbers:

Anything the numbers leave open — a sensor that holds 60 fps at full frame, a lens between two focal lengths — send the simulation's figures through the contact page for a parts check.