Eine Computer-Vision-Pipeline auf einer ISR-Drohne hat eine Aufgabe: Photonen, die auf einen Sensor treffen, in geo-lokalisierte Tracks relevanter Objekte zu verwandeln und diese Tracks schnell genug an ein Führungs- und Kontrollsystem zu schicken, dass ein Operator — oder ein anderes System — darauf reagieren kann. Alles andere ist Engineering-Overhead im Dienst dieser Schleife. Dieser Artikel geht die Pipeline Ende zu Ende durch: die Modellarchitekturen, die detektieren, die Algorithmen, die tracken, die Sensor-Fusion, die Nacht und Wetter überlebt, die Georeferenzierungs-Mathematik, die einen Bounding-Box nützlich macht, und die Edge-Deployment-Realitäten, die entscheiden, ob irgendetwas davon im Feld funktioniert.

Für den breiteren Kontext, wo das in den Verteidigungs-KI-Stack passt, siehe unseren vollständigen Leitfaden zu KI in der Verteidigung und die Sensor-Edge-Analyse in Sensor-zu-Schütze Teil 2.

1. Die ISR-CV-Pipeline

Die kanonische Pipeline hat sechs Stufen: Sensorerfassung (EO und IR), Frame-Ingest und -Synchronisation, Detektion, Multi-Objekt-Tracking, Georeferenzierung und C2-Push. Ende zu Ende liegt das Budget auf einer taktischen ISR-Plattform bei etwa 150–250 ms Wanduhrzeit vom Photonenankommen bis zum Track-Update auf der C2-Oberfläche. Alles über 300 ms bricht das Operator-Vertrauen — ein Fahrzeug bei 60 km/h legt in 300 ms 5 Meter zurück.

Die Budget-Aufschlüsselung auf einer typischen Jetson-Orin-NX-Klasse-Plattform: 16–33 ms für die Erfassung (je nachdem, ob der Sensor mit 30 oder 60 fps läuft), 5–10 ms für ISP und Demosaicing, 15–40 ms für den Detektor-Forward-Pass, 3–8 ms für die Tracking-Assoziation, 10–20 ms für Georeferenzierungs-Mathematik und 20–80 ms für den Funklink zu C2. Der Funk ist meist der schlimmste Übeltäter und der, den der CV-Ingenieur nicht reparieren kann. Alles On-Board muss komprimieren, um das zu kompensieren.

Frame-Ingest-Synchronisation zählt mehr, als Anfänger erwarten. EO- und IR-Sensoren teilen sich selten einen Frame-Takt. Wenn Ihre Fusion-Logik annimmt, dass sie es tun, fusionieren Sie das EO-Pixel eines Ziels bei t mit dem IR-Pixel bei t-16 ms — ein Fahrzeug bei 30 m/s hat sich einen halben Meter bewegt. Die Pipeline muss am Sensor zeitstempeln, nicht am Konsumenten.

2. Detektionsarchitekturen

Der Detektor ist die dominante Compute- und Genauigkeitsentscheidung in der Pipeline. Drei Familien sind derzeit auf ISR-Drohnen relevant.

YOLOv8, v10, v11. Die konvolutionale YOLO-Linie bleibt das Arbeitstier — Ultralytics' YOLOv8 und die neueren YOLOv10 und v11 liefern 30–60 fps bei 640×640 auf Jetson Orin NX mit INT8-Quantisierung. YOLOv11n (Nano) erreicht ~60 fps bei akzeptabler mAP auf Luftbilddatensätzen; YOLOv11s (Small) tauscht zu ~30 fps mit materiell besserem Small-Object-Recall. YOLOv10 entfernt den NMS-Schritt vollständig und spart 3–5 ms Nachverarbeitungslatenz, was zählt, wenn jede Millisekunde umkämpft ist.

RT-DETR. Baidus Echtzeit-DETR ist die Transformer-Alternative — ein abfragebasierter Detektor, der NMS per Design überspringt und einen festen Satz von Objektabfragen erzeugt. In Benchmarks erreicht oder übertrifft RT-DETR-L YOLOv8-L mAP auf COCO bei vergleichbarer Latenz. Bei Luftbildern bewältigt das Transformer-Attention-Muster oft dichte Small-Object-Szenen (geparkte Fahrzeuge, Infanterie-Cluster) besser als konvolutionale Anker-basierte Detektoren. Die Kosten sind ein größeres Modell und kniffligere INT8-Quantisierung — Transformer-Attention-Layer degradieren unter aggressiver Quantisierung stärker als Conv-Layer.

