Rogue RTH Routing on Partial Waypoint Mission (DJI Fly / Mavic 4 Pro)
Environment & Equipment:
-
Drone: DJI Mavic 4 Pro
-
Controller: RC Pro 2
-
App/Protocol: DJI Fly (Waypoint 3.0 KMZ protocol)
-
Planning Software: New Litchi Hub (Imported/Exported KMZ via Litchi Hub Bridge)
Background & Mission Preparation: I am flying a complex 80-waypoint subcanopy route. During post-flight tuning, I updated a 10-waypoint segment near the end (WP64-73).
-
I exported the original route to KMZ, converted to CSV using the Wes Barris “DJI Fly to Litchi” utility.
-
I copy-pasted the 10 new waypoint rows into the CSV via Excel.
-
I imported the spliced CSV into the New Litchi Hub.
-
Crucial Detail: I explicitly verified in Litchi Hub’s Global Settings that the Finish Action was set to Return to Home (RTH).
-
I exported the final KMZ and loaded it onto the RC Pro 2 using the Litchi Hub Bridge.
Flight Execution (The Trigger): To test the newly spliced exit sequence, I executed a partial route flight.
-
Launched from my Home Point (HP), which is a wide-open lawn with zero overhead obstructions (0ft ATL).
-
Manually flew horizontally across the street to line up with WP35 (15ft ATL).
-
Loaded the waypoint mission in DJI Fly.
-
Set the mission to start at WP35 and clicked Next.
Mission Fragmentation: Prior to the final WP35-WP80 run, the WP62-73 segment was heavily debugged during the same flight session. This involved multiple Obstacle Avoidance (Hover) stops, manual repositioning, and immediate mid-route restarts. The flight controller’s RAM was heavily loaded with aborted mission loops prior to the anomaly.
Expected Behavior: The drone flies the route from WP35 to WP80. At WP80 (97ft ATL), the drone recognizes it is directly above the original Home Point (the open lawn). It executes the Global RTH command and descends straight down to land.
Observed Behavior (The Anomaly): The drone flew perfectly from WP35 to WP80. Upon reaching WP80 (directly above the open HP lawn at 97ft), it executed a bizarre, terrifying two-phase RTH sequence:
-
Phase 1 (The Jump): Instead of descending, the drone drew a straight line back to WP35. It flew over the tree line separating my lawn from the street, arriving above WP35, and descended to exactly 15ft ATL (the exact altitude at which the automation was initiated).
-
Phase 2 (The Tunnel Run): Now hovering at 15ft ATL across the street, the drone engaged Advanced RTH (Optimal). Using its vision sensors, it found a physical gap through the tree line, threaded the needle laterally across the street at low altitude, arrived above the true Home Point on my lawn, and finally descended to land.
Variables Ruled Out:
-
Obstacle Avoidance: There is zero canopy or obstruction above the HP lawn. A vertical descent was completely clear.
-
Battery Failsafe: The drone landed with 52% battery.
-
Signal Loss: The RC Pro 2 maintained a solid 5-bar connection the entire time.
-
Metadata/Converter Error: The Litchi Hub global parameters explicitly confirmed the Finish Action was RTH, not “Back to 1st Waypoint.”
Conclusion & Root Cause Analysis: There appears to be an undocumented logic bug in how DJI Fly handles the Return to Home Finish Action when a waypoint mission is started from a mid-point (e.g., WP35).
Rather than executing a true RTH from the final waypoint, the flight controller splits the command into a mandatory closed-loop sequence:
-
Return to Automation Origin: The drone forces a return to the exact spatial coordinate where it was handed automated control (in this case, WP35 at 15ft).
-
Execute True RTH: Only after the automation loop is “closed” at the injection point does it hand control back to the global Advanced RTH system to navigate to the physical Home Point.
Because the drone utilized AR Optimal for Phase 2, it subjected the drone to a highly dangerous low-altitude lateral transit across an active roadway.
Current Workaround: Set the Global Finish Action to Hover on all partial-route testing. This severs the RTH logic chain entirely, leaving the drone at the final waypoint for manual descent.