Sample
Sheet EA-02 · Deliverable sample 01 / 02

Affordance Map

Affordance Map — a PV and storage plant sample · one site, with passage, reach and exclusion computed separately for four platforms

Plant typeIntegrated PV and storage plant
(example scene)
Site extent520 × 340 m
/ 176,800 m²
Annotated elements①–⑮, 15 in all
/ 7 categories
Target platforms4 types, switchable
Drawing no.EA-DEMO-PV-2026
HOW TO USE

This Robot, on This Site. What It Can Do, and What It Cannot.

Affordance holds between the environment and a body. It is a relation, not a fixed property of the site. So there is no general-purpose version of this drawing. It only means anything once it is tied to one specific robot, and the platform switch below is what ties it. Switch platform and every verdict on the same base map is recomputed, and the graphics, the matrix, the tables, the statistics and the title block all go with it. Switch once before you read on.

Through all of that the L2 base map, meaning the site geometry itself, does not move. Only the L3 annotation layer is recalculated. Watch the right-hand side of the control bar: the L2 checksum holds steady across the switch, next to the elapsed time and element count for the L3 recompute. Those two readings are the proof, on the page, that we reuse the base map and recompute the annotation alone.

Conventions used in this sample
  • Numbering. ①–⑮ run throughout, and each number means one element and one only. Like elements share a number and can appear more than once on the drawing, as ⑦, the inverter rooms, does in three places.
  • Two coding channels. The outline style of an element carries its affordance category, 7 of them, fixed. The fill texture and verdict symbol carry the verdict for the current platform, 4 values, recomputed per platform. Hazard boundaries stay warning red. Everything else survives black and white printing intact.
  • Numbers. Every key data item carries a measurement method code, M1M5, explained in TAB.03. A number without a code does not exist.
  • Verdicts. Every passage conclusion is computed on the spot from platform specs and measured geometry. Nothing is typed in by hand. The reasoning behind each one, margins included, is in TAB.01.

TARGET EMBODIMENTS · where platform specs enter L3

Four Target Platforms

Everything below is the entire input to the verdict engine. Minimum passage width and required clear height are derived, computed from platform dimensions plus a safety margin. Whether a robot fits through a gap comes down to its widest point plus side clearance, not track width.


LEGEND

Two Coding Channels

Channel A | outline style = affordance category, unchanged by platform

Channel B | fill and symbol = the verdict for the current platform, recomputed per platform


PLATFORM
LAYERS
RECOMPUTE
FIG.01 · SITE AFFORDANCE MAP

The Site Affordance Drawing

Plotted at 1:2000. ①–⑮ match number for number with TAB.01. One thing follows from the scale: a 0.50 m maintenance gap comes out under 0.3 mm wide, too small to draw at true width, so it shows up as a leader note with a detail index instead. The real geometry is in FIG.03, the section detail. That is the scale talking, not a gap in the annotation.


FIG.02 · AFFORDANCE MATRIX

15 Elements × 4 Platforms, 60 Verdicts

Put the four platforms side by side and the relational nature of affordance becomes visible. No column is a subset of another. The column for the current platform is shown darker.


TAB.01 · ZONE REGISTER

Item by Item: Data, Provenance, and the Basis for Each Verdict

The basis column recomputes with the platform, and the margin in brackets is a number the engine actually worked out, not a turn of phrase.

Method codes are explained in TAB.03. The basis is computed live by rule(platform), and the whole table refreshes when the platform changes.


FIG.03 · SECTION DETAIL 1:20

Gap ③ in Section: Where 0.50 m Runs Out

Here is the 0.50 m the main drawing is too small to show, at 1:20. The grey dashed box is the passage envelope of the current platform: its dimensions, plus side margins, plus top margin. Lay that over the measured clearance and you can see at once which dimension is doing the blocking. Switch platform and the envelope changes with it.


FIG.04 · VIEWSHED ANALYSIS

What PTZ-01 Can See, and What It Cannot

Mounting a fixed PTZ does not mean it can see. The drawing below runs a two-dimensional shadow-volume computation for a PTZ on a 12.0 m pole. Each occluder outline is projected along the line of sight, scaled by k = (HPTZ − htarget) / (HPTZ − hoccluder) and the convex hull of the original and projected outlines becomes the shadow. That shadow is then subtracted from the circle of effective recognition distance.

Target height is taken from the current platform, so the viewshed depends on the platform as well. The module racking top edge at +2.20 m hides a 0.60 m quadruped completely and hides nothing at all from a UAV at 3.00 m. Coverage is computed by intersecting a 3 m grid point by point. It is not an estimate.


WHY EMBODIMENT MATTERS

Three Gaps, Three Different Answers

③④⑤ are three inter-table maintenance gaps, each measured individually, not one figure shared between them. Put them side by side and you can see why an affordance map cannot be annotated with a typical value.

One element, two opposite verdicts

The sharpest case is not a gap at all. It is ⑭, the PV module surface. To the wheeled, quadruped and UAV platforms it is the most emphatic no-step surface on the site. To CL-P2, the rail cleaning robot, it is the only working surface the site has. Same glass, same geometry, opposite conclusions, and every bit of the difference comes from the platform.

The 13 n/a entries in the CL-P2 column are not missing data either. They are a finding. In this robot's world there is only rail and panel, and most of what stands on the site is not an affordance object for it at all. Change the platform and it is not only the verdicts that need recomputing. Which elements are worth annotating changes too.


TAB.02 · PERCEPTION RISK REGISTER

P1–P5: Five Identified Perception Risks

This register records physical causes and expected directions of misjudgement only, and every entry is still marked To be verified. For a verdict on a specific perception system, see the L4 perception validation report, in preparation. The two documents do different jobs. The affordance map tells you whether a place can be passed. The validation report tells you whether the robot knows that.

Trigger conditions are there so the risk can be reproduced in L4 testing, and the validation item points at the matching entry in the Sensor Deception Library.


TAB.03 · DATA PROVENANCE

Measured, or Inferred

Not every number on this drawing carries the same weight. How a figure was obtained sets its precision, its shelf life, and whether it can carry a passable verdict on its own.

Distribution of data items on this drawing


TAB.04 · RECOMPUTE TRIGGERS

When an Affordance Map Stops Being True

An affordance map has a shelf life, and it has conditions under which it stops being true. Once any of the following applies, the verdicts on this drawing no longer stand: recompute within the stated scope and reissue under a new revision. T1 to T5 all touch the L3 annotation layer and nothing else. In almost every case the L2 base map is reused directly, with no need to survey the site again.


LIMITATIONS

Notes

Limitations · read these with the drawing. The graphics are not to be cited on their own
    Relation to the perception validation report

    Elements ⑫ perimeter fence north and ⑬ retention pond are marked as perception risk zones, as is every entry in P1–P5. All any of them says is that physical conditions here may mislead a perception system. None of them says anything about whether a particular robot gets it right here. That comes from the next sample, the perception validation report: adversarial scenes are built from P1–P5, your own perception system runs them for real, what it reports is set item by item against the true properties annotated here, and out comes a deviation list and a corrected affordance map. For how these physical causes are classified and how each scene is built, see EA-03 Sensor Deception Library · Scenario atlas.