Camera Modul an ATMEGA ?

> 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

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

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.

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.

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

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...

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