ASURO mit Kamera ferngesteuert

Hallo Zusammen,
so, jetzt habe ich es geschaft, den ASURO mit einer Kamera fernzusteuern. Es funktiniert zwar noch nicht ganz so schnell, wie bei den Fussbalrobotern der Midsize-Leage, aber immerhin.

Das Setup:
- Logitech Quickcam Pro4000, 1m über Boden
- USB-Infrarot Transceiver daneben
- SCILAB mit SIP zur Steuerung und Bildverarbeitung

Zum Test habe ich dem Roboter mal die Wegpunkte des NIkolaushauses vorgegeben und die Bahn aufgezeichnet. Das ganze siehe ein wenig wackelig aus, besonders an der oberen Kante. Bei der oberen Kante bestand das Problem, dass der ASURO am Rand des Erfassungsbereiches der IR-Sendediode gefahren ist und teilweise Kommandos verloren hat. Die IR-Sendediode des USB-Transceivers hat leider nur einen Öffnungswinkel von 17°, sodass der Lichkegel relativ schmal ist. Ich möchte die Kamera und den Sender aber höher hängen, damit der Aktionsradius des ASURO größer gemacht werden kann.

Die ersten Bilder der Bildverarbeitung habe ich hier gepostet:
https://www.roboternetz.de/phpBB2/viewtopic.php?t=15731

Gruss,
stochri

Hallo stochri,

Gratulation, sieht super aus =D>

Nur so als Idee: Du könntets noch eine (andersfarbige?) Markierung anbringen oder die LESDs anschalten und detektieren. Dann hast du auch die Orientierung.

Wieviele Bilder pro Sekunde analysierst du? Magst du ein wenig mehr über die Bilderkennung berichten (fertige Software oder selbst geschrieben)? Im anderen Beitrag erwähnst du SCILAB (habe ich googeln können), aber was ist SIP (23.000.000 Hits, z.T. recht lustig)?

Gruß Red Baron

Hallo Red Baron,

Zitat:

---

Nur so als Idee: Du könntets noch eine (andersfarbige?) Markierung anbringen oder die LESDs anschalten und detektieren

---

Da habe ich zuerst auch dran gedacht. Ich wollte aber schnell zu einem Ergebnis kommen und die Erkennung mehrer Punkte hätte meine Algorithmus gleich etwas komplizierter und störanfälliger gemacht.
Aber man könnte das Nikolaushaus sowieso nicht zeichnen, wenn man den Winkel des Roboters nicht kennen würde.
Deshalb bin ich folgendermaßen vorgegangen:

0. Bestimme den Standort
1. Fahre einen kleinen Schritt
2. Lege eine Gerade durch die beiden Punkte
3. Ermittle den Winkel
4. Ermittle den Winkel zur Zielposition
5. Drehe um den Differenzwinkel

Mit dem Programm https://www.roboternetz.de/phpBB2/vi...=145769#145769 im ASURO kann kann ich nur in ca10° Schritten drehen. Deshalb fährt der ASURO immer einen kleinen Schritt, die Kamera bestimmt dann die Position und korrigiert nötigenfalls die Richtung.
Dass das Bild wie eine Handzeichnung aussieht, könnte mit der geringen Winkelauflösung beim Drehen zusammenhängen.

Fahren und Drehen kann der ASURO mit dem Programm immer nur in kleinen Schritten. Gegenüber der Methoden dem ASURO per Infrarot einen Drehwinkel und ein Kommando zu übermitteln stört es in diesem Fall nicht, wenn einmal ein Befehl bei der Übertragung verloren geht. Im schlimmsten Fall bewegt sich der ASURO dann minimal in eine falsch Richtung. Er wird aber dann im nächsten Schritt durch die Bildverarbeitung wieder korrigiert.

Hier noch die Links:
SCILAB: http://www.scilab.org/
SIP: http://siptoolbox.sourceforge.net/

Gruss,
stochri

Hier das Scriptfile für die Bildaufnahme und die Bestimmung der Position des ASURO über die Farbe. Zur Bildaufnahme verwende ich das Programm "webcam" ( linux). Leider bremmst dieses Verfahren die ganze Bildauswertung ziemlich stark ab, weil der Aufruf von webcam ca.2 Sekunden dauert.
Es würde mich sehr freuen, wenn jemand eine Lösung wüßte, das ganze zu beschleunigen. Mit kdetv können die Bilder der Kamera immerhin in Echtzeit dargestellt werden, also müßte es auch ein Möglichkeit geben, die Daten schneller in SCILAB reinzukriegen.

Code:

---

function [xcp,ycp]=asuropos()
// Take picture and calculate Position
//
// 4.1.2006 stochri

clear x
clear r
unix webcam
x=imread('webcam.jpeg');
hsv=rgb2hsv(x);
hsv(:,:,3)=1;
r=hsv2rgb(hsv);

red=[1 0 0];
green=[0 1 0];
blue=[0 0 1];
ref=red;
colorerror=sqrt( (r(:,:,1)-ref(1)).^2 + (r(:,:,2)-ref(2)).^2 + (r(:,:,3)-ref(3)).^2)/sqrt(2);
//xset('window',1);
//xbasc
//imshow(colorerror);

bw=im2bw(colorerror,0.3);
//xset('window',2);
//xbasc
//imshow(bw);

[xcp ycp]=centroid(1-bw)

