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.
Ich rate dir dazu, eine Wasco-Karte oder ähnliches zu verbauen die über pci(e) angeschlossen werden kann
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-zone https://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).
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.