How to Evaluate Visual Positioning in a GNSS-Degraded Civilian Operating Area
Define the operating area before discussing accuracy
A GNSS-degraded evaluation should describe the civilian environment in which the visual-position observation is expected to work: reference-map source and age, altitude or camera geometry, lighting, season, repeated structures and areas outside the reference map. The goal is to establish an operating domain, not to produce one universal accuracy number. A result from one campus, industrial site or test route is evidence about that domain only. It should not be generalized to unrelated geography or safety-critical use without further validation.
Use independent reference truth
Position estimates should be compared with an independent reference that was not used to generate the visual observation. Record the coordinate frames and time alignment so apparent error is not created by transformations or synchronization. Report the distribution of errors rather than only a mean or median. Separate initialization behavior from steady-state behavior and identify segments where no valid observation is produced. If the system uses another sensor for initialization, state that explicitly rather than implying the entire sequence is sensor-independent.
Treat false matches as a different failure mode from large error
A confidently wrong position can be more operationally important than an unavailable result. The evaluation should count incorrect matches, record their confidence/quality indicators and examine what the receiving system sees when they occur. Include repeated roofs, roads, vegetation patterns or map changes that can create ambiguity. Do not hide these events inside an average position error. Likewise, record recovery after leaving the mapped area or after a period without a valid result as a separate behavior with its own conditions.
Measure latency and availability at the intended compute boundary
Prototype timing on a workstation does not automatically describe an embedded deployment. Record end-to-end observation latency, processing rate, compute platform and periods when no usable position is available. NVIDIA’s Isaac ROS ecosystem illustrates how localization and mapping workloads are commonly treated as edge robotics components, with deployment behavior depending on the specific platform and integration stack. For Aervimo, migration to RK3588/NPU/C++ and real-time interfaces remains an engineering workstream rather than a released production specification.
Keep the evaluation separate from safety or precision-landing claims
A useful prototype can justify further engineering without being described as a certified navigation system. Define how the position observation would be consumed, what quality flags are available, what other sensors remain in the system and what happens when the observation is rejected or absent. ZhiTu VisNav should continue to be communicated as an engineering-evaluation capability. This framework does not support claims of precision landing, independent flight safety, certification or guaranteed operation in GNSS-denied environments.
Checklist
["Defined civilian operating domain", "Independent reference truth and time alignment", "Tail-error and false-match reporting", "Latency/availability on target compute", "Fallback and integration behavior"]
Sources
[["NVIDIA — Isaac ROS localization and mapping", "https://developer.nvidia.com/isaac/ros"], ["NVIDIA — Edge AI on Jetson for robotics", "https://developer.nvidia.com/blog/?p=110310"]]