mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Camera Modul an ATMEGA ?


Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Wir wollen einen Roboter das "sehen" beibringen ;) ... das Herz ist ein 
ATMEGA. Wir haben ein ein Kamaramodul gedacht.

Für erste Tests schaue ich mich im Netz um. Was sagt ihr dazu (außer, 
dass es aus china kommt ;)) ...

Wäre es geeignet?

Ebay-Artikel Nr. 160191505681

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wäre es geeignet?

Eher nicht.

Wie willst du ein analoges Videosignal in einen Atmega reinschaffen und 
ggf. dort auch noch auswerten?

Da müssen Kameras her, die bereits digitale Daten ausgeben. Je nach 
beabsichtigter Auswertung auch leistungsfähigere µCs.

http://www.cs.cmu.edu/~cmucam/
http://www.ctbot.de/forum/cmucam-2-t60.html

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: thyristor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wie willst du ein analoges Videosignal in einen Atmega reinschaffen

geht analog:
Youtube-Video "RP6 mit analoger Kamera"

nur primitive Verarbeitung aber es geht.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Respekt. Hätte ich nicht vermutet, dass das geht
http://www.roboternetz.de/phpBB2/viewtopic.php?p=3...

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn man sich den Code anschaut, dann merkt man dass da ziemlich 
gepfuscht wurde (mangels Wissen). Der Programmierer verwechselt 
andauernd horizontal und vertikal und dies hier ist der Code:
do *pixelzeiger=ADCH; while (*pixelzeiger++ > 20);

Ob der ADC fertig ist, interessiert nicht, es wird trotzdem gespeichert. 
Von den 60 Messwerten sind daher nur etwa etwa 20 real (sieht man auch 
deutlich an der dort geposteten PDF). Das macht sagenhafte 16 Pixel pro 
Zeile. Theoretisch sind bei 16MHz bis zu 33 Pixel möglich, allerdings 
läuft der ADC dann mit 8MHz statt maximal 250kHz.

Mit einer anderen Technik geht aber sogar noch mehr mit einem AVR. 
Theoretisch sind 864 x 576 Pixel möglich, die Messung funktioniert nur 
mit einem Standbild bzw, sich sehr langsam ändernden Bild, und dauert 
bei voller Auflösung über 30s. Und das bei einem AVR der lediglich mit 
16kHz Samplerate arbeitet. Dazu startet man den links oben und tastet 
Zeile für Zeile des Bildes ab. Danach fügt man einen kleinen Offset zu 
der Startzeit für den ADC hinzu, und tastet danach die 2. Spalte ab usw. 
Mit HSync an Input Capture Eingang, und einem Timergetriggerten ADC kann 
man den Startzeitpunkt auf 1 Takt genau anpassen.
Wenn ich also nur eine Schatte Zeile erkennen wolle, würde ich die 
Kamera um 90° drehen und die Zeilen verwenden. Wenn man nur die 
Halbbilder auswertet, hat man 288 Pixel Auflösung bei 50 Messungen/s. 
Und der AVR langweilt sich, d.h. das ganze läuft im Hintergrund.

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

die Variante, Spaltenweise einzulesen, hab ich vor Jahren mal am 
C64-Userport gebaut, in s/w narürlich. 2-Bit-Wandler mit 3 Komparatoren.
Umwandlung dann in die beim C64 möglichen 4 Graustufen.

Wäre wirklich mal interessant, was ein AVR da schafft.

Gruß aus Berlin
Michael

Autor: Benedikt K. (benedikt) (Moderator)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Michael U. wrote:
> Wäre wirklich mal interessant, was ein AVR da schafft.

Die Analogbandbreite liegt irgendwo um 1MHz. So sieht ein Bild einer 
NTSC Kamera mit voller Auflösung aus.

Die benötigte Zeit beträgt Spalten / Framerate, das doppelte für 
Vollbilder wenn das ganze Interlaced ist. Daher ist diese Technik leider 
nur für Standbilder geeignet.

Autor: ajax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wenn man sich den Code anschaut, dann merkt man dass da ziemlich
>gepfuscht wurde (mangels Wissen).

