Worked with · 11 of 12Humanoid robotsapptronik.com
Apptronik
I collaborated with the Apptronik team on work around embodied AI, humanoid deployment and the gap between a robot that performs well in a controlled demonstration and one that can work reliably in a real environment.
Never quite static
A large part of my work focused on that transition. Industrial environments are repetitive in some ways, but they are never completely static. Objects move, people enter the workspace, layouts change and tasks that look identical at a high level can require slightly different manipulation every time.
Fig. 1Repetitive, never static
- Objects move
- People enter the workspace
- Layouts change
- The same task, slightly different manipulation
Learning from variation
I spent time looking at how Apollo could learn from those environments without treating every variation as a new task. That meant thinking about the relationship between perception, task planning, manipulation and the physical limits of the robot itself.
Fig. 2Four parts of one behavior
- PerceptionWhat the robot sees
- Task planningWhat it decides to do
- ManipulationHow it handles the object
- Physical limitsWhat the robot itself can do
Data
Data collection was an important part of the work. Humanoid systems need experience from real tasks to improve, so deployment also becomes a source of training data. I looked at what information was useful to collect, how teleoperated and autonomous behavior could be compared, and how failures could be turned into examples for the next training cycle.
Fig. 3Deployment as a source of data
- 01Real tasksThe robot at work
- 02CollectionTeleoperated and autonomous
- 03FailuresCould become examples
- 04Next cycleTraining, then back to work
Reliability
Reliability mattered more to me than isolated success. A robot completing a task once tells you much less than the same system completing it hundreds of times while handling small changes in object placement, timing and surrounding activity. I was interested in where performance started to degrade and whether the cause came from perception, planning, control or the physical interaction itself.
Fig. 4Once, and then hundreds of times
Schematic, not data
Around people
Human interaction was another part of the problem. Apollo is designed for workplaces that were built for people, which means the robot has to share space with existing workers and equipment. That makes predictability, safe motion and recovery behavior part of the system design rather than something that can be added after the core task works.
Fig. 5Designed in, not added later
- Predictability
- Safe motion
- Recovery behavior
Hardware and models
I also looked at the feedback loop between hardware and embodied AI. Better models can improve what the robot understands and how it chooses an action, but the training data still comes through a physical platform with its own sensing, dexterity and mobility constraints. Changes to one side affect what is possible on the other.
Fig. 6Two sides of one loop
Models
- What the robot understands
- How it chooses an action
The platform
- Sensing
- Dexterity
- Mobility
What I took from it
The work gave me a better way to think about humanoid robotics. The difficult part starts after a capability works in a demo. The real question is whether the same behavior survives repeated use, unfamiliar situations and the ordinary messiness of a workplace.
Materials
Public pages about the company and the programs around this work.
Screenshot, Oct 5, 2026
Apptronik · June 2026
Welcome to Robot Park: where Apptronik’s Apollo goes to work
Fleets of Apollo 2 robots collecting real-world data across Robot Park sites, in a research partnership with Google DeepMind.
Further reading