optimaler Winkel einer Cam für Wegerkennung

Hallo!

Meine Frage bzw. Problem ist thematisch nicht so leicht einzugliedern - ich versuch es einfach mal hier ;)
Ich versuche gerade eine Weg-Erkennung umzusetzen - meine Fragen nun:

Was ist ein guter Winkel für die Kamera?
- steil von oben
- so flach als möglich?
- irgendwo dazwischen?

Wie wichtig ist der Winkel überhaupt (z.B. für eine vanishing-point Berechnung)?
Brauche ich einen Horizont bzw. ist es schlau den noch in die Analyse mit einzubeziehen?

Ausreichend für mich wäre ein (Bild/Weg) Analyse von ca. 10 Meter - das sollte ausreichen um Wegkreuzungen und dergleichen rechtzeitig zu erkennen.
Ziel ist es, auf einem erkannten Weg (= die Ausgangsposition) wie z.B: Gehsteig, Parkwege, usw. zu bleiben und den nicht zu verlassen bzw. zu folgen.

Meinen aktueller Bot setzt auf einen ausgedienten Rollstuhl auf - d.h. bzgl. Höhe hab ich rel. viel Möglichkeiten.
Anhang 22649 Anhang 22650

Hab zwar schon sehr viel Zeit mit Google verbracht, aber bis jetzt noch nicht wirklich etwas zu diesem Thema gefunden.

Danke, Arno

Ich würde die Kamera ca. in der Höhe des Notebooks montieren (ganz an der Vorderseit). Somit kannst du auch Schlalöcher,... besser erkennen. Wenn du sehr flach über dem Boden bist (z.B. Höhe Laserscanner) kannst du soetwas nicht bzw sehr schwer erkennen.

Das ist zumindest meine Vermutung. Warte lieber noch auf andere Posts bzw montiere die Kamera einmal provisorisch und suche die beste Position aus. Eventuell kannst du die Cam auch auf einem Arm montieren damit du die Höhe "einstellen" kannst, je nach Anforderung.

MfG Hannes

Zitat:

---

Zitat von 021aet04

Ich würde die Kamera ca. in der Höhe des Notebooks montieren (ganz an der Vorderseit).
MfG Hannes

---

... Ober- oder Unterseite? Wenn Oberkante würde ich den Aufbau eher in der Mitte ansetzten - würde aber mit sich bringen dass es einen kleinen toten Winkel gibt, mit dem könnte ich aber ganz gut leben denke ich.

Hast Du diesbezüglich schon Erfahrungen gemacht?

Ich würde die Kamera an der Oberseite des Notebooks montieren. Es entsteht zwar ein toter Winkel, das sollte aber kein Problem sein, da wenn du dich bewegst dieses Bild schon gesehen hast, somit weißt du immer was in diesem Bereich ist. Sollte etwas kurzfristig in diesem Bereich auftauchen (Tier rennt durch diesen Bereich,....) hast du immer noch den Laserscanner.

Eine weitere Möglichkeit wäre die Cam mit einem Servo zu bewegen. Die Kamera montierst du in Höhe Oberkante des NB und an der Vorderseite des Roboters. Mit einem Servo schwenkst du die Kamera das du in die "Ferne" sehen kannst und auch den nahen Bereich sehen kannst, wenn es nötig ist.

Erfahrungen habe ich leider keine in diesem Bereich.

MfG Hannes

Hallo Hannes!

Danke mal für Dein Feedback!
Ich werde es mal an der Position versuchen. Bzgl. Servo - ich verwende die Kinect, d.h. die hat bereits einen Servo eingebaut. Die Stellmöglichkeiten sind zwar beschränkt, aber ich denke für meine Zwecke sollte es reichen.

Ich habe vor meinen Bot mehrere Funktionen zu spendieren - das eine ist eben die Wegerkennung - hier wird die Kinect einfach nach unten sehen und sich nur auf den Weg konzentrieren. Wenn ich nicht gerade im Wegerkennungsmode bin, soll die Kamera auch Gesichtserkennung (funktioniert bereits ;)) machen, dafür muss sie weiter nach oben sehen.

