Hallo zusammen,
ich bin auf der Suche nach einer kompakten Lösung für zwei MIPI Kameras.
Ziel soll es sein, ein möglichst generisches Design zu haben, womit man
verschiedenste Sensoren ansprechen kann. Also die Sensoren via I2C z.B.
mit einem Registerdump File parametrisieren und dann die Bilder abholen.
Ich habe schon verschiedenste Lösungen ergoogelt, aber vielleicht gibt
es hier noch einen guten Tipp?
Hier eine Idee mit Snapdragon, aber dazu bräuchte ich viel
Softwarearbeit und ein Basisboard.
https://www.intrinsyc.com/computing-platforms/open-q-835-usom/
intrinsyc bietet zwar sowas an, aber als ITX leider etwas zu groß.
Klassische Frame Grabber können das auch, aber auch die sind oft zu
groß.
Hat jemand noch eine Idee?
Vielen Dank!
Kämest Du mit einer Schnittstelle aus, reichte ein beliebiger Raspberry
Pi. Der hat nämlich eine CSI-Schnittstelle.
Sofern es bei Deiner Anforderung nicht um stereoskopische Aufnahmen
geht, sollten möglicherweise zwei Pis für zwei Kameras auch verwendbar
sein.
Ansonsten könnte die Firma Framos für derartige Anforderungen ein
Ansprechpartner sein, die sind auf Kamera-/Sensor-Dinge spezialisiert.
Moin,
das Lattice Semiconductor VIP/EVDK hat von Haus aus zwei IMX214 inkl.
Crosslink on Board. Allerdings eine andere Schiene: Statt fertigem SoC
sitzt ein FPGA dahinter. Wenn dein Fokus aber generell auf den Kameras
und weniger auf Integration/Linux liegt, kommst du mit den div.
Referenzdesigns sicher auf nen grünen Zweig. Mit einem Haken: die
Sensoren sind mager dokumentiert.
Eigentlich ist ja ein Handy nix anderes... die haben ja oft mindestens
zwei Kameras.
So ein HDK wäre toll:
https://www.cnx-software.com/2019/03/28/qualcomm-snapdragon-855-hdk/
Aber da mache ich mir echt Gedanken, wie ich da die GPIOs usw.
ansprechen soll, geschweige denn dann die Bilddaten in Echtzeit über USB
oder Ethernet wegbekommen kann, um sie auf einem PC/Laptop anzuzeigen/zu
verarbeiten.
Da fehlt mir leider die Erfahrung, wie man mit so einem Android OS
umgehen kann und welche Möglichkeiten/Freiheiten/Dokumentation man hat.
Der PI ist für derartige Sachen zu schwach auf der Brust (denke ich?).
So 6Gb/s sind schon notwendig pro Kamera...
Framos schaue ich mir mal an!
Vielen Dank!
Hallo Strubi,
die FPGA Lösungen habe ich auch schon gesehen, dort mache ich mir aber
noch weit mehr Gedanken, was die Software angeht.
Diese wird ja ein Großteil des Paketes ausmachen, so dass man die
Sensoren konfigurieren kann und die Bilder in worst case auch als RAW
verarbeiten kann.
Da erhoffe ich mir, bei den Consumer Plattformen mehr schon fertige
Lösungen finden zu können, als bei jder selbstgestrickten FPGA Lösung.
Vielen Dank dennoch - ich schaue es mir nochmal an, vielleicht habe ich
ja eine Erleuchtung.
Hi Bernd,
mit den div. Consumer-SoCs ist die Sache nach meiner bisherigen
Erfahrung teils viel komplexer als mit den FPGA-Ansätzen, sobald es in
die Details geht. Das liegt v.a. an den völlig unterschiedlich
implementierten V4L2-layern (video for linux) und Sensorentreibern und
besagter Nicht-Doku. Wenn du ein passendes System findest und es für
deine Zwecke 'gehackt' kriegst, kommst du ev. schnell zu einer Lösung,
aber ob du die Hardware dann auch gebaut bekommst, ist ein anderes Thema
(Raspberry-Pi-Ansätze sind da unbrauchbar). Würde da IMX6 oder Nvidia
Tegra anpeilen. Bei den meisten sonst angepriesenen Mobile SoCs ist man
mehr mit Reverse engineering als mit Entwickeln dran..
Für Industrielösungen: Crosslink und gut dokumentierte/unterstützte
Application-prozessoren machen mehr Spass.
Fürs VIP gibt es sonst div. Streaming-Lösungen von Stereo-Video mit
draufladbaren konfigurierbaren Encoder-SoCs (YUV video, mjpeg, ...)
Bernd schrieb:> Eigentlich ist ja ein Handy nix anderes...> die haben ja oft mindestens zwei Kameras.
Wäre das für dich vielleicht eine Lösung?
> So ein HDK wäre toll:> https://www.cnx-software.com/2019/03/28/qualcomm-snapdragon-855-hdk/
Wenn du nicht gerade große Lust hast, dich lange und tiefgreifend mit
Qualcomm-Chipsätzen und deren Kamerasoftware zu befassen, dann rate ich
dir davon stark ab. Du wirst daran sehr lange Spaß haben.
Ich weiß, dass ich welchen hatte und auch die nächste Zeit noch haben
werde.
> Aber da mache ich mir echt Gedanken, wie ich da die GPIOs usw.> ansprechen soll, geschweige denn dann die Bilddaten in Echtzeit> über USB oder Ethernet wegbekommen kann, um sie auf einem PC/Laptop> anzuzeigen/zu verarbeiten.
Die GPIOs werden im Devicetree eingetragen und sind von Linux aus ganz
normal ansprechbar.
Das Kamerasystem ist enorm komplex. Erwarte nicht, dass irgendwo ein
roher Datenstrom mit deinen Bilddaten rausfällt: Die Bandbreite ist
enorm und die Verarbeitung findet in Hardware statt. Wenn die Pipeline
passend eingerichtet ist, schaltest du vorne den Sensor an und hinten
fällt MPEG, JPEG, YUV oder RAW raus, mit verschiedenen Algorithmen nach
deinen Wünschen gefiltert.
Die Performance von so einem Chipsatz, wenn ordentlich gekühlt, ist
durchaus mit einem PC/Laptop vergleichbar. Du kannst also die
Verarbeitung eigentlich gleich da lassen. Mit dem Hexagon bekommst du
auch einen DSP dazu, den du programmieren könntest, wenn du die
Android-Plattform unter deiner Kontrolle hast.
> Da fehlt mir leider die Erfahrung, wie man mit so einem Android OS> umgehen kann und welche Möglichkeiten/Freiheiten/Dokumentation man hat.
Schau dir die Camera2-API an und spiele damit ein bisschen rum. Die API
ist ebenfalls komplex, aber einigermaßen flexibel. Du hast relativ wenig
Einfluss auf den Sensor selbst (zumindest bei den Herstellerlösungen).
Referenz:
https://developer.android.com/reference/android/hardware/camera2/package-summary> Der PI ist für derartige Sachen zu schwach auf der Brust (denke ich?).> So 6Gb/s sind schon notwendig pro Kamera...
Welche Auflösung bei welcher Bildrate hättest du denn gern?
Und wie willst du die Daten überhaupt aus dem System rauskriegen?
Mein Gefühl sagt, dass der SDM855 problemlos 4K2K bei 240 fps
hinbekommt, vermutlich sogar mehr. Ob der dahinter liegende Flash das
auch kann... eher fraglich. Unkomprimiert definitiv nicht.