Das Small-Object-Problem. Eine ISR-Drohne auf 1500 m AGL mit 30° HFOV sieht eine Person als etwa 6–10 Pixel auf einer Seite. Standard-Objektdetektoren, die auf COCO-artigen Bildern trainiert sind (wo Objekte typischerweise >32 Pixel sind), versagen in diesem Regime schlecht. Die beiden praktischen Lösungen sind Tiling (den Frame in überlappende 640×640-Patches aufteilen, Inferenz pro Patch laufen lassen, im Bildraum abgleichen) und Training auf luftbild-spezifischen Datensätzen — VisDrone, DOTA, xView und zunehmend domänenspezifische synthetische Daten. Siehe unseren Artikel über synthetische Daten für Verteidigungs-KI-Training für die Pipeline.

3. Tracking-Algorithmen

Detektion gibt Ihnen Bounding-Boxen pro Frame. Tracking verwandelt diese in identitätsstabile Tracks über die Zeit — was ein C2-System tatsächlich braucht. Die dominanten On-Board-Optionen sind BYTETrack, StrongSORT und OC-SORT.

BYTETrack. Billig, schnell und überraschend robust. BYTETracks Erkenntnis ist, dass Niedrig-Konfidenz-Detektionen — die die meisten Tracker verwerfen — meist echte Objekte sind, die teilweise verdeckt oder vorübergehend mehrdeutig sind. Indem zuerst Hoch-Konfidenz-Detektionen assoziiert werden und dann Niedrig-Konfidenz-Boxen in einem zweiten Durchlauf gegen ungematchte Tracks abgeglichen werden, erholt BYTETrack Tracks, die reine IoU-Assoziationsmethoden verlieren. Auf einem Jetson Orin NX fügt der Tracker <5 ms pro Frame hinzu.

StrongSORT. Eine Evolution von DeepSORT — Kalman-Filter für Bewegung plus Re-Identifikations-Erscheinungs-Embedding. Besser bei ID-Switch-anfälligen Szenen (Fahrzeuge, die einander passieren, Okklusion unter Baumdecke), aber das Erscheinungs-Embedding-Netzwerk fügt 8–15 ms pro Frame hinzu und braucht eigene Trainingsdaten. Die Kosten lohnen sich, wenn ID-Stabilität mehr zählt als Durchsatz, zum Beispiel beim Konvoi-Tracking.

OC-SORT. Observation-Centric SORT adressiert ein spezifisches BYTETrack/SORT-Versagen: Wenn ein Objekt mehrere Frames lang verloren geht, driftet die Geschwindigkeitsschätzung des Kalman-Filters. OC-SORT re-schätzt die Geschwindigkeit aus der Beobachtung bei Re-Identifikation, anstatt der Filtervorhersage zu vertrauen. Auf ISR-Aufnahmen mit häufiger Okklusion (städtische Umgebungen, Waldrand) reduziert OC-SORT messbar ID-Wechsel gegenüber BYTETrack.

Das Wackelplattform-Problem. Alle diese Tracker nehmen an, dass die Kamera-Frame-Bewegung eines Objekts von der Objektbewegung dominiert wird. Auf einer Drohne in turbulenter Luft trägt Eigenbewegung den meisten der scheinbaren Pixelgeschwindigkeit bei. Die Lösung ist, in einem stabilisierten oder Welt-Frame zu tracken: entweder vorstabilisierte Frames in den Tracker einspeisen (homographie-basierte De-Rotation gegen die IMU) oder den Kalman-Filter in georeferenzierten Koordinaten laufen lassen statt in Bildkoordinaten. Letzteres ist mehr Arbeit, erzeugt aber dramatisch sauberere Tracks.

4. EO+IR-Sensor-Fusion

Eine reine EO-ISR-Drohne ist eine Tagesplattform. Eine reine IR-Drohne löst Wärmequellen auf, kann aber die Kennzeichnungen eines Fahrzeugs nicht lesen, Personal auf Distanz nicht zuverlässig zählen oder ähnlich-temperierte Decoys unterscheiden. Operatives ISR erfordert beides — und erfordert, dass sie fusionieren.

Späte Fusion betreibt unabhängige Detektoren auf EO- und IR-Streams und gleicht Tracks nachgelagert ab. Einfacher zu entwickeln, scheitert anmutig, wenn ein Sensor degradiert, verliert aber das kreuzmodale Signal — ein schwacher EO-Kontakt, verstärkt durch eine klare IR-Signatur, sollte einen Hoch-Konfidenz-Track erzeugen, und späte Fusion behandelt das unbeholfen.

Frühe Fusion stapelt EO- und IR-Kanäle in einen einzigen Tensor und trainiert einen Detektor über die kombinierte Eingabe. Bessere kreuzmodale Performance, erfordert aber ausgerichtete Daten — was Boresight-Kalibrierungsdisziplin erfordert. EO- und IR-Optiken teilen sich selten ein Boresight; sie brauchen Per-Flugzelle-Kalibrierung (typischerweise eine Schachbrett- oder Hot-Target-Kalibrierung vor dem Flug) und Re-Kalibrierung nach jedem Wartungsereignis.

