Minimallösung: Kamera für den RP6

[radbruch]

Hallo robo,

das ist auch ein hübsches Projekt. Da ich den ADC im Dauerlauf betreibe, kann ich die Syncs auch ohne zusätzlichen Vergleicher erkennen. Mein Kameramodul liefert 1,4V am Multimeter, das messe ich direkt ohne Verstärker. Dadurch erhalte ich bei der internen 2,56V-Referenz zwar nur Werte bis ca. 140 (na sowas), da ich aber sowieso nur mit 4-Bit-Werten weiterrechne, stört das nicht sonderlich.

Der Ablauf ist aber gleich: Warten auf neue Seite, Zeilen zählen bis gewünschte Zeile erreicht ist, kurze Verzögerung um den Pixel in der Zeile anzusteuern, Wert einlesen.

32x32 (=1024Byte) erscheint mir auch als optimale Bildgrösse, allerdings wird's dann beim ATMega8 schon sehr eng. Für ein einfaches Linienverfolgen reicht aber auch ein Bruchteil der Zeilen aus. Auch einfache Mustererkennung sollte möglich sein, einen netten Ansatz dazu habe ich hier gefunden. Minimalste Bildverarbeitung und pfiffige Speichermethoden reduzieren dabei den Platzbedarf für ein Bild auf 64 Bytes. Damit könnte man dann mehrere aufeinanderfolgende Bilder speichern und vergleichen, das ist die Grundlage für Bewegungserkennung und den optischen Fluss. Dafür reichen aber meine Mathekenntnisse noch nicht aus. Auch für neuronale Netze, das eigentliche Thema dieses Threads, bin ich noch nicht reif genug.

Gruß

mic

[roboterheld]

eine tolle leistung mit der camera.

[vklaffehn]

Moin!
Ich wecke den Thread mal wieder, ich bin auch grad dabei, das hier umzusetzen, allerdings bin ich etwas verwirrt. Ich benutze einen Mega8 mit 16MHz, aber Deine ADC-Konfig verstehe ich nicht so ganz, lt. Datenblatt wird beim Mega8 für den ADC nix im SFIOR-Register konfiguriert? Also im Prinzip schaltest Du den Prescaler auf 2, den ADC in den Free Running Mode (das ist bei mir ADFR in ADCSRA?), liest fröhlich ADCH, um die Syncs zu erkennen, wartest ab dem Sync eine fixe Zeit, um einen bestimmten Pixel der Zeile zu erwischen? Soweit richtig? Ich habe bei mir das Problem, daß ich 'Ausreißer' bei den Messungen habe, oder die Syncs nicht erwische, dabei müßte ich doch bei 16MHz eher mehr Werte prü Zeile bekommen? Morgen(naja.... nachher) werd ich hier mal ein paar gesampelte Daten+meinen Code hinpacken, evtl. ist's einfach zu spät dafür...

MfG Volker

[radbruch]

Hallo,

der Ablauf ist genau richtig beschrieben. Mit dem SFIOR-Register wird beim ATMega32 der Free-Runing-Modus als Triggerquelle ausgewählt.

Wichtig ist noch die 2,56V-Referenz für den ADC. Mit den "Schwarzschultern" dauert eine Zeile bis der Wert unter 20 ist. Dann folgt der Zeilensync, dessen Ende ein Wert über 30 (Ende der Schwarzschulter) kennzeichnet. Möglicherweise weichen die Pegel etwas ab. Ein schwarzes Bild (Objektiv geschlossen) sollte Bildpunktwerte von ca. 30 (=schwarz) haben.

Zwischen Zeilensuchen und Einlesen des Wertes sollten die Interrupts gesperrt sein. Ob der Prescaller /2 bei 16 Mhz auch noch funktioniert konnte ich noch nicht testen. Ich nehme zwar an, dass sich die Werte nicht mehr wesentlich verfälschen, aber sicherheitshalber kannst du auch mal mit /4 testen.

Morgen ... werd ich hier mal ein paar gesampelte Daten+meinen Code hinpacken

...und vielleicht noch eine Anschlußsizze.

Gruß

mic

[robo.fr]

Hallo Volker,

wenn Du die Synchronisation mit der Schaltung über den Komperatoreingang machst, wird die Synchronisation noch präzisser.
Bei einigen Programmen zur TV-Ausgabe mit einem Atmega wird als Trick der Prozessor in den Sleep-Modus versetzt, dann wird die Interrupt-Response Time systemtaktgenau ( t=1/16MHz ).

Gruß,
robo

[vklaffehn]

