mikrocontroller.net

Forum: Digitale Signalverarbeitung / DSP Gezieltes auslesen von Cmos Kameras ohne PC


Autor: Berni H. (bimmbamm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo alle zusammen,
erstmal ein grosses lob fuer das forum hier, hab mich schon fleissig 
eingelesen, bin echt begeistert, habe aber noch eine grundlegende frage 
die ich noch nicht loesen konnte.
fuer meine semsterarbeit soll ich mit hilfe von kameras einen sich 
bewegenden leuchtpunkt tracken, dessen erwartete position bekannt ist.
mein gedanke war jetzt, 2 cmos kameras zunehmen und genau den 
pixelbereich auslesen in dem ich den lichtpunkt erwarte und dann schauen 
ob hell oder dunkel und dementsprechend einen befehl ausfuehren. Die 
Frage ist jetzt halt ob das so moeglich ist wie ich mir das vorstelle 
und vom aufwand auch machbar. Die Framerate sollte aber nicht unter 
100fps liegen, der daumennagel grosse leuchtpunkte waere circa 50cm von 
der camera entfernd. die auswertung wuerde ich gerne ohne rechner 
machen, sprich auf MC-Basis. hier im forum habe ich jetzt gelesen das 
normale AVRs zulangsam waeren, die alternative waeren dann wohl FPGA 
oder DSP oder?

bin auf dem gebiet ziemlicher neueinsteiger und wuerde mich freuen, wenn 
mir jemand dabei helfen kann :)
vielen dank schonmal,
gruss berni

PS: Hoffe mal das ich hier in diesem Unterform richtig bin..

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
schau mal hier unter "meine diplomarbeit"

und der trackt mehr als nur n punkt ;)

http://thomaspfeifer.net/

lg Benedikt

Autor: Berni H. (bimmbamm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
whoa, das ging ja schnell, hatte das schon im forum gefunden und mir den 
link notiert, werde mir heute abend das mal genau anschauen was der 
gemacht hat.

gruss berni

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum Laser-Tracking gibt's auch den ziemlich populaeren Roboter SRV1 bei 
www.surveyor.com, die Kamera des Roboters gibts auch einzeln, bzw. als 
Stereo-Loesung. Fuer den Preis bekommt man ne ganze Menge und das System 
ist ziemlich ausgereift. Nachteile sind nur fehlendes Ethernet, 
Entwicklung unter uClinux ist ohne schnelles JTAG also etwas muehsam.

Gruss,

- Strubi

Autor: Sebastian B. (sfreak) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

ich hab auch etwas aehnliches aufgebaut: Eine 
Linien(Fahrspur-)Erkennung. Dazu hab ich ein Blackfin BF537-EZKit 
benutzt und an den PPI(Parallel-)Port eine CMOS-Kameramodul 
angeschlossen (braucht nur eine kleine Adapterplatine).

So hat man viel mehr Schnittstellen, aber das SRV1 ist vieeeel kleiner 
:-)

100fps klingt erstmal viel... aber wenn du dich bei der Aufloesung etwas 
einschraenkst oder nur einen Bildbereich ausliest sollte das auch gehen 
mit dem entsprechenden Sensor.

Sebastian

