DJI Matrice 350 RTK: A Payload Configuration Acceptance Guide

Buy a defined inspection system, not a list of compatible names

An inspection team does not deliver a drone flight. It delivers observations that another person can locate, interpret and use. An aircraft package can arrive with the expected model number, start normally and transmit a convincing live picture, yet still fail that task. The required surface may be outside the installed camera's view, the recording may lack necessary metadata, or the reviewer may be unable to open the original files.

The DJI Matrice 350 RTK aircraft listing should therefore begin a configuration discussion rather than end it. The purchasing unit is one documented aircraft, mounting arrangement, payload, software state and delivery workflow. Changing any of those elements can change what the team must verify. A successful demonstration with a different sensor or connector is useful background, but it is not acceptance of the package being delivered.

This guide provides a way to write that acceptance requirement before ordering. Numerical examples are hypothetical engineering exercises, not measurements of a supplied M350 or approval of an attachment. Aircraft operation, installation and maintenance must follow the current instructions for the exact equipment and the responsible operator's approved procedures. The objective here is to make purchasing assumptions visible and testable.

Start with the evidence the inspection must produce

Describe the asset and the decision first. A structural reviewer may need a contextual image identifying a connection, a detailed view of its accessible surface and an unambiguous link between both files. A thermal specialist may require original measurement-capable data rather than a colored screenshot. A survey deliverable introduces different processing and coordinate requirements. These are different outputs even when the same aircraft can carry equipment relevant to each.

Write one sentence stating what must be visible, from which direction, under what working conditions, and in which delivered file. Then add the acceptance method. For example, a procurement brief could require an assessor to identify a numbered test feature in both a context view and a detail view using the team's normal workstation. That is more useful than asking for excellent image quality without specifying how anyone will judge it.

Keep detection, classification and measurement separate. A feature appearing somewhere in a frame does not establish that its dimensions can be measured or its condition diagnosed. Ask the responsible inspection specialist to define the required evidence and limitations. The sensor choice should follow that requirement; a broad platform compatibility list cannot decide the needed lens, spectral capability, viewing access or analytical workflow on its own.

Freeze a configuration identity before comparing proposals

Assign each proposed package a configuration revision. Record aircraft and payload model identifiers, connector type, mounting location, batteries, removable hardware, controller, recording media and relevant software versions. Include the reference documents that establish the installation and supported combination. Use photographs of the assembled test article to show where components sit, but do not treat a photograph as evidence that an undocumented installation is approved.

DJI's M350 support information describes single, dual and combined upward/downward gimbal arrangements, with up to three payloads in the appropriate configuration. That platform capability does not mean every camera can occupy every location or operate in every combination. Obtain the documentation applicable to the exact payload, mount and simultaneous operating arrangement in the quotation.

Separate three questions in the comparison: can the assembly be installed as documented, can the required functions operate together, and does the resulting data satisfy the inspection brief? A supplier's answer to the first question is not an answer to the other two. List unresolved combinations explicitly. If a proposal depends on a future firmware version or an unverified third-party integration, keep that dependency outside the accepted baseline until it is demonstrated and documented.

Check the aircraft mass and the local mounting limit independently

The current DJI specifications list a 9.2 kg maximum takeoff weight, approximately 6.47 kg for the aircraft with two TB65 batteries and a single downward gimbal, and a 960 g maximum payload for the single gimbal damper. These figures describe different boundaries. Subtracting the nominal aircraft weight from maximum takeoff weight does not authorize that entire difference on one gimbal.

Build a mass ledger for the delivered assembly and weigh the flight-ready configuration using suitable equipment. Include the installed batteries, sensor, connector, adapter, mounting hardware and any other approved flight-carried item. Avoid counting a bracket twice because it appears in both an aircraft kit and a payload kit. Record what was actually on the scale; a number without an equipment list cannot be reproduced after a technician changes the assembly.

Consider an illustrative attachment made up of a 720 g sensor, a 110 g adapter and 40 g of associated hardware. Its combined mass is 870 g, leaving only 90 g against a 960 g numerical limit if that entire assembly is assigned to the limited mount. This is merely an accounting example: the documented definition of the mount load, attachment geometry and approved integration still control. Being lighter than a published limit does not establish compatibility.

Suppose a separate, hypothetical scale reading for a complete proposed aircraft is 7.87 kg. The numerical difference to 9.2 kg is 1.33 kg. That is aircraft-level headroom, not permission to enlarge the sensor on an already constrained mount. Review each applicable limit independently and preserve the configuration record behind both measurements. Also request confirmation of balance, clearance and any configuration-specific operating restrictions rather than trying to derive them from mass alone.

