Imagine you're playing a platformer where your character can only jump in parabolic arcs, but the landing platforms are randomly covered in spikes you can only see mid-air. You need a system that plans the jump, checks the landing zone while airborne, and — if it's bad — recalculates a safe alternative before you hit the ground. That's the core mechanism of this paper: a lunar propulsive drone that plans ballistic hops, evaluates terrain from camera images during flight, and diverts to reachable safe zones when the planned landing site turns out to be hazardous. The committed claim: a unified, autonomous motion planning framework that chains together global waypoint planning, semantic segmentation for obstacle detection, reachable-set computation, and model predictive control into a single pipeline — demonstrated for the first time on lunar hop trajectories in simulation. This isn't a single-component contribution; it's a systems integration paper that argues the full stack is what matters. The architecture sits in the classical robotics pipeline family: a hierarchical planner (global waypoints → local trajectory optimization → MPC tracking) augmented with a learned perception module. The optimal hop planner solves a fuel-minimizing trajectory problem for parabolic arcs under lunar gravity (1.625 m/s²). When the perception module flags the target site as unsafe, a diversion maneuver kicks in — the drone computes reachable terrain from its current state and redirects to the nearest safe landing zone. MPC handles the tracking, closing the loop between planned trajectories and actual execution with robustness to disturbances. The semantic segmentation model is custom-trained for lunar terrain — a notable engineering detail, since off-the-shelf models trained on Earth imagery are useless for identifying rocks, craters, and slopes on the Moon. The reachability computation is designed for speed, which matters enormously when you're a drone with limited fuel and limited time to decide whether to abort a landing. On the ladder: the paper doesn't name a single competing unified framework for lunar drone hop planning, which is honest — there essentially isn't one. Lunar drone mission planning is so nascent that this is closer to defining the problem than to beating a competitor. The individual components (MPC tracking, semantic segmentation, trajectory optimization) each have deep literature, but the integration for this specific use case is genuinely novel. The closest prior art is Ingenuity's Mars helicopter planning stack, but that's a rotorcraft in atmosphere, not a ballistic hopper in vacuum — fundamentally different dynamics. Integrity is the weak point. All results are simulation-only, in the authors' own high-fidelity lunar environment. There's no independent benchmark, no public test set for lunar terrain segmentation, and no hardware-in-the-loop testing. The paper is submitted to IEEE Aerospace 2027, which is a respected venue but peer review hasn't completed. No code release is mentioned. The simulation fidelity is described as "high" but the gap between simulated lunar regolith and actual lunar surface is enormous — terrain models, lighting conditions, dust dynamics, and sensor noise in vacuum are all open problems. The milestone question is where this gets interesting. NASA's planned lunar surface missions and commercial landers (Intuitive Machines, Astrobotic) are on a 2026-2030 timeline. A flight-ready autonomous hop planner would need to survive radiation-hardened compute constraints, real sensor noise, and actual lunar terrain — probably 5-8 years from simulation to flight qualification. The concrete next number: demonstrating this pipeline on hardware-in-the-loop with a realistic compute budget (ARM-class processor, not a GPU cluster) would be the credibility threshold. The obvious experiment not run: hardware-in-the-loop testing on a terrestrial analog (a drone hopping in a lunar regolith simulant testbed, which exist at NASA Johnson and ESA-ESTEC). The honest read is budget and access — this appears to be a university-scale effort (two authors), and analog testing requires facility access and flight hardware that academic groups rarely have. The framework is designed to be testable in such facilities, which suggests the authors know this is the next step.
