Teil 1 dieser Serie zeigte die Grundlagen der Videotachymetrie und ihre Anwendungsgebiete.
Teil 2 betrachtete Bauarten von Vario-Objektiven und den damit bedingten Herausforderungen für photogrammetrische Auswertungen.
Teil 3 bettete diese Herausforderungen wieder in den Kontext der Videotachymetrie ein, insbesondere, wo Vario-Objektive hier mehr ihre Stärken als Schwächen ausspielen können.
Auf diesen Fundamenten geht dieser Teil auf den erstellten Prototypen zu dieser Serie ein. Der Prototyp dient auch für andere Beitragsserien und berücksichtigt daher Anforderungen an die Hardware, die aus den in Teil 3 herausgearbeiteten Einsatzfeldern resultieren.
So wird bewusst keine hochpreisige Optik verwendet, sondern preisgünstige Optik für günstige Geräte im Umfeld von Handwerk.
Als Basis dienen:
- ein IMX477-Board von ArduCAM mit „normaler Aufnahme“ von Optikhaltern nach Pseudostandard
- ein Optikhalter D14
- ein Vario-Objektiv D14 mit Brennweite 5 bis 50mm mit zwei Steppern für Zoom- und Fokus-Regelung
- ein programmierbares SCE2-M-Board von Kurokesu mit einem STM32F103 zur Steuerung und vier Trinamic TMC2300
Gerade bei embedded Vision ist die Hardwareauswahl für die Bild- und Videoverarbeitung von hoher Bedeutung. Keine CPU kann z.B. niedrige Busdurchsätze kompensieren, bei der Energieeffizienz einem Hardware-Encoder nahekommen oder sich mit einem Image Signal Processor messen.
Bei Hardware für embedded Vision sind daher gerade Komponenten wie CSI-Interfaces, ISP, VCU und schnelle, breite Busssysteme zwischen diesen die Grundlage. Die CPU übernimmt quasi nur noch die Koordination, wie ein Dirigent im Orchester. Sie ist nicht Zentrum, die Datenströme werden größtenteils in der Hardware abgewickelt.
Für die Bild- und Videoverarbeitung wird ein Raspberry PI genutzt. Das hat mehrere Gründe. Diese werden folgend genauer erläutert, da manche Entscheidungsträger Raspberry-Produkte immer noch der Maker-Szene zuschreiben.
- Raspberry bedient zwei Märkte parallel, mit jeweils angepassten Produkten. Auch bei den PIs: die „normalen“ Raspberry PIs 1 bis 5 sind für den Maker-Markt, die CMs für den Industriebereich.
- Gerade Raspberry-Produkte haben im Gegensatz zu z.B. NVIDIA sehr lange Liefergarantien bei bereits jahrelanger praktisch nachgewiesener Produktpflege.
- Während die Entwicklung bei NVIDIA zu immer mehr Leistungsaufnahme geht, bietet Raspberry mit seinen Produkten gerade ein gutes Fundament für batterie- und akkubetriebene Geräte mit dem entsprechend reduzierten Energiebedarf.
- Da sowohl Maker- wie Industrieprodukte die gleiche technische Basis haben, fließen Entwicklungen und Kenntnisse des großen Maker-Kreises direkt in den Industriezweig ein. Das sind Vorteile z.B. zu NXP.
- Offener Code und zahlreiche offene Datenblätter sowie umfangreiche Literatur ermöglichen individuelle Anpassungen, ohne vom Handeln des Herstellers abhängig zu werden.
- Durch die große Community fließen Fehlermeldungen und ihre Beseitigung, zur Not auch zunächst über Workarounds, sehr schnell zurück. Das sind Vorteile z.B. zu TI.
Aus den oben genannten Gründen wurden die Kriterien an die Hardwarebegrenzungen vom Autor noch härter gesetzt und statt einem von ihm gern eingesetzten CM3 ein noch leistungsschwächerer Zero 2 W gewählt. Beide besitzen ähnliche SoCs, der Zero 2 W ist aber hinsichtlich Speicher wesentlich begrenzter. Also Tests mit verschärften Bedingungen.
Der Raspberry PI hat einen eigenen ISP am Ende der CSI‑Übertragung. Dieser ist ein Schlüsselbaustein für das Gesamtsystem, da er Funktionen übernehmen kann, welche der Sensor selbst nicht besitzt. Die Videostream-Vorschau kann hierdurch größtenteils durch Hardware abgedeckt werden.
Der IMX477 ist ein 12‑Megapixel-Sensor mit zahlreichen Funktionen. Er wird in 3 verschiedenen Modi genutzt:
| Modus | Genutzter Sensorbereich | Sensorinterne Verarbeitung | Ausgabe über CSI-2 |
|---|---|---|---|
| Livebild 1× – Gesamtansicht | 4056 × 3040 | 2×2-Binning | 2028 × 1520 Bayer-RAW, 12 Bit |
| Livebild 2× – Zentralausschnitt | Zentrische 2028 × 1520 | 1×1, kein Binning | 2028 × 1520 Bayer-RAW, 12 Bit |
| Fokuskalibrierung und Einzelbild | 4056 × 3040 | 1×1, kein Binning | 4056 × 3040 Bayer-RAW, 12 Bit |
Durch die ersten beiden Modi wird bei gleichbleibender Auflösung des Videostreams ein digitaler Zoom realisiert. Anmerkung: hier kam wieder der Vorteil von FOSS zum Tragen. Der zentrische 2028×1520‑Modus ist im offiziellen Kernel-Treiber nicht vorgesehen, konnte aber wegen des offenen Codes einfach ergänzt werden.
Der letzte Modus dient für photogrammetrisch zu verwertende Einzelbildaufnahmen.
Der Videostrom bzw. die Einzelbilder werden per CSI-Lines zum ISP des Raspberry PI übertragen.
Dieser wird in den folgenden Modi genutzt:
| Modus | Format und Auflösung | Verwendung |
|---|---|---|
| Livebild | NV12, 1280 × 960 | Vorschau; anschließend H.264-Kodierung |
| Fokuskalibrierung | YUV420, 4056 × 3040 | Schärfemessung aus der Y-Ebene |
| RGB-Einzelbild | RGB888 oder BGR888, 4056 × 3040 oder Ausschnitt | PNG oder unkodierte RGB-Daten |
| Graubild-Einzelbild | Y-Ebene aus YUV420, 4056 × 3040 oder Ausschnitt | PNG oder unkodierte Graudaten |
| RAW-Pfad – kein ISP-Ausgabemodus | Bayer-RAW12, 4056 × 3040 | DNG oder unkodierte RAW-Daten; RAW-Ausschnitte werden in Software erstellt |
Der Sinn der einzelnen Modi wird in den nächsten Teilen dieser Serie an den betreffenden Stellen erläutert. An dieser Stelle: der erste Modus dient dem Live-Videostream. Die Frames mit einer Auflösung von 2028×1520 im RAW 12 Bit Format werden vom ISP in 1280×960 NV12 umgerechnet, also einschließlich Debayering und Formatwechsel.
Anschließend werden die Frames vom ISP via DMA an den Hardware-Encoder weitergereicht, der komprimierte Stream anschließend an den Netzwerktreiber. Der Raspberry PI überträgt den Live-Videostream auf diese Weise per UDP-Paketen via RTP zur Endanwendung. Die Bilddaten werden dabei über DMA-BUF zwischen den Hardware- und Softwarekomponenten geteilt, ohne die Frame-Daten zwischen den Verarbeitungsschritten kopieren zu müssen. Damit bleibt der Videopfad Zero-Copy.
Die Endanwendung steuert die Firmware über eine parallele TCP-Verbindung, über welche auch Einzelbilder für photogrammetrische Verwertung übertragen werden.
Dabei wird eine klare Aufgabenverteilung eingehalten: Das embedded Device realisiert den Videostream effizient per möglichst viel Hardware. Rechenaufwendige Aufgaben laufen dagegen auf der Hardware des Endgerätes. Auch diese Entscheidung resultiert wieder aus dem im Teil 3 erarbeiteten Anwendungsgebiet. Ein Vermessungsgerät als quasi „Sensor“ kann jahrelang eingesetzt werden, der Nutzer profitiert aber gleichzeitig von der schnellen Entwicklung der Leistungsfähigkeit der Endgeräte.
Im nächsten Teil geht es mit diesen Grundlagen dann an die „erste Treppenstufe“ der statistischen Tests, der Fokussierung.