Ev. komme ich am Wochenende zum Testen, dann werde ich mal ein Video live stellen ;)

LG, Arno

o etwas ähnliches hab ich auch am kochen.
Mein Fahrzeug ist auch aus ausgeschlachteten Rollstuhlteilen konstruiert.
Kinect will ich aber noch nicht verwenden weil mir eine Offboard-Computervariante zum Test besser zusagt.
Daher kommt eine normale Funkkamera zum Einsatz. Das Notebook mit seiner Zusatzperipherie, wie Funkempfänger, Sender usw. steht auf einem Campingtisch und läßt mir auch zum Programmieren ausreichend Spielraum. Wenn nur nicht so verdammt viele Reflex auf dem Display wäre...;-)

Mit GPS wird dann grob navigiert um z.B Abzweigungen zu bestimmen.
Um das Fahrzeug auf der Strasse zu halten wird zur Feinpositionierung Bildverabeitung verwendet.
Dabei zeigte sich, dass Fluchtpunktbestimmung nur bei halbwegs geraden Strassen- oder Wegkanten funktioniert. Von unregelmäßigen Rasenkanten begrnzte Weg werden kaum erkannt. Dort hilft nur, Farbunterschiede auszuwerten und einen Wegverlauf zu renkonstruieren.

Der kamerawinkel ist nicht dramatisch, solange du die Strasse mit einer tiefen Perspektive siehst.
Prinzipiell ginge auch eine senkrecht nach unten gerichtete Kamera und ein Kantenerkenner. Das würde aber wahrsch. nur selten was bringen.
Waagerechte Kamera geht auch ganz gut, solange du nicht direkt "vor die Füße" blicken willst. Damit lassen sich auch Abzweigungen sehen.

Zur optischen Hinderniserkennung ist ca. 10...20m Voraussicht ganz gut. Im Nahbereich liefert dann das Kinect Distanzinformationen. Das würde ich für eine gute Kombination halten, wenn der Robbi flüssig fahren soll.

Ich hab auch ein paar Frage an dich:
Mit welchem Programm machst du Bildverarbeitung? Welche weiteren Algorithmen hast du angedacht?
Willst du gleich mit Onboardcomputer loslegen oder erst einmal mit Bauchladennotebook und Webcam losmarschieren und Freilandtests machen?

LG Thoralf

paar links:

http://www.youtube.com/watch?v=Rbhd50XlnEk
http://www.youtube.com/watch?v=vPKVfSM0cyU
http://www.youtube.com/watch?v=nb0VpSYtJ_Y
http://www.youtube.com/watch?v=2brPk3Eb1wY

Hallo Thoralf!
Danke mal für Deinen Beitrag - irgendwie ist das Thema zwar nicht wegzudenken, aber bis jetzt hab ich wenige gefunden die Feedback geben und/oder auch daran Arbeiten ...

Ich hab meine Notebook schon mehr oder weniger fix am Bot - ist zwar zum Testen ein wenig mühsam, aber ich bin mitunter dazu übergegangen alles auf Video aufzunehmen und mit diesen dann zu experimentieren - somit muss ich auch nicht immer mit dem Bot unterwegs sein.
Derzeit bin ich eben gerade am Suchen nach der optimalen Cam-Position - aber wie Du schon schreibst, so wichtig scheint die gar nicht zu sein.

Ich entwickle aktuell mit C# (ist halt einfach) und emgucv für die optische Unterstützung. Mein Ansatz ist derzeit eine Farbvergleich - ausgeschlossen werden mal Farben die (hoffentlich) nicht auf einem Weg unterkommen - wie z.B. Grün und Blau
Direkt vor dem Bot hab ich mein ROI (region of interest) festgelegt - ich gehe davon aus, dass mein Bot beim Starten "richtig" steht - d.h. das festgelegte ROI enthält den fahrbaren/erlaubten Bereich. Mein ROI vergleiche ich dann mit dem Rest des Bildes und versuche so den Weg/Bereich für die Weiterfahrt zu finden.

