What Is Physical AI? An Engineer's Definition, Examples and What It Takes to Build

Physical AI, defined

Physical AI

Physical AI is artificial intelligence that perceives the physical world through sensors and acts in it through actuators, so its output is a movement or a physical change rather than text or an image.

Chip makers, cloud providers and consultancies all use the term now. NVIDIA describes physical AI as what lets machines such as factory robots and robotaxis perceive, understand and act in the real world. IBM keeps it shorter: AI systems that operate in and interact with the physical world, rather than only in software.

The idea is older than the name. Robotics researchers have talked about embodied AI for years, and industrial engineers have built machines that sense and react for decades. What changed is the hardware and the models. Perception models got good enough, and accelerators small and efficient enough, to put learned behaviour into products that ship in volume, like drones, mobile robots, vehicles and production-line machines.

One question settles it: if the AI is wrong, does something move that shouldn't? If it does, you're building physical AI, and failure handling matters as much as accuracy.

Physical AI overlaps with two older terms, robotics and embodied AI. As the International Federation of Robotics summarises the ISO 8373 standard, a robot needs a degree of autonomy: the ability to perform intended tasks based on current state and sensing, without human intervention. Embodied AI comes from research. A 2021 survey in IEEE Transactions on Emerging Topics in Computational Intelligence describes it as AI whose agents learn through interactions with their environments, rather than from images, video and text collected from the internet. Physical AI is the newer industry term and the widest of the three. It covers robots, and also drones, vehicles and industrial machines that nobody would call a robot.

How physical AI differs from generative AI

Both use the same families of models, and robots increasingly use generative models to understand scenes and spoken instructions. What differs is what happens to the output.

IBM makes the same point: in software a person can ignore a wrong prediction, while in a physical system the same mistake can be serious. That's why most of the work in physical AI is systems engineering: sensors, control, power, safety and updates. The model is one component among them.

How physical AI works: the loop behind every product

Every physical AI product, from a delivery robot to a vibration monitor that stops a machine, runs the same loop.

Authority and fallbacks come before the model

Before anyone picks a model, someone has to answer a harder question: how much is the system allowed to do by itself? We set autonomy one decision at a time on four levels: a person decides, the system recommends, the system acts within rules, and the system acts within explicit limits. The same drone can steer itself around an obstacle at the fourth level and still need a person to approve a landing in an unknown place.

Every level also needs a plan for the moments when the AI can't be trusted. Sensor loss, low confidence, lost connectivity, uncertain model output, subsystem failure and leaving the operating envelope each need a designed answer before the system is given that authority.

It's far cheaper to write these down at the start than to discover them after devices ship.

Where physical AI runs: device, edge or cloud

A decision can run on the device, at the edge, in the cloud or in an application, depending on latency, connectivity, privacy, compute, power and data. There's no best place in general. Anything that has to happen in a fraction of a second, or while the link is down, runs on the device. Learning across the fleet, long-term analysis and retraining go to the cloud.

Onboard AI uses less power than most people expect, at least next to the motors. On a quadcopter we presented with the Edge AI Foundation, the single-board computer and Hailo-8 accelerator draw several watts during inference, while the four-motor drive draws hundreds of watts in flight. On that system, end-to-end image processing, from capture to post-processing, takes roughly 100 to 300 milliseconds.

We keep one rule here: separate the two. Real-time control runs on its own controller and stays responsible for stability. The AI computer sits next to it and sends requests. If the model crashes or slows down, you lose a feature and the machine keeps working.

Physical AI examples and applications from our projects

Three projects show the same loop at different scales.

A drone that follows a person. For Hover Hero, a coastal-safety start-up, we built a concept-stage proof of concept for a drone that could hover and follow a person and alert wearable devices, built on open-source flight software; object recognition was simulated at that stage. For the next stage, the requirements kept the flight firmware unmodified and put detection in a separate edge-processing module that sends it commands over MAVLink. That's the separation rule from the section above.

A machine that diagnoses itself. iReDS is a vibration-diagnostics product owned and developed by Indeema. In iReDS, AI analyses vibration signals and identifies the type of fault in bearings and other rotating mechanisms, so maintenance can be planned before a breakdown. The output is a work order instead of a motor command, yet the loop is identical: sense, interpret, decide, act, learn.

A drone that counts what it sees. In the onboard AI drone architecture we described for orchards, the vision model runs on the aircraft and sends detections, not raw video, to the cloud, which retrains the model and sends it back to the fleet.

None of them is a humanoid robot, and that's typical. Most physical AI reaching the market over the next few years will be existing machines that sense more, handle a few more situations on their own and improve with each update.

Physical AI applications in other industries

Outside our own work, the clearest examples are in warehouses, on roads and in fields.

Warehouses. Amazon has deployed its 1 millionth robot. Its DeepFleet foundation model coordinates how those robots move and, by Amazon's account, improves the travel time of its robotic fleet by 10%.

Roads. Waymo reports that it more than tripled its annual volume to 15 million rides in 2025, and counted 127 million miles of fully autonomous operation by February 2026.

Fields. John Deere's See & Spray uses camera vision and machine learning to tell crops from weeds, and sprays only the weeds.

Each of these runs the loop described above. And each depends as much on sensors, onboard compute, safety logic and fleet-wide updates as on the model itself.

Questions to answer before you build

It's normal for several of these to be open at the start. It's also where physical AI projects often lose months. Indeema engineers intelligence together with the device that carries it: sensor, firmware, connectivity, data path, model and update path are treated as one design problem. Our page on autonomous and intelligent physical systems shows how we work.

Common mistakes

1. Choosing the model before the authority level

   The team optimises accuracy for a decision the product should never make alone.

   Instead: Set the authority for each decision first, then pick the simplest model that serves it.

2. Letting AI compute control stability

   A slow or crashed model takes the whole machine down with it.

   Instead: Keep real-time control on its own controller and let the AI computer send requests.

3. Treating the first model as finished

   Accuracy drops as conditions in the field drift, with no way to fix it.

   Instead: Plan data return, labelling, retraining and signed updates from the first prototype.