DJI Waypoints Repeatability Test - Logs vs Real Flight Path (Mini 5 Pro & Mavic 3 Pro)

[trisen1981]

Hi everyone,

I ran a controlled waypoint repeatability test using the same mission flown multiple times on:

• Mini 5 Pro & Mavic 3 Pro
• Day and night flights
• Planned in Litchi Mission Hub
• Analyzed using DJI logs, Google Earth paths, footage comparison, and photogrammetry

From the log perspective, everything appears clean and repeatable.
However, when comparing actual footage and reconstructed camera paths, things are… not as straightforward.


I documented the full process - flying, log analysis, Google Earth comparison, and camera reconstruction using photogrammetry - in this video:

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

 

[Meta4]

Hi everyone,

I ran a controlled waypoint repeatability test using the same mission flown multiple times on:

• Mini 5 Pro & Mavic 3 Pro
• Day and night flights
• Planned in Litchi Mission Hub
• Analyzed using DJI logs, Google Earth paths, footage comparison, and photogrammetry

From the log perspective, everything appears clean and repeatable.
However, when comparing actual footage and reconstructed camera paths, things are… not as straightforward.


I documented the full process - flying, log analysis, Google Earth comparison, and camera reconstruction using photogrammetry - in this video:

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

It's important to understand the limitations of your equipment.

Your drone's height measurements are all done with a barometric sensor that measures air pressure and all heights are based on the power up location = 0 metres.
Setting heights above ground in Litchi does not use actual height above ground level.
Your drone has no way to measure heights above the ground (except at close range).
Litchi is using a digital elevation model (DEM) for ground level all over the world - a sort of digital contour map with only approximate accuracy.
Then Litchi converts your desired heights above the approximate DEM ground level to heights relative to the launch point which the drone will understand.
The AGL heights are only going to be approximate reflecting the accuracy of the DEM and if you launch from different locations which are not at the same ground level, this will add another inaccuracy since all heights are from startup location = 0.
Changes in local atmospheric pressure from one flight to another might contribute to small differences in height too.
Also if you land the drone at the launch point and compare the inndicated height at landing to the start at zero feet, you will often see that there is drift in the indicated height for the duration of the flight.

With respect to horizontal positioning:
You've just demonstrated the variable (in)accuracy of consumer GPS.
Consumer GPS is unable to have repeatable pinpoint accuracy and is only is only accurate to +/- 2-3 metres.
The "drift" you noticed might be due to GPS inaccuracy rather than actual drone movement.
I would not expect wind to cause the sawtooth pattern you showed.

 

[trisen1981]

Thanks for the detailed response - I agree with a lot of what you wrote, especially regarding barometric altitude drift and consumer GPS limitations.

A few clarifications on why I decided to investigate this deeper:

• I’m not assuming AGL mode in Litchi represents true ground clearance - I’m aware it’s DEM-based and approximate. The comparison here is not “AGL accuracy vs reality,” but repeatability across identical missions flown from the same launch point.

• The horizontal offsets I’m seeing aren’t single-point GPS noise. When reconstructing the flights using photogrammetry and aligning the footage, the offsets are consistent over time, not random jitter. That’s what raised the red flag for me.

• I fully expect 2–3 m GPS variance. What surprised me was seeing up to ~8-10 m separation between reconstructed camera paths across repeated flights, while the logs themselves still appear nearly identical.

• I’m also not suggesting wind alone caused this - the issue shows up even in segments with minimal lateral correction and stable yaw/pitch.

That’s ultimately why I documented the whole process (logs, Google Earth paths, footage alignment, and camera reconstruction) instead of relying on any single data source.

Really interested to see any day-night transition with Enterprise drone + RTK with its cm accuracy- in the city environment

 

[DJ Wes]

I've done a number of projects showing construction progression where the same flight is repeated and the video footage blended together. What you have documented is a common problem where it becomes a challenge to seamlessly blend footage from one flight to the next.

