ASURO mit Kamera ferngesteuert

Hallo Xtreme,
hab mir mal das Bild in Deiner Galerie angeschaut. Das Fadenkreuz hat der Algrithmus ja schön in die Mitte zentriert. Bei 480ms Frame-Folge müsste sich das Objekt ja gut online verfolgen lassen. Funktioniert das einigermaßen störungsfrei ?
Die rote Farbe erscheint mir etwas blass, das war bei meinr alten Quickcam Messenger bei Kunstlicht auch so. Bei der neuen 4000 Pro ist die Farbe wesentlich besser, der Störabstand des Algorithmus schein mir deshalb auch viel besser zu sein.
Vielleicht hiflt es auch, verschiedene rote Oberflächen auszuprobieren. Es könnte sein, dass manche bei Kunstlicht besser dargestellt werden.

Gruss,
stochri

Hallo,

falls es interessiert, ich habe es dann doch geschaft, die WebCam mit VB.NET einzulesen. Hier das Visual-Studio-Projekt.


Gruß RedBaron

Hallo Red Baron,
schön, dass Du es geschafft hast. Ich denke mal VB.NET werden etwas mehr Leute verwenden als SCILAB. Jetzt bin ich mal gespannt, ab es bei Dir auch klappt, den roten Punkt zu erkennen. Willst Du später den ASURO dann auch per infrarot fernsteuern ? Da könntest Du ja erst mal mein primitiv-Programm verwenden, da habe ich das hex-file gleich mitgepostet. Man müsste es blos schaffen von VB.Net auf dei serielle Schnittstelle die Zahlen 1-4 zu schreiben.

Gruss,
stochri

Hallo storchi,

Datenübertragung ist auch noch eine Baustelle... Meine IR-Verbindung reicht max. 1m (bei gutem Wetter O:) ).

Dieses Thema werde ich als eines der nächsten angehen. Ich denke da an Funk (Funkmodul oder Blauzahn) oder ich werde der IR-Schnittstelle ein bisschen mehr Saft verschaffen. Eine TV-Fernbedienung schafft schließlich auch einige Meter bzw. einen ganzen Raum (mit Reflektionen).

Deine Aufgabe mit den verschieden Punkten ist schon interessant. Ich werde mich 'mal bei Gelegenheit damit auseinander setzen. Aber dadurch habe ich einen wichtigen Hinweis erhalten (s.u.).

Ich denke, ich werde erst einmal klein anfangen. Das Problem, die Position zu bestimmen (z.B. Ausgleich der perspektivischen Verzerrungen) und den Asuro zu steuern, sollte erst einmal reichen. Wahrscheinlich werde ich ihn dazu zunächst einfach auf eine möglichst einheitliche Fläche setzen (Rückseite einer Tapete oder so). Autonomer Marsroboter kommt nächste Woche d'ran :-b .

Ich werde aber bei der Schwerpunktberechnung (ist ja eigentlich eine Bestimmung des arithmetischen Mittels) die Standarabweichnung mit berechnen. Das wird kaum mehr Zeit kosten, sichert aber das Ergebnis ab. Wenn die Standarabweichnung zu hoch ist, wird es wahrscheinlich mindestens einen weiteren Punkt im Sichtfeld geben.

Ich werde es mit folgender Strategie versuchen:
1) Die erste Position zu erkennen, ist die schwierigste Aufgabe: Mögliche Lösungen: a) einen einheitlichen Untergrund verwenden (s.o.) oder b) die erste Position mit der Hand markieren oder c) den Asuro ein wenig fahren lassen. Wenn er das einzige Objekt ist, das sich bewegt, ist alles klar.
2) Folgepositionen kann man anhand der erwarteten Bewegung ziemlich genau vorhersagen (umso besser je häufiger die Analyse stattfindet). Wichtig ist nur, dass die geschätzte Position noch im "roten Fleck" der realen Position liegt. Danach Floodfill-Algorithmus. Aus dem, was man füllt, wieder die Position berechnen (Schwerpunkt ist schon ok). Hierbei darf der Asuro-Fleck nur nicht mit einem anderen Fleck verschmelzen.

Aber als allererstes muss ich mir entweder eine ordentliche Leuchte zulegen oder etwas anderes einfallen lassen. 100W Zimmerfunzel reicht nicht für die WebCam. Ich werde es einmal mit einem Reflektor vom Fahrrad versuchen und den von der WebCam aus beleuchten. Müsste dann eigentlich recht gut auf die Kamera zurückstrahlen.

