mbot stellt sich vor

[mbot]

.. na, es scheint hier keiner was zu wissen über den Unterschied v4l vs. v4l2

Folgender Code speichert über "programm > picture.txt" /dev/viedo0-Werte in picture.txt.
vergrößern

#include <stdio.h>
#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#define MAX_BYTES (480 * 640 * 3)
unsigned char image[MAX_BYTES];
long length=480*640*3;

main()
{
	int fd, z=0, bildwert=0;
	fd = open("/dev/video0", O_RDONLY);
	read(fd, image, length);
	do
	{
		bildwert=image[z];
		printf("%d ", bildwert);
		z=z+1;
	}
	while(z<length);
	close(fd);
	return(0);
}

Zur Analyse betrachte ich diese Werte meist mit hexedit.

Sie ergaben unter v4l ein erkennbares Muster, welches sich leicht den 640x480 Pixeln zuordnen ließ.

Das geht unter v4l2 nicht mehr, die Werte unter v4l2 sind verschlüsselt, weit weg von räumlicher Zuordnung.

Vielleicht liegt es nicht an v4l2, dann wüßte ich im Moment aber nicht woran sonst.

... ich bleibe dran...

Gruß mbot

[mbot]

...

ich habe im Raspberry-Forum einen Link erhalten:

http://www.thedirks.org/v4l2/v4l2fmt.htm

Habe noch nicht alles übersetzt.

Zumindest standard-mäßig verwendet v4l2 auch ein unkomprimiertes Ausgabeformat, dessen Beschreibung genauso klingt, wie ich es von v4l kenne.

Allerdings wir dort auch von Treiber abhänigen komprimierten Formaten gesprochen.

Driver-specific formats are possible. In that case the application may depend on a codec driver to convert images to one of the standard formats when needed. But the data can still be stored and retreived in the proprietary format. For example, a device may support a proprietary compressed format. Applications can still capture and save the data in the compressed format

Da die Webcam die gleiche ist, bin ich nicht sicher ob ich alles richtig verstehe.

Soll der text bedeuten, dass v4l2 je nach Hardware/ OS auch komprimiert ausgibt,

oder wird in dem Text gesagt, dass man bei entsprechender Hardware/ Treiber das Format für v4l2 ertsmal convertieren muss?

... ich bleibe dran

Gruß mbot

[mbot]

So
,... es geht weiter,


Ich stehe kurz vor der Anschaffung eines Raspberry Typ B (Weihnachstgeldsegen).

Da ich das Vieh autonom rumspazieren lassen will,
plane ich 'ne mobile Stromversorgung, dazu eine Frage:

Wenn ich das Board mit einer ausreichenden USB Stromquelle versorge,
dann müsste der Strom doch für min. eine USB Webcam reichen ?

Ich meine, der Strom wird doch im Board über USB Power-Leitungen weiter geleitet?
(... wird doch nicht noch von einem Zwischencontroller geregelt,
der auf best. Werte festgelegt ist oder?).

Geplannt ist folgender Akku-Pack:
http://www.amazon.de/8400mAh-Erweiterung...s=XCSOURCE

(der selbige wurde hier schonmal empfohlen)

Eine Webcam zieht bis zu 500mA, (ich werde es mit ner alten LG versuchen),
das wären bei 5 V ungefähr 2,5 Watt.

Das Board braucht 3,5 Watt, der Powerpack liefert 8400mAh, das sollte doch reichen!?
(Motoren und Lautsprecher bekommen eine eigene Stromversorgung).


Die Zeit wird zu knapp sein, aber ich freu mich schon aufs Basteln,
... dafür würd' ich am liebsten sofort Jungrentner werden.

Gruß mbot

[mbot]

... Zwischenstandsbericht:


Hardware (endlich alles da, und: et läuft):

- Raspberry B (+ Speicherkarte)
- Sainsmart Relaiskarte mit 8 Relais
(- alte Parallelport Relaiskarte, auch 8 Relais)
- LG Webcam C200
- 2 kleine Elektromotoren mit Getriebe (Conrad damals ca. 15,-€)
- 4 Mikroschalter
- 1 "Drehschalter" (mit zwei Polen "Eingang" kann man 6 * 2 Ausgangspole wählen)
- Mini Aktivlautsprecherbox (2* AA-Batterien)

Software:

- Betriebssystem: Raspbian
- nachinstalliert per apt-get:
-- ffmpeg um per Webcam Bilder der Umgebung als im pgm-Format zu machen
-- espeak für die Sprachausgabe

Mit diesem Equipment und entsprechendem C-Programm soll mein Raspberry
einen Roboter ansteuern der Sehen und entsprechend reagieren also sich bewegen bzw. sprechen kann.

