Apptronik's Robot Park is a robot-learning and deployment network, not one fully autonomous factory. In its June 30, 2026 announcement, Apptronik described an approximately 90,000-square-foot Austin expansion linked with customer and partner sites. Apollo 2, offered in wheeled and biped configurations, is used as a working platform for customer-shaped logistics, manufacturing and retail tasks with a mix of teleoperation, autonomous execution and high-fidelity physical simulation.
The Google DeepMind connection is a model-and-data collaboration. The companies have confirmed a robotics AI partnership and the use of Apollo among the embodiments for Gemini Robotics research. Apptronik says Robot Park data improves Gemini Robotics models and feeds the next commercial product, Apollo 3. It has not disclosed the number of robot-hours, the teleoperation-to-autonomy ratio, task success rates, dataset transfer terms or a public Apollo 3 launch date, price or specification.
Robot Park links an Austin hub to real customer problems
Apptronik's Robot Park announcement describes a network centered in Austin and extending into customer and partner environments. It names Google DeepMind, Mercedes-Benz and GXO as examples in the wider ecosystem. The approximately 90,000-square-foot figure refers to the Austin expansion described by Apptronik; it is a company-published facility figure, not an independently measured total for every site.
The purpose is to expose Apollo to work that originates outside a robotics laboratory. Apptronik names logistics, manufacturing and retail, but does not publish a task-by-task fleet count or performance table. Robot Park is better understood as an operating framework: define useful work, deploy a suitable Apollo configuration, collect physical experience, improve the system and return it to more demanding work.
That loop is narrower and more credible than saying the facility has solved general-purpose humanoid autonomy. Each site still contributes its own objects, layout, people, workflow interfaces and risk controls.
| Robot Park element | What Apptronik says | What remains unpublished |
|---|---|---|
| Austin expansion | Approximately 90,000 square feet | Independent measurement and the portion actively used by robots |
| Network | Austin-centered sites involving customers and partners | Complete site list, robot count and utilization by site |
| Working platform | Apollo 2 has been used in Robot Park for more than a year | Start date, cumulative hours and task-level uptime |
| Data sources | Teleoperation, autonomous execution and high-fidelity physical simulation | Exact mix, sampling rules and retained failure data |
| Industries | Customer-led work in logistics, manufacturing and retail | Per-task cycle time, success rate and intervention rate |
| Next product | Learning is intended to inform Apollo 3 | Launch date, specifications, price and order availability |
Wheeled and biped Apollo 2 configurations collect different experience
The official Apollo 2 page presents both wheeled and biped forms. A wheeled base can prioritize stable movement and repeated task execution on suitable floors, while a biped body targets spaces and transitions where legs matter. Apptronik does not publish a universal rule that one configuration is better; the relevant question is which embodiment matches the site's route, reach and interaction requirements.
Using both forms also broadens the data problem. A manipulation skill may share visual and semantic structure across bodies, but locomotion state, balance, reachable workspace and recovery are embodiment-specific. Training data should retain configuration, sensors, software version, payload and environment so a successful wheeled episode is not treated as direct evidence for a biped run.
Apptronik identifies Artemis as an integrated perception, planning, control, safety and task-execution stack, while Fleet Connect covers robot status, tasks, deployment and data management. Those product descriptions establish intended system roles. They do not publish the safety architecture, autonomous operating percentage or measured fleet availability for Robot Park.
The data flywheel runs from task selection back to deployment
A useful data flywheel is not simply record everything. The first decision is which customer task is valuable and measurable. Operators then demonstrate or supervise work, autonomy attempts it, and the system retains outcomes—including failures, interventions and recoveries—with enough context to reproduce them. Simulation can expand controlled variation, while physical runs reveal contact, latency and hardware effects that simulation missed.
Apptronik says these data improve Gemini Robotics models and prepare the next Apollo product. That is a company account of the loop, not a published causal evaluation. The robot data factory guide explains the governance needed between collection and release: episode identity, hardware and policy versions, consent, filtering, training mixtures, held-out tests and deployment feedback.
The flywheel becomes useful only when a new model is evaluated on a stable task set and its improvement survives real hardware. More hours can amplify repeated easy behavior or operator habits if the sampling rule is poor.
| Flywheel stage | Robot Park activity | Evidence needed to close the loop |
|---|---|---|
| Choose | Select a customer-shaped task and embodiment | Task definition, business value, hazards and baseline |
| Demonstrate | Collect teleoperated examples | Operator, intent, observation, action and outcome labels |
| Attempt | Run autonomous execution | Policy version, confidence, success, failure and intervention |
| Expand | Use high-fidelity physical simulation | Domain assumptions and measured gap to hardware |
| Train | Use data to improve Gemini Robotics and Apollo software | Dataset version, mixture, code and reproducible evaluation |
| Validate | Return the model to physical tasks | Held-out hardware trials, recovery and safety results |
| Productize | Feed learning into Apollo 3 | Documented feature, qualification and support boundary |
.jpg){kind=link}
Teleoperation and autonomous runs answer different training questions
Teleoperation can provide examples of desired behavior and rescue a robot when autonomy reaches a difficult state. Autonomous execution reveals the model's own state distribution, including errors that a skilled operator may avoid. A dataset made only of clean demonstrations can hide recovery boundaries; a dataset made only of failed autonomous attempts may not show a good path through the task.
The useful record connects each intervention to the policy state before takeover, the operator action, the reason for intervening and the eventual outcome. That supports imitation learning, failure mining and recovery evaluation without pretending that a human-completed episode was an autonomous success. The imitation and reinforcement learning comparison explains how demonstrations and reward-driven improvement can complement each other without becoming the same method.
Apptronik has not published the Robot Park split between teleoperation and autonomy, or whether the split changes by task and site. Therefore, neither all teleoperated nor fully autonomous is justified. Its own announcement explicitly describes both forms of execution.
| Data source | What it can teach | Bias or risk | Metric to preserve |
|---|---|---|---|
| Teleoperated success | Desired trajectories and object-handling choices | Operator style and unrealistically clean recovery | Completion, time, corrections and operator identity |
| Teleoperated intervention | Where autonomy became unsafe or ineffective | Late takeovers can mix policy and human responsibility | Trigger state, takeover latency, reason and outcome |
| Autonomous success | Policy behavior under its own decisions | Easy tasks can dominate the dataset | Task condition, success definition and intervention-free status |
| Autonomous failure | Decision boundary and recovery opportunity | Unsafe or corrupted runs require controlled handling | Failure taxonomy, near miss, damage and recovery |
| Physical simulation | Cheap variation and repeatability | Contact, sensors and people may be unrealistic | Simulator version and hardware gap |
| Customer-site episode | True workflow and environment variation | Privacy, ownership and site-specific bias | Consent, contract, site and retention status |
Google DeepMind is a research partner, not the owner of Apollo
Apptronik's partnership announcement and Google DeepMind's Gemini Robotics page confirm collaboration on embodied AI. Google has shown Gemini Robotics across more than one physical embodiment, including Apollo. This supports a model-research relationship; it does not turn Apollo 2 into a Google-branded robot or establish that Google owns Apptronik's hardware.
Google DeepMind's Gemini Robotics 1.5 announcement describes a model family intended to reason and act across physical tasks. Apptronik says Robot Park data help train and improve Gemini Robotics. Neither public source specifies which raw customer episodes are transferred, where they are stored, how long they are retained or which party can reuse them.
Those details belong in customer contracts and data-governance review, not in marketing inference. Ask who controls raw video, robot state, action logs, annotations, derived datasets, model updates and deletion. Our Google physical AI strategy map places Apollo among Google's partner embodiments without treating the partnership as a purchase bundle.
Apollo 3 is the destination of the loop, not a released specification
Apptronik frames Apollo 2 as the current working platform and Apollo 3 as the next commercial product intended to inherit Robot Park learning. That roadmap gives the data program a product direction. As of August 6, 2026, the cited official sources do not publish Apollo 3's final height, mass, payload, battery capacity, launch date, price, order page or certification scope.
Do not carry numerical specifications from the original 2023 Apollo announcement into Apollo 2 or Apollo 3 unless the current product page repeats them. Apptronik's Apollo 2 page presently emphasizes software, embodiment options and system capabilities without exposing a complete numerical specification sheet. Product generations can change mechanics, sensors and power systems even when the family name remains.
Likewise, a model trained on Apollo 2 data does not guarantee the same behavior on Apollo 3. New geometry, actuators, cameras or control rates can require adaptation and regression testing. The robot foundation-model guide explains why cross-embodiment transfer still needs target-platform evidence.
| Apollo 3 statement | Supported now? | Reason |
|---|---|---|
| Robot Park learning is intended to inform Apollo 3 | Yes, as Apptronik's roadmap claim | The Robot Park announcement makes the connection |
| Apollo 3 has a public release date | No | No date appears in the cited sources |
| Apollo 3 has a public list price | No | No official price or order page is cited |
| Apollo 3 specifications equal the original Apollo figures | No | Current-generation specifications cannot be inherited without confirmation |
| Gemini Robotics performance will transfer unchanged | No | Embodiment and task validation remain necessary |
| Apollo 2 Robot Park results prove Apollo 3 production reliability | No | Task-level Robot Park metrics and Apollo 3 trials are unpublished |
A serious evaluation asks for the denominator behind the flywheel
For Robot Park, ask how many robots, sites, tasks, episodes and autonomous hours contribute to each release. Request task success definitions, intervention and recovery rates, failure taxonomy, hardware downtime, maintenance, dataset exclusions and a held-out evaluation that was not used to tune the model. A total-hour figure without task distribution or outcomes would still be incomplete.
For a customer deployment, define which data may leave the site, which derived artifacts can train shared models, how confidential objects and workers are protected, and how deletion propagates into retained datasets. Identify who reviews near misses and who approves a new policy for physical use. A data flywheel without release gates can circulate defects as quickly as improvements.
The public evidence supports a clear, bounded conclusion: Apptronik has built a substantial network and process around Apollo 2, combines human-operated and autonomous physical experience with simulation, and collaborates with Google DeepMind on Gemini Robotics. It does not yet disclose enough quantitative evidence to calculate general autonomy, customer-task reliability or Apollo 3 readiness. The Gemini Robotics ER 2 explainer covers Google's newer high-level reasoning layer separately; it should not be inserted into Robot Park claims unless Apptronik or Google explicitly connects it to the cited deployment.
Frequently asked questions
Is Apollo 2 fully autonomous inside Robot Park?
That is not established. Apptronik says Robot Park data come from both teleoperation and autonomous execution, plus high-fidelity physical simulation. It does not publish the autonomy share, intervention rate or task-by-task success rate.
Does all Robot Park data go to Google DeepMind?
The public material says Robot Park data help improve Gemini Robotics, but it does not disclose which raw or derived data are transferred, the customer filters, retention terms or ownership. Those boundaries require contract-level confirmation.
When can companies buy Apollo 3?
Apptronik describes Apollo 3 as the next commercial product informed by Apollo 2 and Robot Park learning. As of August 6, 2026, the cited official sources do not publish a launch date, list price, final specifications or general order route.
Official sources checked
- Apptronik: Welcome to Robot Park
- Apptronik: Apollo 2
- Apptronik: Google DeepMind robotics partnership
- Google DeepMind: Gemini Robotics
- Google DeepMind: Gemini Robotics 1.5
Last checked: August 6, 2026