Autor: Berni H. (bimmbamm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja so in der Richtung hatte ich mir das uach überlegt, wie aufwändig ist 
sowas denn, hab da wie gesagt nicht so die Ahnung/Überblick, würde das 
aber gerne mal abschätzen :D

schönen abend, gruß bernhard

Autor: Sebastian B. (sfreak) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Berni H. schrieb:
> ja so in der Richtung hatte ich mir das uach überlegt, wie aufwändig ist
> sowas denn, hab da wie gesagt nicht so die Ahnung/Überblick, würde das
> aber gerne mal abschätzen :D

Also mit dem SRV1 der Einstieg denk ich recht leicht weil es fertige 
Beispiele gibt. Auch die Arbeit mit dem Evaluation-Board ist nicht soo 
kompliziert, insbesondere wenn man sich Kameramodule aussucht fuer die 
es im uCLinux schon Treiber gibt.

Wenn man dann aber etwas eigenes bauen will steht nochmal die 
Einarbeitung in das Linux-Entwicklungssystem oder gar die Entwicklung 
von Standalone-Programmen an, und das ist schon nicht ganz ohne. Man 
sollte schon eine gewisse affinitaet zu kryptischen Kommandozeilentools 
haben, sonst macht das wenig Spass. Beispiele gibts zwar jede Menge, 
aber die Dokumentation ist wie bei Linux ueblich entweder voellig 
veraltet oder nicht vorhanden.

Wenn man sich aber erstmal eingearbeitet hat hat man auch ein sehr 
leistungsfaehiges System zur verfuegung. Fuer mich hat sichs auf jeden 
Fall gelohnt.

Beziffern kann ich den Aufwand aber nicht. Das haengt doch sehr von 
deinen Vorkenntnissen ab...

Autor: Berni H. (bimmbamm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen dank erstmal, im moment versuche ich gerade herauszubekommen, ob 
es möglich ist, dynamisch bestimmte bereiche des Cmos-Sensors 
auszulesen. Ich stell mir das so vor, das ich die kamera frage, ist 
pixel an koordinate XY hell, ja oder nein, das würde mir schon langen. 
Verarbeiten wollte ich die Daten, da es im bereich 100hz sein sollte, 
mit einem DSP oder FPGA (normale Mikrocontroller wie Atmega kommen für 
sowas ja nicht in frage denk ich), wobei ich noch nciht genau weis was 
man da nimmt, da mach ich mich gerade schlau.
Wäre das so möglich wie ich mir das vorstelle?

schönen gruß ;D

Autor: sfreak mobil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also normalerweise kommen aus einem CMOS Kameramodul einfach alle Pixel 
Zeile für Zeile hintereinander als ein durchgehender Datenstrom. Bei 
manchen Kameras kannst du den ausgegebenen Bildbereich einschränken, 
aber dass das bis auf 1 Pixel runter geht glaub ich eher nicht (ins 
Datenblatt deines Wunschsensors gucken).

Das einfachste Vorgehen bei einem DSP wäre das gesamte Videobild 
einzulesen und im Speicher abzulegen (geht meist vollständig über DMA, 
also ohne Software-Eingriff direkt in den Speicher). Und sich hinterher 
aus dem Speicherbereich die interessanten Pixel rauszupicken.

Beim Einlesen selber kann man (über die DMA-Konfiguration beim Blackfin) 
u.U. auch steuern welche Zeilen gespeichert und welche verworfen werden 
sollen. Bei einem Blackfin mit SDRAM hat man aber für Experimente 
erstmal mehr als genug Speicher und Speicherbandbreite um einfach alles 
wegzuschreiben. Dann wird die Software erstmal einfacher und flexibler, 
optimieren geht spaeter immer noch.

Im FPGA dagegen musst du die ganze Einlese-Geschichte sowieso selber 
schreiben und dabei die Zeilen und Pixel mitzählen. Dann hast du auch 
gleich alle nötigen Informationen um nur einzelne Pixel/Zeilen/Bereiche 
abzuspeichern. Da schreibst du dann die DMA-Funktionalität quasi selbst 
und kannst das ganze beliebig genau kontrollieren. Aber das 'alles 
selbst schreiben' ist natuerlich erstmal deutlich mehr Arbeit und 
erfordert noch tiefgreifenderes Verständnis. Ich denke ist es sinnvoll 
mit einer fertigen, funktionierenden Lösung anzufangen. Danach weisst du 
eher was geht und was du brauchst...

Beide beschriebene Verfahren nehmen an, das die Kamera einfach doof 
immer wieder ihren Datenstrom ausspuckt. Ich vermute das du für dein 
gewünschtes Verhalten schon ein sehr viel intelligenteres Modul benutzen 
müsstest das die ganze Bildspeicherung intern nochmal hat. Damit hab ich 
aber keine Erfahrung.

Schau dir vielleicht mal das CMUcam Projekt an, das ist noch ein 
bisschen simpler und kann auch eine ganze Menge (100fps weiss ich nicht, 
aber ein Paar Punkte verfolgen geht damit problemlos).

Autor: Berni H. (bimmbamm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank, denk das ich das ganze jetzt mit einem Blackfin umsetzen 
werde, da das ganze denk ich einfach in C umzusetzen ist. Da meine Daten 
über Ethernet reinkommen, dachte ich an den BF537. Die Kamera verbinde 
ich dann über PPI, im moment warte ich noch auf eine Antwort ob mein 
Cmos Sensor das dynamische auslesen eines bestimmten bereichs zulässt, 
das wäre ja dann ganz fein.Bezweifel nämlich ob die Datenflut sonst 
verarbeitet werden kann wenn alle 10ms en 1MP Bild kommt, sonst müsste 
man halt extern en ram anschließen oder so...
Mit dem BF537 müsste das ja klappen was ich will oder? Welche 
Taktfrequenz bräuchte ich denn? Gibt es an dem DSP einen analogen 
ausgang mit dem ich einfach über "strom an/aus" mit nem ATMEga 
kommunizieren kann? Bin da mit den ganzen Schnittstellen im Datenblatt 
nicht ganz klar gekommen.

Autor: Wolfgang Kopp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi. Kameramodule, wie oben genannt, verwenden und dann mit einer FPGA + 
Controller Kombination auswerten, finde ich sinnvoll. Ggf. könnte man 
ein FPGA Demoboard mit Softcpu dafür hernehmen. Aus den Kameramodulen 
bekommt man meist einfach Pixel und Takt, also sehr einfach 
anzuschliessen. Und im FPGA mitzählen wäre auch keine Hexerei. Damit 
kommt man mit der Rechenleistung allemal durch. Allerdings gibt es 
höhere Aufwände, wenn man sich erst überall einarbeiten muss.

Wolfgang

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welchen Sensor benutzt Du denn?
Die meisten CMOS-Sensoren koennen eigentlich 'region of interest' (ROI).
Der BF537 ist eine gute Wahl, allerdings ist der BF527 billiger und noch 
flexibler, wenn Du nicht gerade CAN brauchst - denn er hat zusaetzlich 
noch USB.
Analoge I/Os gibts nur beim BF527C, aber zur Kommunikation mit externen 
Chips empfiehlt sich ja auch eher was digitales (SPI, i2c, SPORT...) 
Ob/Wie man einen Atmega als 'slave' fahren kann, weiss ich allerdings 
nicht.
Zum Ram: Externes RAM wuerde ich auf jeden Fall verwenden, sonst wird's 
ganz schnell eng. Zum Einlesen des Sensors per PPI musst Du die 
Grenzfrequenz des PPICLK beachten (SCLK / 2). Unter uClinux sind es 
praktisch eher SCLK/3.
Beispiele zu einer video buffer queue mit dem PPI findest Du z.B. hier: 
http://www.section5.ch/forum/viewtopic.php?f=2&t=118 oder etwas 
einfacher unter http://www.surveyor.com/cgi-bin/yabb2/YaBB.pl.

Gruesse,

- Strubi


PTB-7819 whirlpool 
19BD7C71293C1B9869F4A5E9A7E260C17FBB1EB296B68B3E195713A4A6DF43C5
27B46AABB1787CCA09B8FC4907F3617B8EF98605181D3D94171276289831AE49

Autor: Sebastian B. (sfreak) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Berni H. schrieb:
> Mit dem BF537 müsste das ja klappen was ich will oder? Welche
> Taktfrequenz bräuchte ich denn? Gibt es an dem DSP einen analogen
> ausgang mit dem ich einfach über "strom an/aus" mit nem ATMEga
> kommunizieren kann? Bin da mit den ganzen Schnittstellen im Datenblatt
> nicht ganz klar gekommen.

Naja, mit dem Datenblatt musst du dich schon erstmal noch etwas 
intensiver beschaeftigen, und moeglichst alle Schnittstellen grob 
verstehen und zuordnen koennen... sonst seh ich schwarz fuer alle 
komplexeren Projekte.

Mal ne ganz bloede Frage: Wenn du sowieso einen Blackfin verwenden 
willst, wozu brauchst du dann noch einen AVR? Alles was der AVR kann 
macht der Blackfin noch locker so nebenbei (nur einen internen 
AD-Wandler gibts nicht)...

Wenn du ernsthaft noch einen AVR brauchst kannste etweder einfach ueber 
GPIOs (General purpos I/O, wie die Pin/Ports beim AVR) kommunizieren 
oder ueber eine der seriellen Schnittstellen: UART, I2C, SPI.

Aber du klingst noch nicht so als waerst du mit dem Verstaendnis der 
ganzen Thematik und insb. dem Blackfin besonders weit... von daher 
wuerde ich empfehlen erstmal mit einem fertigen und funktionierenden 
Evaluationboard rumzuspielen oder eben doch ein fertiges Modul wie 
CMUcam zu verwenden.

Sebastian

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]
  • [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.