DEV Community: UNITED UAV Official

UA30 Agricultural Drone: Auditing Application Rate from Flow, Speed, and Swath

UNITED UAV Official — Tue, 20 Oct 2026 14:31:40 +0000

A spraying drone can follow its route accurately while its treatment report remains wrong. The usual failure is a mismatch between three quantities: liquid leaving the aircraft, distance travelled over the ground, and the width that actually counts as treated. A dashboard that displays only tank capacity cannot resolve that mismatch.

The UA30 is a complete 30L agricultural drone listed by UNITED UAV. Here, it is a concrete example for developers building application reports and technical teams evaluating a complete aircraft package. The useful question is: what evidence would let another person reproduce the reported application rate?

Disclosure: UNITED UAV sells this aircraft. This article was drafted with AI assistance. Calculations and sample records below are synthetic engineering examples, not UA30 field measurements.

Treat the aircraft as a system

A complete spraying aircraft combines flight control, positioning, a liquid circuit, atomizers, power, mission planning and operator decisions. Their outputs interact. Changing groundspeed changes area covered per second; changing pump output changes volume delivered; changing altitude or operating conditions can change the usable deposition pattern.

For procurement, separate the supplied configuration from available options. Request an itemized aircraft, controller, battery, charger and spraying-system list. Establish whether positioning corrections, terrain sensing, spreading equipment and data-export access are included in that particular quotation. A photograph or a broad feature description does not settle those questions.

Also separate a liquid tank's volume from payload mass. Thirty liters of a formulation does not necessarily weigh thirty kilograms. Density, usable fill level, hardware and the approved mass envelope remain relevant. Software should keep volume and mass in different fields rather than silently converting between them.

This matters when comparing complete machines: a larger tank may reduce refills, but it cannot establish daily output without flight duration, charging, servicing and field geometry.

Start with the units

Let Q be total measured flow in liters per minute, v be groundspeed in meters per second, and w be the validated track spacing in meters. For a straight, steady pass, the nominal application rate is:

R [L/ha] = 10,000 × Q / (60 × v × w)

The conversion follows directly from area per second, v × w, and volume per second, Q / 60. Aerial calibration guidance also expresses this relationship using speed in kilometers per hour. The I2I aerial-equipment calibration SOP documents that form; its public-health operating recommendations should not be transferred wholesale to agricultural spraying.

For an illustrative 6 m/s pass with 6 m track spacing and 4.32 L/min total flow, the result is 20 L/ha. If speed falls to 3 m/s while flow remains unchanged, it becomes 40 L/ha. A route can therefore look geometrically correct while the nominal volume rate doubles.

These are deliberately chosen example inputs, not an asserted UA30 operating point or a pesticide recommendation. Select the actual target and operating envelope through the applicable product label, qualified agronomic advice and aircraft instructions.

Integrate intervals before calculating the mission average

Telemetry rarely arrives at a perfectly uniform rate. Integrate each interval separately: delivered volume equals flow multiplied by elapsed minutes; nominal swept area equals groundspeed multiplied by spacing and elapsed seconds. Then divide total delivered volume by total area.

Do not average individual rate values without weighting. Five seconds at 6 m/s and five seconds at 3 m/s cover different areas. With the example flow and spacing above, those intervals deliver 0.72 L across 270 square meters, giving approximately 26.67 L/ha. The simple arithmetic average of 20 and 40 is 30, which is wrong for that combined volume and area.

A small offline checker makes the arithmetic inspectable:

from math import isfinite

def nominal_rate(intervals):
    liters = area_m2 = 0.0
    for dt_s, speed_mps, spacing_m, flow_lpm in intervals:
        values = (dt_s, speed_mps, spacing_m, flow_lpm)
        if not all(isfinite(x) for x in values):
            raise ValueError("non-finite observation")
        if min(dt_s, speed_mps, spacing_m) <= 0 or flow_lpm < 0:
            raise ValueError("invalid moving-pass interval")
        liters += flow_lpm * dt_s / 60
        area_m2 += speed_mps * spacing_m * dt_s
    if area_m2 == 0:
        raise ValueError("no valid area")
    return liters * 10000 / area_m2

assert abs(nominal_rate([(5, 6, 6, 4.32)]) - 20) < 1e-9
assert abs(nominal_rate([
    (5, 6, 6, 4.32), (5, 3, 6, 4.32)
]) - 26.6666666667) < 1e-8

This function assumes interval-average measurements, straight moving passes and no overlap. It accepts neither raw asynchronous sensor messages nor stationary discharge. Production ingestion must classify those conditions before invoking it; deleting troublesome intervals would create a misleading report.

Make missing evidence visible

For every interval, retain aircraft identity, mission identity, configuration revision, timestamp basis, elapsed time, spray state, speed, total measured flow, spacing source and quality flags. Distinguish measured flow from a pump command. A requested output is not evidence that the same volume passed through the nozzles.

Align measurements to a common clock. If position arrives several hundred milliseconds after flow, a speed change can be paired with the wrong discharge interval. Document the alignment method, expected delay and maximum accepted gap. Preserve the original messages so a revised alignment can be evaluated later.

When data disappear, report unknown coverage and volume separately from accepted intervals. Do not fill a disconnected flow sensor with zero. Zero means an observed absence of flow; missing means the system cannot establish it.

Before promising integration, ask which exports the delivered UA30 configuration actually provides. Obtain sample files, units, timestamps and field definitions. This article proposes an analysis format; it does not claim that the aircraft exposes a particular public SDK, protocol or telemetry endpoint.

Separate flown area from uniquely treated area

Distance multiplied by spacing is a useful diagnostic denominator, but it counts a repeated pass again. Turns, overlap, revisits and boundary crossings can make nominal swept area larger than the unique area treated inside the field.

For a spatial report, represent each accepted pass as a footprint in an appropriate projected coordinate system, clip it to the approved field boundary, and calculate the union. Retain overlapping coverage separately rather than discarding it: repeated application can matter even when the unique-area total stays unchanged.

A geometric buffer is still only a model. The effective width needs deposition assessment for the actual setup and conditions. Positioning accuracy does not prove uniform deposition across that width. Report nominal swept-area rate, unique-area volume rate and any observed deposition results with distinct labels.

This distinction also prevents an attractive but unsupported conclusion: a low average rate across a large polygon does not prove that every part received an appropriate dose. Underapplication and repeated application can coexist.

Reconcile liquid and the complete work cycle

Compare integrated discharge with an independently measured liquid balance. Account for starting volume, refills, recovered liquid, residual contents and any documented draining or leakage. A disagreement can point to calibration error, an omitted refill, a clock problem or a different measurement boundary.

Investigate the residual rather than forcing both totals to match. Preserve uncertainty from collection vessels, scales, density measurements and flow calibration. Acceptance tolerances should follow measurement capability and operational requirements, not a convenient number chosen after the demonstration.

At an illustrative 20 L/ha, a nominal 30L tank gives 1.5 hectares by division alone. Actual dispatch planning must account for usable liquid, required reserve, non-treatment discharge and the energy needed to finish and land. That division says nothing about whether one loaded flight can cover the area.

For throughput, measure the whole cycle: preparation, takeoff, productive passes, turns, return, refill, battery handling, charging and cooling. Distinguish battery energy from ground charging capacity. Neither charger wattage nor a full tank establishes sustained hectares per hour.

Use discrepancies to choose the next measurement

When reported volume disagrees with the independent liquid balance, start with the liquid circuit and its measurement boundaries. Check priming, residual liquid, refill entries and whether the recorded quantity is measured discharge or a requested setting. Repeating the route faster will not isolate a flow-meter problem.

When volume agrees but the rate changes between otherwise similar passes, inspect speed alignment, track spacing and spray-state transitions. A lagging speed message can produce a large instantaneous spike while the total volume still looks reasonable. Keep those spikes attached to their timestamps; smoothing them into a reassuring average removes diagnostic evidence.

When both arithmetic checks agree but deposition is uneven, investigate the physical application pattern. Nozzle condition, liquid properties, aircraft motion, height and wind can matter. A consistent digital report does not establish biological effectiveness or drift control.

Sensitivity calculations help prioritize measurements. If true flow is 5% above the recorded value while actual effective width is 10% below the assumed width, the true nominal rate is about 16.7% higher than reported: 1.05 divided by 0.90. Neither discrepancy looks dramatic in isolation, yet their effects compound.

For a complete UA30 evaluation, this creates a practical division of work. The software team checks timing and arithmetic; the equipment team establishes configuration and calibration; the application specialist assesses deposition and permissible operating conditions. Define who supplies each record before the demonstration, so an unexplained result leads to a specific follow-up measurement rather than another sales comparison.

Ask for a reproducible acceptance record

A useful UA30 demonstration should leave more than a finished-area screenshot. Request the exact configuration, approved operating conditions, calibration record, raw export, refill log and a report showing rejected or unknown intervals. Run the same dataset through an independent calculation and compare the results.

Begin with controlled calibration and an appropriate nonhazardous test liquid under the aircraft supplier's procedure. Keep physical aircraft protection and operator control independent of this reporting script. The checker evaluates recorded evidence; it neither commands flight nor determines chemical application settings.

The UA30 product listing identifies the aircraft discussed here. For a technical evaluation, define the required data exports and acceptance evidence alongside the hardware configuration. A complete spraying system becomes easier to compare when its reported work can be reconstructed from measurements, boundaries and explicit assumptions.

Static Thrust Is Not Cruise Performance: Building a Fixed-Wing Propulsion Envelope from AT2814 Data

UNITED UAV Official — Mon, 28 Sep 2026 13:58:25 +0000

A static thrust table is useful evidence, but it is not a cruise-performance map. The distinction matters whenever a motor and propeller are used as the pusher on a fixed-wing UAV or during the wing-borne phase of a VTOL mission. At zero airspeed, the propeller operates at zero advance ratio. In forward flight, its inflow, blade angle of attack, thrust coefficient, torque coefficient, and efficiency all change. A spreadsheet that equates a static gram-of-thrust row with cruise thrust can therefore look precise while answering the wrong question.

This article develops a data pipeline around the randomly selected UNITED UAV T-MOTOR AT2814 KV1200 fixed-wing pusher motor. The manufacturer's AT2814 page publishes voltage, current, electrical power, RPM, torque, static thrust, thrust per watt, and terminal motor-surface temperature for several propellers. That is enough to audit electrical and mechanical boundaries and to reject bad combinations. It is not enough to predict cruise without an airspeed-dependent propeller map.

No UNITED UAV flight test, wind-tunnel test, or calibrated thrust-stand test was performed for this article. Manufacturer rows are identified as source data. The airframe and mission values below are explicit examples used to demonstrate the method, not claims about a production aircraft. Any flight release needs evidence from the exact installed motor, propeller, ESC, battery, cooling path, airframe, firmware, and operating environment.

