Executive Summary
ESA's NAVISP-funded LUPIN project, led by GMV UK, demonstrated a tightly coupled multisensor PNT engine (ANIME) delivering sub-8-metre 95th-percentile positioning against simulated lunar radio-navigation signals. The headline geodetic finding is that RF geometry and signal availability, not relative-sensor quality, govern absolute accuracy – a result subsea positioning engineers already know intimately. We unpack what an emerging lunar reference frame must deliver before those metre-level numbers mean anything, and what transfers to GNSS-denied offshore work.
From GNSS-denied to GNSS-analogue: what LUPIN demonstrated
The European Space Agency’s NAVISP programme has funded a project, LUPIN – “Enabling high performance PNT in the lunar environment” – led by GMV UK, that tackles a problem any surveyor working GNSS-denied waters will recognise on sight. Lunar rovers have relied on relative sensors: inertial measurement units and visual odometry that track motion continuously but drift without bound. Absolute fixes have come from computationally heavy terrain matching or intermittent Earth-based tracking. Neither combination gives you a persistent, bounded position in a global frame.
LUPIN’s answer is a tightly coupled multisensor architecture called ANIME. Its PNT engine runs an extended Kalman filter fusing IMU data with RF-based absolute positioning, visual odometry, star-tracker attitude and digital elevation model (DEM) aiding. It runs in an Earth configuration on real GNSS, or a Moon configuration on simulated signals from the planned Moonlight lunar communication and navigation service (LCNS) and lunar GNSS. To feed realistic Moon-side conditions, the team built LUSIM, a simulator that converts terrestrial rover trajectories into lunar scenarios and generates synthetic LCNS/GNSS pseudorange, Doppler and carrier-to-noise measurements while modelling visibility, satellite geometry, signal errors and outright failures.
Testing ran on GMV’s RAPID rover platform, with shakedown trials in Oxfordshire and final field campaigns in Fuerteventura, Canary Islands, across daytime and nighttime operations and a range of rover speeds. The reported figures: best 95th-percentile three-dimensional position error below 6 m in the Earth configuration and below 8 m on the Moon side, velocity errors below 0.1 and 0.2 m/s respectively, and attitude errors under 2 degrees. The finding that matters most is stated plainly in the project’s own results – RF geometry and signal availability dominate performance. Relative sensors improved continuity and robustness but did not substantially improve absolute positioning. Three RF measurements plus DEM constraints were needed for stable dynamic operation.
The lunar PNT specification is being written now – and it starts with a frame
Treat LCNS as the lunar analogue of a GNSS constellation and the comparison to terrestrial practice becomes exact. A GNSS position is only as good as the reference frame it is expressed in. On Earth we take that frame for granted because ITRF is realised to millimetre-to-centimetre level through decades of VLBI, SLR, GNSS and DORIS, curated in the coordinate registries that IOGP maintains. We express survey accuracy at the 95% confidence level under IHO S-44 and rarely think about the datum underneath, because its realisation error is negligible against our total propagated uncertainty.
The Moon has no such luxury. There is no operational lunar equivalent of the ITRF. The lunar reference frame is currently realised through Lunar Laser Ranging to the Apollo and Lunokhod retroreflectors and through JPL’s DE440/441 planetary and lunar ephemerides, which tie the Moon’s centre of mass, orbit and physical libration together. On top of that sits a cartographic subtlety that has caught mission planners before: the Moon Mean Earth/Polar Axis frame used for maps differs from the Principal Axis frame in which the lunar orientation is naturally expressed. The two are related by small rotations, but confuse them and you introduce systematic surface offsets of order a kilometre. Any rover claiming a 6-to-8-metre position has to declare which frame it means and how that frame is realised, or the number is not comparable between missions.
This is precisely what the interoperability work behind Moonlight and NASA’s LunaNet is trying to nail down. The LunaNet Interoperability Specification is, in effect, the draft standard for how lunar PNT signals, time and reference frames must be defined so that a European rover and an American lander read the same coordinates. LUPIN is a demonstration against that emerging specification, not against a finished one. Reading the result as “8 metres on the Moon” without reading it as “8 metres in a frame that itself is still being realised” misses the geodesy entirely.
Why geometry beat the sensors, and why subsea engineers already know this
The headline engineering lesson – that RF geometry and availability set the accuracy ceiling, and better relative sensors do not lift it – will surprise nobody who has run acoustic positioning in deep water. The structure of the lunar rover problem is identical to the subsea one. An INS aided by a DVL in bottom-lock is a superb relative sensor: it gives you smooth, high-rate motion with excellent short-term accuracy. Left alone it drifts, and the drift is unbounded. You bound it with sparse absolute observations from USBL or an LBL array, exactly as the rover bounds IMU and visual-odometry drift with LCNS pseudoranges. IMCA’s guidance on deepwater acoustic positioning has long made the same point LUPIN rediscovered on basalt: the absolute solution’s quality is governed by the geometry and availability of the acoustic fixes, not by how good your inertial sensor is. A better IMU buys you longer coasting between fixes and a smoother trajectory; it does not fix a weak transponder geometry.
Geometry here means dilution of precision. With a lunar constellation that is sparse and, in early Moonlight phases, small, the space vehicles will often sit in a narrow cone above the horizon, driving vertical and 3D DOP up hard. That is the mechanism behind the Earth-versus-Moon gap in the reported numbers – the terrestrial GNSS geometry available in Fuerteventura is simply richer than anything simulated for a nascent lunar service. The same geometry-and-integrity argument drives the interest in denser space segments and low-Earth-orbit augmentation offshore, which we’ve set out in our analysis of LEO augmentation and the integrity case for DP. More ranging sources, better distributed, is the lever that moves accuracy – on the seabed and on the lunar surface alike.
The “three RF measurements plus DEM” result is the most instructive line in the whole campaign, and it is pure estimation geodesy. A full 3D fix needs four ranges to solve for three position components and the receiver clock. Constrain one unknown and you need one fewer range. A DEM supplies a height constraint – the same trick as altitude-aided GNSS on Earth, where a known height lets a three-satellite solution stay stable. Tight coupling is what makes this work: because ANIME fuses raw pseudoranges rather than pre-computed position fixes, partial measurement sets still contribute to the filter instead of being discarded when fewer than four ranges are visible. That is the single most valuable architectural choice for any GNSS-starved environment, and it is directly transferable to offshore INS/acoustic integration.
The gaps: frame realisation, time, integrity and the DEM crutch
Four things sit between this demonstration and an operational lunar navigation service, and each has a terrestrial parallel worth stating clearly.
Frame realisation is a hidden error term. On Earth we omit datum realisation from the error budget because it is negligible. On the Moon it may be one of the larger terms. The LCNS space vehicles’ own ephemerides depend on lunar orbit determination, which depends in turn on knowledge of the lunar gravity field – the GRAIL-derived models such as GRGM1200A are good but not GNSS-grade, and residual gravity error propagates straight into satellite position error and then into rover pseudorange error. When the project reports “signal errors”, a meaningful share of that is orbit and frame uncertainty, not receiver noise. A rover position quoted to 8 metres against a frame realised to a comparable level is not an 8-metre position in any absolute sense.
Time is not solved. PNT is positioning, navigation and timing, and the lunar timescale is an open standards question. Clocks on the lunar surface run faster than terrestrial ones by tens of microseconds per day owing to the difference in gravitational potential and relative velocity, and international work to define Coordinated Lunar Time is still in progress. Until that timescale is fixed and disseminated, every lunar pseudorange carries a clock-definition assumption. The resilience and definition of timing references is not an abstract concern for our own industry either, as we’ve discussed in the context of national timing networks and offshore PNT. Get the time definition wrong and the ranging falls apart the same way on the Moon as it does on Earth.
Accuracy without integrity is not a service. The reported figures are accuracy statistics – 95th-percentile error over a campaign. They say nothing about integrity: the probability that the reported position is trustworthy at a given moment, and the alert time when it is not. Terrain matching, DEM aiding and a sparse RF geometry are all fault-prone in ways that an accuracy percentile will not reveal. A lunar service intended to guide long, fast traverses over hazardous terrain needs a protection-level concept and receiver-autonomous fault detection analogous to what aviation and offshore DP demand, otherwise a single undetected ranging fault puts a rover into a crater wall.
The DEM aiding is a strength that can become a crutch. Height aiding stabilises the solution, but it couples navigation accuracy to the quality and registration of the elevation model. If the DEM is itself expressed in, or mis-registered against, a different lunar frame – the ME/PA trap again – the height constraint injects a systematic bias that the filter will happily absorb and smooth over. On Earth we see the equivalent when a geoid model or vertical datum is mismatched to the horizontal frame. The constraint that saved you a satellite can quietly corrupt your fix.
What to take from this now
For anyone building or specifying fused PNT – lunar, subsea or terrestrial GNSS-denied – LUPIN offers a set of testable positions worth adopting.
- Report accuracy and frame realisation as separate line items. State the 95th-percentile 3D error the way S-44 makes you state THU and TVU, and state the reference-frame realisation uncertainty alongside it. Never let a filter statistic stand in for absolute accuracy when the datum is itself uncertain.
- Specify tight coupling, and prove it degrades gracefully. Require the estimator to fuse raw ranges, and demonstrate stable operation on three ranging sources plus a height constraint. Test the transition into and out of that regime explicitly, at operational speeds, not just in steady state.
- Plan by geometry, not by sensor grade. Run DOP-based availability planning against the actual constellation almanac for the mission window, and identify the outage periods before committing to a traverse. Spending the budget on a better IMU when the limiting factor is a three-satellite geometry is money in the wrong place – a point our own sector relearns every time it over-invests in inertial and under-invests in acoustic or RF geometry.
- Demand an integrity layer, not just an accuracy number. Insist on a protection-level and fault-detection concept with a defined alert limit and time-to-alert before any autonomous, high-speed operation is authorised. Treat an accuracy percentile as necessary but not sufficient.
- Audit the vertical constraint’s datum. Confirm that the DEM and the RF frame share a realisation, and quantify the surface offset if they do not. This is the lunar version of the geoid-datum checks that belong in every offshore vertical-reference workflow.
The wider signal for our field is that the lunar programme is forcing a rigorous restatement of first principles we sometimes let slide: that absolute accuracy lives in the reference frame, that geometry sets the ceiling, that timing is part of positioning, and that integrity is a separate property from accuracy. LUPIN did not so much invent a lunar navigation method as demonstrate that the estimation architecture we already trust GNSS-denied works on the Moon – provided the frame, the time and the integrity case are built underneath it. That is the order of work, and it is the same order whether the rover is on Fuerteventura or in Mare Imbrium.
Based on: GMV UK Demonstrates Hybrid PNT for Lunar Surface Navigation
Published by
Positioning & Geodesy Working Group
GNSS, INS/IMU & Coordinate Systems
A working group of positioning specialists covering GNSS, inertial navigation, datum transformations, and geodetic network design for marine and land survey operations.
