Minimallösung: Kamera für den RP6

[radbruch]

Hallo,

ich finde es prima, dass meine eigentlich schon recht alte Idee nun doch noch aufgegriffen wird. Ich dachte damals, ich hätte einen genialen Billigsensor "erfunden", aber die schwache Resonanz hat mich dann doch enttäuscht. Bin mal gespannt, was die echten Könner daraus machen. @robo.fr: Danke für den Hinweis und den Link.

Dass ich damals v- und h-syncs verwechselt habe, weiß ich natürlich inzwischen auch. Dass der ADC mehr kann als im Datenblatt steht kann jeder überprüfen, der es selbst mal versucht. Und dass manche Effekte nicht schlüssig zu erklären sind, habe im Verlauf dieses Thread ja auch geschildert. Wenn ich in der Zwischenzeit nicht über viele andere interessante Themen gestolpert wäre, hätte ich aus der Kamera auch noch mehr rausgekitzelt. Aber was nicht ist kann ja noch werden.

Gruß

mic

[roboterheld]

....dann ist die Idee, ein Kameramodul + LED zu verwenden, gar nicht mal so abwegig......

die hohe auslastung des atmegas , nur durch diesen einen sensor macht ihn nicht sehr attraktiv. wenn ich dann den preis für eine zusatz atmegaplatine rechne, weil ja auch noch andere zeitkritische aufgaben bewältigt werden müssen ist er nicht produktiv im gesamteinsatz.

[vklaffehn]

Naja, Ziel meines Senors ist es, über die gesamte Breite meines Robots, ca. 30 cm, Hindernisse zu erkennen, inklusive eines (groben) Abstandswertes und Position (da haben wir sie wieder, die 16 bis 32 Pixel ) Um Mißverständnissen vorzubeugen : Ich verwende einen Mega8 exklusiv für diese Aufgabe, der per I2C später seine Meßwerte ausgibt. Dieses Prinzip verwenden meines Wissens auch die US-Sensoren der SFR-Reihe, da ist ein PIC drauf, glaube ich. Die Kosten für die Hardware liegen ca. bei 13 € + 6-13€ für einen Linienlaser, ein US-Sensor kostet genausoviel/mehr und ist zwar bei der Entfernung genauer, kann mir aber nicht sagen, wo seitlich das Hindernis ist, ein IR-Sensor ist zwar günstiger, aber mit einem kann ich die Strecke nicht bzw. evtl. mit Servo nicht so schnell, abtasten, somit ist diese Lösung für mich (!) durchaus produktiv.

MfG Volker

[purebasic]

hier ist eine basprogramm mit den zeitplan aus diesem forum, dazwischen können die adc-werte evtl rausgezogen werden. man muss die adc-routinen nur geschickt dort einbauen :

$regfile = "m32def.dat"
$framesize = 32
$swstack = 32
$hwstack = 64
$crystal = 8000000
$baud = 19200


Declare Sub Tv_asm()

Config Pinb.7 = Output
Config Pind.7 = Output

Sync Alias Portb                        '-[ 1,2K ]- Sync Ausgang
Video Alias Portd                       '-[ 560  ]- Video Ausgang
Const Syn = 7
Const Vid = 7

Disable Interrupts

Waitms 200

Call Tv_asm()

End

Sub Tv_asm()
$asm

ldi     r16,168                         'bei internem RC Takt, unbedingt
Out Osccal , R16                        'Kallibrieren !!!

'**************** Hauptschleife **************************************
'  bei 8 MHz ( 1 Takt = 0,125µs )
'  die Zeiten im Hauptprogramm zählen immer von "cbi sync,syn" (Sync auf Low)
'  bis "sbi sync,syn" (Sync auf High) oder eben von High nach Low
'*********************************************************************


'            __         ___         ___
'  V-Sync      |_______|   |_______|   |  ---> die ersten 2,5 Zeilen
'                27,5   4,5  27,5   4,5

Main:

   ldi   r16,5
Syn_0:

   cbi   sync,syn
   cbi   video,vid

   ldi   r23,$49                        '27,5 µs
Syn_1:
   dec   r23
   brne   syn_1

   sbi   sync,syn

   ldi   r23,12                         '4,5 µs
Syn_2:
   dec   r23
   brne   syn_2
   nop

   dec   r16
   brne   syn_0                         'Schleife 5 x 32µs = 160µs


'                  __    ________    _________
'  Nachtrabanten     |__|        |__|         |   ---> wieder 2,5 Zeilen
'                    2,25 29,75  2,25  29,75

   ldi   r16,5
Sync2:

   cbi   sync,syn                       'Nachtrabanten
   cbi   video,vid

   ldi   r23,6                          '2,25 µs
Syn_3:
   dec   r23
   brne   syn_3

   sbi   sync,syn

   ldi   r23,$4f                        '29,75 µs
Syn_4:
   dec   r23
   brne   syn_4

   dec   r16
   brne   sync2                         'Schleife 5 x 32µs = 160µs
                                        'zusammen 320µs = 5 Zeilen

