Trigger a USB camera capture from a robot controller over a socket

The robot reaches its photo position and the cell needs a still before the arm moves on. The camera is USB, the pendant has nowhere to hang it, and the obvious fix — a small capture box the controller drives over the network — has a reputation for hanging and stopping the robot dead. The box is rarely the culprit; the missing piece is a handshake that produces an answer for every request. Here you get that handshake, a short hardware list, the timeout arithmetic and the tests that make the scheme safe to run in production.

The decision: drive the box over a socket and demand an answer

The pattern that holds up is a capture service on a small box next to the camera. The robot program opens a TCP socket to that box, writes one trigger line and blocks on the reply for a fixed time — 500 ms is the right order here, and the worked example below shows why. The box grabs the frame, saves it and returns OK with the filename, or ERR with a reason.

Three rules make it survive the floor:

1. Every request gets an answer. The service replies OK or ERR even when the capture itself fails.
2. Every receive on the robot has a timeout. No blocking receive without one.
3. One command, one connection. The robot opens, sends, receives and closes each cycle; a connect costs about a millisecond on a switched LAN, so simplicity beats a persistent link with heartbeats.

The alternative — a discrete output wired to a camera trigger input — wins when you only need a synchronized exposure and no saved file. When the deliverable is an image on disk, the capture box is the right tool.

What you need

• USB3 board camera. Global shutter if anything moves during the shot; rolling shutter is fine for a part that sits still at the photo position. Compact board-level cameras mount inside your own housing.
• Capture box. A small single-board computer runs the service comfortably; the upgrade path, a vision controller, comes at the end of this guide.
• Cabling. A high-flex USB 3 cable wherever the head sits near motion; ordinary office leads fail early in drag chains. The camera data cables page is the place to compare.
• Power. The box's own 5 V supply sized 2-3 A. Do not feed box and camera from a controller USB port; the port budgets behind that rule are in the questions at the end.
• Network. A small switch and fixed IP addresses for box and controller.

For the capture head, a USB3 board camera with a global shutter fires on the trigger line and re-arms fast enough to repeat inside one cycle:

If the head has to live inside your own machined housing, a bare board with no lens mount bolts straight in:

And where the cable crosses or rides with the motion, a drag-chain-rated lead is what survives:

Put the box on its own network

Give the box and the controller fixed addresses on a small switch — 192.168.10.50 for the box and 192.168.10.10 for the controller are fine example values — and keep that subnet off the office network. Gigabit copper carries 100 m per segment, more than any cell needs. Keep the passive USB 3 run from camera to box at about 3 m; that is the practical ceiling for passive copper, which is why 3 m is the standard high-flex length. Open the service port on any host firewall, then prove the path with a ping in both directions before any code gets written.

Write the capture service

1. Listen. Bind a TCP server on a port above 49152 — the registered range ends there, so 50000 stays clear of anything the operating system hands out.
2. Read one line. Accept, then read until the newline. Simple parsers block without a terminator, so the robot sends TRIG plus a newline and the service requires it.
3. Validate. Anything that is not TRIG gets ERR unknown command. Silence is the one wrong answer.
4. Capture. Keep the camera device open between shots and take stills from the live stream; reopening the device every cycle wastes time and can miss the trigger window. The grab discipline is the same one the hardware trigger grab loop in Python sets out: exposure once, then frames on demand.
5. Save. Encode JPEG at quality 90 and write under a timestamped filename — the name in the reply is your audit trail.
6. Answer. Send OK with the filename on success, ERR with a reason on any failure, both newline-terminated.
7. Guard. Put a 2 s timeout on the service's own socket reads so a half-open cable cannot wedge the listener; the capture stack guide covers the device side from the operating system up.

The service in one file, Python for readability — grab_and_save() is your capture code, everything else is the standard socket API:

import socket

HOST = "0.0.0.0"   # listen on all interfaces
PORT = 50000       # service port, fixed on both sides

def reply(conn, text):
    conn.sendall((text + "\n").encode())

srv = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
srv.bind((HOST, PORT))
srv.listen(1)
while True:
    conn, addr = srv.accept()
    conn.settimeout(2.0)              # half-open links die quietly
    try:
        cmd = conn.recv(64).decode().strip()
        if cmd == "TRIG":
            name = grab_and_save()    # capture, encode, write; returns filename
            reply(conn, "OK " + name)
        else:
            reply(conn, "ERR unknown command")
    except Exception:
        reply(conn, "ERR capture failed")
    finally:
        conn.close()

The exception handler is not decoration: it turns a crashed grab into an ERR the robot can act on.

Call it from the robot program

Robot languages differ in syntax and agree in shape — open, write, receive — so the program reads the same whichever controller runs it:

1. Open the socket to the box's fixed IP on port 50000.
2. Write TRIG with the trailing newline.
3. Receive up to 256 bytes with a 500 ms timeout.
4. On OK, parse the filename and move on; log it if the cell keeps records.
5. On timeout or ERR, take the branch you decided in advance — skip and log where the next station catches a bad part, fault where the process depends on the image.
6. Close the socket at the end of the cycle.