Moin!
Ah, ein Mega32... irgendwie war ich von einem Mega8 ausgegangen und habe mich auch über den 1024 Bytes großen Bildspeicher gewundert....
Ich bin ein wenig schlauer geworden, ich habe einfach mal einen 10K Pulldownwiderstand an mein Videosignal gehängt, nun sieht das irgendwie besser aus. Wie es scheint, kann ich nun den Anfang einer Zeile erkennen und ca. 80 Werte sampeln, allerdings scheint der ADC zu langsam, jeder Wert ist mindestens doppelt, was aber nicht wirklich ein Problem ist. Allerdings habe ich noch nicht durchschaut, wo und wie Du eigentlich den Beginn eines neuen Bildes erkennst.....

Ich habe mir schon einen Wolf gegooglet, ich finde aber irgendwie nur Signalverläufe einer einzelnen Zeile, kann mir jemand einen Tipp gebenm wo ich mal einen Verlauf eines BAS-Bildanfanges oder eines ganzen Bildes inkl. Synchronisationssygnales finde???

MfG Volker

[radbruch]

Hallo,

mein RP6 hat eben einen ATMega32 und der von mir verwendete Eingang ist mit einem 10K-PullDown beschaltet.

Meine Infos zum BAS-Signal habe ich von hier. Der Start einer neuen Zeile ist der Sync-Impuls. Ein neues (Halb-) Bild beginnt mit einem extrem langen Sync.-Impuls:

Um eine Unterscheidung zwischen Zeilen- und Vertikalimpuls zu erreichen, ist letzterer 2,5 Zeilen (2,5 × 64 Mikrosekunden) lang.

Das ist im Programm folgender Abschnitt:

do { h_sync=0; while (ADCH > 20); while (ADCH < 30) h_sync++; } while (h_sync < 40);

Aufgedröselt sieht das so aus:

do
{
	h_sync=0;               // Synclängenzähler rücksetzen
	while (ADCH > 20);      // Ende aktueller Zeile abwarten
	while (ADCH < 30)       // Solange ein Sync-Pegel erkannt wird
	{
		h_sync++;            // wird der Zähler erhöht
	}
} while (h_sync < 40);     // Zähler größer 40 bedeutet: Start neues Halbbild

wird solange ausgeführt, bis 40 mal Sync.-Pegel erkannt wurde. Bei 16Mhz müßte dieser Wert allerdings deutlich größer als 40 sein. Das ist aber egal solange ein Zeilensync nicht länger als 40 ist.

Mit dem kleineren Speicher des ATMega8 must du Abstriche bei der Auflösung des Bildes machen, das ist aber nicht dramatisch. Mein aktueller Linienfolger liest z.B. auch nur eine Zeile mit 32 Werte ein. Das genügt völlig um eine Linie zu erkennen und ist deutlich mehr als eine LED/Fototransistor-Sensorik liefert.

Wenn du deinen Code und deine Messwerte postest, kann man dir etwas helfen ohne raten zu müssen.

Gruß

mic

[vklaffehn]

So, ich bin, galube ich, ein Stück weiter. Wie es scheint, liefern die Zeilensyncs bei mir so ungefähr 31 zurück, und eben scheine ich einen Bildanfang erwischt zu haben, einen haufen '31' und dazwischen ziemlich konstant '60', danach schienen nach den '31' spikes Zeilendaten zu kommen, ich werde das jetzt mal genauer untersuchen.

Übrigens mal am Rande, die Beschaltung ist im Prinzip folgende:

Atmega8 mit 16MHz, Conrad S/W Kameramodul an ADC3, Pulldown von 10KOhm am Videosignal
Den ADC initialisiere ich so

void adc_init()
{
// ADC interne Referenz 2,56V, Ergebniss linksbündig, Kanal ADC3  
   ADMUX = (1<<REFS1) | (1<<REFS0)  | (1<<ADLAR) | 3; 

// Wandler einschalten, prescaler /2 
   ADCSRA = (1<<ADEN) | (0<<ADPS2) | (0<<ADPS1)  | (1<<ADPS0); 

// free running 
   ADCSRA |= (1<<ADFR); 

// Initialisierung starten 
   ADCSRA |= (1<<ADSC); 

// und noch die wohl eher unnötige Initiallesung 
   while (!(ADCSRA & (1<<ADIF))); 
   ADCSRA |= (1<<ADIF); 
}

Die Daten lese ich so

for (cnt=0;cnt<512;cnt++)
{
	*zeiger=ADCH;
	*zeiger++=ADCH;
}

Danach schubse ich die Daten per RS232 in eine Excel Tabelle

[radbruch]

Hallo

for (cnt=0;cnt<512;cnt++) 
{ 
   *zeiger=ADCH; 
   *zeiger++=ADCH; 
}

