Environment Affordance™ takes your real site data and re-annotates it as an affordance map for one specific platform: its dimensions, its gait, its grasp range, the height its sensors sit at. Then, before anything is deployed, we run the scenes that fool perception systems. What you send in and what you hold back becomes a decision you make with the facts already in hand.
Getting an embodied system into the field takes two different kinds of work. The first is about the environment. Can the robot stand here? Can it get through? Can it take hold? Where does cover end and exposure begin? Those answers follow the physical structure of the site and the things in it, and they barely depend on which task happens to be running. The second is about policy. Which route to take right now, whether to grasp this object, whether to move closer. Those answers follow the task, and they belong to the policy layer.
There is no long-running integration here, and nothing to call continuously. Set beside a conventional simulation engine, we sit closer to the independent verifier that intelligent equipment has to clear before it goes in. A penetration test issues findings before a system goes live. A geotechnical survey issues a site report before anyone breaks ground. We do the same thing for robots: one question answered before deployment, whether this robot can land safely on this site, and the answer is auditable and reproducible.
You get annotation files, a test report and a scenario library. None of it locks you into our stack. The hard part is judgement: what counts as a sound annotation, and which failure cases make a test complete. Not data network effects, and not call volume. Building that standard properly, and patiently, is the work.
For ten years, what we could build and what we had to deliver have pushed each other forward. We have shipped large-scene databases fused from many sources (oblique photogrammetry, point clouds, BIM and satellite imagery), fast loading and smooth visualisation of terabyte-scale 3D data, private deployment across every domestic CPU architecture, automatic generation and standardised scoring of red-team scenes at industrial grade, and geospatial work including viewshed analysis, shadow volumes and openness analysis. Computational geometry and spatial analysis are home ground for us.
Does every new demand call for a new technology? Our answer has been to change the question before changing the toolkit. Embodied intelligence did not send us back to the drawing board. We swapped in a robot for the human observer, which turns reading a site into reading a site for a particular robot.
Reframing the question let us repurpose what we already had. Give 3D environment simulation and spatial analysis the specs of a real platform, and it becomes an environment affordance annotation service. Red-team scene generation and standardised scoring changed its target, from a site to a robot's perception system, and became the Sensor Deception Library. Viewshed, shadow volume and openness analysis, all of them classical geospatial algorithms, made the same swap — a robot in place of a person — and became a toolchain that computes affordance straight from platform specs. Each is detailed below.
Four CPU architectures: ARM (Kirin, Kunpeng), MIPS (Loongson), SW-64 (Sunway) and x86. Operating systems cover UOS and Kylin OS, with HarmonyOS supported.
Everything runs on your own machines. Site data, annotation results and test reports stay on your servers and inside your network from start to finish. No outside cloud in the loop.
This architecture has more than ten years of delivery behind it in mining, energy and other specialized industries, where data sovereignty and domestic compliance are contractual requirements, not preferences.
Affordance comes from ecological psychology and design theory, where it names the actions an environment makes possible for one particular body. A slope affords climbing to a goat and affords a fish nothing at all. A doorway affords passage to an adult and may afford a large robot only a detour. An affordance is not a fixed property of the environment, and it is not a subjective impression in the observer. It is a relationship between environment and body, bounded by the specs of both, and it moves whenever either of them moves.
Same site, same map, different platform, different answer.
As long as the physical structure of the site stays put, so does the affordance, whatever task happens to be running.
Walkable surfaces, clear widths, graspable objects, hazard boundaries. Every one of them can be computed, marked and handed over as a file.
Most deployment validation in embodied intelligence is task-driven. Settle the task first, then build test scenes and validate policy around it. Start from the job to be done and the site and the robot become background conditions serving that job. What you end up measuring is how well this robot performs this task, which is exactly why the traps that do not matter for the current task, and will bite on the next one, stay hidden. Field deployments fail largely on that mismatch: the distance between what a site actually permits and what a robot reads as possible. Ground that looks walkable is not. A channel that looks passable is not. The mismatch usually has nothing to do with the task at all. It is built into the relationship between body and site, and changing the task will not make it go away.
Environment Affordance™ starts from the robot instead. Pin down the dimensions, the gait, the grasp range and the sensor height of this platform, then ask what the site allows it. Where can it stand? Where can it pass? Where can it grasp? Where does it have to go around? What the task is, and whether to act on it now, play no part in this step.
Because affordance is a relationship between environment and body, the range is wider than it first looks. Complex sites qualify, and so do plenty that look simple and controlled.
Down the same length of drift a quadruped walks straight through while a wheeled robot stalls at a pile of loose rock. Ground that looks walkable is not the same as ground a robot can put its weight on.
Maintenance gaps measured one row at a time. Specular glare off module glass. Still water in a settling pond. Echo jumps across galvanised grating. A single site here holds most of the traps a perception system falls into.
Glass partition doors between hot and cold aisles. Polished anti-static flooring. Access hatches under a raised floor. The more uniform and regular a place looks, the more easily it fools a perception system that leans on a depth camera.
A live zone is off limits to every platform without exception. Structural clearance is different: it constrains each platform differently, and the higher a sensor sits, the sooner it meets that invisible line.
The narrow lanes between container stacks are a fixed width, and yet two platforms will reach opposite conclusions about the same lane. A polished floor, or standing water after rain, can be read either way.
In a cold room a lens fogs going in and coming out, and a thin frost forms across floors and racking. Today it scatters light evenly. A small shift in humidity turns patches of it into a mirror.
FIG.05 lays out the whole frame. The site comes down from the top, sensor scale comes up from the bottom, and the two meet in the middle. Platform specs enter at L3. Out come annotations, scenes and reports, and what happens on site feeds back into the loop.
The red team, blue team idea comes from safety testing in specialized industries. We work out in advance which scenes make a perception system look at one thing and see another, write them up as a checklist, and put the robot's own judgement through them one item at a time.
The proving ground is built to manufacture disagreement: scenes where what the site holds and what perception concludes come apart. In one spot, what the robot's perception system reports and what is actually there are two different things.
| Site feature | Perception verdict | What is actually there |
|---|---|---|
| Reflective floor | Standing water | Solid ground, safe to stand on |
| Wet metal grating | Solid footing | Slippery, support unreliable |
| Translucent partition | An open passage | A solid barrier, impassable |
| A hollow hidden by cover | Flat ground | A hollow with a drop |
| An edge in backlight | Open area | A drop or a boundary, and a risk |
The whole flow is in FIG.06. Every scene records what the robot's perception system reported, sets it against the true properties of the site, and feeds a standardised validation report saying which scenes were called correctly, where the call went wrong, and at which stage it went wrong.
The five rows above are an extract. The full library is organised by physical cause, and every entry records that cause, which way the misjudgement runs, the conditions that trigger it, and how to build the scene. Samples are in EA-03 Sensor Deception Library · Scenario atlas.
For cover and exposure we use algorithms already proven in specialized industrial work: viewshed analysis, shadow volumes and openness analysis. Pointed now at the perception limits of a robot inside a site. Is the robot itself in cover or out in the open, and can it pick out a target that is not?
The library is organised by task type, covering inspection, transport, collaborative work and security patrol, and we keep adding to it.
The architecture diagram, FIG.05 above gives the L1 to L5 frame. Below, stage by stage, is what goes in, how it is done, and what you get back.
You supply multi-source data from the real deployment site: oblique imagery, laser point clouds, BIM models, on-site sensor records. Any format. We handle coordinate alignment and fusion.
The sources are fused into a single coordinate system to produce a 3D digital twin of the site, which loads and displays smoothly at terabyte scale. Nothing at this step touches platform specs, so the output stands on its own and any number of different platforms can call it again.
Your platform specs go in: dimensions, gait range, grasp span, sensor height. The base map comes back marked up with walkable surfaces, passable channels, graspable objects, obstacles and hazard boundaries. One site can carry a different annotation for every platform it's asked to serve.
DeliverableAn annotated site map, recomputed whenever platform specs change, reusing the L2 base map with no new surveyFrom the annotation we generate the test scenes that mislead perception: reflective floors, wet grating, translucent partitions, hollows hidden by cover, backlit edges. What the robot reports is set item by item against the true properties of the site, while cover and exposure are checked independently through viewshed and openness analysis. The calls being compared come from your own perception system. Environment Affordance™ neither supplies that capability nor stands in for it.
DeliverableStandardised validation reportYou get a standardised validation report: which scenes were called correctly, where the call went wrong, at which stage. Annotation files, scenario library and report all land together on your internal network. When platform specs change, only L3 and L4 need running again. The outputs of L1 and L2 can be reused as they stand.
The affordance map is the standard L3 deliverable. Here is a working demonstration: one sample solar-plus-storage site, annotated for four platforms. Switch platform and the verdicts, the matrix and the data tables all recompute on the spot, reusing the L2 base map and recalculating the L3 annotation alone.
Open the sample →| General-purpose simulator | Environment Affordance™ | |
|---|---|---|
| The business model | A tool you use to validate for yourself | An independent verifier that delivers the verdict itself |
| Core deliverable | A physics engine or rendering environment | An affordance map annotated to your platform, and a validation report |
| Where scenes come from | You model them, or take them from a generic library | Converted straight from your real site data |
| What “precision” refers to | Numerical precision of the physics engine | Completeness of the affordance |
| Test method | Generic benchmarks | Deception scenes built to your platform and your task |
| Deployment | Mostly SaaS or cloud | Private and local, fully domestically compliant |
| Site data sovereignty | Depends on the provider | Stays on your own servers throughout |
On numerical precision and rendering frame rate a general-purpose simulator has the head start, and this was never the same business anyway. A simulator sells you computing power to take away and use. Environment Affordance™ sells one independent judgement, drawn from your own site data against the specs of a specific platform, in a form a deployment decision can act on.
You need policy validated in simulation before anyone enters a real site. We give you an affordance map and stress scenes built from the site where deployment will actually happen, so policy iteration has something solid to work against before it goes live.
Sim2real transfer and automated evaluation need high-fidelity scenes in volume. We supply scene generation and deception testing built to real platform specs, covering the long-tail conditions a generic benchmark never reaches.
If you run a mine, a substation or a plant, you want a third-party site safety report in hand before a robot goes in. We give you an affordance assessment and a perception risk list drawn from measured site data.
Tell us about your industry, the site you look after, and the problems you have run into. We would like to hear what you have seen, tell you how we read it, and put together a sample report tailored to your situation.
Email, WeChat and other contact details are listed on microNature · About.