Locate a part center from its database dimensions

A robot cell picks glass plates with a vacuum gripper, and every new article number currently means a freedrive teach before the first pick. Yet the plates are circles, rectangles and squares, their outline dimensions sit in the article database, and the camera never moves — everything a locate needs is already written down. A script can replace the teach: it reads the article number, pulls the dimensions, thresholds a fixed window at the snapshot position, checks the blob against the database values and returns the centroid as the pick point. What follows gives you the accuracy numbers, the calibration trick, the run-time steps, the camera and lighting decisions, and the cases where teaching still wins.

Can a script locate the part from its database dimensions alone?

Yes, provided the part is a circle, rectangle or square, the snapshot pose is fixed, and your article database already stores outline dimensions; the script then needs no teach at all, because the geometry arrives at run time with the article number.

This differs from parametric teaching, where the vision system still learns a model of the part, even one built from parameters — parametric part teaching by shape is that route. Here no model exists. The database entry is the model: shape code, outline dimensions, tolerance. The camera contributes a single measurement, the centroid of the silhouette, and the script supplies the rest.

Three conditions make it work: the camera pose relative to the robot is fixed, the illumination is identical for every article, and a threshold can separate the outline. Your cell already has the first two, and the plates give you the third. Nothing in the script encodes part knowledge by hand; every geometric value — window size, predicted area, size gates — is derived from the dimensions the database sends.

How accurate is the blob centroid as a pick point?

Count on ±0.1 to 0.3 mm at the part for a calibrated system: the centroid math itself is good to about 0.013 mm at 0.0647 mm per pixel, and scale error, lens distortion and robot repeatability add the rest.

The centroid is the strong half of that figure. On a filled silhouette it averages thousands of edge pixels, so repeatability runs at 0.1 to 0.2 px; at 0.0647 mm/px that is under 0.015 mm. One code detail bites: pixel centers sit at half-integer coordinates, and ignoring the convention shifts every centroid a constant half pixel — 0.032 mm here — as explained in half-pixel offset in blob centroids.

Worked example — a 2448 × 2048 sensor with 3.45 µm pixels, a 16 mm lens, a 300 mm working distance:

• Sensor width: 2448 px × 3.45 µm = 8446 µm ≈ 8.45 mm.
• Field of view: 300 mm × 8.45 mm ÷ 16 mm = 158 mm wide; 2048 px × 0.0647 mm/px = 132 mm tall.
• Scale: 158.4 mm ÷ 2448 px = 0.0647 mm/px.

A Ø120 mm plate spans 1855 px across, and its predicted area is π × 927² ≈ 2.70 × 10⁶ px². Let the plate sit 20 mm off the taught position with the scale 0.3 % optimistic: scale contributes 20 mm × 0.003 = 0.06 mm, near-center distortion under 0.05 mm, robot repeatability ±0.05 mm. Root-sum-squared that is √(0.06² + 0.05² + 0.05²) ≈ 0.09 mm; quote ±0.1 to 0.3 mm as the planning figure and the cell will never surprise you.

How do you calibrate millimetres per pixel without extra hardware?

You need no calibration target: run the locate once on a plate whose diameter the database states, measure that circle in pixels, and divide the stated diameter by the measured diameter to get millimetres per pixel.

With the example optics, a Ø100.0 mm plate measures 1545.6 px across, so s = 100.0 mm ÷ 1545.6 px = 0.0647 mm/px — the same number the lens arithmetic predicted, now measured. Cross-check on a second size: a Ø80 mm plate must read 1237 px, and if it misses by more than 0.5 % the focus or working distance has moved. The scale, the image center and the snapshot pose belong together as one calibration record stored per cell.

The measured area doubles as a scale audit on every cycle: at ±5 % on area you are allowing about ±2.5 % on diameter, since area scales with the square.

What does the locate script do at run time?

Seven steps cover it: read the article number, pull dimensions, open a window sized from them, threshold, check measured size and shape against the database, and return the centroid converted to millimetres as the pick offset.

1. Read the article number and query the database for shape code, outline and tolerance: circle Ø120.0 mm, or rectangle 120.0 × 90.0 mm.
2. Convert to pixels with the stored scale: the Ø120 mm plate predicts a 927 px radius and 2.70 × 10⁶ px² of area.
3. Open the ROI at the snapshot position, outline plus 10 mm per side: 140 × 110 mm → 2164 × 1700 px.
4. Acquire one triggered snapshot with exposure and gain locked, never a live stream — locates taught on still frames fail on streamed ones for exactly this reason (stream versus snapshot).
5. Threshold at the fixed commissioning level and keep the largest blob inside the ROI.
6. Gate before you trust: area within ±5 % of predicted, circularity and aspect matching the shape code, measured dimensions inside the database tolerance.
7. Return (x_px − 1224, y_px − 1024) × 0.0647 mm as the XY offset on the taught pick pose in the robot base frame.

The robot must stand at the taught pose when the frame is taken; the camera-to-base mapping only holds there (why the robot returns to the snapshot position first). Keep each stage a separate, separately testable block — scale, window, threshold, gate, centroid — the structure behind five-locate-node approach to camera part location.

