Building My Own Tool Scanner — Part 13: Z Has Entered the Chat
The accepted A3 calibration described the glass plane.
A ratchet, somewhat inconveniently, wasn't a flat drawing on the glass.
The visible outline existed at different heights above the plane. From the overhead camera, raised geometry appeared enlarged. Better dot calibration couldn't supply the missing height information by itself.
A useful real-world reference
Once the bed-plane measurements were behaving, the next problem was staring me in the face. Tools aren't printed on the calibration sheet. They sit above it. A thin ruler and a chunky ratchet don't present their edges to the camera at the same height, and the camera is looking down from a finite distance. So even with a perfectly mapped glass surface, the apparent outline of a raised object can be larger than its actual footprint.
The ratchet measured 144.89 × 24.84 mm, with a reported height range from zero to 12.2 mm.
Without height correction, one scan returned 148.00 × 25.60 mm. Another returned 148.50 × 25.80 mm.
That was several millimetres of length enlargement from a system with much smaller bed-plane calibration errors.
A larger tool illustrated the effect more strongly: a reported 66.3 × 66.3 mm footprint and 57 mm height produced a scan around 78.8 × 78.6 mm.
The mapping could be doing its intended plane-coordinate calculation while the object didn't exist on that plane.
Which height belongs to the silhouette?
The ratchet was a useful test because it wasn't a tidy block with one height everywhere. There were sections at different levels. That made the question more interesting than simply measuring a known cube and applying one scale factor. Which height should represent the edge the camera is seeing? A correction based on the tallest point might be wrong for the handle. A correction based on the bed would ignore the problem entirely.
Using the maximum tool height for the entire profile wasn't necessarily right either.
A ratchet has different sections at different heights. The boundary visible to the camera isn't automatically generated by the highest point of every section.
For the initial correction, the midpoint of the reported height range was used: an effective Z of 6.1 mm.
The implemented model used an adopted optical-height parameter of 365 mm. A tape measurement around 370 mm was useful context, but it wasn't a precise independent optical calibration.
The scale factor was:
(camera height − effective Z) / camera height
For the ratchet's 6.1 mm effective height, that gave 0.983287671.
The code applied one uniform scale about the workspace centre. It didn't infer a different height for every visible point, and it didn't contain a separately fitted local spatial-correction model.
An explicit effective height could be supplied, or the midpoint calculated from entered minimum and maximum heights. Leave the height blank and the measurement stayed uncorrected.
Show the spread, not just the lovely result
I wanted the results from different positions, not just the one that looked brilliant. A correction that works in the centre and falls apart near the corners isn't ready to be treated as a general solution. Showing the spread matters. If one reading is close to perfect and another is several tenths out, the average alone can make the whole thing sound much better behaved than it actually is. The position tests were there to make that visible.
An early corrected scan measured 145.60 × 25.20 mm. That substantially reduced the enlargement, but left a useful reason to keep testing.
Moving the ratchet around the bed produced the following recorded results. All these corrected runs used the same effective Z.
| Corrected placement run | Measured length | Measured width | Length error | Width error |
|---|---|---|---|---|
| 1 | 144.900 mm | 25.000 mm | +0.010 mm | +0.160 mm |
| 2 | 145.400 mm | 25.000 mm | +0.510 mm | +0.160 mm |
| 3 | 144.800 mm | 25.100 mm | −0.090 mm | +0.260 mm |
| 4 | 145.200 mm | 25.100 mm | +0.310 mm | +0.260 mm |
| 5 | 145.200 mm | 24.900 mm | +0.310 mm | +0.060 mm |
| 6 | 144.900 mm | 24.700 mm | +0.010 mm | −0.140 mm |
The +0.010 mm length result is pleasing. The rest of the table is why it isn't a ±0.010 mm scanner specification.
Moving the object tested the correction across the bed; it did not add a new position-dependent model.
Two later scans on 5 October both reported 144.700 × 24.600 mm, giving errors of −0.190 and −0.240 mm. They agreed at the reported precision. The accompanying print was in progress; the surviving conversation doesn't establish its eventual fit.
The workspace has a height problem too
The correction also had to remain optional and explicit. I didn't want Titan silently assuming every tool had the same effective height, or pretending it had constructed a complete three-dimensional model from one photograph. For a tool with a reasonably uniform profile height, a supplied Z value can make a useful difference. For something irregular, it's an approximation that needs checking against the physical object.
Tall tools could appear close to or outside the calibrated boundary even when their physical footprint seemed to fit on the bed.
They had to be positioned with their visible projected outline in mind. A correction applied later couldn't recover a contour already rejected at the boundary.
That was another reason not to describe the nominal calibrated rectangle as guaranteed useful placement space for every raised object.
An accepted release still needs the right client
This was another reason not to get carried away with calibration figures. The reference plane can be excellent and a raised object can still measure incorrectly. That's not a contradiction. They're different geometries. The sensible solution was to preserve the verified bed mapping, add a separate height correction where justified, and keep the evidence for how well that worked on actual tools.
The A3 B-spline workflow was adopted in the repository on 4 October, with C920 material archived rather than discarded.
The new scanner wrote to Production Scans, while an older client contract expected titan_scans. Repository integration work addressed the change, but the active desktop copy still lost access to new scans and needed a subsequent repair on 5 October.
Supporting both exact final Fusion paths restored the library without letting diagnostic SVGs become authoritative profiles.
By this point, Titan had a usable A3/glass workflow, explicit height correction and real-object evidence. It could make practical measurements without pretending to know geometry the camera couldn't see.
Later testing would reveal a rather different failure.
The processing could be entirely competent and still be measuring the wrong tool, because the camera wasn't necessarily supplying a new photograph.
Next: Part 14 — The Scanner Worked. The Camera Wasn’t Taking Pictures.