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
• NVIDIA TensorRT: Best Practices
• NVIDIA TensorRT: Optimizing Performance

This article discusses engineering principles and software architecture. It does not claim that a particular AI model or aircraft has been independently tested.

This becomes a problem when GNSS signals are unavailable or unreliable. Indoor environments, covered structures and areas with difficult signal conditions can make satellite-based positioning less useful. Yet the aircraft still needs an estimate of its movement to maintain controlled flight.

One approach is Visual-Inertial Odometry, usually shortened to VIO.

It combines information from cameras and inertial sensors to estimate how a vehicle is moving relative to a local starting point. The interesting part is not simply that a drone can see its surroundings. It is how two very different types of sensors compensate for each other's weaknesses.

What the camera knows — and what it doesn't

A camera records images, not geographical coordinates.

Visual odometry works by identifying visual features in successive frames and observing how their apparent positions change. From those changes, an algorithm estimates the camera's movement through the environment.

Imagine a drone moving past a wall with visible patterns, corners and other recognizable details. The camera captures these features repeatedly. By comparing frames, the system can estimate how the camera has moved.

But vision alone has limitations.

Rapid motion can produce blurred images. A surface with very little visual detail offers few useful features to track. Changes in lighting can also make reliable tracking more difficult.

A camera provides valuable information, but it does not provide a complete navigation solution on its own.

Why an IMU changes the picture

An Inertial Measurement Unit (IMU) typically contains accelerometers and gyroscopes.

The accelerometer measures specific force, while the gyroscope measures angular velocity. These measurements describe how the aircraft moves and rotates over time.

An IMU responds much faster than a typical camera frame sequence, making it useful when the aircraft moves quickly between images.

VIO combines the two information streams:

• The camera provides visual observations of the surrounding environment.
• The IMU provides rapid measurements of motion and rotation.
• The estimation algorithm combines these observations to calculate a more useful movement estimate.

The result is an estimate of position, orientation and velocity relative to a local reference, rather than an absolute geographical position.

That distinction matters. VIO does not automatically tell the drone its latitude and longitude.

VIO is not the same as optical flow

These terms are sometimes used interchangeably in casual discussions, but they describe different capabilities.

Optical flow systems commonly use a downward-facing camera together with a distance sensor to estimate two-dimensional velocity.

VIO goes further by combining visual information with IMU measurements to estimate three-dimensional pose and velocity.

The distinction is important when discussing navigation architectures. A system designed to maintain position over a nearby surface is not necessarily capable of providing the same information as a full visual-inertial navigation system.

PX4 documents both approaches as separate computer-vision capabilities.

The difficult part is often integration

Running a VIO algorithm is only one part of building a working aircraft.

Consider a typical PX4-based architecture:

A camera supplies images to a companion computer. A visual-inertial estimation process runs on that computer, often within a ROS-based software environment. The resulting odometry information is then sent to the flight controller through an appropriate interface.

PX4 can use external vision information through its EKF2 estimator.

Several details can determine whether this arrangement works reliably.

Camera mounting and vibration: A camera that moves or vibrates relative to the aircraft frame introduces errors. PX4 specifically recommends vibration isolation for sensitive tracking cameras.

Timing: Camera measurements and IMU measurements must be aligned in time. A delayed position estimate can be misleading even when the underlying algorithm is functioning correctly.

Coordinate frames: The camera's orientation relative to the aircraft must be represented correctly. A mismatch can produce unexpected movement estimates.

Estimator configuration: External vision measurements need to be configured and fused appropriately. Sending valid messages does not automatically guarantee a reliable navigation solution.

These are engineering problems, not merely software installation problems.

Where VIO reaches its limits

VIO is useful, but it is not a universal replacement for GNSS.

Visual tracking can deteriorate in environments with insufficient visual features. Vibration, motion blur, poor image conditions and calibration errors can all affect the estimate.

There is also a longer-term issue: errors in estimated movement can accumulate into position drift.

More advanced visual-inertial SLAM systems introduce mapping and loop-closure techniques to help recognize previously observed locations and correct accumulated errors. However, those capabilities should not be confused with what every basic VIO implementation provides.

The practical question is therefore not whether a camera can replace GPS.

It is how different positioning sources can be combined, monitored and used within the limits of the aircraft's actual environment.

A drone that understands the limitations of its sensors is more interesting, from an engineering perspective, than one that simply claims to be autonomous.

Further reading

• PX4: Visual Inertial Odometry
• PX4: Computer Vision
• ORB-SLAM3: An Accurate Open-Source Library for Visual, Visual-Inertial, and Multimap SLAM

This article is a technical overview based on published research and engineering documentation. It does not describe a particular aircraft test or independently verified flight experiment.