endfunction
//
// -------------------------------------------------------------------------
// This file ist made for scilab the free mathematical toolbox
//
// Copyright (C) 2006  stochri
//
// This program is free software; you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation; either version 2 of the License, or
// (at your option) any later version.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program; if not, write to the Free Software
// Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
// -------------------------------------------------------------------------
//

---

Hallo storchi,

selbermachen sollte eigentlich nicht so schwierig sein:
https://www.roboternetz.de/wissen/in...itung_Tutorial oder
http://de.wikipedia.org/wiki/Segment...bearbeitung%29

Ich hab' leider keine Webcam. Wie kommt man bei solch einem Gerät an die Daten 'ran? Gibt es einen (mehr oder weniger) kontinuierlichen Datenstrom? Treiber? (Ich habe Windows XP und nutze Visual Studio (VB und C#))

Gruß Red Baron

Hallo Red Baron,
das Tuturial habe ich schon gesehen. Allerdings muss ich sagen, dass es ein wenig kurz gefasst ist. Wobei die Transformation der RGB Daten in das HSV Format das weseentliche Element meines Programmes ist. Hier mal der Ausschnitt aus dem obigen SCILAB Scribt:

Mit

rgb2hsv

wandle ich die Daten ins HSV Format um und setze dann die Helligkeit

hsv(:,:,3)=1;

auf Maximum. Dann werden die Daten zurücktransformiert.
Danach wird die Vektordifferenz zur Farbe rot berechnet und das Bild mit

bw=im2bw(colorerror,0.3);

in ein Schwarzweisbild umgewandelt. Dann einfach der Flächenschwerpunkt

[xcp ycp]=centroid(1-bw)

ermittelt. Der Flächenschwerpunkt enspricht der aktuellen Position des ASURO.

Das ganze läuft bei mir unter Linux. Das Programm "webcam" speichert beim Aufruf ein Bild als File in das aktuelle Verzeichnis ( ein ähnliches Programm zu finden, sollte bei XP kein Problem sein). Das Bild lese in Scilab mit

x=imread('webcam.jpeg');

ein ( da müßte es wohl auch ein Bildeinlesfunktion für VB irgendwo geben). Aber ich kenne mich damit nicht aus.


Eigentlich kann man mit einer Webkamera und einem ASURO schon ganz schön viel machen. Wenn man nur einen ASURO hat, kann man damit schon ein 1-Roboter Fussbalspiel programmieren. Die Bilderkennung muss nur den Ball und den ASURO erkennen und wissen wo das Tor ist. Das Programmieren am PC hat den großen Vorteil, dass die langwierige Fehlersuche im ASURO entfällt, weil die Steuerung ja auf dem PC läuft. Und heute erst wieder habe ich eine Webkamera für 10€ gesehen.
Und falls es bei dir mit XP nicht klappt, kannst Du ja eine Linux-Partition installieren. Ich poste dann hier alle SCILAB Files, damit du den Roboter steuern kannst. Allerdings muss man natürlich darauf achten, eine Webkamera zu kaufen, für die es einen Linuxtreiber gibt.
Ich habe mir übrigens die Logitech Quickcam Pro4000 gekauft, weil die einen CCD Chip drin hat und im Vergleich zu meiner alten Quickcam Messenger eine wesentlich bessere Bildqualität hat. Die kostet allerdings 50€.

Gruss,
stochri

Hallo Storchi,

vielen Dank für die vielen Informationen.

Ich glaube, dass das Speichern der Daten auf Platte und das Wiedereinlesen einiges an Zeit kostet (einige 100 mSec zumindest). Deshalb meine Frage nach dem Datenstrom.

Was SCILAB so genau gemacht, weiß ich nicht. Aber es sieht so aus, als ob das Bild mehrfach und jedesmal komplett bearbeitet wird. Ich glaube es wird schneller, wenn man auf jeden Bildpunkt/-ausschnitt die Operationen direkt nacheinander ausführt und dann erst zum nächsten Bildpunkt geht (bin mir aber nicht sicher).

Eine andere Möglichkeit der Optimierung ginge vielleicht etwa so:
Wenn man einmal den Ort des ASURO bestimmt hat und die ungefähre Geschwindigkeit kennt, kann man in etwa abschätzen, wo er beim nächsten Bild sein wird. Dann braucht man nur noch diesen Bildausschnitt (mit einem bisschen Sicherheitsaufschlag) zu analysieren. Also statt 600 x 800 (480.000 Bildpunkte) nur noch z.B. 100 x 200 (20.000 Bildpunkte, Faktor 24). Das könnte zu einer höheren Abtastrate führen, was wiederum die Möglichkeit der Bildrezierung erhöht.

SCILAB hatte ich schon einmal runtergeladen (zum Berechnen von Regelkreisen). Ich hab' aber zu blöd angestellt und bin damit nicht klar gekommen. Kennst du eine Seite (vielleicht sogar auf deutsch), die einen Einstieg in das Programm ermöglicht?

Ich hab' mitlerweile nachgeschaut, eine Webcam kostet wirklich nicht viel. Ich werde mir wohl eine zulegen. Denn das, was du gemacht hast, finde ich schon echt spannend! Bis dahin werde ich mal ein paar Versuche mit dem geposteten jpeg deines ASUROs machen.

Gruß Red Baron

Hallo Stochri,
kennst Du xawtv ?
Das ist ein echt gutes Video Capturing Programm, damit habe ich auch schon einiges aus der Konsole raus gemacht, vielleicht geht es damit schneller...

Gruß Sebastian

Edit:

Was ist, wenn Du Dir eine RAMdisk einrichtest, um die Bilder im Speicher zu belassen, und nicht erst auf die Festplatte zu schreiben? Das könnte eventuell auch schneller gehen, oder ?

Hallo Red Baron,

Zitat:

---

Ich glaube, dass das Speichern der Daten auf Platte und das Wiedereinlesen einiges an Zeit kostet (einige 100 mSec zumindest).

---

Das Speichern auf die Platte wird vielleicht schon 100mSec oder so um den Dreh dauern. Bei mir scheint es allerdings eher der Aufruf der webcam-Funktion zu sein. Es dauert nämlich in der Kommandozeile auch so ca.2 Sekunden. Es könnte natürlich auch damit zusammenhängen, dass ein jpeg-Bild gespeichert wird und dafür wird die Komprimirungsroutine wohl auch etwas Zeit benötigen.

Zitat:

---

Was SCILAB so genau gemacht, weiß ich nicht. Aber es sieht so aus, als ob das Bild mehrfach und jedesmal komplett bearbeitet wird.

---

Sieht so aus, als wenn Du es schon ausprobiert hast? Ich habe festgestellt, dass das Anzeigen des Bildes sehr viel Zeit braucht. Wenn man die Anzeige abschaltet, geht die Verarbeitung wesentlich schneller. Mein Positionsfindealgortihmus braucht, wenn man das Bildladen wegläst und die Bildausgabe abschaltet 260ms (bei 320x240 Punkten). Und meinen Rechner habe ich momentan nur auf der halben Geschwindigkeit laufen (1.2GHz ). Wenn ich auf 2.6GHz hochtakte, rechne ich mit einer Ausführungszeit von unter 150ms.

Zitat:

---

Also statt 600 x 800 (480.000 Bildpunkte) nur noch z.B. 100 x 200 (20.000 Bildpunkte, Faktor 24). Das könnte zu einer höheren Abtastrate führen, was wiederum die Möglichkeit der Bildrezierung erhöht

---

Klar eine Reduzierung der Punkteanzahl erhöht die Geschwindigkeit. Aber wie schon erwähnt, macht ja momentan eher das Bildeinlesen mit mehr als 2Sekunden im Vergleich zu den 150ms Auswerung den großen Anteil

Zitat:

---

SCILAB hatte ich schon einmal runtergeladen (zum Berechnen von Regelkreisen). Ich hab' aber zu blöd angestellt und bin damit nicht klar gekommen. Kennst du eine Seite (vielleicht sogar auf deutsch), die einen Einstieg in das Programm ermöglicht?

---

Scilab Kurzeinführung: http://www.nt.fh-koeln.de/fachgebiet.../scilabein.pdf
Ansonsten bei der Bildverarbeitungstoolbox exec(SIPDEMO)

Zitat:

---

Ich hab' mitlerweile nachgeschaut, eine Webcam kostet wirklich nicht viel. Ich werde mir wohl eine zulegen

---

Na, immer drauf los ! Bildverarbeitung ist ja ein hochaktuelles und spannendes Thema. Mich wundert ja, dass die Leute hier im Robterforum so wenig damit machen.
Wenn Du Dir eine Kamera kaufst und es nicht wirklich eng ist mit dem Geld, würde ich die bessere kaufen. Mit der Bildverarbeitung ist es wie sonst in der Messtechnik: Wenn der Sensor schlecht ist, macht das die Signalauswertung meistens nicht einfacher !

Gruss,
stochri

Hallo Sebastian

Zitat:

---

kennst Du xawtv ?

---

Ich dachte immer, das sei der Fernseher, so wie kdetv.

Zitat:

---

Was ist, wenn Du Dir eine RAMdisk einrichtest, um die Bilder im Speicher zu belassen, und nicht erst auf die Festplatte zu schreiben?

---

Hab ich auch schon mal dran gedacht, ich weiss aber nicht, wie man mit Linux eine Ramdisk einrichtet. Bei webcam gibt es die Möglichkeit, jede Sekunde ein Bild auf die Platte zu schreiben, die habe ich aber verworfen, weil die Bildaufnahme mit der Auswertung synchronisiert sein muss. Wenn ich mit "top" die Systemlast anschaue, braucht "webcam" ca. 7%CPU time. Scheint noch einigermaßen ok.

Gruss,
stochri

Zitat:

---

Ich dachte immer, das sei der Fernseher, so wie kdetv.

---

Ja mit xawtv kann man auch Fernsehen, aber woher es Das Bild bekommt, und wohin es veschickt wird bleibt Dir überlassen.
leider habe ich momentan das Programm nicht drauf, um Dir ein paar Beispiele zu nennen, aber Google danach, oder installiere es und schau Dir die Manpages dazu "man xawvt" vielleicht lohnt es...

Die RAMdisk einzurichten, ist ganz einfach:

Erstelle Dir irgendein Verzeichnis z.B. /mnt/RAM, oder ~/meineRAMdisk oder was auch immer.
Jetzt tipe als root:

mount -t tmpfs -o size=20M tmpfs /mnt/RAM
oder
mount -t tmpfs -o size=20M tmpfs ~/meineRAMdisk

oder wie Dein Verzeichnis auch immer heißen mag.

Schon bist Du fertig, Du hast Dir eine RAMdisk mit 20MB größe eingerichtet!

Daß Du mit size=.... die größe angeben kannst brauch ich wohl nicht zu sagen, oder O:)

mit
df -h kannst Du prüfen, ob sie auch wirklich angelegt worden ist
Das gute daran ist, es werden nicht wirklich 20MB "verbraucht" sondern die größe variert, je nachdem wieviele Dateien drin sind, dynamisch also.

schreibe Deine Bilder einfach in Dieses Verzeichnis, ich hoffe, daß es hilft...

Achso willst Du als user darin schreiben, muß ein Eintrag in /etc/fstab rein, ich hoffe, daß es auch klar ist...

Gruß Sebastian

Hallo stochri,

Ih hätte da noch eine Frage, und zwar, wie komunizierst Du mit dem Asuro ?

Mit der "Onboard" IR-Lösung?
Klappt das gut?

Ich habe irgendwo ein Joystick ausgegraben, und möchte versuchen meinen
Asuro damit zu steuern.
Nur stellt sich die Frage, wie gut die IR Verbindung funktioniert, nicht das sie nach 20 cm abbricht.

Klar könnte ich es selber probieren, nur netterweise hab ich mir die IR-Hindernisserkennung gebaut, und jetzt zeigt die Diode nach vorn, noch schön in einem Röhrchen versteckt #-o .

Gruß Sebastian

Du kannst das auch ohne Kamere machen.
Du sendest einfach deine Pixeldaten vom PC-Programm (ich nehme Pure-Basic) einfach zum Robby und legst für jeden Pixel eine Wegstrecke und Drehpunkt fest.
Mit einem anderen Pure-basic-Programm beobachtet die Kam vom Robby und sendet dir das Bild zum Pc.

Castle

Hallo Storchi,

nein, ich habe noch nie mit SCILAB gearbeitet.

Den Trick mit Flächenschwerpunkt habe zuerst gar nicht so mitgekriegt. Ist aber eine feine und einfache Sache und macht das Leben ziemlich leicht.

Ich habe 'mal ein wenig experimentiert. Als Basis habe ich dein ASURO-Foto genommen.

Ich habe das Bild pixelweise abgearbeitet. Alle Punkte, die eine H-Wert zwischen 350 ... 360 ... 0 ... 10 haben (also rot) und eine Sättigung von min. 70%, habe ich in die Mittelwertberechnung einbezogen, alle anderen ignoriert. Verarbeitungszeit: 150 mSec bei einem 320 x 240 großen Bild (AMD +2800, Windows XP, Visual Basic .NET).

Ich habe mir die Position des Schwerpunkts gemerkt und danach nur noch ein 50 Pixel x 50 Pixel großes Bild um den Schwerpunkt herum analysiert. Hat 3 mSec gedauert. Wenn man davon ausgeht, dass eine Webcam 30 fps liefert und 5-10 Messungen pro Sekunde bereits ein gutes Ergebnis liefern sollten, ist das schon so gut wie Echtzeit.

Danach habe ich deinem ASURO einen grünen Punkt auf der Nase verpasst (zum Detektieren der Orientierung, s. Bild) und bei der Berechnung den "grünen" und den "roten Schwerpunkt" berechnet (Ergebnis s. 2.Bild).

Das mit dem Grün hat nicht ganz so gut geklappt. Der ASURO hat da einige grüne Flächen "onboard". Man sollte also nur solche Flächen berücksichtigen, die eine min. Größe haben.

Ingesamt finde ich das Resultat sehr ermutigend. Gleich morgen werde ich schauen, dass ich an eine Webcam herankomme.

Gruß Red Baron

Hallo Sebastian,

Zitat:

---

Ih hätte da noch eine Frage, und zwar, wie komunizierst Du mit dem Asuro ?
Mit der "Onboard" IR-Lösung?
Klappt das gut?
Ich habe irgendwo ein Joystick ausgegraben, und möchte versuchen meinen
Asuro damit zu steuern.

---

Ich verwende den ASURO IR-mässig im Orginalzustand. Das mit der IR-Kommunikation ist immer ein wenig problematisch. Im Moment häng der Sender in etwa 1m Höhe über dem ASURO. Laut Datenblatt hat die IR-Dioden einen Öffnungswinkel von 17°. Das dürfte einen Lichtkegel von

1m*sin(17°/180*pi)*2 = 58cm

ergeben. Man sieht aber schon, dass der Aktionsradius relativ begrenzt ist. Die Verbindung klappt bis auf eine Entfernung von ca. 4m, damit könnt man also den 4fachen Aktionsradius erreichen, wenn man eine 4m hohe Decke hätte.

Beim Avoider https://www.roboternetz.de/phpBB2/vi...=141576#141576 habe ich auch einen SFH300 wie beim ASURO als Empfänger verwendet. Den kann ich mit meiner normalen CD-Fernbedienung steuern. Ich erwähne das deshalb, weil Fernbedienungen im Vergleich zum ASURO Tranmitter mit Sendeströmen bis in den Amper-Bereich arbeiten und deshalb die Lichtstärke wesentlich größer ist.
Wenn der Empfänger allerdings vom Sender wegdreht, verliert man auch da die Verbindung.

Fazit:
Eine direkte IR-Fernsteuerung für den ASURO ist problematisch. Das läßt sich nur dann vernünftig verwenden, wenn ein kleiner Aktionsradius wie für das Experiment in diesem Thread ausreicht, der Sender ortsfest in gnügendem Abstand über dem Roboter angebracht wird und der Empfänger Sichtverbindung zum Sender hat.

Gruß,
stochri

Hi Leute

könnt ihr das mir dem Farb/Flächenschwerpunkt mal genauer erklähren?
Wäre ne große Hilfe, brauch sowas nämlich grad in Delphi...

Danke!

Hallo Red Baron,

Zitat:

---

nein, ich habe noch nie mit SCILAB gearbeitet.

---

Habe ich bis letzte Woche auch nicht. Aber ich verwende schon seit einiger Zeit MATLAB. Im privaten Bereich möchte ich aber SCILAB einsetzen.
Das sind eigentlich Mathematikprogramme, die für eine schnelle, interaktive Datenvisualisierung und das schnelle Ändern und Ausprobieren von Algorithmen geeignet sind.

Für eine reale Steurung nimmt man diese Programme normalerweise nicht.
Ich habe mit allerdings schon ein wenig mit dem Thema Bildverarbeitung befasst und wenn es um das Thema Neuentwicklung eines Algorithmus geht, glaube ich, dass man mit SCILAB schneller als mit BASIC oder C ans Ziel kommen. Aus diesem Grund sind große Matlab System ja auch in Entwicklung und Forschung im Automotive Bereich so weit verbreitet. Dort ist eben Zeit auch Geld.

Bei der Bildverarbeitung besteht das Problem, dass die Bilder sehr stark von der Beleuchtungssituation abhängen. Aus diesem Grund ist es sehr nützlich, wenn man die Daten schnell visualisieren, analysieren und den Algorithmus anpassen kann.
Etwas ungewohnt bei Scilab/Matlab ist, dass jede Varible als Matrix behandelt wird. Das Verfahren läst sich allerdings relativ rasch verstehen und dann ist der Syntax nur noch eine relativ einfache Scribt-Sprache. Falls es jemand in diesem Thread wünscht, kann ich mal ein kleines Tutorial machen, dann kann man das bestimmt schnell verstehen.

Gruss,
stochri
[/quote]

Hallo Xtreme,

Zitat:

---

könnt ihr das mir dem Farb/Flächenschwerpunkt mal genauer erklähren?
Wäre ne große Hilfe, brauch sowas nämlich grad in Delphi...

---

Der Algothmus für die Positionsbestimmung ist folgender:

1. Alle Farbpunkte auf gleiche Helligkeit bringen
2. Den Rot-Anteil nehmen mit einem Grenzwert vergleichen
3. Die Punkte, die über dem Grenzwert liegen in ein binäres Schwarz/Weisbild übertragen
4. Den Flächenschwerpunkt im Binärbild berechnen.

Hier das SCILAB Scibt für die Berechnung des Schwerpunktes einer Matrix. Wenn Du weist, wie man Matrizen mit Vektoren multipliziert, sollte das kein Problem sein, in Delphi umzusetzen.

Code:

---

function [rowcp,columcp]=centroid(mat)
//
// calculate the centerof a matrix
//
//
// $Revision: 1.0 $ $Date: 2006/04/01


nx=length(mat(:,1)); // nx=number of rows
ny=length(mat(1,:)); // ny=number of colums
gx=1:nx; // create vektor x=1,2,3..nx
gy=1:ny; // create vektor x=1,2,3..ny
summat=sum(mat); // calculate sum of all elements
if summat==0, // if summat=0 then the result is not defined
        columcp=0;
        rowcp=0;       
else
        columcp=sum(mat*gy')/summat; // calculate colum center point
        rowcp=sum(gx*mat)/summat; // calculate row center point
end


endfunction

//
// -------------------------------------------------------------------------
// This file ist made for scilab the free mathematical toolbox
//
// Copyright (C) 2006  stochri
//
// This program is free software; you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation; either version 2 of the License, or
// (at your option) any later version.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program; if not, write to the Free Software
// Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
// -------------------------------------------------------------------------
//

---

Gruss,
stochri

Hallo Red Baron,

Zitat:

---

Danach habe ich deinem ASURO einen grünen Punkt auf der Nase verpasst (zum Detektieren der Orientierung, s. Bild) und bei der Berechnung den "grünen" und den "roten Schwerpunkt" berechnet (Ergebnis s. 2.Bild).

---

Sieht schön aus, der grüne Punkt.

Zitat:

---

Das mit dem Grün hat nicht ganz so gut geklappt. Der ASURO hat da einige grüne Flächen "onboard". Man sollte also nur solche Flächen berücksichtigen, die eine min. Größe haben.

---

Der Algorithmus wird eben stabiler, wenn man nur die Farbe rot vewendet. Wie schon mal weiter oben erwähnt, habe ich die Winkelbestimmung absichtlich über die Gerade zwischen 2 Wegpunkten berechnet. Das funktiniert wirklich sehr gut, weil ja nur der erste Punkte auf der ASURO Wegstrecke unbekannt ist. Sobald man ein kleines Stück gefahren ist, kennt man den Winkel für alle nachfolgenden Fahrten.
Aber für den Lerneffekt ist es natürlich gut, auch mal mehrere Farben zu suchen.

Gruss,
stochri

Hallo Red Baron,
wie wäre es mit der Analyse des folgenden Bildes ?
Vieleicht wäre es praktischer, wenn man den Ball grün machen würde, wie im Beispiel von Dir oben. Aber ich glaube, irgendwann wird man wohl kaum drumrum kommen, mehrere Gegenstände gleicher Farbe im Bild zu finden Ich bin noch am Überlegen, wie man es schaffen könnte, die beiden roten Dinge auseinander zu halten ....

Gruss,
stochri

Aha... Danke! Den Code dieser centeroid funktion hab ich gesucht...
Dann mach ich mich mal an die Arbeit...

Hallo

nochmal ne Frage:

Code:

---

Matrix:  A=
          00000
          01110
          01110
          01110
          00000

Summe der Matix: 9?!?!??

Vektoren:
a=(1,2,3,4,5)
b=(1,2,3,4,5)

---

Wie multipliziere ich jetzt die Vektoren und die Matrix?
Also A*a bzw A*b

Der Zentrale Punkt müsste dann allso
P( (A*a)/9 | (A*b)/9) )sein....

Ich liege warscheinlich total daneben, stimmts?!??!

RedBaron könntest du evtl den VB code posten... den kann ich nämlich besser lesen, Danke!

Zitat:

---

Matrix: A=
00000
01110
01110
01110
00000

Summe der Matix: 9?!?!??

Vektoren:
a=(1,2,3,4,5)
b=(1,2,3,4,5)

---

stimmt beides

Zitat:

---

Wie multipliziere ich jetzt die Vektoren und die Matrix?
Also A*a bzw A*b

Der Zentrale Punkt müsste dann allso
P( (A*a)/9 | (A*b)/9) )sein....