Als ersten Hit möchte ich den Roboter autonom "Skypen" lassen, YEAH und juhu.

Mein Bot hockt dabei vor einem Monitor und reagiert auf das Skype-Bild,
... (ich werde zuerst meinen amerikanischen Schwager (Programmierprofi) schocken),

.. der Bot kann Bewegungen erkennen und mit seinem Kopf verfolgen
(links rechts und rauf runter) und wird dann entsprechend losplaudern.

Es wird nicht in Perfektion gelingen, da er ja den Gesprächspartner nicht wirklich versteht,
er muss also so gut wie möglich verbal bluffen.

C-Programme:


Die Bewegungserkennung ist bereits fertig, dabei machen sich die "nur" 700 MHz am deutlichsten bemerkbar.

Sie muss nun noch mit der Sprachausgabe kombiniert werden,
und auch das Teilprogramm zur Motorenansteuerung fehlt noch.

(die alte Geschichte: Familie und Job lassen zu wenig Zeit. Pro Wochenende gelingt bloß
ein kleiner Entwicklungsschritt, aber immerhin sitzt der 5 Jährige schon interessiert daneben
und hilft beim Löten und Planen.)


Wenn ich wieder zuhause bin werde ich ein paar Bilder zum bisherigen Stand hochladen,
(die C_Programme auch)

in good mood,

Gruß mbot

[mbot]

... ok, hier noch Foto und erster Programmcode;

Bild:

Bild hier  

Wie man sieht, die Bastelei geht jetzt erst los:

- Raspberry und Relay-Karte mit Kabel bestücken (Stecker und Jumper aus alten PCs)
- Elektromotoren (mit Getriebeaufsatz) mit Mikroschalter bestücken (um einen Referenzpunkt zu haben)
- das Ganze sexy zusammenfügen (wg. dreamshader und auch wg. mir)
- usw.

Und hier der Programmcode zur Bewegungswahrnehmung:

#include<stdio.h>

FILE *p_e, *p_n;
int p=0, d=0, s=0;

main()
{
    //Variabeln: c=counter p_e=picture_empty p_n=picture_now p=position d=difference s=switch//
    int    c=0;
    printf("leave the picture-area and then press -Enter-\n");
    getchar();
    system("ffmpeg -f video4linux2 -i /dev/video0 -s 80*60 p1.pgm 2>/dev/null");
    printf("OK, start the Webcam-Watching, press -Enter- again\n");
    getchar();
    p_e=fopen("p1.pgm", "r");
    do
    {
        changing_position();
        if(s==1)
            printf("c: %d Position: %d\n", c, p);
        s=0;
        d=0;
        c++;
    }
    while(c<100);
    fclose(p_e);
    return(0);
}




changing_position()
{
    //Names: bn=bytenumber bv1=bytevalue1 bv2=bytevalue2 d=difference p=position s=switch//
    int bn=80*30+15, bv1=0, bv2=0;
    system("ffmpeg -f video4linux2 -i /dev/video0 -s 80*60 p2.pgm 2>/dev/null");
    p_n=fopen("p2.pgm", "r");
    do
    {
        fseek(p_e, bn, SEEK_SET);
        fread(&bv1, 1, 1, p_e);
        fseek(p_n, bn, SEEK_SET);
        fread(&bv2, 1, 1, p_n);
        d=bv1-bv2;


        if(d>20)
        {
            s=1;
            p=2495-bn;
            return(0);
        }


        bn++;
    }
    while(bn<80*31+15);
    fclose(p_n);
    return(0);
}

Wie Anfangs erwähnt: Ich bin kein C-Könner, mich treibt mehr die Frankenstein'sche Leidenschaft.

Dieses Programm macht ein Anfangsfoto vom möglichst leeren Raum,
und schießt dann so schnell der PC kann regelmäßig weitere Fotos um diese in der mittleren Bildzeile
mit dem Anfangsfoto zu vergleichen. (Auflösung 80*60, wg. bloß 700MHz)

Wenn ein Pixel um den Wert 25 dunkler ist als das Pixel im Anfangsfoto, dann wird dessen horizontale Position
ausgegeben (ca. zw. 0 und 80).

Wie ich anfangs erwähnte ginge diese Form der Personenortung viel schneller, wenn ich die Bilder
ohne Zwischenspeicherung auf d. Festplatte vergleichen könnte.

Das gelang mir früher unter v4l, jetzt unter v4l2 krieg ich's nicht hin.

Noch ein Tipp, dieses "Sehen" gelingt gut bei indirekter Beleuchtung von "hinten",
das heißt hinter der sich bewegenden Person.

sofar4first,

... ich bleibe dran

Gruß mbot