Getting Our Hands on Physical AI: What We're Learning in the Field

Like everyone watching this space, we've seen the videos. Humanoid robots walking, sorting, folding — the demos are polished, and the potential is real. But we kept coming back to a question the videos don't answer: what does it actually take to put one to work on a real task, in a real environment, with real consequences for getting it wrong?

We didn't know. So we decided to find out.

Solving a real problem on a real floor

This work grew out of a long-term partnership with a large food and beverage manufacturer — a relationship that began, as many do, in technical infrastructure. Over years of working together on compute, networking and data architecture, we built the kind of operational trust that makes it possible to have a different kind of conversation: not what technology do you need, but what outcomes are you trying to achieve and what's standing in the way.

That conversation led us to the plant floor. Their production lines shift frequently, sometimes daily, based on what's being made that shift. That variability makes traditional fixed automation impractical, and it had created a persistent operational constraint that no infrastructure refresh was going to solve. The right next step wasn't a hardware recommendation. It was getting our hands on the problem.

At the center of each line sat a specific manual task: a worker scoops ingredients from a large container and transfers them into a hopper, which distributes the correct amounts into packaging as it moves along a conveyor belt. It's repetitive and physically demanding work, but not continuous. Because the line configuration changes with the schedule, the task itself appears and disappears along with it.

That intermittency is the economic problem. A purpose-built machine for this task would be a fixed capital asset tied to a single job on a single line. When that line runs something different — which is most of the time — the machine sits idle. The utilization math doesn't work, and the manufacturer knew it. What they needed was a flexible asset that could be deployed where and when the work existed, and redeployed when it didn't.

Our client wasn't new to this conversation. They came to us with operational specificity — defined problems on defined lines — and with internal stakeholders who had already heard the vendor pitches and weren't moved by them. The question they were asking wasn't "could a robot do this?" It was whether a robot could do this reliably and consistently, and at a cost structure that justified the investment over fixed automation they'd already decided didn't work.

That's a harder question than it sounds, and it's the right one. Part of our job was designing an engagement that could answer it — not with a demonstration built to impress, but with a structured evaluation that would hold up to scrutiny from the people in the room who needed more than a good video.

Separating hype from readiness

What we brought to this engagement wasn't a product recommendation; it was a commitment to answer the question honestly. That meant designing a structured evaluation built around the client's actual environment, their actual task and their actual constraints. Not a vendor demonstration. Not a controlled showcase. Work done on the problem itself.

The distinction matters because it changes what the engagement is for. Our job wasn't to tell this client what they should think about the technology. It was to generate real evidence — about what this robot can do, what it can't do yet and what it would take to close the gap. If the work proves the solution is ready, the client has the data to move forward with confidence. If it proves the technology needs more time, that's equally valuable. It's the answer they need before committing capital, not after.

That's what working on a problem alongside a client actually looks like. Not managing expectations. Doing the work.

How to train a robot

We conducted our evaluation with the Unitree G1 — a humanoid robot about four feet tall with two arms, two legs, dexterous hands and integrated sensors including a RealSense depth camera. Running pre-programmed functions is straightforward. Getting it to perform a dynamic, repeatable task in a variable real-world environment is a different problem entirely, and the work starts well before the robot ever gets near a production floor.

The first phase of that work is teleoperation and training data collection. A team member wears a Meta Quest VR headset that maps their arm movements one-to-one to the robot's arms in real time. We built a controlled environment — a container, a bucket attached to the robot's hand, packing peanuts standing in for the actual ingredient — and recorded multiple episodes of the scooping motion under human control. Each recording captures two things simultaneously: what the robot saw through its cameras and the precise joint positions at every moment. That paired data becomes the training set.

It's unglamorous work. It has to be done before anything more sophisticated is possible.

From that foundation, we're building separate models for distinct phases of the task — scooping, dumping, lower-body navigation — rather than training a single end-to-end model that would compound complexity before we've validated the simpler components. In parallel, a second approach uses reinforcement learning entirely in simulation, without teleoperation data. Running both methods side by side lets us evaluate where each holds up rather than committing to a single training strategy before we have the evidence to justify it.

None of this is deployment. It's the foundational work that determines whether deployment is ever warranted, and doing it carefully is what separates an informed investment decision from an expensive guess.

What the training data must get right

A model trained in a controlled environment will perform well in that environment. Put it on a real plant floor — where light sources shift throughout the day, floor surfaces reflect differently depending on what's been cleaned and when, and the container in front of the robot is a different color than the one in training — and it will show exactly where the training data stopped. That brittleness isn't a robot problem. It's a data problem, and it's predictable.