'************************ Zeile 6-156 *******************************
'
'                         _______________________
'            __      ____|                       |___   ---> 307 Zeilen mit Bildinhalt
'  H-Sync      |____|
'               4,5    6     52µs Bildinhalt      1,5 µs
'
'********************************************************************

   ldi   r16,151                        'Schleife für 151 Zeilen
Hsyn_0:

   cbi   sync,syn
   cbi   video,vid

   ldi   r23,12                         '4,5 µs
Hsyn_1:
   dec   r23
   brne   hsyn_1

   sbi   sync,syn
   cbi   video,vid

   ldi   r23,$9e                        '59,5 µs ( 6 + 52 + 1,5µs )
Hsyn_2:                                 'da die Pegel für Bildinhalt schwarz sind
   dec   r23                            'wurde es hier zusammnegefasst
   brne   hsyn_2
   nop
   nop

   dec   r16
   brne   hsyn_0

'************************ Zeile 157 *********************************

   nop
Hsyn_3:
   cbi   sync,syn                       '1 Zeile
   cbi   video,vid

   ldi   r23,12                         '4,5 µs
Hsyn_4:
   dec   r23
   brne   hsyn_4

   sbi   sync,syn
   cbi   video,vid

   ldi  R23, 16                         '6,0 µs
Hsyn_44:
   dec  R23
   brne Hsyn_44

   sbi   sync,syn
   sbi   video,vid

   ldi   r23,$8a                        '52,0 µs  Bild
Hsyn_5:
   dec   r23
   brne   hsyn_5
   nop
   nop

   sbi   sync,syn
   cbi   video,vid

   ldi   r23,4                          '1,5 µs Nachsync
Hsyn_6:
   dec   r23
   brne   hsyn_6

'************************Zeile 158-312 *******************************

   ldi   r16,155                        'Schleife für 155 Zeilen
Hsyn_8:

   cbi   sync,syn

   ldi   r23,12                         '4,5 µs
Hsyn_9:
   dec   r23
   brne   hsyn_9

   sbi   sync,syn

   ldi   r23,$9e                        '59,5 µs ( 6 + 52 + 1,5µs )
Hsyn_10:                                'da die Pegel für Bildinhalt schwarz
   dec   r23                            'bleiben wurde es zusammnegefasst
   brne   hsyn_10
   nop
   nop
   dec   r16
   breq   ende                          'der Sprung zu "ende" spart 5 Takte
   nop
   nop
   nop                                  'Ausgleichs nop's, da der
   nop                                  'Sprung zu main mehr Takte benötigt
   nop
   nop
   nop
   nop
   nop
   nop
   brne   hsyn_8
Ende:
   jmp   main
$end Asm
End Sub**

[radbruch]

Hallo

Mein aktuelles Projekt bringt mich wieder zurück zur einfachen Kamera:
Bild hier  
http://www.youtube.com/watch?v=XTYzLqgKMLM

Das sieht zwar schon recht schick aus, aber die Ergebnisse mit den Phototransistoren sind einfach unbefriedigend wenn man die Leistung der Kamera kennt ;)

Im Moment mache ich noch Tests mit dem RP6 (8MHz Mega32) als Steuerung, geplant ist das aber eigentlich für einen tiny13 mit 9,6MHz. Deshalb muss der Code deutlich schlanker werden, was zur Folge hat, dass alles auch etwas übersichtlicher ist. Zur allgemeinen Erheiterung zeige ich euch deshalb mal den aktuellen Stand meiner Vorversuche. Ziel ist dabei u.a. möglichst wenig Ram zu verbraten denn der tiny hat davon nicht wirklich viel:

// cd-racer mit cam (erste Tests mit RP6)                          25.9.2008 mic

#include "RP6RobotBaseLib.h"

uint8_t get_line(void)
{
	uint8_t i;

	cli();
	
	// auf Bildanfang warten
	do
	{
		i=0; while (ADCH > 30); while (ADCH < 50) i++;
	} while (i < 40);

	// die ersten 50 Zeilen überlesen
	i=50;
	while (i--)
	{
		while (ADCH > 30); while (ADCH < 50);
	}

 	// warten auf hell-dunkel-Übergang
	while (ADCH > 110) i++; // Zeile einlesen bis Wert deutlich Richtung dunkel
	sei();
	return(i);
}