Eine ziemlich gewagte Aussage. Das jemand ein wenig Spaghetti-Code 
produziert, hat nichts damit zu tun, das er keine Ahnung hat. Meiner 
Meinung ist es eine reife Leistung, auf die Idee zu kommen, eine Kamera 
an einen AVR ohne Zusatzhardware anzuschließen. Wie sieht Deine Hardware 
aus?

>Mit einer anderen Technik geht aber sogar noch mehr mit einem AVR.
>Theoretisch sind 864 x 576 Pixel möglich, die Messung funktioniert nur
>mit einem Standbild bzw, sich sehr langsam ändernden Bild, und dauert
>bei voller Auflösung über 30s.

Wie kommst Du auf die Daten ?

Autor: Christoph H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ajax wrote:
>>Wenn man sich den Code anschaut, dann merkt man dass da ziemlich
>>gepfuscht wurde (mangels Wissen).
>
> Eine ziemlich gewagte Aussage. Das jemand ein wenig Spaghetti-Code
> produziert, hat nichts damit zu tun, das er keine Ahnung hat.

Was hat das mit Spaghetti Code zu tun ? Es geht darum, dass der ADC nur 
20x pro Zeile misst, aber 60x pro Zeile ausgelesen wird, und dann 
behauptet wird man bekomme 60 Pixel Auflösung.

> Meiner
> Meinung ist es eine reife Leistung, auf die Idee zu kommen, eine Kamera
> an einen AVR ohne Zusatzhardware anzuschließen.

Das sehe ich genauso. Viele hatten die Idee schon, einige Ideen 
funktionieren auch mehr oder wenige, nur sind die meisten in der Praxis 
eher nicht zu gebrauchen (so auch meine, denn wann hat man schon ein 
Standbild und möchte 30s warten ? Wie man sieht bin ich nicht der erste 
der diese Idee hat.)

> Wie sieht Deine Hardware aus?

LM1881 als Syncseparator, HSync am Input Capture Pin, VSync am INT0 Pin, 
Videosignal am ADC Pin.

>>Mit einer anderen Technik geht aber sogar noch mehr mit einem AVR.
>>Theoretisch sind 864 x 576 Pixel möglich, die Messung funktioniert nur
>>mit einem Standbild bzw, sich sehr langsam ändernden Bild, und dauert
>>bei voller Auflösung über 30s.
>
> Wie kommst Du auf die Daten ?

16MHz Zeitauflösung * 54µs für eine Videozeile ergibt 864 Pixel.
Man benötigt 864 Frames um alle Spalten abzutasten. Bei 25Hz ergibt das 
etwa 34,6s.

Autor: mic (radbruch) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Mikrokontroller-Fans

Ich muss schon sagen, ich bin doch etwas enttäuscht. Ich hatte erwartet, 
dass wenigstens einer von euch, speziell Benedikt, sich aufrafft und 
meine Angaben wenigstens im Ansatz durch einen Selbstversuch überprüft. 
Und bei Erfolg einen smarten, gut dokumentierten Code abliefert. Aber da 
ja bekanntlich nicht sein kann, was nicht sein darf, ist der Mega32 auf 
meinem RP6 wohl eine Fehlpressung.

Glückliches und erfolgreiches 2008 euch allen.

Gruß

mic

Autor: Lord Maul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>dass wenigstens einer von euch, speziell Benedikt, sich aufrafft und
>meine Angaben wenigstens im Ansatz durch einen Selbstversuch überprüft.
>Und bei Erfolg einen smarten, gut dokumentierten Code abliefert.

Wie, andere sollen Ihre Freizeit opfern und für Dich was programmieren ?
Da könnte ja jeder kommen ...

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mic (radbruch) wrote:
> Ich muss schon sagen, ich bin doch etwas enttäuscht. Ich hatte erwartet,
> dass wenigstens einer von euch, speziell Benedikt, sich aufrafft und
> meine Angaben wenigstens im Ansatz durch einen Selbstversuch überprüft.

