Swappable payloads let a drone change mission equipment while retaining the aircraft. Integrated payloads keep the principal sensing equipment in a fixed aircraft configuration. Choose between them by asking which measurements must be available together, which equipment must change between missions, and who will support each configuration. Neither architecture guarantees better imagery, longer endurance, or lower ownership cost.
The distinction has two levels: a removable payload can contain several tightly integrated sensors, while an aircraft with a fixed camera can still accept accessories. For a modular vs integrated drone payload comparison, identify exactly what can be removed and what remains shared with the aircraft.
On This Page
- Define the replaceable boundary
- Compare the complete mission configuration
- Trace power, commands and measurements
- Check compatibility at the function level
- Plan changeover and fault recovery
- Match the architecture to the mission
- Specify the demonstration before choosing
Define the replaceable boundary
A payload is the equipment carried to perform the mission, such as a camera, scanner or onboard processing module. Here, swappable means designed for replacement at a defined aircraft interface. Integrated means the principal mission sensor assembly is fixed in the aircraft's normal operating configuration. Service repair and routine mission changeover are different capabilities.
DJI's Matrice 30 support documentation provides a concrete example. It identifies the gimbal and camera as fixed and not replaceable with other payloads, yet also describes a top-mounted Payload SDK interface. Accessory support therefore does not establish that the main camera can be exchanged.
At the other boundary, the Zenmuse H30 Series FAQ describes removable payloads supported on specified Matrice aircraft. The H30 combines visible cameras, a rangefinder and auxiliary illumination; the H30T adds thermal imaging. Multiple sensors can be integrated inside a swappable assembly. These are architecture examples, not a matched product-performance contest.
Modularity also differs from openness. A detachable unit may depend on a proprietary connector and software interface. Conversely, a fixed installation may expose documented data interfaces. The guide to open architecture in unmanned systems explains why replaceability, interface access and interoperability need separate examination.
Compare the complete mission configuration
The useful comparison is between two configurations capable of delivering the same result. Specify the required measurement, operating distance, coverage and delivery time before comparing the equipment needed to achieve them.
The table below is an engineering synthesis of the manufacturer interface documentation and protocol examples cited in this article. It describes questions and tradeoffs, rather than measured advantages of either architecture.
| Decision | Swappable payload architecture | Integrated payload architecture |
|---|---|---|
| Mission changes | Exchange a supported assembly when another instrument is required | Retain the fitted sensor set; a different primary instrument may require another aircraft |
| Simultaneous sensing | Fit a combined assembly or a supported multi-payload configuration | Use the channels already included in the fixed assembly |
| Configuration control | Maintain an accepted configuration for every aircraft/payload combination | Maintain the aircraft's fixed sensor baseline and its software dependencies |
| Resource comparison | Include mounts, adapters, cables and any separate processing equipment | Include all fitted equipment, including channels unnecessary for the task |
| Fault and repair planning | Establish whether a spare assembly can restore the mission | Establish the actual service replacement boundary and backup-aircraft need |
| Future changes | Verify support for the specific proposed replacement | Verify whether software or accessory changes can satisfy the new requirement |
Do not compare a bare aircraft's maximum flight time with another aircraft carrying its complete camera suite. Ask for endurance under the intended sensor load, flight profile and reserve policy. Mounting provisions and removable connectors are real hardware, but their presence alone does not establish a measurable endurance penalty. Likewise, integration is not proof that the installed sensor set is the lightest option for a particular job.
Airframe choice remains a separate constraint. A payload that meets the sensing requirement still needs a suitable flight and recovery profile; multirotor vs fixed-wing UAS covers that comparison. Keep payload architecture from becoming a shortcut for choosing the entire aircraft.
Trace power, commands and measurements
Successful integration connects physical mounting, electrical supply, control and usable data. DJI's payload-port documentation distinguishes power, communication, time-synchronization and high-speed data connections. It also gives model-specific interface constraints and gimbal payload-centering instructions. A latch that closes correctly proves only one part of the connection.
Even a familiar connector can hide a different data role. The current documentation describes the Matrice 300 RTK OSDK connection in USB accessory mode and the Matrice 350 RTK E-Port as a USB host by default. Use the instructions for the actual aircraft and port. The same document also marks some older development kits as historical or existing-deployment references; a kit appearing in an interface table is not evidence that it can be bought or supported for a new integration.
For either architecture, trace the mission through four questions:
- What supplies power? Identify the permitted supply, peak operating demand, startup behavior and cooling arrangements for the installed equipment.
- Who issues commands? Identify the operator application, aircraft software and any companion computer between the operator and sensor.
- What comes back? Separate live preview, saved measurements, status and the metadata needed to interpret each observation.
- What happens when a component stops? Establish which data become invalid and how the operator recognizes the loss.
The MAVLink Camera Protocol v2 illustrates the software side. It defines camera discovery, capabilities, capture, streaming and storage functions. Its documentation explicitly distinguishes basic camera-trigger support from the richer protocol. A device can be reachable without implementing every function the mission requires. Check the reported capability flags, storage status and capture status separately. A heartbeat establishes presence, while a live stream and a saved recording are distinct functions. The protocol also warns that its streaming metadata is not precisely synchronized to individual video frames, so a mission needing that relationship must demonstrate its own timing path.
Pointing adds another control path. The MAVLink Gimbal Protocol v2 separates a gimbal device from the manager that handles control requests. That manager may reside in the autopilot, an integrated camera/gimbal or a companion computer. The arrangement determines where commands are coordinated; a shared plug does not answer that question. Where this protocol is used, verify the manager status and the identity of the controlling application. Primary and secondary control ownership need to be configured deliberately, and the way their inputs are combined depends on the implementation.
For a proposed replacement, ask the integrator to show the requested view, recorded output and associated status together. A live preview alone does not demonstrate that the required measurement was saved. For an integrated aircraft, ask the same question about every sensor channel the mission will actually use.
Check compatibility at the function level
Compatibility needs a configuration and a task. The current H30 FAQ lists Matrice 400, Matrice 350 RTK and Matrice 300 RTK, specifies DJI RC Plus for the Matrice 300 RTK combination, and calls for aircraft and controller firmware updates. That is more precise than saying a payload works with a brand's drones. Record the aircraft, payload, controller and software versions for the supported combination.
Independent engineering work illustrates why this matters. In their 2024 Matrice payload study, Springer and colleagues integrated a Raspberry Pi 5 with a Matrice 350. Their implementation used both E-port and SkyPort paths because accessing aircraft camera feeds and streaming processed video to the controller involved different capabilities. They also documented startup-order and interface issues in that configuration.
The study demonstrates that a removable module can be deeply integrated with aircraft resources. Its implementation details concern a 2024 software and hardware baseline; they should not be treated as instructions for every current SDK release. For new work, request a current demonstration of the specific input, processing and output path.
Open-interface claims need similar precision. Johns Hopkins APL's account of Modular Payload Design Standard Revision 6.1 describes defined payload classes and a host/payload architecture. It does not establish that arbitrary commercial cameras are interchangeable. Name the applicable interface and revision, then examine the supported functions and physical limits. This is a description of a particular standard revision, not a claim that it is the latest revision or that any proposed payload complies. The broader MOSA for UAS guide develops the supplier and component-replacement questions.
Plan changeover and fault recovery
Treat changeover as the interval from finishing one mission to being ready to perform the next with valid data. Mechanical removal is one step. The procedure may also involve protective covers, correct mounting, software recognition, selecting the right camera, and completing the checks specified for the fitted instrument. Follow the manufacturer's power-off and handling procedure; quick release does not establish hot-swap permission.
Use a rehearsal to expose the operational differences. The following checks apply the discovery and control behavior in the MAVLink documentation; actual procedures must match the installed system.
| Rehearsal | What to observe | Decision it informs |
|---|---|---|
| Start with the intended payload fitted | Correct identity, available functions and usable sample output | Whether the crew can distinguish a ready sensor from a connected device |
| Change to the second supported configuration | Recognition, settings and the instrument-specific checks needed | The actual work involved between missions |
| Interrupt a payload data connection in a controlled bench test | Stale information becomes distinguishable from current output | Whether a lost sensor could appear to remain usable |
| Restore the connection | Rediscovery, valid status, correct device identity and verified control ownership | What must happen before the mission can resume |
MAVLink's camera specification calls for a disconnected camera to be removed from the available list when its heartbeat disappears and for identification to restart after reconnection. Its gimbal protocol assigns direct device control to the associated manager. Those are useful behaviors to verify where these protocols apply, not universal descriptions of every drone.
A removable spare helps only if the fault lies within the replaceable assembly and the replacement is supported. A shared aircraft port, controller application or power problem may remain. Ask which diagnostic steps distinguish those cases, who can perform the replacement, and which checks are needed before returning it to service.
Match the architecture to the mission
Use the mission schedule to choose the boundary. The scenarios below are selection guidance derived from the preceding integration requirements, not measured productivity comparisons.
- Repeated visual and thermal inspection: a fixed sensor suite is a reasonable fit when its channels meet the required observations and changing instruments provides little benefit. Confirm output quality at the working distance and whether both channels can be used as required.
- Different survey instruments on separate assignments: swappable assemblies are useful when the required instruments differ and supported combinations exist. Include changeover, instrument checks and crew competence in the schedule.
- Research with evolving sensors or onboard processing: a modular boundary can accommodate changes, but budget for interface development and repeat configuration testing. A development kit does not make the integration turnkey.
- Two teams needing different sensors at the same time: swapping equipment on one aircraft cannot provide two simultaneous aircraft missions. Compare the shared-platform proposal with the fleet capacity actually needed.
- A mission needing several channels during one event: assess a combined sensor assembly or supported simultaneous-payload installation. Sequential swapping is unsuitable if it misses an observation that cannot be repeated.
Compare ownership costs over that same schedule. Request separate figures for aircraft, instruments, adapters, integration, training, spare equipment, service and revalidation after updates. Include downtime that affects scheduled work. No universal saving follows from buying fewer aircraft: the answer depends on simultaneous demand and the support obligations for each configuration.
Specify the demonstration before choosing
Ask each supplier to demonstrate one complete representative mission with the proposed configuration and deliver the resulting data. For a swappable system, add the second payload and the complete changeover procedure. For an integrated system, demonstrate every required channel and explain the route for repair or a future sensing requirement.
Keep the configuration record with the results: hardware identities, software versions, fitted accessories, relevant instrument checks and operating conditions. Include the saved sample data, the metadata timing required by the task, and the control/status checks needed after a changeover. Accept the architecture that meets the observations, schedule and support needs with manageable dependencies. Treat future payload flexibility as useful only when the replacement path is specific enough to verify.
Sources
- DJI: Support for Matrice M30 Series. Manufacturer FAQ for the fixed main gimbal/camera and separate top-mounted SDK interface.
- DJI: Zenmuse H30 Series FAQ. Manufacturer FAQ for sensor combinations, named aircraft/controller compatibility and firmware conditions.
- DJI Developer: Aircraft Hardware Port. Current official interface documentation covering model-specific mounting, power, data, USB roles and synchronization; legacy kit listings do not establish availability.
- MAVLink: Camera Protocol v2. Project specification for discovery, capabilities, capture/storage status, streaming, metadata limitations and reconnection.
- MAVLink: Gimbal Protocol (v2). Project specification for manager/device roles, supported control arrangements and controller ownership.
- Springer et al., arXiv: Lowering Barriers to Entry for Fully-Integrated Custom Payloads on a DJI Matrice. Original 2024 research preprint documenting a particular Matrice 350 computational-payload implementation and its historical software/hardware limitations.
- Johns Hopkins Applied Physics Laboratory: Design Standard Update Improves Modular Architecture for Unmanned Platforms. The standard developer’s August 2025 account of Revision 6.1 and its architecture; neither a universal compatibility claim nor an independent performance comparison.
Last checked: November 6, 2026.
