Version vom 2. April 2010, 10:51 Uhr

RP6 Kamera - Mitmach-Projekt: Hardware

Kategorie:Projekte

In diesem "Mitmach-Projekt" soll in den nächsten Monaten eine Experimentierplatine (CONRAD 191537) für den RP6 "gebaut" werden, mit der eine CMOS-Kamera an den RP6 angeschlossen werden kann. Wer mitmachen will, kann zu jeder Zeit selbst entscheiden, wann er aus dem Projekt aussteigen möchte, weil es in 4 Abschnitten ("Phasen") vorgestellt wird. Jede Phase ist ohne die nachfolgenden Abschnitte funktionsfähig.

Im RN-Forum hat radbruch hier: Minimallösung: Kamera für den RP6 ... schon eine einfache und tolle Lösung vorgestellt, mit der der RP6 "sehen" kann. Radbruch hat das eine "Minimallösung" genannt, weil keine weitere Hardware zum Anschluß der Kamera benutzt wurde. Dennoch war das wegen der gut beschriebenen Software-Entwicklung durchaus keine Minimallösung!

In diesem Projekt soll auf der Experimentierplatine (Exp) eine Schaltung "zum Mitmachen" in 4 Schritten aufgebaut werden. Man könnte das dann (wenn es 'mal fertig ist ...) als "Midi-Lösung" für eine Kamera für den RP6 bezeichnen.

So werden die 4 Phasen aussehen:

• Phase 1 -> Anschluß der CMOS-Kamera an den RP6 mit CINCH-Buchse zum Anschluß eines Video-Monitors
• Phase 2 -> Aufbau eines zweifach Video-Verstärkers zur Verbesserung der Qualität
• Phase 3 -> Aufbau eines Sync-Separators zur Abtrennung der Synchronisations-Signale
• Phase 4 -> Anbau von schaltbaren IR-LEDs

Der Aufbau wird so universell wie möglich sein, d.h. eine Auswertung der Kamera kann sowohl mit der Software von radbruch mit dem RP6 erfolgen (schon in Phase 1!), als auch mit der RP6Control M32. Auch an die CCPro M128 wurde hardwaremäßig gedacht,- ob man mit ihr auch eine Video-Auswertung hinbekommt, habe ich nicht probiert.

Was braucht man allgemein für den Aufbau einer Schaltung auf der Exp:

• Seitenschneider, Schere, Zange
• Kleinbohrer 1,5 ... 2,5 mm (zur Platinenbearbeitung)
• Lötkolben 25..30 Watt, Lötzinn
• Plastik 70 Schutzlack
• Isolierter Schaltdraht YV 0,20 mm² (CONRAD 606065)
• Versilberter CU-Draht 0,6 mm (CONRAD 605581)
• Isolierte Kupferlitze in verschiedenen Farben (z.B. CONRAD 605808, rot)

Mit dem versilberten CU-Draht stellt man auf der Unterseite (= Lötseite) der Exp Verbindungen zwischen den Bauteilen her; mit dem isolierten Schaltdraht werden Drahtbrücken auf der Oberseite (= Bestückungsseite) der Exp eingesetzt. Die Lage der Verbindungen zeige ich im Bestückungsplan jeder Phase. Man muss sich nicht an die genaue Lage der Verbindungen halten. Wenn man die Drähte und Bauteile an anderen Positionen einlötet, kann es aber sein, dass man die nächste Phase nicht mehr so aufbauen kann, wie ich das hier zeige!

Phase 1

In der Phase 1 werden Steckkontakte auf die Exp gelötet, an die die Kamera mit einem kurzen Kabel angeschlossen wird. An einer CINCH-Buchse kann das Videosignal abgenommen werden, um zu sehen, was der RP6 sehen sollte. Mit dieser Ausbaustufe kann man eine Auswertung des Bildes genau wie radbruch per Software machen. Für den RP6 existiert dafür die Software im RN-Forum, für die M32 müßte man sie noch etwas anpassen.

Man braucht folgende Bauteile (43,01€ inkl. Versand CONRAD) für die 1. Phase:

Hier erst einmal der Schaltplan:

Und dann der Bestückungsplan:

Die Schaltung wird in der rechten oberen Ecke der Exp aufgebaut (keine Angst: Der übrige Platz wird noch gebraucht!). Für die CINCH-Buchse muss man drei Löcher 1,6 mm für Haltestifte bohren (Kreise auf dem Plan!). Die 2 Kontakte der Buchse haben eine Breite von ebenfalls 1,6 mm,- man sollte aber mit vielleicht 2 mm bohren und die Kontaktzungen auf der Lötseite umbiegen. Es ist gut, die Buchse vor dem Verlöten noch festzukleben.

Wenn man die Platine nicht bearbeiten kann oder will, sollte man anstelle der Einbaubuchse eine gelbe CINCH-Kupplung (731080) bestellen, die mit kurzen Kabeln (am besten einem kurzen abgeschirmten Kabel von einem alten CINCH-Kabel) angeschlossen wird.

Wenn die CINCH-Einbaukupplung fest sitzt, geht es an den weiteren Aufbau:

• Die schwarzen Verbindungen werden auf der Lötseite (unten) mit blankem Draht hergestellt. Man lötet sie an wenigen Punkten an, aber nicht dort, wo noch ein Bauteil oder eine Drahtbrücke von oben durchgesteckt werden soll!
• Die rechteckigen Felder sind die Stiftleisten (1x 5-polig und 5x 2-polig), die man ebenfalls (von oben) auflötet.
• Die zwei rot eingezeichneten Drahtbrücken entstehen aus isoliertem Draht und verlaufen auf der Oberseite der Platine. An dem Loch, wo sie enden, werden sie nach unten auf die Lötseite geführt. Man isoliert sie so weit ab, dass man auf der Unterseite das nächstgelegene Bauteil erreicht.
• Jetzt werden die beiden Kondensatoren eingelötet. Der Elektrolyt Kondensator (Elko) muss richtig herum eingesetzt werden (im Plan ist ein Plus + zu sehen, auf dem Elko ist aber meist der Minuspol markiert).
• Das CMOS-Kameramodul schließt man jetzt an die 5-polige Stiftleiste an. Die Kontakte auf der Exp haben die gleiche Anordnung wie die Stifte an der Kamera. Die Verbindung sollte nicht länger als 10 cm sein. Die Verbindung kann man löten, aber auch mit 5-poligen Stiftbuchsen steckbar machen. Die Kontakte "V out" und "GND" stellt man am besten mit einem abgeschirmten Kabel (von einem alten CINCH-Kabel) her,- die Abschirmung ist dann GND.

So weit dieser erste Abschnitt. Testen, ob alles funktioniert, kann man mit der Software von radbruch (Link siehe oben!)

Viel Erfolg!

Was bleibt noch:

• Es gibt 2 Codierstecker JP1 und JP2. Zunächst braucht man auf die 2-poligen Stiftleisten keine Codierbrücken (= Jumper) zu setzen. Steckt man bei JP1 einen Jumper auf, wird der Pin "Gamma" der Kamera auf GND gelegt. Laut Anleitung der Kamera ist damit Gamma = 1 gesetzt (sonst 0,45). Setzt man auf JP2 einen Jumper, wird die "Gain" (= Verstärkung) reduziert.
• Die Stiftleisten mit dem Namen PGx sind Plugs (= Stecker). Da darf man auf keinen Fall Jumper aufstecken! Hier wird ein Signal ausgegeben oder eingespeist. An PG1 wird die Kamera angeschlossen, PG2 soll einmal in Phase 4 für IR-LEDs dienen. An PG3 kann man das Videosignal abnehmen und an PG4 über eine lose Drahtverbindung (am besten abgeschirmt!) wieder einspeisen. PG4 ist an IT1 des XBUS angeschlossen, das ist der ADC-Eingang 4 (PA4) der RP6 Base (E_INT1). Dieser ADC-Eingang soll die Helligkeit der Bildpunkte auswerten.
• Alternativen zu ADC4 der RP6 Base: Man kann auch ADC0 oder ADC1 nehmen (verfügbar auf dem RP6 Mainboard). Auch die M32 kann schon arbeiten: ADC2..7 sind frei und freuen sich auf diese Aufgabe!

Phase 2

Hier schon einmal die nächste Stückliste! Man braucht folgende Bauteile (3,33€ ohne Versand CONRAD) für die 2. Phase:

- alles Weitere in Vorbereitung ... -

Phase 3

- in Planung ... -

Phase 4

- wird's geben ... -

RP6 Kamera - Mitmach-Projekt: Software

Da dies ein "Mitmach-Projekt" sein soll, hoffe ich für die Programmierung einer Software für die RP6 Kamera, dass sich viele beteiligen und hier fleissig mitschreiben/bearbeiten!

Grundlagen und erste Überlegungen

Auf Wikipedia (siehe Quelle1!) findet man gute Informationen zum Aufbau des BAS Signals, das auch unsere Kamera ausspuckt. Sie ist zwar nicht sehr hochwertig, kann aber laut Datenblatt 352 x 288 Punkte darstellen, was für unsere Zwecke völlig ausreicht. Von den 288 Zeilen, die ausgegeben werden, sind nur ca. 230 Zeilen auf einem Video-Monitor sichtbar.

Jede Zeile wird in 64 µs übertragen, davon sind nur 52 µs für den Bildinhalt vorgesehen. Für einen µC wie den ATMega32 ist das schon eine Herausforderung: Wollte er jeden der 352 Punkte der Zeile lesen, dann hätte er dafür rechnerisch knapp 0,15 µs Zeit. Beim RP6 dauert ein Taktzyklus 0,125 µs (bei 8 MHz Takt), bei der RP6Control M32 0,0625 µs (bei 16 MHz Takt). Mit der M32 hätte man also 2,4 Taktzyklen Zeit für jeden Punkt.

Man sieht schon, dass das nichts werden kann! Es ist unmöglich, jeden Punkt der Zeile "live" einzulesen. Es stellt sich die Frage, wieviele Punkte man denn nun einlesen kann. Ich brauche dazu ja den Analog-Digitalwandler Eingang (ADC) des ATMega32, weil ich die Helligkeit jedes Punktes (also eine Spannung) lesen möchte.

Das Datenblatt zum ATMega32 sagt dazu: Im "free running modus" (auf jede Messung folgt sofort die nächste) braucht jede Analog-Digitalwandlung 13 ADC-Taktzyklen. Das Ergebnis steht dann nach weiteren 0,5 ADC-Taktzyklen zur Verfügung. Was ist eigentlich der "ADC-Takt"? Man muss den Haupttakt des µC für den Analog-Digitalwandler teilen. Das Ergebnis ist dann der ADC-Takt. Der Maximalwert liegt laut Datenblatt bei 1 MHz für den ATMega32. Bei 13 ADC-Taktzyklen pro ADC-Wandlung dauert also jede Wandlung 13 µs.

Das heißt, dass man max. nur 4 Punkte pro Zeile (= 52 / 13) lesen kann. Das ist ja sehr schade! Man hätte dann kaum Auflösung.

Diese Feststellungen sind auch nicht vereinbar mit den Ergebnissen von radbruch (siehe Quelle2!), der viel mehr Punkte pro Zeile einlesen kann. Er verwendet als ADC-Takt 4 MHz, was weit außerhalb der Spezifikationen für den ATMega32 ist. Geht das überhaupt? Kann man mit einer Wandlungszeit von 3,25 µs (= 1 / 4 * 13 µs) realistische 8-Bit-Werte ermitteln? Immerhin würde man so rechnerisch auf eine Auflösung von 16 Punkten pro Zeile (= 52 / 3,25 µs) kommen.

Bevor wir die Fragen beantworten: Überlegen wir erst einmal weiter ...

Mit dem Einlesen der Punkte ist es noch nicht getan. Wir brauchen auch Zeit, um den gewandelten Wert in einer Byte-Variable zu speichern. Dafür stehen die jeweils 13 µs zur Verfügung, während der der ADC-Wandler mit der nächsten Wandlung beschäftigt ist. Bei 8 MHz Takt der RP6 Base sind das 104 Zyklen, in denen man das in GCC gut auch ohne Optimierung durch Assembler-Teile hinkriegt. Wenn eine ADC-Wandlung nur 3,25 µs braucht, hat man bei der RP6 Base noch 26 Taktzyklen zur Verfügung. Auch das reicht noch aus, um in einer Schleife einen Byte-Wert nach jeder Wandlung zu speichern. Wie gross kann denn ein Bild sein, mit dem der ATMega32 nicht überfordert ist? Er hat 2024 Byte SRAM, den Speicherplatz braucht er für Variablen und den Stack (Stapel). Wenn man kein sehr umfangreiches Programm mit vielen Variablen und Unterprogrammen hat, kann man vielleicht die Hälfte (1024 Byte) für ein Bild verwenden. Das wäre eine Auflösung bei 8 Bit Helligkeitswerten von 32 x 32 Punkten. Reduziert man die Helligkeitswerte auf 4 Bit (16 Graustufen), kann man 45 x 45 Bildpunkte darstellen. Auf ein Seitenverhältnis von 4 : 3 des Fernsehbildes bezogen wären in 1024 Byte RAM Bilder von 36 x 28 (8 Bit) oder 52 x 39 (4 Bit) Punkten zu speichern. 16 Graustufen sind für die Aufgabe einer Kamera an einem uC gut ausreichend. Man kann damit Linien folgen und sogar eine einfache Orientierung im Raum erreichen.

Jetzt ist wohl eine Entscheidung fällig:

Ich entscheide mich dafür, eine Bildgröße von 52 x 39 Punkten mit 16 Graustufen zu erreichen.

Kann das klappen? Die 39 Zeilen mache ich dann aus ca. 230 sichtbaren Zeilen der Kamera (Zeilen 30..260). Ich würde also jede 6. Zeile (= 230 / 39) lesen. Jede Zeile dauert 64 µs, also beträgt der Abstand vom Ende der 1. bis zum Anfang der 6. Zeile 256 µs. Das ist genügend Zeit, um die Werte jeder Zeile zu verarbeiten (z.B. in eine Tabelle zu speichern). Kritischer ist die Zeile selbst. Ich will 52 Punkte pro Zeile darstellen. Damit müßte ich jede µs einen Punkt einlesen. Selbst mit der hohen Übertaktung des ADC (4 MHz), die radbruch verwendet hat, komme ich nur auf 16 Punkte pro Zeile. Was tun? Ich könnte das 2. Halbbild benutzen. Bei meiner geringen Auflösung von 52 x 39 Pixeln kann ich ruhig wenige aufeinanderfolgende Zeilen als EINE Zeile betrachten. Wenn ich z.B. Zeilen 5 und 7 eines Halbbildes und Zeile 6 des anderen Halbbildes lesen würde, dann käme ich auf 16 x 3 = 48 Punkte. Natürlich müßte ich nach der Zeile 5 die Zeilen 6 und 7 um je 1,08 µs (= 3,25 / 3) versetzt lesen, damit ich in meiner "dicken Zeile" (besteht aus 3 echten Zeilen!) 48 Punkte (= 16 x 3) lesen kann. Das kommt dem Ziel von 52 Punkten pro Zeile schon nahe.

Bevor ich das als Methode feststampfe, noch eine letzte Überlegung:

Wie wäre es, wenn ich das zeitkritische Lesen einer Zeile vermeide und nur Spalten lese? Das hat radbruch auch in seiner Software gemacht und klingt erfolgversprechend. Ich würde also wie beim 1. Ansatz jede 6. Zeile lesen, um meine vertikale Zeilenauflösung von 39 Zeilen zu erreichen. Das mache ich dann 52 mal, indem ich in jedem Halbbild das Lesen der Zeilenpunkte um 1 µs verzögere. Ich lese also mein Bild spaltenweise ein. Eindeutiger Vorteil: Ich komme nicht in Zeitdruck beim Einlesen, weil ich nur alle 64 µs einen Punkt lesen muss. Nachteil: Ich brauche 52 Halbbilder Zeit, um mein Bild mit allen Zeilenpunkten komplett eingelesen zu haben. Das ist über eine Sekunde.

Schlimm ist das nicht: Ein Bild pro Sekunde ist besser als Nichts. Beim 1. Ansatz wäre das komplette Bild in 60 ms "im Kasten", also 17x schneller.

Hier braucht's wohl wieder eine Entscheidung:

Ich entscheide mich für den 1. Ansatz, der nach 3 Halbbildern fertig ist. Grund: Ich will ja z.B. einer Linie folgen, da kann eine Abtastrate von 1 Sekunde schon zu wenig sein. Sicher könnte man das auch mit der 2. Methode des Spaltenlesens schaffen, wenn man nur wenige Spalten liest und die Kamera um 90° dreht. Ich möchte aber nicht die Kameraposition ändern, sondern immer mein ganzes Bild lesen und verarbeiten. Das ermöglicht mir, im selben Programm einer Linie zu folgen, aber auch einen hellen Gegenstand in der Ferne zu "sehen". Ist sicher Geschmackssache ...

... Baustelle! Hier wird noch weiter gedacht! ..........

Quellen

Quelle1

Wikipedia Fernsehsignal

Quelle2

Minimallösung: Kamera für den RP6

--Dirk 19:19, 27. Mär 2010 (CET)