Comparing the Main Approaches to Robotics and Embodied AI

Three axes, not one spectrum

Ask which is “the” way to build an embodied AI system and the question is already malformed. Practitioners are choosing along at least three largely independent axes at once: how perception, state estimation, planning and control are divided between hand-engineered and learned components; how the resulting policy acquires its behaviour in the first place; and whether control is exercised against an explicit predictive model of the world or without one. A given robot can sit anywhere in this space — a hand-engineered planner driven by a learned perception front end, trained partly by imitation and partly by simulated reinforcement learning, executing through a model-based low-level controller with a learned high-level policy on top of it. The combinations are not academic hair-splitting; they are the actual menu that a robotics team chooses from, and the choice changes what can be verified, what can be debugged, what a demonstration video is evidence of, and what a benchmark number can honestly be compared against.

This article works through the three axes in turn, states plainly what evidence exists for the comparative claims each community makes about its own approach, and then turns to the place where the evidence runs out: benchmarks, robots and task suites differ enough between research groups that a single cross-approach ranking is not something the current evidence can support. Flagging that incomparability is not a hedge. It is the finding.

The classical pipeline: separable, inspectable, jointly suboptimal

The oldest architecture for embodied autonomy divides the problem into stages and hand-engineers each one: perception turns sensor data into a geometric and semantic scene estimate; mapping and state estimation fuse that estimate over time into a coherent model of where the robot and the world’s objects are; planning searches that model for a trajectory or action sequence; and control converts the plan into actuator commands, typically at a fixed, high frequency. Each stage has its own interface, its own test suite, and — critically — its own failure mode that can be isolated. If a manipulator misses a grasp, an engineer can log the perceived object pose, the planned trajectory and the executed torques separately and ask which stage was wrong.

That separability is not incidental; it is the entire reason certification-minded industries still build this way. A stage-by-stage pipeline is amenable to the kind of hazard analysis that safety standards demand, because each hazard can be traced to a specific, boundedly-behaved module rather than to an opaque end-to-end function. It is also why the pipeline persists even where learned components now populate individual stages: a learned object detector feeding a classical Kalman filter and a classical motion planner is still, architecturally, a pipeline, and it inherits the pipeline’s inspectability even though one of its stages is a neural network.

The cost is equally structural. Each stage is optimized against its own local objective — pose estimation accuracy, map consistency, path length — and none of those local objectives is the thing that is actually being paid for, which is task success. A perception module can be locally excellent and still discard exactly the information the planner needed, because nobody told it to keep that information. Recent surveys of the field frame this precisely: end-to-end approaches are pursued because, relative to modular pipelines, they permit joint optimization of the components that a pipeline would otherwise tune separately ^[1]. That is a real, structural advantage of the alternative, not a marketing claim, and it is worth stating exactly what kind of evidence backs it: it is an architectural argument about where information is discarded, documented across the literature that survey synthesizes, rather than a single head-to-head experiment.

End-to-end policies: one function, one optimization, no seam to open

The end-to-end alternative collapses perception, state estimation, planning and control into a single function, typically a neural network, trained to map raw or lightly processed observations directly to actions. There is no intermediate map object, no explicit trajectory to inspect; the network’s internal representations may resemble a map or a plan, but nothing forces them to, and nothing guarantees a human can read them off.

The appeal is exactly the pipeline’s weakness inverted. Because the whole system is one differentiable function trained against one objective, gradients from the actual task — did the grasp succeed, did the robot reach the goal — flow back through every stage at once, so representations are shaped by what actually matters rather than by a locally chosen proxy. Vision-language-action models are the current, most visible instance of this architecture at scale: RT-2 folds a vision-language backbone and an action head into a single network trained to output robot actions directly from an image and an instruction, and its authors report that this lets the system transfer semantic knowledge from web-scale pretraining into robotic control it was never demonstrated on, generalizing to novel objects and following instructions that require a form of reasoning over the input rather than mere pattern matching ^[4]. That is a developer’s own account of its own system’s evaluation trials, not an independent audit, and it should be read as a claim rather than a settled fact — but it is a claim about a specific, real, released model, tested at meaningful scale.

The cost is the mirror image of the pipeline’s benefit: there is no seam left to open. When an end-to-end policy fails, there is no separate perception log and planner log to compare, because there were never separate perception and planner outputs in the first place — only the network’s weights and its one output. Root-causing a failure means probing the network’s internals rather than reading an interface, which is a categorically harder debugging problem, and it is the direct reason that safety-critical deployments have been reluctant to hand end-to-end policies unmediated control authority. This is a structural trade, not a temporary tooling gap: the same property that lets gradients flow freely to fix a genuine local error also removes the interface a human would use to prove, ahead of time, that a specific class of error cannot occur.

Hybrids: learned components, classical guarantees where guarantees are required