int main(void)
{
	uint8_t linie;
	uint16_t i, servo=1550, dummy;

	initRobotBase();
	extIntOFF(); // schaltet den E_INT1-Port auf Eingang für den ADC
	//powerON();

// ADC interne Referenz 2,56V, Ergebniss linksbündig, Kanal ADC4 (E_INT1)
	ADMUX = (1<<REFS1) | (1<<REFS0)  | (1<<ADLAR) | 4;
// setze free running triggern
	SFIOR = (0<<ADTS2) | (0<<ADTS1) | (0<<ADTS0);
// kein Interupt, Wandler einschalten, prescaller /2
	ADCSRA = (0<<ADIE) | (1<<ADEN) | (0<<ADPS2) | (0<<ADPS1)  | (1<<ADPS0);
// Autotriggern bedeutet jetzt free running aktivieren, altes Flag löschen
	ADCSRA |= (1<<ADATE) | (1<<ADIF);
// Initialisierung starten
	ADCSRA |= (1<<ADSC);
// und noch die wohl eher unnötige Initiallesung
	while (!(ADCSRA & (1<<ADIF)));
	ADCSRA |= (1<<ADIF);
	
	// SCL (Pin10) auf Ausgang und Low zur Servoansteuerung
	DDRC |= 1;
	PORTC &= ~1;

	while (1)
	{
		linie=get_line(); // linke Kante der Linie suchen

   	if((linie > 0) && (linie < 70)) // Linie im "Bild"?
   	{
			if(linie > 36 && servo <2000) servo+=(linie-35)*2; // Servoposition
			if(linie < 34 && servo > 675) servo-=(35-linie)*2; // korrigieren

			i=servo; // Servo blockierend auf Position stellen
			cli();
			PORTC |= 1;
			while(i--) dummy ^= i;
			PORTC &= ~1;
			sei();
			i=15000;
			while(i--) dummy ^= i;
		}
	}
	return(0);
}

Wie gehabt hängt die Kamera wieder direkt an einem ADC-Pin. Der ADC rennt wieder im Dauerlauf mit kleinstem Prescaler und die Werte werden auch wieder ohne Rücksicht auf den ADC-Status linksbündig als 8bit-Wert eingelesen. Der Ablauf ist zu Beginn ebenfalls wie gehabt: Warten auf neues Bild und dann Zeilen zählen bis der Start der gewünschten Zeile erreicht ist. Dann kommt eine kleine Änderung: Ich zähle wie oft der eingelesene Wert einen (im Moment noch festen) Wert überschreitet (=heller als Linie) und interpretiere diesen Zählwert dann als linke Kante der Linie. So erhalte ich Werte zwischen 0="Linie links aus dem Bild" bis 69="Linie rechts aus dem Bild".

Mit diesem Wert steuere ich dann ein Servo (ohne großen Schnickschnack über eine Zählschleife mit gesperrten Interrupts) und halte so die Kamera bei einem Wert zwischen 34 und 36:
Bild hier  
http://www.youtube.com/watch?v=46ts6GH04NI

Weil das so wunderbar funktioniert werde ich wohl nochmals einen kleinen Versuch mit einem liniefolgenden RP6 unternehmen ;)

Gruß

mic

[carlitoco]

Ich habe da so eine Idee, aber leider noch nicht soo viel Ahnung vons Janze, wie das halt öfter so ist : ) .

Wäre es möglich mit der erweiterung M32 ein 8-Bit Graustufenblid zu erkennen?

Die Idee dahinter ist folgende.
Ich dachte mir man könnte das Bild als Raster berechnen, um Bewegung/-en in den verschiedenen Sektoren des Rasters zu erkennen.
Anschliesend lässt man den RP6 immmer in die Richtung der Sektoren fahren, welche sich wenig verändern.
Stellt man sich nun einen raum, z.B. sein Zimmer vor, fährt der RP6 immer in die Tiefe des Abblides von dem Raum, bzw. zu den unveränderten Sektoren. Sollte es so sein, das er auf eine weisse Wand zufährt gibt es dafür noch andere Sensoren.

Ich hoffe es ist einigermaßen nachzuvollziehen was ich meine.

Was haltet ihr davon ?

gruss toco

[radbruch]

Wäre es möglich mit der erweiterung M32 ein 8-Bit Graustufenblid zu erkennen?

Ein 32x32Pixel-Bild würde dann 1k Ram belegen. Der Mega32 hat davon aber nur 2k zur Verfügung. Für echte Bildverarbeitung wie man sie vom PC/Mac kennt sind die AVRs wohl nicht geeignet, auch wenn manche Typen noch deutlich mehr Ram anbieten können.

[RP6conrad]

Macht das kein Sinn om einen LM1881 zu nutzen für Erkennung von H-sync und V-sync ? Dan wird die Auslastung von mega32 etwas geringer soll ich denken, und moglich die Erkennung genauer. Den IC selbst soll billig sein und besteht auch in DIP Gehause.

[radbruch]

Macht das kein Sinn om einen LM1881 zu nutzen...

Das würde schon Sinn machen, aber ich finde, der besondere Reiz liegt eben im Verzicht auf weitere Hardware. Nur die Kamera und der AVR und ein paar Codezeilen und die Sache funzt. Deshalb auch der Threadtitel: "Minimallösung" :)

[blenderkid]

hi, da das mit dem Atmega32 nicht so gut geht, wäre das mit dem AT7000 besser zu bewerkstelligen, würde das dann vllt auch mit Farbe funtionieren, es würden auch 32x32 Pixel reichen.

Wäre toll so Farben zu verfolgen.

MfG, blenderkid