How does the script tell a circle from a square or rectangle?

Two measurements decide: circularity above 0.90 means a circle, and anything else is separated by the aspect ratio of a fitted rectangle — 1.00 for the square, 1.33 for a 120 by 90 mm plate — matched against the ratio the database predicts.

Circularity C = 4πA/P² reads 1.00 on a perfect circle, π/4 = 0.785 on a square, 0.769 on a 120 × 90 mm rectangle; pixelated edges shave a few hundredths off the measured value, so band it. Straight-sided shapes then split on the fitted rectangle's aspect: 1.00 ± 0.08 calls square, 1.33 ± 0.05 calls the 120 × 90 article, and further rectangles match by measured width and height against their database entries.

The same numbers guard against the wrong article. A Ø110 mm plate entered as Ø120 mm shows area (110/120)² = 0.84 of predicted — 16 % low, far outside the ±5 % gate, because area scales with the square of diameter. Database dimensions are nominal and real plates wander inside tolerance; why same-revision parts measure differently covers where that spread comes from. It is why the gates are bands, not equalities — and the centroid itself is immune, since a plate that grows uniformly keeps its geometric center exactly where it was.

Which camera runs the locate — smart camera or area scan?

Choose a smart camera or vision sensor when the window is simple and the result is a single offset; choose a GigE area scan camera on a PC when the script needs database access, custom lenses or image logging — both return the same centroid.

For a window this simple — threshold, blob, centroid — an on-device sensor is the tidy answer:

The MV-SC5060XM-08M-WBN is a 6 MP mono SC5000X smart camera with an 8 mm M12 lens on GigE; rolling shutter costs nothing here because plate and robot stand still during the snapshot.

When the field of view must match odd plate sizes exactly, pick the lens yourself on a C-mount: the MV-CU020-90GC is a 2.5 MP global shutter camera on GigE, and global shutter keeps the frame skew-free if the plate is still settling when triggered.

For large plates under one wide view, the MV-SCA002M-03S-WBN-SR ships with a 3 mm lens and a 240 mm focus distance, 0.3 MP mono — a centroid needs nowhere near the pixel count of a measurement.

Browse the smart cameras and area scan cameras categories, or filter by sensor and interface in the camera finder, and size the field with the calculator above before ordering.

What lighting makes glass plates threshold cleanly?

Backlight the plate: a silhouette against a lit panel gives strong, angle-independent edge contrast on clear glass, so one fixed threshold works for every article, while front lighting on glass fights reflections that move with each plate tilt.

Put a backlight panel behind the plates, sized roughly 20 % larger than the largest outline in each direction — a rule of thumb that keeps the plate inside the lit area even at the edge of its travel allowance. Clear glass that disappears under front light becomes a solid dark shape on the lit panel, and the threshold set once at commissioning holds for every article in the database. Coated or opaque plates take a diffuse top light instead; when a surface finish fights the camera, teaching reflective parts by shape, not finish is the fallback that keeps locating possible.

Lock exposure and gain at commissioning; auto exposure rewrites the image as line-side lighting drifts through the day, and the fixed threshold walks with it (live exposure and gain control shows which settings to pin). Daylight through a window does the same damage; shield it or compensate as covered in ambient light control for pick and place vision.

When is a teach still the better choice?

Keep the teach for parts that break the three assumptions: outlines that are none of circle, rectangle or square, poses that move between cycles, or edges the camera cannot separate — those still need a trained model or extra lighting.

Concretely:

• An L-shaped plate, or a cut-out large enough to split the silhouette into two blobs, defeats the single-blob centroid.
• A camera on the gripper, or parts arriving at varying heights outside the depth of field, kills the fixed-scale assumption.
• Frosted glass on a bright panel gives no separable edge, backlit or not.
• A circle carries no orientation: no script can return an angle a rotationally symmetric disc does not contain.

Those cases want a trained model, a second sensor or a mechanical datum. When sizes vary but stay within one shape family, one calibrated model per variable diameter is the teach-based middle ground. If feasibility is unclear before any code is written, the vision locate feasibility checklist sorts it in an afternoon.

What do you check before switching a cell to database locating?

Pass four gates before you switch a cell over: the geometry is in the database, one article's plate stays fully inside the field, a backlit or high-contrast image thresholds with one fixed level, and the vacuum pick tolerates the ±0.3 mm you measured.

Then run this list on the floor:

• Dimensions exist for every article to run — without them the script has nothing to match, and the cell falls back to teaching.
• The largest plate keeps 10 mm of lit margin at both travel extremes — partial silhouettes corrupt area and centroid together.
• One fixed threshold separates all articles — if each needs its own level, the enter-and-run promise is gone.
• The gates reject a wrong plate — prove it by entering a wrong article number on purpose.
• Twenty consecutive picks log offsets within ±0.3 mm — measured, not assumed.
• Scale and image center re-check after every mount, lens or focus change — the two numbers the method stands on.

Once the list passes, the shop floor enters an article number and the cell picks; nobody freedrives to a starting point again. To size the camera and lens for your own plate sizes, start at the camera configurator, send your largest and smallest outline through the contact page, and find more run-time script patterns on the systems topic page.