If replies ever go missing, the fault is usually in the send loop rather than the camera; the send-loop debugging guide walks that diagnosis step by step.

Budget the handshake for a 3.1 MP USB3 camera at 120 fps

This arithmetic sets the timeout. The head is the 3.1 MP USB3 board camera from the list above; the box is a small single-board computer; the images go to a USB stick on the box.

Inputs and where each comes from:

• 3.1 MP, 120 fps, mono 8-bit — the camera's own specification.
• USB 3 practical throughput about 400 MB/s — the 5 Gbit/s line rate loses its 8b/10b coding overhead, capping usable payload at 500 MB/s, and real streams land near 400.
• JPEG at quality 90 compresses roughly 8:1 on industrial scenes — an estimate; measure your own ratio once and adjust.
• Sustained write to a USB stick — commonly 10-30 MB/s; budget the low end, 10 MB/s.
• JPEG encode on a small single-board computer — budget 100 ms, then measure; a desktop-class CPU does it several times faster.
• Network round trip on a switched cell LAN — 2 ms or less.

The rule in words: add the worst-case time of every stage between the robot's trigger and the box's OK, then set the robot's receive timeout to at least twice that sum.

The arithmetic, stage by stage:

• Frame period: 1000 ms / 120 fps = 8.3 ms
• Raw frame: 3.1 MP x 1 B per pixel = 3.1 MB; over USB 3: 3.1 MB / 400 MB/s = 7.8 ms
• JPEG: 3.1 MB / 8 = 0.4 MB; write: 0.4 MB / 10 MB/s = 40 ms
• Encode: 100 ms by budget; ACK round trip: 2 ms
• Total: 8.3 + 7.8 + 100 + 40 + 2 = 158.1 ms, about 160 ms

The decision: set the robot's receive timeout to 500 ms. Worst case lands near 160 ms, so the margin is about 340 ms — roughly 3x the budget — and even a second full attempt, another 160 ms, still fits inside the window while staying far below the 1 s at which operators start reading the cell as hung. If your box measures over about 250 ms on the encode, either ACK after the grab and write asynchronously, or move the service to a vision controller; past that point the timeout stops protecting you.

How to verify it works

Four tests, in order:

1. Manual shot. From a laptop on the same switch, send one TRIG with a command-line socket tool to 192.168.10.50 port 50000 (example address — use yours). Expect OK plus a filename within a second and a viewable file on the box.
2. Timing check. Fire 20 shots and read the timestamps. The spread should sit near the 160 ms budget; above 250 ms, fix the encode or the write before the robot ever sees it.
3. Soak. Trigger from the real robot program for 50 consecutive cycles and require 50 OK replies. Any timeout or ERR gets diagnosed before the cell runs unattended.
4. Failure path. With the cycle live, cut the box's power once. The robot must reach its fault or skip branch inside the 500 ms window — that proves the safety behaviour, not just the happy path.

Compare brightness across the 50 saved images too; drift there points at the light or the exposure, not the socket.

Common failure modes and the fix

The robot stops mid-cycle. A receive with no timeout, or a service that goes silent instead of answering ERR. Fix both ends: timeout on the robot, an answer on every path in the service.

Camera not ready. The trigger lands while the device is still opening or renegotiating its stream. Keep the camera open between shots and take stills from the live stream; if exposure must change per shot, set it right after the previous save completes, not inside the trigger path.

Silence after TRIG. The missing newline is the classic: many simple parsers block until one arrives. Send it, require it, and terminate replies the same way.

Images stop after hours. A half-open connection from a switch reset or a cable wiggle. The service's 2 s read timeout plus the robot's 500 ms window turn this into a logged fault instead of a mystery. If drops correlate with welders or drives starting, the USB run is picking up noise — shorten it, route it away from power lines and use a shielded, drag-chain-rated cable.

Random box reboots. Power, not software. A shared or undersized 5 V rail browns out when camera and storage spike together; give the box its own supply.

When one box grows into three or four cameras, USB bandwidth rations frames before anything errors; the USB camera count guide gives the numbers per controller. And when a full-resolution save stalls the loop, the data was sized wrong — the capture sizing guide shows how to check the stream before blaming the code.

When a vision controller replaces the capture box

The single-board box is the honest tool for one camera, one light and a stick. Move the service onto a vision controller when any of these turn up: a second camera head, illumination that must strobe with the shot, storage you can plan maintenance around, or spare LAN ports for the next station.

An entry controller carries the small end of that job:

This one pairs an Intel N97 processor and 8 GB of memory with a 128 GB SSD and a 1 TB HDD for the image archive, two USB 3 ports for camera heads and four built-in light channels. The strobe that freezes the shot and the camera that takes it then answer to one box and one clock. The socket service ports over unchanged; only grab_and_save() gets rewritten against the controller's own capture tools.

Next step

Start with the head: the camera finder filters board-level and enclosed cameras by sensor, mount and interface. Size the timeout from the budget above, order a spare drag-chain cable and keep the ERR branch in the program from day one. More capture and communications guides sit on the systems topic page; if your cell has a wrinkle this one does not cover, the contact page reaches the applications team before you order hardware.