Tag-Nacht-Übergabe. Der ausfallanfälligste Moment ist Dämmerung und Morgendämmerung, wenn der EO-Kontrast kollabiert, aber die IR-Szene ebenfalls am minimalen Thermalkontrast ist (alles ist bei Umgebungstemperatur). Eine gute Fusion-Pipeline gattert die Pro-Sensor-Konfidenz durch szenenweite Metriken — bildweiten Kontrast, Histogramm-Statistiken — und gewichtet die fusionierte Detektion entsprechend neu, anstatt einer festen Frühfusionsgewichtung 24 Stunden am Tag zu vertrauen.

5. Georeferenzierung bei Bildrate

Ein Bounding-Box in Pixelkoordinaten ist für ein C2-System nutzlos. Der Bounding-Box muss auf eine geografische Koordinate (Breitengrad, Längengrad, Höhe) projiziert werden, mit einer Fehlerellipse. Die Mathematik beinhaltet: die Position der Drohne (GPS, oft INS-fusioniert), die Lage der Drohne (IMU), die Gimbal-Pose relativ zur Flugzelle (Gimbal-Encoder), die Kamera-Intrinsics (Brennweite, Hauptpunkt) und ein Geländemodell (idealerweise ein DTED Level 2 oder besseres DEM), um den Pixelstrahl auf den Bodenschnitt zu entprojizieren.

Zwei praktische Realitäten. Erstens: Georeferenzierungslatenz konkurriert mit Detektionslatenz. Eine naive Implementierung, die Gimbal-Encoder und IMU zum Zeitpunkt des C2-Pushes liest, führt einen 50–100-ms-Fehler gegen den tatsächlichen Frame-Zeitstempel ein — bei 30 m/s Bodengeschwindigkeit sind das 1,5–3 Meter Positionsfehler. Encoder- und IMU-Samples müssen zeitgestempelt und auf die Belichtungsmitte des Frames interpoliert werden.

Zweitens: das Fehlerbudget. Bei 1500 m Schrägbereich mit 0,5° Gimbal-Pose-Unsicherheit beträgt der bodenprojizierte Fehler etwa 13 Meter, bevor Sie GPS-Unsicherheit, Geländemodellfehler und Timing-Schief hinzufügen. Der realistische CEP für ein gut entwickeltes taktisches System ist 15–25 Meter bei typischen ISR-Höhen. Alles, was enger gemeldet wird, ist entweder heroisches Engineering oder Wunschdenken.

6. Modellauswahl für Edge-Deployment

Die Compute-Plattform schränkt alles ein. Die aktuellen ISR-Drohnen-Klassen-Optionen:

Jetson Orin Nano (8 GB) — ~40 TOPS INT8, geeignet für YOLOv8n/v11n bei 640×640 plus einen leichten Tracker. Leistungshülle 7–15 W. Gut für Group-1/2-Plattformen, bei denen die Flugzelle nicht mehr dissipieren kann.

Jetson Orin NX (16 GB) — ~100 TOPS INT8. Lässt YOLOv11s komfortabel bei 60 fps laufen, RT-DETR-R18 bei ~30 fps, StrongSORT mit Erscheinungs-Embedding. 10–25 W. Der aktuelle Sweet Spot für taktisches ISR.

Jetson AGX Orin (32/64 GB) — ~275 TOPS INT8. Lässt größere Modelle laufen, Multi-Stream (EO+IR gleichzeitig, ohne die GPU zu teilen) und lässt Spielraum für zusätzliche CV-Aufgaben (Change Detection, Klassifikationsköpfe). 15–60 W — meist eine Group-3-Plattform-Entscheidung.

INT8-Quantisierungs-Realitäten. Float32 → INT8 liefert typischerweise 3–4× Inferenz-Speedup und 4× Speicherreduktion bei 0,5–1,5 mAP-Verlust auf gut quantisierten Detektoren. Die Fallstricke: Transformer-Attention quantisiert schlechter als Konvolutionen; Kalibrierungsdaten müssen repräsentativ für Deployment-Bilder sein (auf COCO kalibrieren und auf thermalem IR deployen ist Kunstfehler); und einige benutzerdefinierte Layer fallen auf FP16 zurück und verlieren still den Speedup. Unser ONNX/TensorRT-Optimierungsleitfaden deckt die Toolchain ab.

TensorRT vs. ONNX Runtime. Auf Jetson ist TensorRT die richtige Antwort für die Produktion — Engine-Builds auf die exakte GPU-SM-Anzahl getunt, INT8-Kalibrierungs-Pipelines ausgereift, Kernel-Fusion aggressiv. ONNX Runtime mit dem TensorRT-Execution-Provider ist für die Entwicklung akzeptabel und liefert 80–90 % der TensorRT-nativen Performance bei einfacherer Deployment-Story. Reines CUDA EP verliert 30–50 %.

