Camera locate snapshot position: why the robot must return first

You taught the part, the camera finds it, and the robot still drives to approach and pick points taught somewhere else. Or one program picks cleanly while a second stops with a "Not in snapshot position" popup. Both come from the same two rules. A vision locate is only valid when the camera sits at the taught snapshot position, and pick waypoints only follow the found pose when their move uses that snapshot variable as its feature. This guide gives you the program structure, the arithmetic for how far a loose camera moves the pick, and the checks to run before the first real grab.

Why doesn't the robot go to the object the camera found?

The approach and pick waypoints are playing back fixed coordinates because their move does not reference the snapshot position, so the pose the camera found never reaches them.

The locate node does not move the robot and it does not edit your waypoints. It computes one thing: the part pose in the frame the snapshot position defines. If the approach and pick points are children of a move that references the base frame or another fixed feature, that found pose is calculated and then discarded on the way to the gripper.

The fix is structural. Put the waypoints under a move whose feature is the snapshot position variable, and the found pose shifts them as one rigid set; the steps in the next section show where each piece sits. A cousin fault — a locate that works in teach and fails at run time — is usually trigger mode rather than waypoint structure, and vision locate works in teach but fails at run time: stream vs snapshot separates the two. The full locate-to-grip cycle is covered in 2D vision guided robot pick place grip: how the cycle works.

Where should the snapshot position be taught, and where should the camera be mounted?

Teach the snapshot position once, as a fixed overhead pose with the whole part inside the image, and bolt the camera to a rigid stand so nothing about that pose can drift between runs.

Choose a viewpoint that sees the whole part plus margin, square to the work plane, and save it as a named position the whole cell reuses. Everything downstream — found pose, feature, fault check — hangs off that one pose.

A stand such as the LS-MNT-0040 gives you a 700 mm height and a 400 x 450 mm base to fix camera and bracket to, which beats a friction clamp that a dragged cable can rotate.

Sit the camera 300-500 mm above the plane: close enough that a 5 MP sensor fills much of its image with the part, far enough that lens depth of field covers part-height variation. The snapshot itself needs a global shutter so robot settle does not smear the image. The MV-SC3050XC-16M-ATN-H is a 5 MP color vision sensor with a global shutter and a M12-mount lens, and the smart cameras finder filters by shutter and mount.

Teach the snapshot over the surface you will actually pick from. The found pose is projected into the plane the snapshot defines, so a snapshot taught over a fixture plate but used over a loose bin projects the part onto the wrong surface; snapshot position: match the work plane, not the robot pose works through that distinction. Fixed-viewpoint hardware is in camera stands.

How do you wire the locate node into the program so the waypoints follow the found pose?

Add a MoveJ to the snapshot position before the locate node, then put the approach and pick points inside a MoveL whose feature is the snapshot position variable, and every waypoint under it follows the found pose.

1. Teach the snapshot position: robot square over the plane, part flat in view, saved as a named position.
2. Insert a MoveJ to that named position immediately before the locate node, in every program that locates. Replay it; never jog close.
3. Call the locate node with the robot at that pose. It returns the part pose in the snapshot's frame.
4. Put the approach and pick points inside a MoveL that sits under the locate node, not beside it.
5. Set that MoveL's feature to the snapshot position variable. This is the step that lets the found pose move the waypoints.
6. Teach the approach and pick offsets once, over a part at a known spot, so the stored offsets mean "50 mm above the part top" rather than fixed base coordinates.
7. Confirm with an offset test: shift the part 20 mm in x and 10 mm in y and check the gripper tracks both.

Two details trip people up. The MoveJ carries the robot to the snapshot position, but the located waypoints are linear moves; that is what lets the feature plane shift them as a set. Nothing may sit between the MoveJ and the locate call either, because the node reads where the robot is, not where the program was heading. For the surrounding skeleton, structure a vision-guided pick and place program around drop targets shows where locate, approach and release belong.

What does the "Not in snapshot position" error actually check?