Almost no fielded system is purely one or the other, and it is worth naming the hybrid patterns explicitly because “hybrid” is often used as a vague placeholder rather than a specific architecture. Two patterns dominate in practice. In the first, learned perception or a learned high-level planner feeds a classical low-level controller: a network estimates object pose or a rough trajectory, and a hand-engineered controller — often a model-predictive one running at a fixed, guaranteed frequency — turns that estimate into actuator commands with the stability and constraint-satisfaction properties classical control theory can certify. In the second, a learned high-level policy proposes actions freely, and a classical safety layer sits underneath it with the authority to modify or veto those actions before they reach the hardware.

The second pattern has a specific, well-studied mathematical form: the control barrier function, which defines a safe set in the state space and constrains any commanded action to keep the system inside it, regardless of what upstream policy proposed the action ^[7]. This is the honest way to combine a policy that need not be verifiable with a guarantee that must be. A recent and very concrete example ties this directly to an industrial safety standard rather than to an abstract safe set: a 2026 paper builds a control barrier function that explicitly incorporates a human worker’s acceleration to forward-predict minimum separation distance during a robot’s worst-case stopping trajectory, integrates it as a hard constraint inside a real-time controller, and evaluates it against a standard industrial speed-and-separation-monitoring baseline on a real collaborative arm, reporting a 63% reduction in mean trajectory error for its more capable variant while remaining compliant with the relevant safety standard’s monitoring requirements ^[13]. Whatever policy sits above that layer — hand-coded, imitation-learned, or a large VLA model — the safety layer’s guarantees do not depend on trusting it.

Hybrids are not evidence-free middle ground; they are a specific claim that verification effort should be spent where consequences are worst — contact, collision, joint limits — and relaxed where it is not. That claim is defensible in exactly the domains where the underlying dynamics are well enough understood to write the constraint down, and it offers nothing in domains where they are not, which is precisely why the debate below about model-based versus model-free control matters to hybrid design specifically, not only to end-to-end training.

Where the behaviour comes from: imitation, reinforcement, and foundation-scale VLA

Architecture is one axis; how a policy learns its behaviour is a second, and the two are frequently conflated because most current end-to-end systems happen to use one particular training method. They need not.

Imitation learning from teleoperated demonstrations trains a policy to reproduce actions recorded from a human operator, typically minimizing the divergence between the policy’s action distribution and the demonstrated one at each observed state. Its central practical virtue is that it requires no reward function and no exploration in the real world — every training signal comes from a human who already knows how to do the task. Its central practical cost is that every demonstration must be produced by hand on the machine being built, which caps how much data exists and concentrates it on states a competent operator visits, rarely including the recoveries a mediocre policy would actually need. A systematic study of offline imitation and batch reinforcement learning across five simulated and three real multi-stage manipulation tasks found that outcomes were highly sensitive to algorithmic design choices, to the quality of the demonstration data, and to the criterion used to decide when to stop training — three confounds that, the authors note, made it difficult to assess the field’s actual state of progress from published numbers alone ^[8]. That finding is itself a caution against exactly the kind of comparison this article is trying to avoid making carelessly. Within imitation learning, architecture choice still matters: representing the policy as a diffusion process over action sequences rather than a direct regression was reported to outperform prior state-of-the-art behaviour-cloning methods by an average of 46.9% across twelve tasks drawn from four separate manipulation benchmarks, largely by handling the multimodality of human demonstrations — the fact that a demonstrator might reasonably approach the same state from either side — better than a single-mode regression head can ^[2].

Reinforcement learning, trained in simulation and fine-tuned or validated on hardware, instead lets a policy generate its own experience against a reward function, at a volume no human demonstrator could match, because a simulator can be run far faster and far more parallel than a physical robot. The clearest demonstration of what that parallelism buys is a locomotion result: training a quadruped to walk on flat terrain in under four minutes and on uneven terrain in twenty, using thousands of simulated robots running concurrently on a single workstation GPU, a speedup the authors describe as multiple orders of magnitude over prior training setups, with the resulting policy transferred to a physical ANYmal robot ^[3]. That is a genuine and well-documented capability. It is not evidence that reinforcement learning is “better” than imitation learning in any general sense — the two are typically applied to different problem shapes, with RL favoured where a reward function is easy to write and a simulator is trustworthy, and imitation favoured where the task is easy to demonstrate but hard to specify as a reward, such as most contact-rich manipulation. Treating them as competitors on a shared leaderboard obscures that they are usually solving different halves of the problem.

