Onboard navigation asks a small aircraft to do something that used to need a rack of equipment: sense the ground, compare it with a map and produce a position, many times a second, using only what it carries. The hardware choices behind that are less glamorous than the algorithms but they decide whether the system flies at all. This article works through the main decisions from the point of view of a fixed-wing platform.
Start with the budgets, not the parts
The temptation is to start with a shopping list. It is better to start with three numbers: how much mass the airframe can give up to a navigation payload, how much electrical power is available after propulsion and the existing avionics, and how much airflow or surface area is available to shed heat. Every component then has to justify its place against those limits.
On a fixed-wing aircraft, mass is doubly expensive. It shortens endurance directly and it can move the centre of gravity, which affects handling. A navigation payload that adds noticeable mass to a small airframe has to be worth it in mission terms, and the discipline of a fixed budget keeps the design honest.
Compute: enough, not maximum
The processing load in terrain-referenced navigation is dominated by image handling and feature matching. That sounds like it demands the biggest processor available, but the real requirement is a steady rate of position updates within a fixed latency, not peak throughput. A modest embedded system-on-module with a capable GPU or neural accelerator can meet that comfortably if the software is written for it.
A few practical points when evaluating compute:
- Sustained performance matters more than the headline number, because a board that throttles under heat will produce irregular update rates when the aircraft is working hardest.
- Interfaces matter. The board needs a direct camera interface, a serial or CAN link to the autopilot, and enough storage for the terrain database.
- Power draw at the intended workload, not at idle, is the figure to design around.
- Availability and lifecycle are part of the specification. A board that is easy to buy today and will still be made in five years is worth more than a marginally faster one that is not.
Cameras and the IMU
For forward-flying aircraft the camera is the critical sensor, and a few properties dominate. A global shutter avoids the skew that a rolling shutter introduces at speed, which otherwise corrupts the geometry the matcher depends on. Sensor sensitivity and dynamic range decide how well the system copes with early morning, late afternoon and bright midday over pale ground. Lens focal length sets the field of view, which trades ground coverage per frame against detail per pixel, and the right choice depends on the altitude band the aircraft will mostly fly in.
Mounting is easy to underestimate. The camera must be rigidly fixed relative to the IMU, protected from propeller vibration and kept clear of exhaust or heat plumes that distort the air in front of the lens. Heat shimmer from the airframe itself is a real effect over hot ground and a badly placed camera will see it constantly.
The IMU bridges the gaps between terrain fixes and provides the attitude the matcher needs to project the image onto the ground correctly. Industrial-grade micro-electromechanical units are now good enough for this role on small aircraft, provided they are well calibrated and thermally stable. What matters more than raw grade is timing: every image frame needs a precise timestamp aligned with the IMU stream, because a small timing error at forward flight speed becomes a real position error on the ground. Most autopilots already carry a reasonable IMU. Whether the navigation payload uses that stream or its own is a design choice, and using its own removes a dependency on the autopilot’s internal timing at the cost of a little mass.
Power, weight and heat
Power and heat are the same problem seen from two sides. Everything the payload draws becomes heat inside an enclosed fuselage, and small fixed-wing aircraft often have no fan and limited airflow. A design that assumes it can dissipate laboratory-bench power levels will throttle or fail in a summer field trial. Choosing components that run cool at the intended workload, and placing them where the airframe already moves air, is a large part of making an onboard system reliable.
Weight is the obvious constraint and the one most often over-engineered. A single-board computer, a compact global-shutter camera, an IMU and a small carrier board can be built into a light package if the enclosure and cabling are treated as seriously as the electronics.
Why off-the-shelf is a design goal
There is an assumption that serious navigation hardware must be custom or exotic. The opposite is true for operators. A system built on widely available embedded modules and industrial cameras can be repaired in the field, replaced without a long lead time, upgraded as new boards arrive and scaled across a fleet without a special supply chain. It also keeps the price within reach of the agriculture, inspection and survey operators who actually fly most of the hours.
Designing for affordable, available hardware forces the software to be efficient rather than relying on brute force. That is a discipline, not a compromise, and it tends to produce systems that are also lighter, cooler and more robust.
Where TerrainSLAM fits
TerrainSLAM is designed to run entirely onboard on affordable off-the-shelf embedded hardware, with no cloud connection, ground station or ROS dependency required. It is optimised for the forward flight and higher speeds of fixed-wing aircraft and is intended to integrate with existing autopilots as a plug-and-play position source, so the hardware decisions above can be made around the airframe rather than around a bespoke computer.