Any action or procedure performed is a program call. All these calls are held in a large resource library, and the SDK is a program kit that adds these new features or actions to the large library.
Exp, Gimbal Up, Yaw, RTH are all common calls for all DJI crafts. The code isn’t typed each time, the label / Name of procedure is called. Within the Libraries, they don’t have multiple entries for common calls. Next level are specific calls for platform, ie:
Mavic 3. Within this section are common calls unique to
Mavic 3, and next level is specific features per model, Thermal, multispectral, RTK port, etc.
If FW has a new feature or activated/expanded a circuits function. These FW entries already exist in the Library. This will get updated / patched as needed and FW file specific for model will get complied & generated.
To allow extended use of these Libraries, there’s a header section that indicates what specific model development can access and generate FW files or access and use the calls in Interface Code … the App to control and issue instructions to craft. This doesn’t limit Internal Development, only External Development. External Development doesn’t generate new FW, it develops the interface code for an app.
Once the programs calls are in the Library, that feature set is limited by craft athorization, meaning add them to the List of Crafts as in example above.
My view, all the calls are in the Library currently and to correct / patch or enhance the feature, the Library Call is updated so new FW can be generated. New Development versions are released often to Extenal Developers, to include recent updates & patches.
The only component missing is DJI adding the
Mavic 3 to the allowed crafts that External developers can access and direct their Development.
This was a quick detail, much more in-depth but this is the gist of it.
