mikrocontroller.net

Forum: FPGA, VHDL & Co. Videostreaming, FPGA-Kamera


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: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich suche zur Erfassung mehrere gleichzeitiger Ereignisse eine 
Entwicklungsplattform für Bildverarbeitung auf FPGA-Basis. Könnt ihr mir 
etwas empfehlen? Im Grunde brauche ich zunächst nur bilder in 1280*960 
oder ähnlich bei einer Bildrate von 60 pro Sekunde. Wichtig ist Echtzeit 
um später  Ereignisse mit mehreren Kameras aufzunehmen, vielleicht auch 
bei höherer Bildrate. Habe bereits von Elphel (www.elphel.com) eine 
interessante Lösung gefunden, gibt es ähnliche Alternativen? Was wäre 
eine optimale Softwarelösung um mehrere Bildquellen zeitgleich 
auszuwerten (Matlab? OpenCV?) und als JPEG zu speichern?

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

Bewertung
0 lesenswert
nicht lesenswert
Bei 1280x960 kommen viele Plattformen in Frage, ich wuerde etwas mit 
Xilinx Zynq Ultrascale+ nehmen, damit hat man eine Fuelle an 
Moeglichkeiten.

Was fuer Kameras wilst du denn anschliessen? Was sind deine 
Schnittstellen? Hier kann man die Auswahl dann wieder etwas eingrenzen.

Autor: A. S. (rava)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich verstehe gerade nicht, wonach du suchst.
Du möchtest Kameras "anschließen" und die Bilder zeitstempeln. Ok. Aber 
dann fragst du nach einer Auswertungsmethodik? Wenn ich mich nicht irre, 
tun sich sowohl Matlab als auch OpenCV mit FPGAs schwer. Also sollen die 
FPGAs die Daten nur wegspeichern und die Auswertung geschieht am 
Rechner? Warum nicht gleich ein Echtzeitbetriebssystem auf den Rechner 
spielen und alles dort laufen lassen?

Oder, falls das unbedingt im FPGA sein muss: was heißt denn 
"Auswertung"? Wie komplex wird's da? Läuft ein neuronales Netz mit 
Millionen von Parametern? Oder wird nur die druchschnittliche Helligkeit 
der Bilder verglichen?

