Save images from an ABB YuMi integrated vision camera

You have a YuMi with its integrated vision camera, a vision job that finds the parts, and a need the tool never advertises: get the actual images onto your desktop so you can look at them, build a dataset, or prototype inspection logic in OpenCV. RAPID will not do it — no instruction writes a camera frame to a file. Two proven routes get the pixels out: record frames from RobotStudio's integrated vision tab while the camera runs, or fetch the camera's stored files over FTP from its IP address. Below are both routes step by step, how long a pull takes, the OpenCV hand-off, and the point at which a standalone camera makes the problem disappear.

Can RAPID code save an image from the YuMi integrated camera?

No — RAPID has no documented instruction that writes a frame from the integrated vision camera to a file: the vision instructions hand the robot coordinates, verdicts and offsets, and the pixels stay inside the vision system.

The split is deliberate. The robot consumes vision results — a position to pick, a pass or fail, an offset for the tool. The vision system keeps the image to itself, so stop searching the instruction list for a save call; both routes below start outside the robot program. Plan it at design time instead. If the cell will ever need images for training data, audits or traceability, decide now whether a recording made from RobotStudio at commissioning is enough, or whether the station needs a camera whose frames you can pull at any time. Retrofitting that decision costs a camera, a mount and a cable. Deciding it now costs a conversation.

How do you save images from RobotStudio's integrated vision tab?

Open the integrated vision tab, put the camera in run mode, use the filmstrip icon to choose the destination folder and the save condition, then press start record. Every saved frame lands in that folder as a separate file while the cycle runs.

1. Connect to the controller in RobotStudio and open the integrated vision tab for the camera.
2. Set the camera to run mode so its configured job is actually executing.
3. Click the filmstrip icon and set where images are saved and when they are saved. The dialog offers the save condition; pick it before recording, not after.
4. Press start record, then run the robot through real cycles so the camera sees real parts.
5. Stop the recording and open the folder: one file per saved frame, ready to copy, archive or load into your image tool.

This is a development-time tool. It saves to the PC running RobotStudio while you are connected, which is exactly right for building datasets and debugging, and not a production data path.

How do you pull the stored images off the camera over FTP?

Point an FTP client at the camera's IP address. The camera serves its stored image files over FTP, so any PC on the same network can download them without a robot program or a RobotStudio connection.

1. Find the camera's IP address in its vision-system configuration — the ABB IRC5 integrated vision camera setup guide covers where the camera's address and ports live.
2. Ping that address from the PC before anything else; a wrong subnet shows up here in one second.
3. Connect the FTP client, sign in with the camera's configured credentials and download from the image directory.
4. Pull from a quiet network — a busy cell switch drops long transfers mid-session.

The same camera-side storage is why production exports work too: the pattern of pushing NG images from a vision system to an HMI over FTP rides on exactly this service.

How long does an FTP pull of a recording session take?

For a typical session the answer is seconds. 120 frames of 1.6 MP color at a JPEG compression of about 10:1 total roughly 58 MB. On a 100 Mbit/s Fast Ethernet link running at half efficiency that is a 9-second pull — under a second on GigE.

The 1.6 MP figure matches the vision-sensor class listed in the sections below, and the arithmetic scales directly:

• Raw: 1,600,000 pixels x 3 B = 4,800,000 B = 4.8 MB per frame.
• JPEG: 4.8 MB / 10 = 0.48 MB per frame (8:1 to 15:1 gives 0.3-0.6 MB).
• Session: 120 frames x 0.48 MB = 57.6 MB.
• Link: 100 Mbit/s x 0.5 usable = 50 Mbit/s = 6.25 MB/s.
• Time: 57.6 MB / 6.25 MB/s = 9.2 s, about 9 seconds.

What moves the number: frame count scales it linearly, so 500 frames at the same link take 240 MB / 6.25 MB/s = 38 s. Compression at 8:1 instead of 10:1 raises per-frame size to 0.6 MB, a 25% increase. A GigE link at 1000 Mbit/s (62.5 MB/s usable) brings the same 57.6 MB down to 57.6 / 62.5 = 0.9 s.

