# DJI Payload SDK: building hardware that talks to DJI drones > The Payload SDK is DJI's development kit for writing payloads that mount on DJI aircraft through the X-Port, SkyPort or extension port adapter. It is a C library with a CMake build, samples in both C and C++, and it targets Linux and RTOS platforms. The code is MIT licensed, but the repository also carries a separate EULA file. **dji-sdk/Payload-SDK** — DJI Payload SDK Official Repository - Repository: https://github.com/dji-sdk/Payload-SDK - Website: https://github.com/dji-sdk/Payload-SDK - Stars: 551 · Forks: 225 - Language: C - License: NOASSERTION - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/dji-sdk-payload-sdk ## What the SDK is for The DJI Payload SDK, abbreviated PSDK, is a development kit provided by DJI to support developers developing payload that can be mounted on DJI drones. The word payload is the one to understand first. In DJI's model, an aircraft has a flight controller, and a payload is a separate piece of hardware that attaches to it and does a specific job. The payload can be a sensor, a camera, a computing box, a mechanism. The aircraft flies; the payload observes or acts. The SDK is the interface between the two. That interface is physical as well as software. Combined with the X-Port, SkyPort or extension port adapter, developers can obtain information or other resources from the drone. So there are three named connector families, and the SDK supports all of them. The repository topics list the hardware this targets, with xport, skyport and skyportv2 all appearing alongside drone, uav, robotics, gimbal, lidar, camera, sensors, collision-avoidance and flight-controller. The M300 and M300-RTK appear in the topics too, which identifies the aircraft platform in use. That is a useful clue for anyone evaluating the SDK, because the aircraft determines which connector you have and therefore which port family your payload has to speak to. The primary language is C, which is the right choice for embedded payload software and not an accident. A payload is often a microcontroller with limited memory and a real time operating system, and the badge at the top of the readme states the platform as linux_|_rtos, meaning both Linux and RTOS targets are supported. The same source tree serving both a Linux companion computer and a bare metal RTOS board is a constraint that pushes a toolkit towards C. The repository is the official one, dji-sdk/Payload-SDK, and the last push was on 2026-10-15. ## The kinds of payload the SDK is meant to enable The readme lists the kinds of thing the SDK is designed to let you build, and the list is more useful than it first looks because it shows the range of control the interface exposes. There is Automated Flight Controller. That is a payload that takes part in the flight, which is a far stronger relationship than a payload that merely watches. There is Payload Controller, which is a payload that manages another payload or an attached device. There is Video Image Analysis Platform, which is a payload that does computation on the imagery it captures. There is Mapping Camera, which is a survey payload. And there is Megaphone And Searchlight, which is an actuator payload, broadcasting or illuminating. Grouping those five tells you what the SDK actually provides. It is not only a telemetry feed. It covers three distinct relationships: the payload observing the aircraft and its environment, the payload influencing the flight, and the payload driving its own attached equipment. A megaphone does not need to influence the flight at all, while an automated flight controller does nothing but influence it, and a video analysis platform is mostly an observer that happens to be expensive. That range is what makes the SDK interesting for a robotics developer rather than only for a camera vendor. The same toolkit can carry a compute payload that runs a vision pipeline, a mechanism that moves, or a controller that takes over part of the flight logic. The framing in the readme is that the actions are performed according to the software logic and algorithm framework designed by the developer. In other words, the SDK is the transport and the plumbing, and what the payload does with the information is yours to write. ## Repository layout, samples and the build The top level of the repository is short and tells you the shape of the project. There is a CMakeLists.txt at the root, which is the build entry point and immediately confirms this is a native C project rather than something with a managed toolchain. There is a psdk_lib/ directory, which is the library itself. There is a samples/ directory, a tools/ directory, a doc/ directory, and the README, the licence files and the EULA. The samples directory contains sample_c++/ and sample_c/. That is a deliberate choice worth noting. Most SDKs ship one language, and the choice is usually the convenient one. Shipping both means a payload developer working in C++ on a Linux companion computer and a payload developer working in C on an RTOS board are both first class, and the API is demonstrably usable from both rather than only nominally. The tools/ directory is the part that is easy to overlook in an SDK repository and often carries a lot of the practical value. For a protocol-driven SDK like this one, the tools are typically the configuration and diagnostic utilities, the things that talk to the aircraft over its debug or serial interfaces. The readme does not describe them in detail, which is a reason to look at the directory rather than assume it is empty. The doc/ directory is local documentation, and the readme is explicit that full documentation lives on the DJI Developer Documentation site instead. The documentation split is between the Payload SDK tutorial and the PSDK API Reference, both with English and Chinese versions, plus a page for the latest version information and release notes. So there are two documentation surfaces. The site is the reference and the tutorial, and it is where version specific behaviour is documented. The repository's doc/ directory is the version pinned documentation that travels with the code. ## Release cadence and how versions are tracked The version scheme is plain and the release history is regular, which is the kind of thing to check when you are putting a vendor SDK into a device. The badge in the readme reads V3.17.0, matching the most recent release, PSDK 3.17.0, released on 15 October 2026. Before that came PSDK 3.16.0 on 1 April 2026 and PSDK 3.15.0 on 11 December 2025. So the SDK is on a three to six month release cadence with minor version increments. The names are the minor version and the patch level, and the releases carry a description with the version and the release date, which is a small convention that makes a changelog readable without a separate notes file. The readme's handling of release information is worth noting as a practice. It does not reproduce release notes in the repository. It points at the official DJI Developer Documentation for the latest Payload SDK version information and release notes, with links to both the Chinese and English tutorial pages. And in the documentation section it points at a Latest Version Information page. The upshot for a user is that the repository readme tells you which version you have and where the notes for it are, and the notes live on a website that is versioned separately from the repository. That has an obvious benefit, since a web page can be updated when the underlying SDK is, and an obvious cost, since the notes for an older version may not be as easy to find as a tag in a git history. The SDK is at a 3.x version, so the interface has been through several rounds of change. The API reference on the developer site is versioned, and the sensible approach is to read the reference for the specific version you are building against rather than for the newest one. ## Licensing, and the file you should not skip The licensing arrangement is slightly more complicated than the badge suggests, and it is worth reading carefully. The badge at the top of the readme says MIT. The licence section says the Payload SDK codebase is MIT-licensed and refers you to the LICENSE file for detailed information. But the repository listing shows two licence files, LICENSE.txt and EULA.txt, and the platform metadata records the licence as a custom one that GitHub cannot classify. The resolution is that there are two separate things. The SDK codebase itself, the source in psdk_lib/ and the samples, is MIT, which is a permissive licence with almost nothing attached to it beyond attribution. The EULA.txt is a separate document that presumably covers the terms under which the payload runs on DJI hardware and interacts with the aircraft firmware. That distinction is normal for a hardware vendor SDK, and it is also the reason the metadata says custom rather than MIT. GitHub is reading the repository's declared licence and finding a combination it cannot map to a single standard identifier. The practical instruction is simple. If you are building a payload to ship commercially, read both files. The MIT licence on the code tells you what you may do with the source. The EULA tells you what you may do with the payload once it is mounted on a DJI aircraft and talking to a DJI flight controller, and that is the set of terms that matters for a product. The third-party libraries the SDK pulls in will have their own licences, and for a device that has to pass certification those are the ones your legal team will want to see listed as well. The MIT licence on the codebase itself is the easy half of this review. ## Support channels and the contribution route The support section is thorough, and it is split in a way that reflects who the SDK is for. There is the DJI SDK Developer Forum, with separate Chinese and English Zendesk community sites. There is Developer Support, where you submit a request describing your problem, again with Chinese and English entry points. And there is Stack Overflow, where the readme asks you to use the dji-sdk tag. The distinction between the forum and the support request is the one that matters in practice. The forum is public, so anyone can read the answer, and a question answered there helps the next person. The support request is a ticket, so it is a private channel to DJI for something that needs a person to look at it. The readme lists them as separate routes with separate purposes, which is a sensible arrangement and mirrors how most vendor SDKs work. The pull request section is the part with the most nuance. The readme says the DJI Dev Team is committed to improving the developer experience and that contributions are welcome, but that the code review of any pull request may not be timely, and asks you to email dev@dji.com when you have a question. So the expectation is set honestly. Contributions are accepted and will be reviewed, but the review may be slow, and if you need to know something in the meantime, email rather than wait. That is a fair warning for a vendor repository where maintainers have other work, and it is better than the alternative of discovering the queue is slow only after you have sent a patch and waited three weeks. The repository is the official one and it is actively maintained, with the last push on 2026-10-15 and three releases across the preceding ten months. ## Conclusion Adopt the Payload SDK if you are building hardware that has to mount on a DJI aircraft and read its state, because the port interfaces and the flight controller protocol are the parts you would otherwise have to reverse engineer. Do not adopt it as a general drone control library, because the SDK is about the payload side of the relationship rather than about flying the aircraft itself. Before you commit, read the EULA.txt file as well as the MIT licence on the code, since the repository carries both, and expect the documentation on the developer site rather than the repository to be where the real reference lives. ## FAQ ### What is the DJI Payload SDK? It is a development kit provided by DJI for developing payload that can be mounted on DJI drones. Combined with the X-Port, SkyPort or extension port adapter, developers can obtain information or other resources from the drone, and the SDK is MIT licensed with a primary language of C. ### What kinds of payload can be built with the DJI Payload SDK? The readme names Automated Flight Controller, Payload Controller, Video Image Analysis Platform, Mapping Camera, and Megaphone And Searchlight. That covers three distinct relationships: the payload observing the aircraft, the payload influencing the flight, and the payload driving its own attached equipment. ### What platforms does the DJI Payload SDK support? The badge in the readme states the platform as linux_|_rtos, so both Linux and RTOS targets are supported, and the repository is a C library with a CMake build at the root, a psdk_lib directory, tools, docs and samples in both sample_c++ and sample_c. ### What licence applies to the DJI Payload SDK? The codebase is MIT licensed, with the details in the LICENSE file, and the badge at the top of the readme says MIT. The repository also carries a separate EULA.txt, which is why the licence is recorded as a custom one that GitHub cannot classify, so both files are worth reading before shipping a payload commercially. ### How often is the DJI Payload SDK released and where are the release notes? The recent releases are PSDK 3.17.0 on 2026-10-15, PSDK 3.16.0 on 2026-04-01 and PSDK 3.15.0 on 2025-12-11, so roughly every three to six months. The readme points at the official DJI Developer Documentation for the latest version information and release notes, in both Chinese and English. ## Sources - [dji-sdk/Payload-SDK on GitHub](https://github.com/dji-sdk/Payload-SDK) - [Issues](https://github.com/dji-sdk/Payload-SDK/issues) - [Project website](https://github.com/dji-sdk/Payload-SDK) - [README](https://github.com/dji-sdk/Payload-SDK/blob/master/README.md) - [Releases](https://github.com/dji-sdk/Payload-SDK/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dji-sdk-payload-sdk