Autor: Videomann (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Andreas schrieb:
> 1280*960

Das ist Tech von vorgestern. Mein Kunde hat schon vor 4 Jahren komplett 
auf HDMI2.0 umgestellt und arbeitet jetzt auf 3840x2160.

Momentan gibt es preiswerte HDMI-fähige Überwachungskameras von den 
Chinesen, die direkt über IP senden. Kriegt man über Kabel bis zu 8 
Stück dran. Auf Wunsch GigEVision. geht mir frame grabbern direkt in den 
PC. Manuelle Verarbeitung mit Video-Chips, DSPs inklusive Bildfusion, 
wenn unbedingt nötig. Brauchen aber nur wenige Kunden.

FPGAs braucht man da gar keine mehr für, es sei denn, dort muss eine 
Sonderverarbeitung rein. Militär z.B.

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für Eure Tipps!

@Tobias:

Das sollten fertige Kameramodule sein, mit paralleller Ausgabe.
Ich habe noch von Micron ein Developer Kit. Schnittstellen zum PC sind 
USB oder Ethernet. Mit günstigen USB kameras habe ich bereits 
experimentiert, da dauert es aber teils bis zu 100ms bis das Bild 
eintrifft. Per Ethernet habe ich vermutlich bessere Karten.

@rava: Die Auswertung soll selbstverständlich auf dem PC laufen. 
Entschuldige die unpräzise Angabe. Das FPGA soll zunächst die Daten nur 
schnell an den PC liefern, am liebsten schon JPEG-komprimiert. Alles 
andere kommt später. Ich muß nur wissen wann die Bilder gemacht wurden 
(auf ms genau). Also brauche ich nur den Zeitstempel vom FPGA und irgend 
eine Möglichkeit in der Software darauf zuzugreifen.

Mir ist auch klar, dass es dafür Fertiglösungen von Machine Vision 
Anbietern gibt, die alleridngs sehr kostspielig werden sobald man sie 
programmieren will.

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Videomann: Ich brauche nicht mehr als die Auflösung, auch wenn es 
Schnee von gestern ist. HDMI ist keine Option...
Schliesslich soll ein einfacher Algorithmus auf dem FPGA laufen, deshalb 
ist das zunächst so angedacht.

Autor: Videomann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Kameras haben heute selber alle FPGAs drinnen, die so ziemlich alles 
können, was man da machen kann und muss. Alles fertig parametrierbar. 
Schau dich mal bei den Industriekameras um. Es gibt allein in DE >10 
Hersteller, die sowas haben.

Autor: janvi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
von Lattice gibts eine VIP Demo Board. (Video Interface Platform) Sind 
auch komplette gleich zwei Sony Sensoren drauf die gleich ein Bild 
abgeben. Die Deep Learn Bibliotheken dazu heissen Caffe und TensorFlow. 
Auswertung auf dem PC ist wegen der Leistungsaufnahme, dem schlechten 
Echtzeitverhalten, der miserablen Zuverlässigkeit, den langen Bootzeiten 
usw. zumindest beim autonomen Fahren und anderen wichtigen Anwendungen 
verpönt

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

das VIP hätte ich jetzt auch empfohlen, allerdings dann mit dem 
separaten Zusatzbrett mit GigE und USB3-Option. Da gibts auch fertige 
Referenzdesigns zum Streaming per YUV-raw oder MJPEG per RTP, guck mal 
nach RFC2435. Auf PC-seite bist du mit gstreamer sehr flexibel was 
Verarbeitung/Speicherung angeht. Wieviel Resourcen braucht deine 
Verarbeitung? Allenfalls wird's irgendwann mit BRAM eng, debayer und 
jpeg sind kleine Speicherfresser.

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, bin jetzt einen Schritt weiter. Das Lattice-Kit paßt wohl ganz gut 
für einen ersten Ansatz. Habe auch schon einen freien JPEG-Encoder bei 
opencores.org gefunden. Die Blockartefakte bei hoher Kompressionsrate 
bereiten allerdings noch etwas Kopfschmerzen. Kennt jemant eine gute 
Alternative? Gibt es verbesserte Algorithmen oder sollte man besser auf 
JPEG2000 gehen?
Ich brauche keine neuronalen Netze oder solches. Der Algorithmus ist wie 
gesagt recht einfach und sollte wenig Blockram benötigen.

Autor: Kameraentwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm sonst h264, JPEG und JPEG2000 sind nicht low latency. Die Bloecke 
sind bei h264 kleiner und stoeren weniger. Opencores kannst vergessen. 
Guck mal bei https://github.com/bcattle/hardh264.

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weiss nicht, was jetzt bei euch als "low latency" gelten soll, aber die 
minimalen 8 Bildzeilen (und ein paar zerquetschte) bei JPEG sind mehr 
als ausreichend, gemessen daran, dass auch bei einem 
Rolling-Shutter-Sensor intern schon einiges an Verzögerung anfallen 
kann. Das ist allerdings bei den meisten Sensoren, die Rohdaten 
ausgeben, deterministisch (also Zeitpunkt der Aufnahme bestimmbar). Wozu 
brauchst du dann noch low latency?
Bei JPEG2k kriegt man's mit Tiling auch in die Richtung, zumindest wenn 
man einiges vom Standard abspeckt, hat dann aber auch wieder irgendwann 
Block-Artefakte.
Bei JPEG kann man mit cleverem Residual-Coding die Block-Artefakte 
wegbekommen. Ist aber nicht mehr Standard und nicht mal eben so 
implementiert. Bin gespannt, wie sie's beim (zukünftigen) JPEG XS 
hinkriegen.
Bei h264 ist "low latency" recht "bedingt" und der Encoder deutlich 
komplexer.
Viel Spass kannst du bei den opencores-Sachen aber schon mal mit 
effizientem Streaming haben. Es macht einen grossen Unterschied, ob ein 
Codec nur ein "Beschleuniger" ist oder richtig synchron arbeitet. 
Ansonsten gilt, wie fast immer: Zeit ist Geld (wenn nicht Lernprojekt), 
darum würde ich mich auf den Kernalgo fokussieren und die Kompression 
wenn nötig ganz am Schluss dazukaufen.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas schrieb:

> Per Ethernet habe ich vermutlich bessere Karten.
>
> @rava: Die Auswertung soll selbstverständlich auf dem PC laufen.

Da du das eine erkannt hast und das andere sowieso willst, dann verstehe 
ich nicht, wozu jetzt noch ein FPGA gut sein soll.

Es gibt doch fix und fertige Überwachungskameras, die einen RTSP-Stream 
liefern. Und selbst in recht hoher Qualität sind die nichtmal mehr allzu 
teuer (~400€ für full HD). Und sie enthalten bei diesem Preis sogar 
schon eine fertige Entzerrung für die Optik, Bewegungserkennung und 
weiteren Schnickschnack, den man benutzen kann, aber nicht benutzen 
muss...

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas schrieb:

> @rava: Die Auswertung soll selbstverständlich auf dem PC laufen.
> Entschuldige die unpräzise Angabe. Das FPGA soll zunächst die Daten nur
> schnell an den PC liefern, am liebsten schon JPEG-komprimiert. Alles
> andere kommt später. Ich muß nur wissen wann die Bilder gemacht wurden
> (auf ms genau). Also brauche ich nur den Zeitstempel vom FPGA und irgend
> eine Möglichkeit in der Software darauf zuzugreifen.

Vergiss das FPGA.

https://www.ximea.com/en/products/xilab-application-specific-custom-oem/embedded-vision-and-multi-camera-setup-xix/sony-imx174-fast-color-industrial-camera

Da bekommst Du per PCIe die rohen Kameradaten direkt mit 10 MBit/s in 
Deinen Hauptspeicher geschrieben. Ohne weitere Latenzen. Direkter gehts 
nicht. Triggern kannst Du per Software oder per Hardware 
(Trigger-Signal-Inputs und Outputs vorhanden). Dann weißt Du wirklich, 
wann das Bild entstanden ist. Global Shutter ist dann auch nützlich.

fchk

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Da du das eine erkannt hast und das andere sowieso willst, dann verstehe
> ich nicht, wozu jetzt noch ein FPGA gut sein soll.

Es gibt schon eine Reihe von Sachen, die man mit einem Bild on the fly 
machen kann (und auch muss), bevor es in die Bildauswertung auf einen 
Rechner geht. Das haben schon einige lernen müssen. Idealerweise packt 
man die Daten, die der FPGA aus dem Bild ermittelt in den Datenstrom zum 
PC mit hinein. Wenn allerdings die Karte nur den Videokanal hat, dann 
wird das wiederum etwas tricky, geht aber.

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.

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