A theory on the Woes of Litchi/Autopilot caused by New DJI Firmware

[Tim Pearson]

I'm both a Litchi and a Hangar (Autopilot) customer. Customers got e-mail notices from both companies this week about "erratic flight behavior" with their products for users who had upgraded their Mavic, Inspire 2, or P4 Pro to the latest DJI firmware. While I'm grateful for the timely notice from both companies, I'm increasingly frustrated by the design philosophies of both Litchi and Hangar. The post below is sheer conjecture - but I suspect it's at least close to accurate with respect to these most recent issues resulting from the new DJI firmware. If I'm close to being right here, then I'd really encourage both Litchi and Hangar to make some "attitude adjustments" in the development department that will make future events like this much less confusing (and concerning) to their respective customer bases.

After analyzing what both Litchi and Hangar (Autopilot) had to say, I think the evidence points to a situation similar to this one:

Note for the curious non-IT person (skip otherwise): I use the term "API" several times below. API stands for "Application Program Interface" - and consists of, in the DJI case, a set of in-software "levers/buttons and gauges" that the flight software exposes to other programs so that the other program can communicate with the flight software and have some control over what's going on. DJI will also publish a document that 3rd party programmers can refer to that explains what each "API Call" (lever or gauge) is, what it does, and how to use it. "Get" API's send commands that "read the value of a gauge" and return it to the 3rd party program (Litchi/Autopilot). "Set" API's allow the 3rd party program to change the position of a "lever" or toggle the on/off state of a "button".

I betcha that, like many other software companies I've seen, DJI publishes a "standard" set of APIs and a "hacker" API set that lets you deeper into what's going on. They represent to the developers something like: "We promise that we won't alter or "break" the "standard" APIs as we come out with new firmware. The "Standard" API set will be as stable and reliable as possible across firmware.

Then DJI says: In addition, here's this "hacker" API (or set of them) that will let you directly control a lot more stuff... BUT we don't promise that we won't change/break these whenever we need to. Many software manufacturers will do something similar.

In general, 3rd parties can't resist using the "hacker" interface to another product because it let's them do REALLY cool stuff that's not possible with the standard API set -or- it let's them do regular stuff a lot faster (something important when you have an aircraft in flight!).

All well and good, until something DJI needs to do to correct an issue or provide an enhancement of their own causes the no-promises "Hacker" interface to change slightly, or even (to borrow a term) bigly. Then the 3rd party software breaks.

This isn't unique to DJI/drones. People who write code to run on Windows fall prey to their own "non standard" methods used for performance reasons or to do "cool stuff". A Windows Update comes out and their software has issues dealing with it... all because they didn't stick to the "standard" interface Microsoft constructed for apps to use to interact with the operating system. There may be a darn good reason they used the non-standard method. Autopilot, for example, wouldn't be NEARLY as useful if they hadn't done some of this.

For DJI, What I'm calling "Hacker Mode" or the "Hacker API set" appears to be needed when any real-time control of the aircraft by the code running on the phone/tablet is required. The flight software in the aircraft isn't really making many decisions in this mode. It's sending telemetry to the iPad/iPhone/Android device and executing real-time, low level actions it receives from the Autopilot/Litchi app running on those devices. This might even mean that Litchi/Autopilot has to do lots of real-time work just to keep the aircraft stable and react to external forces like wind and obstacles. Can't say for sure because I haven't seen the API specs from DJI.

The "standard" API set appears to involve much less effort from the app on the mobile device. It's creating a set of commands... turn this way, fly at this speed, set the gimbal to x degrees, etc.. until you reach these coordinates. Then it uploads them in something you might think of as a "spreadsheet" - with one command (and it's parameters) per row. The flight software on the aircraft is in charge... it's getting broad, high level commands and executing them one after the other. After Autopilot/Litchi creates this list of commands and uploads them to the memory on the aircraft, it tells the aircraft "run the list of commands I just sent you" - which the DJI flight software dutifully does, one after the other until it reaches the end of the list. This process can continue, even if the 3rd party app loses it's connection with the aircraft. The aircraft already has all the commands stored on board and can keep running them in sequence - all the way to the end of the list.

Autopilot fell into this "Hacker API" trap far more than Litchi did - and they started to do the right thing... create an "on/off" switch for the user that disabled all their features and modes that relied on "hacker" access and created less featured "standard access" alternatives that could be used instead. The "Lost Connection" toggle in the Waypoint settings is a less-than-obvious name for the "advanced/hacker mode on/off" switch that I wish they'd "escalated" to a "system level" option that restricted the entire Autopilot product to use only the standard API set - and disabled features and modes for the user that wouldn't work using only "standard" APIs. That would assure that when the inevitable happened and the "hacker" mode got broken - they could issue a much simpler directive to their users: "Go to "System Settings" and turn the "Advanced Features" switch off until we have an update to go with this new firmware."

