Ben-Gurion's RL Layer Fixes Every Broken Robot Plan Classical Planners Produce
A neurosymbolic pipeline uses PPO and a graph neural network to fix planner trajectories that ignore acceleration limits and drag.
PRO- Ben-Gurion researchers use PPO plus a GNN to repair hybrid planner outputs that violate acceleration and drag limits
- All initial plans from Scotty were physically infeasible under second-order dynamics across four domains
- Refinement recovers 100 percent feasibility, with makespan penalties between 14 and 23 percent
- Approach beats constant-contraction baselines while needing roughly 18x fewer refinement steps
- Method assumes decoupled axes, no disturbances, no time windows, and only contracts velocity bounds
- Full paper on arXiv details the CSA-MDP formulation and MTV feasibility check
Classical hybrid temporal planners are good at ordering discrete actions and stitching together continuous motion, but they cheat on physics. They model robots as first-order integrators, treating velocity as a directly controllable input. The trick keeps optimization tractable, but the plans it produces routinely ask a real vehicle to change speed faster than its motors and mass will allow. A new paper from Ben-Gurion University proposes a reinforcement learning refinement layer that takes those first-order plans and reshapes them into trajectories that respect acceleration limits and drag.
The headline result is stark: across four benchmark domains, every plan from an off-the-shelf planner was physically infeasible. After refinement, every one worked, at the cost of a 14 to 23 percent longer makespan.
Where classical planners fudge the physics
Hybrid planners handle problems where a robot must traverse spatial regions in a particular order while satisfying deadlines, time windows, and velocity limits. Tools like Scotty combine search over plan skeletons with trajectory optimization formulated as a Second Order Cone Program, and related planners encode the same problem as a mixed-integer linear program.
All of them share a modeling assumption: they treat control inputs as velocities and enforce no continuity on those inputs. That keeps the optimization tractable but ignores bounded accelerations and drag, so tracking the resulting trajectory with a real controller causes actuator saturation, large tracking errors, and potential instability.
This story is for Pro members
You've reached the end of the free preview. Upgrade to AlphaSignal Pro to read the full article - and everything else behind the paywall.
Comments
