Concept illustration · original evidence insideChoose the vehicle that carries the job
The aircraft is the carrier. Start with what it must carry, where it must fly and how it will take off and land.
Explore this option →TECHNICAL GUIDE / BEGINNER TO BUYER / ENGLISH
Understand the system.
Then define what must work.
For Brazilian site owners, platform companies and international buyers who need to turn a problem into a verifiable UAV requirement. Start with the decision you need to make—not a list of components.
This guide explains integration questions. Product records describe equipment. Cases explain documented work. Demos illustrate a workflow; they do not certify performance.
What goes into a useful mission?
For inspection, the desired output might be a reviewed finding tied to an asset. The aircraft transports an instrument, the instrument records observations, and a person or approved model helps interpret them. The buyer still needs to accept the result.
Concept illustration · original evidence inside
Concept illustration · original evidence insideChoose what the aircraft needs to see
A payload is the useful equipment carried by the aircraft, such as a camera or thermal imager.
Explore this option →
Concept illustration · original evidence insideGive the operator a clear view
The ground station is the operator’s workspace. Radios and mobile links carry commands, status and images between the aircraft and the ground.
Explore this option →
Concept illustration · original evidence insideHelp the vehicle know where it is
Navigation combines position information with the route the vehicle should follow. RTK uses correction information to improve a satellite position estimate.
Explore this option →Aircraft & energy
The platform carries the equipment; its power system must support the complete mission.
Ask for: Mass, centre of gravity, voltage, peak/continuous power, cooling and mounting.
Open the retained product category →Payload
The instrument does the useful measurement: for example, a visible-light or thermal camera.
Ask for: Calibration, original file format, capture conditions, trigger and timestamps.
Open the retained product category →Position & navigation
The system estimates where it is. A position estimate is not a guaranteed landing accuracy.
Ask for: Coordinate frame, time source, uncertainty and degraded-position behaviour.
Open the retained product category →Flight controller
Handles aircraft control and flight-related safety functions.
Ask for: Exact hardware, firmware, parameters, sensor inputs and failsafe settings.
Open the retained product category →Ground station
The operator plans, supervises and reviews the mission through this interface.
Ask for: Application version, operator permissions, logs and export capability.
Open the retained product category →The linked product records retain historical content. A category link does not confirm current availability, compatibility, certification or English-only source documents.
Separate the roles before choosing suppliers.
| Workstream | Plain-English role | Buyer verification question |
|---|---|---|
| Drone Detection | Observes other aircraft around a site. It is separate from flying an inspection aircraft. | Not required by every mission. Identify sensors, false alarms, missed detections and lawful observation scope. |
| Mission Computer | Runs mission applications such as image processing alongside the flight controller. | Define allowed commands, connection, timeout and restart behaviour. A separate computer alone does not prove isolation. |
| C2 | Command and control is the exchange of instructions and vehicle status. | Specify who may command, acknowledgements, stale-message handling and loss-of-link behaviour. |
| RF | Radio equipment transports signals over a wireless link. | Record exact radios, antennas, region, installation and authorised settings; vendor maximum range is not a mission guarantee. |
| Edge AI | Processes data near its source, potentially onboard or at a local ground computer. | Name the model, compute location and licence. Desktop post-processing does not establish onboard AI. |
These are an engineering framework (I), not a universal stack. Mark an irrelevant layer “not applicable” and explain why; do not force a vendor into it.
The camera should not silently become the pilot.
Aircraft control
PX4 documents a flight controller providing core flight and safety code, with a companion computer handling general-purpose applications. Serial or Ethernet can connect them. PX4 architecture reference [T1]
Proposed integration boundary: explicitly allow only required commands, identify the responsible controller, and test stale inputs, application restart and lost connections before flight.
Mission information
MAVLink is a messaging protocol between vehicles and components. Naming the protocol does not establish that two products implement the same messages or a complete secure system. MAVLink reference [T2]
For each interface, record sender, receiver, protocol/dialect, units, frame, frequency, timestamp source, permissions, acknowledgement and timeout. An ATM capability is not evidence of an available UAV UTM API.
Engineering proposal: keep original sensor files traceable through local storage, approved transfer, analysis, report and the receiving work order. Record the owner of every handoff; identify any cloud or external processing before approving data movement.
View the retained system-platform material →Choose based on what you can verify and maintain.
| Choice | When it can fit | Evidence needed |
|---|---|---|
| Buy a complete solution | The offered workflow matches the required output. | Exact configuration, sample outputs, support scope, data export, recurring costs and acceptance evidence. |
| Integrate modules | No single product covers the job, but documented interfaces exist. | Interface licences, electrical/mechanical limits, version compatibility, responsibility for failures and regression tests. |
| Develop a missing capability | A defined gap justifies engineering effort and long-term ownership. | Requirements, skills and equipment, access to code/data, IP terms, test plan, maintenance budget and exit criteria. |
Engineering judgement (I): retain access to your configuration, original data, export formats, logs and acceptance records. The original four-person planning assumption is retained for this pilot. The current five-person team does not, by itself, establish available skills or equipment.
Proposed roles: requirements/site liaison; integration/control; data/software; validation/configuration. Named assignees, budget, schedule, equipment and field access remain unknown until agreed.
Answer seven questions before approving a data path.
- Who can read the data?
- Where is it stored?
- Who receives it?
- Who can update software, firmware or models?
- Who can control the system?
- What works offline, for how long, and what happens when storage fills?
- Where is post-processing done, and by whom?
Record brand, model, hardware revision, firmware, application, ground station, payload, cloud services, region and network. Taiwan branding, assembly location, supplier statements, test results and procurement eligibility are different evidence categories.
No procurement qualification or operating permission is established by this guide. Applicable official requirements must be checked for the exact configuration, country and proposed operation.
Test the claim you actually intend to make.
| Stage | Entry condition | Exit evidence |
|---|---|---|
| Desktop / offline | Authorised sample data, requirement and draft configuration available. | Reviewable interfaces, unknowns register and accepted sample output. |
| SITL, when control software changes | Pinned software, simulator and vehicle model; isolated test environment. | Repeatable logs for agreed normal and fault cases. Simulation only. |
| HIL / ground bench | Actual hardware, safe fixture, power limits and approved bench procedure. | Measured interfaces, resource use, failure response and rollback evidence. Ground test only. |
| Controlled field trial | Relevant permissions, site access, trained personnel and accepted safety plan. | Signed results under recorded weather, load, configuration and site conditions. |
PX4 distinguishes software simulation from tests involving real controller hardware. Neither proves performance in all operational conditions. Simulation reference [T3]
Minimum acceptance proposal — all tests below are unexecuted.
| Test | Method | Proposed pass condition | Evidence file |
|---|---|---|---|
| Configuration | Export hardware/firmware/OS/app/model versions and parameters before and after the run. | Every evidence file identifies the same approved configuration; changes are recorded. | configuration.json; HBOM.csv; SBOM.json |
| Interface boundary | In an isolated test harness, exercise permitted, malformed, stale and duplicate requests. | Observed responses match the agreed interface and command policy; no unexpected accepted command. | interface-contract.csv; request-response.jsonl |
| Offline recovery | Interrupt only the proposed test transfer path using synthetic files; restore it and reconcile hashes. | No silent loss; duplicates identified; recovery timing within a buyer-approved threshold. | manifest.csv; recovery-log.json |
| Time & asset identity | Join sample sensor files, telemetry and findings by asset ID and recorded time source. | All accepted sample records map to an asset; clock error within an agreed limit. | clock-check.csv; findings.csv |
| Update & rollback | On an authorised bench, install the approved test update and restore the previous version. | Version and configuration read back correctly; logs remain available; failed update is visible. | update-log.json; rollback-log.json |
| Output usefulness | Ask the receiving analyst or maintenance team to locate each sample finding and its original file. | Every accepted finding has evidence, reviewer, decision and an actionable location. | acceptance.csv; sample-report.pdf |
Before running: agree numerical limits for latency, memory, compute load, clock error, recovery time and storage; specify voltage, power, mass, cooling and installation. Unknown thresholds block that test’s acceptance. Record programme, model and dataset licences alongside HBOM/SBOM and configuration versions.
One actual case. One clearly labelled demo.
Brazil solar inspection
See how a historical aircraft/camera workflow led to analysis and maintenance decisions. The case preserves its own equipment evidence and unknowns.
Read the documented case →Inspection workflow demo
Explore capture, transfer, review and action using invented asset IDs. Offline transfer and missing identity are proposed design questions, not recorded incidents.
Try the educational walkthrough →Future case pages will link to the relevant technical chapters. A safety regression bench, local Edge AI inspection and observation-only detection remain proposal categories until their own evidence and specifications are reviewed.
Tell us the output, constraints and unknowns.
Provide country/site, intended mission, existing aircraft and payload, network and data restrictions, required deliverables and equipment availability. “Not yet determined” is a valid answer.
Guide reference: TECH-UAV-01. BE PASSIVE receives the enquiry; no supplier is automatically contracted or emailed. Price, schedule, APIs, licences and staffing require case-specific confirmation.
SUPPLY CHAIN & MISSION INTEGRATION
Know what is inside.
Know who has control.
合機 (Hé Jī) connects the retained product records to a configuration-level review: exact part, revision, origin, firmware authority, data route and acceptance evidence. No whole-system qualification is inferred from the brand or a product category.
Review the component and interface questions →Our origin and non-China sourcing mission →Read dated control evidence →
Current contact: hjuav@icloud.com. Exact availability, origin, API rights, testing, commercial terms and responsible engineer remain to be confirmed.
Check the basis of the explanation.
- T1 — PX4: Companion Computers — P1, official technical documentation; not evidence for an unnamed product configuration.
- T2 — MAVLink Developer Guide — P1, official protocol documentation.
- T3 — PX4: Simulation — P1, official simulation documentation. Pin a release before implementing a test.
- Brazil procurement / integration / development guide — S, retained Portuguese research context.
- Earlier UAV architecture introduction — S, retained Chinese research context.
- Brazil solar procurement and data analysis — S, English supporting analysis.
The framework, suggested boundaries, roles and tests are I (engineering interpretation). Missing project facts are U (unknown). No hardware, simulator or field test was executed to produce this guide.