Kamera-Radar-Fusion · SiL-Validierung auf nuScenes
Wahrnehmungssystem zur Hinderniserkennung (Kamera + Radar), validiert als Software-in-the-Loop gegen den Realdatensatz nuScenes.
Motivation
In der realen ADAS-Entwicklung entfällt der größte Teil des Aufwands auf das Testen und Validieren von Wahrnehmungssoftware, nicht allein auf deren Entwicklung. Dieses Projekt bildet genau diesen Workflow vollständig ab: von den Anforderungen über die Systemarchitektur bis zu einer automatisierten, anforderungsbasierten Validierungs-Pipeline mit CI/CD.
Der Fokus liegt bewusst auf der Validierung: der Wahrnehmungsalgorithmus (Kamera-Detektion, Radarverarbeitung, Fusion) ist das System under Test; das eigentliche Ergebnis ist eine reproduzierbare Validierungsumgebung mit rückverfolgbaren Anforderungen, automatisierten Metriken und CI/CD.
1 - Systemgrenze & Ansatz
Die Architektur trennt zwei klar abgegrenzte Teile: das System under Test (das Wahrnehmungssystem) und das Test Harness (die Validierungsumgebung). Diese Trennung spiegelt die reale ADAS-Entwicklung wider - die Wahrnehmungssoftware läuft im Fahrzeug, die Validierung läuft offline gegen annotierte Daten.
Das System wird auf aufgezeichneten, human-annotierten nuScenes-Daten validiert:
- Rohdaten (Kamerabilder + Radarpunkte) werden aus nuScenes abgespielt (Replay).
- Die Wahrnehmungs-Pipeline erzeugt eine Liste erkannter Hindernisse.
- Die Detektionen werden gegen die Ground-Truth-Annotationen verglichen.
- Metriken (Recall, Precision, Latenz) werden automatisiert berechnet und dokumentiert.
2 - Architektur (Capella / MBSE)
Die logische Architektur wurde in Capella (Arcadia / MBSE) modelliert. Sie zeigt die beiden getrennten Bereiche und die Component Exchanges zwischen den Blöcken.
| Block | Aufgabe |
|---|---|
| Data Loader | Sensordaten einlesen, Kamera & Radar zeitlich synchronisieren |
| Camera Perception | Objekte im Bild erkennen und klassifizieren |
| Radar Processing | Ziele aus Radarpunkten extrahieren (Distanz, Geschwindigkeit) |
| Fusion | Kamera- und Radardetektionen per Datenassoziation zusammenführen |
| Output | Hindernisliste filtern und strukturiert ausgeben |
| Ground Truth | Referenzobjekte aus nuScenes-Annotationen bereitstellen |
| Validation | Recall / Precision gegen Ground Truth berechnen |
| Metrics Report | Ergebnisse reproduzierbar dokumentieren |
3 - Datenmodell (Design → Code)
Die zwischen den Blöcken ausgetauschten Datenstrukturen wurden zuerst im Design
festgelegt und als Python-dataclasses implementiert und mit Unit-Tests abgesichert.
@dataclass
class DetectedObject:
object_class: str # "car", "pedestrian", ...
x: float # longitudinale Position
y: float # laterale Position
velocity: float # Relativgeschwindigkeit
confidence: float # Detektionskonfidenz 0..1
timestamp: float # zugehöriger Frame4 - Fusion: Datenassoziation
Kamera und Radar können dasselbe reale Objekt erfassen. Die Fusion ordnet Detektionen einander zu, wenn sie im selben Frame liegen und räumlich nah beieinander sind (Distanzschwelle), und übernimmt die Klasse von der Kamera sowie Position/Geschwindigkeit vom Radar : jeder Sensor bringt seine Stärke ein.
5 - Anforderungen & Traceability
Jede Muss-Anforderung ist über einen automatisierten Test rückverfolgbar. Jeder Test ist im Code mit seiner Anforderung markiert (@pytest.mark.requirement("REQ-XX")).
| ID | Anforderung | Zielwert | Status |
|---|---|---|---|
| REQ-08 | Recall für Fahrzeuge < 30 m | ≥ 0,90 | ✅ getestet |
| REQ-09 | Precision (Fehldetektionen begrenzen) | ≥ 0,80 | ✅ getestet |
| REQ-10 | Latenz pro Frame | ≤ 100 ms | 🚧 geplant |
| REQ-12 | Zeitliche Synchronisation Kamera / Radar | gleiche Frame | ✅ getestet |
6 - Projektmanagement
Das Projekt wird mit GitHub Issues und einem Kanban-Board organisiert (Todo / In Progress /
Done), der frei verfügbaren Entsprechung eines Jira-Boards. Entwickelt wird über
Feature-Branches und Pull Requests; main bleibt jederzeit stabil.
7 - Aktueller Stand
| Komponente | Technologie | Status |
|---|---|---|
| Requirements-Spezifikation | ID-basiert, rückverfolgbar | ✅ |
| Systemarchitektur | Capella / MBSE | ✅ |
| Detailed Design | Datenstrukturen, Klassendiagramm | ✅ |
| Blöcke (Loader, Kamera, Radar, Fusion, Output) | Python | ✅ |
| Pipeline-Integration | End-to-End | ✅ |
| Validation & Metriken | Recall / Precision, TP/FP/FN | ✅ |
| Tests | 34 Unit- & Integrationstests (pytest) | ✅ |
| Traceability | Requirement ↔ Test (pytest-Marker + Matrix) | ✅ |
| CI/CD | GitHub Actions | ✅ |
| Git Workflow | Feature-Branches, Pull Requests | ✅ |
| Reale nuScenes-Daten | Anbindung Data Loader + Detektor | 🚧 nächster Schritt |
Hinweis: Die Pipeline ist vollständig implementiert und getestet. Aktuell laufen die Blöcke mit synthetischen Platzhalterdaten; die Anbindung der realen nuScenes-Daten erfolgt, ohne die Architektur zu verändern (Kapselung : nur die Blockinternas werden ersetzt).