Agricultural drone software development connects mission planning, flight firmware, autopilot communication and sensor data management. For UAV manufacturers, integrators and survey system developers, the engineering challenge is to build a coherent workflow from a requested route to acquisitions and verifiable results. This requires expertise in C++, embedded firmware, protocols, control systems and operator interfaces.
SLX AgriPilot is the Windows platform developed by Silicon LogiX for building and verifying VTOL drone survey missions. It combines a 3D agricultural environment, route planning, execution with PX4 and Gazebo, telemetry and virtual image analysis. The 0.6.0 evaluation release is available on GitHub. Its architecture provides a technical case study of the software and embedded engineering required to develop UAV systems.
Developing UAV systems for manufacturers and integrators
A drone, payload or inspection platform needs a clear allocation of responsibilities across onboard firmware, an optional mission computer, the ground application and subsequent analysis. Adding a MAVLink interface, another camera or a survey algorithm introduces synchronization, state management and diagnostic requirements that cross component boundaries.
AgriPilot makes this work accessible through an agricultural use case: operators can change a plan, observe a simulated mission and trace results back to acquired data. This workflow supports technical discussions about PX4 and MAVLink integration, mission software, telemetry and sensor acquisition before adapting the system to a product. For a specific development project, the starting point is a technical assessment of firmware and interfaces, with explicit requirements, hardware constraints and verification criteria.
An architecture connecting mission, autopilot and data
AgriPilot comprises a native C++20 application, an SDK for external modules and a simulation backend. On the Windows PC, the operator configures the field, builds the plan, edits waypoints and inspects results and recordings. The Python bridge, MAVSDK, PX4 firmware compiled for SITL and Gazebo Harmonic run in WSL2 with Ubuntu 22.04.
The boundaries between these layers make their responsibilities explicit. A planning module proposes a route; the application checks whether it satisfies the declared constraints; the bridge configures and starts the mission; PX4 executes the autopilot logic; Gazebo integrates the aircraft dynamics. The interface displays recorded samples. Movement in the 3D scene therefore comes from an identified source, such as a simulated flight recording or a geometric preview.
Laboratory architecture. PX4 produces state estimates and commands; Gazebo provides the simulated physical state. The recording preserves both sources.
This separation also helps maintenance. A mission upload failure must be distinguishable from a simulator startup problem, stale position data or an unusable image. Each execution therefore has its own directory, diagnostics for each phase and the identities of the components used. Reference versions are pinned: PX4 1.17.0, Gazebo Harmonic and MAVSDK Python 3.10.2.
Drone mission software: C++20, OpenGL and the operator interface
The desktop software uses GLFW for its window and input, OpenGL 3.3 for rendering, Dear ImGui for panels and ImPlot for charts. C++ supports typed contracts across the mission model, session state, geometry and visualization, with explicit resource management. Managing process handles, graphics resources and files contributes to application quality alongside interface design.
The editor lets operators drag waypoints with the mouse, validate them and undo or redo changes. The plan being edited, the executed mission and a loaded recording have separate roles. During replay, display time is interpolated to make movement readable, while the original samples remain available for analysis. Editing a plan must preserve the history of a flight that has already been recorded.
Interface engineering centers on operator decisions: which module is selected, which locations will be observed, which data are missing and where evidence for a finding can be inspected. The same requirements arise in industrial HMIs, test instruments and supervisory applications.
3D model, kinematics and coordinate systems
The AP-01 model represents a three-rotor VTOL with two tilting front nacelles, a rear rotor, movable surfaces, landing skids and a gimbal-mounted camera. The glTF/GLB asset preserves hierarchies, pivots, materials and transformations. Rotating a nacelle must correctly move all its descendants; orienting the gimbal must also update the camera's optical frame.
This requires transformation matrices, quaternions and explicit axis conventions. The local scene uses metric coordinates with a positive vertical axis; Gazebo and PX4 NED estimates require declared conversions. The glTF export also has its own convention. Applying a conversion twice can reverse a movement; using the body pose instead of the sensor pose can displace the ground footprint. These boundaries are documented in the project's coordinate and API contract.
The inspection camera follows the drone and allows the operator to orbit around it. During replay with joint data, nacelle tilt and the displayed mechanical movements are associated with the Gazebo recording. Maintenance operations are geometric controls performed with the aircraft parked. Defining these relationships between objects, state and data sources is useful in any 3D interface connected to a technical system.
Model inspection in the application: geometry, hierarchy and moving components are accessible in the same environment used to plan and review missions.
Drone firmware: the PX4 autopilot, uORB and state estimation
PX4 is the autopilot stack integrated into the laboratory. The firmware acquires sensor information, estimates aircraft state, manages operating modes and conditions, and produces actuator commands. Work in this project covers integration, nominal aircraft configuration, mission management and recording verification. PX4 remains an identified upstream component: an AgriPilot C++ policy and a flight firmware modification are separate engineering changes.
PX4 modules communicate through uORB, an internal publish/subscribe system. A producer publishes data on a topic; other modules subscribe to the topics they need. This decoupling helps engineers reason separately about drivers, estimation, control and communications while defining messages, timestamps and responsibilities.
State estimation combines inertial measurements with other available observations. The PX4 EKF2 filter handles quantities such as attitude, velocity, position and sensor biases. An accelerometer alone cannot provide a stable position over time: errors and biases accumulate through integration. Measurement fusion, time alignment and observation quality checks therefore contribute directly to autopilot behavior.
Simplified functional chain of a PX4 autopilot. The mission supplies objectives; estimation, control and allocation determine actuator commands.
Controllers turn navigation objectives into motion and attitude requests. Control allocation then translates thrust and torque requests into commands compatible with motor and servo geometry. In a tiltrotor, nacelle position, orientation and control authority matter: a 3D model alone does not define those physical parameters.
From firmware on a PC to an embedded system
In SITL, firmware runs as a program on the computer. A physical flight controller introduces a microcontroller, peripherals and an operating system; many PX4 platforms use NuttX. Embedded development must address task priorities, latency, memory, interrupt handling and peripheral access within the constraints of the selected board.
An acquisition path may require SPI or I²C sensor drivers, UART connections for external devices and CAN interfaces for distributed nodes. PX4 CAN support illustrates why electrical connections and device protocols are part of integration. Rates, queues, timeouts and stale data handling must match the requirements: receiving a message does not by itself establish that its data are still usable.
For a product, these activities also involve board configuration, startup, diagnostics, firmware updates and error recovery. AgriPilot supports work on integration and mission logic first; adapting that work to specific electronics requires a dedicated verification campaign on the target hardware.
SITL and Gazebo: what calculates the movement?
Software-in-the-loop means executing control software connected to a simulated environment. In AgriPilot, Gazebo integrates the physical state of the nominal model, and PX4 receives the observations supplied by the simulation link. Actuator commands return to the model, closing the loop. The Windows renderer uses the resulting data to display the aircraft.
AP-01 has declared mass, inertias, motor characteristics and nacelle limits. Its three-rotor geometry is registered against the visual model; dynamic parameters remain nominal laboratory assumptions. The executed campaign covers takeoff, hover flight, mission traversal, return and landing. Cruise transition and the behavior of a real aircraft require additional models and tests.
A central requirement is to preserve commands, PX4 estimates and Gazebo physical state as separate data. If the estimated drone is close to the route while simulator ground truth differs, the comparison must expose that difference. Simulation time, elapsed PC time and message timestamps also have different meanings: confusing them changes synchronization and measurements. Runtime conditions and model and firmware identities are described in the runtime documentation.
MAVLink and MAVSDK integration: drone missions and telemetry
MAVLink defines messages and services for exchanging information with vehicles and components. In this laboratory it carries missions, telemetry, parameters and command outcomes. MAVSDK provides the APIs used by the Python bridge: AgriPilot uses MissionRaw to work with mission items, and subscriptions to monitor state changes.
The MAVLink Mission Protocol manages item transfer, sequencing and acknowledgment. The bridge also downloads an uploaded mission to check its contents. This verifies the handoff between the planner's proposal and the plan received by the autopilot before execution is considered.
Sending a command initiates a transaction. The Command Protocol provides a COMMAND_ACK response: its result must be interpreted together with the subsequent system state. For example, an arming request may be denied because preconditions are unmet. The project monitors telemetry continuity, transport availability, autopilot health and altitude stability; an eligible transient denial is handled through bounded retries and a fresh stability check.
This is an asynchronous state machine: backend readiness, connection, configuration, upload, verification, arming, takeoff, mission and shutdown. Each phase has entry conditions, timeouts and diagnostic outcomes. The bridge also manages cancellation and termination of its own processes while preserving logs. These skills transfer to industrial gateways and remote control systems, where sending, receiving and completing an action are separate events.
A real link also requires authentication, network segmentation and key management. MAVLink 2 message signing addresses protocol authenticity and integrity; transport encryption serves a different purpose. The laboratory backend is local. Protection of a radio network or remote access must be specified and verified in the operational integration.
Survey planning: geometry, coverage and the SDK
The planner receives the area, altitude, speed, pass spacing, orientation and camera parameters. The C++ examples build parallel transects, clip them to the polygon and alternate pass direction. The application adds takeoff, return and landing anchors and checks the plan's declared constraints.
For an ideal nadir-facing camera over flat ground, footprint width is W = h × s_w / f, where h is height above ground, s_w is sensor width and f is focal length, expressed in the same unit as s_w. Nominal ground sampling distance is GSD = W / N, where N is image width in pixels. Along-track capture spacing is d = H × (1 − o), with footprint length H along the route and longitudinal overlap o.
Ideal planning geometry over flat ground. Nominal coverage must be compared with images that were actually acquired, valid and sufficiently readable.
Reducing pass spacing can increase coverage while changing waypoint count, acquisition count and duration. Baseline and Dense make this choice comparable in the laboratory. The plan's nominal resolution and the analysis raster resolution have separate contracts: current virtual images have an analysis width of 96 pixels. A theoretical GSD value therefore does not establish the resolution of a real image.
The SDK exposes planning and telemetry observation as independent Windows executables. Modules receive and return versioned JSON through pipes. Time, message size and process resource limits contain failures; a SHA-256 checksum identifies the module used. This boundary avoids requiring a shared C++ ABI and supports implementation comparisons with an identifiable execution history.
Gimbal and acquisition: knowing where the sensor looks
The camera acquires from a composed pose: drone position and orientation, the mounting transformation and gimbal rotations. Pitch and yaw change the optical axis and where rays intersect the ground. A camera facing the sky cannot observe the field; an oblique camera produces a different geometry from a nadir-facing camera.
In AgriPilot this pose governs virtual image generation. The system preserves the origin, optical axes, sensor parameters and frame quality. RGB, NIR and thermal rasters come from a procedural optical model over a flat surface; these synthetic data are associated with the mission and inspectable in the interface. The gimbal thereby connects model kinematics to acquisition geometry.
Images and data available in the software. These four views refer to an identified virtual acquisition whose parameters and pixels are preserved.
Agricultural drone data analysis: RGB, NIR, thermal and NDVI
The laboratory includes four contexts: arable crops, irrigation, orchard and post-storm survey. The operator configures points with normal or problematic conditions, position, radius and intensity. During the mission, acquisitions observe only areas inside the valid footprint. Unobserved cells remain unknown.
The image generator knows the field conditions. The detector instead receives saved rasters, poses, declared calibration, area of interest and thresholds: it does not receive configured anomaly centers or intensities. Known conditions are connected later to evaluate errors. This architecture makes it possible to check whether changing pixels actually changes the result.
Scenario knowledge and observed data follow separate paths. Detection preserves the source frame link; evaluation subsequently compares results against known conditions.
NDVI is calculated as (NIR − R) / (NIR + R). In the software it contributes to a vegetation anomaly index; the irrigation scenario also combines a synthetic thermal contrast. Cells are projected into images and sampled only where valid pixels exist. Adjacent anomalous cells form findings linked to the first usable acquisition.
Context gives an indication its meaning: a low vegetation index alone does not identify an agronomic cause. The laboratory score does not represent a probability, moisture percentage or neural network confidence. Current processing uses explicit indices and thresholds; introducing machine learning models would require a dedicated dataset, annotations, metrics and validation.
Noise, exposure, haze, saturation and motion blur can degrade the modeled data. An excluded frame remains saved with its quality outcome. Unknown areas remain distinct from areas observed without anomalies, providing information needed to decide whether a survey is sufficient.
Recordings, before-and-after comparisons and reports
A result becomes useful when the path that produced it can be reconstructed. AgriPilot exports HTML reports, CSV, JSON, images, metadata and a SHA-256 inventory. Every finding links to source cells and frames; the mission preserves flight samples, parameters and the identities of firmware, model and modules. Original PX4 ULog files are retained separately from captured MAVLink datagrams.
A before-and-after comparison can involve a second mission after field conditions have changed. Threshold-only reanalysis uses the same original pixels. Regenerating images along a saved route has another provenance, declared by the software. Distinguishing these operations makes it possible to discuss what changed: environment, route, acquisition or algorithm.
Metrics also remain separate: mission progress and completion, route error, geometric coverage, optical coverage and detection quality. A mission can finish successfully while leaving parts of the field unobserved. Precision, recall and errors against known conditions describe the evaluated synthetic case without extending those numbers to real farmland.
Software verification and the path to hardware
Verification covers module protocols, failures and timeouts, plan validation, editor interactions, camera geometry, detector independence and export integrity. The Windows release has also been exercised with the PX4/Gazebo backend on the nominal three-motor model. Dependency versions, archive hashes, public source builds and CI checks make the distribution scope inspectable.
Moving to an operational drone requires further work: aircraft parameter identification, electronics selection and integration, sensor calibration, link verification, fault analysis and system tests. Hardware-in-the-loop runs firmware on a physical flight controller connected to a compatible simulation. It needs a campaign distinct from SITL, followed by the tests required for the product and its intended use.
The current laboratory supports development and comparison of missions, integrations and data processing within documented assumptions. Real-field multispectral calibration, RTK/DEM georeferencing, calibrated energy endurance, VTOL transition and HIL tests are possible areas of subsequent work, to be specified and verified. The model documentation defines the preview's scope.
Questions about drone software, firmware and simulation
What is the difference between mission software and drone firmware?
Mission software prepares routes, displays states and manages acquisitions and results. Flight firmware executes autopilot functions on the system controlling the aircraft. Integration connects objectives, commands and telemetry through defined interfaces; changes to a planner and changes to controllers require different verification activities.
What are PX4, MAVLink and Gazebo used for?
PX4 supplies the autopilot stack; MAVLink is the protocol used for missions, parameters, commands and telemetry; Gazebo executes the simulated physical model. AgriPilot integrates them with the Windows application and MAVSDK bridge. Recordings keep the requested plan, autopilot estimate and simulator state separate.
Can a custom camera or sensor be integrated?
This requires engineering around the interface, power supply, data format, trigger and timestamps. Calibration, mounting pose relative to the aircraft and sample validity conditions must also be defined. AgriPilot's virtual camera illustrates the data path; a physical payload requires dedicated drivers, integration and tests.
Does simulation replace real drone testing?
Simulation allows software and interfaces to be verified against a declared model. Real system testing must then address electronics, sensors, identified dynamics, operating conditions and fault behavior. SITL, HIL tests and product verification have separate objectives and acceptance criteria.
The engineering capabilities connected by this project
AgriPilot centers on integration work that connects requirements, architecture and evidence:
Software and HMI: C++ applications, editors, charts, 3D rendering and session management.
Firmware and control: autopilot stack integration, configuration, estimation, actuators and diagnostics.
Communications: protocols, transactions, state machines, synchronization and interruption handling.
Geometry and acquisition: coordinate frames, sensor poses, footprint, overlap and valid samples.
Data and verification: traceable algorithms, repeatable comparisons under declared conditions, logs and inspectable reports.
The Silicon LogiX approach connects requirements, firmware, management applications and data through defined interfaces and progressive verification. Work includes analyzing the required behavior, defining contracts, implementing the integration loop and testing against explicit acceptance criteria. The objective is to build components that remain integrable, diagnosable and maintainable as the product evolves.
The SLX AgriPilot GitHub page provides the Windows distribution, technical documentation and SDK examples. UAV integrations, custom payloads and management applications can be assessed through a technical discussion with Silicon LogiX. Engineering services include embedded firmware development, software development and hardware and software prototyping.
Canonical source: Agricultural Drone Software and Firmware: SLX AgriPilot.
Top comments (0)