Two New Papers Want to Fix How Robots Plan and Move. Do They?

The authors argue, correctly I think, that sparse keypoints are a poor match for the continuous-time nature of physical motion. A robot arm moving through space is not a set of discrete dots jumping between positions; it is a continuous physical system with smooth dynamics. Representing it as sparse keypoints introduces discretisation artefacts and loses information that matters for generalisation across different robot bodies.

The solution they propose is to model robot flows using a flow matching formulation, which is a class of generative modelling technique that has become prominent in the last two years, largely through work like Lipman et al.'s Flow Matching for Generative Modeling (2022) and subsequent extensions. To be precise, flow matching learns to transport a simple probability distribution (typically Gaussian noise) toward a target distribution by learning a continuous vector field. The Flow as Flow authors adapt this to the robot motion domain, treating the velocity field describing robot motion as the object to be generated.

This is genuinely new in the specific sense that nobody has previously formulated cross-embodiment robot flows as probability velocity fields within a flow matching framework. It is incremental over the broader flow matching literature, and incremental over prior cross-embodiment flow work, but the combination is novel enough to be interesting.

The numbers are striking. Across standard benchmarks the method reportedly achieves approximately 33 times faster generation than representative baselines, while also outperforming them on standard metrics. The real-world evaluation is more substantial than most manipulation papers manage: 9 methods evaluated, 260 trials per method, across 13 manipulation tasks. That is not a small experiment. It is worth noting that 260 trials per method is still a relatively modest sample when you are trying to establish statistical significance across 13 tasks, and the paper does not, as far as I can tell from the abstract, report confidence intervals or significance tests broken down by task. I would want to see those before treating the success rate comparisons as definitive.

The 33x speedup is the headline result and it matters practically. Slow inference is a real barrier to deployment. If you can generate motion representations an order of magnitude faster without sacrificing quality, that changes what is feasible in real-time control loops. Whether this speedup holds at the same quality level across all 13 tasks, or whether there are task categories where the tradeoff looks different, remains unclear from the abstract alone.

What problem is the feasibility prediction paper solving?

The second paper is solving a problem that anyone who has worked with sampling-based motion planners will recognise immediately. Sampling-based motion planners (SBMPs), things like RRT and its variants, work by randomly sampling configurations in the robot's configuration space and checking whether those configurations are collision-free. When a motion is feasible, they find a path relatively efficiently. When a motion is infeasible, they can spend a very long time failing, because they keep sampling and checking without ever finding a valid path. This is computationally expensive and, in a real system, it means your robot sits there doing nothing useful while the planner thrashes.

Existing approaches to certifying infeasibility, that is, proving that no valid path exists, are generally limited to low-dimensional configuration spaces and tend to assume simplified geometric environments. Real cluttered tabletop scenes, the kind you find in a kitchen or a warehouse, are neither low-dimensional nor geometrically simple.

The Learning Motion Feasibility from Point Clouds paper proposes learning a feasibility predictor directly from raw RGB-D observations, so depth camera data, for a 7-DOF manipulator in realistic cluttered scenes. The idea is that if you can quickly predict whether a grasp attempt is feasible before committing to the full planning process, you can skip the expensive failed planning attempts.

The benchmark they introduce is the most concrete contribution here: 2.7 million grasp feasibility labels over 88 scanned objects and 190 cluttered tabletop scenes. That is a large-scale dataset by the standards of this specific problem, and creating it required substantial engineering effort. The absence of a good benchmark has been a genuine obstacle to progress in this area, so filling that gap has real value independent of the specific models they train on it.

They benchmark three classifier families: MLP-based, volumetric CNN, and point-cloud-based Transformer architectures. Their best model, called GRASPFC-PTX, is a point-cloud transformer that achieves an AUROC of 0.996 on novel objects. That is an impressive number. It is also, I know I am being picky here, a number that should be interpreted carefully. AUROC measures the classifier's ability to rank positive examples above negative ones across all possible thresholds, which is a reasonable summary metric, but what actually matters in deployment is precision and recall at the specific operating threshold you choose. A system that achieves 0.996 AUROC could still have a meaningful false negative rate at a practically useful threshold, and false negatives here mean the planner skips feasible grasps. The paper presumably reports this somewhere in the full text; it is just not visible in the abstract.

The claim that predictions are significantly faster than SBMPs is almost certainly true and also somewhat unfair as a comparison. A learned classifier that runs a forward pass through a neural network is always going to be faster than a search algorithm that requires many collision checks. The more interesting question is whether the combined system (classifier plus planner on the cases the classifier passes) is faster and more reliable than the planner alone. That is the system-level comparison that matters for deployment.

