Bei Jufo wäre die CMUCam wohl nicht das richtige.
Für nicht Wettbewerbe o.k.
Castle
Druckbare Version
Bei Jufo wäre die CMUCam wohl nicht das richtige.
Für nicht Wettbewerbe o.k.
Castle
was wäre denn wünschenswert, nur kommunikation mit der cam, oder auch gleich noch beispiele, was man so mit den befehlen machen kann, oder sonst noch?
....kommunikation mit der cam.
Kein Schnickschnack.
Castle
Hi
Ich wollte mcih eigentlich nicht in diese Diskussion einmischen.
Aber ich arbeite gerade ein einem Jufo-Projekt mit der GBC.
Und du wirst es cniht glauben, aber es geht: Bildauswertung mit dem M8.
Ob dus jetzt glaubst oder nicht... ;D
VLG Tobi
Bin noch nicht ganz durch aber schon mal ein paar Vorab Erfahrungen:
Setup:
gamboy-Kamera an ATMega168 mit 18,432MHz Takt, 5V Versorgung.
Die Bilder werden während des Einlesens direkt über UART0 an den Host übertragen und dort mit dem hier schon erwähnten Java Programm angezeigt.
Folgende Dinge sind dabei zu beachten:
Damit der READ Pin auf low geht, dürfen einige Register nicht 0 sein! Ich teste das mal und setze die Werte hier ins Forum. Wichtig ist aber schon mal auf jeden Fall, dass die Belichtungszeit nicht 0 sein sollte. Damit muss entweder im C0 (reg3) oder C1 (reg2) Register ein Wert != 0 stehen.
Damit im Normalmodus (grauwert-positiv-bild) auch etwas erscheint, muss P=1 M=0 und X=1 sein (reg 4, 5, 6). Steht im Datenblatt auf Seite 14.
Jetzt kommt der entscheidende Punkt, damit man bei der direkten Übertragung des Bildes zum Host über die Serielle auch etwas sinnvolles erkennen kann:
Der M64282FP Chip, der in der Gameboy Kamera verbaut ist, hat keinen Shutter (Verschluss). Das heisst, dass während das Bild ausgelesen wird, die CMOS Elemente weiter Licht aufnehmen! Deswegen kommt es auch zu seltsamen Bildern, wenn man die Kamera zu schnell bewegt.
Hier mal eine kurze Berechnung.
XCLK wird optimal, sprich mit 500kHz getaktet. Den ADC squeeze ich ein bisschen, was laut Datenblatt OK ist, da nur 8bit verwendet werden, mit Prescaler 64, auf 288KHz. Eine ADC Wandlung braucht 13 Takte. Macht also als Gesamtzeit für ein Pixel:
13*1/288k+2us = 47.14us/Pixel
Alle Pixel brauchen dann: 128*128*47.14us = 740ms.
Was fehlt? Richtig: Die Übertragung zum Host!
Dadurch wird die Zeit pro Pixel verlängert. Bei 115200bd ist das (8N1+Startbit) = 115200/10 = 11520kB/s =>86.8us/Pixel. Die kommen also zu unserer Kalkulation oben nochmal hinzu.
In Summe landen wir dann bei 2.162 Sekunden/Bild.
Fazit:
Liest man nur das Bild ein, braucht man mit dem ATMega168, bzw. allen Designs, die den internen ADC der AVRs verwenden, 740ms/Bild. Das ist dann auch die Gesamtbelichungszeit für das letzte Pixel (das erste Pixel hat nur die normale Belichungszeit plus irgendwas <47us für's Auslesen). Schreibt man die Daten direkt zum Host wird's nochmal schlimmer. Die Belichtungszeit ist dann so lange, dass die CMOS Elemente ruckzuck in die Sättigung gehen (Weisses bzw. graues Bild).
Deswegen sollte die initiale Belichtungszeit kurz sein, da die Kamera während des auslesens noch genügend Licht aufnimmt.
Hier sind mal meine Parameter: Belichtungszeit ist in us. Offset Voltage in mV (ist aber 0) und Referenzspannung in Volt*2 (damit kein float anfällt). Ist aber auch 0 das Schwarz auf 0V kalibriert werden soll.
Code:void initRetinaParams( void )
{
_retinaParams.mode = grey;
_retinaParams.enhancement = false;
_retinaParams.enhancementRatio = 50;
_retinaParams.invertImage = false;
_retinaParams.exposureTime = 4500;
_retinaParams.offsetVoltage = 0000;
_retinaParams.outputVoltageRef2 = 0;
_retinaParams.outputGain2 = 104;
_retinaParams.boostGainBy6dB = true;
}
Das führt bei mir zu folgenden Registerwerten:
0: 0x80
1: 0x10
2: 0x01
3: 0x19
4: 0x01
5: 0x00
6: 0x01
7: 0x00
Ich baue im Momemt noch eine Routine für's Binning (Reduktion der Bildauflösung). Sobald die fertig ist (hoffentlich morgen) kommt der ganze Code hier ins Forum. Das Bild ist dann zwar nur noch 24x24 Pixel groß, dafür wird es aber mit der vollen ADC Rate eingelesen und es ist noch genügend Platz im SRAM des 168 um Bildverarbeitung und diversen anderen Kram zu berechnen.
Für meine Zielapp werde ich eher auf den 162 wechseln, da der ein externes Speicherinterface hat, so das man ein komplettes Bild in maximaler Auflösung halten kann. Ausserdem sollte ein externer ADC ran, der die 500KHz Samplerate bringt.
Angenehmen Abend.
Ingo
BTW: Besteht Interesse am Code in C++ oder machen hier alle C?
Ein externer ADC braucht nicht ran beim AVR , nur bei der C-Control.
Auch wenn man die Cam ganz langsam bewegen tut, kommen Schlieren weil die Cam nicht anders verarbeiten kann.
Ich nehme die Cmucam2, dort wird das Bild nach dem Schnappschuss sofort gespeichert bis Ultimo.
Castle
wie bereits oben geschrieben:
Ich benutze den internen ADC und habe die Taktrate schon über die mögliche Grenze gesetzt. 288kHz statt 200. Um die Kamera aber schnellstmöglich auszulesen, muss man einen externen ADC verwenden.
Hinzu kommt, dass kein AVR genügend SRAM an Bord hat um ein Bild (16384 Pixel) vollständig zu speichern. Deswegen der 162, der kommt mit einem externen Memory Interface (XMEM).
Naja, das ist aber eine komische Aussage. Das ist wie: "Der wagen braucht keine 200 PS der läuft auch mit 50ps von A nach B"Zitat:
Zitat von super_castle
Das wir wirklich sehr gerne die Gameboycamera verwenden möchten, sollte im laufe dieses sehr umfangreichen Threads ebenfalls deutlich geworden sein... :-k
Es gibt einen scheinbar sehr guten AD-Converter bei Reichelt. Und zwar handelt es sich um den ADS 830 E . Der schafft satte 60 Mhz und ist quasi der einzige, den ich finden konnte, der parallel Daten ausgibt! Er ist spezialisiert auf hochlast Aufgaben wie Video digitalisieren. Zumal er nur 5.25 Euro kostet.
Warum steigst du nicht auf den Mega 128 um? Der hat nicht nur ebenfalls das XRAM Interface, sondern auch die aktuelleren und evtl schnelleren Operationen.
Ich verwende C. C++ will mein Compiler nicht compilieren.
BTW: du hast fasst genau die selben Regsitereinstellungen, wie ich. Da wir praktisch die gleiche Tacktrate haben, ist das ein gutes Zeichen dafür, dass wir auf dem richtigen Weg sind :)
Gruß
Timo
Ich bekomme auch vernünftige Bilder von der Kamera. Aber da die Auslesezeit so hoch ist, muss die Belichtungszeit eben sehr kurz und der Raum einigermassen dunkel sein.
Den 162 verwende ich, weil es den in DIL gibt und ich die Platine erstmal fädeln will.
ADC: Da reich ein Chip der 500kHz schafft. Schneller kann die GameboyKamera die Daten ja nicht liefern. Ich werde einen ADC0804CN verwenden. Der ist schnell genug, liefert die Daten in 8bit und kostet 3.50 bei Reichelt.
Um mit C++ zu arbeiten muss man das Makefile im AVR Studio exportieren, dann im Makefile die Zeile CC=avr-gcc nach CC=avr-g++ ändern und in den Projekteinstellungen das Makefile auswählen. Funktioniert einwandfrei. Einziger - und wie ich finde gravierender - Nachteil: Man kann den Simulator des AVRStudio (noch) nicht mit C++ benutzen. Aber ansonsten schon sehr schick.
BTW, die CMUCam2 ist ja sehr interessant, aber leider 59 mal teurer als die GBKamera. Ich habe für die GBKamera 1 Euro bezahlt (da habe ich dann direkt vier genommen :)). Abgesehen davon: Der Reiz liegt ja auch darin, die Hardware zu meistern, oder? Ansonsten kann man ja direkt einen Aibo kaufen.
HI!
Wenn du mal wieder so ein Schnäppchen siehst, sagsts mir, oder kaufst mir auch gleich 5 GBCs mit... :D
VLG Tobi
PS: Ein Bild der GBC hat 15744 Pixel.
Ich verwende einen ADC0820, allerdings mit dem neuen System, und das muss ich jetzt erst noch zum funzen bringen, bin aber zuversichtlich, dass das bald läuft.
Ich weis nicht, warum ihr so unsagbare Angst vor RAMs habt! Ich steuere ein RAM mit dem Mega8 an! Und mit dem M16, alles über Software. Das XRAM Interface ist ja was nettes, aber man brauchts nicht unbedingt. Wenn man in ASM programmiert ist man fast so schnell...
have fun
Hi Tobi,
die Kameras habe ich bei eBay ersteigert. Da gibt's die massenweise. Kommen halt noch Versandkosten dazu, aber das ist auch nicht die Welt.
Laut Datenblatt liefert die Kamera aber alle 128*128 Pixel (s. S 17 im Datenblatt). Von denen sind, je nach Modus, aber weniger genutzt
Klar kann man SRAM auch per Software ansteuern, aber warum? Der Mega 162 kostet bei Reichelt <6Euro. Einziger Nachteil: Er hat kein TWI, aber das ist im Moment zu verschmerzen und ausserdem in Sotware noch leichter nachzubilden.
HI!
Ja, bei ebay, aber da hat meine 11€ gekostet.
Aber laut Datenblatt des Sensors, M64282FP, Seite 3 Punkt 6, Image Sensing Specifications 1, 1. Zeile, hat der Sensor eine Auflösung von 128*123 Pixel... :D
(Ich weis, auf Seite 1 steht, dass er 128*128 häbe, er hat aber (ich bekomm nie mehr) 123 in y-Richtung.)
Er schickt die letzten 5 zeilen zwar, aber die haben einen Informationsgehalt von 0...
Warum sollte man das XRAM Interface verwenden? In der Software bin ich viel flexibler und kann meine Busse so legen wie es mir vom Layout her passt.
TWI brauch ich bei der Auswertung eh keinen.
Ausserdem ist ein RAM in der Software viel einfacher als ein TWI.
VLG Tobi
Richtig, die effektiven Pixel sind geringer (im Kantenerkennungsmodus sogar nur 121 Zeilen) aber der Sensor liefert immer die gesamte Pixelzahl. Die ungenutzen muss man dann eben ausblenden.
XRAM ist beim 162 halt schon da. Aber das ist sicherlich jedem selbst überlassen.
Hi!
Ja so ist es.
Mein neues System läuft jetzt auch, das schöne ist, dass mit dem schnellen ADC der Balken oben weg ist. Problem bis jetzt: Kontrast hat das ding wohl noch nicht gehört, das schwimmt alles in ner grauen Suppe.
Ich werd noch ein Bisschen mit dem Offset und dem Gain spielen. Schade dass sie keine automatische Belichtungsmessung hat.
@ogni: Welches Tool benutzt du, um die Bilder aufm PC darzustellen?
VLG Tobi
Kontrast hast das warscheinlich schon, allerdings hat die Camera nur 2Vpp. Wenn man das nicht bedenkt, dann denkt man, dass die Camera wenig kontrast hat und wundert sich, warum die Registereinstellungen zwar das Bild heller oder dunkler machen, aber der Kontrast nicht ansteigt :)
Gruß
Timo
Hi!
Naja, das Bild des anderen Systems ist doch noch etwas kontrastreicher...
Was minst du mti Vpp? Kann ja jetzt sein, dass ich da voll ins Näpfchen trete, aber ich weis es ned... ;D
VLG Tobi
Vpp = Voltage peak to peak, quasi der Spannungshub.
Wenn man also Vref = 0V setzt, liefert die Kamera maximal 2Volt als Weisspegel. Guter Hinweis von McNugget, das hatte ich nämlich vergessen. Dementsprechend muss man VRef für den ADC einstellen.
Tobimc: Ich benutze das Java Programm, das hier schon mal erwähnt wurde. Die javax.comm habe ich bei mir installiert. Ich hänge das Ganze mal hier an den Post dran.
Um das Anzeigeprogramm zu bennutzen muss das jar File richtig installiert sein und - wenn man eclipse benutzt - auch als jar ins Projekt importiert werden. (ist alles attached)
(code gelöscht wg. Platzmangel. Bei Bedarf bitte PN an mich, Grüße /Ingo)
Hi!
Ahhh... hm also könnte ich das theoretisch mit der offset ausgleichen? ich habe ne Vref am ADC von 5V.
(am anderen System aber auch...)
Danke, das hätts nicht gebraucht, ich benutze mein eigenes Tool, das ich in C geschrieben habe.
http://www.tobias-schlegel.de/sides/...final/GBCV.zip
(Infos auf meriner HP unter Andere -> Computer -> Software www.tobias-schlegel.de )
Das ist einfacher zu handeln, find ich...
VLG Tobi
Der AD-Wandler, den ich dir genannt hatte, misst sogar genau im Bereich 0-2V oder 0-1V. Daher hatte ich den mitunter für gut befunden.
Damit wären auch Composite-Video Signale möglich!
An sonsten: guter AD-Wandler da! Ich werde mir den auch mal anschauen! Ich hoffe nur, der ist nicht Seriel! :)
Gruß
Timo
Hi!
Der ADC0820 hat ne Wandlungszeit von 1,4us, und gibt parallel aus.
Also könnte ich die Sache tatsächlich durch die Offset-Spannung aufpeppen?
VLG Tobi
Hm, ich kann den AD Wandler bei Reichelt nicht finden. Hast du evtl einen Link?
@tobi: Nein, die offset spannung hilft Dir nicht weiter. Deine Referenzspannung für den ADWandler muss 2V sein, damit der maximale Pegel der Kamera (sofern kein offset drauf liegt) mit 0xff digitalisiert wird (bei 8bit Genauigkeit des Wandlers)
Formel ist etwa: pixel = 0xff*V_kamera/VRefADC
Wenn Du nun einen Offset aufaddierst, gibt das:
pixel = 0xff*(V_kamera+Voffset)/VRefADC
Damit verschiebst Du also nur den Bereich. Wenn V_kamera 0 ist, werden Deine pixel in dem Moment != 0 (Sprich. nicht mehr schwarz) sein.
Gerade ist meine Hardware in die Fritten gegangen, Takt funzt nicht mehr, super :( Vorher hatte ich aber noch VRef extern auf 2.5V gelegt und die Bilder waren super. Auch das Binning klappt, code kommt nachher. Muss noch ein bisschen Schminke drauf tun.
Hi!
Jungs, da ist irgendwie was faul! Bei meinem anderen System bekomm ist super Bilder (auch weiß!!), obwohl auch da die VREF = 5V ist!! Und da nichtmehr. Die Ref ist gelayoutet, die kann ich also nichtmehr ändern.
VLG Tobi
durchkratzen und neu verdrahten
Hi!
Ha ha das ist nicht lustig, das sind gefertigte Platinen für 20€ das Stück...
Ausserdem...
siehe Anhang...
Die AREF des M8s ist mit VCC verbunden. Hab ich extra nachgemessen. der adc wird in bascom so konfiguriert:
Config Adc = Single , Prescaler = Auto
Ich weis nicht, jetzt hängt alles von einem ab: Wen ich das in Bascom so konfiguriere, wo kommt dann die Vref her? Extern oder intern?
Weispegel (=0xff) kann ja 5V sein, dann ist aber der Schwarzpegel eben nicht bei 0V.
Bei mir zumindest lagen die Werte minimal und maximal immer im Bereich von ca. 100 auseinander, was bei 5V ungefähr 2V Hub des Signals entspricht.
Das erste Bild von Dir sieht auch danach aus. Bestimme einfach mal den minimalen und maximalen Helligkeitswert. Falls Du ein Oszi hast, kannst Du Dir das Signal ja anschauen.
Falls Du das bei Dir nicht mehr ändern kannst/willst: Verstärke das Signal der Kamera über einen OpAmp.
HI...
OpAmp geht schonmal garnicht...
Das ist ne JuFo-Platine, da sollte alles stimmen...
Im Übrigen ist die Vref bei Kjions Board auch auf Vcc.........
VLG Tobi
Sind denn dessen Bilder besser (habe die bisher noch nicht gesehen)?
Laut Datenblatt (Abschnitt 7) bringt der Chip nun mal nur 2Vpp, was im übrigen schon mehr als FBAS Pegel ist. Da kannst Du jetzt beliebig mit offset und vref spielen, das wird daran nichts ändern.
Vielleicht hilft ja das Drehen an den Werten für den gain etwas, setzt aber voraus, dass Gain den Analogpegel verstärkt. Das geht aus dem Datenblatt leider nicht hervor, scheint aber genau das zu sein, was Kijon getan hat.
Gain verändert nicht den Hub von 2V! Der verstärkt nur die Pixel so lange, bis alles weiß ist.
Tobi, bei deinem unteren Bild läuft ne Variable über. Deswegen wird das ganze schwarze auch plötzlich wieder weiß. Das liegt daran, wenn du deinen 10bit AD-Wandler im 8-bit Modus betreibst, aber statt der left-adjusteten 8bit des 10 bit wortes die normal right-adjusteten unteren 8bit verwendest. Das kannst du in den Steuerregistern deines AD-Wandlers festlegen. Also ob das Wort left oder right adjusted sein soll. Wenn du nur 8 bit brauchst, dann musst du es left-adjusten, damit du das überhaupt sinnvoll für die Camera verwenden kannst.
Gruß
Timo
EDIT: Das erklärt außerdem, warum sich die beiden Systeme so stark voneinander unterscheiden. Denn bei denem alten hast du scheinbar nur die unteren 8bit ausgelesen, was selbst aus einem sehr schwachen Bild ohne offset und gain noch hohe kontraste holt. Allerdings ist die Gefahr des überlaufs, nämlich wenn der Pixelwert größer als 255 wird, enorm groß!
Hi!
Das wäre eine annehmbare Theorie, allerdings verwende ich den ADC6 des M8, den es nur bei der SMD-Version gibt. Der kann nur 8Bit. Und deshalb kann keine Variable überlaufen.
Ausserdem würde doch da eigentlich totaler Müll rauskommen, oder?
Bild hier
Dieses Bild hat Kjion mit dieser Konfiguration, Vref an VCC gemacht. Also warum sollte es nicht ebi mir auch funzen?
VLG Tobi
Das Bild sieht aus, als wenn es nachgearbeitet wurde.
Es ist nicht Original.
Castle
Nah, wenn es nachbearbeitet wäre - also vernünftig - dann sähe es aber noch deutlich besser aus. Der kontrast ist viel zu gering. Das erste was ich machen würde wäre eine Grauwertspreizung und dann hat man gleich gute kontraste...
EDIT: in meiner modifizierten Version sieht man deutlich, dass er zu kurz belichtet. Die dunkelheit am oberen Rand kommt daher, dass er zeilenweise ausließt und erst wenn die Pixel ausreichend belichtet werden, werden sie heller als schwarz. Dann erreichen sie eine sättigung und werden fortan gleichmäßig heller bis zum weiß.
Nochmal Nachtrag: Hier ein Bild von mir, dass aufgenommen wurde, als ich eben genau die 8 rechten Bits verwendet habe. Für meine Werte gilt dann, dass sie ab einer bestimmten Helligkeit (über 255) überklappen.Zitat:
Zitat von tobimc
0011111111 -- 255
0100000000 -- 256 --> damit 0
Darum bricht das Bild zusammen.
Gruß
Timo
@McNugget:
Du hast recht. Das mit der unterschiedlich langen Belichtungszeit ist ja genau das Problem, wenn man die internen ADCs verwendet, da die recht langsam sind. Überträgt man das Bild gleichzeitig noch zum Host verschärft sich das Problem noch. Eine grobe Überschlagsrechnung habe ich ein paar posts weiter oben mal gemacht.
Wenn der Gain nicht die Ausgangsspannung verstärkt, bleibt nur VRef des ADC auf 2V+x (für ein bisschen Sicherheit) zu setzen, oder siehst Du noch eine andere Möglichkeit (ausser das Signal über OpAmp zu verstärken)?
"Überträgt man das Bild gleichzeitig noch zum Host verschärft sich das Problem noch."
Das sollte man auf keinen Fall machen und sofort verwerfen. Die Auswertung kann nur auf dem AVR geschehen, nirgendwo anders.
Castle
HI!
MIt dem Variablen überlafen... Ok, das erklärt einiges, aber wenn es bei Kjion funzt muss es bei mir auch funzen...
Ich hab mir schon was überlegt, notfalls werde ich eine huckepack-Platine entwickeln, die die Vref auf 2,5V runterteilt.
Das geht schon! Die Übertragung eines Bildes geht bei 19200bps ca. 20 Sekunden.Zitat:
Das sollte man auf keinen Fall machen und sofort verwerfen. Die Auswertung kann nur auf dem AVR geschehen, nirgendwo anders.
VLG Tobi
Die direkte Übertragung zum Host ist aber die einzige Möglichkeit auf AVRs ohne externen Speicher ein komplettes Bild aufzunehmen und sichtbar zu machen. Dass das für Weiterverarbeitung so nicht geeignet ist, steht auf einem anderen Blatt. Dient ja in erster Linie zum Testen.
Weiterverarbeitung auf AVRs ohne externen Speicher ist ohnehin nur mit reduzierter Auflösung möglich.
Hi!
Oder mit nem speziellen Verfahren...Zitat:
Zitat von ogni42
VLG Tobi
@tobi: Natürlich kann man sich Algorithmen vorstellen, die auch mit weniger Speicher auskommen. Generell kann man ein ganzes Bild aber nur dann in den internen SRAM quetschen, wenn man in irgendeiner Weise eine Datenreduktion durchführt.
Teile des Bildes lassen sich natürlich immer verarbeiten.
edit: Mit Datenreduktion meine ich Reduktion des Informationsgehaltes (bspw. jpeg Kompression), nicht zwingend Anzahl der Pixel.