Maschinelles Sehen Embedded-Vision für intelligente Dinge

Wissenschaftler und Ingenieure arbeiten bereits seit Dekaden an neuen Bildverarbeitungstechnologien. Sie entwickeln neue Algorithmen, damit Computer immer besser »sehen« können. Erste Applikationen für maschinelles Sehen analysierten schnell bewegte Objekte und untersuchten sie auf Produktfehler.

Durch den kontinuierlichen Fortschritt bei Bildsensoren, Rechenleistung und Leistungsaufnahme sowie bei Computeralgorithmen und maschinellem Lernen haben Vision-Systeme heute aber ein deutlich höheres Leistungsniveau erreicht. Kombiniert man diese computerbasierten Vision-Technologien mit aktuellen Embedded System Plattformen, entstehen Embedded Vision Systeme, deren Verbreitung in den nächsten Jahren rasant fortschreiten wird. Es wird Lösungen für besonders lichtschwache Umgebungen oder für extrem hohe Auflösungen geben; und High-End Applikationen werden mit speziell entwickelten Recheneinheiten bestückt sein, die Deep-Learning-Algorithmen ermöglichen. Hieraus entstehen viele neue Anwendungsfelder und Produkte mit visuellem Input für den Konsumermarkt, die Automotive-Industrie, das Gesundheitswesen, die Heim- und Gebäudeautomatisierung, Industrie 4.0 sowie die öffentliche Sicherheit. 

Neue Möglichkeiten 

Durch das Internet der Dinge und durch die Aussicht, dass Milliarden Geräte vernetzt werden, vollzieht sich derzeit auch in der Elektronikindustrie ein drastischer Wandel. Über das IoT sollen Geräte aller Art intelligent werden und sich von überall auf der Welt benutzen lassen. Doch was ist Intelligenz bei Geräten? Geräte gelten in der Regel dann als intelligent, wenn sie unser Leben deutlich vereinfachen. Ein Beispiel unter vielen, was möglich wird, ist eine automatische Bewohnererkennung über Videotelefon mit personenbezogenem Einlass in ein Gebäude. Intelligente Geräte sind zudem in der Regel umso nützlicher, je mehr sie mit der physischen Welt interagieren können. Visuelle Daten/Bilder sind hierbei besonders nützlich: Sie bieten besonders umfassende Informationen und helfen Systemen enorm, mit der physischen Umgebung angemessen interagieren zu können. Ein klassisches Beispiel ist die Robotik, die schon von jeher Bildsensoren nutzt. Das Eingangssystem Bildsensor hilft den Robotern, das Ausgabesystem Motor effizient zu steuern.


Neueste Weiterentwicklungen des maschinellen Lernens wie Convolutional-Neural-Networks – deutsch auch faltendes neuronales Netzwerk genannt – und weitere neuronale Netzwerktechnologien ermöglichen es zudem, selbstlernende intelligente Vision-Systeme zu entwickeln.
 

Neue Herausforderungen

Mit all diesen Innovationen haben Embedded-Vision-Systeme das Potenzial, für nahezu jeden Teilmarkt der Elektronik enorme Mehrwerte zu bieten. Durch den kontinuierlichen Fortschritt bei Hard- und Software wird der Gesamtmarkt auch schnell weiter wachsen. Allerdings ist die Entwicklung von Embedded-Vision-Applikationen auch mit zahlreichen Herausforderungen verbunden.

Rohdaten von Bildern und Videos müssen ihrer Qualität entsprechend auch optimiert und verarbeitet werden. Hat die Linse beispielsweise keine ausreichende Qualität, wirkt sich das negativ auf das gesamte Bildverarbeitungselement aus. Die erfassten Bilddaten können auch enorm groß ausfallen – insbesondere bei der Echtzeitverarbeitung von Videos mit hoher Auflösung. Die meisten Bildverarbeitungsapplikationen im High-End-Bereich benötigen deshalb parallele Verarbeitungssysteme oder dedizierte Hardware wie beispielsweise General-Purpose-Graphics-Processing-Units (GPUs), Digitale Signalprozessoren (DSPs), Field-Programmable-Arrays (FPGAs) oder Co-Prozessoren. Gleichzeitig müssen Embedded-Vision-Systeme aber auch oft strikte Grenzen hinsichtlich Kosten, Baugröße und Leistungsaufnahme einhalten. Eine High-End-Verarbeitungseinheit, die die erforderliche Rechenleistung zwar bietet, kann also sowohl zu teuer als auch zu energiehungrig sein.

