Verify camera coordinates in a robot program before moving

A coordinate string from the camera and a move command from the robot sit a few lines apart in your program, and nothing between them checks that the numbers make sense. If the vision side changed units, dropped a field or flipped a sign, nothing warns you: the arm goes to the wrong place at full speed. This procedure puts a gate between the decode and the motion. You parse the received string into typed real variables, reject bad field counts, impossible ranges and flipped signs, then compare X and Y with a taught reference point at a fixed tolerance. Only a string that passes every check releases the move. The gate is about a dozen lines in any robot language, and it catches the faults behind most first-day crashes.

What you need before you write the check

• A taught reference point. Place a dowel or fiducial in the middle of the field, run your hand-eye calibration, and record its X and Y in robot base coordinates. If the calibration itself is in doubt, settle that first with the hand-eye calibration accuracy verification procedure.
• A written message contract. Field order, delimiter, units, decimal places, one part per line. The send side of that contract is covered in sending string data from a vision system to a robot over TCP.
• The decode routines of your robot language. Every controller manual documents string-to-real conversion. Parse with those routines; do not copy character offsets from an old program.
• A tolerance, chosen from the process in the next section.
• Network headroom on the vision side, so camera traffic and robot traffic sit on separate ports. When the controller and its software need to run on a cabinet-mounted machine, dedicated industrial mini PCs are an option; otherwise an area scan camera on its own subnet keeps image traffic away from the robot link.

Two controllers that fit this split-network set-up:

Set the tolerance from the process, not from the camera

Gate at half the placement tolerance of the step the robot performs. A placement specified to ±1 mm gets a 0.5 mm check on each axis; a palletizing pick good to ±10 mm gets 5 mm. Half the process tolerance is tight enough to catch a real fault and loose enough that normal vision noise never rejects a good part. Write the number as one constant next to the taught point, so a tolerance change is a one-line edit.

Add a second, absolute gate: any coordinate outside the calibrated field footprint rejects immediately, whatever the tolerance says. That gate costs one comparison and catches wrong units and wrong frames outright.

The pre-move checks, in order

1. Decode the string into real variables in one place. Split the line on the agreed delimiter, convert each field with the controller's decode routine, and reject the message if the field count differs from the contract. Three fields — X, Y, angle — means exactly three parse or nothing moves.
2. Range-gate X and Y against the calibrated footprint. Your hand-eye calibration tells you where the camera's field sits in base coordinates. A part imaged in that field cannot report a coordinate outside it, so a value beyond the footprint means wrong units, wrong frame or corrupt data. Gate the angle field to its valid range too: ±180 degrees at the widest, tighter if the part orientation is known.
3. Check the sign convention. The taught point fixes the expected quadrant. If your cell sits at negative Y in base coordinates and the string claims positive Y, reject it. Do not flip signs inside the parser to make bad data fit; that hides the next fault.
4. Reject stale data. Have the vision side echo a trigger number, and compare it with the trigger you sent. A frame captured for the previous part passes every numeric gate below. On a moving belt this matters more: the conveyor target acknowledgment at tracking position rollover case shows what an out-of-date target does at the end of a track.
5. Compare with the taught point. Compute the two axis errors from the reported X and Y, and pass only when both sit within the tolerance. The worked example below shows the arithmetic and the threshold.
6. Release or hold. A pass commands the move. A failure holds position, raises an alarm code and logs the raw string with a timestamp. The operator decides what happens next; the program never moves on a failed gate.
7. Command the delta, not the raw coordinate, if your set-up uses offsets. Many guidance cells move to nominal-plus-offset. If that is your architecture, apply the received offset with the unit conversion set out in applying camera XY offsets in a robot program — and gate the raw values anyway, before any offset is added.

Worked example: a 0.5 mm gate against a dowel taught at (350.000, -120.000) mm