Commercial disclosure: UNITED UAV Official publishes this article and sells the linked motor. The workflow is intended to remain useful if a different motor or supplier is selected.

The aircraft asks for thrust at airspeed, not static grams

In steady, level fixed-wing flight, thrust balances drag. NASA's drag equation expresses drag as dynamic pressure multiplied by reference area and drag coefficient. A preliminary aircraft model often expands the coefficient into a zero-lift term and a lift-dependent term:

CD = CD0 + k × CL²

With lift approximately equal to weight in level flight, the corresponding drag estimate is:

D = q × S × CD0 + k × W² / (q × S)

where q = 0.5 × rho × V², S is the declared wing reference area, W is weight, rho is air density, and V is true airspeed. The model is only as credible as its coefficients and reference conventions. CD0, span efficiency, wing area, mass, and density must carry provenance. Wind-tunnel or flight-identification data should replace illustrative assumptions as soon as they exist.

This framing immediately exposes a common category error. A multirotor hover calculation begins with weight divided by lifting rotors. A fixed-wing cruise calculation begins with aircraft drag at a flight condition. The pusher does not normally support the aircraft's weight directly; the wing does. During climb, the propulsion system must provide both the power associated with drag and the rate of increase of potential energy. During acceleration, it must additionally supply excess thrust. During VTOL transition, neither a pure hover model nor a steady fixed-wing model is sufficient.

For an illustrative 1.35 kg airframe, assume a 0.34 m² wing, CD0 = 0.035, aspect ratio 7.5, span efficiency 0.8, and sea-level density 1.225 kg/m³. These are teaching inputs, not measured properties. At 18 m/s, the simple polar produces about 2.50 N of drag. The mechanical power delivered to useful propulsive work in level flight would be at least D × V, approximately 45 W, before accounting for propeller efficiency, motor/ESC loss, installation effects, and control activity.

During a 3 m/s climb, the potential-energy rate alone is approximately W × climb_rate, or about 40 W. The shaft-power requirement is therefore not obtained by looking for 1.35 kg in a static thrust table. It comes from the drag polar, climb requirement, airspeed, propulsive efficiency, drivetrain efficiency, and margins. Each input must be tied to an operating condition.

Advance ratio is the missing coordinate

Propeller data are commonly organized by advance ratio:

J = V / (n × D)

where V is forward speed, n is revolutions per second, and D is propeller diameter. A static bench point has V = 0, so J = 0. A fixed-wing cruise point does not.

Consider the manufacturer's published full-command rows for the AT2814 KV1200. With an APC 9×6 propeller, the table reports 12,788 RPM at 14.46 V. At 18 m/s, that RPM and diameter correspond to an advance ratio of roughly 0.37. The APC 10×5.5 row reports 12,029 RPM at 14.37 V, corresponding to roughly 0.35 at the same airspeed. Those values are not small perturbations around a static point; they identify a different propeller operating condition.

Without thrust and power coefficients across advance ratio—or a validated wind-tunnel, dynamometer, or flight-derived map—the static table cannot tell us cruise thrust, cruise torque, or propulsive efficiency. Scaling static thrust by voltage, RPM squared, or throttle percentage does not restore the missing inflow physics. A responsible model should represent that state as unknown, not fill it with a convenient extrapolation.

Preserve the published boundary data

The manufacturer's current specification for the long-shaft KV1200 identifies a 108 g motor including cable, 26 mΩ internal resistance, 12N14P configuration, 5 mm input and output shaft diameters, 3–4S LiPo range, 1.8 A idle current at 10 V, 55 A peak current for 180 seconds, and 800 W maximum power for 180 seconds. These are motor-level, duration-qualified figures. They are not continuous ratings for the ESC, battery, connector, or installed aircraft.

Representative KV1200 source rows are:

Supply / propeller	Command	Voltage	Current	Input power	RPM	Torque	Static thrust	Listed surface temperature
4S / APC 9×6	75%	14.78 V	30.26 A	447.22 W	11,085	0.289 N·m	1,611 g	85 °C
4S / APC 9×6	90%	14.54 V	45.13 A	656.04 W	12,479	0.379 N·m	2,044 g	85 °C
4S / APC 9×6	100%	14.46 V	49.57 A	716.86 W	12,788	0.402 N·m	2,152 g	85 °C
4S / APC 10×5.5	75%	14.72 V	33.92 A	499.21 W	10,615	0.324 N·m	1,982 g	97 °C
4S / APC 10×5.5	80%	14.64 V	38.94 A	569.96 W	11,052	0.355 N·m	2,169 g	97 °C
4S / APC 10×5.5	100%	14.37 V	54.64 A	785.36 W	12,029	0.436 N·m	2,616 g	97 °C
3S / APC 10×5.5	100%	10.90 V	35.83 A	390.52 W	10,077	0.285 N·m	1,767 g	66 °C
3S / APC 11×5.5	100%	10.80 V	41.64 A	449.82 W	9,503	0.332 N·m	2,044 g	82 °C

The source states that the temperature is motor surface temperature after three minutes at 100% command. It does not assign that temperature independently to every partial-command row. Store it as a terminal test-condition observation for the configuration, not as a temperature measured at 75% or 90%. Sensor placement, emissivity, airflow, starting temperature, and ambient temperature are not fully specified in the displayed rows, so the values cannot be converted into a universal thermal model.

Basic arithmetic should be automated. In the 4S 10×5.5 full-command row, 14.37 V multiplied by 54.64 A is about 785.4 W, consistent with the listed 785.36 W after rounding. The row is only 0.36 A below the motor's published 55 A / 180-second current figure and only 14.64 W below the published 800 W / 180-second power figure. That is boundary evidence, not usable design margin. Battery sag, sensor error, propeller tolerance, a denser atmosphere, cooling differences, or an ESC timing change can move the installed point.

Compare configurations at a declared static condition

Static data are still valuable when used for a static requirement: launch checks, restrained ground tests, low-speed transition screening, or source-data quality control. Comparisons must be made at the same thrust and within one measured curve.

For example, the 4S 9×6 row reports 2,044 g at 90% and 656.04 W. The 4S 10×5.5 curve brackets the same static thrust between 1,982 g at 499.21 W and 2,169 g at 569.96 W. Linear interpolation within that narrow source interval gives roughly 522.7 W at 2,044 g. Under those particular static bench conditions, the larger propeller needs about 20% less listed input power at that target.

That result is useful but deliberately narrow. It does not prove lower cruise energy. It does not resolve propeller clearance, noise, vibration, control response, launch behavior, forward-flight efficiency, or the much hotter published terminal surface-temperature value for the 10×5.5 configuration. It also does not turn linear interpolation into a physical law. The interpolation should retain its two bracketing rows and refuse targets outside the measured interval.

The right conclusion is “this combination deserves the next test at the defined operating condition,” not “this propeller is 20% more efficient in flight.”

Use a data contract that keeps unlike evidence separate

Every observation should identify both its configuration and evidence class. A minimum propulsion record includes:

motor model and winding;
propeller manufacturer, diameter, pitch, material, and revision;
ESC model, firmware, timing, and switching settings;
battery chemistry, cell count, state of charge, temperature, and loaded voltage;
command, RPM, voltage, current, electrical measurement boundary, torque, and thrust;
airspeed, air density, angle of attack, and installation state;
sensor IDs, calibration dates, sample windows, and uncertainty;
source type such as manufacturer_static, local_static, wind_tunnel, or flight_identified;
raw-data URI, checksum, test procedure revision, and reviewer.

Do not merge rows simply because the column names match. A manufacturer static row and a flight-identified cruise row have different authority, conditions, and uncertainty. A value copied from a page is not a measurement made by your team. An absent airspeed must be null with a reason such as static_test, never silently encoded as zero unless the source explicitly establishes zero inflow.

A configuration fingerprint can be generated from normalized identity fields. If the motor winding, propeller revision, ESC firmware, or measurement boundary changes, the fingerprint must change. That prevents a dashboard from averaging incompatible tests into a reassuring but meaningless trend.

Audit the source rows and mission model in code

The following dependency-free Python example performs three bounded jobs. It checks electrical power consistency, derives shaft power from published torque and RPM, and interpolates static power only within a matching curve. Separately, it evaluates an illustrative drag polar and reports advance ratio. It never converts static thrust into cruise thrust.

from dataclasses import dataclass
from math import isfinite, pi, sqrt


@dataclass(frozen=True)
class StaticPoint:
    propeller: str
    diameter_in: float
    command_pct: float
    voltage_v: float
    current_a: float
    input_power_w: float
    rpm: float
    torque_nm: float
    thrust_g: float


def audit_point(point: StaticPoint) -> dict:
    numbers = (
        point.diameter_in,
        point.command_pct,
        point.voltage_v,
        point.current_a,
        point.input_power_w,
        point.rpm,
        point.torque_nm,
        point.thrust_g,
    )
    if not point.propeller or not all(isfinite(value) for value in numbers):
        raise ValueError("invalid static point")
    if min(numbers) <= 0 or point.command_pct > 100:
        raise ValueError("non-positive value or command above 100%")

    recomputed_input_w = point.voltage_v * point.current_a
    power_error = abs(recomputed_input_w - point.input_power_w)
    power_error_fraction = power_error / point.input_power_w
    if power_error_fraction > 0.015:
        raise ValueError("input power disagrees with voltage times current")

    shaft_power_w = point.torque_nm * 2 * pi * point.rpm / 60
    if shaft_power_w > point.input_power_w * 1.02:
        raise ValueError("shaft power exceeds plausible electrical input")

    diameter_m = point.diameter_in * 0.0254
    tip_speed_mps = pi * diameter_m * point.rpm / 60
    return {
        "propeller": point.propeller,
        "recomputed_input_w": recomputed_input_w,
        "shaft_power_w": shaft_power_w,
        "drive_efficiency": shaft_power_w / point.input_power_w,
        "static_tip_mach_at_340_3_mps": tip_speed_mps / 340.3,
    }


def interpolate_static_power(points: list[StaticPoint], target_thrust_g: float) -> dict:
    if not isfinite(target_thrust_g) or target_thrust_g <= 0:
        raise ValueError("target thrust must be positive and finite")
    if len(points) < 2:
        raise ValueError("at least two source points are required")
    for point in points:
        audit_point(point)

    identities = {(p.propeller, p.diameter_in) for p in points}
    if len(identities) != 1:
        raise ValueError("mixed propeller curves cannot be interpolated")

    ordered = sorted(points, key=lambda p: p.thrust_g)
    bracket = next(
        ((a, b) for a, b in zip(ordered, ordered[1:])
         if a.thrust_g <= target_thrust_g <= b.thrust_g),
        None,
    )
    if bracket is None:
        raise ValueError("target would require extrapolation")

    low, high = bracket
    fraction = (
        (target_thrust_g - low.thrust_g)
        / (high.thrust_g - low.thrust_g)
    )

    def lerp(a: float, b: float) -> float:
        return a + fraction * (b - a)

    return {
        "propeller": low.propeller,
        "target_static_thrust_g": target_thrust_g,
        "input_power_w": lerp(low.input_power_w, high.input_power_w),
        "current_a": lerp(low.current_a, high.current_a),
        "command_pct": lerp(low.command_pct, high.command_pct),
        "bracket_g": [low.thrust_g, high.thrust_g],
        "evidence": "interpolated_manufacturer_static",
    }