Wichtig ist zudem, dass Embedded-Vision-Systeme für den Einsatz unter realen Bedingungen entwickelt sind. Sie müssen also auch bei sich ständig verändernden Lichtverhältnissen, Bewegungsgeschwindigkeiten und -richtungen zuverlässig arbeiten. Um die Daten solcher Umgebungsvariablen kontrollieren zu können, ist der Einsatz spezialisierter Bildverarbeitungsalgorithmen erforderlich. Es reicht nämlich nicht aus, sich nur auf Simulationen zu verlassen. Deshalb sind Tests unter realen Bedingungen erforderlich. Diese können allerdings viel Zeit in Anspruch nehmen, insbesondere bei Automotive-, Sicherheits- und Robotik-Applikationen.

Vision-Systeme

Embedded-Vision-Systeme basieren auf einer breiten Palette unterschiedlicher Funktionsbausteine, die auf unterschiedliche Arten integriert werden können. Grundlegend beinhalten sie aber alle Bilderfassungs-, Verarbeitungs- und Erkennungstechnologien (Bild 1).

Auf der Eingangsseite des Systems sind aktuell CMOS- und CCD-Sensoren die beiden führenden Technologien für die Bilderfassung. Auch wenn die CCD-Technologie noch eine höhere Gesamtqualität liefert, so hat doch die CMOS-Technologie in der letzten Dekade den Vorsprung eingeholt. Neben der besseren Lichtausbeute bei schwacher Beleuchtung haben die verbesserte Bildqualität, der geringere Leistungsbedarf und die geringeren Kosten dazu geführt, dass CMOS-Sensoren heute wesentlich häufiger eingesetzt werden als CCD-Sensoren. Auch entwickelt sich die CMOS-Technologie ständig weiter: Es werden kontinuierlich höhere Auflösungen erzielt, die Pixel werden zudem immer kleiner und die dafür benötigte immer schnellere High-Speed-Anbindung und Bandbreite nimmt ebenfalls zu. Damit einhergehend werden auch immer kleinere Bildsensoren und Module verfügbar, durch die kompakte Dual-Kamera-Lösungen und stereoskopische Vision-Systeme zunehmend Verbreitung finden, die geringere Verzerrungen aufweisen, eine Entfernungsmessung ermöglichen sowie einen besseren Kontrastumfang und auch mehr Bildschärfe bieten.

Den passenden Prozessor sollten Entwickler anhand von Aspekten wie der benötigten Echtzeit-Performance, Leistungsaufnahme und Bildpräzision sowie der Komplexität der Algorithmen auswählen. Hier gibt es kontinuierlich Verbesserungen bei der Rechenleistung und den unterstützten Bildverarbeitungsalgorithmen. Zudem wird für den Einsatz in Automobil-, Robotik- und Drohnen-Applikationen auch die SLAM-Methodik (Simultaneous Localisation And Mapping) zunehmend integriert.

Embedded-Vision-Systeme benötigen zudem lokalen Speicher, um Bilder vergleichen oder Bilddaten für eine spätere Auswertung speichern zu können. Für die Speicherung selektierter Bildelemente oder aller erfassten Bilddaten werden in der Regel sowohl flüchtige als auch nichtflüchtige Speicher genutzt.

Spezialisierte Bildverarbeitungsalgorithmen sind ebenfalls elementar – um beispielsweise den Videobildeingang zu steuern und die Bilddaten für spezifische Aufgaben aufzubereiten. Beispiele hierfür sind die Farboptimierung oder Verbesserung der Objekterkennung.

