Walk into any robotics company mid-build and you'll hear the same arguments in every standup. Some are worth having. Some are pure bike-shedding. And exactly one has quietly gone settled while nobody was looking. Here are the nine questions robotics teams are still fighting over in 2026 — and the one they've stopped asking.
Buying a platform gets you to a demo in weeks; building your own gives you control over every gram and every dollar at scale. The math keeps shifting — supply constraints and a moving regulatory picture make it harder to bet confidently in either direction. But here's the part both camps forget: whether you buy the chassis or build it, you still inherit the software problem. Someone has to own the OS, the updates, and the fleet — and that work is identical no matter who bent the metal.
Buy the robot or build it, you still build the software layer. That decision is downstream of the one everyone argues about.
Jetson wins on power envelope and the NVIDIA Isaac ecosystem; x86 + RTX wins on raw throughput and a dev box that's just a PC. Qualcomm and AMD are finally close enough to be real options rather than science projects. But the framing is wrong. Production robots aren't one compute choice — they're a safety microcontroller, an edge-AI SoC, and a high-TOPS brain on the same chassis, each in a different tier. The honest question isn't Jetson or x86; it's which tier does this job, because you're going to run several at once. We mapped the four tiers here.
This is where the most bike-shedding happens and the least actually matters. ROS 2 owns perception, navigation, and an ecosystem you don't want to rebuild. Bare-metal controls own the hard real-time loop, where a scheduler hiccup is a safety event, not a dropped frame. You're not choosing between them — you're running ROS 2 up top and deterministic control underneath. The real question is whether your operating system can serve both without a fight, which is a PREEMPT_RT and workload-isolation problem, not a religious one.
Sooner than the roadmap says. JetPack and Ubuntu carry you through the demo; the day you need a reproducible image, a signed update, and a minimal attack surface, you're staring at Yocto. And Yocto doesn't just add a tool — it adds a team, a build you now own, and a critical path that every application engineer waits behind. The trap isn't Yocto itself. It's that maintaining Yocto quietly becomes the thing you do instead of building your robot.
Yocto isn't the question. Owning and maintaining Yocto is — and that bill comes due right when you're trying to ship.
There's a way to get the reproducibility, OTA, and rollback without standing up that team — which is the entire reason Avocado OS exists. But recognizing the moment it's coming is more than half the battle.
Every robotics company has one person who understands the kernel, the device tree, the board support package, and the flashing scripts — and usually exactly one. When they take PTO, releases stall. When they leave, you're negotiating with a black box. This isn't a hiring problem you can solve by posting a req, because embedded systems engineers are scarce and expensive. The only durable fix is structural: make the OS layer declarative and reproducible so it stops being tribal knowledge living in one person's head.
It's going to be both, and anyone selling you one is selling you half a robot. Vision-language-action models are extraordinary at high-level reasoning and generalization; classical controls are still how you close a loop deterministically at a kilohertz. The interesting engineering isn't picking a side, it's running them on the same box without the VLA workload starving the control loop. That's a compute-isolation problem, not a philosophy debate.
All of the above, in a loop. Simulation scales infinitely and costs nothing per run; real robot hours are the only ground truth; pre-trained and foundation models get you past the cold start. Teams burn months arguing the ratio when the thing that actually determines success is the loop between them — how fast a policy goes sim to real and back with corrections. And that loop only holds if the runtime is identical in both places. A "works in sim" gap is usually an environment gap, not a model gap.
These are the questions that stall a deal in the last mile, and treating them as a late-stage checklist is exactly why. Secure boot, a signed and immutable image, a software bill of materials, CVE response, and a rollback path aren't features you bolt on before the audit — they're properties the operating system either has or doesn't. Decide early whether they're your problem or your platform's, because retrofitting them into a fleet that's already shipping is the most expensive possible way to answer.
Security and safety aren't a checklist you run before the audit. They're properties your OS either ships with or it doesn't.
The quietest question, and the one that decides all the others. Every engineer-quarter spent building undifferentiated infrastructure — an OS, an OTA system, a fleet console — is a quarter not spent on the thing customers actually pay for. Build-versus-buy on the robot is a real debate; build-versus-buy on the plumbing usually isn't, once you price in the maintenance tail. Your runway is better spent on the robot than on reinventing embedded Linux.
Notice what's missing from the list. Nobody argues about where they train their models: it's NVIDIA, and that debate is closed. Which is the tell: settled decisions move up the stack, and the live fights move down it, into deployment, updates, and fleet operations. That's the layer worth being deliberate about, because it's the one still up for grabs, and the one that decides whether robot two ships as fast as robot one.
Win the layer that's still up for grabs. We wrote the long version — the reproducible, sim-to-fleet workflow that closes the deployment gap — in the robotics guide. Already in the fight? Talk to an engineer.