Official T800 computing configurations
| T800 edition | Base computing | High-computing module listed by EngineAI | Secondary development | |---|---|---|---| | Basic | Eight-core high-performance CPU | Orin NX 16GB | Not listed | | Open Source | Eight-core high-performance CPU | AGX Orin 64GB; Thor upgrade on request | Listed | | Pro | Eight-core high-performance CPU | AGX Orin 64GB; Thor upgrade on request | Listed | | Max | Eight-core high-performance CPU | AGX Orin 64GB; Thor upgrade on request | Listed |
The official table therefore separates a base CPU from a high-computing module. It does not say that every workload runs on one processor, and it does not publish a complete task allocation for URKL fighters.
The configuration must be evaluated together with the sensors and development rights of the same edition. For example, Basic pairs its listed Orin NX module with a binocular camera and no listed secondary development, while the other editions list 3D LiDAR and secondary development.
For the wider platform context, see our robot specifications and profiles.
“16GB” and “64GB” describe memory, not total performance
Memory capacity matters because perception models, runtime components, maps, buffers and logged data need resources. A larger memory configuration can reduce pressure when several substantial workloads share a system.
But 64GB is not “four times the combat intelligence” of 16GB. Computing performance also depends on the processor architecture, available accelerators, memory bandwidth, software optimization, clocks, power mode, thermal behavior and the actual models being run.
EngineAI’s T800 page does not publish a like-for-like frames-per-second, inference-latency or whole-body-control benchmark for these modules in a fighting configuration. A responsible comparison should not invent one from the memory figures.
NVIDIA’s own documentation treats module performance and power as configuration-dependent. Its Jetson Orin guidance describes power modes, thermal sensing, active cooling and software or hardware throttling. A robot integrator therefore has to test the complete workload under the selected operating mode, not rely on a product-family headline.
Which computing tasks does a humanoid need?
A fighting or research humanoid can contain several computing layers with different timing requirements.
1. Device and joint-level control
Motor drives and low-level control handle fast actuator feedback. These functions need predictable timing and should not depend on a remote model responding whenever network conditions allow.
2. State estimation and whole-body control
The robot estimates its configuration, motion and contacts, then coordinates many joints while maintaining balance. These workloads use fresh body-state information and tight local feedback.
3. Sensor processing
Camera and LiDAR pipelines may perform image processing, depth estimation, spatial mapping, localization, detection or tracking. Their cost depends on resolution, update rates, algorithms and how much processing is shared across tasks.
4. Policy and action selection
A learned policy, planner or human interface can select high-level actions. The required compute varies widely: a compact controller and a large perception-action model are not equivalent workloads.
5. Logging and development
Recording sensor streams, running diagnostics, visualizing state and deploying new software can consume substantial compute, memory, storage and bandwidth. Development workloads may need to be isolated from safety-critical control.
The public T800 table does not map each of these tasks to a named processor. That mapping is an integration detail buyers should request rather than assume.
Why fast control should remain local
A humanoid cannot pause its physics while waiting for a network response. Balance and contact control need fresh observations even if a high-level planner or remote operator becomes unavailable.
A robust architecture commonly separates:
- fast local feedback for actuator and body control;
- onboard perception and state estimation where timing requires it;
- higher-level planning that can operate at a slower rate;
- remote supervision or development tools that are not a single point of failure for immediate stabilization.
This separation also clarifies teleoperation. A person can choose a strike or movement while onboard software executes stabilization. The presence of a handheld touchscreen controller in the T800 specification does not mean every joint is manually driven, just as an Orin module does not prove fully autonomous tactics.
Our humanoid balance explainer details the local feedback problem. The networked humanoid survey likewise distinguishes fast onboard control from functions that can tolerate edge or cloud communication.
Orin NX Basic versus AGX Orin development editions
The most useful comparison is not “small chip versus big chip.” It is the complete package.
T800 Basic lists:
- Orin NX 16GB;
- an Intel wide-field binocular head camera;
- no 3D LiDAR in the table;
- no listed secondary development;
- Wi-Fi 5 and Bluetooth 5.0.
T800 Open Source, Pro and Max list:
- AGX Orin 64GB;
- an ultra-wide binocular camera and 3D LiDAR;
- secondary development;
- optional Thor on request;
- Wi-Fi 5, Bluetooth 5.0 and 5G.
Those differences make Basic and the development-oriented editions suitable for different procurement questions. Comparing only module memory hides the sensor, software-access and connectivity differences.
Pro and Max also change articulation and dexterous-hand configurations. More axes or tactile data can change integration and processing needs, although the public page does not quantify that effect.
See the complete EngineAI T800 profile for the edition-by-edition breakdown.
What the Thor option does—and does not—tell us
EngineAI lists Thor as an upgrade available on request for Open Source, Pro and Max. This confirms an option, not that every delivered T800 includes it.
The T800 source used here does not provide a complete Thor configuration, memory variant, power mode, software stack or combat benchmark. Consequently, this article does not assign it a TOPS score or claim a measured speed improvement over AGX Orin.
Before selecting the option, a buyer should request:
- the exact module and memory configuration;
- supported operating system and middleware versions;
- compatibility with existing T800 APIs;
- power modes and measured consumption under the intended workload;
- thermal design and throttling behavior;
- sensor-driver and model compatibility;
- end-to-end latency on the robot, not a desktop benchmark;
- any changes to warranty, support or delivery configuration.
An upgrade is useful only if the complete software and hardware system can exploit it.
Computing power affects heat and battery
High-computing modules consume electrical power and produce heat. Under demanding workloads, thermal limits can lead to reduced clocks or other protective behavior. NVIDIA’s Jetson Orin documentation explicitly describes cooling, throttling and shutdown mechanisms.
That creates a system-level trade-off. A larger perception workload may demand more compute while also increasing the cooling and energy budget. At the same time, motors, drives and batteries generate their own heat during dynamic motion.
EngineAI lists “Super Air-Cooled Heat Dissipation” and active cooling for T800 leg joints. Those claims do not publish a combined thermal test covering actuators, battery and high compute during repeated combat rounds.
For the wider system view, read humanoid robot thermal management. For battery claims and their limits, see our T800 solid-state battery analysis.
Does more onboard compute mean autonomous fighting?
No. Autonomy is a system property, not a component specification. An autonomous fighter needs software that can perceive, decide, plan, act and respond safely under the event’s rules. It also needs evidence that those functions—not a hidden human decision layer—produce the observed behavior.
A powerful module can instead be used for:
- teleoperation interfaces;
- sensor visualization;
- stabilization;
- data logging;
- development tools;
- perception that assists a human commander.
Likewise, a less powerful computer can run an efficient autonomous policy in a constrained task. Module choice alone cannot settle the autonomy question.
A practical T800 compute evaluation
Researchers should benchmark their own pipeline on the exact edition and power configuration being considered. A useful test records:
- sensor input rates and dropped frames;
- perception latency and its worst-case tail;
- policy or planner update rate;
- memory use under the full concurrent workload;
- control-loop timing while perception and logging run;
- module and ambient temperatures;
- throttling events;
- battery consumption;
- behavior when remote communication is interrupted.
The pass criterion should be task performance with safe control timing, not a synthetic number detached from the robot.
The bottom line
The T800’s documented computing distinction is clear: Orin NX 16GB for Basic; AGX Orin 64GB for Open Source, Pro and Max; Thor as a requested upgrade for those three editions.
The engineering decision is less simple. Buyers need to evaluate the full sensor package, development access, software compatibility, real-time workload, power and cooling. And no Orin or Thor label, by itself, proves that a T800 chooses its own boxing tactics.