Mit vanishing point detection hab ich nicht mehr weitergemacht, da ich hier nicht wirklich zu einem für mich brauchbaren Ergebnis gekommen bin. Ich bewege mich sehr viel in Parkanlagen - da bin ich einfach nicht weitergekommen, was möglicherweise an meinem eingeschränktes Wissen bzgl. Bildanalyse zu tun hat ;)

Generell bin ich glaube ich noch weit weg von einer wirklich brauchbaren Lösung. Primär spiele ich derzeit eben mit ROI (finden von erlaubten Bereichen mit einer gewissen Abweichung), hough transformation, K-Means Clustering herum (in Kombination mit div. Smoothed filter usw). Immer wenn ich denke ich hab eine halbwegs gute Lösung, kommt die nächste Auswertung mit anderen Randbedingungen und ich stehe wieder am Anfang ;(

Das Letze YouTube Video wäre eigentlich so mein angestrebtes Ziel ;)

Was verwendest Du? Wie sieht denn dein Bot aus? Was ist Dein Ziel?

LG, Arno

Hallo, interessantes Projekt.
Aus meiner Erfahrung (allerdings mit anderen Bedingungen: definierte und regelmäßige Fahrspurbegrenzungen):
Höhe: so hoch wie möglich. Ist die Kamera zu tief, schrumpft die Strecke in der Entfernung vertikal auf ein paar Pixel zusammen und der Kontrast leidet. Ideal aber unpraktisch wäre Vogelperspektive.
Position: soweit nach hinten wie möglich. Die Streckenränder seitlich neben dem Roboter sollten am besten noch im Bild sein. Wird die Begrenzung erst in einem Mindestabstand vor dem Roboter erkannt (vertikaler toter Winkel), wird die Streckenerkennung in Kurven und nach kurzen Aussetzern sehr unzuverlässig, im schlechtesten Fall sieht die Kamera in Kurven die Strecke gar nicht.

Grüße


EDIT: Vanishing Point Detection scheint gerade parallele Linien zu benötigen, die gibt es wohl eher auf der Autobahn als auf Parkwegen.

@arnoa

hast ja auch schon einiges durch mit testen, ja das kenn ich auch:
Man denkt, man hats endlich und am nächsten Tag scheint die Sonne und alles geht in die Hose.
Es gibt nichts schlimmeres für eine Idee als wenn sie von der hässlichen Praxis erschlagen wird... *ggg*

Ich arbeite mit Roborealm. Das ist ein Baukastensystem, das viele Module zur Bildverarbeitung und -verbesserung umfasst. Man kann sich rel. schnell mal eine Lösung zusammenstricken und testen.
Es arbeitet interpretativ und immer aufs ganze Bild angewendet (i.a.). Dadurch ist es irgendwann ziemlich langsam und die Framerate sinkt.
Aber es werden eine ganze Reihe von Schnittstellen unterstützt, so dass über Kabel oder Funk sehr einfach auf den Robbi zugegriffen werden kann.
Die "richtige" Auswertung und Steuerung mach mit VB (nicht lachen, das ist halbwegs compiliert und schnell genug)

Mit VP hab ich auch keine guten Erfahrungen im Grünen gemacht. Es werden - wie auch EZ81 sagt - ausreichend gerade Kanten gebraucht.

Mit Bloberkennung und Highest Point bin ich etwas weiter gekommen. Gut war auch der Floorfinder von RR. Der vergleicht einen definierten Bildausschnitt auf farbe und Muster mit dem Rest des Bildes. Legt man den Ausschnitt "zu Füßen" des Robots sieht man so halbwegs die erlaubte Bahn. Problematisch wirds aber bei scharfen Abbiegungen. Dort ist der Weg einfach weg. Kamera zur Seite drehen und Weg suchen ist auch nicht so einfach, da der Floorausschnitt evtl. Wiese zeigt und den Weg nicht ermitteln kann.
Und überfährt der Erkenner die Abbiegung, so zeigt das Floormuster nur noch Wiese und die Erkennung versagt auch.
Mal sehen, was mir so schlaues einfällt.
Zumindest ist eines sicher: Ein einziger Algorithmus bringt kaum was. Nur eine Vielzahl von Erkennervarianten mit geeignetem Sensorfusionsalgorithmus wird zur Lösung führen.

