DEV Community: UNITED UAV Official

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.