That flexibility is real, but it moves several familiar server problems onto an aircraft with a battery, a flight controller and an unreliable network. Service startup time, storage health, CPU load, thermal throttling, container state and link latency become part of the mission engineering problem.
The paper, published online in September in AEÜ - International Journal of Electronics and Communications, is valuable because it includes hardware and field trials rather than stopping at an architecture diagram. It also makes an important distinction between terrestrial Narrowband IoT and satellite NB-IoT: the first was tested on real UAV flights, while the satellite path was validated on a ground testbed using real LEO satellite hardware.
The useful idea is deployable services, not Kubernetes for its own sake
Companion computers are already common on more capable drones. ArduPilot's documentation describes the standard pattern clearly: a small computer communicates with the autopilot over MAVLink, receives vehicle data and can make application-level decisions such as triggering a camera or processing an advanced sensor.
The service-centric paper pushes that pattern further. Its companion computer is not assigned one permanently installed application. K3s, a lightweight Kubernetes distribution, provides an orchestration layer so containerized services can be deployed to the aircraft as workloads.
That changes the unit of integration. A conventional custom drone often couples the airframe, payload and application into one tested software image. Updating the application can mean rebuilding and retesting that image. A containerized design can package an inference service or data-processing task separately and deploy it when needed.
For fleets that share hardware but perform different jobs, the attraction is straightforward. The same aircraft could host one application for crop analysis, another for infrastructure inspection and another for emergency sensing without every mission becoming a bespoke operating-system build.
The cost is that orchestration becomes part of the aircraft's dependency graph. The question stops being only "does the application work?" and becomes "does the service start, stay healthy and fail safely while the vehicle is moving?"
Keep the flight controller outside the service scheduler
The strongest architectural boundary in this kind of system is the one between flight-critical control and application computing.
The prototype uses a Pixhawk 4 flight controller alongside the Raspberry Pi 5. That separation matters. A container runtime can restart a crashed workload, reschedule a service or consume a burst of CPU and storage I/O. Those are useful behaviors on a server. They are poor substitutes for deterministic attitude stabilization.
A sensible service-centric drone therefore keeps the fast control loops, estimator and basic failsafes on the autopilot. The companion computer should request higher-level actions through an explicit interface rather than own the control loop simply because it has more compute.
The paper's NB-IoT path demonstrates bidirectional traffic, including AI inference results, telemetry and commands such as waypoint updates and mode changes. That makes command authority an engineering issue, not just a networking issue. A remote service able to influence the mission needs clear limits on which commands it may issue, how old a command may be before it is rejected, and what happens if the application or link disappears halfway through a transaction.
MAVLink makes companion-computer integration practical, but it does not remove the need to define trust and responsibility between the two computers. A service restart should not leave the flight controller waiting for state that will never arrive. A companion-computer reboot should be a recoverable subsystem failure, not a reason for the aircraft to lose basic flight stability.
K3s has a measurable resource floor
"Lightweight Kubernetes" is still software that needs CPU, memory and storage.
K3s currently lists a minimum of two CPU cores and 2 GB of RAM for a server node, while an agent can be smaller. Its own resource profiling shows that a single-node K3s server with a workload can consume roughly 1.6 GB of memory in the tested configurations. The Raspberry Pi figures in that profiling are from a Pi 4 rather than the Pi 5 used in the UAV paper, so they should be read as a resource-order reference, not a direct measurement of the prototype.
Storage deserves equal attention. K3s warns that its database is sensitive to disk performance and recommends SSD storage when possible. That advice becomes more consequential on an aircraft. A microSD card that is acceptable for bench development may see repeated logging, container-image extraction, database writes and abrupt power loss in field use.
The companion computer also consumes flight energy. Raspberry Pi recommends a 27 W USB-C power supply for Raspberry Pi 5. That is a supply recommendation, not a claim that the board continuously draws 27 W, but it illustrates the power envelope the integration has to support. Add a modem, storage, cooling and payload sensors and the compute stack becomes a non-trivial electrical load.
For a drone, the right measurement is not only average watts on the bench. It is energy per mission under the actual workload, including inference bursts, radio transmission, service startup and thermal management. If a compute-heavy service shortens reserve time by several minutes, that effect belongs in the flight plan.
The terrestrial NB-IoT result is encouraging, but narrow
The field result that deserves the most attention is also the easiest to overgeneralize.
During real outdoor UAV flights, the authors report 0% packet loss across 324 terrestrial NB-IoT messages and end-to-end latency of 1 to 2 seconds. The link carried bidirectional traffic, including AI inference results and command reception.
That is useful evidence that NB-IoT can provide a low-rate fallback path when a broadband link is unavailable. It is not evidence that NB-IoT should replace the primary command-and-control link for every mission.
One to two seconds is already a long interval for some interactive control tasks. NB-IoT is better matched to telemetry, status, sparse commands and compact inference results than to live piloting or video. The 324-message sample also describes the tested network, route, coverage and traffic conditions. It does not establish a general packet-loss rate for other operators or locations.
The satellite result needs an even sharper boundary. The paper validates non-terrestrial NB-IoT using a ground-based testbed with authentic 5G LEO satellite hardware and store-and-forward behavior. It was not an in-flight satellite trial. That distinction matters because an airborne installation adds antenna orientation, airframe shadowing, motion, power constraints and changing geometry.
The operational lesson is still useful: a very low-rate path can preserve a small set of mission functions after broadband disappears. But "fallback" should be defined by the functions it must carry. Telemetry continuity, a safe mission abort and a waypoint update have different latency and reliability requirements.
Containers create new failure states worth testing deliberately
Containerization can make application deployment cleaner, but it adds failure modes that do not exist on a single-purpose firmware image.
A field test plan for a service-centric aircraft should include at least these cases:
- the application container crashes while the aircraft is in mission;
- K3s restarts the workload but the service comes back with empty or stale state;
- the companion computer reboots while the autopilot remains healthy;
- storage is full or becomes read-only;
- a container image is corrupt or incompatible with the currently deployed sensor driver;
- CPU or memory pressure delays application output;
- the Pi thermally throttles during a long hover in hot weather;
- the broadband link disappears and only the low-rate fallback remains;
- a delayed network command arrives after its operational context has expired;
- the remote service is unavailable even though the radio link itself is still up.
The point is not that containers make the aircraft unsafe. The point is that container orchestration changes what "system healthy" means. A vehicle can be flying normally while its mission service is dead. Conversely, a healthy application can be producing good output while the network path needed to deliver that output has failed.
Those states need explicit observability. The ground station should know whether it is looking at an aircraft fault, an application fault or a communications fault.
Service updates need a rollback rule
Dynamic deployment is one of the architecture's main benefits, so update control deserves more attention than it usually gets in a lab prototype.
A container image can be versioned and rolled back more cleanly than a hand-installed application. That helps reproducibility. It also creates the possibility of changing mission software close to flight time, or potentially while the aircraft is operating.
For production use, the safer pattern is to separate "technically deployable" from "approved to deploy." An image should carry a known version, compatible hardware and sensor requirements, resource limits and a tested rollback target. The aircraft should be able to reject a service whose requirements exceed the available CPU, memory, storage or interface version.
This is where Kubernetes concepts can help rather than merely add overhead. Health checks, resource limits, immutable images and declarative deployment state give engineers tools to make software state visible. They do not prove that the workload is safe for flight. That still requires domain-specific testing.
Measure recovery, not only nominal performance
The paper demonstrates that the architecture can run services onboard and maintain low-rate connectivity in the tested conditions. The next engineering step is to characterize recovery behavior.
For a practical UAV edge node, the most useful acceptance metrics would include:
- time from power-on to flight-ready and service-ready states;
- CPU, memory, storage and temperature margins during the heaviest application workload;
- companion-computer energy consumption over a representative mission;
- time to detect and restart a failed service;
- effect of a service restart on mission state and duplicate commands;
- autopilot behavior when MAVLink traffic from the companion computer stops;
- command expiry and deduplication across a delayed NB-IoT link;
- time to fall back from broadband to NB-IoT and back again;
- safe behavior when the fallback link cannot deliver a command;
- reproducible rollback from a bad application image.
Those measurements turn an interesting compute architecture into an aircraft integration specification.
A drone edge node is useful when failure boundaries stay clear
The paper's strongest contribution is not the novelty of running K3s on a Raspberry Pi. The useful part is showing that a civilian UAV can host deployable application services and still keep a conventional autopilot at the center of flight control, while a low-rate network provides a separate fallback communications path.
That architecture can make one airframe more reusable across missions. It can also make software operations more disciplined because services become versioned deployment units instead of ad hoc scripts copied onto a companion computer.
The trade-off is a larger failure budget. Compute, storage, orchestration and fallback connectivity all become systems that can degrade independently. The design is credible when each layer has a bounded responsibility, a visible health state and a tested failure response.
For builders, the practical question is therefore not whether Kubernetes can run on a drone. The paper shows that it can. The harder question is whether the aircraft remains predictable when Kubernetes, an application service or the network does not.