def drag_polar(mass_kg: float, airspeed_mps: float, rho: float,
               wing_area_m2: float, cd0: float,
               aspect_ratio: float, span_efficiency: float) -> dict:
    values = (mass_kg, airspeed_mps, rho, wing_area_m2,
              cd0, aspect_ratio, span_efficiency)
    if not all(isfinite(value) and value > 0 for value in values):
        raise ValueError("drag-polar inputs must be positive and finite")
    if span_efficiency > 1:
        raise ValueError("span efficiency must not exceed 1")

    weight_n = mass_kg * 9.80665
    dynamic_pressure_pa = 0.5 * rho * airspeed_mps ** 2
    k = 1 / (pi * aspect_ratio * span_efficiency)
    parasite_drag_n = dynamic_pressure_pa * wing_area_m2 * cd0
    induced_drag_n = (
        k * weight_n ** 2 / (dynamic_pressure_pa * wing_area_m2)
    )
    drag_n = parasite_drag_n + induced_drag_n
    return {
        "drag_n": drag_n,
        "parasite_drag_n": parasite_drag_n,
        "induced_drag_n": induced_drag_n,
        "useful_level_flight_power_w": drag_n * airspeed_mps,
        "evidence": "illustrative_airframe_model",
    }


def advance_ratio(airspeed_mps: float, rpm: float, diameter_in: float) -> float:
    if min(airspeed_mps, rpm, diameter_in) < 0 or rpm == 0 or diameter_in == 0:
        raise ValueError("invalid advance-ratio inputs")
    revolutions_per_second = rpm / 60
    diameter_m = diameter_in * 0.0254
    return airspeed_mps / (revolutions_per_second * diameter_m)


prop_10x55 = [
    StaticPoint("APC 10x5.5", 10, 75, 14.72, 33.92,
                499.21, 10615, 0.324, 1982),
    StaticPoint("APC 10x5.5", 10, 80, 14.64, 38.94,
                569.96, 11052, 0.355, 2169),
    StaticPoint("APC 10x5.5", 10, 100, 14.37, 54.64,
                785.36, 12029, 0.436, 2616),
]

print(audit_point(prop_10x55[-1]))
print(interpolate_static_power(prop_10x55, target_thrust_g=2044))
print(drag_polar(
    mass_kg=1.35,
    airspeed_mps=18,
    rho=1.225,
    wing_area_m2=0.34,
    cd0=0.035,
    aspect_ratio=7.5,
    span_efficiency=0.8,
))
print({
    "advance_ratio_at_18_mps": advance_ratio(18, 12029, 10),
    "static_table_advance_ratio": 0.0,
})

The program should report approximately 549 W of shaft power and 70% electrical-to-shaft efficiency for the full-command 4S 10×5.5 row, subject to the published torque and electrical measurement boundaries. It should interpolate approximately 523 W and 35.6 A at 2,044 g static thrust. The illustrative airframe model should return about 2.50 N drag and 45 W of useful level-flight power at 18 m/s. The reported advance ratio should be about 0.35, while every static table row remains at zero.

Those outputs are intentionally not merged into a cruise-current prediction. Doing so would require a propeller map as a function of advance ratio, Reynolds number, and possibly blade angle and installation condition. The code preserves the gap instead of laundering an assumption into a result.

Convert the model into explicit gates

A useful screening service returns more than a ranked list. It returns failed constraints and missing evidence. For this class of propulsion decision, sensible gates include:

Identity gate. Exact motor winding, propeller, ESC hardware and firmware, supply, and source revision are known.
Arithmetic gate. Voltage-current power, torque-RPM shaft power, units, monotonicity, and duplicate rows pass validation.
Static-envelope gate. Takeoff or low-speed static requirements fall inside measured brackets; no extrapolation is used.
Electrical gate. Continuous and transient current, power, connector, cable, distribution, and battery limits have duration-aware margin.
Dynamic-propeller gate. Required cruise and climb advance ratios are covered by trusted propeller coefficients or a representative test.
Thermal gate. The installed system completes the intended duty cycle at the hot operating condition without exceeding approved limits or retaining an unacceptable positive temperature slope.
Mechanical gate. Shaft, fasteners, propeller retention, balance, clearance, mount stiffness, and vibration meet the airframe acceptance criteria.
Control gate. Command headroom, transition behavior, RPM response, governor or ESC behavior, and fault handling are verified with the flight-control configuration.

If the dynamic-propeller map is missing, the correct state is requires_dynamic_test. The system may still be suitable, but the evidence does not yet support a cruise claim. This distinction is important for automated selection tools: “no qualifying candidate” and “insufficient data” are different outcomes and should lead to different engineering work.

Design the dynamic test around the missing coordinate

The next test should add controlled airspeed, not repeat more static points. A wind-tunnel or propeller dynamometer setup should measure thrust and torque across the intended combinations of RPM and inflow speed. Convert observations to nondimensional thrust and power coefficients, record advance ratio, and preserve air density, temperature, pressure, propeller geometry, and uncertainty.

For an installed pusher, test installation effects. The fuselage, wing, tail, motor mount, cooling inlet, and propeller clearance can change inflow and efficiency. A tractor-propeller map is not automatically transferable to a pusher location. A VTOL transition adds changing angle of attack, possible lift-rotor wake interaction, and rapidly changing demand. The test matrix should cover the actual operating corridor rather than a single nominal cruise point.

Synchronize electrical, mechanical, and aerodynamic measurements. Voltage and current averaged over one window cannot be paired with thrust and torque from another during a ramp. Record raw timestamps and the exact aggregation method. Repeat points in randomized order or revisit baselines to expose heating, battery depletion, and sensor drift.

Propeller testing is hazardous. Use a suitably engineered enclosure, guarded and restrained hardware, an exclusion zone, remote observation, and an independent emergency power disconnect. Analysis code must remain outside the flight-critical or emergency-control path.

Treat limits as time-dependent

The manufacturer's 55 A and 800 W values are labeled for 180 seconds. A mission model must therefore integrate duration as well as amplitude. Store each segment with its start condition, expected current and power distribution, duration, and recovery interval. A three-second launch burst, a sixty-second climb, and twenty minutes of cruise are not interchangeable merely because their peak current is similar.

Thermal state carries between segments. The motor entering a go-around after a long climb is not at the same initial temperature as a cold bench unit. ESC and battery temperature also alter loss and protection behavior. A useful model propagates temperature or, before such a model is validated, requires representative sequence testing.

Do not infer a continuous limit from the fact that one source row is below a 180-second maximum. The 4S 10×5.5 full-command row nearly consumes the published transient current and power limits and carries a listed 97 °C terminal surface temperature under the source procedure. It is a boundary point for validation, not a cruise target.

Close the loop with flight telemetry

After ground and dynamic qualification, flight data should be traceable to the same configuration fingerprint. Record true or calibrated airspeed where available, RPM, motor command, pack and ESC voltage, current, motor and ESC temperature, altitude, ambient estimates, battery state, aircraft mass configuration, and flight mode. Preserve controller saturation and transition-state flags; otherwise high current caused by a control problem can be mistaken for normal propulsion demand.

Compare measured power against the mission model by segment and by advance-ratio region. A persistent residual may indicate an inaccurate drag polar, propeller-map error, airspeed bias, installation loss, mass mismatch, or drivetrain degradation. Do not immediately tune a correction factor to erase it. Diagnose which boundary or assumption is wrong and retain the pre-correction evidence.

Operational monitoring should compare like configurations and conditions. Useful signals include increasing current at matched airspeed and mass, declining RPM at matched voltage and command, growing vibration, reduced climb excess power, rising temperature slope, and repeated ESC protection events. Missing telemetry must be flagged as missing; zero is a real value.

What the AT2814 data can and cannot decide

The published AT2814 KV1200 table can support source-data validation, static combination screening, motor/ESC/battery boundary checks, approximate shaft-power reconciliation, tip-speed checks, and definition of the next test. It reveals that the 4S 10×5.5 full-command point is very close to the motor's published 180-second current and power figures. It also shows a substantial static input-power difference between 9×6 and 10×5.5 combinations near 2,044 g of thrust.

It cannot establish cruise thrust, cruise efficiency, range, endurance, climb rate, hot-day continuous capability, pusher-installation loss, transition behavior, or aircraft suitability by itself. Those outputs require airframe aerodynamics, advance-ratio-dependent propeller data, installed electrical and thermal evidence, and flight validation.

That boundary is the core engineering result. Professional propulsion software should make valid deductions easy, invalid extrapolations impossible, and missing evidence visible. A static table becomes useful not when it is treated as a complete answer, but when it is integrated into a mission-specific evidence chain with explicit refusal rules.

From Mission Requirements to a UAV Motor Operating Point: An MN4010 Sizing Workflow

UNITED UAV Official — Sun, 20 Sep 2026 15:18:24 +0000

A motor is not selected when its maximum-thrust number exceeds the aircraft weight. It is selected only after the motor, propeller, voltage, ESC, battery, airframe, and control reserve have been evaluated at the operating points the mission will actually use.

This article builds that evaluation around the randomly selected UNITED UAV T-MOTOR MN4010 KV370 Navigator motor. The useful part of this example is not the product name. It is the unusually complete set of manufacturer-published MN4010 test rows: several propellers, both 14.8 V and 22.2 V supplies, and current, power, thrust, RPM, and temperature at multiple command points. That is enough data to show how a mission requirement can become a traceable propulsion decision instead of a spreadsheet guess.

No UNITED UAV flight test or calibrated thrust-stand test was performed for this article. All MN4010 measurements cited below are published manufacturer reference data. The aircraft and mission are an explicit engineering example, not a claim about a production vehicle. Before flight, reproduce the relevant points on the installed propulsion system and use limits approved for that aircraft.

Commercial disclosure: UNITED UAV Official publishes this article and sells the linked motor. The workflow is vendor-neutral and is designed to expose, rather than hide, the assumptions behind a selection.

Begin with a load-case contract

Suppose a team is designing a six-rotor mapping aircraft with a maximum takeoff mass of 4.5 kg. Its nominal static hover allocation is:

4500 g / 6 = 750 g per rotor

That value is not yet a motor requirement. The installed aircraft may have unequal arm loading, non-ideal inflow near the fuselage, propeller-to-propeller variation, battery voltage sag, and lower air density than the bench environment. For a first screening calculation, the team assigns a 13% installed-condition factor:

750 g × 1.13 = 847.5 g per rotor

