Minimal-Videocapture mit ATMega162

[toemchen]

Dieses Thema hat als Suche nach dem richtigen ARM-Prozessor für diese Aufgabe angefangen, mittlerweile will ich es mit einem ATMega162 versuchen und außerdem geht es langsam ziemlich konkret um die schaltungstechnische Umsetzung. Deshalb hier ein Neuanfang unter diesem Thema.

Vielleicht findet es hier mehr Interesse, zuvor haben sich nur ogni42 und ich unterhalten. Nicht, daß ich mit der Hilfe von ogni42 unzufrieden wäre - ganz im Gegenteil! - aber hier werden mehr mitlesen.

Es geht um das Einlesen eines Bildes eines S/W-CMOS-Kameramoduls mit Videoausgang.

Hier zunächst mal, was ich damit vorhabe:
www.robofriend.de/laserscanner.htm
Und meine Vorbilder/Informationsquellen:
http://b-duschinger.homepage.t-online.de/index.html
http://www.users.uswest.net/~kmaxon/...e/art9_137.htm

Nun die genauere Beschreibung:

Die Kamera hat 352x288. Bin aber pro Zeile auch mit der Hälfte der 352 Pixel zufrieden. Dann ergibt sich ein Speicherbedarf von gut 50kByte pro Bild. Bei 50Hz Halbbildwiederholrate, 144 Halbbildzeilen und 176 Samples ergibt sich 1,27MS/s, oder 0,79us pro Sample.

Der 8Bit-Wert wird von einem Flash-Wandler (ADC1173) parallel an einem Port des ARMs zur Verfügung stehen. Der Flash-Wandler braucht sicher ein Triggersignal oder so. Der Beginn eines Bildes und jeder Zeile würde von einem speziellen Chip (LM1881) zu kurzen TTL-Signalen aufbereitet werden, die man auf Interrupt- oder Porteingänge legen kann.

In einem zweiten Durchlauf muß dann bei jedem Pixel sofort der vorherige Wert aus dem Speicher abgezogen werden, und dann die Differenz im Speicher abgelegt werden. Wenn man zuerst zwei Bilder sampelt und danach die Differenzbildung macht, wird der Speicherbedarf größer als 64kB.

Der Prozessor wird wie gesagt der ATMega162 sein, der zusätzlich 64kB externes SRAM adressieren kann. Bei 16MHz bleiben pro Sample 12 Taktzyklen... geht das?

Hier noch, was ich mit den gesampelten Bildern machen will.

Es geht im Prinzip darum, das Differenzbild Spalte (!) für Spalte durchzugehen und den hellsten Punkt zu suchen.

Vielleicht gibt es aber pfiffigere Verfahren als die sture Suche nach dem Maximum - zum Beispiel Mustervergleich mit einem einige Pixel breiten Peak. Das könnte dann fehlertoleranter bei einer Spalte mit verrauschten Daten und einem sehr schwach ausgeprägten hellsten Pixel sein. Oder man macht eine Plausibilitätskontrolle mit den benachbarten Spalten, wo ist dort der hellste Punkt? Diese Ideen vergrößern natürlich den Rechenaufwand.

Danach werden dann den hellsten Punkten anhand eines einmal aufgenommenen Kennfelds Entfernungen zugewiesen. Das erscheint mir einfacher als das herumjonglieren mit trigonometischen Funktionen. Und zuletzt steht ein Entfernungsprofil im Speicher, das über UART übertragen werden kann.

Sodala, viel Text als Einführung. Momentan schau ich nach Schaltplänen für ATMega162 plus SRAM, da gibts schon was bei http://www.kreatives-chaos.com/index.php?seite=gbcam. Dann werde ich mir das Viedosignal mal auf nem guten Oszi anschauen, den LM1881 ausprobieren, langsam einen Schaltplan und eine Platine entwerfen.

[toemchen]

Laut Datenblatt ist der LM1881 zum Decodieren der Sync-Impulse eines FBAS-Signals (gehen ins Negative) geeignet. Hier handelt es sich aber um eine S/W-Kamera mit BAS-Signal (geht bis 0V runter, aber nicht ins Negative).

Das Kamerasignal hab ich mir gerade auf dem Oszi angeschaut: Stimmt. Geht genau bis 0V runter. Mit einem 35MHz Analogoszi hab ichs ja nicht getriggert bekommen, aber unser Super-Duper 5GS/s 350Mhz Tektronix machts natürlich, wenn man sich mal durch die ganzen Menüs geklickt hat.

Komischerweise gibt es trotz Super-Duper keine Funktion zum Darstellen des Videosignals als Bild, oder hab ichs nicht gefunden?

Nun ist die Frage, wird der LM1881 das decodieren? Weiß das jemand? Muß ichs ausprobieren?

Gruß
Tom.

[PicNick]

Nach dem Anschlußschema muß er das locker bringen, würd' ich sagen

[ogni42]

Seh ich genau so. Die Beschreibung im Datenblatt sagt, dass der Chip für NTSC gemacht ist und soweit ich weiss, deckt der NTSC Standard auch SW ab.

[Bernhard667]

Hallo,

klar geht eine SW Kamera mit BAS.
Hab ich auch so gemacht.

Bernhard

[jeffrey]

hi,
müssen wirklich 50 bilder pro sekunde verarbeitet werden? reicht es nicht nur z.b. 2 bilder pro sekund oder so auszuwerten? dann hättest du mehr zeit für die bildauswertung.
mfg jeffrey

[Serious]

Gibts hier schon irgendwelche neuen Ergebnisse? Genau dieses Thema beschäftigt mich nämlich auch schon länger.

Mensch war ich enttäuscht, als ich bemerkt hatte, dass meine tolle Idee mit dem Linienlaser nicht neu ist...