Wrist camera image storage: where frames live and how to access them

You taught the wrist camera, the locate step works, and now someone wants the pictures: an archive of what the cell actually saw, a training set for a classifier, or evidence for a customer audit. The catch is that nothing in a wrist-camera cell keeps images by default. The pose reaches the robot controller, the log keeps a few lines of text, and the frame itself lives in the camera's memory until the next trigger replaces it. This guide shows where wrist camera image storage actually happens, which network paths can carry a frame to your PC and which cannot, how to write each frame to disk before the cycle overwrites it, and how big the archive gets — with the arithmetic worked out in full.

Where a wrist camera keeps data — and where it does not

A wrist camera has no archive of its own. During the locate step the current frame sits in the camera's internal buffer; what travels to the robot controller is the result, chiefly the pose, plus whatever fields the locate function returns. The controller log records text: the locate result, the calibration quality — mean and maximum error, printed after calibration runs — and the taught part height after you teach a new object. Good for audits, but no pixels anywhere in it. A locate on these cameras also reports one best-fit part at a time: a frame holding several parts yields a single pose, not a list.

Two consequences follow. First, a picture exists only while the program holds it; the next trigger reuses the buffer, which is also why a live preview sometimes freezes mid-program — why a wrist camera preview freezes during run walks through that mechanism. Second, keeping one frame or twenty is the same operation; the pattern for holding several is in retrieving multiple images from the camera buffer, and pairing them with poses is covered in storing multiple part poses from one vision image.

Why the pose arrives but the image does not

The robot's real-time data channel — RTDE is the common name for it on collaborative platforms — streams joint states, poses and registers to the cell, and the wrist camera's results ride along as variables. Images are not among those variables, so a request for the picture through the interface that delivers the pose returns nothing at all. That exact gap, and the route that works instead, is documented step by step in a walkthrough of wrist camera image access over RTDE.

The controller filesystem is a different matter. It is reachable over SSH or FTP with your administrator login, and a camera plug-in that caches frames writes them there. Look there to confirm what a plug-in saved; do not build an archive on it. Controller storage is small and shared with the robot's own files, and an archive that lives inside the robot controller dies with the controller.

What you need

• The camera and the robot controller on one Ethernet network with fixed addresses. The GigE camera on a robot wrist guide covers addressing, subnets and retrieval end to end.
• Your PC on that network, able to open a TCP connection to the camera's IP address.
• The camera's image service: a live-image TCP port — 4242 on the common collaborative-robot wrist camera — or an HTTP snapshot URL that returns a JPEG.
• The locate call from the camera manual, so you can log its result next to each picture. In one wrist-camera manual it is the object_location function, documented in section 6.2.
• Disk space sized by the worked example below.
• A short client script in the language the line already uses; the receive loop is ready-made in sending images over a TCP socket with a length header.

Store the frame: six steps

1. Give the camera a fixed address on the network and ping it from the PC. Nothing else in this procedure works until the ping answers.
2. Trigger the locate from the robot program and hold the cycle there. The frame is valid only until the next trigger, and on a fast cycle that window can be well under a second; the frame-timing arithmetic is in camera buffer timestamp latency.
3. Open the image service. For a live-image port, connect a TCP socket to the camera IP on port 4242 and read until the frame is complete — the port 4242 live image guide documents the exchange. For a camera that publishes an HTTP snapshot URL, a plain request returns the JPEG body, the same mechanism as the snapshot URL one-button live view.
4. Write the bytes to disk as they arrive, with the extension that matches the payload: a snapshot URL hands you a JPEG; a socket stream follows the framing given in the camera manual. Put the timestamp and a trigger counter in the file name.
5. Pair every picture with its result. Write one CSV line per frame — trigger number, timestamp and the pose fields from the locate call — so the archive answers what the cell saw and decided, not just what it saw.
6. Verify on a full production cycle, not a staged still: dimensions matching the sensor's nominal resolution, and file timestamps advancing once per cycle.

