Concept illustration
Design Guides
Component selection frameworks, system architecture patterns, and integration best practices for UAV engineering teams building mission-critical aircraft.
Why Design Guides
Making Informed Component Decisions
Selecting the right components for a UAV system is a multi-dimensional engineering challenge. Every decision, from the flight controller microcontroller to the gauge of power distribution wiring, cascades through weight, endurance, reliability, and total system cost. These guides distill our engineering team's experience across a broad range of aircraft configurations into actionable decision frameworks.
Whether you are designing an agricultural spraying multi-rotor, a long-endurance fixed-wing survey platform, or a research aircraft with custom sensor payloads, these guides provide the technical depth needed to evaluate tradeoffs and converge on a well-matched component set.
Guide Library
Six Core Engineering Domains
Each guide addresses a critical subsystem. Read them in sequence for a full-system perspective, or jump directly to the domain most relevant to your current design phase.
1. Flight Controller Selection
Processor architecture, sensor fusion, firmware ecosystem compatibility, and redundancy topologies. Covers MCU performance tiers, IMU selection criteria (vibration rejection, update rate, redundancy), barometer and GNSS integration, and the tradeoffs between open-source (ArduPilot, PX4) and proprietary flight stacks for different mission profiles.
Key considerations: loop rate vs. computational load, triple-redundant IMU architectures, RTK GNSS precision tiers, and hardware-in-the-loop testing compatibility.
2. ESC & Motor Matching
Voltage, current, and protocol alignment across the propulsion chain. Covers ESC firmware options (BLHeli_32, AM32, proprietary FOC), communication protocols (DShot, CAN, PWM), and motor sizing methodology, KV selection, stator dimensions, and thermal derating under sustained load.
Key considerations: thermal headroom at max continuous current, active freewheeling efficiency gains, CAN vs. DShot for large aircraft, and motor-ESC connector standardization.
3. Power System Architecture
Battery chemistry selection, power distribution bus design, BMS integration, and wiring gauge calculations. Covers LiPo vs. Li-Ion vs. semi-solid-state tradeoffs for different endurance and discharge-rate requirements, PDB architecture (centralized vs. distributed), and voltage sag compensation strategies.
Key considerations: cell internal resistance at target current draw, connector current ratings with safety margin, parallel battery configurations, and BMS communication bus selection.
4. Communication Stack Design
Radio frequency selection, telemetry architecture, data link redundancy, and antenna placement. Covers frequency band tradeoffs (433 MHz, 868/915 MHz, 2.4 GHz) for range vs. bandwidth, dual-link redundancy patterns, and antenna diversity strategies for composite airframes.
Key considerations: link budget calculations, antenna polarization matching, RF-transparent airframe materials, and spectrum regulatory compliance by region.
5. Airframe Integration
Materials selection, component mounting geometries, vibration isolation techniques, and center-of-gravity optimization. Covers carbon fiber vs. aluminum vs. composite frame tradeoffs, vibration damping materials and mounting patterns, and CG calculation methodology for asymmetric payload configurations.
Key considerations: frame resonance frequencies vs. motor RPM bands, fastener torque specifications for carbon fiber, and modular vs. monolithic frame design for field repair.
6. Payload Interface Design
Mechanical mounting standards, electrical power and signal interfaces, and data protocol integration. Covers quick-release mechanism selection, gimbal communication protocols (PWM, SBUS, CAN, serial), and payload power budgeting within the total aircraft power envelope.
Key considerations: hot-swap payload connector specifications, data bandwidth for real-time payload telemetry, and EMI isolation between payload and aircraft electronics.
File Format Requirements
When engaging our engineering team for component selection support or custom integration work, providing design files in standardized formats accelerates the review and quotation process.
Concept illustration
Mechanical CAD
- STEP (.stp / .step), Preferred for 3D models; universal compatibility across CAD platforms
- DXF (.dxf), For 2D profiles, mounting patterns, and frame plate layouts
- PDF (.pdf), Dimensioned drawings with tolerances for quick review
Configuration & Data
- JSON (.json), Preferred for component BOM, configuration parameters, and telemetry schema definitions
- XML (.xml), For parameter files and flight controller configuration exports
- CSV (.csv), Acceptable for motor thrust tables and test data
From Design File to Quotation
What happens after you send us a design file
A design file is not the same thing as an engineering brief. The format tells us how to open the file; it does not tell us what you are trying to build, what it has to survive, or which constraints are fixed. The table below is the acceptance standard our applications engineers apply to every submission, and the sequence a file moves through before a quotation number is issued. Submissions that meet all four columns typically receive a preliminary BOM within three business days. Submissions that miss a column start with a clarification round instead.
| Input | What it must contain | What we return | Effect on the quote cycle |
|---|---|---|---|
| Mechanical CAD (STEP / DXF / PDF) | Mounting interface datums, hole patterns with tolerances, and the load path through the frame. A STEP without datum callouts is a shape, not an interface. | Fit-check note against the proposed component envelopes and a flagged list of interfaces that need a dimension confirmed. | Complete → no delay. Missing datums → one clarification round (adds 1–2 business days). |
| Configuration / parameter file (JSON / XML) | Firmware target, protocol assignments and the parameter names as your stack names them. Our files use our own naming; a translation table is not something we can guess. | Parameter mapping back to the selected component set, with any names that have no equivalent called out explicitly. | Complete → same-cycle mapping. Unmapped names → the affected subsystem is quoted after the mapping is agreed. |
| Electrical intent (BOM or netlist, CSV acceptable) | Rails and their nominal voltages, target continuous current per rail, and connector family in use. "24 V system" alone under-specifies the whole power bus. | A rail-by-rail adequacy check against the ESC, BEC and harness current ratings, plus the derating margin we would apply. | Complete → quoted as a configured stack. Rail currents absent → the power subsystem is quoted as a range, not a number. |
| Mission envelope (prose is fine) | Payload mass and dimensions, endurance or range target, operating environment (temperature band, dust, salt, altitude) and whether the platform must be re-certified after your change. | A short suitability note: which of the six guide domains your envelope stresses hardest, and the two component families that will govern cost. | Complete → targeted quotation. Absent → we quote a general stack and mark the cost drivers as provisional. |
What we do not require: a finished design. The majority of briefs we receive arrive as a concept plus a payload and an endurance target. The four inputs above are the minimum that lets an engineer commit to a number instead of a range.
Where Submissions Stall
Seven defects that cost a quotation cycle
These are the recurring causes of a brief sitting in a clarification loop rather than moving to a BOM line. Each one is cheap to fix at the point of submission and expensive to discover after a design freeze. They are listed in the order our engineers encounter them, not in order of severity.
- Unitless dimensions. A DXF with no units declared is read as millimetres by default. If the plate was drawn in inches, every mating hole pattern is wrong by a factor of 25.4 and the fit check fails on the first assembly.
- Headline ratings with no duty cycle. An ESC quoted at a peak current, with no continuous figure and no duration, cannot be sized. Propulsion reserves are calculated on sustained hover load, so a peak-only number forces us back to the datasheet anyway.
- Connector families left implied. When the CAD shows a connector body but the BOM names a different series, the harness becomes a two-week negotiation. Naming the family at submission removes the ambiguity before it reaches the harness station.
- Firmware version omitted. Parameter files are version-specific. A mapping produced against one release can silently misbehave on another, so a version string is treated as a required field, not a courtesy.
- Environmental envelope stated as "outdoor". Outdoor covers a coastal inspection platform and a high-plateau survey aircraft, which are different sealing, coating and thermal problems. A temperature band and a contamination class replace the word entirely.
- Payload mass given without mounting geometry. A 2.5 kg payload on a hard-mounted plate and the same payload on an isolated gimbal have different centre-of-gravity and vibration implications. Mass alone does not let us size the interface.
- Revision not marked. Two files with the same name and different content is the single most common source of a build that no longer matches the drawing. Every file carries a revision identifier, and the identifier is referenced in the RFQ.
Review Turnaround
How long a design review takes, and what it costs
An applications-engineering review is a scoped piece of work, not an open-ended favour. The bands below reflect the review effort against the submission quality, quoted in absolute terms so you can plan around it. Review effort is credited against the order when the reviewed configuration is subsequently quoted and placed.
| Submission state | Engineering effort | Turnaround | Charge treatment |
|---|---|---|---|
| Complete brief, four inputs present | 4–8 engineer-hours: fit check, rail check, mapping, suitability note | 2–3 business days | No charge. Effort is absorbed into the quotation. |
| Complete brief, novel platform or first-time envelope | 10–20 engineer-hours, including two feasibility passes and a component survey | 4–6 business days | First pass free. A second design iteration on the same brief is quoted at our standard hourly rate. |
| Partial brief, one clarification round expected | 6–12 engineer-hours, front-loaded with a written clarification | 3–5 business days after clarification returns | No charge, provided the clarification round is the only one. Repeated rounds are quoted per iteration. |
| Concept only, no mechanical or electrical input | 20–40 engineer-hours: architecture proposal from first principles | 1–2 weeks | Charged as a scoped architecture study, credited in full against a subsequent build order above a defined value. |
The distinction that matters: we do not charge for reading a document, we charge for producing an architecture. A brief that arrives complete gets its architecture for free inside the quotation. A concept that arrives without any mechanical or electrical input requires us to propose one, and that proposal is the deliverable.
Review Deliverable
What a design review actually produces
"We looked at your files" is not a deliverable. A completed review produces a document you can hand to your own team and act on. It contains, in this order:
- Interface register. Every mechanical and electrical interface in the submission, with its datum or rail reference, and a pass / clarify / conflict status against the proposed component set.
- Component recommendation table. The selected families per domain, each with the governing specification (the one number that decided the selection) and a named alternative that trades cost against performance.
- Derating and margin schedule. The applied current, thermal and vibration margins, stated as factors rather than adjectives, so your reviewer can challenge a specific number.
- Cost-driver statement. Which two or three selections dominate the BOM value, and what a change to each would move the cost by.
- Open-items list. The specific dimensions, ratings or envelope parameters still needed to convert the review into a firm quotation, written as questions rather than a request to "send more detail".
Read alongside the capability layers that the recommendations draw from, and against the incoming-inspection standard that governs what arrives at the build station, the register becomes the working document for the rest of the project.
If your submission is already close, the custom-engineering brief is the shorter path to a scoped build, and our documentation library lists the datasheets the review will cite.
Lessons from the Field
Common Design Pitfalls
Our engineering team has seen these mistakes repeated across a broad project portfolio. Avoiding them early saves weeks of rework and thousands in component costs.
- Under-specifying ESC current rating. Operating at or near the rated continuous current leaves zero thermal margin. Apply at minimum a 1.3x derating factor for sustained hover and a 1.5x factor for aggressive maneuvering.
- Ignoring vibration resonance. A motor-propeller combination that excites frame resonant frequencies can saturate IMU sensors and degrade flight controller performance, even on otherwise well-designed aircraft.
- Mismatched connector standards across subsystems. Different vendors using different connectors for the same voltage rail leads to adapter proliferation, added weight, and additional failure points. Standardize connectors early in the design phase.
- Insufficient power distribution margin. Designing the PDB for nominal current draw ignores voltage sag, connector heating, and inrush current during rapid throttle changes. Size traces and connectors for peak, not average.
Engineering Support
Need Design Help?
Our applications engineering team can review your concept, recommend component pairings, and provide preliminary BOM costing: typically within 3 business days.