Inputs. Taught point X_teach = 350.000 mm, Y_teach = -120.000 mm in robot base coordinates, recorded during hand-eye calibration (example values; your taught numbers replace them). Calibrated footprint from the same calibration: X from 250.000 to 450.000 mm, Y from -195.000 to -45.000 mm — a 200 × 150 mm field. Gate t = 0.5 mm, half of a ±1 mm placement tolerance. Incoming string: 349.62,-119.85,12.4, three fields, X and Y in mm, angle in degrees.

Rule. Pass only when both axis errors are at or below t:

Arithmetic. X error: abs(350.000 - 349.62) = 0.38 mm, at or below 0.5 mm. Y error: abs(-120.000 - (-119.85)) = abs(-0.15) = 0.15 mm, at or below 0.5 mm.

Fault case, wrong units. The vision side reports the same part in inches: 13.765,-4.719,12.4. The conversion is 349.62 / 25.4 = 13.765 in and 119.85 / 25.4 = 4.719 in, so this is physically the same part. The range gate rejects it first — 13.765 mm lies far outside the 250.000 to 450.000 mm footprint — and the tolerance gate rejects it after: ex = abs(350.000 - 13.765) = 336.235 mm.

Fault case, flipped sign. A corrupted X arrives as -349.62,-119.85,12.4: ex = abs(350.000 - (-349.62)) = 699.62 mm. Rejected, and the robot never leaves its position.

Result and decision. The good string passes with 0.38 mm on X and 0.15 mm on Y against the 0.5 mm gate, so the move releases. Both fault strings stop at the gate with their raw text in the log. That is the decision rule for every cycle: both errors within the gate, move; either one outside, hold and alarm.

Prove the gate works before you trust it

Run four tests with the arm in a safe mode at reduced speed:

• Send the good string: expect a pass and a normal move.
• Send the inches version of the same point: expect a rejection at the range gate, no motion, alarm logged.
• Send the string with one field deleted: expect a rejection at the field-count check, before any number is used.
• Shim the part or the camera by a known 1 mm, re-trigger, and read the reported change: it should read about 1 mm in the right direction, with the axis error landing near the gate.

Repeat each test ten times. Acceptance is zero bad-string passes and zero good-string rejections; anything else means the parser and the contract disagree.

Common mistakes

• Comparing against the image centre. The centre of the field and the taught point differ by the whole hand-eye transform. Compare in base coordinates against the taught values.
• No freshness check. Numeric gates happily pass last part's data. Echo the trigger number.
• A parser written twice. If the vision program and the robot program each define the field order in code, one update misses the other. Keep the contract in a comment block next to the taught constants on both sides, dated.
• Undefined units. Millimetres on one side, inches on the other: a 25.4× mismatch that the range gate in step 2 catches only if the contract states the unit.
• Gating only Z. Most guidance faults are in-plane. X and Y carry the fault; gate them first, angle second, Z last.

When a coordinate fails the gate

Work down the list in this order:

1. Read the logged raw string. Garbled, truncated or duplicated text points at the link, not the vision software; the robot socket handshake fix covers that symptom.
2. Format right, values wrong. Re-run the hand-eye verification. Mounts creep after a bump, a lens change or a large temperature swing, and the taught point no longer sits where the calibration says.
3. Values right, part still misplaced. The image-to-robot conversion is the suspect; converting image coordinates to robot coordinates for servo moves walks through that transform.

Commission checks

• Message contract written, versioned and identical on both sides.
• Taught point recorded with its date and the calibration that produced it.
• Gate constant matches the tolerance table for this step.
• Alarm path defined: hold, operator message, raw string stored.
• Camera network and robot network on separate ports or subnets.
• The four proof tests from the previous section run and logged.

Next step

The gate is software; the hardware under it needs the ports to keep camera, robot and plant traffic apart. Browse the vision controllers, start the system configurator, or contact us with your camera, protocol and robot details for a set-up check. The applications topic page collects more procedures like this one.