---

Nicht ganz, weil A*a nicht gleich a*A ist.
Matrixmultiplikation heißt ja immer Zeile mit Spalte multiplizieren.
richtig wäre
P( (A*a)/9 | (b*A)/9) )sein, wobie ich allerding immer irgendwie Zeile und Spalte vertausche, es könnte also auch
P( (b*A)/9)|(A*a)/9 ) sein

bei Deiner obigen Beispielmatrix werden allerdings beide Fehler kompensiert, weil sie ja symmetrisch ist. Nimm lieber mal

00000
11100
11100
11100
00000

Gruss,
stochri

AAHHH!!
Stimmt... Matrixmultiplikationen sind ja nicht kommutativ.
Danke!

00000
11100
11100
11100
00000

Bei der Matrix müsste als Schwerpunkt
zeile=3
spalte=2
rauskommen.

Wenn Dein gesamtes Projekt funktioniert, poste doch mal das Ergebnis mit Bidl und so. Willst Du eigentlich den ASURO dann mit Delphi steuern ?
Mich würde interessieren, wie schnell dass der ganze Algoritnmus dann arbeitet.

Gruss,
stochri

Moment... wenn ich nen Vektor mit ner Matrix multipliziere bekomm ich wieder ne Matrix... dann durch 9... wieder ne Matrix.
Ich will doch net Zahl =(
Tut mir leid, aber heut steh ich aufm Schlauch... die komplexen Zahlen von heut Vormittag taten mir wohl nicht so gut =)