We will round the screening hover target to 850 g. The factor is an example input, not a universal safety constant. A real project should derive it from mass-properties analysis, expected density altitude, installation measurements, manufacturing tolerance, and the applicable safety process.

The same contract requires at least 1.6 times the corrected hover target at the published high-command point:

850 g × 1.6 = 1360 g per rotor

This second constraint matters. A combination can be extremely efficient at hover and still leave too little authority for climb, gust rejection, load redistribution, or control saturation. Conversely, a combination with impressive maximum thrust can waste energy during the long hover segment. A defensible choice has to pass both the normal operating point and the reserve condition.

Write the contract as data before inspecting candidates. At minimum, include aircraft mass, lifting-rotor count, corrected hover target, required thrust ratio, maximum propeller diameter, allowed supply-voltage range, mission duration, ambient envelope, maximum permitted current at each electrical boundary, and the policy for interpolation. If a value is unknown, mark it unknown. Quietly replacing an unknown with an optimistic default is how a screening spreadsheet becomes an unsafe specification.

Preserve the source rows, not just a marketing maximum

The manufacturer's current page identifies the KV370 version as a 4–8S motor with a listed 137 g mass including its cable, 98 mΩ internal resistance, 0.8 A idle current at 10 V, and 450 W / 20 A figures labeled for 180 seconds. Its test table includes these representative KV370 observations:

Supply	Propeller	Command	Current	Power	Thrust	RPM	Listed temperature
14.8 V	14×4.8 CF	85%	5.4 A	79.92 W	810 g	4,400	44 °C
14.8 V	14×4.8 CF	100%	6.5 A	96.20 W	920 g	4,700	44 °C
14.8 V	15×5 CF	75%	5.1 A	75.48 W	820 g	3,800	44 °C
14.8 V	15×5 CF	100%	8.2 A	121.36 W	1,160 g	4,450	44 °C
14.8 V	16×5.4 CF	65%	4.3 A	63.64 W	770 g	3,300	45 °C
14.8 V	16×5.4 CF	75%	6.1 A	90.28 W	970 g	3,650	45 °C
14.8 V	16×5.4 CF	100%	9.6 A	142.08 W	1,380 g	4,300	45 °C
22.2 V	12×4 CF	75%	5.0 A	111.00 W	860 g	6,200	40 °C
22.2 V	13×4.4 CF	65%	4.3 A	95.46 W	810 g	5,300	47 °C
22.2 V	14×4.8 CF	50%	3.5 A	77.70 W	780 g	4,400	51 °C
22.2 V	14×4.8 CF	65%	5.7 A	126.54 W	1,060 g	5,100	51 °C
22.2 V	14×4.8 CF	100%	11.7 A	259.74 W	1,830 g	6,600	51 °C

The page notes that the temperature field is motor surface temperature after a ten-minute run at 100% command. That note is part of the data. It does not establish winding temperature, hot-day continuous capability, or the temperature of a motor partly shielded by an airframe. Likewise, the 180-second current and power labels are duration-limited component figures, not permission to operate the whole installed system at those values.

Keep the original source URL, retrieval date, model and winding, voltage, propeller identity, and every published column. Do not copy only thrust and current into a design sheet. RPM can reveal a transcription error. Voltage is required to reconcile power. Test notes define what the temperature means. Provenance lets a later reviewer distinguish manufacturer literature from local acceptance evidence.

Do not treat KV as a complete propulsion model

KV is approximately the no-load speed constant expressed in RPM per volt. Multiplying 370 KV by 22.2 V may be useful as a rough no-load sanity check, but it does not predict loaded RPM, thrust, torque, current, or efficiency. The loaded operating point emerges from the motor, ESC timing, supply impedance, propeller torque curve, and airflow together.

The table demonstrates this directly. At 22.2 V with the 14×4.8 propeller, the published 100% point is 6,600 RPM, well below the simplistic no-load product. The difference is not a defect; it is evidence that the propeller is loading the motor. A design process that estimates thrust from KV and voltage alone has discarded the dominant aerodynamic interaction.

Command percentage is also not a portable physical unit. It is a point on one ESC/controller mapping under one test setup. The required quantity is thrust. When comparing propellers, interpolate against thrust inside each measured curve. Never assume that 70% on one propeller is equivalent to 70% on another, and never extrapolate outside the measured range merely because a polynomial can produce a number.

Interpolate with explicit refusal rules

For the 850 g screening target, the 14.8 V 16×5.4 curve brackets the requirement between 770 g and 970 g. Linear interpolation places the target 40% of the way through that interval. That produces approximately 5.02 A and 74.30 W. The same calculation for the 22.2 V 14×4.8 curve, bracketed by 780 g and 1,060 g, produces approximately 4.05 A and 89.91 W.

Linear interpolation is not a claim that the underlying motor-propeller physics are linear. It is a local screening method between adjacent measurements. Its result should retain the two bracket rows and an interpolated flag. If the target is outside the source curve, if voltage differs, if the propeller identity changes, or if the bracket is too wide for the project's accuracy requirement, the program must refuse the calculation.

The 14.8 V 15×5 curve also brackets 850 g and would use about 79.48 W by the same method. However, its published maximum of 1,160 g fails the 1,360 g reserve requirement. The 14.8 V 14×4.8 curve fails that reserve even more clearly. Ranking only by interpolated hover power without enforcing reserve would therefore return a result that violates the aircraft contract.

The 14.8 V 16×5.4 combination reaches a published 1,380 g, only 20 g above the illustrative reserve threshold. It technically passes the simple screen but leaves about 1.5% margin between the required and published values. That is too narrow to absorb the uncertainties we explicitly said existed. A production rule might require the source maximum to exceed the reserve target by an additional measured uncertainty allowance. Under such a rule, this candidate would be rejected or moved to a mandatory local test rather than silently accepted.

The 22.2 V 14×4.8 combination reaches a published 1,830 g and therefore offers more screening headroom, but it consumes about 21% more electrical power at the interpolated 850 g point than the 14.8 V 16×5.4 combination. This is the engineering trade: hover energy, command headroom, propeller clearance, acoustic behavior, current, voltage, control response, and thermal state are coupled. There is no single “best motor efficiency” number that resolves all of them.

Make the screening algorithm auditable

The following dependency-free Python program implements the narrow decision described above. It validates the source rows, groups only identical motor/voltage/propeller configurations, brackets a target without extrapolation, interpolates current and power, and then applies a separate maximum-thrust reserve constraint. It deliberately does not invent density corrections or thermal limits.

from dataclasses import dataclass
from math import isfinite


@dataclass(frozen=True)
class Point:
    voltage_v: float
    propeller: str
    command_pct: float
    current_a: float
    power_w: float
    thrust_g: float
    rpm: float


def validate(point: Point) -> None:
    values = (
        point.voltage_v,
        point.command_pct,
        point.current_a,
        point.power_w,
        point.thrust_g,
        point.rpm,
    )
    if not point.propeller or not all(isfinite(value) for value in values):
        raise ValueError("invalid source point")
    if min(point.voltage_v, point.current_a, point.power_w,
           point.thrust_g, point.rpm) <= 0:
        raise ValueError("measurements must be positive")
    if not 0 < point.command_pct <= 100:
        raise ValueError("command must be in (0, 100]")
    relative_power_error = abs(
        point.power_w - point.voltage_v * point.current_a
    ) / point.power_w
    if relative_power_error > 0.015:
        raise ValueError("published power is inconsistent with V × A")


def interpolate_at_thrust(points: list[Point], target_g: float) -> dict:
    if not isfinite(target_g) or target_g <= 0:
        raise ValueError("target thrust must be positive and finite")
    if len(points) < 2:
        raise ValueError("at least two source points are required")

    for point in points:
        validate(point)

    voltages = {point.voltage_v for point in points}
    propellers = {point.propeller for point in points}
    if len(voltages) != 1 or len(propellers) != 1:
        raise ValueError("mixed configurations cannot be interpolated")

    ordered = sorted(points, key=lambda point: point.thrust_g)
    if any(a.thrust_g >= b.thrust_g for a, b in zip(ordered, ordered[1:])):
        raise ValueError("thrust points must be unique and increasing")

    bracket = next(
        (
            (low, high)
            for low, high in zip(ordered, ordered[1:])
            if low.thrust_g <= target_g <= high.thrust_g
        ),
        None,
    )
    if bracket is None:
        raise ValueError("target would require extrapolation")

    low, high = bracket
    fraction = (target_g - low.thrust_g) / (high.thrust_g - low.thrust_g)

    def lerp(a: float, b: float) -> float:
        return a + fraction * (b - a)

    return {
        "voltage_v": low.voltage_v,
        "propeller": low.propeller,
        "target_thrust_g": target_g,
        "current_a": lerp(low.current_a, high.current_a),
        "power_w": lerp(low.power_w, high.power_w),
        "command_pct": lerp(low.command_pct, high.command_pct),
        "bracket_thrust_g": [low.thrust_g, high.thrust_g],
        "published_max_thrust_g": ordered[-1].thrust_g,
        "interpolated": True,
    }


def screen(points: list[Point], hover_target_g: float,
           minimum_thrust_ratio: float) -> dict:
    result = interpolate_at_thrust(points, hover_target_g)
    reserve_target_g = hover_target_g * minimum_thrust_ratio
    result["reserve_target_g"] = reserve_target_g
    result["passes_published_reserve"] = (
        result["published_max_thrust_g"] >= reserve_target_g
    )
    result["reserve_margin_g"] = (
        result["published_max_thrust_g"] - reserve_target_g
    )
    return result


mn4010_4s_16x54 = [
    Point(14.8, "T-MOTOR 16x5.4 CF", 65, 4.3, 63.64, 770, 3300),
    Point(14.8, "T-MOTOR 16x5.4 CF", 75, 6.1, 90.28, 970, 3650),
    Point(14.8, "T-MOTOR 16x5.4 CF", 100, 9.6, 142.08, 1380, 4300),
]

mn4010_6s_14x48 = [
    Point(22.2, "T-MOTOR 14x4.8 CF", 50, 3.5, 77.70, 780, 4400),
    Point(22.2, "T-MOTOR 14x4.8 CF", 65, 5.7, 126.54, 1060, 5100),
    Point(22.2, "T-MOTOR 14x4.8 CF", 100, 11.7, 259.74, 1830, 6600),
]

for curve in (mn4010_4s_16x54, mn4010_6s_14x48):
    print(screen(curve, hover_target_g=850, minimum_thrust_ratio=1.6))

The output should show roughly 5.02 A, 74.30 W, and 20 g of published reserve margin for the 4S 16×5.4 curve; and roughly 4.05 A, 89.91 W, and 470 g for the 6S 14×4.8 curve. The lower current on 6S does not mean lower battery stress by itself: pack construction, capacity, C-rate, wiring, connector loss, state of charge, and total six-motor current all matter. Power and heat must be evaluated at the correct boundary.