Why do these two papers matter together?

Considered separately, each paper is a solid contribution to its specific subfield. Considered together, they are addressing two different bottlenecks in the same pipeline.

If you are building a robot manipulation system, you need to answer two questions in sequence: is this action feasible given my current environment, and if so, how do I generate the motion to execute it? The feasibility paper is attacking the first question; the flow paper is attacking the second. A system that combined fast feasibility prediction with fast, cross-embodiment motion generation would be meaningfully better than either component alone.

The cross-embodiment angle in the flow paper is worth dwelling on. The central problem in robotics right now, actually, the research shows this repeatedly, is that data is expensive and robot-specific. A dataset collected on a Boston Dynamics Spot does not transfer cleanly to a Franka Panda arm. If you can represent motion in a way that abstracts over the specific robot body, you can potentially pool data across embodiments and train more capable models with less per-robot data collection. This is the promise of cross-embodiment representations, and it is why they have attracted so much attention in the foundation model literature, including in work from groups like DeepMind's robotics team and Stanford's Mobile ALOHA project.

The flow matching approach in Flow as Flow is a reasonable candidate for achieving this abstraction because velocity fields are, in principle, a physical description of motion rather than a robot-specific one. Whether the learned representations actually generalise across substantially different embodiments, rather than just across the specific robots used in training, is something the paper's evaluation cannot fully answer. The 13-task evaluation is real-world and reasonably broad, but it is not clear how many distinct embodiments were included or how different they were from each other.

What are the methodological concerns?

I want to be specific about what I would want to see before treating either result as settled.

For Flow as Flow: the 33x speedup is a strong claim and I would want to know the hardware conditions under which it was measured, what the baseline inference times actually were in absolute terms (33x faster than something slow may still be slow), and whether the speedup is consistent across all 13 tasks or driven by a subset. The success rate comparison across 9 methods is the right kind of evaluation, but without confidence intervals and significance testing broken down by task, it is hard to know whether the differences are robust. The sample size of 260 trials per method is not small, but 260 divided across 13 tasks is only 20 trials per task per method, which is on the lower end for reliable estimates of success rates in manipulation tasks where variance is high.

For Learning Motion Feasibility: the AUROC of 0.996 is high enough that I am mildly curious about data leakage or distribution mismatch concerns, though the fact that they specifically report performance on "Novel objects" suggests they have thought about generalisation. The more important question is how the model performs when the cluttered scene distribution shifts from the training set, which is the realistic deployment scenario. 190 tabletop scenes is a reasonable number for training, but tabletop scenes in real kitchens and warehouses are more varied than any controlled benchmark can capture. This hasn't been replicated in truly out-of-distribution conditions yet, as far as I can tell.

Both papers are preprints. Neither has gone through peer review. That is not a criticism of the authors; preprints are how the field moves fast. But it is a reason to hold the specific numbers loosely until they have been scrutinised more carefully.

What would I want to see next?

For the flow matching work, the obvious next step is a systematic cross-embodiment generalisation study: train on data from robot A, evaluate on robot B, with B being substantially different from A in morphology and degrees of freedom. The current evaluation presumably shows the method works on the embodiments it was trained on, but the cross-embodiment promise is the interesting scientific claim, and it requires a more demanding test.

For the feasibility prediction work, the interesting extension is integrating the predictor into a full task-and-motion planning system and measuring end-to-end task completion rates rather than standalone classifier metrics. The classifier is a component; what matters is whether the component improves the system. I would also want to see the benchmark released publicly, because 2.7 million grasp feasibility labels is the kind of resource that could accelerate a lot of follow-on work if it is accessible.

More broadly, the two papers point toward a version of robot manipulation that is sort of more modular than the current dominant paradigm: separate learned components for feasibility, motion generation, and presumably perception, that can be composed and updated independently. Whether that modular approach ultimately outperforms end-to-end learned systems is one of the genuinely open questions in the field right now, and it is too early to say which direction the evidence will settle.

Both papers are worth reading if you work in manipulation or motion planning. Neither is going to change how you think about robotics overnight. Together, they are a reasonable snapshot of where the field is putting its energy in mid-2025.

A pair of new arXiv preprints take different but complementary approaches to a problem the field has largely been avoiding: how do you formally guarantee the safety of a robot running a foundation model?

Aisha Patel · 20 hours ago · 9 min