The 146 millimetre square your inspection round depends on

Boston Dynamics publishes a developer documentation set, currently at the version labelled Spot 5.1.9, and its pages on autonomy initialisation are unusually direct about the physical world the robot needs around it.

Spot localises in part against fiducials: printed markers from the AprilTag Tag36h11 set. The documentation gives an image size of 146 mm square, and then explains why that number is not a suggestion: “Spot is configured to treat fiducials as 146mm squares and computes the distance based on that size. If a fiducial is printed at another size, Spot will infer the wrong position.”

Read that as an operator rather than an engineer. The robot derives how far away it is from how large the marker appears. The size is a constant in the robot, not a measurement it takes. So a marker reprinted to fit an A4 sheet, scaled by a print driver, or reproduced by a facilities team who had the image but not the specification does not fail loudly. It produces a confident, wrong position.

That is a different class of problem from a robot that stops. A machine that halts creates a ticket. A machine that is quietly mislocalised completes its round and reports success.

The size is the sharpest requirement but not the only one. The same documentation sets out where fiducials go and where they must not:

• One at the mission's starting location, required at the beginning of every Autowalk mission.
• Taped flat against a vertical wall, as securely as possible.
• At knee height — the top of the fiducial image 45 to 60 cm above the ground.
• In feature deserts, the documentation giving a span of over three metres of featureless white wall as the example.
• Not repeated — the same fiducial should not appear multiple times in a single mission.
• Not in inconsistent or backlit lighting.
• Not where they will be blocked, damaged, moved, or removed.

That last line is the one worth pausing on, because it is the only requirement on the list that cannot be satisfied at installation. Size, height and placement are all decided once, by whoever commissions the robot. Whether a marker is later blocked, damaged, moved or removed is decided over the following three years by people who were not in that conversation: the contractor who repaints the corridor, the team who mounts new signage at exactly knee height, the cleaner whose machine catches the corner of a taped edge.

The documentation states the consequence without hedging: if fiducials move after recording, the mission may no longer replay.

That single sentence relocates the whole subject. Up to that point, fiducials look like a commissioning detail — something the integrator does once, correctly, and then forgets. After it, they are a live dependency between the autonomy and the building's own change process, and the building's change process has no idea it is participating.

Consider the ordinary sequence. A corridor is redecorated over a weekend. The markers are taken down carefully, because the contractor is conscientious, and put back afterwards in what is visibly the same place. Nobody measured. The height is within a few centimetres, the position within a hand's width, and the tape is fresh. On Monday the round runs. Whether it runs correctly is now a question nobody in the building can answer, because the person who could is the one who recorded the mission months earlier.

None of this is a criticism of the robot or of its documentation. The behaviour is specified, published and easy to find. What is missing is not information. What is missing is an owner.

The markers are the visible part of the site configuration. The map is the larger and less visible part, and it behaves differently in one respect that matters commercially.

In the same documentation, a GraphNav map is described as three things: waypoints, which are reference frames with names, unique identifiers, annotations and sensor data; edges, directed connections carrying a 3D spatial transform between two waypoints; and snapshots, the data packages stored at each. Waypoint snapshots hold geometry and image data used for localisation, including feature clouds, AprilTag detections, imagery and terrain maps. Edge snapshots hold the robot's footstep locations.

Crucially, the documentation states that maps stored on client computers can be uploaded to the robot for reuse, and cautions that recording new maps might move waypoints and edges in a recorded map out of the cache. In other words the map is a file. It can be held, copied, versioned and archived by whoever decides to hold it.

That makes it an asset in the ordinary sense, and it raises the question that never gets asked at go-live: who has a copy. The mapping effort is real work — the walk-through, the recording, the corrections — and it is usually performed by the integrator or the manufacturer's field team. If the only copy lives on their laptop, the operator has paid for an asset they do not hold. This is the same exposure examined from the commercial side in what an operator actually loses when a robot supplier goes under.

Ask on any live site who is responsible for the fiducials and the answer is usually a pause. The candidates are all plausible and all wrong on their own.

• Facilities maintain the building but were handed a robot, not a specification. Nothing in their asset register mentions a 146 mm square.
• The cleaning contractor is in the corridor nightly and is the party most likely to notice damage, and least likely to have been told it matters.
• The integrator commissioned the markers and typically leaves after go-live. Their contract usually ends at acceptance.
• The robot manufacturer published the specification and has no presence in the building.
• The operations team owns the outcome of the round and has no way of knowing that the round's precondition has changed.

The gap is not technical. It is that a physical object with an engineering tolerance was installed into a building whose maintenance regime handles physical objects without tolerances. Paint, signage and fixtures are all replaced on a like-for-like judgement by eye, and by eye is exactly the method that fails here.

The related pattern — site infrastructure that decides whether a robot project works, and that nobody costed — runs through lifts, fire doors and wireless coverage as well, covered in what decides hospital and hotel robot projects, and through the on-site portion of commissioning in how a robot learns your building.

The fix is administrative, it costs almost nothing, and it has to happen at go-live because that is the only moment when everyone involved is in the same room.

1. Put the markers in the asset register, with location, height and the specified size. A register entry is what makes them visible to a maintenance regime that otherwise cannot see them.
2. Record the specification, not just the image. Anyone who may ever reprint one needs the size in millimetres, not a file. A printed sheet in the facilities file is sufficient.
3. Add a line to the redecoration and refit checklist: markers are not to be moved, and if they must be, the deployment owner is told before the work, not after.
4. Brief the cleaning contractor once. They are in the corridor more often than anyone else and are the cheapest possible early warning.
5. Hold your own copy of the map, with a date, and agree in the contract who provides it and in what form.
6. Re-verify after any building work in an area the robot covers, before the next unattended round rather than after it.

An operator who does all six has converted an invisible dependency into a two-line item on a schedule that already exists. That is the whole intervention.

Three qualifications, because the specifics above are exactly that — specific.

Not every robot uses fiducials. The 146 mm figure and the placement rules are Boston Dynamics' documented requirements for Spot, read at documentation version 5.1.9. Many mobile robots localise from LiDAR and camera features alone and need no markers at all. The question to ask of any given machine is what its site preconditions are, not whether it has fiducials.

Different machines have different site dependencies. A cleaning robot may depend on a docking position and a defined no-go zone; a transport robot on a lift interface and a door release. The general point survives translation even when the specific object does not: something physical in the building is a precondition, and it needs an owner.

Documentation depth varies, and that is itself information. This article could be written precisely because Boston Dynamics publishes a versioned developer manual that states the number and the failure mode. Where a manufacturer publishes only a product brochure, the same preconditions still exist — they are simply not written down anywhere the operator can read them. Asking for the site-preparation document before signature is a reasonable tender requirement, and the answer tells you something either way.