Locate node calibration change: why waypoints move too

You re-teach a locate node's calibration, the score comes back high, and three weeks later picks drift or a vacuum cup clips a fixture. The calibration was never the only thing you changed. Every waypoint built on that node's feature points lives in the calibration frame, so a new frame silently re-maps each of them in robot coordinates. The sections below give you the arithmetic that shows how far they moved, an order for re-checking them, and a process that keeps the next calibration change from rewriting your program unnoticed. It applies to wrist-mounted and fixed cameras alike, on smart cameras and vision controllers — anywhere a move node references points from a vision calibration.

What happens to taught waypoints when a locate node's calibration changes?

Every move node that references feature points from that calibration is stored relative to the calibration frame. A new calibration re-maps all of them at once: the robot coordinates change without you editing a single waypoint.

The chain runs image → calibration → part frame → feature points → move targets. A feature point is not a robot position stored once; it is a coordinate inside the calibration frame, so when the frame changes the software re-resolves every point hanging on it. Current wrist-camera software makes this explicit: at least one major package now updates dependent linear and process move nodes automatically when a locate node's calibration changes, and requires the model position to be set in the same edit.

Automatic does not mean harmless. The re-map preserves each waypoint's coordinates relative to the frame, not its position over the hardware. A grasp point defined 2 mm above the located part keeps its 2 mm offset — if the new calibration is more accurate, it lands more accurately on the part. A waypoint jogged to a fixture edge and stored in the calibration feature holds the same frame coordinates, but the fixture has not moved, so the tool arrives at a shifted spot over unchanged hardware. The first case self-corrects; the second is the one that costs a crash.

How far do my waypoints move after a calibration change?

Far enough to fail most precise picks: a calibration that moves 1.4 mm at the origin and turns 0.3° shifts a waypoint 250 mm out by about 2.7 mm — more than five times a ±0.5 mm pick tolerance.

Three inputs decide it: the frame offset Δt, the frame rotation Δθ, and the lever L from the calibration origin to the waypoint. The offset comes from the image through the pixel scale:

Worked example. A 5 MP sensor of 2,448 × 2,048 pixels covers a 150 mm field of view, so s = 150 / 2,448 = 0.061 mm per pixel. The new calibration resolves the origin 20 pixels from where the old one did — a plate re-placed by that much, or a bracket eased a fraction of a millimetre. Δt = 20 × 0.061 = 1.2 mm in X and 0.8 mm in Y (about 13 pixels), so |Δt| = √(1.2² + 0.8²) = 1.4 mm. The rotation changed by Δθ = 0.3° = 0.0052 rad.

A place position 250 mm from the calibration origin adds a rotation term of 250 × 0.0052 = 1.3 mm. Worst case, that waypoint moves 1.4 + 1.3 = 2.7 mm; best case the two terms oppose and it moves about 0.1 mm. Both terms scale linearly — double the lever to 500 mm and the rotation term doubles to 2.6 mm — so plan on the worst case.

Now the decision. Against a ±0.5 mm pick tolerance, 2.7 mm fails by more than 5×: re-teach every dependent waypoint carrying that tolerance. Against a ±5 mm machine-tending tolerance it passes, but a 5 mm fixture-clearance margin drops to 5 − 2.7 = 2.3 mm, so dry-run the approach points at reduced speed first.

Why did the calibration score stay high while the frame moved?

A locate score measures how well the model matched the image, not whether the calibration frame matches the previous one. A 0.3° frame change moves a calibration feature about 1 pixel at 200 pixels from the sensor centre — invisible on screen, yet 1.3 mm at a 250 mm robot lever.

The score grades pattern matching; the calibration grades coordinate mapping, and the two are independent. The usual sources of a small frame change are physical: a bracket re-mounted a fraction of a degree out, a lens ring nudged during cleaning, a calibration plate placed a few pixels off its previous spot, or a lighting change that shifts marker centroids. Each is tiny in the image — the 0.3° example moves a feature 200 × 0.0052 ≈ 1 pixel at that radius — and each multiplies by the robot lever by the time it reaches a move node.

