mikrocontroller.net

Forum: FPGA, VHDL & Co. FPGA für Kamera-Synchronisation mit Raspberry Pi 3 gesucht


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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..

Autor: Tobias B. (Firma: www.elpra.de) (ttobsen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stephan G. (stephan_g296)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: PittyJ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.