Wiso soll ich etwas in der Praxis überprüfen, wenn sogar die Theorie 
sagt, dass es nicht gehen kann ?
Du lässt den AVR mit 8MHz laufen. Der ADC Prescaler ist minimal auf 2 
einstellbar, macht also 26CPU Takte bzw 3,25µs für eine ADC Abtastung.
Und da eine Bildzeile 64µs lang ist, sind niemals 50 Wert pro Zeile 
möglich.
Das ist nunmal Fakt. Der ADC des AVRs ist für sowas eben nicht 
ausgelegt. Mit ein paar Tricks kann man das ein wenig umgehen, aber 
dafür hat man andere Nachteile (es dauert sehr lange).

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

oder einfach die Philips DC-3840 von meiner Homepage nehmen.
Diese hat eine serielle Schnittstelle und liefert auch Rohdaten.

Gruß
Uli

Autor: Atmega8 Atmega8 (atmega8) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Ulrich Radig
Hab mir deine Kamera gestern zufällig mal angeschaut, die ist also quasi 
für ein Handy gedacht.
Für 5.48 Euro bekommt man so ein Modul inklusive Gehäuse von dir?
Gibt es dafür ein Datenblatt?

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

das Protokoll ist auf meiner HP beschrieben, diese Kamera entspricht in 
etwa der C328 für 48€. Diese Kamera funktioniert ohne Probleme an meinem 
Webserver. Ein Testcode für einen Mega32/644 gibt es auch schon.

Gruß
Uli

Autor: mic (radbruch) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo nochmal

Ich brauche niemanden, der für mich seine Freizeit opfert und für mich 
Programme schreibt, ich möchte das als AVR-Einsteiger selbst lernen. 
Mich hätte einzig interessiert, wie ein "Profi" aus euren Reihen das 
umgesetzt hätte.

Wie hoch die maximale Samplefrequenz des ATMega-ADCs sein kann, dürfte 
euch vielleicht doch verblüffen. Hier beziehe ich mich auf die 
avr-freaks:

http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=33070

Ob das Einlesen eines BAS-Signals nun wirklich so funktioniert wie ich 
das beschreibe, ob es völlig unmöglich ist oder gar nutzlos, weil es 
auch andere günstige Kameras gibt, ist mir recht egal. Ich hatte meinen 
Spaß beim "Entwickeln" und habe dabei auch noch einiges über die AVRs 
und ihre Anwender gelernt.

Gruß

mic

Autor: mic (radbruch) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und nochmal hallo

Nun hat mir der Besuch in eurem Forum doch noch eine Erkenntniss 
gebracht. Das mit den Taktzyklen verstehe ich nämlich auch nicht 
wirklich, aber ich vermute, wenn ADCH ausgelesen wird, bevor der ADC 
fertig ist, bricht er die aktuelle Wandlung ab. Ich habe jetzt meinen 
C-Code untersucht und folgendes zusammengezählt:

  cli();
  do *pixelzeiger++=ADCH; while (count_pixel--);
  sei();

1 003c F894          cli               ; Clocks
2                 /* #NOAPP */
3                 .L4:
4                 .LM15:
5 003e 85B1          in r24,37-0x20    ;1
6 0040 F701          movw r30,r14      ;1
7 0042 8193          st Z+,r24         ;2
8 0044 7F01          movw r14,r30      ;1
9 0046 1150          subi r17,1        ;1
0 0048 D0F7          brcc .L4          ;1/2
1                 .LM16:
2                 /* #APP */           ;__
3 004a 7894          sei               ;8

Also benötige ich 8 Takte oder (mit meinem 8MHz-ATMega32) 1us um einen 
Wert einzulesen. Da das reine Bildsignal knapp 60us dauert, bin ich mit 
fast 60 Werten pro Zeile scheinbar doch im grünen Bereich.

Gruß

mic

Autor: mic (radbruch) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider weiß ich nicht, wie man hier einen Beitrag editieren kann deshalb 
schreibe ich einfach mal weiter.