Warum liest du den Wert zweimal ein? Wir verwenden nur das High-Byte des Ergebnisses der A/D-Wandlung. Deshalb reicht ein *zeiger++=ADCH; pro Wert. Der Zeiger sollte auf ein Byte-Feld zeigen, dieses solltest du sicherheitshalber zuvor löschen (mit 0 füllen).

Deine Daten zeigen selten Werte unter 30, hier scheinen die Pegel der Kameras zu streuen. Da wir auf Werte größer 20 prüfen um das Zeilenende zu erkennen, ist das kritisch. Günstiger wäre hier auf 30 zu prüfen. Versuch doch mal folgende Kombination:

while (ADCH > 30); while (ADCH < 40)

Solange der Wert größer 30 ist, befinden wir uns in einer Zeile, Start der nächsten Zeile ist am Ende des syncs wenn der Pegel wieder über 40 ist.

Deine Daten scheinen auch noch einen anderen Fehler zu haben, ich weiß aber noch nicht, was da nicht stimmt. Versuche doch mal mit einem weisen Blatt vor der Kameralinse eine Datenreihe zu erzeugen (200 Werte reichen vorerst), dann sollte man den Bereich "Sync" vom Bereich "Daten" besser unterscheiden können. Das selbe mit verdeckter Linse zeigt den Unterschied zwischen Sync-Pegel und Schwarz (~30). Meine Kamera passt automatisch ihren Weisabgleich an, möglichst parallel auf einem TV-Bildschirm das Kamerabild kontrollieren.

Deine Codestückchen sind zu kurz! Ich kann weder erkennen, wie du zum Seiten-/Zeilenanfang findest, ob die Interrupts gesperrt sind oder ob sonst noch Fehler erkennbar sind. Noch ganz wichtig ist folgendes: Nach dem Seitenanfang folgen erst einige Zeilen "Schrottpixel" (bei meiner Kamera bis ca. 35ste Zeile). Diese Zeilen muss man überlesen, das eigentliche Bild beginnt erst hier. Ebenso endet das Bild auch schon vor der letzten Zeile.

Gruß

mic

[vklaffehn]

Moin!
Bin wohl noch nicht ganz wach
Vielen Dank für's schauen, ich fasse nochmal zusammen :
Das doppelte Einlesen war nur ein Unfall, eigentlich soll das so aussehen:

void grab()
{
	unsigned int cnt;
	unsigned char pixel;
	uint8_t daten[512],*zeiger;
	zeiger=&daten[0];

	cli();

	while (ADCH > 30); while (ADCH < 40); //Zeile abwarten 

	
	for (cnt=0;cnt<512;cnt++)
	{
		*zeiger++=ADCH;
	}
	
	for (cnt=0;cnt<512;cnt++)
	{
		pixel=daten[cnt];
		txd(pixel);
	}
}

Also ich warte im Moment eigentlich den Anfang einer (beliebigen) Zeile ab und erfasse danach einfach 512 bytes, das müßten ja ein paar Zeilen sein. Diese will ich mir erst einmal am PC (also in Rohform) anschauen.
Interrupts brauche ich im Moment nicht, die Funktion 'txd()' ist ein Mini Software UART, der einfach das übergebene Byte an 'nem Pin rausschreibt und irgendwas anderes macht der µC im Moment auch erstmal nicht.

Automatic Gain Control kann man bei dem Modul mit einem Pin an und abschalten, zur Zeit ist das deaktiviert, als Kontrolle lasse ich mir das Bild über den Video-In von meinem Compi hier anzeigen, das sieht auch richtig aus. Den Beginn einer Zeile kann ich auch erkennen, aber den Anfang des Bildes krieg ich nicht raus.
Folgendermaßen habe ich mal versucht, dahinterzusteigen :

void synctest()
{
	uint8_t h_sync;
	uint8_t daten[512];
                unsigned int cnt;
	cli();

	//auf bildanfang warten
	for (cnt=0;cnt<512;cnt++)
	{
		h_sync=0;
		while (ADCH > 50); // Zeile abwarten	
		{
			while (ADCH < 50) h_sync++;	//Syncs zählen
		}
		daten[cnt]=h_sync;
	}

	//debugging...
	for (cnt=0;cnt<512;cnt++)
	{
		txd(daten[cnt]);
	}
}

Damit zähle ich ja quasi die Dauer der Sync-signale, und bei 512 Messungen sollte doch eigentlich immer mindestens ein Bildrücklauf vorhanden sein, richtig? Naja, da ich morgen arbeiten muß, werde ich mich den Daten wohl morgen Abend wieder widmen.

Vielen Dank für die Ausführungen!!

MfG Volker