That amplification is why a one-pixel locate shift changes detection results downstream; why pixel shifts change detection results covers the detection side. For the frame itself, judge the re-teach by a measured delta, not by the score: log Δt and Δθ every time you change a calibration, and the formula turns those two numbers into a millimetre figure you can act on.

Which nodes do I re-check, and in what order?

Re-check in this order: waypoints that approach fixtures or parts in confined space, then the first pick after the locate, then place positions, then anything that references the calibration feature rather than the part. Automatic propagation changes the stored coordinates, not the physics.

While you are in the node, re-set the model position in the same edit as the calibration. Skipping it leaves the node's taught reference resolving through the old frame, and the offset surfaces later as drifting picks.

Does it matter where the locate runs — camera or vision controller?

Yes, because the calibration frame lives with the program that owns it: a smart camera keeps it in the camera job, a vision controller keeps it in the vision software — and dependent waypoints re-map in both cases.

On-device locate keeps calibration, model and feature points inside the camera's job; the robot program receives corrected part coordinates and stores its own offsets. Controller-based locate concentrates the same data in one vision program, which helps when several cameras share a scene. What changes is who owns the frame and where the delta gets logged — the waypoint rule itself is identical.

Both of these run the locate on the device, so the calibration never leaves the camera:

The MV-SC3050XC-16M-ATN-H pairs a 5 MP global-shutter sensor with Fast Ethernet. The MV-SC5060XM-08M-WBN moves 6 MP over GigE. For a multi-camera cell, one controller owning every frame makes the delta a single logged event:

The MV-VC2140-128G40-1T provides 3-4 LAN ports and 4 built-in light channels, so calibration ownership concentrates in one vision program. Browse the smart cameras for on-device locate, the vision controllers for centralised frames, or the camera finder to filter by interface, resolution and shutter.

How do I re-verify without re-teaching the whole program?

Measure, don't guess: run the locate with a part at a known position, command the robot to the first pick, and read the offset at the part. Recompute the shift for every dependent waypoint and re-teach only the ones that exceed a third of their tolerance.

1. Before touching the calibration, save a program revision and export the old calibration data. You cannot measure a delta you did not keep.
2. After the change and the model position re-set, run the locate with a part present. The robot returns to the snapshot position first, for the same reason it must for the original teach — why the robot must return to the snapshot position first.
3. Command the first pick at reduced speed and read the offset at the part, not at the flange.
4. Recompute shift ≈ |Δt| + L × Δθ for every dependent waypoint and compare each with a third of its tolerance.
5. Re-teach the exceeders, then dry-run every clearance point at reduced speed before production.

If the measured first-pick offset reads under a third of tolerance and every clearance point comes through clean, the rest of the program usually stands. The hand-eye calibration accuracy verification test turns step 3 into a number you can file with the program revision.

How do I keep a calibration change from moving waypoints again?

Make calibration changes rare and deliberate: mount the camera so nothing moves it, teach feature points against the part frame instead of the calibration frame where the software allows, and treat any calibration edit as a program revision with a logged delta and a re-verification test.

• Mount as if it will be hit. A rigid one-piece bracket and a strain-relieved cable mean a bumped cable cannot walk the camera a few pixels — the source of a silent Δt.
• Prefer part-relative feature points. Points defined against the located part inherit calibration improvements; points defined against the calibration frame inherit its drift over unchanged fixtures.
• Version every calibration edit. Save the program revision and log Δt and Δθ with it; a change without a logged delta is a change you cannot audit later.
• Trigger recalibration on events. After a collision, bracket or cable work, a lens or focus change, or a lighting geometry change — the same triggers that force a hand-eye redo after a wrist camera tool change. On a fixed camera, re-verify the camera-to-base result the same way; the eye-to-hand verification guide gives the test.
• Keep a verification part. Pick a known-good part on a schedule; an offset under a third of tolerance means the frame still holds.

Whichever hardware owns the locate, the re-check habit is what protects the program. If you are planning a new cell, size the camera in the smart camera configurator, then read the rest of the systems guides before the first teach — and if a locate still will not hold, the vision locate feasibility checklist tells you whether the part is locatable at all.