Wenn der ADC pro Takt ein Bit wandeln kann, würde er mit prescaler /2 
genau 4 Bit wandeln können, bis ich den nächsten Wert auslese. Da ich 
vom linksbündigen Ergebniss aber nur die oberen 4 Bit auswerte, würde 
die Rechnung genau aufgehen. Allerdings müßte man dabei die 2,5us 
"overhead" pro Wandlung unter den Tisch kehren. Eine 10-bit-Wandlung 
dauert laut Datenblatt 13 Zyklen. 2,5us ist wohl die Zeit für das 
Kopieren ins Sample&Hold-Register :(

Irgendwas muss aber dran sein, denn im am Threadanfang erwähnten Video 
kann die ascii-Linie wirklich 40 verschiedene Positionen haben 
(Fensterbreite 80 Zeichen), und der Rand der Linie macht tatsächlich 
Einer-Sprünge:
http://www.roboternetz.de/phpBB2/zeigebeitrag.php?...

Geile Teile diese AVRs

Gruß

mic

Autor: mr.chip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gameboy-Kamera? Liefert zwar bescheidene Bilder, aber bei richtiger 
Einstellung lässt sich einiges herausholen. Jedenfalls liefert die 
GB-Cam schon mehr als genug Daten, um den AVR richtig auszulasten.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mic (radbruch) wrote:
> Nun hat mir der Besuch in eurem Forum doch noch eine Erkenntniss
> gebracht. Das mit den Taktzyklen verstehe ich nämlich auch nicht
> wirklich, aber ich vermute, wenn ADCH ausgelesen wird, bevor der ADC
> fertig ist, bricht er die aktuelle Wandlung ab.

Nicht ganz.
Der ADC wandelt weiter, aber du liest das Ergebnis der letzen Messung 
erneut aus.

> Also benötige ich 8 Takte oder (mit meinem 8MHz-ATMega32) 1us um einen
> Wert einzulesen. Da das reine Bildsignal knapp 60us dauert, bin ich mit
> fast 60 Werten pro Zeile scheinbar doch im grünen Bereich.

Du liest zwar 60 Werte, bekommst aber nur etwa 17 echte Messwerte.

> Wenn der ADC pro Takt ein Bit wandeln kann, würde er mit prescaler /2
> genau 4 Bit wandeln können, bis ich den nächsten Wert auslese. Da ich
> vom linksbündigen Ergebniss aber nur die oberen 4 Bit auswerte, würde
> die Rechnung genau aufgehen. Allerdings müßte man dabei die 2,5us
> "overhead" pro Wandlung unter den Tisch kehren. Eine 10-bit-Wandlung
> dauert laut Datenblatt 13 Zyklen. 2,5us ist wohl die Zeit für das
> Kopieren ins Sample&Hold-Register :(

So ganz stimmt das nicht. Der ADC wandelt immer 10bit, nur eben 
schneller. Und wenn es zu schnell wird, macht er dabei Mist. Ich habe 
dies selbst schonmal ausprobiert und meiner Erfahrung nach, ist der ADC 
bis etwa 100kS/s einigermaßen brauchbar. Danach nehmen die Verzerrungen 
überproportional stark zu. Du bist bei etwa 300kS/s, und das ist schon 
Faktor 20 über den Spezifikationen.

> Irgendwas muss aber dran sein, denn im am Threadanfang erwähnten Video
> kann die ascii-Linie wirklich 40 verschiedene Positionen haben
> (Fensterbreite 80 Zeichen), und der Rand der Linie macht tatsächlich
> Einer-Sprünge:
> http://www.roboternetz.de/phpBB2/zeigebeitrag.php?...

Schau dir das Video noch mal genau an: Es haben immer mehrere Pixel 
nebeneinander die gleichen Werte. Das sieht man auch deutlich in der von 
dir geposteten PDF: Es haben meist 3 nebeneinanderliegende Balken die 
gleiche Höhe...

Autor: mic (radbruch) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Benedikt

Vielen Dank für die Mühe, die du dir nun doch noch gamacht hast. Wie du 
schon zu beginn richtig festgestellt hast, bin ich noch AVR-Newbee und 
war es damals noch viel mehr. Ich kannte weder die Grundlagen noch 
konnte ich meine Ergebnisse richtig interpretieren.

Offensichtlich habe ich zuerst wirklich den selben Wert mehrfach 
eingelesen, das zeigt das PDF eindeutig. Das hatte ich im Verlauf 
meinens Kamera-Threads aber auch bemerkt, weil ich davon abgekommen bin, 
die Pixel zeilenweise einzulesen.

In den letzten Versionen meiner Programme zähle ich die Zeilen ab 
Seitenstart, dann warte ich nach dem Zeilenstart der Zielzeile über eine 
Verzögerungeschleife. Am Ende der Verzögerung lese ich ADCH zweimal aus. 
Den ersten Wert werfe ich weg, weil er das Ergebniss einer alten 
Wandlung ist das noch ansteht, solange es nicht ausgelesen wird. Den 
zweiten Wert betrachtete ich bisher als gültig, aber da nach den jetigen 
Erkenntnissen zuwenig Zyklen vergangen sind um die Wandlung 
abzuschliesen, war er das vermutlich nicht. Möglicherweise stimmten aber 
die hochwertigen Bits:

      h_delay=delay;
      while (h_delay--); // auf richtiges Pixel warten
      *pixelzeiger=ADCH; // letzten ADC-Wert auslesen und wegwerfen
      *pixelzeiger++=ADCH;  // aktuellsten ADC-Werte speichern

Mit dieser Technik "erkenne" ich z.B. den Smilie. Auch wenn es euch 
eventuell die Zehennägel aufrollt: So kann ich ca. 120x230 Pixel direkt 
ansteuern und auslesen, allerdings nur einen Pixel pro Halbbild und eben 
nur mit eingeschränkter Gültigkeit des Ergebnisses.

Passt nun alles, oder habe ich immer noch einen Denkfehler? Denn ich 
hatte eigentlich vor, diese Lösung in einem meiner geplanten Projekte 
einzusetzen, aber die Ungereimtheiten im Timeing haben das bisher 
verhindert.

Gruß

mic

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mic (radbruch) wrote:

> Passt nun alles, oder habe ich immer noch einen Denkfehler? Denn ich
> hatte eigentlich vor, diese Lösung in einem meiner geplanten Projekte
> einzusetzen, aber die Ungereimtheiten im Timeing haben das bisher
> verhindert.

Ja, sieht schon besser aus, auch wenn es noch Optimierungspotential 
gibt. Man kann z.B. die Verzögerung den µC selbst erledigen lassen, 
indem man den ADC vom Timer triggern lässt. Damit kann man den Zeitpunkt 
auf einen CPU Takt genau einstellen. Das ganze ist allerdings ein wenig 
kompliziert, bis alles richtig zusammenarbeitet.
Das ganze sieht dann folgendermaßen aus:
- Der Timer läuft.
- Beim HSync Impuls wird der aktuelle Timerwert gespeichert (Input 
Capture).
- Zu diesem Wert wird die Verzögerung addiert und in ein Output Compare 
Register kopiert
- Erreicht der Timer den Wert im Output Compare Register, wird die ADC 
Messung gestartet.
- Ist der ADC fertig, wird das Ergebnis weiterverarbeitet.
- Das ganze läuft Zeile für Zeile durch.
- Beim VSync Impuls wird die Verzögerung um 1 erhöht.
- Das ganze läuft wieder das nächste Bild lang durch.

So kann man ein TV Bild mit voller Auflösung (theoretisch bis zu 864x576 
bei 16MHz )abtasten. Das ganze dauert aber rund 30s. Wenn man die 
Verzögerung in jedem Schritt um 2 oder mehr erhöht, verringert sich die 
Auflösung entsprechend, dafür auch die benötigte Zeit.

Die Schwierigkeit dabei ist, alle Funktionen entsprechend zu 
konfigurieren, damit alles schön zusammenarbeitet.

Das ganze funktioniert an sich ziemlich gut, ist leider in der Praxis 
nur begrenzt einsetzbar, da das Bild eben still stehen muss, während es 
abgetastet wird.

Ich werde daher in Zukunfst warscheinlich die Kamera von Ulrich Radig 
verwenden: Bei der kann man die Auflösung, Farbtiefe usw. schön 
konfigurieren und man bekommt alles schon fertig formatiert in digitaler 
Form.

Autor: Jörg B. (manos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mic (radbruch) wrote:
> Leider weiß ich nicht, wie man hier einen Beitrag editieren kann deshalb
> schreibe ich einfach mal weiter.
Dafür muss man sich als User anmelden (registrieren)... dann kann man 
seine Beiträge noch eine gewisse Zeit editieren und auch wieder löschen. 
Ich glaube, "Antworten mit Zitat" geht auch nur wenn man angemeldet ist.

Autor: Mic M. (radbruch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Jörg B. wrote:
> Dafür muss man sich als User anmelden (registrieren)...
Jepp, nun funktioniert's. Danke.

Benedikt wrote:
> Die Schwierigkeit dabei ist, alle Funktionen entsprechend zu
> konfigurieren, damit alles schön zusammenarbeitet.

Der Timer-Ansatz klingt vielversprechend, das werde ich versuchen. Danke 
für den Tipp. Ein komplettes Bild würde meinen Mega32 natürlich 
sprengen, aber mir reicht es ja vollkommen, wenn ich möglichst viele 
verschiedene Pixel ansteuern kann. Wenn das dann zufriedenstellend 
funktioniert, kann den ADC nochmal genauer unter die Lupe nehmen.

btw: Die Kamera habe ich mir auch bestellt. Aber auch die wird mich 
nicht über meine nächste große Hürde heben: Wie interpretiere ich mein 
Bild mit dem Mega32. Es gibt noch viel zu entdecken ;)

Gruß

mic

Autor: Christoph H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei meiner Kameralösung

http://www.roboterclub-freiburg.de/AtmelAVR/Hardwa...

habe ich den Komperatorinterupt für die Erkennung des Zeilenanfangs 
verwendet und dann eine Softwareverzögerung eingebaut. Damit läst sich 
der Abtastzeitpunkt relativ genau steuern. Wie man im Bild mit der 
Technology-Review erkennt, mindestens 80 Spalten ( Die Kamera steht um 
90° verdreht )

Gruß,
Christoph

SIGNAL(SIG_COMPARATOR)
{
  static uint16_t rowcount=0;

  uint8_t n;
  if(CAPFLAG)
  {
    _delay_loop_1(Colum);   // 3 clock cycles delay / count
    ADCSRA |= (1 << ADSC);  // sample ADC value
    //TESTPULS;
  }
  else
  {
    n=0;

    while (n<4)
    {
      if(ACSR&(1 << ACO))
      {
        if(n>2) rowcount=0;
      }
      n++;
    }
  }
  rowcount++;
  if(rowcount==20) CAPFLAG=TRUE;
}

Autor: Christoph H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>btw: Die Kamera habe ich mir auch bestellt. Aber auch die wird mich
>nicht über meine nächste große Hürde heben: Wie interpretiere ich mein
>Bild mit dem Mega32. Es gibt noch viel zu entdecken ;)

Für einfache Kameras auf Robotern sind in diesem Link Anregungen zu 
finden:
http://www.erkenntnishorizont.de/ki/bildverarb/opt...
Ich hatte mal ein Paper von Rodney-Brooks dazu im Internet gefunden, in 
dem alles recht gut beschrieben war.  Leider ist es jetzt nicht mehr 
aufzutreiben.
Ähnliche Algorithmen hatte Tobias ( http://www.tobias-schlegel.de/ ) in 
seinem Log-Roboter eingesetzt.

Christoph

Autor: Tupf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte mich auch mal mit dem Thema beschaeftigt. Dieser Link hat mir 
ganz gut geholfen: http://www.techmind.org/vd/mk1/vdescrpt.html.

Bis dann ...

Autor: fred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
33 x 33

Autor: lontano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann mir bitte jemand sagen welche Zeit zwischen V synch und dem Synch 
impuls der ersten Zeile vergeht ?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.