mbot stellt sich vor

Moin alle,

mbot:

bisher:

Ansatz: autonome Bots die sehen und sprechen können und mobil sind (klar hier fehlt noch "verstehen können"),
nach dem LOW-BUDGET Prinzip


Board: .............................. mini-ITX, ca. 20 Watt, 70 €
Betriebssystem:...................Linux (Debian) x-ubuntu_alternate
Programmiersprache:........... C
Sehen:..................... über WebCam, unter C über read()-> /dev/video0 (v4l)
Sprechen:................. unter C mit espaek (oder mbrola)
Bewegen/ Action:....... 2 Relaisplatinen über Parallelport und über seriellen Port
I/O-Nutzung:....................... 2 Eingänge am ParPort, 16 Ausgänge über ParPort und seriellen Port
Mechanik:........................... nach langem Rumprobieren; Spindelsteuerung mit Minischalter für min- und max-Position


Möglichkeiten:

... der Bot sieht dich egal wo du stehst im Zimmer, er spricht dich an, er wendet seinen Kopf nach dir,
er warnt dich vielleicht ein zwei mal, bevor er seine elektrische Wasserspritzpistole einsetzt.

Nebeneffekt: bei 16tel-Sekunden Bild-Aktualisierung bzw. Bewegungskorrektur rattern min. 8 Schaltrelais wie ein Maschinengewehr ... => schon wieder sparen für Optokoppler

... der Bot steht an der Theke und wartet darauf dass er Gästen einen Drink einschenken
und mit ihnen Plaudern kann (leider nicht vollendet)

... der Bot Sitzt am Schachbrett und wartet auf einen würdigen Gegner, er plaudern während des Spieles, ist ein schlechter Verlierer, muss frech kommentieren, er erkennt den Spielstand und setzt seine Figuren selber. (leider nicht vollendet)


Mit dem oben genannten Material, gibt es noch viele Möglichkeiten ein wenig Science-Fiction in der Gegenwart zum Leben zu erwecken, fast immer fehlt die Zeit da man ja erstmal das nötige Geld verdienen muss.
In meinem Fall geht das Geld aber meist für die Familie drauf, ... für Robot-Umsetzungen schlechte Karten im Moment.

Das KnowHow ist da und weitgehend getestet, bin noch am Arbeitsplatz, ... werde von zu Hause aus noch Bilder nachliefern.

Meist muss ich einen Bot wieder zerlegen, wenn ich einen neuen bauen will....

Wenn jemand Interesse hat, stelle ich alles Wissen zur Verfügung, ich selber hab auch noch ein paar ungelöste Probleme,
würde mich trotz einiger Ergebnisse, dennoch als Anfänger in Sachen "Robotik unter C" bezeichnen.

Für den oben genannten Ansatz ist ein komplett verbauter PC sinnvoll, ich nehme bisher mini-ITX Boards,
eventuell versuch ich es mal mit nem Raspberry-Pi, ... hatte noch keins in der Hand, aber das Ding ist'n voller Computer (ARM-Mainboard), ca. so groß wie ne Zigarettenschachtel, kostet ca. 30,-€ und es gibt eine Debianversion dafür (Raspbian).

espeak -vde "Ai froi mi tubi hia, werri matsch, jea"

Gruß mbot

... hier noch ein paar Fotos:

Das erste ist etwas groß, es zeigt das was ein Barkeeper werden sollte:

Man sieht die Arm-Ansteuerung über Gewindestangen (Spindel), es ist das mini-ITX Board da, 2 Netzteile, die Relaisplatinen ..

Bild hier  


hier von vorne, mit Kopf, das Vieh konnte natürlich wie alle andern auch Sprechen

Bild hier  


hier ein Bild, wie ich für kleines Geld relativ genau einen Hebel positionieren kann:
Diese Mechanik in Verbindung mit einem Zähler unter C, der durch Minitaster auf 0 oder max gesetzt wird.

Bild hier  

... und hier der Koffer, mit dem ich an Bahnhöfen u.ä. immer sehr unhöflich von Ordnungshütern aufgehalten werde ;- )
... er enthält das Board, 2 Relaisplatinen, eine Memorycard fürs OS und 2 Netzteile und jede Menge Ka,
das Scheißding wiegt an die 8 Pfund, deswegen demnächst ---> Raspberry-Pi (mit Optokopplern)


Bild hier  


wr_u, Gruß mbot

..., nach weiteren Tests zeigt sich:... Mist:

Bisher gelang Umgebungserkennung dmit einem C_Programnm immer problemlos über /dev/video0,
da v4l was ausgespuckt hat, was man Byteweise auswerten konnte, ... also mühelos in Raumkoordinaten umwandeln konnte.

Der seit geraumer Zeit gängige Nachfolger v4l2 liefert unverständliche Daten, ich vermute ist ein komprimiertes Format (evtl. jpg).
solche Daten sind i.d. Regel mit (komplexen) Algorithmen verschlüsselt.

Das Raspbian verwendet sehr wahrscheinlich auch 4vl2, ... so komm ich erstmal nicht weiter, ich muss mich nach einer Lösung umsehen,
wie ich jpg-Daten "räumlich" mache (ohne Zwischenspeicherung auf d. Festplatte versteht sich).

Ich bin nicht sicher ob ich unter Raspbian (für ARM-Prozessoren) den v4l2 gegen v4l austasuchen könnte.
(Ich wüßte sowieso nicht wie man das macht...)

Bis zum Kauf eines Raspberry-Pi dauerts also noch ne Weile...

Gruß 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

Code:

---

#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

...

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.

Zitat:

---

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

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

... 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

... 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:

Code:

---

#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