HorizonNav turns an image of an unfamiliar place into generated “future” camera views, then reconstructs those views as a 3D map for route planning before a robot moves. In tests, it produced usable visual-SLAM reconstructions in 58 of 67 generated-video cases; in a corridor study, its independent planner found a collision-free alternative in five of six cases where the generated camera path collided with the reconstructed map.
What did the researchers build?
HorizonNav is a system for turning a robot’s current camera image into a tentative 3D picture of what may lie beyond the view, then using that picture to plan a route before the robot sets off. Its central idea is to use generated video as a source of possible viewpoints—not as a ready-made instruction for the robot to follow.
The system begins with an image and a navigation task. A vision-language model examines the visible scene and describes landmarks, obstacles, apparent open space, and areas hidden from view. It then creates an exploration instruction, such as looking through an opening or turning toward an occluded area. The instruction also identifies visual details that should remain consistent with the original image, helping constrain the generated scene.
A video-generation model produces candidate first-person views following that instruction. The system reconstructs the resulting views into a spatial representation, marks obstacles, and asks a conventional path planner to find a route through the estimated free space. The map is treated as a hypothesis: generated views can supply useful clues, but they do not prove that unseen parts of the real environment match the imagined scene.
What were the key results?
More generated viewpoints generally improved the chance of finding a route in the reconstructed map, though the trend was not consistent for every individual scene. At the shorter P20 horizon, 13 of 19 scenes admitted a feasible route and RRT succeeded in 62 of 90 trials. At P81, the longer horizon, those figures rose to 15 of 19 scenes and 75 of 90 trials. These figures measure planning against the reconstructed obstacle map, not the accuracy of the map against the real world.
| Generated-view horizon | Scenes with a feasible route | Successful RRT trials |
|---|---|---|
| P20 | 13/19 | 62/90 |
| P81 | 15/19 | 75/90 |
A separate archive of 67 generated-view cases yielded a usable ORB-SLAM3 reconstruction in 58. Of those 58 reconstructions, 36 supported a feasible plan and 22 did not. Failed plans were linked to issues such as weak camera movement, sparse or distorted geometry, and errors that closed off narrow passages.
The corridor test highlights why the planned route is kept separate from the generated camera path. Of 32 branch-and-horizon cases, 25 had enough data to compare both paths in the same map. Six generated camera paths violated the study’s collision criterion; an independently planned RRT route avoided the collision in five of those six cases. The paper also describes six physical quadrotor trials, but the supplied paper text cuts off before reporting their outcomes.
How does HorizonNav work?
The process separates visual imagination, 3D reconstruction, and route planning. First, a vision-language model—Gemini 2.5 Flash in the reported system—uses the initial image and task to identify what is visible and where further observation could help. Its exploration instruction guides a video model, Wan 2.2 I2V Fast, to generate candidate first-person sequences. The generated camera movement supplies viewpoints for mapping; it is not automatically treated as a safe robot trajectory.
For reconstruction, the reported planning experiments rely primarily on ORB-SLAM3. This visual mapping system tracks image features across frames to estimate camera motion and build a sparse 3D point cloud. A usable reconstruction requires enough stable visual features and sufficiently informative camera movement. The study also examines Video Depth Anything as a way to add dense depth information, but stresses that smooth depth across video frames does not guarantee that geometry lines up correctly across viewpoints.
Next, the point cloud is converted into an occupancy map: a grid-like representation of which areas appear occupied or free. Obstacles are expanded by the robot’s radius and a safety margin, leaving a more conservative area in which the robot can travel. Rapidly-exploring Random Tree (RRT) then searches for a collision-free route by sampling possible positions and connecting them when the connecting path does not cross mapped obstacles. For aerial robots, the search includes altitude; a ground robot can plan on the floor plane.
The design’s key safeguard is that generated movement and robot movement serve different purposes. A video may reveal useful geometry even if its camera path crosses an obstacle. The planner uses the reconstructed map to select a separate route, and the paper emphasizes that the result is still an estimate—not a substitute for checking the real environment during execution.
Why does this matter for robotics?
Robots often need to choose a direction before they have physically looked around a corner, entered a room, or approached a gap. HorizonNav tests whether generated viewpoints can help fill that information gap early enough to support planning. Its results show a practical distinction: an imagined view does not need to be a faithful, executable journey to provide useful clues for a separate mapping and planning system.
That separation could be relevant to mobile robots operating in unfamiliar or partly observed spaces, including warehouse systems that need to assess routes around occlusions. The experiments do not validate HorizonNav on warehouse fleets, so that application remains a possibility rather than a demonstrated result. Teams exploring platform options can browse warehouse robots or see used robots for sale.
For engineers, the work also frames an important deployment question: whether a generated scene preserves the features that matter for a specific decision. A map can be visually plausible yet still make a narrow opening look blocked—or show a route as open when it is not. HorizonNav’s emphasis on conservative obstacle handling and independent planning points toward combining generative AI with established mapping, planning, and live sensing rather than asking a video model to control a robot on its own.
What are the limitations and open questions?
A generated view is not evidence that the corresponding space exists as shown. The study’s own failures include weak or degenerate camera motion, degraded reconstruction, and geometry that distorts free-space connections. Even with 58 usable reconstructions out of 67 attempts, only 36 supported a feasible plan, showing that reconstruction success alone does not establish planning usefulness.
The reported planning numbers are map-level results; they do not verify that every route is safe in the physical environment. Online perception and safety margins remain necessary. The corridor comparison also covers a limited set of evaluable cases, and RRT is used as a downstream planner rather than introduced as a new planning algorithm. Finally, although the paper describes six quadrotor flight trials and their evaluation setup, the supplied text omits their outcome statistics, so no physical success rate can be stated here.
What are the frequently asked questions?
Does HorizonNav tell the robot to follow the generated video’s camera path? No. The generated path supplies possible viewpoints for reconstruction, while a separate planner calculates the robot’s route.
What does the system use to build its 3D map? The reported planning results use ORB-SLAM3 to estimate camera motion and recover sparse 3D structure from the generated views.
Did more generated frames always improve planning? No. The overall results improved from P20 to P81, but individual reconstructions could become less useful as generation added faulty geometry.
Does the study prove that generated maps are safe for real-world navigation? No. The main planning results are measured against reconstructed maps, and the supplied text does not include the physical flight outcome statistics.
What should readers take away?
HorizonNav demonstrates a way to use generated video as an exploratory mapping aid while keeping route selection in a separate planning system. Its results show promise for pre-motion planning, but also make clear that generated geometry must be treated cautiously and checked against the real world.