Vision-language-action foundation models are a third, distinct training strategy that has become easy to confuse with either of the above because it typically uses imitation-style supervised training internally: a single large network is trained on demonstration and, in some cases, web-scale vision-language data pooled across many robots, embodiments and tasks, with the goal of generalizing to instructions and objects it was never shown on that specific robot. OpenVLA, an openly released 7-billion-parameter model trained on 970,000 real-world robot demonstrations pooled across many robot embodiments, is reported by its authors to outperform a much larger closed model, RT-2-X at 55 billion parameters, by 16.5 percentage points in absolute task success rate across their evaluation suite, while requiring roughly an order of magnitude fewer parameters ^[5]. That comparison is informative about the value of open pooled training data and architecture choices at a fixed evaluation suite designed by the same team, which is a meaningfully narrower claim than “this model is better than that one” in general — a distinction the rest of this article returns to directly.

Model-based versus model-free control: two different bets about what is worth learning

Orthogonal to both axes above is a question specifically about control: does the controller act against an explicit, queryable model of how the world responds to its actions, or does it map states directly to actions without ever representing dynamics at all?

A model-free update never references a transition model. A canonical form, temporal-difference learning, updates a value estimate purely from sampled transitions:

Nothing in this update requires knowing or estimating $p(s' \mid s, a)$; it only requires having experienced $(s, a, r, s')$. A model-based approach instead fits an explicit dynamics model $\hat{p}_\theta(s' \mid s, a)$ — a “world model” — and plans against it directly:

A comprehensive survey of the model-based literature frames the trade this way: fitting and planning against $\hat{p}_\theta$ typically buys sample efficiency, because every transition teaches the model something reusable across many hypothetical future plans rather than updating one value estimate, and it buys interpretability, because the model can be queried and its predictions checked against reality independent of the policy it supports; the cost is that policy quality is now bounded by model accuracy, and errors in $\hat{p}_\theta$ compound over the planning horizon $H$ in ways that are hard to detect from the outside ^[6]. Classical robotics has practiced a version of this for decades without calling it “model-based reinforcement learning”: model-predictive control on the MIT Cheetah 3 solves a convex optimization over ground reaction forces against a simplified but explicit rigid-body dynamics model, to optimality, in well under half a millisecond per solve at 20 to 30 hertz, producing trot, bound, pace and full three-dimensional gallop gaits on real hardware ^[10]. The model there is hand-derived physics rather than a learned network, but the structural bet is the same one Moerland and colleagues describe: an explicit, checkable model of dynamics, planned against at run time.

The learned-world-model line of work aims to get the sample efficiency of that bet without hand-deriving the physics. DreamerV3 learns a model of its environment from experience and “imagines” future trajectories through that learned model to improve its behaviour, and its authors report it outperforming specialized, task-tuned methods across more than 150 tasks spanning distinct domains using one fixed configuration — including, notably, learning to collect diamonds in Minecraft entirely from pixels and sparse reward with no human demonstrations or hand-built curriculum, a benchmark specifically posed because it requires exploring far ahead under sparse feedback ^[9]. Model-free reinforcement learning gives up the explicit model entirely and instead relies on breadth of experience — the massively parallel simulated training behind the ANYmal locomotion result above is model-free in exactly this sense, learning a direct state-to-action mapping from an enormous number of simulated trials rather than planning against a dynamics model at run time ^[3]. Both the MIT Cheetah and the ANYmal work are legged locomotion, trained and evaluated on different robots, different terrain and different metrics; that proximity in domain is what makes the contrast in method legible, and it is exactly why it stops short of being a controlled comparison — nothing in either paper varies only the model-based-versus-model-free axis while holding the robot and task fixed.

Why these approaches resist a single ranking

Everything above has been stated as a structural trade-off deliberately, because the evidence available does not support a stronger claim, and a real, current example shows exactly why.

RoboChallenge is a purpose-built, large-scale attempt to evaluate multiple released vision-language-action policies on a shared real-robot benchmark, Table30, across several robot platforms with repeated trials per task — precisely the kind of infrastructure that would be needed to support a genuine cross-model ranking ^[11]. Even inside that controlled effort, the authors report success rates that swing sharply with evaluation setting: on the task-specific setting, where a policy is fine-tuned per task, one model family scored a 43.7% average success rate; the same family’s generalist variant, evaluated without per-task specialization, scored 17.7%, a drop of 26 percentage points from changing only how narrowly the model was tuned, not which model it was ^[11]. That single comparison already shows how much a reported number depends on a choice — task-specific versus generalist evaluation — that is rarely stated prominently when a success rate is quoted.

More telling still is what the same authors report about their own measurement process: they document that, even holding the same props, task and model fixed, the measured success rate can swing from 0% to 100% or the reverse depending on who administers the trial, and they describe an “adaptive tester” effect in which a model’s own developers, running its evaluation themselves, can position objects within an allowed range in ways that favour that model’s particular strengths — a “sweet spot” that inflates a self-reported number relative to what an independent tester would obtain ^[11]. This is not a criticism of any one model or lab; it is a documented property of how real-robot evaluation currently works, reported by the people building the evaluation infrastructure specifically to fix it. It means that a benchmark comparison across different labs’ self-administered trials, on different robots, with different prop sets and different testers, is not currently a sound basis for declaring one architecture or one training paradigm superior to another — the variance introduced by who ran the trial and how the props were placed can be larger than the gap the comparison is trying to measure.

This is the editorial position this article takes deliberately rather than by omission: modular pipelines, end-to-end policies and hybrids solve different debugging and certification problems; imitation learning, reinforcement learning and VLA foundation models are typically trained under different assumptions about what is available — a demonstrator, a reward function and simulator, or a large pooled multi-robot corpus — and evaluated on different robots by different people. Where a specific, controlled, same-team comparison exists, such as OpenVLA against RT-2-X on one shared evaluation suite, it is worth reporting as exactly that — one comparison, on one suite, run by one team. Building a general ranking by pooling numbers across papers that used different robots, different props, different testers and different stopping criteria manufactures a precision the underlying measurements cannot support.

What each choice actually costs to run

The architectural and training choices above are not free-floating engineering preferences; the series’ broader concern with deployment economics attaches directly to them. A classical pipeline’s per-stage inspectability lowers the cost of certifying a specific hazard is controlled, at the cost of engineering time spent hand-tuning interfaces between modules that a learned end-to-end system would instead optimize jointly. Imitation learning trades a data-collection cost that scales with the number of demonstrations a person can physically record against a training cost that stays comparatively low; reinforcement learning trades that data-collection cost for a simulation-infrastructure and sim-to-real engineering cost that scales with how faithfully the simulator must model contact and dynamics for the domain in question. VLA foundation models push much of the marginal per-task data cost into a large, shared pretraining investment made once and amortized across many downstream deployments — OpenVLA’s authors frame open, pooled training data as the lever that let a smaller model match or beat a larger closed one, which is as much a claim about amortized data economics as about architecture ^[5]. Hybrids spend their budget asymmetrically on purpose, concentrating verification effort on the safety layer — the ISO 10218 revision that took effect in 2025 explicitly restructured collaborative-robot safety around fully specified applications rather than treating any robot as collaborative in isolation, which is itself a recognition that verification cost attaches to the whole system, robot plus tool plus task plus layout, not to an architecture in the abstract ^[12]. None of these costs is visible in a headline success-rate number, which is one more reason such numbers travel badly across architectures.

Predictions, with the observations that would falsify them

These are forecasts, separated from the sourced analysis above. Horizon: 16 August 2030.

One. Fully end-to-end policies will not displace hybrid architectures in applications where a collision or a dropped payload has significant real-world cost; a classical or control-barrier-function safety layer will remain standard beneath learned policies in these settings. Disconfirmed if a majority of newly certified collaborative or industrial deployments in safety-relevant applications run a purely end-to-end policy with no separable safety layer.

Two. No single training paradigm — imitation learning, sim-trained reinforcement learning, or VLA pretraining — will dominate the others across task types; each will remain the practical default for the problem shape it already fits best (easy-to-demonstrate tasks, easy-to-simulate-and-reward tasks, and broad instruction-following generalization, respectively). Disconfirmed if one paradigm becomes the reported training method for a clear majority of new published results across manipulation, locomotion and navigation alike.

Three. Reported cross-lab benchmark comparisons will continue to diverge from independently repeated measurements by a wide margin, because tester and setup variance of the kind RoboChallenge documented is a property of the measurement process rather than of any specific benchmark’s design. Disconfirmed if an independent replication effort, repeating a published multi-model real-robot comparison with a different tester and prop set, reproduces the original ranking within a small margin.

Four. Standards bodies will keep extending application-specific certification (of the kind the 2025 ISO 10218 revision represents) rather than certifying an architecture or training method in the abstract, because the safety-relevant unit is the deployed system, not the algorithm class. Disconfirmed if a major safety standard is published that certifies a training method or model architecture independent of the specific robot, tool, task and layout it runs in.

What to take away

There is no single best way to build an embodied AI system, and the evidence does not currently support pretending otherwise. Classical pipelines, end-to-end policies and hybrids answer different questions about what must be inspectable before it can be trusted. Imitation learning, simulation-trained reinforcement learning and large VLA foundation models answer different questions about what kind of experience is available to learn from. Model-based and model-free control answer different questions about whether an explicit, checkable model of the world is worth the cost of building and maintaining one.

When a claim crosses your desk that one approach has beaten another, ask four questions before accepting the ranking. Same robot, or different robots. Same task set, or a task set each side chose for itself. Same tester, or the developer testing its own system. Task-specific tuning, or a generalist evaluation held to the same standard as the specialist it is compared against. A comparison that cannot answer all four is not yet evidence of which architecture is better — it is, at most, evidence that a specific system did a specific thing once, under conditions somebody else arranged.