Anwenden wollte ich das um den Hund auszuführen. Der Hund ist zwar über meine Bemühungen hinweg gestorben aber nun bin ich so weit, dass ich das Projekt auch nicht aufgeben will :-)

@EZ81

klingt ganz gut, deine Überlegungen, werd ich auch mal testen.
Da ich meine Technik im "Bauchladen" vor mir hertrage, kann ich ziemlich schnell ein neues Testdesign realisieren.


Insgesamt geshen halte ich das ganze für ein sehr interessantes Projekt und wir sollten unbedingt dran bleiben und hier Ideen austauschen

Hallo!

@EZ81: Danke für Dein Input - sehr gute Hinweise. Hab zwar im ersten Schritt meine Cam in der Mitte positioniert, werde diese aber jetzt ganz nach hinten pflanzen - klingt einfach alles völlig logisch was Du geschrieben hast. Auch der Hinweis dass die vorderen Räder bzw. der Bereich neben den Rädern noch sichtbar sein soll ist gut - ich hätte das natürlich genau anders gemacht ;)

Sobald ich die ersten Aufnahmen habe werde ich die mal posten - danke soweit!!!

@Thoralf: Kann man bei Roborealm auch selber (weiter) entwickeln oder kann man nur die Sachen verwenden die zur Verfügung gestellt werden? Bzgl. VB gibt nichts zu lachen. Ich schreibe ja in C# weil mir C++ zu mühsam ist. Ich denke für unsere Anwendungen ist es rel. egal was man verwendet - wenn wir mit unseren Bot´s mal zum Mars wollen müssen wir wahrscheinlich unsere Programme sowieso optimieren ;))

LG, Arno

Bei Roborealm kann man entweder durch Scriptmodule auf alle internen Variablen zu greifen. Welche das sind , wird in einem Fenster angezeigt. Das können solche Dinge sein wie "COG", "highest middle" uvam.
Die ruft man mit einer Get-Methode im script auf und kann die dann verarbeiten. Definiert man im script eigene Variablen, lassen die sich in der RR-Pipeline weiter verwenden, z.B. eine errechnete Servodrehzahl uä.
Eine andere Variante ist, Roborealm von einer anderen Entwicklungsumgebung zu starten, connecten und Variablen abzurufen oder zu übergeben.
Ich mach das mit VB (mit C geht das sicher auch), da man hier komplexere Steuerungen, dateiverarbeitungen usw. realisieren kann. außerdem ist Roborealm ziemlich spartanisch, was Module zusammenlinken oder ausdrucken angeht.
Wenn man sich mal mit RR befasst, merkt man ziemlich schnell, das erstmal schnell was zusammengeschossen werden kann, was geht, und wo man besser Programmlogik in C oder VB auslagert.

noch vergessen: ist schön, dass du über VB nicht lachst :-)

Stimmt schon, optimal sind die Programme damit nicht. Da aber die Prozessortaktgeschwindigkeiten schon jenseits von gut und böse sind, kriegt man ja eigentlich immer schnelle Programme hin.

Warum sollte man über VB lachen. Das ist eine Programmiersprache wie jede andere auch, auch wenn diese nicht so schnell ist wie C o.Ä. Es gibt ja auch z.B. Bascom (Basic für µC), und da hat u.A. Willa sehr eindrucksvoll gezeigt was man damit machen kann.

MfG Hannes

... der Aufbau ist soweit abgeschlossen ;)

Hier mal die ersten Bilder meines AU.ROB´s mit Kinect- und Notebook-Aufbau.
Anhang 22890 Anhang 22891 Anhang 22892

Weiters habe ich meiner Kinect einen Weitwinkelaufsatz spendiert, der Unterschiede ist hier zu sehen.
Anhang 22893 Anhang 22894

Nächster Schritt wird der saubere Einbau der gesamten Elektronik, parallel geht´s mit der Wegerkennung weiter.

LG, Arno

mal paar Fragen:

wieso 2 GPSse? Willst du wirklich einen Sick verbauen (Preis)? 2 Kompasse? Einer magnetisch und der andere GPS-Kompass?