Gruß RedBaron

Hallo Red Baron

Zitat:

---

Datenübertragung ist auch noch eine Baustelle... Meine IR-Verbindung reicht max. 1m (bei gutem Wetter Angel ).

---

Bist Du sicher ? Bei mir geht die Übertragung mindestens 3m. Allerdings Sende ich nur Daten vom PC zum ASURO. Wenn ich über die IR programmieren wollte, ginge es nicht so weit.
Ich verwende den USB-Tranceiver, da stimmt die Sendefrequenz vielleicht genauer als beim RS232 Transceiver. Bei 1m Abstand hat man durch den engen Sendekegel der IR-Diode ja nur die ca. 60cm Aktionsradius des ASURO ( wie weiter oben im Thread berechnet ). Ich habe mir schon überlegt, ob ich nicht 3 zusätzliche Dioden dranhänge um den Lichtkegel zu vergrößern.

Zitat:

---

Aber als allererstes muss ich mir entweder eine ordentliche Leuchte zulegen oder etwas anderes einfallen lassen. 100W Zimmerfunzel reicht nicht für die WebCam.

---

Was hast Du denn für eine Kamera ? Würde mich mal interessieren. Meine alte war auch etwas lichtschwach, aber die neue 4000 PRO geht erstaunlich gut bei normalem Zimmerlicht.

Gruss,
sto---chri

Hallo zusammen.

Ich arbeite grad an der Uni an nem Programm, welches mit einer von der Decke nach unten gerichteten CCD-Kamera ine einem bestimmten Gebiet eine Menge (bis zu 60) Mikroroboter erkennen und tracken soll. Da bin ich natürlich auf die gleiche Problematik gestossen, und meine Lösung sieht folgendermaßen aus:

Die Roboter kriegen zwei Positions-smd-LEDs aufs Dach gesetzt, die einen genügen großen Abstrahlwinkel haben, sonst verliert die Kamera sie an den Rändern des Gebiets. Diese beiden LEDs sollten möglichst verschiedene Farben haben, also z.B. rot und blau, um die Ausrichtung der Bots zu bestimmen. Mit rot und gelb hab ich allerdings z.B. schon Schwierigkeiten gehabt, weil in dem rot sehr viele gleiche Farbanteile stecken wie in dem gelb und umgekehrt. Soviel zur Theorie.

In der Realität haben wir auf die zweite LED verzichtet, und zwar - man glaubt es kaum - wegen des Energieverbrauchs. Die Roboter sind halt doch _sehr_ klein, und somit auch ihre Akkus. Aber man kann die Ausrichtung ja auch über den letzten und den aktuellen Standort bestimmen, merkt dann halt nicht wenn der Bot auf der Stelle rotiert.

Warum LEDs? Im HSV-Colorspace kann man diese eben auch bei widrigen Randbedingungen noch sehr zuverlässig aus dem Bild extrahieren. Da auf die Roboter-Arena noch ein Beamer verschiedene Sequenzen projeziert, aus denen die autonomen Bots selbst ihr Position und andere Daten bestimmen können, gibt es ständig irgendwelche Reflexionen und Helligkeitsunterschiede, die normale Farbmarkierungen ausschließen würden.

Die Bildverarbeitung sieht folgendermaßen aus:
- grabbe Frame von der Kamera
- Wandle Frame von RGB nach HSV (wie das geht ist findet sich u.a. im Bildverarbeitungs-Tutorial)
- Filter: Alles, was nicht LED ist wird weiß, die LEDs werden auch aufgearbeitet
- der eigentliche Erkennungs-Algo läuft im Prinzip durch das Bild, sucht Farbkleckse/LEDs, vergleicht mit alten Positionen und gesammelten Daten und entscheidet dann welcher Roboter wo ist.

Die Mittelpunkte der Kleckse bestimme ich einfach, indem für jeden Pixel eines Kleckses der x- und y-Wert aufaddiert werden und dann jeweils durch die Anzahl der Pixel geteilt wird. Das müsste das gleiche sein, das ihr meint.

Ich hoff das war jetzt hilfreich (auf jeden Fall lang :)
Gruß
Raphael

Zitat:

---

Warum LEDs? Im HSV-Colorspace kann man diese eben auch bei widrigen Randbedingungen noch sehr zuverlässig aus dem Bild extrahieren. Da auf die Roboter-Arena noch ein Beamer verschiedene Sequenzen projeziert