The function also performs a 1.5% consistency check between the published power and voltage × current. Such checks catch unit and transcription mistakes, but small differences can result from rounded display values or measurements averaged over different windows. Store the source value and the recomputed value; do not overwrite the source to make the table look cleaner.

For production use, add a schema version, source identifier, retrieval timestamp, test report number, unit metadata, uncertainty fields, calibration state, and immutable raw-data hash. Keep rejected rows with their rejection reasons. A system that silently drops malformed observations can produce a polished but unauditable ranking.

Integrate power over the mission, not over one row

Hover is often the longest segment, but it is not the whole mission. Create a timeline of takeoff, climb, transit, mapping, loiter, descent, and reserve. Each segment should specify duration and per-rotor thrust distribution, not merely a throttle percentage. Interpolate power only within a validated curve and sum energy across the timeline:

mission energy = Σ(power at segment operating point × segment duration)

For six rotors at the illustrative 850 g point, the interpolated motor/ESC input implied by the manufacturer rows is about 446 W for the 4S 16×5.4 option or 539 W for the 6S 14×4.8 option. Those numbers exclude avionics, payload, conversion losses outside the measurement boundary, and any extra control activity. They are not battery-size recommendations.

Battery sizing must use the worst credible loaded voltage rather than the nominal label alone. Repeat the operating-point analysis at the voltage the ESC will actually see near the minimum allowed state of charge. If no source curve exists at that voltage, test it. Scaling thrust by the square of voltage or scaling current linearly may be tempting, but those approximations can be wrong once ESC duty, motor loading, propeller RPM, and battery resistance interact.

Log current at the pack and, during development, at selected ESC inputs. The sum of ESC currents need not exactly equal pack current if timestamps, filters, and measurement boundaries differ. Synchronize clocks and document averaging windows before using the data to estimate wiring loss or diagnose an outlier motor.

Size the ESC and wiring from waveforms and duration

An ESC should not be chosen by matching one published current number. Confirm supported cell count, continuous and transient current at the installed cooling condition, commutation compatibility, firmware settings, command protocol, telemetry behavior, and protection response. Consider the current step during rapid attitude correction, not just steady hover average. A slow current logger can miss short peaks that heat semiconductors or trigger protection.

Connector, cable, distribution-board, and solder-joint resistance turn current into localized heat. Measure voltage at both the pack and ESC during a restrained installed test. A few tenths of a volt lost in distribution can alter available control margin while the battery monitor still reports an acceptable pack voltage. Use appropriately rated protection and an independent emergency disconnect on the test stand.

Do not run an automated script as a flight-safety controller. The code above is offline analysis. Propeller testing requires a mechanically secure stand, guarding, an exclusion zone, remote observation, and a qualified operator. Emergency shutdown must not depend on a browser, wireless link, cloud service, or the analysis process.

Treat temperature as a time series

A single temperature cell cannot prove thermal suitability. Record ambient temperature, pressure, motor surface or winding sensor location, ESC sensor location, airflow configuration, command, current, RPM, and time. Plot temperature rise and its slope. If the slope is still positive at the end of the required segment, the system has not demonstrated a stable continuous condition.

The manufacturer's listed test temperatures were produced under its stated procedure. An installed arm, fairing, payload, or coaxial arrangement can change cooling and recirculation. Copper resistance rises with temperature, battery sag changes with state and temperature, and hot electronics may derate. Validate the hottest expected operating environment and the actual duty cycle. Do not subtract a cool bench ambient from a listed surface temperature and then add that difference to a hot-day forecast as if the system were linear.

Air density affects the operating point as well. Density altitude is not solved by adding an arbitrary fixed thrust percentage to every mission. Use atmospheric inputs appropriate to the site, then verify the predicted correction against an installed test. If the aircraft must operate across a wide altitude range, store separate validated envelopes or use a model whose error bounds are supported by test data.

Connect the calculation to telemetry and review

The design record and flight log should share stable identifiers for motor model, winding, propeller part and revision, ESC hardware and firmware, battery type, airframe revision, and analysis version. Without those joins, an analyst can observe elevated current but cannot determine which physical configuration produced it.

At minimum, log battery voltage and current, per-motor command, RPM or ESC telemetry where available, attitude-controller saturation, vehicle mass configuration, ambient conditions, and relevant temperatures. Use monotonic timestamps on the vehicle and preserve clock-correlation metadata for external payloads. Flag sensor dropouts explicitly; zero is a measurement, not a substitute for missing data.

Define operational signals before flight. Examples include hover power drifting upward relative to comparable flights, persistent RPM divergence at similar commands, reduced command headroom, rising vibration, connector temperature growth, or one ESC reporting repeated protection events. Compare like with like: similar mass, propeller, battery state, wind, altitude, and mission segment. A fleet dashboard that ignores configuration identity can turn normal differences into false alarms and real degradation into averages.

Review the result as an envelope, not a winner. A candidate can be rejected, requires_test, or qualified_for_defined_conditions. The last state must name those conditions. “Qualified” without voltage, propeller, mass, ambient range, firmware, and duration is not a reusable engineering decision.

Build evidence in stages

Start with document reconciliation: current drawing, winding, propeller, voltage, ESC manual, connector and mounting requirements. Then perform receiving inspection and a no-propeller electrical check. Move to a guarded thrust stand with calibrated thrust, voltage, current, RPM, vibration, and temperature sensing. Reproduce the intended hover and reserve points, including the worst expected loaded voltage and duration.

Next test the installed but restrained propulsion system. Installation can reveal arm resonance, airflow obstruction, wiring loss, telemetry interference, or controller behavior absent from an isolated stand. Only then conduct a conservative first flight with explicit abort conditions and a limited envelope. Review the complete log before expanding mass, duration, wind, temperature, or altitude.

Acceptance criteria should have been written before the test. They may include maximum stabilized current at a specified thrust, minimum command reserve, temperature limits at declared sensor locations, vibration thresholds, allowable sensor disagreement, and post-test mechanical inspection. If the evidence fails a criterion, preserve the failure and its configuration. Do not simply rerun until a passing trace appears.

The MN4010 data illustrates the central lesson: component selection is a constrained, provenance-aware software problem as much as it is a hardware problem. At the same 850 g screening target, a larger 4S propeller can use less published electrical power, while a smaller 6S propeller provides substantially more published thrust headroom. The right choice depends on the aircraft's mission, geometry, uncertainty, power system, thermal envelope, and control requirements. A professional workflow makes every one of those dependencies visible—and refuses to manufacture certainty when the required evidence does not exist.

Stop Comparing UAV Motors at Equal Throttle: A Reproducible MN505-S Bench Workflow

UNITED UAV Official — Sun, 13 Sep 2026 11:58:16 +0000

A motor table is often read as a shopping chart: find the largest thrust number, check that the ESC amperage looks close, and move on. For an aircraft that must fly repeatedly, that is not a propulsion design. The useful question is whether a particular motor, propeller, ESC, battery, mount, and cooling path can deliver the required thrust at the actual operating point, for the required duration, with measurable margin.

The randomly selected product for this example is the UNITED UAV T-MOTOR MN505-S KV320 Navigator motor. It provides an unusually useful case study because T-MOTOR publishes separate bench curves for the KV320 winding with P20×6 and P22×6.6 propellers. Those curves let us demonstrate a mistake that survives many otherwise careful reviews: comparing combinations at equal throttle percentage rather than equal thrust.

This is a software-and-test-engineering article, not a recommendation that a motor is suitable for any particular aircraft. No flight test, calibrated bench test, or independent endurance measurement was performed for this post. Published numbers are reference data to audit and reproduce. The Python example is an analysis tool for recorded observations; it does not command a motor or an aircraft.

Commercial disclosure: UNITED UAV Official publishes this article and sells the linked motor. The analysis method is intended to be useful even if you choose a different supplier.

Define the decision before opening a motor spreadsheet

Start with an aircraft-level requirement rather than a component-level target. For a multirotor, record the maximum takeoff mass, number of lifting rotors, permitted center-of-gravity range, intended hover duration, climb requirement, ambient-temperature envelope, operating altitude, and minimum reserve after a credible degradation. A VTOL needs separate lift, transition, and cruise conditions because the same average mission power can hide a short but severe vertical-load phase.

A first-pass hover estimate is aircraft weight divided by the number of lifting rotors. It is not the design thrust per rotor. It omits maneuvering, gust rejection, thrust imbalance, degraded battery voltage, manufacturing variation, and whatever reserve the airframe safety analysis requires. It also assumes every rotor shares load equally. That may not hold when the center of gravity moves with payload or battery placement. Calculate the required operating points from the complete aircraft, then ask which propulsion combination can meet them.

Write the acceptance criteria before testing. Examples include a maximum measured current at a specified thrust, a maximum stabilized motor and ESC temperature at a specified ambient condition, a minimum control reserve at the worst expected battery voltage, and a vibration threshold under the installed propeller. The numerical limits must come from the airframe design and verified component documentation; borrowing a generic percentage from another aircraft is not engineering evidence.

The output should be a decision record with the exact motor winding, propeller part number and revision, ESC model and firmware, battery or power-supply configuration, mount, calibration identifiers, environmental conditions, raw data hashes, analysis version, and reviewer. Without configuration identity, a beautiful thrust plot is difficult to reproduce and almost impossible to use safely for a later replacement.

Read the published numbers with their conditions attached

The current UNITED UAV listing identifies the MN505-S KV320 item separately from other windings. The manufacturer's specification and test table list 6S LiPo as the rated voltage, 55 A peak current for 180 seconds, 1,300 W maximum power for 180 seconds, approximately 225 g motor mass including cable, and suggested 20–22 inch propellers. The same page identifies IP45 for the motor. These are not whole-aircraft ratings. They do not tell you that a chosen ESC, connector, battery, flight controller, or airframe can tolerate rain, dust, heat, or a 180-second peak.

The published table gives these KV320 points:

Propeller	Throttle label	Voltage	Current	Thrust	Input power	Listed efficiency
P20×6	70%	24.03 V	16.30 A	2,921 g	393 W	7.44 g/W
P22×6.6	60%	23.99 V	15.20 A	2,968 g	364 W	8.15 g/W
P20×6	100%	23.96 V	38.50 A	5,372 g	921 W	5.83 g/W
P22×6.6	100%	23.87 V	52.40 A	6,680 g	1,249 W	5.35 g/W

The first two rows are near the same thrust, even though their throttle labels differ by ten points. In those specific published conditions, P22×6.6 produces about 47 g more thrust while drawing about 29 W less electrical power. That is a useful clue for a roughly 3 kg-per-rotor design point, not proof that P22×6.6 is always superior. It may have different mechanical clearance, inertia, control response, vibration, or high-temperature behavior. The last two rows instead show why “more maximum thrust” carries a cost: the larger propeller's published full-throttle point is 52.4 A and 1,249 W, close to the motor's listed 55 A and 1,300 W 180-second figures. Treat those maxima as boundary data, not a continuous operating prescription.

