Onboard AI Drones: How Edge Vision Turns Field Flights into Decisions

Why field data still arrives too late to act on

Many farms still learn about crop problems the slow way: someone drives the rows, checks plants by hand and reacts once the damage is visible. The data that does exist is scattered. Photos sit on SD cards, laptops and chat threads, telemetry lives in a separate tool, and nobody has one place to see what is happening across the orchard.

Drones are not new to agriculture. What has been missing, as Alex Fesiak, VP of Sales at Indeema, said in the Edge AI Foundation webinar we joined with Avnet, is drones that are connected to the cloud and run AI on board. Without both, a drone is a better camera, not a better decision: someone still has to download the images and look through them.

This article walks through the architecture we presented there, on a concrete case: a drone that flies an apple orchard, detects and counts the fruit on board and streams the results to a cloud dashboard for yield estimation and harvest planning.

What makes a drone an edge AI drone

Edge AI drone

A drone that runs machine-learning inference on its own processor during the flight, so it can detect, classify or count objects without sending images to a server first. The cloud is still used for storage, fleet management and retraining, but it is not on the critical path of each decision.

The question we hear most is why not simply send every image to the cloud, where compute is cheap. Ivan Karbovnyk, Indeema’s CTO, answers it with three words: bandwidth, latency and connectivity.

• Bandwidth. A drone can capture dozens of images per second. Uploading all of them over a cellular link is slow and expensive.
• Latency. A decision made on board takes a fraction of a second. A round trip to the cloud adds network delay before the drone can react.
• Connectivity. Rural fields often have weak or no cellular coverage. An onboard model keeps working when the link drops, and the drone uploads its results when it can.

That does not make the cloud optional. It moves the cloud from the inference path to the improvement path: the drone decides, the cloud learns.

A four-layer reference architecture for an edge AI drone

The platform we presented is modular on purpose. The core stays the same across use cases, while the sensors, the model and the mission change. It has four layers, each with its own processor and its own job.

Why a Linux computer does not fly the drone

It is tempting to let the powerful single-board computer orchestrate everything. We do not. The flight controller runs ArduPilot on a microcontroller because flight needs precise timing and must stay stable whatever the Linux system is doing: a hung process or a model update must never reach the motors. Even platforms built on a real-time Linux kernel keep a separate safety microcontroller that can reset the main computer in an emergency.

The vision module talks to the flight controller over a UART link using MAVLink, the protocol ground stations use. It reads the flight status and sends commands, but the flight controller remains the authority. An analog camera with an on-screen display keeps a low-latency video link to the ground station, so a pilot can take over, although the intended way to operate is a pre-planned mission configured from the cloud.

Radio links: control, video and data on separate channels

A connected drone carries several radios, and each one has a different job.

Because these radios work in different frequency bands, interference is rarely a problem; where two must share a band, they are put on different channels. Wi-Fi is used near the base, where a local network exists, and LTE covers the field and takes over when Wi-Fi drops. The IoT companion module provisions Wi-Fi and falls back to 4G automatically, so remote access and telemetry upload are not interrupted.

We mostly use off-the-shelf LTE modules on ordinary prepaid SIM cards rather than private networks: farms are remote, and good Wi-Fi infrastructure there cannot be assumed. Satellite links are used in some deployments, and LoRaWAN in drone-swarm applications, where several drones share an area.

The point is not live piloting from an office. It is that mission plans and waypoints reach the drone from the cloud before take-off, so nobody has to fly it by hand across the orchard.

Bandwidth budget: what to send and what to keep on board

Cellular traffic can get expensive, so the capture mode is chosen per mission. The figures below are the orders of magnitude Ivan Karbovnyk gave for the presented platform.

The gap between the first two rows and the rest is the business case for edge AI. When the drone sends what it found instead of what it saw, a full survey needs kilobytes per second of uplink. Imagery is uploaded selectively: the frames the model was unsure about, or new conditions worth adding to the training set.

Onboard inference: model, latency and power

The vision and edge AI module is the custom part of the platform. A Raspberry Pi 5 handles image capture, preprocessing and communication with the cloud; a Hailo-8 accelerator with 26 TOPS of processing power runs the neural network; a high-resolution camera connects directly to the Pi. A small STM32-based controller drives the gimbal, so the camera angle can be set from the cloud, for example to keep the sun out of the lens when the drone flies towards it.

Why YOLO