How do you get the images into OpenCV?

Once the frames are files in a folder, OpenCV reads them like any other image: enumerate the folder, decode each file, and your prototyping loop starts from exactly the pixels the camera delivered.

import glob

import cv2

frames = sorted(glob.glob("C:/yumi_capture/*"))  # list of str paths, empty until you download
assert frames, "no files pulled from the camera"
img = cv2.imread(frames[0])  # returns an ndarray, or None if it cannot decode
assert img is not None, "decoder rejected the file"
print(frames[0], img.shape)  # proof: file path plus (height, width, channels)

Run it right after a download. The two assertions prove the pull worked and the files decode, and img.shape reports the frame size for free. From there the discipline is the same as for any camera: keep raw sets untouched, copy before you annotate, and record enough metadata to know which cycle each frame came from. The save-camera-frames-to-disk workflow covers the folder and naming side, and the hardware-trigger grab loop in Python shows the acquisition half if you later move to a camera you trigger yourself.

How do you tune the vision job against saved images?

Saving is not only for export. ABB's Integrated Vision application manual (document 3HAC067707-001, available from ABB through its official library) states that images can both be acquired from the camera and loaded from a previously saved file, so a recorded set doubles as the regression test you replay after every job change.

Record a set that spans the variation you must handle — good parts, marginal parts, the rejects — then load those files back into the job while you move grids and thresholds. The job sees the same pixels every run, so a parameter change that improves one image and ruins another shows up immediately. RobotStudio can also emulate an integrated vision camera on a virtual controller (the capability is documented for the 6.05 release, which ran 32-bit only). That lets you rehearse job configuration and the record workflow with no robot and no camera on the desk.

When is a standalone camera the better answer?

If images in your own code are the regular deliverable — datasets, custom OpenCV logic, traceability archives — put a camera you address directly on the task. A camera that talks to your PC over Ethernet makes saving a one-line operation instead of a workaround.

For inspection that runs on the device with no PC, a smart camera does the job itself: the smart cameras category carries them, the camera finder filters by interface and resolution, and the camera configurator pairs camera and lens. The LS-SMC-0063 is a 1.6 MP smart camera with a 16 mm lens rated at 60 fps on GigE.

Where the check belongs near a gripper or inside a tight cell, two compact vision sensors cover it: the MV-SCB007EC-12S-WBN and HK-TD032-12-WBN are both 1.6 MP, global-shutter, M12-mount vision sensors on Fast Ethernet.

Route the frames to your own code the same way every time — command the GigE Vision camera over Ethernet and save each image. On anything that moves, use the 3 m high-flex GigE camera cable: the LS-CBL-0199 is a 3 m GigE camera cable built for drag-chain flexing.

If you would rather keep the robot's integrated vision workflow and change only the camera hardware, the third-party camera options for ABB integrated vision lay out what connects and what does not. And for the bench where you develop the logic, a slide-table stand such as the LS-MNT-0040 — 700 mm height, 400 x 450 mm base — holds the working distance fixed from one session to the next (camera stands, cables).

What do you check before you trust a recorded image set?

Four checks decide whether a recorded set is worth building on: camera in run mode, folder sized for the frame count, IP reachable for the FTP pull, and lighting that matches production.

• Run mode before record. The tab captures a running job; an idle camera produces an empty folder and a wasted cycle run.
• Folder capacity and location. At 0.48 MB per 1.6 MP frame, 500 frames need about 240 MB — keep twice that free on a local disk, not a network share a remapped drive can orphan.
• Reachability before the session. Ping the camera's IP first; fix subnet or firewall problems in the morning, not mid-recording.
• Production-identical lighting and presentation. A set recorded under different light teaches your logic the wrong appearance; how ambient light variation behaves in pick-and-place vision shows how much drift to budget for.
• Immutable raw sets. Copy before annotating; a training set you have cropped in place cannot be re-derived.

To spec the standalone camera, cable and stand for the bench in one pass, start the camera configurator and, once the layout is on paper, contact us with the working distance and the interface you want.