# Does LLM-Guided Contact Planning Actually Work for Humanoid Motion?

A new paper from Michal Ciebielski, Shafeef Omar, Aaron Johnson, and Majid Khadiv says yes — at least when paired with the right feasibility filter. Published today on arXiv (2607.18362), FARO (Feasibility-Aware Robot Motion Optimization) proposes a nested kino-dynamic framework that combines LLM-based contact plan sampling with a feasibility-guided tree search to generate dynamically consistent trajectories for humanoid [loco-manipulation](https://humanoidintel.ai/glossary/loco-manipulation). The trajectories are then tracked by a reinforcement learning (RL)-based controller and validated in real-world scenarios — closing the loop from language-level planning down to physical execution.

The core problem FARO targets is well-understood in the field: humanoid motion planning fails to scale because the search space is high-dimensional, hybrid (continuous dynamics interrupted by discrete contact events), and underactuated. Every time a foot lifts or a hand contacts a surface, the feasibility landscape changes discontinuously. Prior approaches either over-constrain the problem with pre-defined contact schedules or burn excessive compute on infeasible candidates. FARO's answer is a rapid feasibility-checking module that prunes the tree search before expensive trajectory optimization is invoked — letting the LLM generate creative contact sequences while the kino-dynamic layer enforces physical reality.

The paper demonstrates that generated trajectories are of "sufficiently high quality for execution in real-world loco-manipulation scenarios," per the authors' own framing — measured language that serious researchers will note is not a claim of state-of-the-art across all benchmarks.

---

## The Architecture: Three Interlocking Layers

FARO's design is best understood as a stack, not a monolith.

**Layer 1: LLM-Based Contact Plan Sampling.** An LLM generates candidate contact sequences — specifying where and when the robot's hands and feet should interact with the environment. Using an LLM here is a pragmatic choice: language models encode substantial implicit knowledge about how objects are manipulated and how bodies move through space, providing a structured prior that narrows the combinatorial search without hard-coding contact templates.

**Layer 2: Feasibility-Guided Tree Search.** Rather than evaluating all LLM-generated candidates with full trajectory optimization, FARO runs a nested kino-dynamic feasibility check first. Kinodynamic planning simultaneously considers kinematic reachability and dynamic consistency — a contact sequence that is geometrically plausible but dynamically infeasible (violating momentum constraints or torque limits, for instance) gets pruned early. This is where the paper's primary computational claim lives: rapid feasibility checking substantially improves the search process.

**Layer 3: RL-Based Tracking Controller.** Once a dynamically consistent trajectory is generated, an RL-trained controller executes it on hardware. This is a conventional [sim-to-real transfer](https://humanoidintel.ai/glossary/sim-to-real-transfer) pipeline, and the authors' decision to use RL rather than a model predictive controller reflects the field's current consensus that learned controllers generalize better to hardware imperfections and unmodeled contact dynamics.

The combination is architecturally coherent. The LLM handles combinatorial search; the kino-dynamic checker enforces physics; the RL controller absorbs hardware noise. Each layer does what it's actually good at.

---

## Why This Matters for Whole-Body Control

The hardest open problem in humanoid robotics today isn't bipedal locomotion in isolation or manipulation in isolation — it's [whole-body control](https://humanoidintel.ai/glossary/whole-body-control) that coordinates both simultaneously. A humanoid that needs to step onto a platform while simultaneously placing an object on a shelf above it must solve a tightly coupled contact scheduling problem that pure end-to-end learning approaches have struggled to generalize across novel environments.

FARO's nested structure directly attacks that coupling. By making feasibility checking fast enough to run inside a tree search, the framework enables rapid planning of novel behaviors — behaviors not seen during training — which is precisely the [zero-shot generalization](https://humanoidintel.ai/glossary/zero-shot-generalization) problem that every hardware company in the humanoid space is trying to solve at the system level.

The LLM integration is also worth scrutinizing. LLMs as high-level planners for robotics have been demonstrated in prior work (SayCan, Code as Policies, and others), but those systems typically assume fixed manipulation primitives. FARO uses the LLM to generate contact sequences — a lower-level and more physically grounded output — which is a more demanding and arguably more useful application.

---

## Skeptical Analysis: What the Paper Doesn't Claim

The abstract is careful, and readers should be too. Several questions are left open:

**Compute budget.** The paper claims the framework "substantially improves the search process" but does not, in the abstract, quantify planning latency or compare wall-clock time against baseline planners. Whether this runs fast enough for reactive real-world deployment — versus offline trajectory generation — is not established by the available source text.

**Generalization scope.** Real-world validation in "loco-manipulation scenarios" (plural) is mentioned, but the range of scenarios, the number of trials, and success rates are not available in the abstract. The supplementary video will be the primary evidence here, and industry readers should watch it before drawing deployment conclusions.

**LLM dependence.** Using an LLM for contact plan sampling introduces a dependency on prompt engineering and model quality. If the LLM generates systematically biased contact proposals — for example, anthropomorphizing contact points in ways that don't match the robot's kinematic envelope — the feasibility filter must compensate. The robustness of this interface under distribution shift isn't addressed in the abstract.

**Hardware platform.** The source text does not specify which humanoid platform was used for real-world experiments. This matters: a result on a torque-controlled research platform doesn't automatically transfer to a position-controlled commercial system with different [backdrivability](https://humanoidintel.ai/glossary/backdrivability) characteristics.

---

## Industry Trajectory Implications

FARO represents a meaningful step toward what the humanoid industry actually needs: planners that can generate feasible, novel behaviors fast enough to be useful outside of pre-choreographed demos. The LLM-as-contact-sampler approach is particularly interesting for companies building general-purpose humanoids, where the contact schedule for a new task can't be hand-engineered at scale.

The RL-based tracking layer also signals where the field has landed: rather than trying to solve whole-body control purely through optimization at runtime, the practical approach is to pre-train a robust tracking controller and use it to absorb the gap between planned and executed trajectories. That's a sim-to-real architecture choice with real implications for how companies like [Agility Robotics](https://humanoidintel.ai/companies/agility-robotics) and others structure their software stacks.

The deeper question FARO raises for the industry is whether LLM-guided planning can eventually replace the need for large demonstration datasets for novel task types. If a language model can propose physically plausible contact sequences that a kino-dynamic checker can validate, the data bottleneck for new behaviors shifts from human teleoperation to trajectory optimization compute — a potentially more scalable tradeoff.

---

## Key Takeaways

- **FARO introduces a three-layer architecture**: LLM-based contact sampling → kino-dynamic feasibility checking → RL-based trajectory tracking, applied to humanoid loco-manipulation.
- **The central innovation is rapid feasibility filtering** within a tree search, pruning physically infeasible contact sequences before expensive optimization runs.
- **Real-world execution is demonstrated**, though the specific platform, scenario range, and quantitative success metrics are not available in the abstract.
- **LLM integration is at the contact-sequence level**, not just high-level task description — a more physically grounded application than most prior LLM-robotics work.
- **Key unknowns include** planning latency, hardware platform specifics, and generalization breadth across unseen environments.
- **Industry relevance**: the framework directly targets the whole-body control and novel-behavior generalization problems that commercial humanoid programs have not yet solved at scale.

---

## Frequently Asked Questions

**What is FARO in robotics?**
FARO (Feasibility-Aware Robot Motion Optimization) is a motion planning framework for humanoid robots, proposed in a July 2026 arXiv paper by Ciebielski, Omar, Johnson, and Khadiv. It combines an LLM-based contact plan sampler, a kino-dynamic feasibility checker, and a reinforcement learning tracking controller to generate and execute novel loco-manipulation trajectories.

**What is kino-dynamic planning for humanoids?**
Kino-dynamic planning simultaneously enforces kinematic constraints (reachability, joint limits) and dynamic constraints (momentum, torque limits, underactuation) when generating robot motion. For humanoids, this is critical because motions that look geometrically feasible can violate the robot's physical dynamics — particularly during contact transitions between locomotion and manipulation.

**Why use an LLM for contact plan generation?**
LLMs encode implicit knowledge about how objects are handled and how bodies move, providing a structured prior for generating candidate contact sequences. Rather than exhaustively searching all possible contact schedules, the LLM narrows the space to physically plausible candidates, which the kino-dynamic layer then validates. This is a more grounded application than using LLMs for high-level task descriptions alone.

**How does FARO handle sim-to-real transfer?**
FARO uses an RL-trained tracking controller to execute planned trajectories on real hardware. The RL controller absorbs the gap between the idealized planned trajectory and actual hardware behavior — a standard sim-to-real pattern that has proven more robust to hardware imperfections than pure model-based execution.

**What are the limitations of the FARO approach?**
Based on the available abstract, key open questions include planning latency (whether it runs fast enough for reactive deployment), the specific hardware platform used, the range of real-world scenarios tested, and how robustly the LLM-feasibility interface behaves under distribution shift from unseen environments.