Use viewing geometry to test whether the package can see the job

A sensor can have adequate nominal resolution and still be a poor fit when the required view is blocked. Describe the target surface relative to the aircraft, not merely as an asset category. An underside, recessed connection or vertical face can require a different viewing direction from an unobstructed roof. Identify the intended observation positions, possible occlusion and the operator's safe access constraints before selecting a mounting arrangement.

For a simplified perpendicular view of a flat surface, scene width is W = 2d tan(θ/2), where d is the sensor-to-surface distance and θ is the horizontal field of view in the selected camera mode. A hypothetical 60-degree camera at 20 m sees about 23.1 m of width. Those values describe an imaginary sensor and scene, not the field of view or approved inspection distance of any M350 payload.

If the hypothetical image contains 4,000 horizontal pixels, dividing 23.1 m by 4,000 gives approximately 5.8 mm per pixel at that perpendicular plane. An inclined surface changes the scale across the image, and digital enlargement does not create additional captured detail. Optical performance, focus, contrast, motion and processing also matter. This calculation can reject an obviously unsuitable proposal, but it cannot certify that a defect of a particular size will be detected.

Ask for a representative sample using the proposed sensor mode and working geometry. Have the reviewer assess original files, not a presentation slide. Record the actual distance, lens or zoom state, orientation and processing applied. If the package requires an upward-facing installation to access the target, obtain exact configuration support rather than assuming a downward camera can achieve the same view simply because its gimbal moves.

Specify the power and control interface as a complete path

A connector name alone is not an electrical integration specification. Ask the payload supplier to identify its approved aircraft interface, installation instructions, operating modes, power demand and startup behavior. The evidence should cover the actual device revision and arrangement being purchased. Do not adapt a component by connector appearance or borrow a power limit from another port, aircraft or generation of the same product family.

For third-party equipment, require a clear account of which functions are supported through the documented integration. Establish how the operator starts and stops recording, changes settings, sees fault status and confirms that data is being saved. A live image proving that a video path exists does not establish reliable record control or access to every sensor output. List unsupported functions before the order is accepted.

Use an approved ground demonstration to exercise normal startup, recording and shutdown without inventing a flight procedure. Ask what happens if the payload is not ready when the aircraft system initializes, if storage is full, or if a supported application reports an error. The acceptance record should contain observed behavior and the documented recovery action. It should not instruct a technician to bypass a warning or improvise an electrical connection.

Make the file handoff part of the aircraft acceptance

The most important data path may begin after landing. Agree which device holds the original files, which metadata is required, how the files reach the review workstation and which software can open them. Distinguish a live-view stream, an onboard recording, an exported image and a processed report. They can represent different resolutions, metadata and analytical possibilities; one should not be accepted silently in place of another.

Define a sample delivery package before the demonstration. It might contain an asset identifier, a context/detail image pair, the original sensor files, a record of capture settings and a plain index connecting each observation to the asset. State the required file formats and version constraints. If an analytical workflow depends on a particular software license or calibration record, include that dependency in the proposal and test it on the buyer's intended system.

Data volume also affects daily practicality. As a purely hypothetical calculation, 500 files averaging 24 MB represent approximately 12 GB using decimal units. At a measured effective transfer rate of 40 MB/s, copying alone takes about 300 seconds. That five-minute estimate excludes locating media, opening files, verification, backup and processing. It is not a recording-rate or transfer-performance claim about the aircraft or a DJI payload.

Test a complete handoff, including verification that the copied files open and correspond to the right configuration and asset. A checksum comparison can help establish that two copies contain the same bytes; it does not prove the scene was correctly inspected. Keep original files separate from edited derivatives and identify transformations. The receiving reviewer, not only the flight operator, should participate in this acceptance step.

Separate platform limits from the inspection operating plan

A headline endurance figure cannot supply the missing inspection schedule. DJI's published 55-minute maximum uses an unloaded aircraft flying at approximately 8 m/s without wind until the battery reaches zero. It is not a loaded inspection allowance. Do not subtract an arbitrary percentage from that maximum and call the result a validated mission duration. The actual configuration and an appropriately planned demonstration are necessary.

Likewise, the aircraft's IP55 rating is not a blanket permission for the complete sensor package to work in every wet or dusty condition. DJI notes that protection can decline with wear. Identify the restrictions of every installed component, its connections and the manufacturer's current procedures. Where operating limits differ, the plan must account for the restrictive requirement rather than treating the strongest rating as transferable to everything onboard.

