For ABot-N1, every route begins with a pixel

AMap headquarters in Beijing, photographed by N509FZ on August 21, 2023. The building is the documentary anchor for a release from Alibaba's AMap CV Lab, whose navigation research joins map-scale spatial knowledge to on-robot perception.[7][8]

A coordinate, a shop name, a request to find a chair, a paragraph of directions, and a person in a blue jacket do not look like the same navigation problem. ABot-N1 makes them share the same middle step: before the robot moves, a slower vision-language model points into the camera image. A faster controller then chases that point.

That small handoff is the most interesting part of the release. AMap CV Lab posted the ABot-N1 technical report on July 11, 2026 and revised it on July 14. The model covers point-goal, point-of-interest, object-goal, instruction-following, and person-following navigation in one architecture.[1][2] The headline scores are large, especially on two new AMap benchmarks. But the durable idea is easier to see than a leaderboard: language and geometry meet at a pixel before either becomes motion.

As of 2026-07-19T03:42:17Z UTC, the public package includes the report, a project page, three benchmark datasets, and a runnable evaluation toolkit. It does not include ABot-N1 model weights or its training and inference pipeline.[1][2][3][4][5] This is therefore a release with an unusually inspectable test surface and a still-closed policy. Those two facts should be kept together.

The narrow waist is visible

ABot-N1 divides navigation into a slow system and a fast system. In the report's main architecture, the slow side is a 4-billion-parameter Qwen-3.5 vision-language model. It receives left, front, and right camera views, a short visual memory, the task instruction, and its previous decision. It can return a natural-language reasoning trace plus two kinds of image-space anchor.[1]

The affordance pixel marks a place where motion is currently possible: roughly the next safe patch of floor, pavement, or path. The target pixel marks the destination itself when it becomes visible: an object, a storefront entrance, or the person being followed. Not every task needs both. A point-goal instruction may use only an affordance pixel; an object search uses that pixel while exploring and adds a target pixel once the object appears. For person-following, the two can coincide at the bottom center of the person's bounding box.[1][2]

The fast side uses a 2-billion-parameter Qwen-3.5 backbone in the report's main configuration. It reads current camera views alongside the slow model's latest text, pixels, and reference image, then predicts five continuous local waypoints. Each waypoint carries position, heading, and a completion flag. The systems run asynchronously: while the expensive reasoner considers the next subgoal, the controller keeps tracking the last cached pixel against new images.[1]

This is a useful “narrow waist” for a general navigator. Everything above it can vary—metric offsets, prose, an object category, a business name, a person's appearance. Everything below it can remain a control problem: keep the indicated patch in view, produce a short path, and decide when to stop. The controller does not have to rediscover the meaning of “the entrance to the Lanzhou noodle shop” at every motor update. The reasoner converts that meaning into something the controller can see.

A pixel can repair a coordinate without becoming a map

The point-goal case shows why this intermediate representation matters. A low-detail map or imperfect localization can place a nominal coordinate in a traffic lane, flower bed, or behind a barrier. A controller that follows the offset literally may reach the number and fail the journey. ABot-N1 instead asks the slow system to re-ground the goal in the current view and select a traversable affordance pixel. The robot still knows where it is trying to go, but each local step is negotiated with visible ground.[1]

POI navigation adds a semantic trap. Finding a sign is not the same as finding the door beneath or beside it. The report's data process distinguishes a sign box, an entrance box, a target pixel on the entrance, and an affordance pixel on reachable ground. That sequencing turns “go to this business” into a last-meter arrival problem rather than an image-retrieval win.[1]

The same interface also makes failures easier to name. If the reasoning text identifies the wrong shop, the semantic stage failed. If the shop is correct but the pixel lands on a planter, spatial grounding failed. If both are correct and the waypoint cuts a corner, control failed. That is more legible than one large policy producing motion directly from a prompt.

Legible does not mean safe by itself. A pixel has no depth, persistence, or uncertainty attached to it. It can be occluded, projected onto a reflection, or made stale by a moving person and a turning robot. ABot-N1 explicitly trains the fast system with noisy coordinates, imperfect upstream predictions, and simulated asynchronous lag; person-following examples sample slow-system outputs from zero to four steps earlier.[1] That is a thoughtful response to delay. It is not a guarantee against it. A deployable system still needs to expose the age and confidence of its cached anchor—and know when to stop following one.

Five tasks train the same visual grammar

AMap reports a pretraining collection of 30 million samples across 8,423 3D scenes, covering 14.7 square kilometres and 482 kilometres of paths.[2] The task recipes differ, but they all teach some version of the same grammar: an instruction, a view, a permissible next patch, an optional final target, and a short sequence of motion.

That shared grammar is what makes cross-task transfer plausible. Object-goal data can teach the slow system when a named thing is actually visible. Point-goal data can give the fast controller much more practice following traversable pixels. POI data can teach that visual recognition and physical arrival are separate stages. Instruction-following adds progress through a sequence of subgoals, while person-following adds a target that moves and disappears.[1]