ansonsten ein sehr engagiertes Projekt, Respekt!

Du bist schon weiter als ich. Ich krebse noch beim besten Wegerkenner rum und muß endlich ***seufz*** die Schnittstelle COM->Robosteuerung realisieren. Dann kann ich das Notebook auf den Robo schnallen.

Hi Thoralf!

Ich verbau praktisch alles was ich so rumliegen habe ;)

Von den zwei GPS Empfänger - die zwar sehr nahe beieinander liegen (werden über die Kinect auf einem Querträger montiert) nehme ich den Mittelwert bzw. wenn ein Empfänger einen Aussetzer hat (kommt immer wieder vor) nehme ich den Wert von dem jeweils anderen.

Kompass kommt nur mehr einer drauf – mit dem HDMM01 komme ich nicht zusammen. Der CMPS10 ist wesentlich besser und hat eine rel. gute Autokorrektur.

Vorgesehen ist auch eine Anbindung entweder von meinem Handy oder meines Pad´s - beide Android. Und die Sensoren auch noch mal mit allen anderen abzugleichen. Das wird aber sicher einer der letzten Schritte.

Sick-Laserscanner hab ich auf E-Bay wirklich sehr günstig bekommen – der PLS100-112 ist zwar schon alt, liefert aber für meine Zwecke brauchbare Werte. Mit dem Sick bekomm ich halt wirklich sehr genau Ergebnisse wo sich Hindernisse befinden.
Natürlich reichen Ultraschallsensoren auch aus (von denen ich auch nochmal 12 Stück auf meinem Bot verbaut habe) – die Entscheidung zum Sick Scanner war wirklich nur der Preis. Hätt ich den „normalen“ preis zahlen müssen hätt ich sicher keinen ;)

Wie geht’s Dir mit der Wegerkennung – hast schon was zum herzeigen, würde mich wirklich sehr interessieren? Auch wie Dein Bot aussieht.

LG, Arno

so nun ist das erste Video fertig:
http://www.myvideo.de/watch/8739752/..._mit_roborealm

wie schon mal geschrieben, gehe ich hier einen Weg im Dorf mit meinem Bauchladen ab, eigentlich "nur" mit einem Camcorder. Da ich mit Roborealm auch avi-Files laden und in der Pipeline nach Herzenslust verarbeiten kann, stört mich weder Wetter noch Reflexe auf dem Notebook-Display.
Dadurch ist ein Optimieren der Auswertung total easy.

Hier arbeite ich mit einem Floor-erkenner, der zu Füßen in einem Auswahlviereck die Helligkeit, den Farbwert und die Textur bestimmt und im Bild sucht. Was er findet ist, im Video das bräunliche Overlay. Von dem wird Streifen für Streifen der COG-Wert bestimmt und die Trajektorie im Display angezeigt. So findet man ziemlich leicht den optimalen Istwert in der Trajektorie. Bei zu starker Abweichung vom Soll ergibt das eine einfache Rechts-Links-Steuerinformation, die mit dem grünen Pfeil angezeigt wird. Wahrscheinlich muß ich aber bei einer realen Steuerung mit dem Analogwert arbeiten und eine PID-Steuerung realisieren.

In der nächsten Zeit nehm ich mal eine ganze Latte von Videos zur Analyse unterschiedlicher Bedingungen auf:

- versch. Lichtverhältnisse (tags, früh, abends, pralle Sonne und Schattenwurf)

- versch. Straßenbeläge wie Asphalt mit und ohne Schlaglöcher, Pflaster, Beton, Kies und Erde

Übrigens hab ich in meinen versch. Videos gesehen, daß der Kamerawinkel optimal ist, wenn die unter Bildkante direkt vor die Füße oder max. 1m entfernt davon gelegt wird und die obere Bildkante der Strassenhorizont ist (kann auch etwas kürzer sein).

Bilder vom Robbi kommen auch noch.

Die Stunde der Wahrheit kommt noch, wenn alles im Freien spielen soll. Aber es sit schon schön, daß der Erkenner überhaupt ersteinmal brauchbar ist.

LG Thoralf