Hallo, Wir wollen einen Roboter das "sehen" beibringen ;) ... das Herz ist ein ATMEGA. Wir haben ein ein Kamaramodul gedacht. Für erste Tests schaue ich mich im Netz um. Was sagt ihr dazu (außer, dass es aus china kommt ;)) ... Wäre es geeignet? http://cgi.ebay.de/CMOS-PLATINEN-CAMERA-BOARD-SWARZ-WEISS-352L-LENS-NEU_W0QQitemZ160191505681QQihZ006QQcategoryZ12949QQssPageNameZWDVWQQrdZ1QQcmdZViewItem
> Wäre es geeignet? Eher nicht. Wie willst du ein analoges Videosignal in einen Atmega reinschaffen und ggf. dort auch noch auswerten? Da müssen Kameras her, die bereits digitale Daten ausgeben. Je nach beabsichtigter Auswertung auch leistungsfähigere µCs. http://www.cs.cmu.edu/~cmucam/ http://www.ctbot.de/forum/cmucam-2-t60.html
> Wie willst du ein analoges Videosignal in einen Atmega reinschaffen geht analog: http://www.youtube.com/watch?v=G2F4jhsRtF4&feature=related nur primitive Verarbeitung aber es geht.
Respekt. Hätte ich nicht vermutet, dass das geht http://www.roboternetz.de/phpBB2/viewtopic.php?p=307897#307897
Wenn man sich den Code anschaut, dann merkt man dass da ziemlich gepfuscht wurde (mangels Wissen). Der Programmierer verwechselt andauernd horizontal und vertikal und dies hier ist der Code: do *pixelzeiger=ADCH; while (*pixelzeiger++ > 20); Ob der ADC fertig ist, interessiert nicht, es wird trotzdem gespeichert. Von den 60 Messwerten sind daher nur etwa etwa 20 real (sieht man auch deutlich an der dort geposteten PDF). Das macht sagenhafte 16 Pixel pro Zeile. Theoretisch sind bei 16MHz bis zu 33 Pixel möglich, allerdings läuft der ADC dann mit 8MHz statt maximal 250kHz. Mit einer anderen Technik geht aber sogar noch mehr mit einem AVR. Theoretisch sind 864 x 576 Pixel möglich, die Messung funktioniert nur mit einem Standbild bzw, sich sehr langsam ändernden Bild, und dauert bei voller Auflösung über 30s. Und das bei einem AVR der lediglich mit 16kHz Samplerate arbeitet. Dazu startet man den links oben und tastet Zeile für Zeile des Bildes ab. Danach fügt man einen kleinen Offset zu der Startzeit für den ADC hinzu, und tastet danach die 2. Spalte ab usw. Mit HSync an Input Capture Eingang, und einem Timergetriggerten ADC kann man den Startzeitpunkt auf 1 Takt genau anpassen. Wenn ich also nur eine Schatte Zeile erkennen wolle, würde ich die Kamera um 90° drehen und die Zeilen verwenden. Wenn man nur die Halbbilder auswertet, hat man 288 Pixel Auflösung bei 50 Messungen/s. Und der AVR langweilt sich, d.h. das ganze läuft im Hintergrund.
Hallo, die Variante, Spaltenweise einzulesen, hab ich vor Jahren mal am C64-Userport gebaut, in s/w narürlich. 2-Bit-Wandler mit 3 Komparatoren. Umwandlung dann in die beim C64 möglichen 4 Graustufen. Wäre wirklich mal interessant, was ein AVR da schafft. Gruß aus Berlin Michael
Angehängte Dateien:
-
adc_mega48.jpg
59 KB
Michael U. wrote:
> Wäre wirklich mal interessant, was ein AVR da schafft.
Die Analogbandbreite liegt irgendwo um 1MHz. So sieht ein Bild einer
NTSC Kamera mit voller Auflösung aus.
Die benötigte Zeit beträgt Spalten / Framerate, das doppelte für
Vollbilder wenn das ganze Interlaced ist. Daher ist diese Technik leider
nur für Standbilder geeignet.
>Wenn man sich den Code anschaut, dann merkt man dass da ziemlich >gepfuscht wurde (mangels Wissen). Eine ziemlich gewagte Aussage. Das jemand ein wenig Spaghetti-Code produziert, hat nichts damit zu tun, das er keine Ahnung hat. Meiner Meinung ist es eine reife Leistung, auf die Idee zu kommen, eine Kamera an einen AVR ohne Zusatzhardware anzuschließen. Wie sieht Deine Hardware aus? >Mit einer anderen Technik geht aber sogar noch mehr mit einem AVR. >Theoretisch sind 864 x 576 Pixel möglich, die Messung funktioniert nur >mit einem Standbild bzw, sich sehr langsam ändernden Bild, und dauert >bei voller Auflösung über 30s. Wie kommst Du auf die Daten ?
Noch eine Lösung: http://www.roboterclub-freiburg.de/AtmelAVR/Hardware/AtmegaKamera/AtmegaKamera.html
ajax wrote: >>Wenn man sich den Code anschaut, dann merkt man dass da ziemlich >>gepfuscht wurde (mangels Wissen). > > Eine ziemlich gewagte Aussage. Das jemand ein wenig Spaghetti-Code > produziert, hat nichts damit zu tun, das er keine Ahnung hat. Was hat das mit Spaghetti Code zu tun ? Es geht darum, dass der ADC nur 20x pro Zeile misst, aber 60x pro Zeile ausgelesen wird, und dann behauptet wird man bekomme 60 Pixel Auflösung. > Meiner > Meinung ist es eine reife Leistung, auf die Idee zu kommen, eine Kamera > an einen AVR ohne Zusatzhardware anzuschließen. Das sehe ich genauso. Viele hatten die Idee schon, einige Ideen funktionieren auch mehr oder wenige, nur sind die meisten in der Praxis eher nicht zu gebrauchen (so auch meine, denn wann hat man schon ein Standbild und möchte 30s warten ? Wie man sieht bin ich nicht der erste der diese Idee hat.) > Wie sieht Deine Hardware aus? LM1881 als Syncseparator, HSync am Input Capture Pin, VSync am INT0 Pin, Videosignal am ADC Pin. >>Mit einer anderen Technik geht aber sogar noch mehr mit einem AVR. >>Theoretisch sind 864 x 576 Pixel möglich, die Messung funktioniert nur >>mit einem Standbild bzw, sich sehr langsam ändernden Bild, und dauert >>bei voller Auflösung über 30s. > > Wie kommst Du auf die Daten ? 16MHz Zeitauflösung * 54µs für eine Videozeile ergibt 864 Pixel. Man benötigt 864 Frames um alle Spalten abzutasten. Bei 25Hz ergibt das etwa 34,6s.
Hallo Mikrokontroller-Fans Ich muss schon sagen, ich bin doch etwas enttäuscht. Ich hatte erwartet, dass wenigstens einer von euch, speziell Benedikt, sich aufrafft und meine Angaben wenigstens im Ansatz durch einen Selbstversuch überprüft. Und bei Erfolg einen smarten, gut dokumentierten Code abliefert. Aber da ja bekanntlich nicht sein kann, was nicht sein darf, ist der Mega32 auf meinem RP6 wohl eine Fehlpressung. Glückliches und erfolgreiches 2008 euch allen. Gruß mic
>dass wenigstens einer von euch, speziell Benedikt, sich aufrafft und >meine Angaben wenigstens im Ansatz durch einen Selbstversuch überprüft. >Und bei Erfolg einen smarten, gut dokumentierten Code abliefert. Wie, andere sollen Ihre Freizeit opfern und für Dich was programmieren ? Da könnte ja jeder kommen ...
mic (radbruch) wrote: > Ich muss schon sagen, ich bin doch etwas enttäuscht. Ich hatte erwartet, > dass wenigstens einer von euch, speziell Benedikt, sich aufrafft und > meine Angaben wenigstens im Ansatz durch einen Selbstversuch überprüft. Wiso soll ich etwas in der Praxis überprüfen, wenn sogar die Theorie sagt, dass es nicht gehen kann ? Du lässt den AVR mit 8MHz laufen. Der ADC Prescaler ist minimal auf 2 einstellbar, macht also 26CPU Takte bzw 3,25µs für eine ADC Abtastung. Und da eine Bildzeile 64µs lang ist, sind niemals 50 Wert pro Zeile möglich. Das ist nunmal Fakt. Der ADC des AVRs ist für sowas eben nicht ausgelegt. Mit ein paar Tricks kann man das ein wenig umgehen, aber dafür hat man andere Nachteile (es dauert sehr lange).
Hallo, oder einfach die Philips DC-3840 von meiner Homepage nehmen. Diese hat eine serielle Schnittstelle und liefert auch Rohdaten. Gruß Uli
@ Ulrich Radig Hab mir deine Kamera gestern zufällig mal angeschaut, die ist also quasi für ein Handy gedacht. Für 5.48 Euro bekommt man so ein Modul inklusive Gehäuse von dir? Gibt es dafür ein Datenblatt?
Hallo, das Protokoll ist auf meiner HP beschrieben, diese Kamera entspricht in etwa der C328 für 48€. Diese Kamera funktioniert ohne Probleme an meinem Webserver. Ein Testcode für einen Mega32/644 gibt es auch schon. Gruß Uli
Hallo nochmal Ich brauche niemanden, der für mich seine Freizeit opfert und für mich Programme schreibt, ich möchte das als AVR-Einsteiger selbst lernen. Mich hätte einzig interessiert, wie ein "Profi" aus euren Reihen das umgesetzt hätte. Wie hoch die maximale Samplefrequenz des ATMega-ADCs sein kann, dürfte euch vielleicht doch verblüffen. Hier beziehe ich mich auf die avr-freaks: http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=33070 Ob das Einlesen eines BAS-Signals nun wirklich so funktioniert wie ich das beschreibe, ob es völlig unmöglich ist oder gar nutzlos, weil es auch andere günstige Kameras gibt, ist mir recht egal. Ich hatte meinen Spaß beim "Entwickeln" und habe dabei auch noch einiges über die AVRs und ihre Anwender gelernt. Gruß mic
Und nochmal hallo Nun hat mir der Besuch in eurem Forum doch noch eine Erkenntniss gebracht. Das mit den Taktzyklen verstehe ich nämlich auch nicht wirklich, aber ich vermute, wenn ADCH ausgelesen wird, bevor der ADC fertig ist, bricht er die aktuelle Wandlung ab. Ich habe jetzt meinen C-Code untersucht und folgendes zusammengezählt: cli(); do *pixelzeiger++=ADCH; while (count_pixel--); sei(); 1 003c F894 cli ; Clocks 2 /* #NOAPP */ 3 .L4: 4 .LM15: 5 003e 85B1 in r24,37-0x20 ;1 6 0040 F701 movw r30,r14 ;1 7 0042 8193 st Z+,r24 ;2 8 0044 7F01 movw r14,r30 ;1 9 0046 1150 subi r17,1 ;1 0 0048 D0F7 brcc .L4 ;1/2 1 .LM16: 2 /* #APP */ ;__ 3 004a 7894 sei ;8 Also benötige ich 8 Takte oder (mit meinem 8MHz-ATMega32) 1us um einen Wert einzulesen. Da das reine Bildsignal knapp 60us dauert, bin ich mit fast 60 Werten pro Zeile scheinbar doch im grünen Bereich. Gruß mic
Leider weiß ich nicht, wie man hier einen Beitrag editieren kann deshalb schreibe ich einfach mal weiter. Wenn der ADC pro Takt ein Bit wandeln kann, würde er mit prescaler /2 genau 4 Bit wandeln können, bis ich den nächsten Wert auslese. Da ich vom linksbündigen Ergebniss aber nur die oberen 4 Bit auswerte, würde die Rechnung genau aufgehen. Allerdings müßte man dabei die 2,5us "overhead" pro Wandlung unter den Tisch kehren. Eine 10-bit-Wandlung dauert laut Datenblatt 13 Zyklen. 2,5us ist wohl die Zeit für das Kopieren ins Sample&Hold-Register :( Irgendwas muss aber dran sein, denn im am Threadanfang erwähnten Video kann die ascii-Linie wirklich 40 verschiedene Positionen haben (Fensterbreite 80 Zeichen), und der Rand der Linie macht tatsächlich Einer-Sprünge: http://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=307897#307897 Geile Teile diese AVRs Gruß mic
Gameboy-Kamera? Liefert zwar bescheidene Bilder, aber bei richtiger Einstellung lässt sich einiges herausholen. Jedenfalls liefert die GB-Cam schon mehr als genug Daten, um den AVR richtig auszulasten.
mic (radbruch) wrote: > Nun hat mir der Besuch in eurem Forum doch noch eine Erkenntniss > gebracht. Das mit den Taktzyklen verstehe ich nämlich auch nicht > wirklich, aber ich vermute, wenn ADCH ausgelesen wird, bevor der ADC > fertig ist, bricht er die aktuelle Wandlung ab. Nicht ganz. Der ADC wandelt weiter, aber du liest das Ergebnis der letzen Messung erneut aus. > Also benötige ich 8 Takte oder (mit meinem 8MHz-ATMega32) 1us um einen > Wert einzulesen. Da das reine Bildsignal knapp 60us dauert, bin ich mit > fast 60 Werten pro Zeile scheinbar doch im grünen Bereich. Du liest zwar 60 Werte, bekommst aber nur etwa 17 echte Messwerte. > Wenn der ADC pro Takt ein Bit wandeln kann, würde er mit prescaler /2 > genau 4 Bit wandeln können, bis ich den nächsten Wert auslese. Da ich > vom linksbündigen Ergebniss aber nur die oberen 4 Bit auswerte, würde > die Rechnung genau aufgehen. Allerdings müßte man dabei die 2,5us > "overhead" pro Wandlung unter den Tisch kehren. Eine 10-bit-Wandlung > dauert laut Datenblatt 13 Zyklen. 2,5us ist wohl die Zeit für das > Kopieren ins Sample&Hold-Register :( So ganz stimmt das nicht. Der ADC wandelt immer 10bit, nur eben schneller. Und wenn es zu schnell wird, macht er dabei Mist. Ich habe dies selbst schonmal ausprobiert und meiner Erfahrung nach, ist der ADC bis etwa 100kS/s einigermaßen brauchbar. Danach nehmen die Verzerrungen überproportional stark zu. Du bist bei etwa 300kS/s, und das ist schon Faktor 20 über den Spezifikationen. > Irgendwas muss aber dran sein, denn im am Threadanfang erwähnten Video > kann die ascii-Linie wirklich 40 verschiedene Positionen haben > (Fensterbreite 80 Zeichen), und der Rand der Linie macht tatsächlich > Einer-Sprünge: > http://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=307897#307897 Schau dir das Video noch mal genau an: Es haben immer mehrere Pixel nebeneinander die gleichen Werte. Das sieht man auch deutlich in der von dir geposteten PDF: Es haben meist 3 nebeneinanderliegende Balken die gleiche Höhe...
Hallo Benedikt Vielen Dank für die Mühe, die du dir nun doch noch gamacht hast. Wie du schon zu beginn richtig festgestellt hast, bin ich noch AVR-Newbee und war es damals noch viel mehr. Ich kannte weder die Grundlagen noch konnte ich meine Ergebnisse richtig interpretieren. Offensichtlich habe ich zuerst wirklich den selben Wert mehrfach eingelesen, das zeigt das PDF eindeutig. Das hatte ich im Verlauf meinens Kamera-Threads aber auch bemerkt, weil ich davon abgekommen bin, die Pixel zeilenweise einzulesen. In den letzten Versionen meiner Programme zähle ich die Zeilen ab Seitenstart, dann warte ich nach dem Zeilenstart der Zielzeile über eine Verzögerungeschleife. Am Ende der Verzögerung lese ich ADCH zweimal aus. Den ersten Wert werfe ich weg, weil er das Ergebniss einer alten Wandlung ist das noch ansteht, solange es nicht ausgelesen wird. Den zweiten Wert betrachtete ich bisher als gültig, aber da nach den jetigen Erkenntnissen zuwenig Zyklen vergangen sind um die Wandlung abzuschliesen, war er das vermutlich nicht. Möglicherweise stimmten aber die hochwertigen Bits: h_delay=delay; while (h_delay--); // auf richtiges Pixel warten *pixelzeiger=ADCH; // letzten ADC-Wert auslesen und wegwerfen *pixelzeiger++=ADCH; // aktuellsten ADC-Werte speichern Mit dieser Technik "erkenne" ich z.B. den Smilie. Auch wenn es euch eventuell die Zehennägel aufrollt: So kann ich ca. 120x230 Pixel direkt ansteuern und auslesen, allerdings nur einen Pixel pro Halbbild und eben nur mit eingeschränkter Gültigkeit des Ergebnisses. Passt nun alles, oder habe ich immer noch einen Denkfehler? Denn ich hatte eigentlich vor, diese Lösung in einem meiner geplanten Projekte einzusetzen, aber die Ungereimtheiten im Timeing haben das bisher verhindert. Gruß mic
mic (radbruch) wrote: > Passt nun alles, oder habe ich immer noch einen Denkfehler? Denn ich > hatte eigentlich vor, diese Lösung in einem meiner geplanten Projekte > einzusetzen, aber die Ungereimtheiten im Timeing haben das bisher > verhindert. Ja, sieht schon besser aus, auch wenn es noch Optimierungspotential gibt. Man kann z.B. die Verzögerung den µC selbst erledigen lassen, indem man den ADC vom Timer triggern lässt. Damit kann man den Zeitpunkt auf einen CPU Takt genau einstellen. Das ganze ist allerdings ein wenig kompliziert, bis alles richtig zusammenarbeitet. Das ganze sieht dann folgendermaßen aus: - Der Timer läuft. - Beim HSync Impuls wird der aktuelle Timerwert gespeichert (Input Capture). - Zu diesem Wert wird die Verzögerung addiert und in ein Output Compare Register kopiert - Erreicht der Timer den Wert im Output Compare Register, wird die ADC Messung gestartet. - Ist der ADC fertig, wird das Ergebnis weiterverarbeitet. - Das ganze läuft Zeile für Zeile durch. - Beim VSync Impuls wird die Verzögerung um 1 erhöht. - Das ganze läuft wieder das nächste Bild lang durch. So kann man ein TV Bild mit voller Auflösung (theoretisch bis zu 864x576 bei 16MHz )abtasten. Das ganze dauert aber rund 30s. Wenn man die Verzögerung in jedem Schritt um 2 oder mehr erhöht, verringert sich die Auflösung entsprechend, dafür auch die benötigte Zeit. Die Schwierigkeit dabei ist, alle Funktionen entsprechend zu konfigurieren, damit alles schön zusammenarbeitet. Das ganze funktioniert an sich ziemlich gut, ist leider in der Praxis nur begrenzt einsetzbar, da das Bild eben still stehen muss, während es abgetastet wird. Ich werde daher in Zukunfst warscheinlich die Kamera von Ulrich Radig verwenden: Bei der kann man die Auflösung, Farbtiefe usw. schön konfigurieren und man bekommt alles schon fertig formatiert in digitaler Form.
mic (radbruch) wrote: > Leider weiß ich nicht, wie man hier einen Beitrag editieren kann deshalb > schreibe ich einfach mal weiter. Dafür muss man sich als User anmelden (registrieren)... dann kann man seine Beiträge noch eine gewisse Zeit editieren und auch wieder löschen. Ich glaube, "Antworten mit Zitat" geht auch nur wenn man angemeldet ist.
Hallo Jörg B. wrote: > Dafür muss man sich als User anmelden (registrieren)... Jepp, nun funktioniert's. Danke. Benedikt wrote: > Die Schwierigkeit dabei ist, alle Funktionen entsprechend zu > konfigurieren, damit alles schön zusammenarbeitet. Der Timer-Ansatz klingt vielversprechend, das werde ich versuchen. Danke für den Tipp. Ein komplettes Bild würde meinen Mega32 natürlich sprengen, aber mir reicht es ja vollkommen, wenn ich möglichst viele verschiedene Pixel ansteuern kann. Wenn das dann zufriedenstellend funktioniert, kann den ADC nochmal genauer unter die Lupe nehmen. btw: Die Kamera habe ich mir auch bestellt. Aber auch die wird mich nicht über meine nächste große Hürde heben: Wie interpretiere ich mein Bild mit dem Mega32. Es gibt noch viel zu entdecken ;) Gruß mic
Bei meiner Kameralösung http://www.roboterclub-freiburg.de/AtmelAVR/Hardware/AtmegaKamera/AtmegaKamera.html habe ich den Komperatorinterupt für die Erkennung des Zeilenanfangs verwendet und dann eine Softwareverzögerung eingebaut. Damit läst sich der Abtastzeitpunkt relativ genau steuern. Wie man im Bild mit der Technology-Review erkennt, mindestens 80 Spalten ( Die Kamera steht um 90° verdreht ) Gruß, Christoph SIGNAL(SIG_COMPARATOR) { static uint16_t rowcount=0; uint8_t n; if(CAPFLAG) { _delay_loop_1(Colum); // 3 clock cycles delay / count ADCSRA |= (1 << ADSC); // sample ADC value //TESTPULS; } else { n=0; while (n<4) { if(ACSR&(1 << ACO)) { if(n>2) rowcount=0; } n++; } } rowcount++; if(rowcount==20) CAPFLAG=TRUE; }
>btw: Die Kamera habe ich mir auch bestellt. Aber auch die wird mich >nicht über meine nächste große Hürde heben: Wie interpretiere ich mein >Bild mit dem Mega32. Es gibt noch viel zu entdecken ;) Für einfache Kameras auf Robotern sind in diesem Link Anregungen zu finden: http://www.erkenntnishorizont.de/ki/bildverarb/optreakthv.c.php?screen=800 Ich hatte mal ein Paper von Rodney-Brooks dazu im Internet gefunden, in dem alles recht gut beschrieben war. Leider ist es jetzt nicht mehr aufzutreiben. Ähnliche Algorithmen hatte Tobias ( http://www.tobias-schlegel.de/ ) in seinem Log-Roboter eingesetzt. Christoph
Ich hatte mich auch mal mit dem Thema beschaeftigt. Dieser Link hat mir ganz gut geholfen: http://www.techmind.org/vd/mk1/vdescrpt.html. Bis dann ...
Kann mir bitte jemand sagen welche Zeit zwischen V synch und dem Synch impuls der ersten Zeile vergeht ?
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.