The release also uses reinforcement learning on the slow system rather than treating fluent reasoning as the finish line. In the paper's point-goal stage, its reward combines output-format validity, target-pixel alignment across camera views, and a safety term based on distance from non-traversable regions. The authors train that stage on 0.5 million point-goal episodes; extending the target reward to other tasks is described as future work. The aim is to make the reasoner's visible answer useful to the downstream controller, not merely plausible to a reader.[1]

There is an important boundary around those data claims. Much of the supervision is synthesized, filtered, reconstructed, or produced inside AMap's own data engine. Scale helps a shared interface emerge; it does not make simulation equivalent to the clutter, glare, crowds, temporary barriers, and ambiguous entrances of a new city. The pixel grammar is the hypothesis. Transfer beyond AMap's environments is the test.

The edge robot uses a smaller pair

The report's real-world section quietly strengthens the interface argument by changing the models around it. The principal architecture is described as a 4B slow model and a 2B fast model. For deployment on AMap's TuTu quadruped, however, the team reports a 2B slow model and a 306-million-parameter diffusion transformer on the fast side, with DINOv2-Base encoding the visual observations. Both run on a Jetson AGX Orin with 64 GB of memory at an overall 10 Hz control frequency.[1]

In other words, the pixel-and-text handoff survives even when the controller's backbone changes. That is more consequential than one checkpoint size. A useful interface lets a laboratory train with one allocation of compute and ship with another, so long as the slow side can communicate a grounded subgoal and the fast side can track it.

The hardware description also prevents an easy overclaim. The paper's abstract policy is framed around RGB navigation without a global metric map, depth input, or semantic segmentation. The physical TuTu platform nevertheless carries omnidirectional LiDAR, RTK-GNSS, three cameras, and an integrated bird's-eye-view perception stack.[1] The real-world demonstrations therefore show the full robot system operating, not a camera-only checkpoint succeeding in isolation. They are valuable qualitative evidence of integration, but they do not isolate how much robustness comes from ABot-N1 versus the surrounding sensors and locomotion stack.

Read the scores in two layers

On established instruction-following evaluations, the team reports 70.89% success on R2R-CE Val-Unseen and 73.85% on RxR-CE Val-Unseen. On a re-curated short-horizon object-goal set, it reports 84.9% success, up from 73.2% for the earlier ABot-N0 system.[1][6] These comparisons are the more portable part of the evaluation because the underlying benchmark families predate N1, even though the paper's exact curation and model setup still matter.

The larger-looking results come from AMap's new suites. ABotN-PointBench contains 31 reconstructed real-world scenes and 465 episodes. The reported success rate is 92.9% outdoors and 95.4% indoors. Those figures use different collision rules: outdoor success permits fewer than three collision events, while indoor success requires zero. They should not be read as two directly comparable measures of difficulty.[1][3][4]

ABotN-POIBench covers 11 commercial areas, 126,000 square metres, and 163 points of interest. It counts success within two metres of the annotated entrance; ABot-N1 reaches 77.3%, compared with 42.3% for POINav in the team's evaluation.[1][3][5] The benchmark is unusually relevant to AMap's actual domain because it tests whether a navigator can turn a business name into the correct physical doorway.

It is also a house-built exam. AMap created the scenes, annotations, metrics, evaluation pipeline, and tested model. The constructive part is that the datasets and evaluator are genuinely public: an outside team can implement the small reset() and predict() agent interface and rerun the closed-loop episodes.[3][4][5] Independent results will matter more than another internal table, especially on whether collision labels, entrance boxes, and reconstructed scenes advantage the pixel-goal design.

What the release opens—and what it does not

ABot-N1's public surface is split cleanly. The research argument is open in the report. The visual story is open on the project page. Point-goal, POI-goal, and short-horizon object-goal benchmark data are downloadable, and the Apache-2.0 evaluator includes render-server code, metrics, and wrappers for custom agents.[1][2][3][4][5]

The policy itself is not yet reproducible from those artifacts. The cited repository releases the examination room, not the student: there are no ABot-N1 weights, model inference implementation, training code, or exact edge-deployment package in the public project as of the article timestamp.[3] That limits scrutiny of the most interesting operational questions—how often the slow system refreshes, how latency changes with scene complexity, when a cached pixel is rejected, and how the controller behaves when the two systems disagree.

Three follow-ups would make the release much stronger:

Publish the model and inference path for both the report configuration and the smaller on-robot variant, with measured update rates for each subsystem.
Log pixel age, confidence, and replacement events so stale-anchor failures can be separated from perception and control failures.
Invite blind reruns on new buildings and streets where signs, entrances, walkable areas, and social rules were annotated outside AMap's pipeline.

ABot-N1 does not solve general navigation by pointing at the floor. It proposes a visible place to join deliberation and motion. That is valuable precisely because it can be challenged: the text can be wrong, the pixel can be stale, and the controller can miss. For a robot trying to find a door in a changing city, a route beginning with a pixel is only the first claim. The next metre is the proof.

cronfeed.work