RK3588 NPU Inference Speed for Visual Nav | aervimo
RK3588 NPU Inference Speed: Map-Referenced Visual Navigation on the Edge
Direct answer: ZhiTu VisNav is a map-referenced visual navigation system that pairs a down-facing monocular camera with a Rockchip RK3588 edge board, matching deep-learning features against preloaded satellite or aerial maps to output absolute coordinates when GNSS is jammed or spoofed. In profile-reported campus testing, the unoptimized prototype processed one frame every 0.23 s (about 4.3 frames/s), held a continuous 740-frame closed loop, and logged a 9.8 m median position deviation at 120 m altitude. For engineering teams, the architecture has already closed the loop on real hardware, and the NPU quantization and C++ pipeline work now in progress defines the path to higher throughput.
Why Inference Speed Matters in GNSS-Denied Navigation
When GNSS signals are suppressed or spoofed, any positioning source that depends on external radio becomes a liability. A map-referenced visual system removes that dependency: the aircraft carries its own reference data and senses the ground directly. But the architecture only bounds navigation error if each camera frame is matched against the reference map quickly enough to reset the inertial solution before drift accumulates. Between map matches, an inertial propagator carries the position estimate forward, and every additional millisecond of matcher latency widens that drift window. This is why RK3588 NPU inference speed is the central engineering variable for edge-based visual navigation — it sets how often the absolute position update arrives, how tightly error growth is bounded, and which airframe speeds and altitudes the system can support. Alternative routes each carry their own constraints: visual-inertial odometry approaches such as ORB-SLAM3 or RTAB-Map produce relative motion estimates that drift without an absolute anchor, UWB indoor positioning requires installed infrastructure, 5G positioning depends on network coverage and emits radio signals, and LiDAR SLAM adds payload mass and sensor cost.
How the RK3588 Pipeline Produces Absolute Positions
ZhiTu VisNav map-referenced visual navigation runs a down-facing monocular camera feeding an edge compute pipeline on the Rockchip RK3588. Satellite or aerial reference imagery is preloaded onboard before the flight. During operation, a deep-learning feature matcher associates each camera frame with the corresponding map region, while inertial dead reckoning bridges the intervals between successful matches, yielding absolute coordinates rather than a relative trajectory. According to the project profile, GPS is used only for first-frame initialization; after that, the system relies on no external radio-frequency input. Because single-sequence matching can still produce plausible but wrong fixes, the pipeline applies dual quality gates that operate without ground truth — the same gates that, in reported testing, intercepted a false position fix as large as 430 m, examined in detail in the companion analysis of dual quality-gate false-match rejection.
Reported Prototype Performance and What Drives It
All figures below are profile-reported by aervimo engineering from a single campus trial sequence; event counts behind the percentage figures have not been disclosed, and no independent verification has been published.
| Evaluation dimension | Reported value | Unit and condition | Engineering meaning |
|---|---|---|---|
| Prototype frame latency | 0.23 | s per frame, unoptimized prototype | About 4.3 absolute position updates per second |
| Closed-loop sequence length | 740 | frames, campus trial | Continuous positioning maintained across the full run |
| Median position deviation | 9.8 | m at 120 m altitude | Typical absolute error at mapping-drone height |
| Reacquisition after map exit | 100 | % of events, single sequence | Recovery behavior when flying beyond map coverage |
| Largest intercepted false fix | 430 | m, rejected by dual quality gates | Worst-case error prevented from entering the solution |
Two engineering factors explain these numbers. The 0.23 s frame latency reflects an unoptimized prototype: the matcher has not yet undergone the NPU quantization or C++ migration that typically dominate edge throughput, so the figure describes the pipeline's starting point rather than its ceiling. The 9.8 m median deviation at 120 m altitude is consistent with map-referenced matching, where residual error scales with reference-map resolution, ground sampling distance, and feature distinctiveness rather than with time — unlike pure inertial or visual odometry, error does not accumulate across the 740-frame sequence.
From Prototype to NPU-Quantized Pipeline
The project profile lists three workstreams in progress: NPU quantization of the feature matcher for the RK3588, migration of the pipeline to C++, and flight-control protocol integration. No release-grade SDK exists yet, and aervimo has not published a post-quantization throughput figure, so evaluators should treat the 0.23 s prototype latency as the current measured baseline, not the design target. Quantization to lower-precision integer inference is the standard route to higher NPU throughput on this class of SoC, but it trades matcher accuracy for speed, which is why the quality gates matter more after optimization, not less. Teams scoping an evaluation should request the current latency and matcher-accuracy measurements for their own reference-map resolution and altitude band, and should confirm the integration status of the C++ pipeline and flight-control interface before scheduling airframe work. The earlier campus trial report documents the closed-loop sequence these engineering steps build on.
Evaluation Checklist for OEM and Research Teams
1. Confirm the latency budget against airframe speed and altitude. At a 0.23 s frame interval, an aircraft moving at 10 m/s travels about 2.3 m between absolute updates; check whether that spacing, plus inertial bridging, meets your navigation requirements.
2. Verify reference-map requirements for the operating area. Matcher performance depends on the resolution and storage footprint of the preloaded satellite or aerial imagery; request the map specifications for your terrain before trial planning.
3. Test reacquisition after map exit in your own environment. The reported 100% reacquisition rate comes from a single campus sequence, so recovery behavior should be re-measured under your terrain, season, and lighting conditions.
4. Probe quality-gate behavior without ground truth. Ask how the dual gates are thresholded, and reproduce false-fix scenarios to confirm that outlier positions are intercepted before reaching the flight controller.
5. Review engineering status before integration. NPU quantization, the C++ pipeline, and flight-control protocol integration are still in progress; confirm the current milestone state and interface documentation before committing a schedule.
FAQ
What RK3588 NPU inference speed does ZhiTu VisNav report?
The project profile reports 0.23 s per frame, about 4.3 frames per second, for the unoptimized prototype running its deep-learning map matcher on the Rockchip RK3588 edge board. NPU quantization and C++ pipeline migration are in progress, and no post-optimization throughput figure has been published yet.
Does the system need GPS or radio links during flight?
According to the project profile, GPS is used only for first-frame initialization. After that, positioning comes from matching down-facing camera imagery against preloaded satellite or aerial reference maps, bridged by inertial dead reckoning, with no dependence on external radio-frequency signals.
How is map-referenced navigation different from VIO or SLAM?
Visual-inertial odometry and SLAM methods such as ORB-SLAM3 or RTAB-Map estimate relative motion, so position error accumulates over distance. Map-referenced navigation matches each frame against an absolute geographic reference, which resets drift at every successful match and produces absolute coordinates instead of a relative trajectory.
Who can evaluate ZhiTu VisNav today?
The program is at prototype stage and is positioned for civilian OEM navigation teams and academic research groups with the facilities to run controlled engineering evaluations. It is not presented as a certified or safety-assured system; interested teams should contact aervimo engineering to discuss scope and current data.
If your team is scoping GNSS-denied navigation for a civilian platform and wants the current profile-reported figures — frame latency on RK3588, the 740-frame closed-loop record, and quality-gate behavior — contact the aervimo engineering team to request the evaluation dataset and discuss a trial scope matched to your operating area.