A few comments on your video:

Another thing that contributes to horizontal offsets in two photos or video from different flights are slight errors or "wobble" in the drone's heading. If you check the gimbal heading (either from the logs or from the EXIF data in the photos) on different flights you will notice slight differences. A one degree difference at 60 meters away will result in a one meter horizontal difference.

You had mentioned the "Above take-off" versus "Above ground" option in Litchi. The drone will only ever be able to calculate its height above take-off. Litchi's "Above ground" option uses a DEM to calculate ground elevation offsets between waypoint #1 and every other waypoint. Assuming your take-off elevation is the same as the ground elevation under waypoint #1, Litchi will apply those offsets to all waypoints in the mission (except for waypoint #1) to achieve the above-ground height. The fact that in your simulation, waypoints 2 and 3 appeared to match the height of the logged data was just by chance.

The apparent difference in the flight paths (when viewed from above) show that even though the data's GPS coordinates from one flight to the next may agree, the absolute position may not. That is just the nature of consumer GPS.

Yours is a very nice video documenting limitations relating to consumer GPS, barometric height, and repeatability in general.

 

[trisen1981]

Safety note for anyone using waypoint missions in tight spaces:

This is the main takeaway from my test - do not rely on waypoint missions for obstacle clearance in constrained environments.

In my case, in one of the missions, Litchi planned path showed safe clearance,, but the drone’s actual position was a few meters lower than expected. The aircraft ended up flying between upper and lower power lines purely by luck.

Waypoint missions on consumer drones should be treated as approximate guidance, not deterministic paths. Always leave a large vertical and horizontal safety buffer (10-12 meters minimum), especially near wires, poles, or structures.


I’ve linked the video below showing the near-miss so others don’t have to learn this the hard way.

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

 

[dajomu]

I watched the video in the original post with considerable interest, and was quite surprised (and disappointed) to see a glaring issue in the testing procedure that no one has mentioned so far (as of the time of this comment): The "footage" that is compared toward the end of the video is actually a series of still photos taken at UNSYCHRONIZED 2 second intervals during each flight, put together to form a timelapse sequence for each flight. The operator does nothing to synchronize when those photos are taken relative to the start of the mission. Indeed, as you can see throughout the first portion of the video, he initiates the recording of those interval photographs at an apparently random time before the drone reaches waypoint 1 on each flight. This means that photos are likely to be taken at different locations along the flight path on each flight. How much location variability might there be? At 5:02 we see that the global speed for the mission is 10 meters per second. So the distance traveled between each 2 second interval is 20 meters. So, even if the drone followed exactly the same path through space, at exactly the same orientation, there would be no reason to expect the photos to match from flight to flight, and every reason to expect them to NOT match.

The other thing that's a bit mis-guided here is comparing the full paths as shown in Litchi's mission planner, vs the paths traveled by the drone while executing the mission. Yes, the 3 waypoints were created in Litchi, but only those 3 points are being used by the drone while flying. The path that the drone takes to get from one waypoint to the next is being computed by DJI's Waypoint software, not Litchi's. And it is obvious from even casual use of Litchi's mission planner vs DJI's, that the two programs connect waypoints with significantly different path geometries (DJI's are generally more rounded and smoother than Litchi's). So there is no reason to think that the actual path recorded in the DJI flight logs will match the path exported from Litchi, as shown in Google Earth. The only points where you'd expect the paths to match would be at the 3 waypoints.

None of the above takes away from all of the other good and valid comments others make above, regarding reasons why DJI Waypoint missions follow slightly different real world paths each time they run. But the methodology used in preparing this video introduces additional sources of variation that need to be considered when evaluating the results that are presented, and the usefulness of the exercise it documents.

 

[trisen1981]

