AI Only in the Right Places: What Intel's Robotics Team Taught Me About Physical AI

Last night I walked into a room full of robot arms, engineers, and Intel people, and walked out with an Intel hat and a much clearer picture of where AI actually belongs in a robot.

The event was Bots & Bevs: An Intel Robotics Experience, hosted by Intel with Brampton Venture Zone (BVZ) by Toronto Metropolitan University and Trossen Robotics, at The Sandbox by DMZ in Toronto. It ran alongside ROSCon 2026, so the room was full of people who actually build and deploy robots.

The demo: training a robot to mix a drink

The centerpiece was a pair of Trossen Robotics Solo AI arms running on Intel Core Ultra Series 3 processors and the Intel Robotics AI Suite. Attendees teleoperated the arms through a drink-mixing task, and those demonstrations became training data through imitation learning: a human shows the robot how, and the model learns to copy it.

It's a simple demo, but it shows the whole modern robotics loop: demonstrate, train, deploy.

Intel's stack, in one picture

The talk walked through Intel's end-to-end Physical AI workflow in three stages:

Stage	Tools	What happens
1. Train anywhere	VLA/VLM models (PyTorch/JAX), training cluster	Train on whatever hardware you have
2. Build/simulate anywhere	Intel Physical AI Studio, LeRobot, Geti	Fine-tune with imitation learning, standardize workflows
3. Deploy on Intel	OpenVINO Physical AI, ROS 2, oneAPI, Real Time FW, Core Ultra	Run VLA policies in production on CPU/GPU/NPU

What stood out to me is the positioning. Intel isn't trying to win training; that's NVIDIA's territory. The bet is on deployment: one runtime connecting models, hardware backends, and different robots, so builders don't have to re-integrate everything for every new robot.

A VLA (vision-language-action) policy, for anyone new to the term, is a model that takes camera input plus an instruction ("pour the juice") and outputs actions for the robot.

The part that stuck with me: AI only in the right places

After the talk I got a few minutes with Ashwin Vijayakumar, Intel's Director of Products for Robotics, Physical AI & Education. I told him what I liked most was his point about a LiDAR sensor talking to a tiny microcontroller, deterministic systems, and using AI only where it actually belongs.

That idea reframed how I think about robots. From our conversation, here's the architecture as I understood it:

Tier	Runs on	Job
Sensor and motor I/O	A microcontroller costing cents, bare metal	Hard real-time; the sensor never waits on Linux
Closed-loop control	Linux with PREEMPT_RT, control loop pinned to a dedicated core	Deterministic timing, isolated from everything else
Decision-making	AI / agentic layer	Picks which skill to run

A few takeaways from the conversation:

• The basics remain. PREEMPT_RT, closed-loop control, and CPU core pinning still do the heavy lifting underneath. AI changed the top of the stack, not the foundation.

• Don't overbuild the setup. Install Ubuntu and use a prebuilt real-time kernel instead of fighting a custom build.

• Simple, deterministic AI. The AI layer calls tools and skills that are already tried and tested. It decides what to do; proven code decides how.

That last point clicked for me because I've built LLM agents that call tools. A robot that calls grasp() or navigate() is the same pattern, except the functions move physical things. The safety win is huge: the AI can't command motors directly, and each skill can be validated on its own instead of trying to validate an entire neural network.

We also touched on humanoids like Tesla's Optimus, which follow the same idea at a bigger scale: a central AI computer on top and a small embedded controller in every joint running its own fast loop.

Why this matters to me

I'm a final-year Computer Engineering student at TMU, and my long-term direction is embedded systems and firmware. Physical AI is exciting precisely because it needs that layer. Every robot running a fancy VLA model still depends on someone writing deterministic firmware, real-time drivers, and control loops underneath.

AI is getting all the attention, but the robots that work in the real world are standing on embedded fundamentals.

What I'm building next

I'm turning this into a hands-on project on an x86 laptop (Intel Core i7-1065G7, Ice Lake):

1. Real-time Linux: Ubuntu with the PREEMPT_RT kernel, an isolated CPU core, and cyclictest latency measurements comparing a stock kernel, an RT kernel, and RT with core pinning, under load.

2. Computer vision on the edge with OpenVINO: running and optimizing a vision model on the CPU and integrated GPU, including INT8 quantization and possibly fine-tuning a small model for a specific task.

3. Going smaller: pushing a vision task onto an ESP32 microcontroller and squeezing every bit of performance out of its cores, to see how far "AI at the edge" can really go.

I'll post the results, latency histograms included.

I'm not going to forget the embedded side while I work through Computer Networks and CI/CD. If anything, this event reminded me why it matters.

Thanks to Intel, Trossen Robotics, and BVZ by TMU for hosting, and to Ashwin for the conversation (and the hat).