Press Release
MultiSet AI has released v2.3.0. Mapping has always started at ground level, with a person walking a space holding a camera. v2.3.0 lifts it. Fly a 360° camera over a site and the map that comes back serves the drone in the air and the phone in a technician's hand, in the same coordinate frame, with no second capture and no alignment step. The release also localizes from a single 360° panorama with no camera intrinsics, publishes a point cloud for every map regardless of how it was captured, turns panoramas already sitting inside scan files into navigable tours, and flags the localization failure mode that is hardest to detect. v2.3.0 shipped on 26 August 2026.
Aerial capture and ground capture have lived in separate stacks. Drone survey produces one deliverable, a walked scan produces another, and reconciling them is a project of its own. Two captures, two coordinate frames, and a manual registration step between them that nobody wants to own.
v2.3.0 removes the split. Mount a 360° camera on a drone, fly the site, and the resulting MultiSet map is a normal map. A drone can localize against it in the air. A phone, a headset, or a robot can localize against it on the ground. Same map, same frame, same API call.
Three capture inputs go in without a conversion step:
The flight path matters more than the aircraft. Orbit a subject to establish it, snake a facade, spiral a tower, or run overhead lanes across an open site.
Large industrial sites already get flown. Progress photography, roof inspection, stockpile volumes, facade survey. That footage has been an image archive. In v2.3.0 it is a positioning asset.
Localization has always needed to know the lens. Focal length, principal point, distortion. Cameras that arrive without calibration data have been a recurring blocker on enterprise integrations.
A full 360° panorama does not have that problem. It contains the whole sphere, so the geometry is fixed by the format itself. The query is three steps:
One image, one call, one position. That is the shortest path into MultiSet positioning that exists today, and it works from a 360° camera, a drone frame, or an archived panorama nobody planned to localize against.
Every processed map now writes PointCloud/map.pcd alongside its other outputs:
This matters because a point cloud is the format the rest of the industry already speaks. Robotics stacks consume it. CAD and BIM tools import it. Analysis pipelines are written against it. Until now, teams who wanted MultiSet positioning and a point cloud had to capture twice, once for the VPS map and once for the survey deliverable.
A mesh and a point cloud now come out of every capture, whatever the input. The Gaussian Splat and the panoramas that become a 360° tour are opted into at map creation with source.metadata.assets, and cannot be added afterward. Nothing about the capture itself changes.
v2.2.0 made every map a navigable 360° tour. v2.3.0 extends that to the panoramas already embedded inside point cloud scans. Declare them through source.metadata.assets at upload and the panoramas inside .e57 and MatterPak files publish as tours, positioned in the same space the VPS works in.
Most enterprise sites have already been scanned. Those files carry panoramas that were captured, stored, and never used as anything but a viewer artifact. They are now a walkthrough that knows where it is.
Tour orientation from scan sources is also corrected in this release, resolving a 90° yaw offset.
A localization system that returns nothing is an inconvenience. A localization system that returns a wrong pose with high confidence is a real problem, because everything downstream trusts it. Content lands in the wrong place, a robot corrects toward the wrong position, and nothing in the stack reports an error.
v2.3.0 adds false-positive detection. The SDK cross-checks every localization response against the device's own motion. When the returned pose disagrees with where the device has actually moved, the pose is discarded and onLocalizationFalsePositive fires. Your application decides what happens next: retry, fall back to tracking, or ask the user to move.
This is the first release where a wrong answer is treated as a distinct event rather than a bad number.
Multi-frame query previously required a tracking pose with each image, which meant it only worked inside a live SLAM session. The per-image imageN_data tracking pose is now optional, so multi-frame accuracy reaches inputs that have no tracking at all:
The SDK also accepts a configurable API environment. MultiSetConfig takes a baseURL, and MultiSet.shared.activeBaseURL reports the host in use, so the same build points at public cloud, a private cloud tenant, or a staging environment without a rebuild.
The rest of the release is quality and reliability work:
v2.3.0 is live on MultiSet's public cloud and rolling out to private-cloud, self-hosted, and on-device customers on each environment's normal cadence.
Existing integrations require no changes. Everything in this release is additive. Optional tracking poses relax a requirement rather than replacing one, so multi-frame queries that already send tracking data keep working exactly as written. False-positive detection is a callback you opt into. Reconstruction, session, and scan handling improvements apply automatically.
Maps already processed carry their point cloud, so for most teams it is waiting in the Developer Portal. Full details in the v2.3.0 changelog.