I watched the video in the original post with considerable interest, and was quite surprised (and disappointed) to see a glaring issue in the testing procedure that no one has mentioned so far (as of the time of this comment): The "footage" that is compared toward the end of the video is actually a series of still photos taken at UNSYCHRONIZED 2 second intervals during each flight, put together to form a timelapse sequence for each flight. The operator does nothing to synchronize when those photos are taken relative to the start of the mission. Indeed, as you can see throughout the first portion of the video, he initiates the recording of those interval photographs at an apparently random time before the drone reaches waypoint 1 on each flight. This means that photos are likely to be taken at different locations along the flight path on each flight. How much location variability might there be? At 5:02 we see that the global speed for the mission is 10 meters per second. So the distance traveled between each 2 second interval is 20 meters. So, even if the drone followed exactly the same path through space, at exactly the same orientation, there would be no reason to expect the photos to match from flight to flight, and every reason to expect them to NOT match.

The other thing that's a bit mis-guided here is comparing the full paths as shown in Litchi's mission planner, vs the paths traveled by the drone while executing the mission. Yes, the 3 waypoints were created in Litchi, but only those 3 points are being used by the drone while flying. The path that the drone takes to get from one waypoint to the next is being computed by DJI's Waypoint software, not Litchi's. And it is obvious from even casual use of Litchi's mission planner vs DJI's, that the two programs connect waypoints with significantly different path geometries (DJI's are generally more rounded and smoother than Litchi's). So there is no reason to think that the actual path recorded in the DJI flight logs will match the path exported from Litchi, as shown in Google Earth. The only points where you'd expect the paths to match would be at the 3 waypoints.

None of the above takes away from all of the other good and valid comments others make above, regarding reasons why DJI Waypoint missions follow slightly different real world paths each time they run. But the methodology used in preparing this video introduces additional sources of variation that need to be considered when evaluating the results that are presented, and the usefulness of the exercise it documents.

I think this critique is focusing on an issue that isn’t central to what was being tested.

1. The global speed shown in the mission summary (10 m/s) is not the speed used during the waypoint execution being analyzed. Each waypoint in this mission had its own explicit speed override set to 1 m/s, which is what the aircraft actually flew. And it is visible when the drone is doing the mission.

So the assumption of 20 meters of travel per 2-second interval is incorrect. The actual distance between interval captures was on the order of ~2 meters, not 20. That magnitude of along-path variation cannot account for the multi-meter lateral and vertical discrepancies observed between the day and night passes.

For clarity: interval timing differences explain small forward/backward offsets. They do not explain the persistent camera-space mismatch and positional drift (up to 10 metres )that remain even when accounting for timing.

2. Regarding Litchi vs DJI smoothing: with path mode set to Smooth Curves (it has other two modes - Litchi classic Curved Turns and straight) in Litchi, Litchi’s interpolation closely approximates DJI’s waypoint execution. I am not claiming the interpolated path is identical - only that it is sufficiently close to make multi-meter real-world deviations meaningful.

This test isn’t evaluating editing technique - it documents repeatability limits. Consumer DJI waypoint missions are approximate , not deterministic and the error is not 1-2 meters as many expect . Day vs night runs showed positional deviations of up to 10 meters. Anyone planning waypoint missions should treat the path as guidance only and maintain a minimum 10-12-meter clearance from obstacles.

That’s the limitation being documented.

 

[dajomu]

I think this critique is focusing on an issue that isn’t central to what was being tested.

1. The global speed shown in the mission summary (10 m/s) is not the speed used during the waypoint execution being analyzed. Each waypoint in this mission had its own explicit speed override set to 1 m/s, which is what the aircraft actually flew. And it is visible when the drone is doing the mission.

So the assumption of 20 meters of travel per 2-second interval is incorrect. The actual distance between interval captures was on the order of ~2 meters, not 20. That magnitude of along-path variation cannot account for the multi-meter lateral and vertical discrepancies observed between the day and night passes.

For clarity: interval timing differences explain small forward/backward offsets. They do not explain the persistent camera-space mismatch and positional drift (up to 10 metres )that remain even when accounting for timing.

