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..
schau mal hier unter "meine diplomarbeit" und der trackt mehr als nur n punkt ;) http://thomaspfeifer.net/ lg Benedikt
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
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
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
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
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...
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
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).
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.
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
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
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
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.