Why AMD says robot performance takes more than AI TOPS
Giulio Corradi’s ROSCon recap puts CPU timing beside AI speed. Read the July benchmark’s methods, hardware limits and the customer evidence still needed.
Peak AI speed cannot establish reliable robot operation. AMD’s case needs workload-specific timing results and evidence that builders adopt the platform in products.
A robot can have fast AI inference and still respond late if the rest of its software cannot keep up. That is the useful question behind AMD Fellow Giulio Corradi’s ROSCon recap: can sensing, planning and movement stay coordinated while AI adds more work?
In his own account of the keynote scheduled for September 23, Corradi writes: “AI performance matters, but a peak TOPS number cannot describe how the complete robot will behave.” He emphasizes the CPU’s role in planning and coordination, alongside limits on power, temperature and cost. This is his post-event account, rather than a transcript of the talk. Corradi’s public recap AMD’s dated event announcement
The argument was already taking shape in July
TOPS means trillions of operations per second. It describes arithmetic throughput under specified conditions; it does not directly count successful robot tasks. Corradi’s September remarks extend an existing AMD position. In a July 23 article, AMD product manager Quenton Hall argued for testing perception, planning, control and AI together, citing an Open Navigation benchmark. The September post adds a public explanation, not a newly completed customer deployment. AMD’s earlier argument
The timing problem is older than today’s robot models. Jackie Kay’s 2016 ROS 2 design document distinguishes completing work quickly from completing it before a required deadline. Operating-system scheduling and application behavior both matter. For a robot, a useful answer that arrives after the motion controller needs it may be too late. The real-time computing background
Read the benchmark’s setup before its headline
Open Navigation’s July test runs a simulated forklift workload alongside a vision-language model. The onboard computers receive simulation data from a separate machine. The author discloses collaboration with AMD and says the tests were executed without its influence. AMD’s own footnote describes the work as commissioned. The benchmark author’s methods
One hardware detail matters: AMD’s comparison used a GMKtec EVO-X2 mini PC with a Ryzen AI Max+ 395 configured to reflect Ryzen AI Embedded X199 specifications. It was not a measurement of a finished customer robot using an X199 module. AMD’s hardware disclosure, footnotes 3–4
In the reported 15-minute test at the stated full-power settings, both the AMD system and Jetson Thor completed all ten missions. Their reported control-loop scheduling misses averaged 0.45 and 1.6 per second, respectively. The author also notes that changing thread priorities could improve both. These are missed timing deadlines within that workload, not robot accident rates. Results and tuning limits
Our reading is that the test makes the CPU argument concrete, while leaving the choice of platform dependent on the application. A developer changing sensors, models, power limits or software may change the result. A warehouse simulation also cannot establish how much useful work a customer gets over months of operation.
What would make the case stronger for AMD?
AMD’s ROSCon announcement names Foundation Robotics’ Phantom MKI in a planned demonstration using its embedded processor. That gives readers a specific builder to follow. It does not supply a production order, a shipment count or robotics revenue. The demonstration described by AMD
For investors following the company, the next evidence should connect the technical pitch to a design choice and then to sustained use. We would look for these three steps:
| Next evidence | What it would clarify |
|---|---|
| A named production design with its exact processor | Whether a demonstration becomes a product commitment. |
| Timing and completed work under the customer’s full workload | Whether the claimed headroom improves operation outside the benchmark. |
| Shipments and repeat purchases over a stated period | Whether the design develops into a continuing business. |
Software integration belongs in that assessment too. Our NVIDIA platform analysis follows the tools builders must actually use. Figure’s compute commitment concerns a different bottleneck: training capacity. Training a better model and keeping a robot’s onboard work on schedule each need evidence of their own.
- A named production robot design identifying its AMD processor and operating task.
- Results on the final hardware and software, including missed deadlines and useful completed work under concurrent load.
- Dated shipments or repeat customer purchases, separately from demonstrations and benchmark claims.
Sources & context
- Giulio Corradi’s ROSCon 2026 recapGiulio Corradi / LinkedIn · SupplierPost paragraphs on whole-system timing, CPU orchestration, peak TOPS and AMD portfolio.
- AMD to Showcase Physical AI and Robotics Innovation at ROSCon 2026AMD · Sep 21, 2026 · SupplierEvent date, speaker identification, and demonstration list.
- From Benchmarks to Behavior: Rethinking Performance in Autonomous RoboticsAMD · Jul 23, 2026 · SupplierDated article by Quenton Hall; concurrency, control-loop and CPU-headroom sections.
- AMD Strix Halo vs. NVIDIA Jetson Thor, Orin AGX for Real Robotics WorkloadsOpen Navigation · Jul 23, 2026 · ResearchSteven Macenski; Benchmark Design, Platform Results Analysis, and thread-priority note.
- AMD Kria AI SolutionsAMD · SupplierKria AI SOM overview and footnotes 3–4 (REX-018 / REX-016).
- Introduction to Real-time SystemsOpen Source Robotics Foundation · ResearchJackie Kay; date written 2016-01, modified 2016-05; Definition of Real-time Computing and memory/scheduling discussion.