Hi, für ein Studienprojekt suche ich einen FPGA der mit einer Raspberry Pi 2/3 B kompatibel ist, mit welchem ich 3 Kameras zeitgleich ansteuern kann. Programmiersprache egal. Bevorzugt VHDL oder Python. Mehr Infos zum Projekt: Die vorherige Projektgruppe hat eine USB-Kamera, welche mit einem C++ Code und openvc eingestellt und angesprochen wird, verwendet. Ein fertiges Programm zur Bildanalyse geschrieben. http://www.elpcctv.com/wide-angle-full-hd-usb-camera-module-1080p-usb20-ov2710-color-sensor-mjpeg-with-21mm-lens-p-204.html Ziel ist es nun, drei verschiedene Kameras zu verwenden und die unterschiedlichen Kamerapositionen und deren Aufnahmen zeitgleich zu synchronisieren. Am besten hardwaretechnisch, da das per Softwarelösung (Zeitstempel, etc.) zu aufwendig und unexakt ist. Das Anwendungsgebiet (Kieferbewegungen Medizintechnik) sollte in der Theorie eigentlich überhaupt gar keine Abweichungen haben. Das Problem: mit USB und Windows-Rechner kann man das vergessen! Daher die Idee der Verwendung eines FPGA-Bausteins. Alle Kameras zurselben Zeit triggern und die Aufnahme starten. Gefunden habe ich: http://www.bugblat.com/products/pif/index.html und: https://www.xilinx.com/support/documentation-navigation/silicon-devices/mature-products/spartan-3a-dsp.html Welche Erfahrungen habt ihr mit den beiden? Kann ich damit auch USB-Kameras ansprechen? Oder brauche ich eine andere Verkabelnung? Jemand eine Idee? Die Aufnahmezeit beträgt zwischen 10 und 60sec. Die Videos sollten von der Raspberry Pi aus auf einem Windows Rechner/ins Internet übertragen werden können. Im Idealfall im FPGA "zwischen"gespeichert. Allgemein: hat jemand OpenVC schon mal auf einer Raspberry genutzt? Alle Infos und Tipps sind sehr hilfreich! Bevorzugt mit Leuten, die Erfahrungen im DSP und mit FPGAs und Kameras haben ;-) Danke!
Moin, erstmal: Du meinst sicher OpenCV. Zum Thema erst ein paar Gegenfragen: - Welcher Kamerasensor, soll das der OV2710 werden? - Was für Latenzzeiten müssen das sein, bzw. wie genau die Kameras aufeinander synchronisiert? - Hast du dich mit den Details von v4l2 auseinandergesetzt? - Genauso: MIPI versus Parallel-Video? Kann sein, dass OpenCV inzwischen eine bessere Nummer macht, was Geschwindigkeit und DSP-Instruktionen angeht, aber eventuell kannst du da mit klassischen Float-Operationen auch mal enttäuscht werden. Bin da nicht up to date.. Was FPGA angeht, müsstest du erst abklären, wie die Sensoren rangebacken werden. Bei MIPI wirds knifflig, und bei Parallel und Synchronisierung brauchst du schnell mal ein grösseres FPGA, wenn Pufferung von Zeilen und höhere Bitraten fällig sind. Mit einem HDR60 (etwas älter) kann man da einiges machen, Lattice hat auch noch ne neuere Plattform ('VIP' mit ECP5) im Angebot.
Hi, Vielen Dank für deine Hilfe! Ich meine natürlich OpenCV ;-) Bisher wurde eben der OV2710 eingesetzt, die Kamera funktionsfäig umgebaut (Diskette als IR-Filter). Ich finde die Kamera auch nicht ideal (erst recht nicht für unsere Anwendung!) - Aber das stammt eben aus dem Vorgänger-Projekt eines früheren Semesters... Ich gehe davon aus, dass mein Professor jetzt noch zweimal dieselbe Kamera bestellen wird, anstatt neue Experimente mit einer anderen Kamera einzugehen. Das geschriebene Kamera-Programm ist eben so funktionsfähig. Es muss quasi nur noch auf drei "skaliert" und dann "synchronisiert" werden. Latenzzeit ist natürlich ein sehr dehnbarer Begriff.. :D In meinem Anwendungsfall ist eigentlich nur wichtig, dass alle drei Kameras so synchron zueinander sind wie möglich. Wie groß die Verzögerungs-/Ansprechzeit ist, ist prinzipiell egal. Sie sollte nur bei allen Kameras gleich groß sein... Alle gleichzeitig mit der Aufnahme starten und stoppen... Also dreimal dieselbe Kamera :) Klar: Umso kleiner, umso besser natürlich. Aber primär ist, dass die Kameras nicht allzu teuer sind und die Synchronisation funktioniert. Ich habe mich leider noch nicht im Detail mit v4l2 beschäftigt. Zu empfehlen??? Ist dieses auf einer Raspberr Pi einsetzbar? Können dort drei Kameras angeschlossen werden? Auch USB?! Ich kann mir eben nicht vorstellen, dass es überhaupt einen FPGA gibt, an dem USB-Kameras angeschlossen werden können - ein Irrtum?? Oder lässt sich die eingesetzte Kamera vielleicht auch mit einem anderen Anschluss an den FPGA-Baustein anschließen? Ich habe selber nur die Modellnummer der Kamera erhalten, aber kein Datenblatt oder passende Produktinformationen erhalten und muss mir diese Kamera erst näher anschauen... Die Programme sind eben mit OpenCV gemacht. Ich kenne mich da leider auch nicht näher aus. Mit den Begriffen MIPI und Parallel Video kann ich leider nicht so viel anfangen... Lattice HDR60 scheint ziemlich teuer zu sein... Wie können dort die Kameras angeschlossen werden? USB wohl kaum... Können drei Kameras angeschlossen werden? Und: ansteurbar mit einer Raspberry PI? Oder wie funktioniert der HDR60? Ein weiteres Problem in unserem Projekt (worüber sich noch keiner der bisherigen 4 Vorgänger-Gruppen Gedanken gemacht hat) - Stromversorgung :D Letzten Endes muss ein Patient beim Kieferorthopethen das ganze Konstrukt (Condilograph) tragen können... Steckdose eignet sich nicht... Für die Raspberry Pi ist mir ein "Akku"-System bekannt. Aber wenn man Kameras, FPGA, etc. alles "mobil" mit Strom versorgen will... Ohje... Aber darum will ich mich nicht kümmern - macht vielleicht das Semester danach ;-) Bei uns ist eben das Synchronisieren der Kameras das wesentliche. Letzten Endes brauche ich eine preiswerte Lösung, um drei Kameras über USB anzuschließen und zu synchronisieren. Ist das mit HDR60 möglich?
Hi Matthias, mal mit der USB-Lösung angefangen: Da wirst du sicher auch schon festgestellt haben, dass die div. Kameras 'auseinanderlaufen'. D.h. mit einer Framedauer an Jitter bzw. Versatz zueinander musst du bei der Lösung leben. Jetzt weiss ich nur immer noch nicht, wie genau das Timing sein muss. Was ich dir schon sagen kann, ist, dass der Rpi nicht für eine Industrielösung oder gar medizinische Diagnostik tauglich ist. Fürn Prototypen reicht's, solang du kein 100% zuverlässiges USB oder I2C brauchst. Abgesehen davon musst du für die drei Kameras allenfalls im v4l2 (Video 4 Linux) Layer gut Bescheid wissen, um da eine vernünftige Synchronisation hinzukriegen - wenn die Kamera es überhaupt kann. Oder du steuerst einen eventuell existierenden Triggereingang an den Sensoren periodisch an. Dann ist das bei ev. bei einer nicht allzu grossen Bildrate zu schaffen. Ich habe aber bei einem ähnlichen System Probleme im isochronen Modus gehabt, da steckt derselbe Core wie im Broadcom drin. Also: Schwer unter Vorbehalt. Würde ich als erstes testen, wieviele /dev/videox gleichzeitig Bilder liefern können, und was dabei verlorengeht. Jetz zum FPGA: Da würdest du kaum die USB-Kameras anschliessen wollen, das wäre noch der grössere Implementations-Albtraum. Den OV2710 kannst du also nur direkt (ohne USB) am FPGA ankoppeln, m.W. hatte der auch die Option "Parallel" (MIPI ist von der Komplexität wohl eher ausm Fokus). Wenn aber das HDR60 schon vom Preis her ein Kriterium ist, bleibt wohl nur der USB-Prototyp, d.h. du musst rauskriegen, ob du die Kamera entweder im Software-Trigger (da spielt dann die Linux-Systemlatenz wie auch USB-Latenz ne Rolle) oder per HW-Trigger-Modus treiben kannst. Letzeres kriegst du nur per PWM mit guter Genauigkeit hin, oder du nutzt Echtzeit-Erweiterungen. Oder mal so gefragt: Wieviel Zeit/Hilfskraft hast du? Sind ne Menge Baustellen..
Ich würde da ganz klar auf Lattice gehen mit den Crosslinks. Eventuell kannst du dich sogar an deren Evalkit orientieren: http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/CrossLinkLIFMD6000RaspberryPiBoards Hängt natürlich auch stark davon ab, wie Kamera Schnittselle aussieht. Die Synchronisation ist im Prinzip ganz einfach, du musst halt alle 3 Kameras mit gleichem VSync Triggern. Darf ich mal Fragen für was du 3 Kameras hast? Nicht zufällig um die zu einer 3 Chip Kamera zu kombinieren?
Hallo Tobias, die Kameras sollten idealerweise per USB angeschlossen werden... Oder gibt es da irgendeinen Adapter, um das an den FPGA anzuschließen? Kann man sich selber eine USB-Schnittstelle an einem FPGA bauen? Gibt es dafür schon Bibliotheken/Codes? Drei Kameras werden benötigt, um die Kieferbewegung zu vermessen. Aufwendige Aparatur. Zu komplex, das jetzt schnell zu erklären. Kurzfassung: links, rechts und von vorne ;-) Kamera dabei statisch und nimmt über UV-Bilder LED-Sensoren auf, die ausgewertet werden. Das Programm für eine Seite steht bereits. Wichtig ist eben, dass die Bilder synchron sind, d.h. von drei Position zeitgleich dieselben Kieferbewegungen aufgenommen, vermessen und verarbeitet werden. Nur leider ist ja USB seriell... Daher die Idee mit dem FPGA und synchrones Trigger-Signal. Alternatives Konzept: Zeitstempel der Aufnahmen und dann am Anfang und Ende ein bisschen wegschneiden ;-) @Martin S.: Handelt sich erstmals um einen Prototyp! Später kommen bestimmt bessere Microcontroller/Boards, FPGAs und Kameras zum Einsatz... Geht erstmal darum zu zeigen, dass das einfach und deutlich billiger zu realisieren ist, als die teuren bisherigen Condiolographen auf dem Markt. Vielen Dank schon mal für eure Hilfe und das Brainstorming ;-) Matthias
Habe mal ähnliches gemacht. 3 CMOS Kameras in das FPGA, dann über USB 2.0 zum Rechner. Der Rechner kann dann mit Bildern machen, was er will. Die Bilder waren absolut Synchron (Pixel-Genau), allerdings hingen die Sensoren auch an einem FPGA :-/ Von der Hardware her ist es aber schon industrie-Elektronik, nichts mit Basteln und so. Und teuer ist es natürlich auch. Grüße Kest
Kest schrieb: > Habe mal ähnliches gemacht. 3 CMOS Kameras in das FPGA, dann über USB > 2.0 zum Rechner. Der Rechner kann dann mit Bildern machen, was er will. > Die Bilder waren absolut Synchron (Pixel-Genau), allerdings hingen die > Sensoren auch an einem FPGA :-/ > Von der Hardware her ist es aber schon industrie-Elektronik, nichts mit > Basteln und so. Und teuer ist es natürlich auch. > > Grüße > Kest das halte ich auch für die einzigste vernüftige lösung, der usb ist zu weich in richtung zeitlich genaue abläufe.
Matthias schrieb: > die Kameras sollten idealerweise per USB angeschlossen werden... Nein, idealerweise UND realistischerweise kannst du USB vergessen. Wenn du schon USB-Kameras verwendest, kannst du die auch direkt am Rechner per USB auslesen. Was soll ein FPGA dazwischen noch retten? Informiere dich über Highspeed-Echtzeit-Kameras mit praxistauglicher Synchronisation. Solche Kameras definieren geeignete Interfaces. Mein Eindruck ist, du musst die vorhandene, ungeeignete Hardware verwenden und willst dir nun schönreden, dass ein zwischengeschalteter FPGA die verlorengegangene Zeitinformation wiederherstellen kann. Vergiss es!
FPGA und USB-Kameras? Das ist ein ziemlicher Aufwand. Davon würde ich jedem abraten. Die Kameras werden direkt an den PC angeschlossen. Dann gibt es ein System, welches die Kameras zeitgleich triggert. Dazu haben alle besseren Industriekameras Triggereingänge. Der PC bekommt dann synchronisierte Kamerabilder. Ein Firma hier nebenann stellt exakt sowas her. Steuergeräte und auch Auswertesoftware für bewegte Bilder mit mehreren synchronen Kameras. Kann man von der Stange kaufen.
Matthias schrieb: > Oder gibt es da irgendeinen Adapter, um das an den FPGA anzuschließen? > Kann man sich selber eine USB-Schnittstelle an einem FPGA bauen? Gibt es > dafür schon Bibliotheken/Codes? Kann man, aber wie ja schon einige betont haben macht das so gar keinen Sinn. Du gewinnst damit ja nix dabei an Timing-Präzision, mehr noch, du kaufst dir eine Menge mehr an Implementierungsaufwand ein, ganz zu schweigen von den Extrakosten für die USB-Phys und dem zusätzlichen Aufwand, die Daten wieder komprimiert rauszukriegen. Nimm lieber einen Core mit vernünftigem USB, wie IMX6 oder frischer. Auch da musst du aber das Bandbreitenproblem erst abchecken. Du hast auch noch nicht die Genauigkeit spezifiziert. Gib doch mal an, was ein Versatz in ms bei welcher Framerate akzeptabel ist. Gehe davon aus, dass das nicht so streng ist, da du ja offenbar rolling-Shutter-Sensoren einsetzt. Man kann USB-Kameras bis zu einem gewissen Punkt schon software-triggern. Würde ich aber bei einem Standard Rpi-Kernel nicht machen, wegen fehlender Latenz-Garantie. Haben die Dinger denn nun einen Hardware-Triggereingang? Sonst können wir noch lange spekulieren... Matthias schrieb: > Geht erstmal darum zu zeigen, dass das einfach und deutlich > billiger zu realisieren ist, als die teuren bisherigen Condiolographen > auf dem Markt. Solche Aussagen treffen leider oft schlussendlich im Engineering-Geschäft seltenst zu, insbesondere wenn es sich um kleine Stückzahlen handelt. Ich würde in deinem Fall, wo es sich auch offenbar um eine akademische Uebung handelt, auf das FPGA verzichten und kleine Schritte mit einem passenden imx6-Brett gehen. Kann sein, dass das Bandbreitenproblem gleich zum Killer wird...aber dann hast du was gelernt. Dazu ist wichtig zu wissen, wie die Kameras ihr Videosignal liefern. Können sie auch Bilder puffern / bzw. arbeiten sie im bulk oder isochronous mode?
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.