---

Hallo Raphael,
das mit der LED ist eine sehr schöne Lösung gerade weil ihr ja den hohen Störabstand wegen des Beamers braucht. Das könnte man sogar recht gut auf dem ASURO umsetzen, weil der ja auf der Oberseite ein paar LEDs hat.

Für mein Miniprojekt, bei dem ich meinem künstlichen Ball folgen will, muss ich es anderst machen, weil ich in den Ball keine LED einbauen möchte.

Bei Deinem Verfahren hat man natürlich auch den zusätzlichen Vorteil, dass die Fläche der LED's relativ klein sind und fast als Punkte im Bild erscheinen dürften. Bei meine etwas größeren Ball kann es Unterbrechungen im Objekt geben, deshalb ist bei mir die Tiefpassfilterung eingebaut. Mittlerweile funktioniert das sogar schon sehr zuverlässig.

Zitat:

---

Ich hoff das war jetzt hilfreich (auf jeden Fall lang Smile

---

Ja, ist immer ein wenig anstrengend, soviel zu schreiben, gell ? Deshalb habe ich mich jetzt mal kurz gefasst.

Beste Grüße,
stochri

Ich benutze übrigens auch OpenCV, da fällt mir spontan noch was dazu ein: Wenn du eh einen Ball, also ein aus jeder Perspektive rundes Objekt tracken willst, kannst du dir mal die Hough-Transformation anschauen. Is auch in openCV implementiert, cvHoughCircles oder so heißt das dann. Ist ein praktischer Algorithmus zur Enteckung von Kreisen in Grafiken...

Zitat:

---

Ich benutze übrigens auch OpenCV ...
die Hough-Transformation anschauen....

---

Ah, interessant, ich wusste nicht, dass es die Hough-Transformation auch für Kreise gibt.
Allerdings frißt die ja normalerweise ziemlich Rechenpower. OpenCV ist ja eigentlich für Intel-Prozesoren, ich konnte sie aber auf meinem AMD-System auch kompilieren. Ich nehme mal an, dass das Ganze dann ein wenig langsamer läuft.
Die Beispiele hat es zwar aus irgendwelchen Gründen nicht mitkompiliert, aber das werde ich auch noch irgendwann rausfinden.
Hast Du eigentlich ein Bild von Deiner Kamera ? Wenn ja und es nicht so geheim ist, könntest Du es hier ja mal posten, es ist immer schön ein paar Bilder hier zu sehen.

Bis dann,
stochri

Ehrlich gesagt hab ich keine Ahnung ob ich das darf, denk aber schon. Allerdings is das nicht so spannend.... einfach so ne Firewire-Kamera, die eben von oben auf eine 1,60*2m große weiße, eingegrenzte Fläche ausgerichtet ist... und dann eben noch ein Beamer. Von den Robotern gibt es bisher nur 5 oder so, die werden grad erst noch entwickelt. Ich hab eben einige Tests mit LEDs ohne Roboter durchgeführt und mir eine Simulation geschrieben, die die Bewegungen der Roboter vortäuscht und dem eigentlichen Trackingprogramm Bilder mit "LEDs" liefert...

Benutzt du OpenCV unter Win oder Linux? Probleme mit den Beispielen hatte ich bei meinem Linuxsystem auch schon, das lag aber glaub ich an den Parametern, mit denen sie von dem Skript kompiliert wurden... als ich sie nochmal von Hand kompiliert hab hats glaub bei allen geklappt.

Ist die Hough-Transf. nicht sogar ursprünglich nur für Kreise gedacht? Mich hat die Linienversion in OpenCV überrascht. Is ja egal. Ich würd mir auf jeden Fall ma die Doku dazu durchlesen... je nach dem wie schnell dein System ist merkst du auch mit AMD nicht viel von der Rechenintensität. Es handelt sich ja um einen grafischen Algorithmus (da werden ja tatsächlich ne Menge Kreise gezeichnet, ein Schwellwert gebildet und ausgewertet)... möglicherweise ist das dann gar nicht sooo systembelastend wie sämtliche Kreisberechnungen tatsächlich auszuführen... Weiß nicht ob die These haltbar ist :)

Ich nutze nen P4-Rechner (Taktfrequenz weiß ich grad nicht... sorry) mit 1 GB RAM, und dan kann man schon ne Menge grafisches Zeugs in Echtzeit machen, bis mal Verzögerungen bemerkbar sind. Is aber natürlich auch Intel.