Verify the archive and fix the classic failures

After the first hour of production, check three things. Every trigger number appears once in the folder and once in the CSV; gaps mean the cycle outran the fetch. File sizes sit in a narrow band; a run of half-size files means torn transfers, and the cure is the one described in copy the buffer before you queue it. Brightness holds steady across shifts; drift means ambient light is reaching the sensor, which controlling ambient light variation in pick-and-place vision treats separately.

Three failures account for most abandoned attempts. Reading the controller log and expecting pixels — the log carries results only. Fetching after the robot has moved on — the frame is already overwritten. And testing with the preview stream instead of the locate frame — the preview reuses the buffer for display and dies mid-program, for the reason covered at the top of this guide.

Sizing the archive: a 6 MP mono camera at one frame per second

One worked case settles the storage question for a typical cell.

Inputs, and where each comes from:

• Pixels: 6 MP mono, from the example camera, the MV-SC5060XM-08M-WBN smart camera — 6 MP, monochrome, GigE interface. 6 MP means about 6,000,000 pixels.
• Bytes per pixel: 1, for 8-bit monochrome output, the default raw format on these cameras.
• Capture rate: one frame per second across an 8-hour shift — the case this example works.
• Storage: 128 GB SSD plus 1 TB HDD, from the example archive, the MV-VC2140-128G40-1T vision controller.

The rule, in words: a raw frame weighs pixels times bytes per pixel, and a shift weighs frames per shift times the weight of one frame.

The arithmetic:

• frame_MB = 6,000,000 × 1 / 1,000,000 = 6 MB per raw frame.
• frames_per_shift = 1 × 3600 × 8 = 28,800 frames.
• shift_GB = 6 × 28,800 / 1000 = 172.8, so about 173 GB per shift.
• SSD margin: 128 GB / 173 GB ≈ 0.74 of one shift. At 173 GB per 8 hours the SSD fills about 6 hours into the shift, so roughly the last two hours of frames fail to write.
• HDD margin: 1,000 GB / 173 GB ≈ 5.8 shifts at full capacity, or 800 GB / 173 GB ≈ 4.6 shifts keeping 20 percent headroom.
• JPEG estimate: at typical quality settings a machine-vision JPEG is several times smaller than raw, so the same shift lands near 20-60 GB and the SSD alone then carries two to six shifts.

Decision: once raw shift volume passes about 90 GB — 70 percent of this SSD — the SSD does not survive a shift on its own. Save JPEGs to the SSD for the current shift, stream raws to the HDD or the office PC over the network, or archive only the frames that failed inspection. Below that line the SSD carries the shift with room to spare.

When the wrist camera is the wrong tool for the archive

Some cells cannot open the wrist camera's image service at all: closed plug-ins, restricted firmware, or an integrator handover with no documents. Then archive from a camera that speaks Ethernet to everyone. A smart camera accepts an image request from any client on the network and holds its own locate results; both of these serve frames over Ethernet to a requesting PC:

For a cell with several cameras and a real archive to keep, a vision controller receives and stores in one box on the cell, with LAN ports for every camera and onboard SSD and HDD storage — the sizing arithmetic above applies unchanged. If the cell already runs ROS, some wrist cameras also expose frames as image topics; configuring ROS image access for a wrist camera covers that route. For the retrieval side on a standard camera — getting the full-resolution frame off the device in the first place — the companion piece is full-resolution wrist camera image access from an external PC.

Decision, per case. Need evidence or a training set and the camera serves an image port: use the six steps and the sizing arithmetic above. Need the same but the camera is closed: move the archive to a smart camera or a vision controller on the same network. Need every part in a multi-part frame: move the locate to a smart camera or PC vision and store the pose list with each picture.

To pick the camera or controller for a cell that keeps its images, start with the camera finder or step through this configurator:

The rest of the integration side — sockets, buffers, timing — sits on the systems topic page, with the guides hub indexing everything else.