VPS
You are flying a facade inspection. At 40 metres everything is fine. The aircraft holds position, the fix is solid, the log looks clean.
Then you drop to three metres off the wall for the detail pass, which is the only reason anyone commissioned the flight, and the position solution starts to come apart. Satellites disappear behind the building. The ones you can still see are bouncing off glass and concrete before they reach you. Your fix goes to float, or it holds a number that looks plausible and is quietly wrong by a couple of metres.
The aircraft did not get worse at flying. It got closer to the thing it was sent to look at.
That is the gap this post is about. Not how to fly better, but what a drone should be doing about position when the satellites stop being useful, and why the answer has been sitting inside the survey data the whole time.
X 84.498 Y -1.207 Z 67.135 m, yaw 355.0°, confidence 0.97, with no GPS fix.
Four layers sit under any drone's sense of where it is, and each one gives you something the others cannot.
| Layer | What you get | What is still missing |
|---|---|---|
| GNSS and RTK | Global position, metres to centimetres with a correction stream | Fails at facades, under canopy and indoors. No heading at all without a second antenna |
| Photogrammetry and orthomosaics | A measurable deliverable of the site as it was on flight day | A frame that something can localize into, live |
| Onboard VIO and SLAM | Smooth relative motion between fixes | Drift. Nothing absolute. None of it survives the flight |
| A VPS map | An absolute 6-DoF pose against a map made earlier, carrying no accumulated error | The layer most aerial captures never get |
The rest of this post is about that last row.
Aerial capture grew up selling pictures. The first paying customers wanted things to look at: progress photos, roof condition, a fly-around for the client. So the industry learned that the deliverable is the visual, and that framing survived every technology change underneath it. Film to digital, digital to photogrammetry, photogrammetry to LiDAR, LiDAR to splats. Camera up, render out, invoice.
But a flight is not a picture. It is a measurement. When you fly a site you are recording geometry, appearance, and, if you are disciplined about it, a coordinate frame. The orthomosaic is not that dataset. It is one read path through it, the projection optimised for human eyes. The same measurement can be read by machines, for localization, for navigation, for simulation.
This matters because appearance fidelity and metric fidelity are different axes. A facade survey that is seven percent wrong in scale looks identical to one that is exactly right. Your eyes do not notice. A drone trying to hold three metres off that facade notices immediately.
Credit where it is due, because the hard parts did get solved.
Docked drone-in-a-box systems now fly a fixed route on a schedule with nobody at the controls, and because every flight follows the same path they produce orthomosaics and volumetrics that are comparable week over week. Verity's indoor inventory drones took the 2026 Award for Innovation and Entrepreneurship in Robotics and Automation and run in about 200 warehouses, with no GPS and no human in the loop. Corvus Robotics deploys infrastructure-free into a million square feet in about a week and moves cycle counts from twice a year to weekly.
Every one of those is a closed loop, and that is the limitation nobody names. The drone knows where it is for its own purposes, inside its own stack, for the duration of its own mission. Nothing in that position is addressable by anything else, and nothing in it survives the flight. Repeating a path is not the same as knowing where you are. The moment the path is unavailable, or the site has changed, or somebody on the ground needs to meet the drone's data in the same frame, a closed loop has nothing to offer.
The failure is not random and it is not rare. It is structural, and it is worst exactly where the work is.
RTK does not exempt you from any of this. RTK is still GNSS. It needs a live correction stream, it drops to float in the same places GPS does, and it gives you position without heading unless you have paid for a second antenna. Practitioners describe the worst RTK failure mode as a fix that looks good and is wrong, which is precisely the problem.
And interference is now an operating condition rather than an edge case. EUROCONTROL puts up to 38 percent of European en-route traffic through regions that are intermittently but regularly affected by radio-frequency interference, and IATA's flight data recorded a 220 percent rise in GPS signal-loss events between 2021 and 2024. EASA has revised its safety bulletin on GNSS interference four times. Aviation treats a degraded fix as a standing condition to design around rather than an incident to report, and drone work sits in the same signal environment.
There is a version of this problem that visual positioning shares, and it is worth saying out loud rather than waiting to be asked. A visual fix can also be confidently wrong, and a confident wrong answer is worse than no answer, because everything downstream trusts it. That is why v2.3.0 added false-positive detection: the SDK cross-checks every localization against the device's own motion, and when the returned pose disagrees with where the device has actually moved, the pose is discarded and onLocalizationFalsePositive fires. A wrong answer is treated as a distinct event, not as a bad number.
Fly the site once with a 360 camera. That is the whole capture step.
Raw .insv from an Antigravity A1 uploads directly and MultiSet stitches it server-side, which preserves more detail than re-ingesting somebody else's stitch. Any other 360 drone exports a stitched equirectangular .mp4 and goes through that route instead: DJI Avata 360, DJI Osmo 360, GoPro Max 2, Ricoh Theta, Insta360 X3. The pipeline cares about the format, not the brand.
What it will not take:
The capture rules matter more than the hardware. Fly in Cinematic mode at constant speed, turn through motion rather than pivoting on the spot, and never stop recording partway through a zone, because the whole zone is one continuous clip. Lock the shutter at 1/2000 in bright sun or 1/1000 in overcast, fix the white balance, and shoot 8K at 30 fps in strong light or 5.2K at 60 when motion blur is the bigger risk. Auto exposure is the single biggest cause of grey, smeared reconstructions.
Level the aircraft and let it settle before the clip starts. The tilt you begin with is the tilt the map keeps, and a tilted frame means floors are not flat in map space, floor-height bands cut diagonally through the building, and georeferencing starts from a frame that is already wrong.
Then fly four passes, as one continuous clip, in this order:
| Pass | What to fly |
|---|---|
| 1. Establishing orbit | One smooth loop at mid altitude, showing every primary side |
| 2. Fill-in snake | A lawn-mower path across the whole surface, 30 to 50 percent overlap between lanes, flown close enough to pick up detail |
| 3. Higher and wider | Roofline, upper facade and the surrounding context |
| 4. Reverse return | Back toward the start from a different angle, closing the loop |
Low, mid and high are all required. A capture flown at one altitude will not reconstruct. Match the trajectory to the subject: a vertical snake for a flat facade, a rising spiral for a tower, a lawn-mower grid over a property.
Two practical notes. A flight covers what nobody wants to walk, which is the real argument for aerial capture on a large site, and the 50 GB ceiling is how you split one into zones and rejoin them with a MapSet rather than a limitation. And because a printed ChArUco board cannot be resolved from the air, drone captures set metric scale after processing rather than from a marker in frame.
One distinction first, because it is the one enterprise readers ask about. Localization runs on the map's feature data, which stays inside the platform and is never downloaded. The output assets are separate visual representations of the same space, and you can preview, download and load them wherever you like.
A mesh and a point cloud are produced from every input, whatever it was. The Gaussian splat and the panoramic tour are opt-in at upload. 360 video is the only input that yields the complete set, which is the argument for flying a 360 camera rather than a conventional payload.
One detail worth carrying away: the mesh, the splat and the panoramas share the map's local frame, origin at zero, +Y up, metric scale, and a localization query returns poses in that same frame. The point cloud is the exception. map.pcd is right-handed with +Z up, so overlaying it on the mesh needs a conversion. That catches people.
An aerial capture and a walked ground capture fold into one coordinate frame through a MapSet, which holds the relative transform between them. A facade flown from the air and a corridor walked on foot resolve in the same query. There is no second capture and no registration step, and a robot and a technician's glasses report positions that can be compared directly.
The property that surprises people: you do not have to query from where you captured. Localization matches a live camera view against the map, not against a recorded flight path, so a device can localize from a position and an angle no flight ever occupied, as long as it is looking at mapped surfaces. The drone flies the facade. The technician stands at the bottom of it two weeks later and gets a pose from the same map.
It is a REST call. Not an SDK dependency, not a flight-controller integration.
Three endpoints share one response shape. POST /vps/map/query takes JSON with one base64 image and answers in about two seconds. POST /vps/map/query-form is the same query when uploading a file is easier than encoding one. POST /vps/map/multi-image-query takes four to six frames and returns a consensus pose, which is the right choice in repetitive or partly occluded scenes.
A request carries the map code, the image, the camera intrinsics and the frame dimensions, plus whatever hints you want to apply. The response is small and always the same shape: whether a pose was found, position as x, y and z in metres, rotation as a quaternion, a confidence value between 0 and 1, which map it matched against, and how long the query took. The full request and response reference, with worked examples, is in the Map Query docs.
Gate on that confidence value. Applying a low-confidence pose is worse than applying none, because it moves something that was previously correct.
If the frame is a full 360 panorama, the request gets shorter rather than longer. Set imageType to equirect and send the map code, the handedness and the image. No fx, no fy, no principal point, no width or height, because a full sphere fixes the geometry by itself. The pose you get back describes the forward-looking direction, the way the centre column of the panorama faces. Panoramas need to be at least 1.9:1, between 2048 and 16384 pixels wide, and under 30 MB, and 4096 by 2048 is a good default. Larger is not better.
Hints narrow the search when you already have a rough idea where you are:
hintPosition with hintRadius, from 5 to 100 metres around a known point.hintMapCodes to pin the query to specific maps inside a MapSet.hintFloorHeight to restrict the search to a vertical band.geoHint to seed from a GPS fix, on a georeferenced map.One trap worth printing. Hints are always supplied in the map's native left-handed frame, whatever you set isRightHanded to. Passing a right-handed hintPosition straight back from a previous result is the most common reason a query mysteriously stops finding a pose.
When a query does fail, the documented ladder is short. Query with the fast engine, which answers in about two seconds. On poseFound: false or low confidence, retry the same frame with Deep Search, which searches more of the map for up to 15 percent higher recall at three to four seconds. If it still fails, keep running on local tracking and re-query from a different viewpoint.
The architectural constraint underneath all of this, stated once: a query is a network round trip, so it cannot live inside a control loop. Onboard visual-inertial odometry flies the aircraft between queries, and each VPS fix stops that estimate drifting. It is the same division of labour a ground robot uses, which is the point. The platform does not have a drone mode.
The framing of RTK as the thing visual positioning replaces is wrong, and the API makes it obvious why.
Georeferencing a map means posting control points. Each one pairs a map-local x, y, z in metres with a WGS 84 latitude, longitude and altitude, and the server solves the map's origin and heading from those pairs, so no compass reading is required. You need at least three, not all on the same vertical line, with six decimal places on the coordinates.
Control points are exactly what an RTK rover produces. That is the join. Your existing survey workflow is what ties the visual map into the real world, once.
rmseMeters, horizontalRmseMeters, maxErrorMeters, which points were kept as inliers, which were rejected, and a tiltCheck telling you whether the map's gravity alignment is sound.geoHint, and every pose comes back as GeoPose.
So an existing waypoint stack that speaks latitude and longitude carries on speaking it, with a visually derived position underneath when the satellites cannot supply one. RTK builds the frame. Visual positioning delivers position in that frame when RTK cannot hold a fix.
| Layer | Gives you | Fails when | Role |
|---|---|---|---|
| GNSS and RTK | Global position, centimetres with corrections | Multipath, canopy, canyon, roofline, interference, or the correction stream dropping | Primary in open sky, and the source of the control points that georeference the map |
| VIO and onboard SLAM | Smooth relative motion at a high rate | Always drifting, never absolute | Carries the pose between fixes |
| VPS | An absolute 6-DoF pose against a prior map, orientation included | No prior map, unmapped area, feature-poor scene | Absolute correction, and the only layer that does not share GNSS's failure mode |
That last row is the whole argument. A fallback that fails for the same reason as the primary is not a fallback. It is a second copy of the same risk.
| Use case | What the pose makes possible |
|---|---|
| Change detection | Two flights of the same site land in one coordinate frame, so a difference becomes a measurement rather than two orthomosaics compared by eye |
| Inspection and QA/QC | A defect gets a map-space coordinate instead of a photo filename, so whoever comes next can find it again, on foot or in the air |
| Incident reporting | Place, time and the camera position the photo was taken from, all logged together. The photo becomes evidence with a location attached |
| Tracking inside other systems | Live pose drawn into the reconstruction, or handed to a GIS, a fleet view or an ops console as GeoPose |
| Air-to-ground handoff | The drone that surveyed the site and the technician who walks it later agree on where everything is |
| Progress capture | This week's flight lands in last week's frame with no alignment work |
Change detection deserves a straight answer rather than a claim. MultiSet gives you the shared frame and the aligned captures. It does not ship a diffing product. Map Versioning aligns scans taken months apart using the VPS itself rather than ICP, which is why it survives repainted walls, swapped fixtures, different sensors and different point densities where geometric matching gives up, and the panoramas carry position and orientation per capture point, which is what makes a visual before-and-after comparable at all. The frame is the hard part. The diff is the easy part, and it is yours.
| Condition | Failure mode | What to do |
|---|---|---|
| A single-altitude flight | Will not reconstruct at all | Four passes, low, mid and high, as one continuous clip |
| Auto exposure or a tilted start | Grey smeared map, or a frame whose tilt breaks floor bands, georeferencing and any measurement off the mesh | Lock the shutter and white balance, and let the aircraft settle level before recording |
| Feature-poor or reflective surfaces | Confidence drops, or worse, a confident wrong pose | Gate on confidence, retry with Deep Search, add a wider context pass, turn on false-positive detection |
| A site that changed since capture | Poses that are right about a space that no longer exists | Map Version the zone that moved, set a recapture cadence per zone |
| Wind, rain or moving subjects | Blur and inconsistent geometry | Daylight and stable light, nothing large moving through the area you care about |
Everything above holds regardless of vendor. Here is how we have built for it.
One pipeline, scan-agnostic on the way in, producing a human-readable scene and a machine-readable map from the same capture. It runs in:
Map versioning carries your anchors and routes forward across recaptures instead of resetting the world each time, and a Fortune 100 industrial customer runs this pattern in private cloud production.
Everything in v2.3.0 is additive, so existing integrations need no changes.
By recognising where it is. Fly the site once with a 360 camera and process it into a map. In flight, send a camera frame to the localization API with the map code. A pose comes back in about two seconds: position in metres, rotation as a quaternion, and a confidence value, all in that map's coordinate frame. Onboard visual-inertial odometry carries the aircraft between queries. Each pose is absolute, so it carries no accumulated error however long the flight has been running.
Yes, and it works in both directions. RTK control points are what georeference the map in the first place, so your survey rig builds the frame. Once that is done, a visual pose comes back as GeoPose in the same latitude and longitude your waypoint stack already uses, which means the handoff needs no new coordinate system. The reason it works as a fallback is that visual positioning fails for entirely different reasons than GNSS. Multipath, canopy and interference do not touch it.
No. An Antigravity A1 uploads its raw .insv directly. Any other drone carrying a 360 camera that exports monoscopic 2:1 equirectangular .mp4 works through the same pipeline. What does not work is flat, single-lens footage, which is what most drones record by default.
No, it is ageing, and the decay is zonal rather than total. A loading yard changes weekly, a facade changes over years. Map Versioning plus partial recapture handles it: rescan the zones that moved, keep the ones that did not, and anchors authored against the original frame carry forward. The question is not whether to recapture but at what cadence per zone.
Aircraft will keep changing. So will sensors, payloads and capture formats. The conserved quantity across all of them is the registration: the shared frame every future flight lands in, and every device on the ground can be measured against.
A flight without one is a folder of pictures with a timestamp on it.
If you want to give yours a coordinate frame, start free on the developer portal or book a demo. One flight is all the hardware asks.
Further reading: 360 Video to VPS · Antigravity A1 · Map Versioning · Localization · Equirect Query · Georeferencing Maps · How It Works
