Autonomes Fahrzeug, abgeschlossenes Projekt

[daniel.weber]

Hallo Hannes,

in welcher Entwicklungsumgebung programmierst du die Software?

[.:Sebastian:.]

Also nach dem Icon in den ersten Screens würde ich auch Delphi tippen.

Außerdem sind die Buttons relativ groß, dass machen Delphiprogrammierer normalerweise gern.

Sieht aber nicht schlecht aus !
Bin mal gespannt wie das weiter geht.

Sebastian

[vohopri]

Hallo,

ich programmiere unter Delphi. Eigentlich ist es egal, was man verwendet.
Eine ausgefeilte graphische Entwicklungsumgebung spart schon einiges an Arbeit.
Ein komfortabler Zugang zum Windows API wird für solche Sachen auch gebraucht.
Und Objektorientiertes Programmieren kann ich mir nicht mehr wegdenken und ist auch state of the art.

grüsse,
Hannes

[daniel.weber]

ok danke. Mit Delphi hatte ich noch nicht so viel zu tun, habe mehr mit VB und C++ programmiert, derzeit versuche ich mich ein bisschen in C# einzuarbeiten, da ich wie du bereits gesagt hast, auch nicht so viel Zeit mit programmieren von Fensterklassen oder ähnliches verlieren möchte und ich denke da ist C# bestens für geeignet

[.:Sebastian:.]

Moin Moin

Sorry wenn ich mich kurz mal leicht OT einklinke :

Also Ich Programmiere meine PC Anwendungen meistens in C++ mit dem Qt Framework.
Das geht auch ziemlich einfach, eigentlich fast genauso wie in Delphi. (unter Linux greift Delphi imho. auch auf QT zurück).
Ein nur Qt Programm ist dann sogar plattformunabhängig.
Das einzeigte Manko is halt wenn ich an Hardware rann muss, weil ich dann Betriebssystem spezifische Sachen brauche, dann wars das mit platformunabhängig.
Aber sonst kann ich das eigentlich nur empfehlen. Open Source, schöne Doku und tolle Einsteigertutorials.

Ich hab aber noch was zur Topic :
vohopri, wie genau ist eigentlich die Erkennung von den Leds, also vor allem die Farbliche ?
Ich wollte mal über einen ähnlichen Weg zwei Leds erfassen, einmal rot und einmal grün, hatte aber das Problem das meine Webcam gerauscht hat.
Der Plan war eigentlich einfach am Pc den R und den G Kanal einzel zu betrachten und dann da drin die beiden hellsten Punkte zu suchen.
Ging eigentlich ganz gut, war für mich aber letztlich doch etwas zu ungenau.
Ab un zu sind halt mal ein paar falsche Pixel als Led durchgegangen, dass ließ sich zwar noch einfach rausrechnen, aber als ich dann noch mit unterschiedlichen Lichtverhältnissen gespielt hab, war es schon nimmer so toll.
Weil a) die Webcam versucht hat die Helligkeitsunterschiede auszugleichen, was dann immer in 20 Frames mit den tollsten Farben geendet hat und b) weil mein Algo etwas umständlich war (9te Klasse Mathematik vs. |R^3), was sich in einer ziemlich lahmen Framerate geäußert hat.

Du hast, wenn die Farbe auf den Bildern passt, eine gelbe und eine blaue Led.
Wie gut lässt sich die wieder finden ? / Warum gerade diese Fraben ?

Sebastian

[daniel.weber]

Hallo Sebastian,

hatte vor kurzem mal etwas zu dem Problem mit dem Rauschen bei Webcams gelesen. Man kann einen einfachen Filter drüber laufen lassen. Mach einfach ein Bild bei vollkommener dunkelheit, am besten Webcam verdecken. So bekommst du nur das Rauschen der Kamera. Nun ziehst du das Bild vom Rauschen von dem Livebild ab.

Dieser einfache Filter soll recht gute Ergebnisse bringen. Habe das aber selber noch nicht ausprobiert.

[.:Sebastian:.]

Danke für den Tipp ...
Soweit war ich damals auch schon, aber die webcam hat nicht nur wie normale Webcams "pixelweiße" gerauscht, sondern auch "blockweise" d.h. auf einer fläche von ca. 30x30px hat sich die Farbe entlang von einem Kanal verschoben.

Ich hab damals immer2 Bildern genommen und die miteinander verrechnet.
D.h. wenn zwei Pixel nur eine Abweichung von durchschnittlich a ( a war einstellbar) hatten ( a > |[r1 + g1 + b1 ] / 3 - [r2 + g2 + b2] / 3|) hab ich das Pixel aus dem Zweiten Bild genommen, wenn nicht einfach nur die Werte wenn nicht hab ich das Pixel zunächst übersprungen und im einem zweiten Durchlauf Anhand der Differenz zu den umliegenden, schon bestimmten, Pixel im Ausgabebild entschieden ob, das Pixel aus dem ersten oder aus dem zweiten Bild genommen wurde.
Die Idee war ganz gut, bloß meine Umsetzung hat zu viel Rechenzeit benötigt. Dadurch ging die Framerate in den Keller und das verrechnen von 2 Bildern hat teilweise auch die Led gefressen.
Danach ist die Webcam völlig krepiert und ich hatte auch keine Lust mehr da großartig weiter zu programmieren.

