A robot cannot pretend the world matched its assumptions. Wheels slip, sensors drift, batteries sag, and the chair that was not on the map is still very much in the room. This makes robotics a particularly honest kind of software engineering.

Looking inside the machine

When you finally open up a robot, you realize that you are quite literally looking at its brain. Intelligence stops feeling abstract: it becomes boards, cooling, cables, sensors, power delivery, and a physical system in which every software decision eventually has a consequence.

The open torso of a Unitree G1 humanoid robot showing its onboard computers, cooling system, wiring, and sensors
A look inside the Unitree G1. Image shared by Harrison Kinsley; original LinkedIn post ↗

This quick peek inside the G1—and the prospect of a quickly swappable GPU—feels like a step toward humanoid computing as a real platform. More accessible compute could make iteration faster, but it also makes the boundary between model and machine more important. A failed inference is no longer only a bad answer on a screen; it may become motion in a shared space.

Diagram showing a robot sense, plan, act, and adjust loop
The loop only works when each stage expects imperfect information.

Uncertainty is part of the interface

A sensor reading is not simply true or false. It has a timestamp, resolution, confidence, and failure mode. Once those qualities become explicit, downstream decisions improve. The same principle applies to an AI answer or a result returned by a search service.

Robust software does not eliminate uncertainty. It carries uncertainty far enough for the next decision to use it.

Recovery is a feature

In a demo, the happy path is the product. In the physical world, recovery is the product. What happens when localization fails? Can the machine stop safely? Can a person understand what happened and resume without restarting everything?

Designing these paths early changes the architecture. Components become observable, state becomes explicit, and actions become reversible wherever possible.

Safety is a hierarchy, not a feature

As we push the frontiers of robotics and AI, Isaac Asimov’s Three Laws still echo—not as a complete engineering specification, but as a remarkably clear statement that a machine’s goals must have an order:

  1. A robot may not injure a human being or, through inaction, allow a human being to come to harm.
  2. A robot must obey orders given to it by human beings, except where such orders would conflict with the First Law.
  3. A robot must protect its own existence, as long as such protection does not conflict with the First or Second Law.

The difficult part is not writing down the priorities. It is translating words like harm, inaction, and conflict into behavior under uncertainty. Real systems need layered safeguards: bounded actions, independent checks, visible state, human overrides, and a safe way to stop. Ethics has to survive compilation into mechanics.

Build for contact with reality

The lesson I carry from robotics into AI systems is to test with the inputs we wish did not exist: blurry images, contradictory documents, interrupted requests, and unclear goals. Reality is not an edge case. It is the environment.