Host Inference
Capture, Preprocessing, YOLO-Inferenz, Confidence-Filter und NMS laufen als getrennte Pipeline-Stufen.
CS / 02Case-Study
Realtime Vision Runtime: hardwarebeschleunigte Computer-Vision-Pipeline
Private Computer-Vision-Plattform für latenzarme Objekterkennung mit austauschbaren Inferenz-Runtimes und einem getrennten Arduino-basierten Hardware-Layer.
Realtime Demo
Inferenz direkt im Debug-Viewport.
Technischer Ausschnitt der privaten RuntimeRealtime inference
Runtime Adapter
TensorRT, ONNX Runtime und OpenVINO bleiben hinter derselben Schnittstelle austauschbar.
Arduino Layer
Strukturierte Ergebnisse werden über ein versioniertes Protokoll an die getrennte Firmware übergeben.
01 / System
Kontext, Problem und Umsetzung.
01 / Kontext
Systemrahmen
Die Case-Study konzentriert sich ausschließlich auf die technische Umsetzung: Capture, Preprocessing, neuronale Inferenz, Postprocessing, Runtime-Auswahl und Hardware-Kommunikation. Produktname, Einsatzzweck, Modelle und betrieblicher Kontext bleiben bewusst privat.
02 / Problem
Ausgangslage
Eine Echtzeit-Vision-Pipeline muss auf sehr unterschiedlicher Hardware niedrige und stabile Latenzen liefern. Capture, Preprocessing, Inferenz und Postprocessing dürfen sich dabei nicht gegenseitig blockieren, und ein fehlendes GPU-Backend darf die Anwendung nicht unbrauchbar machen.
03 / Umsetzung
Technischer Ansatz
Ein standardisierter Frame-Flow verbindet Capture, normalisiertes Preprocessing, YOLO-Inferenz, Confidence-Filter und Non-Maximum Suppression. TensorRT, ONNX Runtime oder OpenVINO führen das Modell auf dem Hostsystem aus und werden passend zur vorhandenen Hardware gewählt. Erst die strukturierten Ergebnisse gehen über ein versioniertes serielles Protokoll an eine eigenständige Arduino-Firmware, die Timing, Gerätekommunikation und Hardware-Ausgabe übernimmt.
04 / Vertiefung
Technischer Fokus
Der belegbare Schwerpunkt liegt auf Echtzeit-Computer-Vision, YOLO-Inferenz, ONNX-Modellformaten, TensorRT-Optimierung, OpenVINO, OpenCV, Provider-Fallbacks, Desktop-UI sowie Arduino-Firmware und einer getrennten seriellen Hardware-Ausgabe. Produktfunktion und Zielkontext bleiben privat.
02 / Decisions
Zentrale technische Entscheidungen.
Nicht nur was gebaut wurde, sondern warum das System genau diese Form bekommen hat.
Mehrere Inferenz-Runtimes hinter einem Adapter.
TensorRT nutzt NVIDIA-Hardware maximal aus, ONNX Runtime deckt CUDA, DirectML und CPU ab, OpenVINO Intel-Systeme. Die fachliche Pipeline bleibt dabei unverändert und damit testbar.
Deterministischer Hardware-Fallback statt harter GPU-Abhängigkeit.
Beim Start werden verfügbare Provider geprüft und nach Eignung gewählt. Fehlt der schnellste Pfad, läuft dieselbe Pipeline kontrolliert auf einem kompatiblen Backend weiter.
Pre- und Postprocessing als eigene Pipeline-Stufen.
Resize, Normalisierung, Tensor-Layout, Confidence-Filter und NMS sind unabhängig vom Modellaufruf. Das erleichtert Profiling, Austausch und reproduzierbare Tests.
Host-Inferenz und Arduino-Firmware bleiben getrennte Systeme.
In dieser Architektur laufen die Modelle im Host-Runtime-Layer. Die Desktop-Anwendung sendet nur strukturierte Ergebnisse an den Arduino; Protokoll, Firmware, Geräteverhalten und Transport lassen sich dadurch unabhängig entwickeln und diagnostizieren.
03 / Delivery
Stack und belegbare Grenze.
Technologien
- Python
- C++
- PyQt6
- OpenCV
- YOLO
- ONNX Runtime
- TensorRT
- OpenVINO
- CUDA
- Arduino
Ehrliche Grenze
Privates proprietäres Projekt. Produktname, konkreter Einsatzzweck, Datensätze, Modellgewichte, Konfigurationen und ausführbare Artefakte werden absichtlich nicht veröffentlicht.
Nächstes Projekt
UnitFly