Vor einigen Jahren wurde zudem die Open-Source-Bibliothek OpenCV eingeführt, was die Entwicklung und Implementierung von Algorithmen dramatisch verändert hat. OpenCV ist auf die Bildverarbeitung ausgerichtet und beinhaltet Programmcode mit C/C++ Funktionen, was die Portierung und Ausführung von Algorithmen auf Embedded-Prozessoren deutlich vereinfacht. Es gibt bereits viele Bild- und Videoverarbeitungslösungen von Drittanbietern auf der Basis von OpenCV oder ähnlichen Bibliotheken. Für viele Anwendungen gibt es sogar ganze Frameworks, die die Entwicklung deutlich erleichtern. Auch Chiphersteller bieten in der Regel eigene Bildverarbeitungsbibliotheken an, um die Bildverarbeitungsleistung ihrer eigenen Produkte nochmals deutlich zu optimieren.

Ein weiteres, zunehmend wichtigeres Element, ist insbesondere im Zeitalter des IoT die zur Applikation passende, drahtlose oder drahtgebundene Vernetzung. Auch die Frage, ob die Analysealgorithmen beim Sensor vor Ort oder auf cloud-basierten Servern betrieben werden sollen, ist ein wichtiger Einflussfaktor.

Letztendlich ist es wichtig, zuerst die passenden Komponenten für das jeweilige System und die Applikation auszuwählen und erst dann die Feinabstimmung von Hardware, Software und Algorithmen vorzunehmen. Dieses Procedere ist allerdings nicht immer ganz einfach. Entwickler benötigen aufgrund der Komplexität von Embedded-Vision-Applikationen deshalb professionelle Tools, mit denen sie die Entwicklungskosten, -zeit und -risiken minimieren und ihre Projekte schneller auf den Markt bringen können.

Komplette Lösungen

Avnet Silica verfügt über eine umfassende Erfahrung, seine Kunden bei der Entwicklung von Embedded-Vision-Applikationen zu unterstützen. Das Unternehmen bietet praktisch alle benötigten Building-Blocks für komplette Embedded-Vision-Systeme – inklusive optimierter Hard- und Software sowie Treibern und Applikationen. Die Liste verfügbarer Komponenten reicht von Bildsensor- und Kameramodulen auf der Eingangsseite bis hin zu dedizierter Hardware wie Prozessoren, Speicher und Komponenten für die Stromversorgung, die Entwickler benötigen, um die strikten Vorgaben für Rechenleistung und Stromverbrauch zu erreichen. Alle diese Komponenten ergänzt Avnet Silica mit entsprechenden Softwareentwicklungstools, Treibersoftware für Kameras, exemplarischen Referenzdesigns und einem umfassenden Fachwissen über Bildverarbeitungssoftware und Algorithmen.

Avnet Silica hilft seinen Kunden aber nicht nur bei der Entwicklung von Embedded-Vision-Plattformen und Produkten, sondern bietet Entwicklern auch eine breite Palette von fertigen Kameraentwicklungskits an. Ein Beispiel ist das PicoZed-Embedded-Vision-Kit (Bild 2) mit dem hochflexiblen PicoZed-System-on-Module (SoM) auf Basis des programmierbaren System-on-Chip (SoC) Zynq-7000 von Xilinx. Das PicoZed-Kit ist ideal für Applikationen im Bereich des maschinellen Sehens und beinhaltet alle für die Entwicklung von kundenspezifischen Videoverarbeitungslösungen benötigte Hardware, Software und IP. Das Kit unterstützt den rekonfigurierbaren reVISION-Stack, der für Computer-Vision und bildbasiertes maschinelles Lernen optimiert ist. Der Stack bietet Ressourcen für die Plattform-, Algorithmen- und Applikationsentwicklung, nutzt hardwarebeschleunigte OpenCV-Funktionen und unterstützt die wichtigsten neuronalen Netzwerke.