7. Echtzeit-Ausgabe an C2

Das Produkt der Pipeline ist ein Stream von geo-lokalisierten, identitätsstabilen Tracks plus dem Full-Motion-Video, das sie erzeugt hat. Die interoperablen Formate sind wohldefiniert.

CoT (Cursor-on-Target). XML-basiertes Ereignisformat, von MITRE entwickelt, die Lingua Franca von TAK-Ökosystem-C2 (ATAK, WinTAK, iTAK). Ein CoT-Ereignis kodiert einen Punkt (lat/lon/Höhe mit Fehlerellipse), einen Typ-Code (z. B. a-h-G-U-C-I für eine feindliche Bodeneinheit) und freien Detail. Eine Drohne, die alle 0,5–1 s pro getracktem Objekt CoT publiziert, integriert sich nativ mit Operator-Anzeigen.

MISB 0903 VMTI. Video Moving Target Indicator — der NATO/MISB-Standard zum Einbetten von Detektions- und Track-Metadaten in KLV neben Full-Motion-Video. Ein VMTI-Paket innerhalb des MISB-0601-kodierten MPEG-TS-Streams trägt Pro-Frame-Ziellisten mit georeferenzierter Position, Geschwindigkeit und Konfidenz. Erforderlich für jede Plattform, die in NATO-Klasse-1-ISR-FMV-Konsumenten eingesteckt werden muss.

Message-Bus-Muster. Innerhalb der Flugzelle tragen ROS 2, Zenoh oder MQTT Zwischenmessages zwischen dem Detektor, dem Tracker, dem Georeferenzierer und dem Funk-Downlink-Prozess. Zenohs Pub-Sub-Query-Modell behandelt intermittierende Links gut — der Funk fällt aus, der On-Board-Store-and-Forward hält Tracks und der C2-Client holt bei der Reconnect auf.

8. Feldrealitäten

Alles Obige ist der einfache Teil. Der schwierige Teil ist, es im Feld funktionsfähig zu halten.

Vibration. Ein 2-kg-Quadcopter bei Vollgas vibriert die Kamerahalterung bei 100–200 Hz. Rolling-Shutter-Sensoren verschmieren; Global-Shutter-Sensoren tun das nicht, kosten aber mehr und dissipieren mehr. Detektor-Genauigkeit auf bewegungsverschwommenen Bildern fällt um 5–15 mAP-Punkte, es sei denn, der Trainingssatz enthält bewegungsverschwommene Samples.

Thermisch. Ein Jetson Orin NX, der bei 100 TOPS läuft, dissipiert 20+ W in einer versiegelten Nutzlast, die selbst bei +45 °C in direkter Sonne sein kann. Ohne aktive Kühlung greift thermisches Throttling innerhalb von 90 Sekunden ein — und eine gedrosselte GPU lässt die Detektor-fps um 40–60 % fallen. Die Auslegung des Nutzlast-Thermalenvelopes ist ebenso eine CV-Engineering-Sorge wie die Modellwahl.

Niedrigenergiemodi. Eine kreisende ISR-Mission möchte vielleicht den Detektor bei 5 fps während des Transits und 60 fps über dem Interessensgebiet laufen lassen und so die durchschnittliche Leistung um 4–5× senken. Die Pipeline muss Per-Stage-Power-Gating unterstützen — nicht nur GPU-Takte, sondern Sensor-Bildrate, ISP-Pfad und Funk-Tastverhältnis. Siehe KI-ISR-Daten-Triage für die On-Board-Filterseite.

Modell-Degradierung über das Deployment hinweg. Ein Detektor, der auf europäischen Sommerbildern trainiert und in -20 °C baltischem Winter eingesetzt wird, sieht eine andere Welt: schneebedecktes Gelände-Reflektanz ändert EO-Statistiken; kalte Motoren emittieren weniger IR; Laubwerk, das im Juli Fahrzeuge versteckte, ist im Februar laublos. Die realistische Minderung ist kontinuierliche Evaluierung gegen neu gesammelte Daten und eine Re-Training-Kadenz in Wochen, nicht das einmalige Trainings-und-Deploy-Modell, das Laborarbeit annimmt.

Eine ISR-Drohnen-CV-Pipeline ist kein Modell — sie ist ein System. Das Modell ist der kleinste Teil. Das Latenzbudget, die Kalibrierungsdisziplin, das C2-Message-Format, das Thermal-Design und die Re-Training-Kadenz sind, was entscheidet, ob das System für den Operator am anderen Ende des Funklinks funktioniert.