Ask the responsible operator to define the representative mission, environment, reserve policy and stopping conditions. Acceptance should observe the intended work while preserving those requirements, not pursue a record duration. Log the configuration, conditions, productive observation time, remaining work and any warning. A shortened or inconclusive demonstration is an unresolved requirement to investigate, not evidence that the advertised maximum is false or that the package is universally unsuitable.

Write acceptance criteria that produce an observable result

Replace a general promise of compatibility with a small set of witnessed checks. Each requirement needs an owner, an evidence item and a decision rule agreed before the test. Where the buyer has not yet defined a threshold, mark it as an open requirement rather than inventing a universal number. The table below shows useful categories, not a substitute for the equipment manuals or a flight authorization.

Keep the evidence at the level of the requirement. A photograph of a controller showing a live view can support a live-view observation, but not a claim that an original radiometric file was saved. A mass record can support an assembly mass, but not an assertion of aerodynamic approval. This discipline makes gaps easier to resolve because each missing item has a specific purpose rather than becoming an argument about whether the overall demonstration looked convincing.

Use a staged sequence: document review, approved ground checks, an appropriately authorized representative flight, then independent file review. Stop when a prerequisite fails. Do not change several settings and replace a connector halfway through a test without recording a new configuration state. If a change is necessary, preserve the failed observation and identify which earlier results remain applicable and which must be repeated.

Control substitutions after the demonstration

A passed demonstration applies to its recorded configuration. If the delivered camera, adapter, firmware or recording workflow changes, the earlier evidence needs review. Not every change requires repeating every test, but someone must decide which requirements it can affect. A different connector may affect mounting and access; a software change may affect commands or output formats; a media change may affect recording and transfer.

Require substitutions to be disclosed before delivery. Maintain a short change record describing the old item, new item, reason, affected requirements and verification completed. Avoid accepting equivalent as an undocumented purchasing term. Equivalence should refer to the specific inspection task and constraints, not merely a similar retail category or a higher number in one headline specification.

Preserve the accepted baseline for future troubleshooting and repeat purchases. When a later flight produces missing files or a different view, the team can compare the current assembly and settings with the accepted configuration. Without that baseline, diagnosing a hardware fault, a changed setting and a substituted component becomes unnecessarily difficult, and a second purchase may quietly recreate the same unresolved assumption.

Turn the inspection brief into an itemized purchase request

Send the supplier the asset type, required evidence, viewing directions, intended environment, processing workstation and proposed acceptance exercise. Request separate line items for the aircraft package, mission payload, required connectors, supported software and any services needed for delivery. The current UNITED UAV listing distinguishes the aircraft combo from separately sold mission cameras and sensors. An illustrated payload should never become an assumed included item.

Ask the proposal to identify supplied, optional, buyer-supplied and unresolved components. Those four categories prevent a complete-looking package name from concealing a missing sensor, integration step or software dependency. Clarify which party prepares the configuration record, performs installation, witnesses the demonstration and resolves a failed requirement. Commercial terms should state how unresolved acceptance items are handled rather than leaving them to an informal conversation after shipment.

Use the Matrice 350 RTK product page to identify the aircraft, then attach the configuration and output brief when requesting a proposal. A useful reply should explain how the exact package will produce the required evidence, identify remaining assumptions and propose a reproducible check. That creates a much stronger basis for comparison than selecting the longest list of supported payload names.

Questions to settle before accepting the package

Does sufficient aircraft mass headroom prove a sensor is acceptable?

No. Aircraft takeoff mass, local mount loading, approved installation, balance, clearance, electrical integration and supported operation are separate questions. A favorable subtraction addresses only one numerical boundary. Require the documented integration and checks applicable to the whole assembly rather than treating a scale reading as permission to fit any attachment.

Is a clear live picture enough to accept the inspection system?

Only if live viewing is the complete contracted requirement. If the team needs original recordings, metadata, measurement-capable files or reviewable asset evidence, demonstrate those outputs too. Open the actual delivered sample on the intended workstation and confirm the connection between the observation, asset and recorded configuration.

Should every firmware or component change trigger a complete retest?

Use a documented impact review. Identify which requirements the change can affect and repeat the relevant checks before relying on the modified system. Keep the previous baseline and new evidence distinguishable. The aim is neither blanket repetition nor automatic acceptance, but a defensible connection between each requirement and the configuration that satisfied it.