Oh, jetzt... hab das sum übersehen... seh die Befehle vor lauter Matrizien nicht mehr.
jetzt stimmts!!
Ja, kann ich posten wennst fertig ist!!

EDIT:
Mich intressiert nur das Verfahren an sich. Möchte eine Art Objektüberwachung machen. Vieleicht versuche ich auch meinen Bot damit zu steuern. Ist allerdings ein Eigenbau.

Zitat:

---

Vieleicht versuche ich auch meinen Bot damit zu steuern. Ist allerdings ein Eigenbau.

---

Eigenbau ist doch toll.
Falls du noch mehr files brauchst: Ich habe jetzt das gesamte Projekt inclusive des ASURO-Codes und aller script-files nach:

https://www.roboternetz.de/phpBB2/viewtopic.php?t=15537

kopiert.

Damit kann also jeder, der Suse 10 und eine Linux-fähige Webcam hat, seinen ASURO steuern.

Gruss,
stochri

Ah! Danke, werd ich mir mal anschaun!

Hallo Xtreme,
wie läuft Deine Bildverarbeitung, kann sie den Mittelpunkt schon finden ?

Gruss,
stochri

Jep... allerdings hab ich die Bilder bis jetzt immer noch "von Hand" geladen. Arbeite gerade daran das Bild direkt von der Cam zu laden. Ich hab schon mal was mit Video Capture gemacht, wird also nicht mehr lange dauern... morgen vieleicht.

