Guten Abend liebe mikrocontroller.net Community,
ich arbeite momentan an einem spannenden Hobbyprojekt mit
Bildverarbeitung, bei dem ich mit hohem Durchsatz auf der GPU und CPU
Objekte erkenne, die per Zeilenkamera (2048 px) im freien Fall
aufgenommen werden. Ich extrahiere bei vollem Kameratakt (20 kHz)
Vordergrundobjekte auf der GPU und rechne dann auf der CPU pro Objekt
einen Merkmalsvektor aus, der dann per OpenCV und Entscheidungsbaum
klassifiziert wird. Schlussendlich möchte ich mitsamt des
Klassifikationsergebnis am Ende der Verarbeitungskette spezielle Aktorik
(Klappen oder vielleicht auch Druckluft-Ventile) ansteuern, sodass ich
bestimmte Objekte aussortieren kann.
Der Bildeinzug über die Kamera, sowie die Bildauswertung funktioniert
soweit rudimentär und schritthaltend beim anvisiertem Durchsatz. Ich
tüftele nun daran, wie ich das Feintiming zur Ansteuerung der Aktorik
realisieren kann. Die gesamte Umsetzung erfolgte bisher in der mir
bekannten GPU/CPU Welt und ich würde nun aber zwecks Feintiming die
Ausschleusung der Objekte gerne über einen Mikrocontroller realisieren.
Leider bin ich auf diesem Gebiet, bis auf einige Experimente mit Arduino
und Co. relativ unbedarft und hoffe, dass ihr mir einigen Input geben
könnt, sodass ich auf die richtige Schiene komme.
Die Idee ist, dass ich den Hardwaretrigger der Kamera (20 kHz) in einen
Digitaleingang eines Mikrocontrollers führe und dort eine Hardware
Zeilenzählung realisiere. Gleichzeitig steht mir auf der CPU Seite über
den Bildeinzug ebenfalls ein Zeilenzähler zur Verfügung, den ich dann
mit jedem Objekt, dass ich ausschleusen möchte, verknüpfe. Von der
Sichtlinie der Zeilenkamera bis hin zu den Ausschleuseeinheiten habe ich
bei bekannter Fallgeschwindigkeit der Objekte dann rechnerisch einen
Offset, den ich auf Zeilen umrechnen kann. Die Annahme ist hier
natürlich, dass von der Sichtlinie bis zur Ausschleusung eine konstante
Geschwindigkeit herrscht, da die Wegstrecke relativ klein ist. Ich weiß
daher am Ende der Klassifikation, dass ich ein Objekt, das bei Zeile X
begonnen hat, bei Zeile X + einem Zeilenoffset spätestens ausschleusen
muss. Der Offset/mechanische Abstand ist hierbei so groß gewählt, dass
die Bildverarbeitungskette genug Zeit hat, die Daten durchzurechnen. Da
die Bildverarbeitung allerdings durch eine GPU/CPU-Kette geht, habe ich
natürlich einen gewissen Jitter, so dass ein Feintiming auf der
CPU-Seite per Polling schwierig werden wird.
Ich würde daher die Daten zur Ausschleusung von der CPU auf den
Mikrocontroller senden, und zwar in der vollen Geschwindigkeit mit der
die CPU-Kette die Daten durchrechnen kann. Der Mikrocontroller soll dann
die Daten puffern und in einer Schleife kontinuierlich einen Vergleich
mit dem Kamerazeilenzähler machen und zum "richtigen Zeitpunkt", die
Aktorik über Digital-Ausgänge ansteuern. Soviel zu der grundsätzlichen
Idee. Neben der ersten und wichtigsten Frage, ob dieser Ansatz euch
generell sinnvoll/plausibel erscheint, stellen sich mir einige
technische Fragen:
* Wie synchronisiere ich den CPU und die Mikrocontroller Hardwarezählung
Zähler robust, sodass Sie gemeinsam starten und nicht mehr
auseinanderlaufen? Ich würde hier am liebsten konsequent mit einem
64-Bit Zähler arbeiten, sodass ein Überlauf im gesamten System kein
Thema ist (zumindest nicht so lange ich lebe ;)
* Wie bekomme ich die Daten von der CPU robust und sicher auf den
Mikrocontroller? Hier würde ich gerne auf eine Standardtechnologie wie
z.B. Ethernet (UDP) setzen. Die Datenrate wird hier kein großes Problem
sein.
* Am liebsten wäre es mir, wenn ich die Aktorik direkt per
Digital-Ausgängen ansteuern könnte. Dann bräuchte ich allerdings schon
128 oder lieber 256 Ausgänge, die ich mit <= 1 kHz schalten kann.
* Welchen Mikrocontroller/Board kann ich für die Aufgabe verwenden? Ich
möchte ca. 20 ms mit zur Kamerazeile passenden Ausschleusezeilen puffern
können. Eine Ausschleusezeile besteht aus maximal 1024 Bit. D. h. auf 20
ms sind es 6.25 KByte Daten.
Habt ihr für die Hardware eine gute Empfehlung? Wenn es ein fertiges
Board mitsamt Ethernet und passendem Mikrocontroller gibt, wäre das
natürlich prima. Das Ganze sollte für einen Hobbyisten noch bezahlbar
bleiben. Die Aktorik wird leider wohl auch noch was kosten.
Ich würde mich über ein Feedback von Euch freuen!
Schönen Gruß
Philipp
Wenn ich das richtig verstanden habe, hast du also ein Objekt, dass im
freien Fall von einer Kamera aufgenommen wird, die Bilder werden von
GPU+CPU ausgewertet und daraus kannst du berechnen, wann das Objekt an
einem gewissen Ort ist und willst zu diesem Zeitpunkt einen Aktor
ansteuern.
Philipp schrieb:> * Wie synchronisiere ich den CPU und die Mikrocontroller Hardwarezählung> Zähler robust, sodass Sie gemeinsam starten und nicht mehr> auseinanderlaufen? Ich würde hier am liebsten konsequent mit einem> 64-Bit Zähler arbeiten, sodass ein Überlauf im gesamten System kein> Thema ist (zumindest nicht so lange ich lebe ;)
Soweit ich das verstanden habe, hast du bereits auf der CPU eine
Zeilenzählung und du musst diese nun mit dem Microcontroller
synchronisieren. Du hast Zugriff auf das Hardwaretriggersignal der
Kamera, also sollte es kein Problem sein ein Auseinanderlaufen zu
verhindern. Gibt es auch ein extra Signal, wenn die Aufnahme beginnt um
eine gemeinsame Zeile 0 festzulegen, sowas wie ein Start- oder
Einschaltsignal?
Am Mikrocontroller würde ich zum Zählen einen Hardware Timer mit
externem Clock Eingang verwenden (die meisten Microcontroller besitzen
einen). Da der Timer aber wahrscheinlich nur 16 oder max. 32 bit haben
wird, kannst du zusätzlich bei Überlauf einen Interrupt auslösen und
darin eine Variable inkrementieren, um die Zählergröße praktisch in
Software zu erhöhen.
Philipp schrieb:> * Wie bekomme ich die Daten von der CPU robust und sicher auf den> Mikrocontroller? Hier würde ich gerne auf eine Standardtechnologie wie> z.B. Ethernet (UDP) setzen. Die Datenrate wird hier kein großes Problem> sein.
Ethernet ist natürlich eine Möglichkeit, aber recht kompliziert,
einfacher ist USB oder UART (RS232 falls die Distanz größer ist) über
einen USB-UART Wandler.
Bei UART sollten normalerweise bis 115200 baud kein Problem sein, USB
geht schneller, ist aber komplizierter zu Programmieren und nicht jeder
Microcontroller besitzt ein USB Interface.
Philipp schrieb:> * Am liebsten wäre es mir, wenn ich die Aktorik direkt per> Digital-Ausgängen ansteuern könnte. Dann bräuchte ich allerdings schon> 128 oder lieber 256 Ausgänge, die ich mit <= 1 kHz schalten kann.
Wären Schieberegister eine Möglichkeit? z.B. HC595 sind 8-bit
Schieberegister, die hintereinander betrieben werden können und vom
Mikrocontroller seriell angesprochen werden können. 256 Ausgänge mit
1kHz würde einen Takt von ca. 256kHz benötigen was leicht möglich sein
sollte.
Die HC595 können auch so angesteuert werden, dass sich alle Ausgänge
gleichzeitig ändern.
Philipp schrieb:> * Welchen Mikrocontroller/Board kann ich für die Aufgabe verwenden? Ich> möchte ca. 20 ms mit zur Kamerazeile passenden Ausschleusezeilen puffern> können. Eine Ausschleusezeile besteht aus maximal 1024 Bit. D. h. auf 20> ms sind es 6.25 KByte Daten.
Fürs Hobby würde ich ein STM32 Nucleo board empfehlen, z.B. Nucleo
F303RE, hat 80kB RAM, also locker genug. Programmer ist am Board drauf,
dieser kann auch als USB-UART Wandler benutzt werden.
Falls du noch wenig oder gar nicht mit Microcontrollern gearbeitet hast,
ist STM32 vielleicht nicht der perfekte Einstieg, da die Controller doch
sehr komplexe Peripherie haben, aber mit ein paar Tutorials sollte es
schon gehen.
Wenn du statt UART doch direkt USB oder Ethernet benutzen willst,
müsstest du ein anderes Board benutzen, denn der STM32F303RE hat zwar
ein USB Peripheral, aber das Nucleo board hat keine USB Buchse die mit
diesem verbunden ist.
Philipp schrieb:> bei dem ich mit hohem Durchsatz auf der GPU und CPU Objekte erkenne
Wie viel Leistung brauchst du denn ungefähr? eventuell reicht eines der
Leistungsfähigeren BeagleBone, da läuft dann ein Linux mit DSP und
Graphik Einheit sowie Cortex M4 als MCU für den Real Time Bedarf. Gibt
es auch mit Beschleunigung für Machine Vision (
https://beagleboard.org/ai ), das könnte ein passendes all in one Paket
sein.
Philipp schrieb:> * Welchen Mikrocontroller/Board kann ich für die Aufgabe verwenden? Ich> möchte ca. 20 ms mit zur Kamerazeile passenden Ausschleusezeilen puffern> können. Eine Ausschleusezeile besteht aus maximal 1024 Bit. D. h. auf 20> ms sind es 6.25 KByte Daten.
soll das auch mit der Geschwindigkeit aktualisiert werden? also die
6.25kByte kommen alle 20ms, macht 312.5kB/s, ergibt 2.5MBaud reine
Nutzdaten (3.125MBaud wenn man start und stop bit vom UART
berücksichigt). das könnte etwas knapp werden mit UART.
Alex D. schrieb:> denn der STM32F303RE hat zwar> ein USB Peripheral, aber das Nucleo board hat keine USB Buchse die mit> diesem verbunden ist.
die kann man als Breakout Modul für nen Euro haben, USB wäre hier schon
angesagt denke ich. Ansonsten sollte das gut passen, und ist auch
verbreitet genug um Beispiele und Hilfe zu finden.
Was man allerdings noch testen sollte sind die Latenzen die vom
Betriebssystem sowie von USB oder Ethernet ausgehen inklusive
Fehlerbehandlung und neusynchronisation falls mal über 20ms keine Daten
reinkommen. Was für ein System nutzt du zur Zeit und was für Latenzen/
Abweichungen vom Mittel hast du so? Ein RTLinux sollte auch die
Synchronisation selber hinbekommen, bei Windows würde ich mir schon
Gedanken machen ob das mit den 20ms immer funktioniert.
Philipp schrieb:> Kameratakt
Der sollte deine Referenz sein.
Wenn dein Programm berechnen kann, dass ein Objekt aus Kameratakt x zu
Kameratakt x+m von deinem Aktor entfernt werden soll, dann kannst du zu
jedem Zeitpunkt zwischen x und x+m-1, also zeitlich völlig
unsynchronisiert nur halt rechtzeitig, einem uC die Botschaft schicken
'Aktor a zum Zeitpunkt m aktivieren'. Der uC hat kein Problem, das dann
zum Zeitpunkt x+m auszulösen, 20kHz sind für den langsam, er könnte
jeweils vom Kameratakt einen Interrupt bekommen. Die Botschaft würde ich
per USB senden, nicht dem overheadbehafteten Ethernet. Es kann im
Prinhip jeder uC, schon ein Arduino.
Vielen Dank für den wertvollen Input von eurer Seite und die Vorschläge
für die Hardware. Die Variante mit dem STM32 mitsamt extra Baustein für
die Schieberegister zur Ansteuerung der Aktorink klingt für die reine
Feintiming-Aufgabe gut durchdacht/dimensioniert.
Die Beaglebone Variante intererssiert mich auch (brennend), aber ich
denke nach meinen bisherigen Benchmarks nicht, dass ich die
Bildverarbeitung von 2K Pixel rechentechnisch da schritthaltend bei 20
kHz sauber durch bekomme. Aktuell verwende ich übrigens einen Intel
Core-i7 8600 unter Windows mitsamt eines dedizierten PCI-E GigE
Framegrabbers um die CPU zu entlasten (es wird aber wahrscheinlich noch
auf ein Linux mit RTOS-Kernel gewechselt). Mir gefällt diese
Monster-Lösung auch nicht so sehr. Gibt es für die Beaglebone Platine
(oder möglicherweise auch auf dem Rasberry-PI) eine sinnvolle Lösung,
wenn man eine Zeilenkamera anschließen kann? Bei GIG-E wird ja ziemlich
die CPU gestresst, wenn man keine extra Framegrabber-Hardware hat.
Andere Interfaces, wie etwa CameraLink, wären auf solchen Platinen auch
einmal sehr interessant. Weiß jemand, ob es dafür passende
Zusatzhardware gibt. Ich habe beim schnellen Suchen leider nichts
passendes gefunden. Wenn so etwas existiert, dann könnte ich mir auch
vorstellen, mehrere solcher Platinen für ein 2K Bild zu betreiben, so
dass jede nur einen Bereich sieht und rechnentechnisch durchkommt. Das
Synchronisationsthema wird dadurch natürlich auch nicht gerade
einfacher.
Egal, dass sind so meine Ideen im Kopf. Vielen Dank nochmals für Euren
profunden Input!
Philipp schrieb:> Bei GIG-E wird ja ziemlich> die CPU gestresst, wenn man keine extra Framegrabber-Hardware hat.
Eigentlich nicht, der i7 langweilt sich beim Bildeinzug, vor allem wenn
die Treiber den NIC unterstützen und nicht der IP Stack vom OS genutzt
werden muss.
Richtig schnell und synchron wird es nur mit spezieller HW gehen, etwa
Grabbern von Silicon Software (jetzt Basler). Da ist ein FPGA drauf und
kann direkt BV Aufgaben übernehmen und dann auch GPIOs setzen.
Dein i7 hat wohl ausreichend Rechenleistung, aber beachte bitte, dass
Fenster und Pinguin nicht echtzeitfähig (im Normalfall) sind.
Dem nach ja bekommst Du da ein Timing mit Jitter.
Das ich über ein Nicht-Echtzeit-OS einen signifikanten Jitter bekomme,
kann ich durch interne Zeitmessungen meiner Bildverarbeitungskette recht
gut sehen. Daher möchte ich auf ein Linux mit Realtimekernel, für den
Bildeinzug und die Bildverarbeitung, umsteigen und das Feintiming auf
einen Mikrocontroller auslagern. Ein FPGA direkt im Framegrabber ist
hier auch eine spannende Option, allerdings auch mit hohen Kosten
verbunden und von der Algorithmik eher limitiert. Ich habe auch nicht
die Zeit mich hier in die FPGA Welt einzuarbeiten. Meine pixelweise
Vorverarbeitung ließe sich wohl gut auf einen FPGA portieren, bei der
Objektextraktion wird es deutlich schwieriger, da die Algorithmen mit
dynamischen Listen/Speicherverwaltung arbeiten.
Die bisherige Verarbeitung funktioniert auf der GPU/CPU auch robust und
performant, zumindest im Schnitt. Es gibt dann eben Ausreißer in der
Berechnungszeit, die ich ausgleichen muss.
Was mir am aktuellen Ansatz weniger gefällt, ist das ich für die
Bildverarbeitung einen High-End-PC nutzen muss. Eine Lösung über mehrere
zusammengeschaltete kleinere Recheneinheiten, wie z.B. Beaglebones oder
NVidia Jetsons oder gar RBPIs, würde mich hier schon reizen. Ich müsste
halt eine Anbindung an einer 2K GigE Zeilenkamera über mehrere Einheiten
verteilen und die Ergebnisse bei der Ansteuerung der Aktorik, wieder
"verheiraten". Ich finde derzeit allerdings nicht wirklich etwas mit
entsprechenden Kamera-Interface. Am günstigsten erscheint mir GigE und
dieses könnte ich direkt in eine solche SoC Lösung führen, aber dann ist
die dortige CPU schon arg beschäftigt 20 kHz mit 2K Zeile auf ETH zu
dekorieren. Die Bildverarbeitung auf 2K bei 20 kHz auf den verbleibenden
ARM Cores durchzuziehen, halte ich für "sportlich"...
MaWin schrieb:> Die Botschaft würde ich> per USB senden, nicht dem overheadbehafteten Ethernet.
Was ist denn das für ein Unsinn? USB hat WESENTLICH mehr Overhead als
Ethernet und auch WESENTLICH höhere Latenzen.
Ich bin da nicht so tief drinnen und habe eher die
"Softwareentwicklerbrille" auf. Ein einfaches Protokoll über Ethernet
per UPD von der CPU zur Kommunikation mit dem Mikrocontroller schwebte
mir ursprünglich vor, aber vielleicht prallen da auch zwei Welten
aufeinander :) interessanter wäre für mich, was ihr von der verwegen
Idee mit den kleinen Recheneinheiten a la Beaglebone/Jetson/RBPi haltet.
Seht ihr eine Chance dort eine latenzarme Anbindung an eine GigE
Zeilenkamera zu realisieren? Wenn ich pro Einheit nur 512 oder besser
1024 Pixel bei 20 kHz abarbeiten kann, dann kann man schon etwas
hinbekommen. Ich müsste nur meine Algorithmen auf ARM kompiliert
bekommen, was ich durchaus für möglich halte.
Philipp schrieb:> Ich bin da nicht so tief drinnen und habe eher die> "Softwareentwicklerbrille" auf. Ein einfaches Protokoll über Ethernet> per UPD von der CPU zur Kommunikation mit dem Mikrocontroller schwebte> mir ursprünglich vor, aber vielleicht prallen da auch zwei Welten> aufeinander :) interessanter wäre für mich, was ihr von der verwegen> Idee mit den kleinen Recheneinheiten a la Beaglebone/Jetson/RBPi haltet.> Seht ihr eine Chance dort eine latenzarme Anbindung an eine GigE> Zeilenkamera zu realisieren? Wenn ich pro Einheit nur 512 oder besser> 1024 Pixel bei 20 kHz abarbeiten kann, dann kann man schon etwas> hinbekommen. Ich müsste nur meine Algorithmen auf ARM kompiliert> bekommen, was ich durchaus für möglich halte.
Für solche Aufgaben möchstest Du eine dicke GPU haben. Das führt Dich
direkt und unmittelbar zu NVidia Jetson. Ich entwickle dafür eigene
Boards, wobei wir PCIe-Kameras nutzen - wegen der Latenz. Der TX2 hat
zusätzlich zu seinen 6 Cortex-A Kernen fürs Linux einen Cortex R5, und
auch auf dem kann man eigenen Code ausführen. Da auf den Cortex-A Kernen
ein Ubuntu Linux läuft, hast Du auch dort die Realtime-Problematik, aber
dank ARM nicht so ausgeprägt. Und das Cuda auf den Jetson-Modulen ist
das im Prinzip gleiche wie das auf dem PC.
fchk
Philipp schrieb:> Ich bin da nicht so tief drinnen und habe eher die> "Softwareentwicklerbrille" auf. Ein einfaches Protokoll über Ethernet> per UPD von der CPU zur Kommunikation mit dem Mikrocontroller schwebte> mir ursprünglich vor
Wieso auf dieser hohen Protokollebene? UDP und das ganze darunter nötige
IP-Geraffel samt Helper-Protokollen wie ICMP und ARP braucht man für
sowas nicht. Sowas handelt man direkt oberhalb des MAC-Layers mit einem
eigenen Protokoll ab.
Im Extremfall sogar noch noch "unterhalb" des MAC-Layers, sprich anstatt
der Benutzung desselben. Soweit runterzugehen dürfte in deiner Anwendung
allerdings längst noch nicht nötig sein...
Mit der "Softwareentwicklerbrille" solltest du schon eine deutliche
Vorstellung vom Netzwerkstack haben, um sowas abschätzen zu können. Oder
hat die "Softwareentwicklerbrille" etwa schwarze Gläser, weil sie
eigentlich eine "Glue-Code-Frickler-Brille" ist, sprich: du eigentlich
ein Copy&Pastler bist, der garnicht wirklich selber irgendwas schaffen
kann?
c-hater schrieb:> Philipp schrieb:>> Ich bin da nicht so tief drinnen und habe eher die> "Softwareentwicklerbrille" auf. Ein einfaches Protokoll über Ethernet> per UPD von der CPU zur Kommunikation mit dem Mikrocontroller schwebte> mir ursprünglich vor>> Wieso auf dieser hohen Protokollebene? UDP und das ganze darunter nötige> IP-Geraffel samt Helper-Protokollen wie ICMP und ARP braucht man für> sowas nicht. Sowas handelt man direkt oberhalb des MAC-Layers mit einem> eigenen Protokoll ab.>> Im Extremfall sogar noch noch "unterhalb" des MAC-Layers, sprich anstatt> der Benutzung desselben. Soweit runterzugehen dürfte in deiner Anwendung> allerdings längst noch nicht nötig sein...>
Bis hierhin bedanke ich mich für deine sachliche Antwort.
> Mit der "Softwareentwicklerbrille" solltest du schon eine deutliche> Vorstellung vom Netzwerkstack haben, um sowas abschätzen zu können. Oder> hat die "Softwareentwicklerbrille" etwa schwarze Gläser, weil sie> eigentlich eine "Glue-Code-Frickler-Brille" ist, sprich: du eigentlich> ein Copy&Pastler bist, der garnicht wirklich selber irgendwas schaffen> kann?
Diesen Rest kannst du dir beim nächsten Mal sparen. Was ist dein
Problem?
Ok, ist ein Troll. Dachte eigentlich die Welt hätte sich
weiterentwickelt. Das gilt wohl leider nicht für alle. Ich würde mich
freuen, wenn wir wieder sachlich diskutieren könnten. Oder was c-hater
du älter Zerstörer;)
Um mal beim Thema zu bleiben: Den Beitrag von Frank K. bzgl. Nvidia
Jetson fand ich übrigens richtig interessant. Was meinst du mit PCIe
Kamera? Das (offizielle) Datenblatt zur Jetson TX2 sieht für meine
Zwecke durchaus interessant aus. Könnte ich hier auch eine GigE Kamera
anbinden und den Bildeinzug mit einem Core für den Bildeinzug abwickeln,
so dass der Rest die Bildvearbeitung rechnen kann? Wenn ich das ganze
noch von der Jetson aus per Hardware triggern kann, wäre das natürlich
ganz schick. Ich glaube dennoch, dass eine Jetson die 2K auf 20 kHz
nicht packt. Kostentechnisch habe ich aber keine Problem 2-4 für dem
Zweck parallel zu nutzen. Die Frage ist aber dann, wie ich den
Datenstrom von einer GigE Zeilenkamera auf die 2 oder 4 Jetsons bekomme
und jede nur einen Bereich "sieht"...
Philipp schrieb:> Um mal beim Thema zu bleiben: Den Beitrag von Frank K. bzgl. Nvidia> Jetson fand ich übrigens richtig interessant. Was meinst du mit PCIe> Kamera?
Sowas z.B.
https://www.ximea.com/en/products/xilab-application-specific-custom-oem/embedded-vision-and-multi-camera-setup-xix/cmosis-cmv12000-nir-4k-embedded-camera> Das (offizielle) Datenblatt zur Jetson TX2 sieht für meine> Zwecke durchaus interessant aus. Könnte ich hier auch eine GigE Kamera> anbinden und den Bildeinzug mit einem Core für den Bildeinzug abwickeln,> so dass der Rest die Bildvearbeitung rechnen kann?
Die Bibliotheken für GigE sind meist closed-source. Wenn Du Binaries für
arm64 bekommst, geht das. Machen wir auch.
> Wenn ich das ganze> noch von der Jetson aus per Hardware triggern kann, wäre das natürlich> ganz schick. Ich glaube dennoch, dass eine Jetson die 2K auf 20 kHz> nicht packt. Kostentechnisch habe ich aber keine Problem 2-4 für dem> Zweck parallel zu nutzen. Die Frage ist aber dann, wie ich den> Datenstrom von einer GigE Zeilenkamera auf die 2 oder 4 Jetsons bekomme> und jede nur einen Bereich "sieht"...
Das geht schon. Du darfst das ganze Zeugs halt nur nicht auf den
ARM-Cores rechnen wollen, sondern musst das auf die GPU auslagern.
Dafür ist die da. Dann geht so einiges mehr.
https://developer.nvidia.com/cuda-zonehttps://developer.ridgerun.com/wiki/index.php?title=Xavier/JetPack_4.1/Components/Cuda
fchk
Frank K. schrieb:> Das geht schon. Du darfst das ganze Zeugs halt nur nicht auf den> ARM-Cores rechnen wollen, sondern musst das auf die GPU auslagern.> Dafür ist die da. Dann geht so einiges mehr.>> https://developer.nvidia.com/cuda-zone> https://developer.ridgerun.com/wiki/index.php?title=Xavier/JetPack_4.1/Components/Cuda
GPU Programmierung mit CUDA/OpenCL ist mir bekannt. Leider sind manche
Algorithmen meiner Bildverarbeitungskette nicht wirklich sinnvoll auf
der GPU zu realisieren. Auf der Pixelebene am Anfang der Kette direkt
hinter dem Bildeinzug ist hingegen Potential dafür. Evtl. ließe sich ja
hier ein Debayering, Shading etc. implementieren.
Angefangen beim Bildeinzug ist natürlich die Frage, wie ich mit
möglichst niedriger Latenz/Jitter bei 20kHz zwei Kameras per GigE an
Jetson anbinden kann ohne den ARMs unnötig Resourcen durch die
Deserialisierung des UDP-Protokolls zu entziehen. Andere
Kamerainterfaces (USB,PCIe) kommen für mich derzeit nicht in Frage, oder
sind inkompatibel mit Jetson (CameraLink).