Litchi also went "off the reservation" and added stuff that requires "hacker" level access to the aircraft. They should add the same "Advanced Features" on/off toggle in their system settings.

Now that DJI made some (intentional or unintentional) changes that broke some of the "hacker mode" commands, we're left with a confusing set of instructions from Litchi and Autopilot... "You can safely use this and this mode but not this one or this other one."

Wouldn't it have been nice if the user manuals for these apps had a bold section that said something like: If you experience unexpected behavior or failures with our app right after a DJI firmware update, go to "Settings" and turn "Advanced Features" off, then contact us. The limited features and modes available with Advanced Settings turned off should work with the new firmware. If not, again, please contact us.

Similarly, when something happened, the instructions to their users could be a lot simpler: Turn off Advanced Features till further notice if you have firmware x.x.x installed.

Who knows, maybe we'll see some improvements in this area as a result of this pretty significant "oops" event for both Litchi and Autopilot. I sure hope so!

Thanks,

Tim

 

[GMack]

I have a feeling both Litchi and Autopilot got the notice first from DJI. Probably a bug DJI found in their SDK kit and forwarded it to them until their next SDK kit is issued. Doubt if that may fliers experienced all the bugs they found and that quick and simultaneously.

I think Autopilot has a red warning in their write up about flipping the P4 out of P mode into S mode to disable the program, although there is a cancel at the bottom of their flight screen too.

 

[smiller]

I have a feeling both Litchi and Autopilot got the notice first from DJI.

DJI introduces new features without any documentation whatsoever all the time, leaving users to figure things out for themselves. They may be better with respect to the SDK but I sure wouldn't count on it.

 

[Philltayl]

The 3rd party developers need to be able to keep up with the manufacturer..............often they don't and it's not the fault of the original operating system team...........the world is littered with this.........

 

[ecolumbia999]

I've been writing software with the DJI api for over a year and this is my take. Upgrades are always difficult for software developers. Writing software, especially android apps, takes a degree of juggling to keep everything working. There is the DJI sdk (or api if you prefer) which gets upgraded approximately every 4 months, there are the frequent upgrades to the firmware which are specific to DJI models, there are different android devices to support, different screen sizes and densities, and also different android operating systems to support.
In addition due to the way an android app communicates with the drone via the rc, any app built on the DJI sdk has to deal with how the phone is set up that might interfere with this communication. The interference can show up as making the app slow, causing disconnects, or simply causing the app to close.
Any general ground control DJI software is going to have a hard time supporting the past versions of all these items as well as frequent future changes.
However this is to be expected in this industry especially with DJI. DJI is releasing not just new products but new capabilities every 4 months or so which is good but very difficult to support.

 

[Hangar]

The post below is sheer conjecture

No need for conjecture. The DJI SDK has public documentation:
Documentation Introduction - DJI Mobile SDK Documentation

You are correct that there are two primary modes of control in the SDK. They are called Virtual Stick and Mission. Virtual Stick does allow for much more fine grained control vs Mission, but both are fully supported, as stated in both the documentation and by DJI directly in the many interactions that we have had with them over the years. Neither of these modes can be considered the hacker / unsupported control mode that you are referencing.

 

[dwallersv]

While I understand where the OP is coming from, my experience in the IT industry over my 33 year career makes this highly unlikely for these two applications, and same for most if not all 3rd party S/W in any sort of widespread use.

Reputable software companies never take risks like this. Fully supported external APIs are strictly used, and any needed functionality outside of this is engineered by the company itself, either directly or by contract. Often, a company will work with the API vendor to add functionality they need. I have no doubt both Litchi and Autopilot have active, strong relationships with DJI.

The reason for this is obvious: The existence of the company could rise or fall on a catastrophic defect the company is solely responsible for, yet utterly powerless to correct in any way, if they use unsupported code they do not have any control over or access to.

This sort of "hack" commercial software development is characteristic of a handful of reckless startups and unethical companies, which are always coming and going on the scene. Ironically, much of this sort of garbage is cloneware coming out of -- wait for it -- China.

 

[Tim Pearson]

No need for conjecture. The DJI SDK has public documentation:
Documentation Introduction - DJI Mobile SDK Documentation

You are correct that there are two primary modes of control in the SDK. They are called Virtual Stick and Mission. Virtual Stick does allow for much more fine grained control vs Mission, but both are fully supported, as stated in both the documentation and by DJI directly in the many interactions that we have had with them over the years. Neither of these modes can be considered the hacker / unsupported control mode that you are referencing.

So what I was calling "Hacker Mode" is DJI's supported "Virtual Stick" API set. That casts DJI in a much less favorable light in this case. They shouldn'-a-broke it, Captain!

Thanks for the additional information and thanks for a great product. Also, FYI, I included your clarification about Virtual Stick as a supported DJI API set in my most recent blog post. Thanks again!

Tim