We design for it from the start. Training data is deliberately varied across scooping angles, positions and lighting conditions — not because it's more work, but because a model that can only perform in the conditions it was trained on isn't a model ready for a manufacturing environment. We're also using synthetic data augmentation: simulation tools that generate training scenarios with varied reflections, surfaces and light sources that would be impractical to recreate physically at scale. The goal isn't a model that works in our test setup. It's a model robust enough to handle the natural variability of an actual floor, which is a meaningfully higher bar, and the one that actually matters.

Safety planning starts early

Safety isn't evaluated at the end of this process. It's designed into it from the beginning.

Before any trained model runs on the physical robot, it runs in simulation — not as a formality, but as a hard gate. The simulation environment lets us identify erratic or unsafe behaviors under conditions that would be dangerous or destructive to encounter first on the real platform. A model doesn't leave simulation until it demonstrates consistent, controlled behavior across the range of scenarios it will face in deployment.

The safety architecture for a real plant floor deployment goes further. A robot operating near people requires proximity detection and shutdown systems that respond faster than any human supervisor can. In a food manufacturing environment, the robot itself must meet materials and cleaning standards — not an afterthought, but a specification that shapes hardware selection from the start. The operational model must account for battery endurance across long shifts, which means designing a charging strategy and, in some cases, including unit rotation in the deployment plan before the first robot arrives on the floor.

These aren't obstacles discovered late. They're engineering requirements that get resolved before deployment is on the table, which is exactly why the evaluation phase exists.

Form factor and intelligence are not the same thing

The intelligence layer of a robotic system and its physical form factor are entirely separate design decisions. Computer vision, model training and the decision-making that let a robot perceive its environment and act on what it sees, none of that is determined by whether the platform has two legs or four, arms or a fixed mount. A highly capable robotic arm can make real-time, context-aware decisions. A humanoid platform is only as capable as the models running it.

This matters because form factor selection is a design question that should be answered by the task, not by what looks most impressive. The right platform for a given job is the one that performs it reliably, safely and cost-effectively, which is exactly what the evaluation is designed to determine. The evaluation is structured around that question — not to validate a single platform, but to determine which approach actually fits the job.

For this engagement, we evaluated the Unitree G1. Its bipedal design introduces specific engineering considerations: balancing the robot as it lifts weight away from its center of mass adds computational load that a fixed-mount system doesn't, and payload tolerance is constrained in ways that matter when the ingredient being scooped has real mass. These aren't disqualifying findings — they're the findings the evaluation exists to surface.

Whether a humanoid platform is the right answer for this task is still an open question. That's not a hedge. That's the work.

What we're taking forward

The work with the Unitree G1 has sharpened our understanding of what rigorous physical AI evaluation actually requires and reinforced why the evaluation phase exists before deployment is ever on the table.

Task decomposition is the right architecture for this stage. Breaking the target behavior into discrete, trainable subtasks — scooping, dumping, navigation — is more tractable than attempting end-to-end training before the simpler components are validated. The complexity compounds fast when you skip that sequence, which is why running teleoperation-based imitation learning and simulation-based reinforcement learning in parallel was the right call. Two methods, same task, real comparative data.

Training data quality is the foundation on which everything else rests on. Volume without variety produces brittle models. Shortcuts in data collection show up as failures in deployment conditions, not in the lab.

Simulation is a hard gate, not a step that can be skipped when timelines get tight. A model doesn't run on the physical robot until it has demonstrated safe, controlled behavior in simulation first. That discipline holds regardless of schedule pressure.

And the most valuable thing we can offer a client considering this technology is an honest picture of where it stands today versus where it is going — grounded in work we've done ourselves, not in vendor demonstrations built to impress. That's what this evaluation is. It's also what the next phase of this work will be.

What this means for your organization

If you're in manufacturing, logistics, food production or warehousing — anywhere physical, repetitive tasks create variability that fixed automation can't cost-effectively address — robotic automation is worth evaluating seriously. Not because of what the demos show. Because of what a disciplined evaluation can actually tell you about whether the economics work in your specific environment.

The path from a promising capability to a robot running reliably on your floor runs through task analysis, deliberate model training, safety architecture and an honest assessment of which form factor is right for the job. That sequence isn't optional, and it isn't short. But organizations that build real, hands-on experience with it now, rather than waiting for the technology to arrive fully formed, will be meaningfully ahead when deployment becomes the conversation.

That's the work we did with this client. It's the work we'd do with yours.

WWT's AI and Data practice is actively engaged in physical AI evaluation and deployment across manufacturing and industrial environments. If you're considering where robotics fits in your operations or whether it does, reach out to your WWT account team. We'll start with the evidence, not the pitch.