The detector is a YOLOv11 model. YOLO models balance detection accuracy against inference speed and are simple to deploy, which matters when video has to be processed in real time on constrained hardware. Single Shot Detector (SSD) models are an older but still lightweight alternative that also suits onboard deployment.

How fast, and at what power cost

On the Raspberry Pi and Hailo combination, the full cycle takes roughly 100 to 300 milliseconds per image: capture, preprocessing, inference and postprocessing together. That is fast enough to count fruit or flag an anomaly while the drone is still over the tree.

Power is less of a constraint than most teams expect. The computer and accelerator draw several watts during inference, while the four motors draw hundreds of watts in flight and more during manoeuvres. The AI module is a small share of the power budget.

Telemetry that predicts, not only reports

Raw telemetry tells the operator where the drone is. Derived telemetry tells them what is about to happen. Once the data is in the cloud, dashboard widgets combine signals into answers an operator can act on.

These are the features that make a drone usable by someone who is not a drone engineer. A farm manager does not want voltage curves; they want to know whether the drone will make it back.

Why the model must keep learning after deployment

In agriculture, a model trained once does not stay accurate. Varieties, growth stages, light and weeds change through the season and from farm to farm, so the platform treats the model as something that ships again and again.

Redeployment happens on the ground, not mid-flight: the drone is recalled to base and receives the new model there. Swapping a model in the air gains nothing and adds risk.

How much training data you need

It depends on the task. Common problems such as weed detection can start from open datasets and work well. A customer-specific classification task, such as one kind of fruit damage, depends entirely on imagery the customer can supply, and that is usually the real bottleneck. Thousands of labelled images are typically needed for decent results. Synthetic images from generative models are a promising way to fill the gaps; we train on synthetic data in other domains but have not yet tried it on agricultural imagery.

Use case: counting apples to estimate orchard yield

Estimating apple yield across a large orchard is slow and labour-intensive when it is done on foot, and the rows are hard to reach after heavy rain. This is how the edge AI drone handles it:

1. An operator defines the mission in the cloud and uploads the waypoints: the drone flies from A to B to C and back.
2. The drone flies the route automatically, and telemetry places every detection in a specific row and tree.
3. The onboard model detects and counts apples, and flags anomalies, in near real time.
4. Telemetry and AI results stream through the connectivity layer to /IOTCONNECT, where a dashboard shows them on any tablet, laptop or phone.
5. If something looks wrong, the operator sends a command and the drone returns to base.

The result is an automated yield estimate that feeds harvest planning, instead of a manual sample extrapolated across the orchard. Technically the system is complex; for the farm team it is a route, a map and a dashboard, and that simplicity decides whether the product gets used.

We are currently developing this approach with farming companies in Western Europe.

From detection to action, and beyond agriculture

Detection is the first step. The action agricultural customers ask for most is spraying, which needs a larger drone with liquid tanks. Rather than building heavy airframes, we build the actuator and control infrastructure that lets onboard detections trigger spraying or other equipment, and we bring that automation to a customer’s own larger drone.

The same core architecture transfers to other industries with different sensors and models:

• Energy and utilities: power lines, solar farms, pipelines and wind turbines, checked for corrosion, vegetation and leaks without sending crews up towers.
• Building and infrastructure inspection: roofs, bridges and facades, with structural issues flagged during the flight.
• Emergency services: search and rescue, wildfire monitoring and disaster assessment, where responders need actionable information in minutes, not hours.

More compute at the edge means more autonomy: drones that decide in flight instead of only collecting data for later.

Questions to answer before you build an edge AI drone

If some of these answers are still open, that is normal at the start of a programme. It is also where integration risk hides, which is the subject of our whitepaper on the problems that stall drone projects.

Common mistakes

1. Letting the companion computer fly the drone

   A hung process or a model update on the Linux side can destabilise the aircraft.

   Instead: Keep a real-time flight controller in charge and talk to it over MAVLink.

2. Streaming everything to the cloud

   Data costs grow with every flight and the system stops working where coverage is weak.

   Instead: Send detections and telemetry, and upload images selectively.

3. Training the model once

   Accuracy drifts as crops, seasons, light and farms change.

   Instead: Build upload, labelling, retraining and redeployment into the platform from the start.

4. Showing operators raw telemetry only

   People who are not drone engineers cannot judge whether a mission is safe to continue.

   Instead: Add derived insights such as point of no return and remaining flight time.