2. Regarding Litchi vs DJI smoothing: with path mode set to Smooth Curves (it has other two modes - Litchi classic Curved Turns and straight) in Litchi, Litchi’s interpolation closely approximates DJI’s waypoint execution. I am not claiming the interpolated path is identical - only that it is sufficiently close to make multi-meter real-world deviations meaningful.

This test isn’t evaluating editing technique - it documents repeatability limits. Consumer DJI waypoint missions are approximate , not deterministic and the error is not 1-2 meters as many expect . Day vs night runs showed positional deviations of up to 10 meters. Anyone planning waypoint missions should treat the path as guidance only and maintain a minimum 10-12-meter clearance from obstacles.

That’s the limitation being documented.

My apologies regarding the speed issue. I missed that you had waypoint-level speed overrides. In light of that, I agree that the timing issue is less significant than I claimed. My bad.

 

[DJ Wes]

The other thing that's a bit mis-guided here is comparing the full paths as shown in Litchi's mission planner, vs the paths traveled by the drone while executing the mission. Yes, the 3 waypoints were created in Litchi, but only those 3 points are being used by the drone while flying.

In DJI Fly, the three waypoints are used as control points on a spline. DJI uses a Catmull-Rom spline for their missions. It is the spline that is used while executing the mission, not the control points directly.

The path that the drone takes to get from one waypoint to the next is being computed by DJI's Waypoint software, not Litchi's.

Both DJI Fly and Litchi's new Mission Hub compute the path the same way when Litchi's "Smooth Curves" path mode is used. Litchi refers to this as the "DJI Engine". You may be thinking of Litchi's traditional curved path where straight lines are used with quadratic splines producing the curves near each waypoint. Litchi refers to this as the "Litchi Engine".

And it is obvious from even casual use of Litchi's mission planner vs DJI's, that the two programs connect waypoints with significantly different path geometries (DJI's are generally more rounded and smoother than Litchi's). So there is no reason to think that the actual path recorded in the DJI flight logs will match the path exported from Litchi, as shown in Google Earth. The only points where you'd expect the paths to match would be at the 3 waypoints.

Litchi's new Mission Hub provides the choice of using either the DJI Engine (smooth curves) or the Litchi Engine (traditional curves) with appropriate drones. If the DJI engine is used, there is every reason to believe the path as shown in Litchi's Mission Hub will be the same as the path shown in DJI Fly (and flown by the drone). One should expect the entire paths to match. You can read more details of methods used to calculate the paths here:

Litchi Missions fs DJI Fly Missions

Litchi and DJI waypoint paths are computed differently. This document will describe how those paths are computed and the advantages of each method.

www.litchiutilities.com

 

[dajomu]

In DJI Fly, the three waypoints are used as control points on a spline. DJI uses a Catmull-Rom spline for their missions. It is the spline that is used while executing the mission, not the control points directly.


Both DJI Fly and Litchi's new Mission Hub compute the path the same way when Litchi's "Smooth Curves" path mode is used. Litchi refers to this as the "DJI Engine". You may be thinking of Litchi's traditional curved path where straight lines are used with quadratic splines producing the curves near each waypoint. Litchi refers to this as the "Litchi Engine".


Litchi's new Mission Hub provides the choice of using either the DJI Engine (smooth curves) or the Litchi Engine (traditional curves) with appropriate drones. If the DJI engine is used, there is every reason to believe the path as shown in Litchi's Mission Hub will be the same as the path shown in DJI Fly (and flown by the drone). One should expect the entire paths to match. You can read more details of methods used to calculate the paths here:

Litchi Missions fs DJI Fly Missions

Litchi and DJI waypoint paths are computed differently. This document will describe how those paths are computed and the advantages of each method.

www.litchiutilities.com

I was not aware of the new "DJI Engine" option in Litchi's Mission Hub. Thanks for letting me know. I'll check it out.