Minimallösung: Kamera für den RP6

[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

[radbruch]

Hallo

Versuche es mal so:

/*
	Solange Zeilen abwarten bis das Sync-Signal länger als 40 Lesezyklen ist
	(CPU-Takt abhängig!) An dieser Stelle beginnt ein neues Halbbild.
*/
do { h_sync=0; while (ADCH > 20); while (ADCH < 30) h_sync++; } while (h_sync < 40);

/*
	Ab jetzt zählen wir die Zeilensyncs um die gewünschte Zeile anzusteuern
	(mindestens 35 um die ersten Schrottzeilen zu überspringen, 100-200 wäre
	im Teststadium sinnvoll)
*/
zeile=35; while (zeile) { while (ADCH > 20); while (ADCH < 30); zeile--; }

Schwellwerte für Bild/Sync (der Strahlrücklauf IST das Syncsignal!) must du anpassen. while (h_sync < 40); macht das selbe wie bei dir, es zählt die Lesezyklen und misst damit die Zeit des Syncs. Bei meinem CPU-Takt bedeutet mehr als 40 den vertikalen Strahlrücklauf(=Bildanfang). Was bei dir jetzt noch fehlt ist das Ansteuern einer Zeile mit Bildinformationen. Ansonsten guter Testcode, das muss man auch mal loben.

Gruß

mic

[Edit]
Ursache für die verschiedenen BAS-Pegel könnte auch die interne Spannungsreferenz des ADC sein. Irgendwo habe ich mal was von "ein paar 0,1V" Ungenauigkeit gelesen. Mein Kalibrierungstest mit einer 1,5V-Batterie ergab allerdings den selben Wert wie die Messung mit einem Multimeter. Mit dieser "Festspannungsquelle" habe ich übrigends auch im Vorfeld die Messfehler bei unterschiedlichen Prescallerwerten getestet. Hierbei gab es auch beim Faktor /2 im HighByte keinen Messfehler, im LowByte waren die Bits 0-3 verfälscht. Möglicherweise steigt der Fehler bei höherem CPU-Takt. Wenn ich das M32-Board habe, werde ich das mal testen...

[vklaffehn]

Moin!
Hmmm, bin doch noch hier
Das obere habe ich schon versucht, auch an den Schwellwerten ein wenig rumgedreht, leider scheint mein Programm dann immer stehenzubleiben, daher mein Versuch, die Längen der Syncpulse zu debuggen, da sollten ja kurze Impulse der Zeilensynchronisation auftauchen und jedes Halbbild ein langer Strahlenrücklauf. Morgen werde ich auch mal nach der Genauigkeit meines ADC schauen und evtl. mal eine andere Camera nehmen. Sobald das dann hinhaut, brauche ich auch nicht komplette Bilder speichern, sondern nur pro Spalte den jeweils hellsten Wert je zweimal, einmal ohne, einmal mit Laserlinie aufgenommen. Naja, wie gesagt, morgen geht's weiter.....
Brauch doch was für den Robotik Treff Niedersachsen am Samstag

P.S.anke für das Lob, ist, ehrlich gesagt, nicht das erste Programm, was ich schreibe ... Hab schon Assembler auf dem C64, Turbo Pascal, C++ mit MFC unter Windows, ein wenig C# sowie PHP/MySQL hinter mir, aber alles eher als fortgeschrittener Amateur.... Außerdem räum ich den Code immer vorher auf, bevor ich ihn poste, normalerweise sind da Millionen auskommentierte Zeilen von irgendwelchen Versuchen drin.

[radbruch]

Was is nun mit der Kamera? *ungeduldigmitdenfingerntippelt*

Zu deinem P.S.:
C64 war doch Mist, Z80 war Top!

mic

[vklaffehn]

Moin!
Hab zu viel versprochen, heut keine Zeit gehabt. Was den C64 angeht, der gehörte meinem Papa, was anderes hatten wir halt nicht, mit dem Z80 hat mein großer Bruder später rumgebastelt, 4MHz mit Klingeldraht!!!
Back to Topic: Ich denke mal, morgen Abend klappt vielleicht noch was, ansonsten am Samstag, wenn die anderen durch die Robotik-Abteilung der TU Braunschweig wandern...

MfG Volker