Hallo Zusammen,
im Moment versuche ich gerade, einen Algorithmus für die Suche nach zwei Objekten in einem Bild zu realisieren.
Es klappt schon, nur ist der Algorithmus noch ein wenig langsam. Die Tiefpassfilterung braucht etwas zuviel Zeit.

Hier eine Beschreibung des Algorithmus zu den obigen Bildern ( gestern war's schon etwas zu spät ):

Bild1: Orginalbild
Bild2: Rote Farben mittels des Algoritnus wie weiter oben im Thread beschrieben extrahiert und in eine Pixelbild umgewandelt
Bild3: tiefpassgefiltertes Pixelbild, durch die Tiefpassfilterung werden aus den ebenen weißen Fläche kleine Berge
Bild4: Höchste Bergspitze gesucht und Berg mittels Überzeichnen aus dem Bild entfernt danach suchen der zweiten Bergspitze
Bild5: Position der beiden gefundenen Bergspitzen

Mich würde mal interessieren, was ihr von dem Algorithmus haltet. Er funktioniert, aber vielleicht hat ja noch jemand eine andere Idee ?

Gruss,
stochri

Hallo, ich speichere die VideoCapturebilder der Cam über die Ablage in ein Picturefenster zum auswerten.
Ich Progge in Purebasic.
Ich Teste es zur Zeit über einen Button. Links ist das Videocapturebild (25 B/sec) und rechts wird nach dem Buttondrücken ein Picturebild dargestellt zum auswerten.
Eine andere schnellere Lösung als über die Ablage habe ich nicht gefunden.

Code:

---

; PureBasic Visual Designer v3.92 build 1460

IncludeFile "inc.pb"

#WM_CAP_START = #WM_USER
#WM_CAP_SET_CALLBACK_ERROR = #WM_CAP_START + 2
#WM_CAP_SET_CALLBACK_STATUS = #WM_CAP_START + 3
#WM_CAP_SET_CALLBACK_YIELD = #WM_CAP_START + 4
#WM_CAP_SET_CALLBACK_FRAME = #WM_CAP_START + 5
#WM_CAP_SET_CALLBACK_VIDEOSTREAM = #WM_CAP_START + 6
#WM_CAP_SET_CALLBACK_WAVESTREAM = #WM_CAP_START + 7
#WM_CAP_DRIVER_CONNECT = #WM_CAP_START + 10
#WM_CAP_DRIVER_DISCONNECT = #WM_CAP_START + 11
#WM_CAP_DRIVER_GET_CAPS = #WM_CAP_START + 14
#WM_CAP_DLG_VIDEOFORMAT = #WM_CAP_START + 41
#WM_CAP_DLG_VIDEOSOURCE = #WM_CAP_START + 42
#WM_CAP_DLG_VIDEODISPLAY = #WM_CAP_START + 43
#WM_CAP_SET_PREVIEW = #WM_CAP_START + 50
#WM_CAP_SET_PREVIEWRATE = #WM_CAP_START + 52
#WM_CAP_GET_STATUS = #WM_CAP_START + 54
#WM_CAP_FILE_SAVEDIB = #WM_CAP_START + 25
#WM_CAP_SET_SCALE = #WM_CAP_START + 53
#WM_CAP_SET_CALLBACK_CAPCONTROL = #WM_CAP_START + 85
#WM_CAP_EDIT_COPY = #WM_CAP_START + 30
#WM_CAP_GRAB_FRAME = #WM_CAP_START+60

Open_Window_0()
OpenLibrary(0, "AVICAP32.DLL")

hRobby = CallFunction(0, "capCreateCaptureWindowA", "Test", #WS_VISIBLE + #WS_CHILD, 120, 30, 300, 300, hWnd, 0)
SendMessage_(hRobby, #WM_CAP_DRIVER_CONNECT, 0 , 0)
SendMessage_(hRobby, #WM_CAP_SET_SCALE , 1 , 0)
SendMessage_(hRobby, #WM_CAP_SET_PREVIEWRATE, 50, 0)
SendMessage_(hRobby, #WM_CAP_SET_PREVIEW, 1 , 0)

Repeat ; Start of the event loop
 
  Event = WaitWindowEvent() ; This line waits until an event is received from Windows
 
  WindowID = EventWindowID() ; The Window where the event is generated, can be used in the gadget procedures
 
  GadgetID = EventGadgetID() ; Is it a gadget event?
 
  EventType = EventType() ; The event type
 
  ;You can place code here, and use the result as parameters for the procedures
 
  If Event = #PB_EventGadget
   
    If GadgetID = #Button_0
      If Link <> 0
        StartDrawing( WindowOutput() )
        DrawImage(Link, 440,30,300, 300)
        StopDrawing()
      EndIf
    EndIf
   
  EndIf
 
  SendMessage_(hRobby, #WM_CAP_GRAB_FRAME, 0 , 0)
  SendMessage_(hRobby, #WM_CAP_EDIT_COPY, 0 , 0)
  Link = GetClipboardData(#PB_ClipboardImage)
 
  Delay(1)
 
Until Event = #PB_Event_CloseWindow ; End of the event loop

SendMessage_(hRobby, #WM_CAP_SET_PREVIEW, 0, 0)
SendMessage_(hRobby, #WM_CAP_DRIVER_DISCONNECT, "Test", 0)
CloseWindow(0)
CloseLibrary(0)

End
;

---

Castle

In Delphi gibt es sowas wie Copyrect... so machs ich jedenfalls!
Werde heute Abend mal das Progrmm hochladen...

So, in meiner Galerie befindet sich jetzt ein Screenshot des Programms.
Bearbeitungszeit auf meinem 1,5 GhZ Rechner: ca. 450 ms

Auf meiner 3500 er Kiste läuft die Webcam komischerweiße net... muss ich mir mal genauer anschaun...

Hallo,

ich hab' mir jetzt eine WebCam zugelegt. Zur Zeit versuche ich mich darin, die Bilder mit einem VB-Programm einzulesen. Als Vorlage habe ich leider nur ein Programm in C++, das aber ekelhaft viele API-Funktionen über DirectX aufruft. Hat jemand eine Idee, wie es einfacher geht?

Hier der VB-Code (Auszüge) zur ermittlung der Schwerpunkt-Koordinaten:

Code:

---

....

bmpOrig ist eine Bitmap und enhält das Bild.

Dim mXRed As Integer, cXRed As Integer
Dim mYRed As Double, cYRed As Integer
Dim mXGreen As Integer, cXGreen As Integer
Dim mYGreen As Double, cYGreen As Integer

Dim x, y As Integer
Dim c As Color
Dim Hue As Integer
Dim Saturation As Integer
Dim Brightness As Integer

For y = 0 To bmpOrig.Height - 1
    For x = 0 To bmpOrig.Width - 1
        c = bmpOrig.GetPixel(x, y)
        Hue = CInt(c.GetHue())
        Saturation = CInt(c.GetSaturation() * 100)
        Brightness = CInt(c.GetBrightness() * 100)
        If (Hue > 355 Or Hue < 5) And (Saturation > 70) And Brightness > 35 Then
            'roter Punkt, Farbwert (Hue) zwischen 355 .. 360 / 0 .. 5
            mXRed += x 'Summe der x-Koordinaten mit roten Pixel
            mYRed += y
            cXRed += 1  'Anzahl der x-Koordinaten mit rotem Pixel
            cYRed += 1
        ElseIf (Hue > 105 Or Hue < 120) And (Saturation > 70) And Brightness > 35 Then
            'grüner Punkt, Hue zwischen 105 .. 120
            mXGreen += x
            mYGreen += y
            cXGreen += 1
            cYGreen += 1
        Else
            'irgendeine  andere Farbe
        End If
    Next
Next
mXRed = CInt(mXRed / cXRed) 'Mittelwert der x-Koordinaten mit rotem Pixel = x-Koordinate des Schwerpunkts
mYRed = CInt(mYRed / cYRed)
mXGreen = CInt(mXGreen / cXGreen)
mYGreen = CInt(mYGreen / cYGreen)

---

@storchi: Ich habe die ersten Experimente mit SCILAB gemacht. Damit kann man sicher gut Versuche anstellen. Vielen Dank noch einmal für den Hinweis auf das Tutorial.

Gruß Red Baron

xtreme, warum machst du das videocapturebild von der cam nicht ins gleiche fenster, sieht doch besser aus, als wenn es daneben hängt. es gibt dafür schöne videobefehle in der avicap32.dll :
#WM_CAP_START = #WM_USER
#WM_CAP_SET_CALLBACK_ERROR = #WM_CAP_START + 2
#WM_CAP_SET_CALLBACK_STATUS = #WM_CAP_START + 3
#WM_CAP_SET_CALLBACK_YIELD = #WM_CAP_START + 4
#WM_CAP_SET_CALLBACK_FRAME = #WM_CAP_START + 5
#WM_CAP_SET_CALLBACK_VIDEOSTREAM = #WM_CAP_START + 6
#WM_CAP_SET_CALLBACK_WAVESTREAM = #WM_CAP_START + 7
#WM_CAP_DRIVER_CONNECT = #WM_CAP_START + 10
#WM_CAP_DRIVER_DISCONNECT = #WM_CAP_START + 11
#WM_CAP_DRIVER_GET_CAPS = #WM_CAP_START + 14
#WM_CAP_DLG_VIDEOFORMAT = #WM_CAP_START + 41
#WM_CAP_DLG_VIDEOSOURCE = #WM_CAP_START + 42
#WM_CAP_DLG_VIDEODISPLAY = #WM_CAP_START + 43
#WM_CAP_SET_PREVIEW = #WM_CAP_START + 50
#WM_CAP_SET_PREVIEWRATE = #WM_CAP_START + 52
#WM_CAP_GET_STATUS = #WM_CAP_START + 54
#WM_CAP_FILE_SAVEDIB = #WM_CAP_START + 25
#WM_CAP_SET_SCALE = #WM_CAP_START + 53
#WM_CAP_SET_CALLBACK_CAPCONTROL = #WM_CAP_START + 85
#WM_CAP_EDIT_COPY = #WM_CAP_START + 30
#WM_CAP_GRAB_FRAME = #WM_CAP_START+60

Castle

Ja, dir kenn ich... verwende die auch für das Cam Fenster...
Keine Ahnung warum ich das so gemacht hab ;-)

Hallo RedBaron,
Schön, dass Du SCILAB ausprobiert hast. Es ist schon ganz gut, um mal schnell Experimente zu machen. Mittlerweile bin ich noch auf eine andere Toolbox gestossen: SIVP für Scilab. Leider hab ich die bis jetzt noch nicht zum Laufen gekriegt. Die benutzt die Open-Soruce Bildverarbeitungsroutinen OpenCV von Intel. Kennst Du diese Bibliothek ? Eine riesige Sammlung von Funktionen in C. Wenn Du also gerne weiter in C-Programmieren möchtest: dort findest Du alles, was für die Bildverarbeitung nötig ist. Allerdings kommt man natürlich vom hundersten ins tausendste. Eigentlich wollte ich nur eine Routine für eine schnelles vergrößern und Verkleinern des Bildes. Aber jetzt bin ich an der OpenCV hängen geblieben. Die Routinen sind natürlich optimiert für Intel-Prozessoren, aber auf meinem AMD lassen die sich auch kompliieren. Ich nehme mal an, dass sie dort halt langsamer laufen.

Wenn Du also genügend Zeit hast: .... OpenCV !

Gruss,
stochri