Ein weiteres Beispiel ist das Kameraentwicklungskit STM32F7 von Avnet Silica (Bild 3). Das kostengünstige, für die Arm-mbed-IoT-Device-Platform geeignete Kit besticht durch seine geringe Stromaufnahme, USB-Support, einen kapazitiven Farb-Touchscreen mit 4,3 Zoll und beinhaltet sämtliche Hard- und Software, die für die schnelle Entwicklung von Embedded-Vision-Applikationen im IoT-Umfeld, der Gebäude- und Heimautomatisierung sowie in vielen anderen Videoverarbeitungsapplikationen benötigt wird. Das dritte Kit ist das Low-Power-Kit Kinetis. Es basiert auf dem Cortex-M4-Mikrocontroller NXP Kinetis K82F mit einem VGA-Kameramodul im Miniaturformat, Flex-Konnektor, 90°-Sichtfeld und Infrarot-Filter. Damit können Standbilder aufgenommen oder Videos mit niedriger Auflösung in Echtzeit gestreamt werden. Avnet Silica arbeitet kontinuierlich an der Entwicklung weiterer Produkte, um das Angebot an Off-the-Shelf-Kits zu erweitern und damit seinen Kunden ein noch umfassenderes Angebot an fortschrittlichen Embedded-Vision-Lösungen bereitstellen zu können. (fr)

Basis des STM32F7: Arm Cortex-M7

Wie auch der Cortex-M4 basiert der M7 auf Arms v7E-M-Architektur, was eine hundertprozentige Code-Aufwärtskompatibilität des M4 bedeutet (anders herum gilt das dank einiger M7-spezifischer Erweiterungen nicht). Die mit zwölf Taktzyklen geringe Interrupt-Latenz des M4 konnte beim M7 sogar in manchen Fällen noch um einen Zyklus auf elf Taktzyklen verringert werden, die Regel sind auch hier zwölf Taktzyklen (gemessen von Auftreten des Interrupts bis zur Ausführung der ersten Instruktion in der Interrupt-Service-Routine). Wichtig: Diese Angaben gelten natürlich nur bei einem Null-Wait-State-Betrieb bezüglich des Speicherzugriffs.


Diese funktionalen Erweiterungen gehen – da auch Arm die Physik nicht ausschalten kann – natürlich auf Kosten der Leistungsaufnahme. Um diese trotz allem möglichst niedrig zu halten, hat Arm das M7-Design auch in diese Richtung verbessert: Drei separate Power-Domänen (Interrupts, Prozessor, Cache) und gegenüber dem M4 deutlich erweitertes Clock- und Power-Gating ermöglichen Arms Lizenznehmern deutlich mehr Optionen in Richtung Energiesparen. Dazu kommen vier Energiesparmodi (Power Off, Deep-Sleep (WIC), Deep-Sleep und Sleep). Im Deep-Sleep-Modus wird der Core komplett abgeschaltet und von einem optional zu implementierenden Wake-Up-Interrupt-Controller (WIC) wieder aktiviert, was noch energiesparender ist, als wenn der interne Interrupt-Controller NVIC aktiv bleiben würde.

Die vom Cortex-M3 und -M4 bekannte dreistufige doch sehr einfach gehaltene Pipeline wurde beim M7 vollständig durch eine 6-stufige Dual-Issue-Pipeline ersetzt (Bild), wobei die parallele Ausführung von zwei Befehlen nicht bei allen Sequenzen möglich ist; hier ist der Compiler dafür verantwortlich, einen möglichst optimalen Code zu generieren. Allerdings sind die meisten Befehle parallelisierbar, anders als bei anderen Architekturen, wo der Compiler einige wenige quasi »magische Befehlspaare« erzeugen muss. In jedem Fall ist auch die parallele Ausführung zweier Befehle in der Kombination Laden/Laden und Laden/Speichern möglich. Die fünf Ausführungseinheiten teilen sich in eine Einheit für Laden/Speichern, zwei ALUs, eine Einheit für MAC-Instruktionen und  eine Gleitkommaeinheit auf.


Die beiden ALUs der Integer-Pipeline unterscheiden sich dahingehend, dass eine ausschließlich für einfache Operationen vorgesehen ist und eine auch SIMD-fähig ist. Die MAC-Pipeline kann Berechnungen der Art 32 × 32 + 64 bit = 64 bit ausführen. In der Gleitkomma-Pipeline kann parallel zur Integer-Pipeline eine MAC-Operation mit einfacher Genauigkeit pro Taktzyklus ausgeführt werden. Die Lade-/Speicher-Pipeline unterstützt die Dual-Issue-Ausführung von 32-bit-Ladeoperationen in den TCM und Datencache.

