Apollo

Apollo is an industrial product, so the most truthful perspective into the ownership experience is how the platform would be deployed and run in an actual plant over a period of months and a production shift or two.

Apollo is delivered using a traditional enterprise manufacturing engagement model, with Apptronik’s field engineers performing a preliminary onsite assessment prior to delivery to address workcell scoping, safety zoning, hot-swap battery systems, networking, and existing-safety-system integration. Physically, delivery is simple; the Apollo robot, infrastructure including charging station and swap batteries, safety equipment and sensors will be delivered by traditional freight and our field engineers will unbox, unpack, calibrate and install a simple workcell in your facility. You can expect your first production-grade workload in eight-to-12 weeks and steady-state production in four-to-five months, significantly shorter than any enterprise humanoid robot on the market today because Apptronik has invested in delivery tools.

Running Apollo on a production line is an entirely different beast from testing other generations of humanoid prototypes. The platform is predictable, boring, and non-invasive, the exact opposite of what one expects from a flashy demonstration. In fact, that’s boring is the operative term here, because this is how you want your manufacturing floor to look. Managers control Apollo via Apptronik’s management software, which hooks into the plant’s existing manufacturing execution system. Line workers tell us they have much shorter adjustment time with Apollo than they do with other, flashier humanoids. The human-scale body and limited range of motion are less startling to the human eye than other human-like platforms. Also, Apollo is not performing. It’s not improvising. It has no extra duties. There is no additional noise on the factory floor. Apptronik’s ethos, if it can be called that, is all about industrial, not demonstration. It’s an ethos that permeates every aspect of Apollo’s design.

The Apollo hot-swap battery design is the most distinctive element of its engineering compared with most other humanoid robots. Each battery will provide about four hours’ runtime under normal manufacturing conditions, and battery swaps will be performed quickly under ten minutes by a well-trained operator. To make sure Apollo can run around the clock, Apptronik envisions the system operating with three to four active battery packs in rotation during a typical shift. A charging station or hub should be located at or near the Apollo’s primary work zone in this scenario. Apptronik’s deployment engineering will cover everything from the optimal way to cycle batteries to the optimal design of the charging stations. Compared to competing humanoids that rely solely on contact or wireless/inductive battery charging (which necessitates returning the robots to a charging station), Apollo’s ability to work continuously throughout the night is a distinct advantage.

Apollo is by far the most operationally mature collaborative industrial humanoid currently available. However, its everyday operation reveals friction points that need to be understood before deploying.

Apollo’s relatively conservative motion is appropriate for shared-floor safety, though some customers do wish there were more aggressive throughput available on tasks where a dynamic response could help. This is an acceptable tradeoff for any Apollo system that is already in successful deployment, and it is a part of the platform’s engineered identity.

Apollo procurement is an industrial business relationship, not a purchase. You must be prepared to enter multi-year contracts, pay for structured deployments and service, and commit to service levels for extended periods of time.

Customers must also work with Apptronik engineering to add new, qualified tasks to their deployed robots, since adding a new workload requires some Apptronik expertise. If you plan to rapidly deploy a task across many SKUs, be aware that you must have a plan for ongoing behavior expansion rather than expecting to self-serve the task authoring.