Der Grund für meine Frage war nur, dass ich demnächst (nach meiner Facharbeit d.h. in 4-5 Wochen) wieder mit Bilderkennung experimentieren will.
Konkret: Ich will mit einer Kamera meinem Modellheli folgen.
Der hat 3 Positionslampen, die schön blinken, das sollte recht einfach zu machen sein.
Dann wert ich das ganze in Linux mit C umsetzen (ohne GUI) und für einfacheren Bildfilter auf asm zurück greifen.

Sebastian

[vohopri]

Hallo,

Zum Thema Programmiersprachen gibts da einen interessanten Thread: https://www.roboternetz.de/phpBB2/vi...=430297#430297 ,aber Bildanalyse ist hier schon gut aufgehoben.

Meine Algorithmen sind noch nicht fertig ausgearbeitet, weil ich erst andere Arbeiten abschliesse. Die Tests, die ich gemacht habe waren erfolgreich. In den Bildern davon sind die Kreuzchen und Linien vom Programm richtig gesetzt worden, wie man ein paar Postings zurück sehen kann. Gegen das Rauschen, das ja wirklich im Extremfall bunt funkeln kann, gibt es mehrere Strategien.

Das was Daniel wieder gegeben hat hilft nicht gegen das Rauschen. Mit einer ähnlichen Methode kann ich nur statische Kamerafehler abziehen. Wenn ich aber von einem verrauschten Bild ein 2. Bild, das nur Rauschen enthält, abziehe, dann verstärke ich das Rauschen. Denn die beiden Rauschanteile sind nicht korreliert.

Was aber hilft, ist das Bilden von Mittelwerten über mehrere inhaltlich identische Bilder hinweg. Das hilft im vorliegenden Fall normalerweise nicht, weil ich keine inhaltlich identischen Bilder habe, das Fahrzeug bewegt sich ja im Normalfall. Aber man könnte durchaus das Fahrzeug anhalten und dann 500 identische Bilder mitteln, um das Fahrzeug wieder zu findenn.

Was ich in Versuchen auch als hilfreich bestätigt gefunden habe, das ist das Weichzeichnen. Das ist auch eine Mittelwertbildung, aber innerhalb eines Bildes um die jeweiligen Pixels herum. Einzelne farbige Pixels verschwinden ebenso wie einzelne andersfarbige Bildpunkte inmitten der LED.

Auch kannst du jeden Bildpunkt mit seiner Umgebung korrelieren. Die unkorrelierten schwächst du ab. Das bewertet dann die Dichte des Vorkommens einer Farbe höher.

Anhand der Streuung der Koordinatenwerte, kann ich auch immer beurteilen, ob ich eine brauchbare Bildpunktgruppierung gefunden habe, oder ob ich noch Ausreisser eliminieren muss.

Was ich als sehr zielführend herausgefunden habe ist folgendes. Anhand eines Grenzwertes werden die Bildpunkte als ähnlich oder unähnlich zur gesuchten Farbe (zweiwertig) eingestuft. Vor der Weiterverarbeitung werden die Punkte, die von mehr anders bewerteten umgeben sind, umbewertet. Das ist ein sehr wirksamer Filter, wenn man die Grösse des gesuchten Objekts kennt und die Krümmung des Umrisses einbezieht.

Eine weitere Strategie ist die, dass man die Kriterien für die Ähnlichkeit so anpasst, dass man so viele Bildpunkte findet wie man erwartet: Zum Beispiel 80 % von der Fläche des gesuchten Objekts.

Und die wichtigste Strategie hab ich schon in einem Postig erwähnt: Ich weiss, wo sich das Fahrzeug befinden soll. Also wird es dort mit einem bestimmten Fehlerradius gesucht. Es ist sinnlos, das ganze Bild ab zu suchen. Dazu gehört, dass das Programm ein flexibles Modell des Fahrzeugverhaltens hat. Wenn das Fahrzeug aufgrund neuer Batterien immer weiter fährt, als berechnet, dann wird das in die weiteren Berechnungen einbezogen.

Die Anpassung der Bildhelligkeit überlasse ich nicht der Kamera, die kann das Programm selbst vornehmen. Auch kann man so Unsinn, den die Kamera produkiert, wieder rückgängig machen.

Es gibt also genug Möglichkeiten, für gute Ergebnisse zu sorgen. Tests werden später zeigen, was nötig ist.

Gelb und Blau habe ich nur gewählt, weil in der Navigation rot backbord und grün steuerbord signalisiert. Die Farben müssen sich nur ausreichend von der Umgebung abheben.

grüsse,
Hannes

[radbruch]

Ein echt extremer Schwenk von einfachen Tests in die Untiefen der Bildanalyse. Sehr lehrreich und inspirierend.

Gruß

mic

[vohopri]

Hallo Mic,
hallo die Runde,

Das Bild von den "Untiefen der Bildanalyse" finde ich sehr treffend. Das Gewässer ist seicht und von Klippen durchsetzt. Was helfen kann, das ist sorgfältige Navigation.

Mein Control Center ist jetzt wenigstens ein Rahmen, in dem man Algorithmen testen kann. Testdaten gibt es so genug, und die Ergebnisse kann man schön verfolgen. Zunächst geht es noch um die Fahrzeugerkennung. Das geht noch nicht flexibel genug, aber wenn es erkannt wird, dann habe ich Position und Ausrichtung in der Karte.

Bild hier  

Die magentafarbenen Balken sind die Grenzzonen um Möbel, Raumbegrenzung und den Rand des Kamerabildes Klarerweise zeichnet das Programm die Grenzen des Kamerabildes automatisch in die Karte.

Als nächstes werde ich Plausibilitätsprüfung und das Nachführen der Analyseparameter implementieren und austesten.

grüsse,
Hannes