Während der Cortex-M4 noch auf eine Gleitkommaeinheit des Typs FPv4 zurückgriff, die zwar Lade- und Speicheroperationen in doppelter Genauigkeit (64 bit) ermöglichte, Berechnungen aber nur in einfacher Genauigkeit (32 bit), musste die Armv7-M-Architektur zwangsläufig in diese Richtung erweitert werden. Das Ergebnis ist eine FPU des Typs FPv5. Bei dieser bleibt der Registersatz (schon FPv4 enthielt 16 Register für Gleitkommawerte doppelter Genauigkeit) und die Lade-/Speicheroperationen unverändert. Die existierenden 18 Recheninstruktionen wurden für das Rechnen mit doppelter Genauigkeit erweitert, dazu gibt es auch noch 14 neue Gleitkommainstruktionen.

Auf Grund der Anforderung an deterministisches Verhalten handelt es sich zwangsläufig um ein In-Order-Design, bei welchem im Gegensatz zu den »großen« Out-of-Order-CPUs der Cortex-A-Familie alle Instruktionen in der tatsächlichen Reihenfolge abgearbeitet werden. Verbessert wurde auch das sogenannte Load-Use-Penalty für DSP-Code. Bislang sollte man zwischen Ladeinstruktionen und Befehlen, welche diese Daten weiterverarbeiten, möglichst andere Befehle setzen, damit der Prozessor nicht Wartezyklen einfügen muss, weil er auf die Verfügbarkeit der weiterzuverarbeitenden Daten warten muss. Beim M7 können jetzt geladene Daten unmittelbar mit ADD und MUL/MAC ohne Wartezyklen weiterverarbeitet werden, bei Laden gefolgt von Laden einer Basisadresse (Zeigeroperation) wurde die Wartezeit auf einen Taktzyklus verkürzt.

Auf Grund der verlängerten Pipeline ergab sich die Notwendigkeit einer erweiterten Sprungvorhersage, die man so bei Arms M-Cores bislang noch nicht kannte. Dazu wurde ein 64 Einträge umfassender Sprungziel-Adressen-Puffer (BTAC) implementiert, aus dem zu einem frühen Zeitpunkt (in der Fetch-Einheit) in der Pipeline potentielle Sprungadressen gelesen werden.

Trifft die Sprungvorhersage zu, gibt es keinerlei Verzögerung, bei einer Sprungfehlvorhersage in Abhängigkeit der Sprungart 4, 6 oder 7 Taktzyklen, da die Pipeline ganz oder teilweise gelöscht und neu befüllt werden muss. Um ein »Verhungern« der Pipeline zu verhindern, wurde die Fetch-Einheit mit einer Pre-Fetch-Warteschlange von 4×64 bit ausgestattet. Zu der im Bild abgebildeten Pipeline kommt wie beim Cortex-M4 noch ein Hardware-Dividierer für Integer-Divisionen in einem Taktzyklus hinzu.

Am Ende steht eine fast doppelt so hohe Rechenleistung wie beim Cortex-M4. Der legale DMIPS-Wert (also ohne Inlining oder andere Compiler-Tricks) wurde von 1,25 auf 2,14 gesteigert, das ist mehr als der Cortex-A8 liefert (2,0 DMIPS/MHz), der immerhin im iPhone 3GS eingesetzt wurde. Der CoreMark-Wert steigert sich von 2,7 auf 4,45 (mit dem Arms Development-Studio 5.03.) beziehungsweise von 3,4 auf 5,0 (mit dem IAR-Compiler), dazu werden natürlich auch in CMSIS implementierte Funktionen wie FIR (von 1,35 auf 0,64 Taktzyklen pro Tap) oder IIR (von 11,0 auf 9,00 Taktzyklen/Biquad bei Q15-Daten) schneller.