The locate node compares the robot's current pose against the taught snapshot position and stops when they differ, because every pose it computes is only valid for the viewpoint the calibration was recorded from.

One program picks while another faults for ordinary reasons. The working one has the MoveJ before the locate and the failing one starts from a home pose; the snapshot position was re-taught in one program only; or a jog crept in between the MoveJ and the call. The node reads the robot, not the program text, so all three look identical to it.

The reliable pattern is one named snapshot position, replayed identically everywhere. If the inspection runs once at program start and stores the pose, that only holds when the start pose is the snapshot position itself; run the camera inspection once at program start and save the pose covers that pattern. The plugin-level walkthrough on fixing snapshot position faults in a camera locate node lists the same causes for the popup.

How far off is the pick if the camera is not quite at the snapshot position?

A camera displaced 1 mm sideways shifts the reported part pose by about the same 1 mm, and a 1° tilt at a 300 mm camera-to-part distance shifts it about 5 mm.

Translation is the gentle case: the calibration composes camera pose with part pose, so a camera moved 1 mm in the work plane shifts the computed part pose by that same 1 mm, at any magnification. Tilt is what bites, because the image swings across the plane in proportion to the camera-to-part distance.

Worked example at L = 300 mm with a mount tilted 1°: Δpick = 300 mm × sin 1° = 300 × 0.01745 = 5.2 mm, five times a ±1 mm parallel-grip tolerance. The same 1° at L = 500 mm gives 500 × 0.01745 = 8.7 mm, so taller mounts amplify tilt in direct proportion. Height error at the same 300 mm mount, camera 10 mm high with the feature 80 mm off-axis: Δpick = 80 mm × 10 / 300 = 2.7 mm.

The software cannot see a tilted bracket; it can only refuse to run from a pose that is not the taught one, which is what the snapshot check is for. When the pick drifts with part rotation instead of camera pose, that is a different mechanism; vision pick error under rotation: diagnose position drift walks that one.

When is a fresh calibration the real fix, not a program change?

When the program structure is right and the pick still lands with a consistent offset, the hand-eye calibration is stale; re-run it instead of nudging waypoints, because a nudge fixes one pose and corrupts every other.

Re-run the calibration after any physical change to the camera: a bumped bracket, a swapped lens, a replaced stand, a snapshot re-taught after the mount moved. Calibration consumes matched pairs — robot poses and the frames captured at them — and eye in hand calibration inputs: the same robot pose and frame pairs shows which pairs must correspond.

A waypoint nudge compensates at exactly one pose: the one where you noticed the offset. Every other part position inherits the nudge plus its own calibration error, which is why a fix that works at the centre of the workspace fails at the edges. For a fixed overhead camera, recalibration need not be a full project; robot cell vision recalibration with one reference target describes a single-target routine. In a multi-camera cell the calibrations live off-board on a vision controller such as the MV-VC3301H-128G66, one per camera, instead of scattered across programs.

What do you check before running the first pick?

Confirm the mount, the MoveJ, the feature reference, the work plane and a known offset test before you let the gripper close on a real part.

• Mount: camera bolted hard to the stand, bracket tight, cables dressed away from the bracket.
• Program: one named snapshot position, a MoveJ to it before every locate node, nothing between that MoveJ and the call.
• Feature: approach and pick inside a MoveL whose feature is the snapshot position variable.
• Work plane: snapshot taught over the surface you pick from, parts presented flat.
• Image: sharp across the plane, exposure short enough that settle does not smear; reduce wrist camera snapshot time: fix focus and exposure covers the timing side.
• Light: ambient held between teach and run; ambient light variation in pick and place vision: control it lists the controls.
• Offset test: part moved +20 mm in x, +10 mm in y and 5° rotated; the gripper should track all three.
• Part families: give each family its own snapshot position; teach two parts in one vision program: separate snapshot positions explains why one shared view fights one of them.

If you are equipping a new cell rather than repairing one, the system configurator walks camera, lens, light and stand in order, and the team answers part-drawing questions through the contact page.