The manufacturer notes an ambient temperature of 9.5 °C for the bench curves and describes motor-surface temperature after a ten-minute full-throttle run. Its page also labels peak current and maximum power as 180-second values. Do not resolve that duration mismatch by assuming a ten-minute high-power rating. Ask the manufacturer which conditions, sensors, and duty limits apply to the exact combination, then validate the intended duty cycle locally. A cool laboratory is not a hot installed nacelle.

A quick arithmetic check is worthwhile. At the P20×6 70% row, 24.03 V × 16.30 A is about 392 W, consistent with the listed 393 W after rounding. Thrust divided by listed power is about 7.43 g/W, consistent with 7.44 g/W. These checks cannot certify the test, but they catch transcription or unit errors before the data enters a selection model.

Compare at equal thrust, not equal command

Throttle percentage is a command coordinate, not an aerodynamic requirement. Two ESCs can map the same percentage to different electrical timing and speed; two propellers impose different torque on the same motor. Even within one manufacturer's table, equal percentages do not imply equal thrust, current, efficiency, or thermal load.

For candidate comparison, choose a target thrust derived from the aircraft load case. Interpolate within a measured curve only between nearby points of the same motor, propeller, voltage class, and test setup. Do not extrapolate beyond its measured range. Report the bracket points and interpolation method with the result. If battery voltage differs materially between curves, normalize with an appropriate validated model or repeat the test at matched voltage rather than silently treating them as equal.

Near 3 kg, the two rows above are close enough to illustrate the principle without pretending to be a high-precision interpolation. At 70% command, P20×6 reports 2,921 g and 393 W. At 60% command, P22×6.6 reports 2,968 g and 364 W. A chart organized by throttle would put those observations in different columns and could obscure the comparison. A chart with thrust on the x-axis and electrical input power on the y-axis makes the design decision visible.

At other load points, the answer can change. Propeller aerodynamic efficiency, motor copper loss, ESC behavior, and cooling all vary with torque and speed. A single g/W value is not a universal property of the motor. The candidate should be evaluated over the mission's thrust distribution: minutes at hover, seconds during climb, time in transition, and the battery voltage at each phase. One row at full throttle should never be used to predict an entire flight.

Instrument the bench so the data can be trusted

A useful bench has a restrained, guarded motor mount; a calibrated thrust sensor; voltage and current measurement at a declared point in the electrical path; RPM measurement; motor and ESC temperature sensors; ambient temperature; and a record of propeller identity. If torque is measured, log the torque-sensor calibration and sign convention. If it is not measured, do not infer mechanical efficiency from electrical input and thrust alone.

Specify sensor placement. Battery-terminal voltage is not necessarily ESC-input voltage after cables, connectors, and distribution hardware. An ESC's reported current may be filtered or estimated differently from a calibrated shunt. An infrared image of a shiny rotor can be misleading because emissivity and viewing angle are uncontrolled. For temperature trends, use repeatable sensor locations and document whether the value is winding, stator case, rotor surface, ESC case, or ambient air.

Define a common timebase. Record raw sensor timestamps, sample rates, clock offsets, and the aggregation window used for each test point. A row that joins thrust at second 12 with current at second 18 can create a false efficiency result during a throttle ramp. A stable-point result should be computed from a window in which command, RPM, thrust, and current have settled. Keep the raw series so an analyst can see oscillation or heating that a single average hides.

Calibrate and zero the load cell before each session. Record the thrust-stand orientation, fixture geometry, propeller plane, and nearby surfaces. Recirculation, wall proximity, ground effect, and test-stand blockage can move results. Compare candidate propellers on the same fixture under a controlled procedure. Randomize test order or repeat a baseline combination at the end; otherwise ambient warming, battery depletion, or sensor drift may look like a propeller effect.

Propeller testing is hazardous. Use a suitable enclosure and exclusion zone, secure the stand, keep people out of the propeller plane, provide an independent emergency power disconnect, and have a qualified operator supervise the test. A browser dashboard or Python script should only observe the stand. Flight-critical protection and physical emergency controls must not depend on a cloud service.

Persist a minimal data contract

A row should be self-describing enough to survive export from the original logging system. A compact JSON record can carry the exact configuration, measurements, and quality flags:

{
  "schema_version": 1,
  "run_id": "mn505s-kv320-p22x66-20260913-b",
  "point_id": "hover-03",
  "motor": "MN505-S KV320",
  "propeller": "T-MOTOR P22x6.6",
  "esc": "record-exact-model-and-firmware",
  "supply": "6S test supply",
  "window_start_utc": "2026-09-13T03:10:00Z",
  "window_duration_s": 20,
  "voltage_v": 23.99,
  "current_a": 15.20,
  "thrust_g": 2968,
  "rpm": 3790,
  "motor_surface_c": null,
  "esc_case_c": null,
  "ambient_c": 9.5,
  "quality_flags": ["illustrative_from_manufacturer_table"]
}

The sample values reproduce one published manufacturer row; the run ID and timestamp are illustrative, not a claim that UNITED UAV performed this test. Null temperatures mean “not available in this row,” not zero degrees. A production record should include sensor IDs, calibration dates, fixture revision, raw-data URI and checksum, operator, and the exact source document revision. Use a separate field for a vendor-published row versus a measurement made by your team. Otherwise downstream code may accidentally merge literature data and acceptance-test evidence.

Keep current and voltage at the same electrical boundary. If a regulator, distribution board, or cable lies between their measurement points, their product does not represent the motor/ESC input power you think it does. Record whether the power measurement includes ESC loss. “Efficiency” in g/W is a useful thrust-per-electrical-input metric, but it is not motor shaft efficiency and should not be labeled as such.

Validate observations before ranking candidates

The following dependency-free Python function checks the minimum numerical invariants in a list of bench records and selects a point near a target thrust. It intentionally refuses to compare records outside a declared thrust tolerance. It does not extrapolate, interpolate, or claim a production safety decision.

from math import isfinite

def rank_near_target(rows, target_g, tolerance_g=100):
    if not isfinite(target_g) or target_g <= 0:
        raise ValueError("target_g must be positive and finite")
    if not isfinite(tolerance_g) or tolerance_g <= 0:
        raise ValueError("tolerance_g must be positive and finite")

    accepted = []
    rejected = []

    for row in rows:
        identity = (row.get("run_id"), row.get("point_id"))
        try:
            if row.get("schema_version") != 1:
                raise ValueError("unsupported schema")
            if not row.get("motor") or not row.get("propeller"):
                raise ValueError("missing configuration identity")

            v = float(row["voltage_v"])
            a = float(row["current_a"])
            thrust = float(row["thrust_g"])
            if not all(map(isfinite, (v, a, thrust))):
                raise ValueError("non-finite measurement")
            if min(v, a, thrust) <= 0:
                raise ValueError("non-positive measurement")

            power_w = v * a
            efficiency_g_per_w = thrust / power_w
            if abs(thrust - target_g) > tolerance_g:
                raise ValueError("outside target thrust window")

            accepted.append({
                "identity": identity,
                "propeller": row["propeller"],
                "thrust_g": thrust,
                "power_w": power_w,
                "g_per_w": efficiency_g_per_w,
                "distance_g": abs(thrust - target_g),
            })
        except (KeyError, TypeError, ValueError) as error:
            rejected.append({"identity": identity, "reason": str(error)})

    accepted.sort(key=lambda item: (item["power_w"], item["distance_g"]))
    return {"ranked": accepted, "rejected": rejected}

For the two published near-3 kg observations, the function reports roughly 392 W for P20×6 and 365 W for P22×6.6 when calculated from the rounded voltage and current fields. That slight difference from the table's 393 W and 364 W is a rounding reminder, not a reason to “correct” the manufacturer's data. Retain both the published value and the recomputed value with provenance if exact reconciliation matters.

This small function is not enough for an acceptance pipeline. Production code should validate units, schema revisions, unique identities, calibration validity, timestamps, sensor saturation, and the distinction between measured and source-derived records. It should keep rejected rows in an auditable quarantine set rather than silently dropping them. Property-based tests can generate zero, negative, infinite, NaN, duplicate, and out-of-range inputs to prove that ranking never accepts them.

Model uncertainty instead of hiding it

Any thrust/power comparison needs an uncertainty budget. The load cell contributes calibration and repeatability error. Current and voltage sensors contribute gain, offset, and timing error. The battery or power supply can sag. The stand can alter flow. Ambient density changes with temperature, pressure, and humidity. Propeller manufacturing tolerances and balance change both thrust and vibration. The total is not necessarily the simple sum of each individual sensor tolerance, but it should be documented.

Report at least the number of repeats, mean, spread, and test conditions for each target point. If the apparent power advantage is smaller than the combined uncertainty or varies by test order, label the result inconclusive. If the candidate is selected on a 29 W difference near 3 kg of thrust, repeat the measurements with a calibrated system before using that difference in an endurance promise.

Thermal uncertainty is especially easy to underestimate. The manufacturer's surface-temperature figures are tied to its bench and a cool listed ambient. A motor installed close to an arm, fairing, spray system, or tether hardware may have a different cooling path. Winding temperature can differ from a case or rotor measurement. Build a controlled duration test at the expected thrust, then review the temperature slope and stabilization behavior. If temperature is still rising near the end of the planned duty interval, a single final value does not establish continuous suitability.

Do not extrapolate “temperature rise above ambient” linearly from one laboratory point to a hot field site. Air density, propeller loading, convective cooling, ESC loss, and motor resistance can all change. A hot-condition test or validated thermal model is needed for a high-consequence mission.

Integrate the whole power path

A 55 A motor peak-current figure does not authorize a 55 A aircraft design. Confirm the ESC's voltage and continuous/transient current capability for the exact firmware and cooling condition. Confirm connector and cable ampacity, distribution-board heating, battery discharge limits, fuse or protection strategy where applicable, and voltage sag at the worst expected state of charge. Log at both battery and ESC boundaries if cable loss matters.

Mechanical integration is equally specific. The manufacturer's page lists an approximately 55.6 × 38.9 mm motor envelope, 225 g mass including cable, and a warning to keep mounting-thread engagement within its stated limit. Obtain the current drawing, verify bolt pattern and screw depth, and inspect for any contact with windings or rotating parts. Validate propeller retention, clearance, rotation direction, and arm stiffness. A well-matched electrical system can still fail because the mount resonates or a screw damages the motor.

The motor's IP45 claim does not transfer to the ESC, connectors, bearings after wear, or the complete aircraft. Environmental qualification should consider the installed system and its maintenance state. Record water or dust exposure, cleaning method, corrosion findings, bearing play, cable damage, vibration trend, and current drift over service life. A numerical MTBF claim, where listed, is not a substitute for a fleet-specific inspection program.

Turn the bench result into a flight-readiness gate

