Physical AI Systems
Intelligence that acts in the physical world.
Software that only produces text can be wrong quietly. Software that moves a motor cannot. Physical AI is where perception, inference and control meet a machine that will do exactly what it is told, including the wrong thing.
Failure behaviour is a design input. Before we write the control loop, we write down what the machine does when the sensor lies, the network drops and the model is uncertain. If that document is uncomfortable to write, the design is not finished.
The problem
The loop is the system.
A perception model is judged on accuracy. A control loop is judged on what happens between two frames — latency, jitter, the state it holds, the recovery path when the input goes missing. Teams that come from pure machine learning tend to optimise the first and discover the second in the field.
We treat sensing, inference and actuation as one closed loop with a defined budget for time and a defined answer for every degraded state.
Scope
What the work usually includes.
- PerceptionVision, depth and signal processing tuned for the actual optics, lighting and mounting, not for a benchmark set.
- Sensor fusionCombining sources with different rates, latencies and failure modes into one state estimate that degrades gracefully.
- On-device inferenceModel selection, quantisation and scheduling to fit the compute and thermal budget of the target hardware.
- Control loopsDeterministic timing, bounded actions, explicit safe states and a defined path back from every one of them.
- Fleet telemetryObservability from the device upward: what it saw, what it decided, what it did, and how long each took.
- Update pathSigned, staged, reversible updates — because a device you cannot safely change is a device you cannot fix.
On safety certification. Where a system falls under a functional-safety or machinery standard, we work alongside your certification body and supply the engineering evidence they ask for. We do not issue conformity assessments ourselves.
Sequence
From bench to field.
Characterise
Measure the real environment: sensor noise, latency, vibration, lighting, duty cycle. Assumptions get replaced by numbers.
Close the loop early
A crude end-to-end loop on the target hardware beats a perfect model on a laptop. It surfaces the timing problems while they are still cheap.
Harden the edges
Degraded modes, watchdogs, safe stops, recovery. This is the part that decides whether the system survives contact with reality.
Instrument and hand over
Telemetry, update path, spare-parts reality and the documentation your maintenance people will actually use.
Deliverables
What is on the table at the end.
Deployed loop
Running on the target hardware with measured timing, not on a development board with a promise.
Failure-mode register
Every degraded state, its trigger, its detection, and the behaviour the machine falls back to.
Telemetry and update path
Dashboards for the fleet and a signed, reversible way to change what is running on it.
Have a machine that should decide for itself?
Tell us what it senses, what it moves and how bad a wrong decision would be. That last answer shapes everything else.