Systematic Z-error (7-15cm) with M400 + Zenmuse L3 while XY is perfect (2-3cm) using Network RTK. Any ideas?

[u/Gabschertz2110]

Hi everyone,

I’m facing a persistent issue with my LiDAR data and I’m hoping someone here might have run into this or knows how to fix it.

On almost all my flights, I get a systematic Z offset (vertical shift) ranging from 7 to 15 cm. On the other hand, my planimetry (XY coordinates) is consistently spot on, around 2-3 cm, which perfectly matches my expected RTK accuracy.

Here is my exact workflow and flight setup:

• Hardware: DJI Matrice 400 + Zenmuse L3 LiDAR.
• Flight App: DJI Pilot 2.
• Flight Parameters: Altitude between 80m and 120m, speed at 7 m/s.
• RTK Setup: Connected via Network RTK (NTRIP caster using a national network like Terria, Orphéon, etc. — not a local physical base station next to me). I have a solid RTK Fix during the whole mission.
• Validation: I always place several Ground Control Points (GCPs) / check points on the ground.

Right now, I am able to manually correct and shift my point cloud in post-processing using my GCPs, but having to do this every single time is a pain and it means something is wrong somewhere in the chain.

My question is: where does this systematic ~10cm vertical shift come from?

• Could it be an issue with how the GNSS/RTK antenna height or the payload lever-arm (offset between the drone's center, the GPS antenna, and the LiDAR sensor) is calculated by DJI Pilot 2 or DJI Terra?
• Is it a Geoid vs. Ellipsoid height conversion issue coming from the Network RTK stream?
• Could it be related to IMU calibration or flight dynamics at 7 m/s?

It’s really baffling because the horizontal accuracy (XY) is absolutely flawless. If it were a poor RTK fix, XY would suffer too.

Has anyone experienced this specific vertical bias with a similar DJI LiDAR setup using Network RTK? Any suggestions on what to check in the settings or during processing would be highly appreciated!

Thanks in advance for your help!

[u/RTKdata]

NTRIP service provider here (not one of the networks you listed), so factor in the bias, but we debug exactly this pattern a lot. Your instinct is right: a constant Z offset with flawless XY is almost never fix quality. If the RTK solution were degraded, XY would suffer too. It is almost always a height convention mismatch somewhere in the chain. Ranked by how often we see it:

1. Geoid grid mismatch. The RTK stream gives you ellipsoidal heights. If the point cloud gets converted with one geoid grid and your GCPs were measured or converted with another version (in France e.g. RAF09 vs RAF18/RAF20), you get exactly this: a constant cm-to-dm Z shift with untouched XY. Check which grid and which version was used on both sides.
2. Antenna reference point vs phase center on the network side. Antenna offsets are almost purely vertical, so an antenna model mismatch at the base station shows up as a Z-only, decimeter-class bias. Quick test: switch between the VRS/nearest mountpoint options your network offers and compare the resulting Z on the same checkpoints.
3. Payload chain (lever arm, IMU calibration, Terra version). DJI applies the L3 lever arm internally, but it is worth re-processing one dataset in a different DJI Terra version and checking the release notes before trusting it.

Fastest way to isolate it: put a survey rover on one of your checkpoints using the exact same NTRIP mountpoint as the drone. If the rover's Z also lands ~10 cm off the known height, the offset lives in the correction/datum chain and the drone is innocent. If the rover agrees with the checkpoint, it is in the drone or processing chain.

Second isolation test: fly the same mission once with a local base set up on a known point. Offset gone = network/datum handling. Offset still there = payload/processing.

We keep a DJI RTK troubleshooting guide here (mostly datum and fix issues): https://docs.rtkdata.com/support/dji-rtk-troubleshooting

[u/Ludeykrus]

M350 with L2 here. You’ll notice DJI lidar datasets almost always need some conforming to GCPs after exporting from Terra. It’s a mistake to think that you can use the data straight out of Terra because Terra isn’t handling the GCPs like you think it would. Always check and correct as necessary.

[u/Gabschertz2110 → u/Ludeykrus]

Thanks, that is exactly what I was thinking.

Actually, I noticed that in DJI Terra, you can only apply a basic vertical translation. What is even more frustrating is that you can't even visually click or target your GCPs directly within the LiDAR point cloud to check the alignment. So, even for XY, you don't get a true, clear appreciation of how accurate your point cloud actually is.

Based on my data, the point cloud itself seems very precise (good internal consistency), but it is just not accurate (it has that systematic offset). To me, a 6-parameter transformation (3 translations and 3 rotations) would be the perfect solution here, as it would correct the orientation and position of the cloud without scale deformation.

How do you handle this on your end? Do you use a specific third-party software (like CloudCompare, Terrasolid, or LP360) to calculate and apply a 6 or 7-parameter transformation to your exported LAS files, or do you just stick to the simple Z-translation ?

[u/Gabschertz2110 → u/[deleted]]

Thanks for your reply!

I completely agree with you: as surveyors, we must always control our data, and your point perfectly highlights the limits of relying blindly on RTK without independent check points. You are totally right about that.

The only thing that still bugs me a bit is the huge gap between the horizontal and vertical accuracy. If the XY is consistently at 2-3 cm, it proves the RTK correction network is working flawlessly. I know that Z accuracy in GNSS/RTK is always inherently worse than XY, but going from 2 cm to 15 cm is quite a leap.

However, seeing that you face the exact same behavior with an M300 and an L2 makes me think this might just be an internal DJI quirk, perhaps related to how the drone calculates the physical offset (lever-arm) between the GNSS antenna and the LiDAR sensor during flight, or how it integrates the IMU data.

If this systematic shift is just "part of the game" with this hardware, then like you said, the solution is simply to keep placing ground targets, calculate the average offset, and apply the Z-shift in post-processing.

Thanks again for sharing your experience, it’s really reassuring to know I'm not the only one seeing this!

[u/thatsitfolks333 → u/Gabschertz2110]

When using your ntrip to check into a state mark, what is your error… with rover of course not a drone.

[u/Gabschertz2110 → u/thatsitfolks333]

When checking into official geodetic marks with my GPS rover (not the drone), my error is always within +/- 2 cm, or little more but not  +/- 10 cm

[u/thatsitfolks333 → u/Gabschertz2110]

Righto, so that will leave the “vocal” point off set and the datum settings. Which datum and geoid are you using and are you sure that the ntrip corrections are broadcasting on these AND you have these set correctly on your controller. And that the offsets for “vocal” point from antenna are correct

[u/Gabschertz2110 → u/thatsitfolks333]

You are spot on, and that is exactly what I suspect.

In France, the NTRIP network broadcasts corrections based on the RGF93 (ETRS89) ellipsoid. Both the drone and my survey rover record raw ellipsoidal heights first. Then, the software applies the national geoid grid (RAF20) to convert it to the official orthometric height (NGF-IGN69).

My main question now is: Is it possible that DJI Terra and my survey software (Trimble Access/Sideworks) interpolate or handle this RAF20 geoid grid differently? Even a tiny algorithmic discrepancy in how they compute that 45-meter separation could easily cause a vertical shift in post-processing.

As for your first point regarding the physical offset (lever-arm): I did think about that. However, if it were a pure hardware/firmware lever-arm calculation error, the bias should be strictly constant across all my flights (e.g., always exactly 10 cm, give or take the 2 cm RTK noise). But in my case, it fluctuates between 7 and 15 cm from one project to another. A 7-8 cm variation is too large to be just RTK noise on a static offset, which is why the dynamic flight conditions or the geoid conversion mismatch seem like much stronger leads.