A sensible sequence is receiving inspection; document and connector review; no-propeller rotation check; guarded stand test; installed restrained ground test; conservative first flight; and log review before expanding the envelope. Each transition should have written entry conditions and stop criteria. The first flight should not be asked to discover a propeller mismatch that a guarded bench could have found.

For an installed multirotor, compare equivalent arms at a controlled operating condition. Look for differences in current at similar thrust command, RPM where available, ESC temperature, motor temperature, and vibration. An outlier may indicate a damaged propeller, bearing issue, cable resistance, ESC configuration difference, or structural resonance. Do not assume that swapping only the motor isolates the cause; change one variable at a time and preserve the configuration history.

After flight, compare the measured thrust-demand distribution with the load cases used in selection. If the aircraft spends more time at high command than expected, or one arm consistently works harder, revisit the mass, center of gravity, propeller, and control assumptions. A propulsion design is validated by the operating envelope it actually sees, not merely by a catalog point it once matched.

The engineering takeaway is narrow but important: use the MN505-S KV320 manufacturer's table as a starting dataset, not a certificate of aircraft suitability. Compare propellers at equal required thrust, carry measurement provenance and uncertainty through analysis, validate the thermal and electrical path at the intended duty cycle, and require independent acceptance evidence before flight. That workflow is portable to other UAV motors—and more valuable than any isolated “maximum thrust” number.

Designing a Dual-Sensor Data Contract for a Thermal VTOL Pipeline

UNITED UAV Official — Fri, 28 Aug 2026 11:30:37 +0000

A dual-sensor UAV can produce visible video, thermal frames, aircraft position, attitude, gimbal angles, target detections, and operator events at different rates. The difficult part is not collecting every stream. It is proving which observations belong together without inventing precision that the source system never provided.

This article develops a data contract for that problem. It uses the UNITED UAV UVH2 dual-sensor fixed-wing VTOL drone as a concrete product context. The current listing describes a K8T-V2 payload with an 8 MP visible channel, 4K visible recording, a native 640 × 512 thermal detector, processed 1280 × 1024 thermal super-resolution, and Ethernet, serial, and SBUS interfaces. It also identifies the communication protocol as proprietary.

That last detail defines the software boundary: obtain the supported interface-control document and use an approved adapter. The schemas and code below describe a downstream observation pipeline. They are not the UVH2 command protocol, do not reverse-engineer it, and must not be placed in a flight-critical control path.

Commercial disclosure: UNITED UAV Official publishes this technical article and links to a product sold through the UNITED UAV store.

Why a filename pair is not a data contract

A common first implementation writes visible_001.jpg and thermal_001.jpg, then assumes the matching number proves that the files were captured together. That assumption breaks when one encoder drops a frame, a camera restarts, a buffer flushes late, or a transmission path reorders messages.

The pipeline needs to preserve three different facts:

what each source reported;
how the integration correlated the sources;
how confident the integration is in that correlation.

Those facts should remain visible to every downstream consumer. An inspection model may accept a 200 ms pairing tolerance. A moving-target workflow may require a much tighter limit. A reviewer should never have to infer that tolerance from filenames or application code.

Define an immutable capture bundle

Treat every correlated observation as an immutable bundle. Large media files stay in object storage; the event carries their checksums, dimensions, formats, timestamps, and references.

{
  "schema_version": 1,
  "capture_id": "01J6FGP8B0V5TGQ1M9A2X4K7CZ",
  "vehicle_id": "uvh2-field-07",
  "mission_id": "roof-baseline-2026-08-28-r3",
  "observed_at": "2026-08-28T06:18:42.481Z",
  "source_clock_ns": 5842284190031,
  "clock_epoch": "payload-boot-0194",
  "visible": {
    "object_uri": "s3://uav-raw/2026/08/28/visible/01J6F.jpg",
    "sha256": "...",
    "width": 3840,
    "height": 2160,
    "encoding": "jpeg",
    "source_sequence": 18422
  },
  "thermal": {
    "object_uri": "s3://uav-raw/2026/08/28/thermal/01J6F.bin",
    "sha256": "...",
    "width": 640,
    "height": 512,
    "representation": "native_detector",
    "source_sequence": 9211
  },
  "correlation": {
    "method": "source_clock_nearest",
    "delta_ms": 18.4,
    "max_allowed_delta_ms": 50,
    "quality": "accepted"
  },
  "pose": {
    "position_source": "aircraft_telemetry",
    "attitude_source": "aircraft_telemetry",
    "gimbal_source": "payload_telemetry",
    "sample_delta_ms": 11.2
  },
  "adapter": {
    "version": "2.3.1",
    "interface_document_revision": "vendor-approved-revision"
  }
}

The example deliberately avoids claiming that every payload exposes the same fields. The adapter should record null plus a reason when the supported interface does not provide a value. Fabricated defaults are more dangerous than missing data.

Use two clocks, not one

Wall-clock time answers when an observation occurred in a shared timeline. A monotonic source clock answers how events were ordered inside one boot session. Both are necessary.

observed_at should use UTC with an explicit offset. source_clock_ns should never move backward during one clock_epoch. A payload restart creates a new epoch even if its sequence counter returns to zero. The ingestion service can then distinguish a reboot from delayed delivery.

Store clock-quality metadata separately:

synchronization source, such as GNSS, PTP, NTP, or platform-provided time;
last successful synchronization time;
estimated offset and uncertainty;
detection of an unexpected time step;
adapter receive time and storage time.

A precise-looking timestamp is not proof of accurate synchronization. If uncertainty is unknown, say so and lower the correlation quality.

Keep native and derived thermal imagery distinct

The UVH2 listing separates the native 640 × 512 detector from 1280 × 1024 thermal super-resolution output. A data model should preserve that distinction. Upscaled or enhanced output is useful, but it is not a higher-resolution detector measurement.

Use an explicit representation field:

native_detector
processed_super_resolution
colorized_preview
visible_thermal_overlay

Derived assets should reference their parents and record the processing version, parameters, and checksum. Never overwrite the native input with an enhanced image. If a later model produces a different result, both versions should remain reproducible.

Thermal observation also does not automatically mean calibrated temperature measurement. If radiometric values are required, the contract needs documented units, calibration state, emissivity handling, reflected-temperature assumptions, measurement range, accuracy, and invalid-pixel behavior. When the source interface does not provide those fields, the pipeline should label the asset as qualitative thermal imagery.

Make partial pairs first-class events

A dual-sensor pipeline must tolerate one channel arriving late or not arriving at all. Use an explicit lifecycle:

received_visible_only
received_thermal_only
paired_pending_validation
paired_accepted
paired_rejected
expired_unpaired

Do not keep an event in memory forever while waiting for its partner. Persist the first observation, start a bounded correlation window, and finalize it as expired_unpaired when the deadline passes. A late partner can create a new reconciliation record without rewriting history.

The difference matters operationally. A missing visible frame may still leave a useful thermal observation. A missing thermal frame may still preserve visual context. Downstream systems can decide whether a partial bundle is usable, but they should not be told that a complete pair exists.

Validate at ingestion

Validation should reject malformed events before analytics or indexing. A dependency-free Python example can enforce some basic invariants:

from datetime import datetime, timezone


ALLOWED_THERMAL_REPRESENTATIONS = {
    "native_detector",
    "processed_super_resolution",
    "colorized_preview",
    "visible_thermal_overlay",
}


def parse_utc(value: str) -> datetime:
    parsed = datetime.fromisoformat(value.replace("Z", "+00:00"))
    if parsed.tzinfo is None:
        raise ValueError("observed_at requires a timezone")
    return parsed.astimezone(timezone.utc)


def validate_bundle(bundle: dict) -> None:
    if bundle.get("schema_version") != 1:
        raise ValueError("unsupported schema_version")

    for field in ("capture_id", "vehicle_id", "mission_id", "clock_epoch"):
        if not isinstance(bundle.get(field), str) or not bundle[field].strip():
            raise ValueError(f"missing {field}")

    parse_utc(bundle["observed_at"])

    correlation = bundle["correlation"]
    delta = float(correlation["delta_ms"])
    limit = float(correlation["max_allowed_delta_ms"])
    if delta < 0 or limit <= 0:
        raise ValueError("invalid correlation timing")
    if correlation["quality"] == "accepted" and delta > limit:
        raise ValueError("accepted pair exceeds timing limit")

    thermal = bundle.get("thermal")
    if thermal and thermal["representation"] not in ALLOWED_THERMAL_REPRESENTATIONS:
        raise ValueError("unknown thermal representation")

    for channel in ("visible", "thermal"):
        asset = bundle.get(channel)
        if not asset:
            continue
        if asset["width"] <= 0 or asset["height"] <= 0:
            raise ValueError(f"invalid {channel} dimensions")
        if len(asset["sha256"]) != 64:
            raise ValueError(f"invalid {channel} checksum")

Production validation should use a versioned schema format and bounded payload sizes. Keep rejected metadata in a quarantine stream with reason codes; do not silently discard it or mix it with accepted observations. Media decoders need their own resource limits because image dimensions in metadata cannot be trusted until the bytes are inspected.

Make idempotency content-aware

Networks retry. Edge computers reboot. Upload workers receive the same message twice. A stable event identity prevents those normal behaviors from multiplying observations.

Use capture_id as the business identity and verify that any repeat has the same immutable digest. The outcomes should be:

same ID, same digest: harmless retry;
same ID, different digest: conflict requiring investigation;
new ID, same source sequences and clock epoch: probable duplicate from an upstream identity defect;
new ID, same media checksums: duplicate asset or repeated capture requiring a documented decision.

Write the event and its asset references atomically, or keep an explicit state such as metadata_committed_assets_pending. A database row that points to missing media is not a complete ingestion result.

Separate observation from inference

Target recognition, tracking, anomaly scoring, mapping, and thermography interpretation are downstream results. Store them as derived records that point back to the immutable capture bundle. Each result should include:

model or algorithm name and version;
model-file checksum;
input capture ID and asset representation;
thresholds and preprocessing version;
output coordinate system;
confidence and known limitations;
reviewer state when a human decision is required.

Do not write a detection back into the source event as if the camera observed a semantic truth. The camera produced pixels and metadata; an algorithm produced an interpretation. That separation makes reprocessing, disagreement analysis, and incident review possible.

Protect operational and personal data

Visible and thermal UAV data may reveal people, vehicles, infrastructure, precise locations, schedules, and operational patterns. Minimize collection to the approved mission, encrypt data in transit and at rest, use short-lived scoped credentials, and log access to original media.

Keep raw media separate from public application paths. Derived previews should remove unnecessary metadata and use redaction when the workflow requires it. Retention policy should apply to raw files, thumbnails, detections, exports, backups, and cached edge copies—not only to the primary database.

The adapter that reads the supported payload interface should have no broader command permission than it needs. Observation ingestion must not become an undocumented route to aircraft or gimbal control.

Test the failure modes

Before relying on the pipeline, replay at least these scenarios:

