# Edge AI on a Drone Is a Systems Problem, Not a Model Problem An object-detection model can perform impressively on a desktop computer and still be a poor choice for a drone. The difference is the environment in which the model has to work. A desktop computer can draw power from a stable supply, use substantial cooling and process data without worrying about every gram of additional hardware. An aircraft has a very different set of constraints. Its computing hardware adds weight, consumes battery power and has to operate within a compact physical system. This is why deploying AI on a drone is not simply a matter of exporting a trained model and running inference. It is a systems engineering problem. ## From camera image to useful decision Consider a drone using computer vision to identify an obstacle. The process involves more than the neural network itself: 1. A camera captures an image. 2. The onboard computer receives and preprocesses the image. 3. The inference engine runs the model. 4. The system interprets the model output. 5. A perception or planning component decides what the information means for the current flight. 6. Relevant information is communicated to the flight-control system. Every stage introduces processing time and potential failure points. A model that completes inference quickly may still belong to a slow overall pipeline if image transfer, preprocessing or communication takes too long. For a moving aircraft, the age of the information matters. A detection that arrives after the aircraft has already moved significantly may be less useful than a slightly less detailed result delivered on time. That is why end-to-end latency deserves at least as much attention as model inference time. ## Why a companion computer makes sense Many autonomous drone architectures separate the flight controller from a companion computer. The flight controller handles core flight-control and safety functions. The companion computer provides a more flexible environment for general software and computationally demanding applications such as computer vision. In a PX4-based architecture, the companion computer commonly runs Linux and communicates with the flight controller through MAVLink or uXRCE-DDS. This separation has a practical advantage. Developers can experiment with computer-vision models, robotics software and other applications without treating the flight-control firmware as a general-purpose AI workstation. It also creates an important architectural responsibility: the flight-control system must not blindly trust every output from an AI process. Perception, planning and flight control are related, but they are not interchangeable. An object detector identifies patterns in images. It does not automatically understand every flight constraint or guarantee that a proposed manoeuvre is safe. ## The hardware budget is part of the algorithm A model that requires more computation may deliver better results, but the aircraft has to carry the hardware that runs it. Weight, power consumption, cost and available computing resources all influence the choice of companion computer. There are several competing requirements: - Processing capacity for the selected model. - Memory for images, model weights and intermediate data. - Power consumption within the aircraft's electrical budget. - Thermal management in a compact enclosure. - Reliable communication with the flight controller and sensors. These considerations can change which model is actually suitable. A smaller model with predictable response times may be more useful than a larger model that occasionally misses its processing deadline. The best model is not necessarily the most accurate model on a benchmark dataset. It is the model that meets the requirements of the complete aircraft system. ## Model optimisation comes with trade-offs Tools such as NVIDIA TensorRT can optimise trained neural networks for deployment on supported GPU hardware. Techniques such as reduced-precision computation can improve performance and reduce resource requirements. However, faster execution does not automatically mean equivalent model accuracy. NVIDIA's TensorRT documentation explicitly discusses accuracy and performance trade-offs associated with FP16, BF16 and INT8 execution. Quantisation and other optimisation choices need to be validated against representative data. This matters particularly for aerial applications. The camera may encounter changing lighting, shadows, motion blur, different viewing angles and objects that were poorly represented in the training data. A model that performs well on a prepared dataset may behave differently under real operating conditions. ## Measure the entire system, not just inference A sensible development process starts with measurement. Instead of asking only how many frames per second a model can process, measure the complete pipeline: - Camera capture and frame delivery. - Image preprocessing. - Data transfer. - Inference latency. - Post-processing. - Communication with other onboard components. - Total time from image capture to usable output. Then repeat the measurements under realistic hardware and workload conditions. NVIDIA recommends a measure-then-optimise workflow for TensorRT: establish a reproducible baseline, make changes and measure again. The same principle applies to drone engineering. An optimisation is only useful when it improves the actual system without introducing unacceptable accuracy or reliability problems. ## What happens when AI stops responding? This is perhaps the most important design question. What should the aircraft do if the inference process crashes, the camera stops delivering frames or the model produces results with insufficient confidence? The answer should be part of the system architecture, not something considered after deployment. A robust design should distinguish between valid perception data, uncertain results and complete loss of the perception process. It should also define how the flight-control system behaves when those conditions occur. AI should provide information that the wider system can evaluate. It should not be treated as an unquestionable source of truth. The goal is not to put the largest possible neural network on a flying platform. It is to build an aircraft in which sensing, computing, communication and control work together predictably. That is where edge AI becomes an engineering discipline rather than a demonstration of model performance. --- ### Further reading - [PX4: Companion Computers](https://docs.px4.io/main/en/companion_computer/) - [NVIDIA TensorRT: Best Practices](https://docs.nvidia.com/deeplearning/tensorrt/latest/performance/best-practices.html) - [NVIDIA TensorRT: Optimizing Performance](https://docs.nvidia.com/deeplearning/tensorrt/latest/performance/optimization.html) *This article discusses engineering principles and software architecture. It does not claim that a particular AI model or aircraft has been independently tested.*