Field log · ARCore

Measuring a child's height with ARCore

The pitch was simple: point your phone, measure how tall your kid is, plot it on a growth curve. The AR part was the easy 20%. The other 80% was accuracy — and the fix that mattered most wasn't clever computer vision, it was a humble calibration step.

I wanted an app that measures a child's standing height from the phone camera and drops that number onto standard growth percentile curves, so a parent can see where their kid sits over time. ARCore gives you the raw capability — understand the floor, place points in 3D space, measure the distance between them. Getting from that capability to a number a parent will trust is the entire project, and it's mostly a fight with error.

The three accuracy problems

1. The floor is a guess

ARCore builds its sense of the world from detected planes, and the floor plane is the reference everything else hangs off. In good light on a textured floor it's solid. On a plain, glossy, or dim floor, the plane can sit slightly above or below the real surface, and every measurement inherits that offset. A centimetre of floor error is a centimetre of height error, invisibly. You have to design the flow to get a good plane first — move the phone, let tracking settle — before you let anyone measure anything.

2. Where exactly is the top of the head?

A tape measure touches the crown of the head. A camera has to decide where that is, and hair, posture, and a wriggling child all conspire against you. Marking the top point is where most of the run-to-run variation came from — the same child measured twice, seconds apart, could differ by more than the floor error did. This is the human-input problem, and no amount of AR precision downstream saves you if the point you started from wandered.

3. Drift over the session

ARCore's world tracking is relative and accumulates small errors as the phone moves. Take too long, walk around too much, and the coordinate you placed thirty seconds ago has quietly shifted. Fast, deliberate measurements beat slow, careful ones here — the longer the session, the more drift you bank.

Why calibration carried everything

Absolute AR measurement is at the mercy of the floor plane, the device, and the lighting — all of which vary. But if you first measure a reference of known height in the same conditions, the difference between what the app reports and the truth is your systematic error for that session. Apply that same correction to the child's measurement and most of the floor-and-device error cancels out, because it was present in both. It doesn't fix the top-of-head input problem, but it removes the single largest source of between-session inconsistency. A slightly tedious calibration step bought more accuracy than any tweak to the measurement math.

The other half: turning a number into meaning

A height in centimetres is data, not insight. The value for a parent is where does this sit for a child this age and sex — the percentile. That means plotting the measurement against standardized growth references (such as the WHO child growth standards, and locale-specific ones like the KDCA charts in Korea). The engineering there is unglamorous but exact: store the reference curves, interpolate to the child's precise age, and place the measurement as a percentile. This is the part that makes the app feel like more than a novelty ruler — and it's a good reminder that the domain data (the growth curves) is as much of the product as the AR.

What I'd tell myself starting over

• Budget your time by error source, not by feature. The AR SDK call was an afternoon; accuracy was weeks. Plan for that ratio.
• Make error correctable instead of chasing perfection. A calibration step against a known reference beat every attempt to make the raw measurement absolutely right.
• The human input point is your biggest variance. Design the UI to make marking the top of the head as unambiguous and repeatable as possible.
• Fast measurements beat careful ones when your tracking drifts over time.
• The reference data is half the product. A number without a percentile is just a number.

None of these are ARCore-specific tricks — they're what any real-world measurement app teaches you. The camera can tell you a distance; making that distance true and meaningful is the actual work, and it lives in calibration and domain data far more than in the AR API.

This describes a hobby engineering project. A phone-camera measurement is not a medical instrument, and growth-percentile results from such an app should never replace a clinician's assessment — treat any concern about a child's growth as a conversation for a doctor.