Autonomous Satellites: AI in Orbit

The default architecture of an Earth observation satellite is dumb on purpose: point the sensor, capture pixels, store them, and wait for a ground station pass to dump everything to Earth, where the actual analysis happens. It is simple and it is wasteful. A satellite in low Earth orbit sees a given ground station for only a few minutes per pass, the downlink is bandwidth-constrained, and a large fraction of every image is cloud, ocean, or empty desert that no one will ever look at. You spend power, storage, and precious downlink shipping garbage to the ground so a server can throw most of it away. Moving the model up to the satellite — running inference in orbit and downlinking only what matters — flips that economics. After years of demonstrations, it is now real, on real hardware, in real missions.

The proof points: Phi-Sat and Pelican#

Two efforts mark the before and after.

ESA Phi-Sat: the first neural net in orbit#

Phi-Sat-1 was a 6U CubeSat flown as part of ESA’s FSSCat mission, launched in September 2020 into a sun-synchronous orbit at roughly 540km. Its job was narrow and exactly right as a first step: detect clouds on board and discard cloud-covered imagery before downlink. The model, a convolutional network called CloudScout, ran on an Intel Movidius Myriad 2 vision processing unit — a commercial edge accelerator never designed for space — and classified cloudy versus clear scenes at around 92% accuracy in orbit. The premise is brutally simple: if two-thirds of an image is cloud, do not waste downlink on it. It was the first demonstration of a deep neural network doing useful inference on an Earth observation satellite, and it worked.

Phi-Sat-2, launched in August 2024 on a SpaceX Transporter rideshare, generalized the idea from a single hard-wired model to a platform: a multispectral camera, a dedicated AI accelerator, and the ability to run multiple on-board applications — cloud detection, deep image compression, vessel and street detection, anomaly detection — and even to upload new models after launch. That last point matters. A satellite whose behavior you can change with a software update, after it is in orbit, is a fundamentally different asset from one whose logic is frozen at integration.

Planet’s Pelican: inference as product#

The commercial proof landed in early 2026. Planet reported that its Pelican-4 satellite ran AI inference in orbit: over Alice Springs, Australia, at roughly 500km altitude, it captured an image of an airport and ran an on-board model on an NVIDIA Jetson Orin module to detect aircraft within moments of capture. The architectural significance is in what came down. Instead of downlinking a full multi-gigabyte frame, the satellite sent compact GeoJSON detections — coordinates and labels — collapsing time-to-insight from hours to minutes and shrinking the downlink payload by orders of magnitude. A satellite tasked to watch a port can return “these three berths changed, this ship moved” instead of the whole scene. That is the difference between selling imagery and selling answers.

Why orbit makes this hard#

None of this is a straightforward edge-deployment problem with a thermal twist. Space removes the assumptions edge AI normally takes for granted.

Radiation#

This is the constraint that dominates everything. Beyond the atmosphere, high-energy particles flip bits and corrupt logic. A single-event upset can silently change a weight in memory or a value mid-computation; a single-event latch-up can destroy the part outright. Radiation-hardened processors exist, but they lag commercial silicon by a decade or more in performance and cost a fortune — useless for running a modern neural network. So the real-world approach is to fly commercial-off-the-shelf accelerators (the Myriad 2, the Jetson Orin) and engineer tolerance around them: pre-flight beam testing — Phi-Sat-1’s VPU was characterized in a proton beam at CERN before launch — plus error-correcting memory, watchdog timers, redundant inference, and aggressive sanity-checking of outputs. You assume the hardware will glitch and design the system to detect and recover, rather than pretending it won’t.

Power, thermal, and compute#

A small satellite operates on tens to low hundreds of watts for everything: payload, radios, attitude control, and any compute you add. There is no convective cooling in vacuum; waste heat leaves only by radiation, so a power-hungry accelerator is also a thermal management problem. This forces hard discipline on the model — quantized, pruned, distilled to run within a power and latency envelope that would be considered severe on the ground. The same engineering muscle behind on-device inference on a phone applies here, with the failure cost raised by several orders of magnitude.

You cannot fix it after launch#

There is no field service in orbit. If a model is wrong, your only recovery channel is a radio link with minutes of contact per pass and strict bandwidth limits. This is why Phi-Sat-2’s uploadable-model capability is a genuine advance: it turns an unfixable asset into a maintainable one. It also raises the bar on validation — you want extreme confidence in a model before it flies, and a safe, well-tested mechanism for updating it once it is up there.

This reframes what “MLOps” means when the deployment target is moving at seven kilometers per second. On the ground, a bad model is a rollback and a postmortem. In orbit, the feedback loop is measured in orbital passes, the bandwidth to ship a new model is a scarce resource you share with the actual mission payload, and you often cannot even observe the failure directly — you infer it from anomalous outputs over a handful of brief contacts. The disciplines that matter become shadow deployment (running the new model alongside the old and comparing before you trust it), staged rollout across a constellation rather than a fleet-wide flip, and telemetry designed so that a small, cheap stream of metrics tells you whether the model is healthy without downlinking its full output. None of that is exotic. It is the same operational rigor any serious production system needs, compressed and hardened by an environment that punishes every shortcut.

Autonomous tasking, not just on-board inference#

Cloud filtering and object detection are the visible wins. The larger shift is autonomy in the loop. A traditional satellite executes a tasking plan computed on the ground hours earlier; it cannot react to what it sees. An on-board model that understands the scene enables the satellite to decide: this area is fully clouded, skip it and save power; this scene contains an anomaly — a fire front, an oil slick, an unexpected vessel — capture at higher resolution and prioritize it for the next downlink. Combine that with inter-satellite links and a constellation starts to behave like a distributed sensing system that allocates its own attention, rather than a fleet of cameras waiting for instructions.

This is the same Operational Automation pattern we apply on the ground — pushing decisions to where the data is born instead of hauling everything back to a central system to be processed later. Whether the edge node is an orbiting sensor, a factory PLC, or a Hospital Management System triaging records at intake, the logic is identical: filter and decide at the source, move only the signal, and keep a human-auditable trail of why each decision was made. The constraints in orbit are just more extreme, which is exactly why the field is a useful proving ground.

There is a second-order consequence worth naming. Once a satellite ships derived detections instead of raw frames, the product changes and so does the verification burden. A buyer who receives “47 aircraft, here are the coordinates” instead of an image cannot independently re-examine the scene later — the evidence was discarded in orbit to save downlink. That is a real tradeoff: bandwidth efficiency bought at the cost of auditability. The mature pattern is hybrid — downlink the compact detections for speed, but retain and selectively return enough raw context to validate the model’s claims and to build the next training set. The same tension shows up in any ground-side AI Implementation that summarizes before it stores: the cheapest pipeline throws away exactly the data you will wish you had kept when someone disputes an output. Designing for that dispute, up front, is the difference between a demo and a system you can defend.

The honest assessment: on-board AI is no longer a demo. It is reducing real downlink volume and cutting real time-to-insight in flying systems today. But it is narrow. These are detection, classification, and filtering models — not general reasoning — operating inside hard power, thermal, and radiation envelopes, on hardware you cannot touch once it leaves the pad. The engineering that makes them work is unglamorous: quantization, error correction, watchdogs, beam testing, and a validation discipline that assumes the environment is actively hostile. That is precisely why it is worth studying. If your AI Implementation has to be right the first time, with no rollback and an adversarial operating environment, the people flying neural networks through a radiation belt have already done the hard thinking.

---

Deploying AI at the edge where you get one shot, no rollback, and a hostile environment? We design for the constraints first and the model second. Talk to our engineers.