visible frames arrive before, after, and without thermal frames;
sequence counters restart after a payload reboot;
wall time jumps while the monotonic clock continues;
a processed thermal asset is incorrectly labelled as native;
the same capture ID arrives with a different checksum;
object storage succeeds but metadata commit fails, and vice versa;
the adapter version changes during a mission;
media is truncated, oversized, or declares false dimensions;
telemetry and gimbal samples are older than the configured limit;
a late event arrives after the correlation window expires.

For each test, define the expected event state and evidence before running it. A pipeline that merely avoids crashing is not necessarily correct. It should expose why a bundle was accepted, rejected, left partial, or quarantined.

A practical readiness checklist

Before production use, confirm that:

the delivered payload and approved interface document match the adapter version;
every boot session has a distinct clock epoch;
wall-clock accuracy and monotonic ordering are recorded separately;
pairing tolerance is explicit and mission-appropriate;
native and processed thermal representations cannot be confused;
partial and late observations have bounded, auditable states;
media bytes are verified independently of metadata;
retries are idempotent and digest conflicts stop processing;
inference outputs never overwrite source observations;
retention, redaction, encryption, and access logging cover edge and cloud copies.

A strong dual-sensor pipeline does not hide uncertainty. It turns timing, derivation, missing data, and interface revision into fields that can be tested. That makes the resulting data more useful to developers and more defensible to operators and reviewers.

Review the current UVH2 product page for the published platform and payload starting point. For a real integration, request the current K8T-V2 interface-control document, supported command and telemetry definitions, connector details, licensing terms, sample files, and a configuration-specific acceptance procedure.

Designing a Fail-Closed API Integration for an Autonomous Drone Dock

UNITED UAV Official — Fri, 28 Aug 2026 11:23:30 +0000

Autonomous drone docks sit at an awkward boundary: they look like IoT devices, but a command can eventually affect a real aircraft. That makes a conventional "send request and retry on failure" integration unsafe. The software must distinguish observation from authorization, reject stale or ambiguous commands, and fail closed whenever state cannot be proven.

This article presents a reference architecture for that integration problem. It uses the UNITED UAV UK03 drone docking station as a concrete product context because its current listing includes API availability, RTK, internal and external cameras, weather sensing, optional edge computing, optional mesh networking, and optional SIM-based 4G. The listing does not publish an endpoint schema, so every endpoint and payload below is deliberately illustrative. A production implementation must use the current vendor documentation and the approved aircraft-management workflow.

Commercial disclosure: UNITED UAV Official publishes this technical article and links to a product sold through the UNITED UAV store.

Start by separating four kinds of state

Many integrations become dangerous because they compress several questions into one boolean such as ready: true. A safer model records at least four independent states:

Observed state — what the dock, aircraft, weather sensors, and network last reported.
Validated state — whether those observations are recent, internally consistent, and within the operating envelope.
Authorized intent — which mission was approved, by whom, for which aircraft, site, route, and time window.
Executed state — what the vendor platform accepted and what later telemetry proves actually happened.

A positive observation is not authorization. An accepted API response is not proof of aircraft motion. A dashboard that has stopped updating is not evidence that conditions remain unchanged. Keeping these states separate makes the system easier to audit and prevents a stale green status from becoming a launch decision.

Put an adapter in front of the vendor API

Do not let schedulers, dashboards, or business applications call the dock API directly. Put a narrow adapter between them:

Planner -> Intent Store -> Safety Gate -> Dock Adapter -> Vendor Platform
              |               |              |
              v               v              v
          Audit Log      State Snapshot   Readback Worker

The adapter should expose only the small set of operations the organization has approved. It can normalize vendor-specific status codes, enforce request IDs, apply timeouts, and redact secrets from logs. If the vendor API changes, only the adapter should need to understand the new schema.

This boundary is also where command and telemetry permissions can be separated. A monitoring service may need read-only access to weather, dock health, charging state, and alarms. It should not automatically inherit permission to open the dock, schedule a route, or dispatch an aircraft.

Make every command an expiring intent

A mission request should be an immutable record, not a transient button click. For example:

{
  "intent_id": "01J6E7Y9M2K8Q4R5T6V7W8X9ZA",
  "site_id": "solar-north-01",
  "aircraft_id": "uis220-07",
  "mission_revision": 4,
  "approved_by": "ops-review-queue",
  "not_before": "2026-08-28T02:00:00Z",
  "expires_at": "2026-08-28T02:10:00Z",
  "required_state_revision": 1842
}

The intent_id becomes the idempotency key. mission_revision prevents an older route from being dispatched after an edit. expires_at prevents a delayed queue message from starting a mission outside its approval window. required_state_revision binds the decision to a particular validated snapshot instead of whatever state happens to exist later.

If the vendor API supports an idempotency header, pass the intent ID through. If it does not, the adapter must keep its own durable command ledger and query vendor state before deciding whether a retry is safe. Never generate a new intent ID merely to make an uncertain request succeed.

Validate freshness before values

A weather value can be numerically safe and operationally useless if it is old. Every safety-relevant observation should carry three timestamps:

when the sensor measured it;
when the platform received it;
when the integration read it.

The safety gate should reject missing timestamps, future timestamps beyond an allowed clock-skew window, and observations older than the system's documented freshness limit. Apply the same rule to dock-door state, aircraft-in-place detection, charging state, RTK status, network health, and camera availability.

A compact TypeScript-style check might look like this:

type GateResult =
  | { ok: true; snapshotRevision: number }
  | { ok: false; reasons: string[] };

function validateSnapshot(s: Snapshot, nowMs: number): GateResult {
  const reasons: string[] = [];

  if (nowMs - s.observedAtMs > 15_000) reasons.push("snapshot_stale");
  if (!s.aircraftInPlace) reasons.push("aircraft_not_confirmed");
  if (s.activeAlarmCount > 0) reasons.push("active_alarm");
  if (!s.weather.dataQualityOk) reasons.push("weather_quality_unknown");
  if (!s.network.commandPathHealthy) reasons.push("command_path_unhealthy");
  if (s.maintenanceLock) reasons.push("maintenance_lock");

  return reasons.length
    ? { ok: false, reasons }
    : { ok: true, snapshotRevision: s.revision };
}

The example intentionally does not hard-code wind, temperature, rainfall, or battery thresholds. Those limits must come from the most restrictive verified value across the aircraft, payload, dock configuration, route, regulation, and operator procedure.

Use a command state machine

A boolean sent field cannot represent an external command safely. Use explicit states:

prepared
  -> rejected_prewrite
  -> dispatch_requested
  -> accepted_unverified
  -> verified
  -> outcome_uncertain

rejected_prewrite means no external write occurred. It is safe to prepare a new intent after correcting the reason. accepted_unverified means the vendor acknowledged the request, but independent state has not yet proved the result. outcome_uncertain means a timeout or connection loss happened after transmission may have begun. That state must trigger readback, not a blind retry.

Persist the transition before and after the external call. The log should contain the intent ID, payload digest, vendor request correlation ID when available, response status, timestamps, adapter version, state revision, and redacted error class. It should never contain API keys, session tokens, or complete signed URLs.

Read back the effect independently

After a command is accepted, query the authoritative state surface. For a scheduled mission, verify the mission identifier, route revision, aircraft, dock, planned time, and enabled status. For a door or charging operation, verify the resulting hardware state and its observation timestamp.

Use a different read path when the platform provides one. For example, a command endpoint may acknowledge queueing while a mission-status endpoint reports execution. Telemetry can then confirm physical progress. These layers answer different questions and should not be treated as duplicates.

A successful readback should be narrow and deterministic:

const accepted = await adapter.dispatch(intent);
await ledger.markAccepted(intent.intent_id, accepted.correlationId);

const finalState = await adapter.readMission(accepted.missionId);
assert(finalState.intentId === intent.intent_id);
assert(finalState.revision === intent.mission_revision);
assert(finalState.aircraftId === intent.aircraft_id);

await ledger.markVerified(intent.intent_id, finalState);

If any assertion fails, preserve both records and escalate. Do not overwrite the mismatch with the newest response.

Keep humans at the right boundary

Human approval should apply to a complete, reviewable mission intent. The reviewer should see the route revision, aircraft and payload, launch window, forecast and live weather, site status, airspace or operating approval, expected communications path, and defined abort behavior.

The integration may automate collection, validation, expiry, and readback. It should not silently broaden an approval when a route, aircraft, payload, time window, safety limit, or site changes. Those changes create a new revision and may require a new approval.

This distinction also helps during incidents. Operators can determine whether a bad outcome came from incorrect source data, a validation defect, an authorization error, an adapter failure, vendor-platform behavior, or a physical-system fault.

Design network loss as a normal state

The UK03 listing describes optional 4G and mesh capabilities, but multiple bearers do not make a network infallible. Define behavior for at least these cases:

the adapter cannot reach the vendor platform before dispatch;
the request times out after bytes may have been transmitted;
telemetry continues but the command channel is unavailable;
the dock is reachable but the aircraft link is degraded;
the WAN fails during a mission;
buffered events arrive out of order after reconnection.

For each case, document which component owns the safe response. Flight-critical failsafes belong in the validated aircraft and approved control system, not in a remote web service. The external integration should observe and report those states without pretending it can replace them.

Test faults before unattended operation

A staging environment is useful, but it is not enough. The production configuration should go through controlled acceptance tests with the real dock, supported aircraft, network path, and management platform. Include:

duplicate command delivery with the same intent ID;
an expired intent arriving late;
a route revision changing after approval;
stale weather and dock-status observations;
API timeout before and after request transmission;
loss and recovery of WAN, RTK corrections, and telemetry;
an aircraft not correctly detected in the dock;
an active maintenance lock or unresolved alarm;
a readback that disagrees with the accepted command;
adapter restart during every state-machine transition.

Record the expected safe state and pass criterion before each test. A fault-injection exercise is successful when the system prevents or contains the unsafe action and preserves evidence, not merely when it emits an error message.

A practical production checklist

Before enabling an autonomous dock integration, confirm that:

vendor API documentation matches the delivered hardware, licenses, and software version;
read-only and command credentials are separated and can be rotated;
every intent is immutable, versioned, expiring, and idempotent;
observations include freshness and data-quality checks;
command outcomes have explicit uncertain and verified states;
retries require readback after any ambiguous transmission;
logs are durable, redacted, time-synchronized, and reviewable;
human approval covers the exact mission revision and operating window;
aircraft and dock failsafes work without the external automation;
controlled fault tests have been completed and defects closed.

The central design principle is simple: an automation system should only advance when it can prove that the required state, authorization, and prior outcome all match. Anything less becomes a stop condition. That approach may produce more visible refusals during development, but it also makes the integration understandable, testable, and safer to operate.

Review the current UK03 product listing for the published configuration starting point, then request the applicable API documentation, supported-aircraft matrix, licensing details, and acceptance procedure for the actual deployment.