Navigation in der Wohnung

Hallo,

ich suche nach bisher verwendeten Möglichkeiten der Navigation. Manches habe ich schon im Kopf. Wie Navigation per Karte, an Baken ausgerichtete Navigation oder an einem Kompass ausgerichtete Navigation. Ich treffe vor allem immer wieder auf Karten, die zur Navigation genutzt werden. Ich denke, die Art und Weise der Navigation hängt vom Ziel ab. In meinem Fall will ich jetzt nur von Punkt zu Punkt fahren. Zu Punkten, wo ich den Roboter zuvor hin navigiert habe. Danach soll er selbstständig die Punkte anfahren. Abstände zu Hindernissen und Wänden will ich mit Ultraschall erfassen.

MfG
:Weihnacht

Ich hab mal was sehr Interessantes gesehen, da hat jemand ein Streifenmuster auf die Wand projiziert und das Gerät hat das Muster erkannt und daraus seine eigene Position ermittelt. Leider kann ich mich nicht mehr genau erinnern, was der Hintergrund der ganzen Geschichte war. Das Streifenmuster war so eine Art digitaler Code, der sich aber an keiner Stelle wiederholt, so dass das Muster an jeder Stelle eindeutig ist. Wenn du deine kompletten Wände in Fußleistenhöhe mit solchen Mustern markieren würdest, könnte sich der Roboter daran sehr genau orientieren. Allerdings ist die Auswertung per Kamera sicher aufwändig.

Wenns effizient sein soll, kommst du an irgendeiner Form von Karte nicht vorbei, denn der Roboter muss ja entscheiden, wie er von A nach B fährt. Ist eine Wand dazwischen, muss er ermitteln können, ob er links oder rechts fährt - mit Ausprobieren wird es jedes Mal ein Glücksspiel.
Entfernungen sind mit Ultraschall sicher ganz gut messbar. Allerdings genügt schon eine Sporttasche auf dem Boden, um den Robotter zu verwirren.
Interessant wöre vielleicht auch ein (unsichtbarer Infrarot) Laserstrahl, der die gesamten Bodenfläche durchstreift. Mit einem drehbaren Sensor könnte der Roboter schauen, woher der Strahl kommt. Mit zwei Strahlen aus verschiedenen Ecken könnte er seine Position sehr genau bestimmen. Probleme machen hier aber schon verwinkelte Möbelecken, Tisch-/Stuhlbeine usw.
Ultraschallsender an verschiedenen Stellen und ein Empfänger im Roboter könnten aus den Laufzeiten der Signale die Position berechnen. Dafür brauchts dann aber mindestens 3 Signale, entweder 3 Ultraschallsender oder ein Funksender als Zeitnormal und zwei Ultraaschallsender für die Triangulation. Alles recht aufwändig.

Ich würd es mit einer gespeicherten Karteninformation und Abstandsmessung per Ultraschall versuchen. Und dann zusätzlich versuchen, den Roboter erkennen zu lassen, falls sich ein unerwartetes Hindernis auftut (eben die Sporttasche oder ein rumlaufender Mensch).

Ich habe unterm Strich nicht mehr gefunden, als Kartennavigation.
Mich interessieren aber auch andere Verfahren. Ich will sehen, welche Vor- oder Nachteile es gibt und was für Probleme damit verbunden sind.

Ich befürchte, dass es viel mehr nicht geben wird. Bei der Abstandsmessung gibt es noch unterschiedliche Möglichkeiten, aber bei der Wegfindung?

:Weihnacht

Zitat:

Ich habe unterm Strich nicht mehr gefunden, als Kartennavigation ..

Stimmt, das Gebiet ist kaum beackert. Ich kenne noch diese Diskussionen - aber ohne wirklich neuen Erkenntnisse. Da gehts aber mehr um die Bahnplanung (Ziel kennen - also Grobplanung und Hindernisse erkennen und umfahren - also Feinplanung).

Wenn Du auf das Überqueren von größeren Flächen verzichten kannst, der Roboter sich also nur an Wänden entlang hangelt, sollte ein schwenkbarer(-135...+45°) IR-Abstandssensor mit kurzer Reichweite (Sharp/VL53L0X/VL53L1X) für die Wegfindung reichen. Das Teil folgt dann einfach der "Rechtsfahrregel" und bildet aus Strecken/ Ecken eine unverzweigte Landmark-Liste.

Zwischengeschobene Gegenstände, die Deinen Weg unerwartet kreuzen und damit die Anzahl der Ecken erhöhen, bekommst Du mit der "Damerau-Levenshtein Distanz" in den Griff (ein Algorithmus, der ursprünglich zum Finden ähnlicher Wörter oder Sätze erfunden wurde). Geschlossene Türen allerdings sind ein Problem, dass sich nur durch Verzweigungen in der Landmark-Liste lösen lässt.

Schade, dass sich hier nichts weiter etabliert hat. Vielleicht aber doch? Vielleicht weiß jemand noch was. Zum Sortieren von Werten z.b. gibt es auch verschiedene Algorithmen.
Die Ansätze einen Weg zu finden sind oft recht kompliziert. Ich werde versuchen den Roboter implizit lernen zu lassen. Mal schauen, wie weit der Speicher dann ausreicht und wie schnell oder langsam das dann vonstatten geht.

@Holomino
Ich schau mir das mit der "Damerau-Levenshtein Distanz" mal etwas genauer an. Danke!

:Weihnacht

Zitat:

Wenn Du auf das Überqueren von größeren Flächen verzichten kannst .. Das Teil folgt dann einfach der "Rechtsfahrregel" ..

Jaaa, mein WALL R ist so ein "Rechtsfolger", oder, wie der Name hinter der Abkürzung schon sagt, ein " Wand Abstands Limit Läufer auf RC-carbasis ". Drei Sensoren als Baugruppe "IR-LED-36kHz" und IR-Empfänger SFH5110. Und der WALL R läuft ja ganz ok: bei ordentlichem Wandabstand rechts UND viel Abstand nach vorne - gib Gummi, abgestuft steigend bis Grenze und leichter Rechtsdrall bis Abstandslimit rechts erreicht ist, bei wenig Abstand in Fahrtrichtung wird die Fahrgeschwindigkeit stetig abgesenkt und angepasst links gesteuert.

Zitat:

Zitat von Moppi

@Holomino
Ich schau mir das mit der "Damerau-Levenshtein Distanz" mal etwas genauer an. Danke!

Du musst das dann aber auch etwas abstrakt denken und Dir vorstellen, dass Du anstatt Zeichen z.B. Zahlenkolonnen miteinander vergleichst, wobei die einzelnen Zahlenwerte dann auch wieder eine gewisse Ungenauigkeit aufweisen dürfen. Erst dann macht's Sinn.

Zitat:

der Roboter sich also nur an Wänden entlang hangelt, sollte ein schwenkbarer(-135...+45°) IR-Abstandssensor mit kurzer Reichweite (Sharp/VL53L0X/VL53L1X) für die Wegfindung reichen

Ich habe schon fast zwei Hand voll HY-SRF05. An Wänden langhangeln - nicht wirklich. Er soll sich an Hindernissen generell orientieren. Im Grunde so, wie wir das auch tun. Wenn wir die offene Tür sehen, schwenken wir rechts oder links und bewegen uns hindurch. So ein ähnliches Prinzip, nur nicht mit komplexen Bildern, soll es werden. Den Roboter an die Hand nehmen, zu einem Punkt in der Wohnung führen, diesen speichern, dann zu einem andern Punkt in der Wohnung führen, diesen auch speichern. Danach soll er diese beiden Punkte wechselseitig aufsuchen. Können auch mehrere Punkte sein.

MfG
:Weihnacht

Wenn Du ein wenig Geld ausgeben willst, kannst Du es mit UWB-Baken
versuchen:
https://www.decawave.com/product/dwm1000-module/

Hier gibt's eine Auswertung:

https://www.ardumower.de/index.php/d...echnologie-uwb

Also, es würde mich wundern, wenn es dazu nicht massenweise Literatur gäbe. Ergebnis einer kurzen Google-Bemühung:

Grundlegendes aus Wiki. ...und hier.
Hier ist was Grundlegendes.
Hier gehts nochmal etwas genauer zur Sache.
Oder hier... noch etwas spezieller.
Oder hier.

Guten Morgen,

Beschreibungen zu Verfahren und Ansätzen der Fusion, von Sensordaten, wurden hier im Forum auch schon oft besprochen. Ich habe im Wesentlichen dieselben Links im Netz gefunden. Möglich wäre es, mehrere Sensoren zu verwenden, dann müssen die Daten zusammengebracht werden. Das habe ich im Wesentlichen nicht, sondern für jede Richtung einen Sensor, der mindestens eine relative Entfernungsmessung erlaubt. Aus den Sensordaten versucht man die Position des Roboters im Raum zu bestimmen. Einer Positionsbestimmung muss irgendein System zugrunde liegen, eben landläufig eine Karte. Anhand einer Karte kann ein Weg zum Ziel bestimmt werden. Hier sind dem Erfindungsreichtum eigentlich kaum Grenzen gesetzt. Ich suche vor allem Möglichkeiten, ohne dies auszukommen.

Jeder von uns kann seine Wohnung aus dem Kopf skizzieren. Aber keine maßstabsgetreue Zeichnung anfertigen. Es sei denn, er hat die Wohnung vorher vermessen und sich die Maße gemerkt. Also gibt es Orientierungsverfahren in Räumlichkeiten, die wir intuitiv anwenden. Und dazu merken wir uns dann bestimmte Eigenschaften oder relative Gegebenheiten, die wir aus dem Gesehenen entnehmen, um uns zu orientieren. Auch wenn wir einen Raum nicht vermessen haben, können wir doch einen bestimmten Punkt in ihm wiederfinden, an dem wir zuvor schon einmal waren. Waren wir öfter dort, haben den Punkt öfter gefunden, gelingt das Wiederfinden besser. Gelingen tut uns das vor allem über Bilder, die wir erfassen und auswerten. Wenn wir, wie im Dunkel, nicht sehen können, wird es weitaus schwieriger. Je mehr Details wir erkennen können, je besser gelingt uns der Vorgang der relativen Orientierung. Allerdings ist mir bisher unklar, welche Detailgenauigkeit dafür notwendig ist. Größere Entfernungen müssen nur geschätzt werden, wie: "ich bin weit weg" oder "ich bin nah dran". Bin ich nah an einer Wand oder sonstigem Hindernis, dann genügt ebenfalls eine Schätzung zur Kollisionserkennung, wie: "ich bin ca. 10cm entfernt" oder "gleich stoße ich an". Ich kann meine genaue Position in der Regel nicht bestimmen, eine relative Position, die zur Orientierung genügt, aus dem Gedächtnis heraus, aber schon, wenn ich meine Position in einer Karte eintragen sollte. Wir zeichnen aber in der Regel keine Karte, wenn wir uns durch Räume bewegen. So Verfahren, wie sich an einer Wand entlang zu hangeln, sind da schon ganz gut und zielen in die Richtung, der Orientierung ohne vorliegende Karte und genaue Positionsbestimmung.

MfG

:Weihnacht

Ergänzend, zur räumlichen Orientierung, ein Link.

Zur Systematik:
a) Sensoren mit internen Referenzen (z.B. Odometrie, Gyro, Accelerometer)
b) Sensoren für relative externe Referenzen (US, IR, LIDAR)
c) Sensoren für absolute externe Referenzen (Kompass, GPS, Baken)

1.) wenn der Raum exakt (!!) bekannt ist, kann man die Position über a) und b) mit einer gewissen Wahrscheinlichkeit per Monte-Carlo-Filter (=Partikelfilter) berechnen (Kompass allerdings hilfreich)
https://www.youtube.com/watch?v=Rj7s...layer_embedded

2.) wenn der Raum unbekannt ist oder viele zufällige Hindernisse enthält (SLAM), braucht man zu a) und b) auch zusätzlich c)

Um mehrere Sensoren entsprechend ihrer unterschiedlichen Spezifität und Sensitivität zusammenzufassen, verwendet man statistische Methoden zur Sensor-Fusion (z.B. den Extended Kalman Flter).

Für Baken in mehreren Räumen mit Wänden dazwischen haben sich z.B. Dezimeterwellen mit 4-8 Baken (anchors) bewährt, s. pozyx
https://www.pozyx.io/?gclid=EAIaIQob...SAAEgJTNvD_BwE
https://www.pozyx.io/shop/product/creator-kit-lite-67

Ich schätze das jedenfalls so ein, dass die Navigation einigen Aufwand mit sich bringt und deshalb einen relativ leistungsfähigen Rechner braucht. Dagegen soll das Fahrzeug wahrscheinlich mit Akku fahren und deshalb einen möglichst geringen Energieverbrauch haben. Da empfiehlt es sich vielleicht, den Roboter mit einem sparsamen µC zu betreiben und per Funk (433 MHz/BLE/WLAN) die Sensordaten, und Fahrbefehle auszutauschen. Die eigentliche Rechenarbeit würde dann ein Pi machen, der Roboter könnte mit einem ESP gesteuert werden. Hätte auch den Vorteil, dass man alle Daten auf dem zentralen Rechner gut visualisieren und die Algorithmen bequem vom Schreibtisch aus entwickeln kann. Wenn dann mal alles läuft, kann man immer noch schauen, ob man die gesamte Logik in einen µC packen kann.

Spannend ist sicher, wie man das System flexibel und ein bisschen lernfähig bekommt. In einer Wohnung verändern sich die meisten Dinge kaum (Wände), einige in engen Grenzen (Türen) und manches ziemlich unerwartet (Sporttasche/Staubsauger/Kinderspielzeug auf dem Boden, rumlaufende Leute). Da muss man sich was einfallen lassen. Spontan hatte ich die Idee, die gesamte Fläche in (mehr oder minder) kleine Felder einzuteilen und jeweils zu speichern, ob das Feld ein Hindernis ist oder befahrbar. Wände könnte man als permanente/feste Hindernisse definieren. Türen als Felder mit variablen Hindernissen, andere Felder könnte man temporär als Hindernis kennzeichen - wenn der Roboter dort vorbei kommt, schaut er nach, ob das Hindernis noch da ist. Ggf. kann er sich merken, dass dort immer mal Hindernisse auftauchen (meine Sporttasche steht meist am gleichen Fleck). Er könnte auch Wahrscheinlichkeiten für Hindernisse speichern. Die Genauigkeit des Systems hängt von der Größe der Felder ab. Wenn man erst mal mit 25x25 cm anfängt (800 Felder für eine 50 qm Wohnung - bei 10 cm sind es schon 5000, bei 5 cm 20000), kann man es später verfeinern, was Speicherbedarf und Rechenaufwand erhöht aber die Genauigkeit verbessert.

Zitat:

In einer Wohnung verändern sich die meisten Dinge kaum (Wände), einige in engen Grenzen (Türen) und manches ziemlich unerwartet (Sporttasche/Staubsauger/Kinderspielzeug auf dem Boden, rumlaufende Leute).

Deswegen halte ich die "indoor"-Navigation für die einfachste Navigation.

Zitat:

hängt von der Größe der Felder ab. Wenn man erst mal mit 25x25 cm anfängt

Haben wir doch gar nicht drüber gesprochen! - Das habe ich mir heute Morgen mit der Größe auch schon so gedacht, ist denke ich ein guter Startwert. Allerdings will ich zunächst weg, von der berechnenden Navigation, hin zu: ich kenne den Weg, fahre den ab und wenn ich mich verfahren habe, kenne ich Fahrmanöver, um ihn wiederzufinden. Das Wiederfinden der Ladestation ist die letzte Herausforderung, weil deren Position sich auch geringfügig ändern kann. Ist die Ladestation mal in einem andern Raum, tut es auch nicht weh, wenn der Roboter still steht und "nachfragt" - dann weißt man ihm den Weg und gut ist. Hat er sich mehrere Positionen gemerkt, könnte er die später absuchen (muss aber nicht sein).

Ich denke, vor allem Speicherplatz wird es kosten, deshalb habe ich schon eine SD-Karte im Hinterkopf. Allerdings würde ich schon gerne mit den 3MB des nodeMCU ESP-12E auskommen. Der noch verfügbare Programmspeicher (vermutlich bis 500KB) soll dann für kurzzeitige Ausflüge herhalten, wie wenn Hindernisse auftauchen, bei denen großzügiges Ausweichen nötig ist (der Weg zurück sollte gefunden werden).

MfG
:Weihnacht

Offline-Entwicklung ist sicher komfortabler, als gleich alles im System selbst zu machen. Bei jeder Programmänderung musst du das Ding neu flashen...

Weg kennen und abfahren klingt einfach... 2 m geradeaus, dann 1,5 m rechts, dann 2 m links - Ziel erreicht. So lange sich der Roboter auf definierten Bahnen bewegt, müsste er nur in gewissen Anständen schauen, ob der Fahrweg noch plausibel ist. (Ist die Wand so weit weg, wie sie sein sollte?). Schwieriger wird es, wenn er aus dem Tritt kommt. Was dann? Die Sporttasche im Weg sagt ihm: "Hier stimmt was nicht." Aber was?
Die Navigation mit Ultraschall ist kompliziert, weil die Echos nicht immer von der gegenüberliegenden Wand kommen, sondern auch mal von seitlichen Objekten - Mauerecken, Türrahmen usw.
Baken zur Positionskorrektur sind ein probates Mittel, aber wenn sich ein Roboter auch in neuen Umgebungen zurechtfinden soll, ist das unpraktsich. ("Inbetriebnahme: Kleben Sie zunächst die Baken an gut sichtbaren Stellen in allen Räumen an die Fußleisten...")
Netter wäre ein System, das aus den Ultraschalldaten verlässlich die eigene Position ermittelt. Das ist aber sicher relativ aufwändig. Man könnte die Ultraschallerkennung auf wenige, sehr typische und gut identifizierbare Stellen beschränken. Ideal sind Türzargen. Meist steht dort nichts im Weg. Es gibt in der Regel keine Objekte, die näher sind als die Türzarge und das Signal verfälschen. Bei jeder Türdurchfahrt kann das Gerät die eigene Position in Fahrtrichtung und seitllich recht genau bestimmen. Allerdings spielt der Fahrtwinkel noch eine Rolle. Das könnte man mit einem Kompass hinkriegen, wenn der genau genug ist. Aber vielleicht gibts Störungen durch elektromagentische Felder - Stromleitungen, Lautsprecherboxen, ... keine Ahnung, wie zuverlässig das ist.

Man könnte auch für jede Position (im Raster) die Ultraschalldaten in alle vier Richtungen speichern und dann jeweils mit den gemessenen Distanzen vergleichen. Es dürfte aber nicht einfach sein, Messungenauigkeiten Poisionsabweichung (Raster +/- 5-25 cm) und Winkelabweichungen rauszurechnen. Bein recht kleinem Raster braucht man wieder viel Speicherplatz.

Zitat:

Schwieriger wird es, wenn er aus dem Tritt kommt. Was dann? Die Sporttasche im Weg sagt ihm: "Hier stimmt was nicht." Aber was?

Das Was interessiert ja nicht. Für den Roboter ist doch einfach nur eine (oder mehrere) Distanzmessung signifikant anders. Ist dann ein nicht zuzuordnender Fall, wo er erst mal stehen bleiben würde, bis eine Anweisung erfolgt, wie er in diesem Fall weiterfahren soll. Bei diesen und ähnlichen Distanzmessungen wird er das dann immer so tun, das kann sich auch um ein ganzes Fahrmanöver handeln. Wenn er mal aus dem Tritt kommt, was passieren kann, weil jemand gegen ihn läuft, würde ähnliches bewirken. Man zeigt ihm, wie er fahren soll, bis er seinen Weg von allein weiter fährt. In dieser oder ähnlicher Situation wird er das dann genau so tun.

Zitat:

Die Navigation mit Ultraschall ist kompliziert, weil die Echos nicht immer von der gegenüberliegenden Wand kommen, sondern auch mal von seitlichen Objekten

Stimmt schon, kommt aber irgendwie drauf an, wie viele Fehlmessungen es gibt. Ich würde mit 1 Sensor für jede Richtung anfangen. Die sind fest installiert und es gibt schon mal keine Fehlerquelle, die von einem motorischen Antrieb ausgehen könnte (wie bei nur einem Sensor für alle Richtungen). Solang nicht ständig stark schwankende Werte auf allen Sensoren gleichzeitig auftreten, sollte sich der Roboter orientieren können. Auch eine falsche Messung ist eine Messung und damit verwertbar, sie tritt so vermutlich nur an bestimmten Positionen auf oder in bestimmten Situationen. Daher würde ich sagen, es gibt nur Messungen mit Ergebnissen, solang sie nicht komplett untauglich sind, weil der Sensor meinetwegen defekt ist.

Zitat:

Es dürfte aber nicht einfach sein, Messungenauigkeiten Poisionsabweichung (Raster +/- 5-25 cm) und Winkelabweichungen rauszurechnen.

Da weiß ich nicht, wie/was Du (das) meinst. Ich würde ohne Winkel arbeiten. Es ist nur interessant, in welchem Maß die Motoren angesteuert werden, abhängig von der Umgebung. Falls das nicht funktioniert, würde ich überlegen, ob ich dann einfach mit festeingestellten Werten (Winkeln) arbeite. Vielleicht auch mit beidem, wegen einer Korrekturmöglichkeit.

MfG
:Weihnacht

Du meinst, wenn er mal nicht weiß, wo er ist, piepst er und blinkt rot und dann setzt man ihn an eine definierte Stelle und von da aus gehts dann wieder weiter... das halte ich für eine nur zweitbeste Lösung.

Das mit den Messungen sehe ich anders. Erstmal kann man nicht davon ausgehen, dass der Roboter immer nur in rechten Winkeln fährt - mit der Zeit wird er im Winkel abdriften und dann sind die Messwerte weitgehend untauglich. Zweites hängen die Fehlmessungen stark von der Position ab. Fährt der Roboter mittig auf die Türzarge zu, misst er mehrere Meter bis zur nächsten Wand, steht er leicht schräg oder fährt weiter am Rand, bekommt er das Echo der Türzarge und denkt "Ups, da ist wohl ne Wand. Wo bin ich denn jetzt geladnet? Da mach ich mal besser das Rotlicht an!".

Es hilf dir ja nicht, wenn du weißt, dass die Wand 3 Meter vor dir sein soll, wenn der Roboter um 20° falsch fährt. In rechtwinkligen Räumen kann man immerhin versuchen, mit Drehungen die kürzeste Distanz zu finden - die ist dann im rechten Winkel zur Wand. Je weiter man von der Wand weg ist, desto schwieriger wird das wegen Reflexionen, Störobjekten usw. Deshalb sind wohl diese Wandläufer so beliebt, weil sie sich ja immer nur in konstantem und relativ kleinem Abstand zur Wand bewegen müssen. Wandende = Türzarge - 90° Drehen und weiter fahren... Das ist einfach aber ineffizient.

Zitat:

und dann setzt man ihn an eine definierte Stelle

Nein, man steuert ihn - nicht Umsetzen! Also man zeigt ihm, was er tun muss.

Zitat:

Das mit den Messungen sehe ich anders....

Ok, ich sehe, Du denkst anders. In Hindernissen und Wegen, die gefunden werden müssen, inkl. Speicherung, wo sich was befindet.

Zitat:

Wandende = Türzarge - 90° Drehen und weiter fahren... Das ist einfach aber ineffizient.

Könnte man annehmen. Du findest lieber den kürzeren Weg.

Ich dachte etwas anders. Ich gebe den Weg vor, damit ist dies vermutlich der effizienteste Weg, aber vermutlich auf jeden Fall der tauglichste, direkte Weg. Es sei denn, ich suche mir extra einen umständlichen Weg oder lasse den Roboter unterwegs noch ein paar Drehungen auf der Stelle absolvieren - wäre nicht so gut.
Also wenn ich ihm den Weg zeige, kann ich auch Kurven schneiden und eben den besten Weg wählen, den er nehmen soll. Ist evtl. auch der Weg, bei dem er mir am wenigsten in die Quere kommt. Der Roboter soll sich diesen Weg, anhand der Umgebungsparameter (Ultraschallsignale und evtl. andere Sensoren), merken.

MfG
:Weihnacht

Ich versuche schon, deinen Ansatz nachzuvollziehen. Aber "Weg vorgeben"... was heißt das genau? Den Weg als Fahranweisungen? Oder als Streckenführung in Relation zur Umgebung (Abstände zu anderen Objekten)?
Sinnvoll ist wahrscheinlich eine Kombination aus Antriebswerten (zurückgelegte Strecke und Richtung) und Ultraschallmessungen. Die müssten dann immer übereinstimmen. Schwierig wird es, auf Abweichungen zu ragieren. Und die Messungen sind nicht immer nur ein bisschen ungenau, so dass man sagen kann "Ich bin 20 cm zu weit rechts". Störobjekte, Winkeldrift und Fehlmessungen können das Ganze ziemlich durcheinander bringen. Ich stell mir das wirklich nicht so einfach vor.

Zitat:

Störobjekte, Winkeldrift und Fehlmessungen können das Ganze ziemlich durcheinander bringen.

Deswegen wollte ich wissen, ob es solche Ansätze woanders schon gibt, zum Nachvollziehen der Probleme, die dann in der Realität auftreten. Wollte mich etwas damit beschäftigen, während ich noch auf Teile warte.

Zitat:

Den Weg als Fahranweisungen? Oder als Streckenführung in Relation zur Umgebung (Abstände zu anderen Objekten)? ... eine Kombination aus Antriebswerten (zurückgelegte Strecke und Richtung) und Ultraschallmessungen.

So in etwa. Eine genaue Entscheidung habe ich da noch nicht getroffen. Mal sehen, was die Steuerung der Motoren so ergibt.

Zitat:

Und die Messungen sind nicht immer nur ein bisschen ungenau, so dass man sagen kann "Ich bin 20 cm zu weit rechts".

Das muss ich noch herausfinden. Die Probemessungen mit dem SRF05 waren sehr positiv, was die Genauigkeit angeht. Was die Reproduzierbarkeit angeht, habe ich noch keine Erfahrung. Deshalb will ich aber zunächst vier Sensoren fest installieren und eben keinen Motor zum Schwenken nur eines Sensors nehmen. Herauszufinden gilt es auf jeden Fall, in welchem Raster/welcher Auflösung die Orientierung stattfindet. Ob in einem Vielfachen von 10cm, von 25cm oder was anderem. Ich denke, bei Unterschreitung bestimmter Abstände die Auflösung zu ändern, könnte sinnvoll sein. Ob etwas 4m oder 2.5m entfernt ist dürfte nicht so wichtig sein, aber schon, ob etwas - im Bereich bis 1m - 2cm, 5cm oder 10cm entfernt ist.

MfG
:Weihnacht

Vielleicht hilft hier eine Simulation?

Simulation ist schwierig, weil man ja die Abweichungen und Ungenauigkeiten simulieren müsste, von denen man eben nicht weiß, wie sie sich auswirken.

Ich denke nicht, dass größere Entfernungen vernachlässigbar sind. Wenn das Teil mitten im Raum steht, muss es doch auch wissen, wo es ist. Die Rastermethode fällt aus, wenn der Speicher knapp ist. Dann würde ich eher die Positionen der Mauern und Objekte speichern. Die Logik wird aber dann sicher nicht einfacher.

Zitat:

Wenn das Teil mitten im Raum steht, muss es doch auch wissen, wo es ist.

Ich denke, das muss nicht zwangsweise so sein. Es würde genügen, den Pfad von dort aus, zu einem Ziel, verfolgen zu können, den es gelernt hat. Aus den gespeicherten Pfadinformationen könnte man eine Skizze der Räume (um den Pfad herum) erstellen und so könnte auch eine Positionsbestimmung möglich sein, wo auf dem Pfad sich das Teil befindet. Wenn zwei Punkte existieren, zwischen denen der Pfad liegt, dann wäre nur der Pfad bekannt und rückschließend die Position auf dem Pfad. Bildlich betrachtet würde das auf einer Karte keinen ganzen Raum ergeben, sondern ein Art Schlauch. Würde der Roboter den ganzen Raum abfahren müssen (z. Saugen) könnte man mehr Informationen für eine Karte erhalten, aus der dann auch die Räume erkennbar sein müssten. Würde ich aber einfach einen Raum von außen nach innen spiralförmig abfahren, bräuchte es wohl auch keine Karte zur Navigation.

:Weihnacht

Zitat:

Zitat von Gnom67

Simulation ist schwierig, weil man ja die Abweichungen und Ungenauigkeiten simulieren müsste, von denen man eben nicht weiß, wie sie sich auswirken.

https://www.roboternetz.de/community...e92#post648519

Deutlich einfacher, als mit den Unwägbarkeiten einer neugebauten Plattform auf Akkubetrieb im Originaltempo irgendetwas zustande bekommen zu wollen.

Ich muss korrigieren:

Die Position im Pfad ist immer bekannt, da der Pfad abgefahren wird.

@Holomino

Zitat:

https://www.roboternetz.de/community...e92#post648519

was ist dort jetzt einfacher?

PS: Ich sollte noch anmerken, dass mich auch das Fahren nach Gelerntem interessiert. Schön ist, wenn es auf einem nodeMCU ausgeführt wird, dass man auch die Möglichkeit hat, die entstandenen Daten zu exportieren, um sie zu analysieren. Bislang mache ich so etwas nur, in einer einfacheren Version, mit einem ATmega328P, ohne die Daten einsehen zu können.

MfG
:Weihnacht

Zitat:

Zitat von Moppi

was ist dort jetzt einfacher?

Den Zusammenhang zwischen
- Sensorfehler
- Sensorreichweite
- Anzahl der Sensoren (Winkelauflösung)
- Odometriefehlern
- Geschwindigkeit des Fahrzeuges
- Auflösung der Karte
- Dynamik der Umgebung

zu testen und zu begreifen.
Wenn Du schon in der Simulation keine stabile Navigation hinbekommst, dann brauchst Du es auch nicht zu bauen.

Ich weiß nicht, was Du da hast. Ich sehe wohl ein Bild.
Aber ich finde es schon erstaunlich, dass Du das alles testen kannst! Was für ein Programm ist das?
Was für einen Programmcode gibst Du dort ein? Du müsstest ja den gesamten Ablauf simulieren können!? Oder kannst Du Dir eine Methodik aussuchen, die Du testest und baust es dann per Programm nach?

Zitat:

Wenn Du schon in der Simulation keine stabile Navigation hinbekommst, dann brauchst Du es auch nicht zu bauen.

Gibt es nicht so viel zu bauen. Ich werde die Motoren ansteuern und die Sensoren auslesen. Die Sensoren müssen angebaut werden, das nodeMCU mit der Treiberplatine auf das Chassis montiert werden. Vermutlich muss noch ein ATmega328P bestückt werden, weil ich die Sensoren alle darüber abfragen will, die Daten schicke ich vermutlich wieder per ser. Schnittstelle rüber. Die Kabelverbindungen noch herstellen. Akkus anschließen. DC/DC-Wandler dazwischen schalten - kann ich erstmal alles mit 5V betreiben. Oder ich nehme zunächst einfach die 5V-Powerbank. Das ist dann für mich wohl einfacher, die Zusammenhänge zu testen und zu begreifen.

MfG
:Weihnacht

Das ist ein Applikationsrahmen, in den ich jeweils eine "World" und einen (oder mehrere) "Algorithmen" lade.
Eine World repräsentiert die Interaktion mit der Umwelt, führt also Fahrbefehle aus und gibt Sensorwerte an den Algorithmus weiter. Ein Algorithmus wertet die Sensorinformationen aus und generiert Fahrbefehle.

Die im Link gezeigte SimulationWorld beinhaltet eine (in schwarzen Linien gezeichnete) simulierte 2-D Umgebung bestehend aus einem Grundriss (Outer-Polygon) und einer Liste von einfachen geometischen Formen (Inner-Polygons), mit denen sich Sensorwerte und Kollisionen des Roboters simulieren lassen. Außerdem siehst Du als schwarzen Pacman den Roboter in der Pose, in der der Roboter sich nach seinen Odometriedaten befindet. Als blauen Pacman findest Du die Position, die vom Algorithmus ermittelt wurde. Letztendlich beschränkt sich ein Simulationszyklus auf die Aufgabe, die Pose des Roboters ein kleines Stück in Richtung des vom Algorithmus bestimmten Zielpunktes zu verändern und von dort aus einem Sensorwert zu generieren (also eine Strahl in vorgegebene Richtung abzuschicken und den nächsten Schnittpunkt mit der Umgebung finden). Messfehler in den Sensorwerten lassen sich über die Angabe von z.B. +/-5% durch Random-Variationen in den Strahlenlängen simulieren. Die fehlerhafte Odometrie lässt sich in Drehung und Strecke ähnlich mit Fehlern simulieren.
Der Algorithmus sammelt in diesem Beispiel die Sensorinformationen zu einem vollständigen Rundumscan, und versucht, die wirkliche Pose durch bestmögliches Einpassen des Scans in die bereits vorliegende Map (die Klötzchenfelder) zu bestimmen. Wenn er das nicht hinbekommt, sieht man in der grafischen Darstellung, wie die Map zerfasert.

Neben der SimulationWorld gibt's aber auch noch die RealWorld, die die reale Kommunikation mit der Roboterhardware (seriell über Bluetooth) darstellt und eine FileRecordWorld, mit der sich mitgeschnittene Daten aus der RealWorld offline sequentiell in den Algorithmus laden lassen.

Ich hab das vor urig langer Zeit mal mit VB6 angefangen und irgendwann auf C# transkribiert. Mittlerweile rennt es auch auf nem Raspberry unter Mono, wobei ich die Browser-Schnittstelle über NodeJS nach einem knappen Jahr immer noch nicht fertig habe (ich komm nicht mehr dazu).

Was man manchmal alles so macht - finde ich nicht schlecht!

Ich habe auch mal Programme mit VB geschrieben, war aber glaub noch Version 4. 1995 bis 1997. Man kann mit VB wirklich gut solche Sachen machen. Ich habe dazumal Flughafenkarten in einen Editor geladen, als Bitmap. Dazu ein Algorithmus, um Häuser zu plazieren und zu drehen. Also Häuser für Terminalgebäude etc. So konnte ich also die Größe der Gebäude - nach Kartenvorlage - direkt anpassen und in die richtige Position drehen. Auch die Funkfeuer konnte ich so setzen, da die in den Karten angegeben waren. Auch Baumbewuchs habe ich eintragen können. Nachher sind die Daten exportiert worden, damit Dateien für den MS Flugsimulator erstellt werden konnten. Dafür hatte ich damals eine Software (ich glaub FS Designer hieß die), habe da noch ein wenig drum herum geschrieben, also eine eigene EXE- oder COM-Datei, damit ich den Vorgang automatisch von Anfang bis Ende durchlaufen lassen konnte. Das Original Tool war leider etwas eingeschränkt, ich glaube da waren nur max. 5 oder 10 Häuser möglich paar Landebahnen und Straßen. Bäume habe ich damit selber generiert (zwei Bitmaps im 90 Grad Winkel ineinandergestellt, ich glaube da musste man ein Gebäude als Grundobjekt nehmen und dann die Bitmap auf die Flächen setzen. Je nach Richtungsvektor oder so ähnlich wurden dann nur die Bitmaps dargestellt und die Wände des Gebäudes nicht). Aber der Designer erlaubte das Zusammenführen mehrerer Objektdateien, die man damit generiert hatte. Das habe ich dann ausgenutzt. Aufgrund meiner Erweiterung konnte ich dann also riesige Flächen mit Häusern per Zufallsgenerator bebauen, wie Berlin z.B.. Das war damals noch Seltenheit im MS Flugsimulator. Meist gab es ja nur ein paar Flughafengebäude bzw. mal ein markantes Gebäude in einer Stadt und das war es dann so weit. Bloß leider kann ich die alte VB Version nicht mehr installieren, so dass ich auch auf meine Programme nicht mehr zugreifen kann, die ich damit geschrieben habe.

Von daher weiß ich, was Du geleistet hast und finde das toll!
Schade ist aber, dass Du mit der Browser-Schnittstelle nicht weiter kommst!

MfG
:Weihnacht

PS:

Einmal habe ich Paderborn nachgebaut, das sah dann für den FS Designer z.B. so aus:

Code:

'******************************************************************** ID 1 'Szenerie-ID '******************************************************************** '-------------------------------------------------------------------- 'Szenerie beschreiben '-------------------------------------------------------------------- GEO_AREA "GERMANY" '-------------------------------------------------------------------- 'Ausmaáe der Szenerie '-------------------------------------------------------------------- include "range1.inc" '******************************************************************** 'Flughafen Paderborn-Lippstadt '******************************************************************** ATIS 118.27,80/2,(N51,36,55),(E8,37,2),24,0,0,0, "Paderborn - Lippstadt … Delta ‚ € Š - Altimeter 1021 - † - ‡ Œyou have Delta ... ILS Freq 24 NAV 111.7 ..." '-------------------------------------------------------------------- 'Lande-/Startbahnen definieren '-------------------------------------------------------------------- AREA_TEST (N51,36,55), 'Position n”rdl.Breite (G,M,S) (E08,37,02), 'Position ”stl. L„nge (G,M,S) 25 'Reichweite (max.255) RUNWAY (N51,36,55), 'Position n”rdl.Breite (G,M,S) (E08,37,02), 'Position ”stl. L„nge (G,M,S) 288, 'H”he in Meter 239, 'Anflugkurs der Runway in Grad 7300, 'L„nge in Fuá 160, 'Breite in Fuá 24, 'Nummer der Bahn (1-63) ' 0, 'Buchstabe L =64, R =128, C =192 ' Bahn-Oberfl„che: ' 0, 'graues Muster 1, 'beton hell, m.Punkten ' 2, 'beton dunkel, m.Streifen ' 3, 'grasartig ' Bahn-Markierungen: 1+2+4+8+16+32, 'Seitenlinien '2+ 'Schwellenmarkierungen '4+ 'Landemarkierungen '8+ 'Abstandsmarkierungen (breit) '16+ 'Mittellinie '32, 'Darstellung der Beschriftung ' 64, 'Abstandsmarkierungen (schmal) ' Bahn-Beleuchtung: ' 0, 'keine ' 1, 'an den Seiten ' 4, 'in der Mitte 5, 'an den Seiten und in der Mitte ' Bahn-Beginn: 1, 'Schwellenmarkierung an/aus 1/0 1010, 'Markierung Typ1 an/aus 1010/0 0, 'Markierung Typ2 an/aus 1010/0 ' 2, 'Anflugbefeuerung MALSR ' 6, ' " ALSF-1 7, ' " ALSF-2 19, ' " Zahl der Blitzlichter ' Bahn-Ende: 1, 'Schwellenmarkierung an/aus 1/0 1010, 'Markierung Typ1 an/aus 1010/0 0, 'Markierung Typ2 an/aus 1010/0 ' 2, 'Anflugbefeuerung MALSR 6, ' " ALSF-1 ' 7, ' " ALSF-2 11, ' " Zahl der Blitzlichter 'Sichtflug-Gleitwinkelanzeigesystem 1: ' 0, 'kein ' 1, '2 Balken 2, '3 Balken 3, 'Winkel der Balken in Grad 'Sichtflug-Gleitwinkelanzeigesystem 2: ' 0, 'kein 1, '2 Balken ' 2, '3 Balken 3 'Winkel der Balken in Grad '-------------------------------------------------------------------- 'Navigationshilfen '-------------------------------------------------------------------- 'include "navtest.inc" NDB 354.0, 'Frequenz 30000, 'Reichweite in Meter /2048 (N51,36,55), 'Position n”rdl.Breite (G,M,S) (E8, 38,25), 'Position ”stl. L„nge (G,M,S) 288, 'H”he in Meter "PAD", 'Kennung (max.5) "Paderborn-Lippstadt" 'Name (max.24) '-------------------------- VOR 108.5, 'Frequenz 120000, 'Reichweite in Meter 0.1, 'magnetische Abweichung in Grad (N51,36,55), 'Position n”rdl.Breite (G,M,S) (E8, 38,25), 'Position ”stl. L„nge (G,M,S) 288, 'H”he in Meter "PAD", 'Kennung (max.5) "Paderborn-Lippstadt", 'Name (max.24) 1 'DME vorhanden '-------------------------- ILS 111.7, 'Frequenz 50000, 'Reichweite in Meter 0, 'magnetische Abweichung in Grad (N51,36,37.8764), 'Position n”rdl.Breite (G,M,S) (E08,36,16.2401), 'Position ”stl. L„nge (G,M,S) 288, 'H”he in Meter "PAD", 'Kennung (max.5) "Paderborn-Lippstadt", 'Name (max.24) 1+64+128, 'DME + Gleitwegsender + Empfindlichkeit 239, 'Anflugkurs in Grad 'Gleitwegsender: (N51,37,04.0557), 'Position n”rdl.Breite (G,M,S) (E08,37,26.3361), 'Position ”stl. L„nge (G,M,S) 288, 'H”he in Meter 3 'Winkel in Grad ' (N51,36,50.7359), 'Position n”rdl.Breite (G,M,S) ' (E08,36,50.7462), 'Position ”stl. L„nge (G,M,S) '-------------------------- INNER_MARKER (N51,37,13.3965), 'Position n”rdl.Breite (G,M,S) (E08,37,51.0021), 'Position ”stl. L„nge (G,M,S) 288 'H”he in Meter MIDDLE_MARKER (N51,38,32.2371), 'Position n”rdl.Breite (G,M,S) (E08,41,22.4972), 'Position ”stl. L„nge (G,M,S) 288 'H”he in Meter OUTER_MARKER (N51,40,22.8508), 'Position n”rdl.Breite (G,M,S) (E08,46,18.7887), 'Position ”stl. L„nge (G,M,S) 288 'H”he in Meter '-------------------------- '-------------------------------------------------------------------- 'Bodenfl„chen '-------------------------------------------------------------------- include "betflae.inc" '-------------------------------------------------------------------- 'Taxi Ways '-------------------------------------------------------------------- include "txwayss.inc" '-------------------------------------------------------------------- 'Airport definieren '-------------------------------------------------------------------- $f3os=$RefPointSecH/100000 $f3ns=$RefPointSecV/100000 $f3og=$f3os/60/60/100*100 $f3og=$f3og-0.5 $f3og=$f3og/1000*1000 $f3ng=$f3ns/60/60/100*100 $f3ng=$f3ng-0.5 $f3ng=$f3ng/1000*1000 $f4=$f3og*60*60 $f3os=$f3os-$f4 $f4=$f3ng*60*60 $f3ns=$f3ns-$f4 $f3om=$f3os/60/100*100 $f3om=$f3om-0.5 $f3om=$f3om/1000*1000 $f3nm=$f3ns/60/100*100 $f3nm=$f3nm-0.5 $f3nm=$f3nm/1000*1000 $f4=$f3om*60 $f3os=$f3os-$f4 $f4=$f3nm*60 $f3ns=$f3ns-$f4 AIRPORT (0~$f3ng,$f3nm,3~$f3ns), 'Position n”rdl.Breite (G,M,S) (0~$f3og,$f3om,3~$f3os), 'Position ”stl. L„nge (G,M,S) 288, 'H”he in Meter 239, 'Anflugkurs der Runway in Grad "Paderborn-Lippstadt", 'Name (max.24) 118.27, 'Frequenz COM1 in MHz 168.0 , 'Frequenz NAV1 in MHz 0, 'Azimutkurs NAV1 in Grad 173.0 , 'Frequenz NAV2 in MHz 0 'Azimutkurs NAV2 in Grad '******************************************************************** 'Geb„ude '******************************************************************** $label=-1 $1=-1 include "tower.inc" include "haus01.inc" include "tank1.inc" include "tank2.inc" include "tank3.inc" include "tank4.inc" include "1hangar.inc" include "2hangar.inc" include "baracke.inc" '*********************************************************** END

Zitat:

Zitat von Moppi

Ich muss korrigieren:
Die Position im Pfad ist immer bekannt, da der Pfad abgefahren wird.

Wie kommst du zu der Aussage? Wenn du einen Pfad irgendwie definierst und dann VERSUCHST ihn abzufahren, ist die Position noch lange nicht bekannt. So genau lässt sich gar kein Gerät steuern (ohne irgendeine Referenz), dass es nicht nach mehr oder minder vielen Bewegungen zwischen den Punkten A und B (oder weiteren) zu Abweichungen kommt. Wenn es so einfach wäre, müsstest du ja gar keinen Aufwand machen. Dann würde die Bewegungsanweisung ja völlig reichen. 3m vor, 2m links, 1,5m vor, 2m rechts. Ziel erreicht. Aber so einfach ist es nicht. Es sei denn, du bist damit zufrieden, wenn du dem Roboter alle paar mal eine Korrektur per Hand verpassen musst. Dann bist du der Sensor, der die Referenz erfasst.
Wenn du es schaffst, wenigstens halbwegs in die Zielregion zu kommen oder regelmäßig an einer geeigneten Stelle vorbei zu fahren, kannst du vielleicht diese eine Stelle als Referenz nehmen. Wenn der Roboter an einer Raumecke vorbei kommt, könntest du ihn dort sozusagen kalibrieren. der Pfad soll genau 15 cm von den beiden Wänden der Raumecken entfernt verlaufen.Du misst die Entfernung zu den beiden Wänden und kannst dann die Position so korrigieren, dass der Roboter auf dem Sollpfad liegt. Wenn die Abweichungen sonst nicht erheblich sind, kannst du bei jeder Fahrt an dieser Stelle korrigieren, so dass sich die Abweichungen nicht über viele Fahrten aufsummieren. Das wäre aber ein noch recht wenig flexibles System.

Zitat:

Wie kommst du zu der Aussage?

Es sollten Bewegungsmuster entstehen. Idealer Weise, wenn die Strecke in einem Stück angelernt wird, sollte auch nur ein Bewegungsmuster entstehen. Mit jeder Korrektur oder Änderung durch Anlernen entstehen neue Muster. Theoretisch kann man sich ein ideales Muster vorstellen, das also dem Pfad entspricht, bzw. bei Abarbeitung dem Pfad wiedergibt. Beim Anwenden des Musters ist bekannt, welche Position im Muster abgearbeitet wird. Weil jede Position, im Muster, nicht zufällig gewählt wird, sondern die beruht auf Abhängigkeiten, von Umgebungs- und Bewegungsparametern. Durch Bewegungsmuster lässt sich ein Rückschluss auf die Position im Raum ziehen, weil alle Bewegungen einen Bezug zum Raum haben.

Beispiel: Wenn ich ein Bewegungsmuster mit "drei Schritten" nach vorn trainiere und dieses Muster abarbeite, befinde ich mich am Anfang der Bewegung auf Position 0 und am Ende der Bewegung auf Position 3. Die Distanz wir durch "Schritt" definiert. Damit steht eine Position fest, auch wenn sie nur relativ angegeben werden kann und nicht genau ist. Wenn ich morgens aufwache und gehe in die Küche, kenne ich meine genaue Position im Raum (nach Koordinaten) auch nicht.
Abweichungen spielen keine große Rolle. Schlimmstenfalls führt es zur Desorientierung, ich habe mich dann verirrt.

Zitat:

Das wäre aber ein noch recht wenig flexibles System.

Was soll das System tun? Zielsetzung ist, von Punkt zu Punkt zu fahren, wobei dem Roboter der Weg gezeigt wird.

Ist beim Mensch genauso so. Entweder ich habe einen Plan, dann gehe ich nach dem von einem Raum zum andern, zielgerichtet. Oder ich folge einer anderen Person. Oder ich folge einer Wegbeschreibung. Habe ich vom Wohnzimmer aus dann die Toilette gefunden, kenne ich den Weg. Damit bin ich aber auch nur so flexibel, dass ich den Weg zur Toilette finde und zurück. Das Auffinden der übrigen Räume müsste ich erst noch lernen.

Nachtrag:

Das Verfahren könnte an der Menge benötigten Speichers, bzw. an der Verarbeitungsgeschwindigkeit, die mit der Datenmenge zunimmt, scheitern. Die Flexibilität ergibt sich aus der Menge gespeicherter Daten und deren Verarbeitung. Das bedeutet, zunächst ausprobieren und die einzelnen Eingabeparameter auf das Nötigste relativieren. Dann könnte ich die anfallende Datenmenge abschätzen. Durch Priorisieren der Eingabeparameter kann die weiter gering gehalten werden, dadurch steigt die Ausführungssicherheit; aber es sinkt die Flexibilität bezüglich der situativen Wiedererkennung (Ähnlichkeit).
Daher kann ich nur hoffen, dass 3MB Speicher und 80MHz eines nodeMCU, genügen. Nach meinen bisherigen Schätzungen könnte das knapp werden. Aber gut, letztens war ich beim Zahnarzt und musste mich etwas festlegen, wann ich da sein werde und ich habe dann - unter Vorbehalt einiger Minuten Abweichung - eine Zeit genannt; als ich dann angekommen war, hat sich gezeigt, dass das sehr sehr knapp war (was ich aber auch vorher aus dem Bauch heraus wusste), da ich praktisch auf die Minute da war (ca. 60s bis 80s früher).

MfG
:Weihnacht

Ich kann deinen Ausführungen nur schwer folgen. Wenn du morgens aufstehst, gehst du doch nicht drei Schritte vor und dann drei Schritte links, sondern du benutzt deine Sensoren (Augen), um zu navigieren. Der Pfad und das Schrittmuster alleine genügt dir nicht. Mit jeder kleinen Abweichung kommst du weiter vom Pfad ab und am Ende rennst du gegen einen Türpfosten. Und jetzt sag nicht: "Dafür hab ich ja die Ultraschallsensoren." Das ist nämlich das, was ich die ganze Zeit sage. Du hast gesagt: "Die Position im Pfad ist immer bekannt, da der Pfad abgefahren wird."

Ich klink mich hier aus - das führt alles zu nichts.

Hallo Gnom67!

Zitat:

Ich kann deinen Ausführungen nur schwer folgen. Wenn du morgens aufstehst, gehst du doch nicht drei Schritte vor und dann drei Schritte links, sondern du benutzt deine Sensoren (Augen), um zu navigieren.

Das ist nur bedingt richtig. Vieles machen wir automatisch, weil wir es jeden Tag wieder tun, immer gleich oder ähnlich. Das kann auch dazu führen, dass ich als Mensch erst das Muster abspule und dann Sensordaten auswerte. Wenn das dann hinterher nicht zusammenpasst, kann es sein, dass ich z.B. ausrutsche - das nennt man dann Unfall.

Zitat:

Und jetzt sag nicht: "Dafür hab ich ja die Ultraschallsensoren." Das ist nämlich das, was ich die ganze Zeit sage. Du hast gesagt: "Die Position im Pfad ist immer bekannt, da der Pfad abgefahren wird."

Beides gehört zusammen. Aufgrund der Sensordaten kann mit einer Wahrscheinlichkeit sagen, was als nächstes passieren muss, das ist in den Daten gespeichert. Als Grundregel würde ich hier nennen: suche den passendsten, nächsten Schritt. Sollte es zu Problemen kommen, können die Sensoren in ihrer Gewichtung der Priorität nachjustiert werden. Im ungünstigsten Fall muss die Auflösung der Sensordaten erhöht werden; ungünstig deshalb, weil dann mehr Lernphasen notwendig sind und damit die Datenmenge und die Ausführungszeit, zur Entscheidungsfindung, zunimmt.

Zitat:

Mit jeder kleinen Abweichung kommst du weiter vom Pfad ab und am Ende rennst du gegen einen Türpfosten.

Das ist richtig. Du hast schon eine mögliche Lösung vorgestellt. So was in der Richtung muss es natürlich geben. Weil ich es mit zwei Motoren zu tun habe, die die Richtung bestimmen. Im Grunde ein Linienfolger-Mechanismus, der sich nur nicht an einer Linie auf dem Boden orientiert (die zwischen zwei Sensoren verläuft), sondern an außerhalb liegenden Merkmalen, per Ultraschall (hier wieder sehr ähnlich zu dem Mechanismus, an einer Wand lang zu fahren). Ich werde also zwei Dinge brauchen. Die Wegfindung per erlernten Daten, wobei sich der Roboter - stark vereinfacht - von Datum zu Datum bewegt und die Richtungskorrektur. Die Richtungskorrektur könnte man vielleicht für den Roboter selbst erlernbar machen, weil aufgrund der Sensordaten irgendwann klar ist, dass er kollidiert (in einem intelligenteren Szenario der Steuerung könnte man auch sagen: vom Weg abweicht).

Zitat:

Ich klink mich hier aus - das führt alles zu nichts.

Trotzdem herzlichen Dank, für Deine Anregungen, bezüglich der Probleme! Damit hast Du schon sehr weitergeholfen.
Was Du geschrieben hast, lese ich mir, zu gegebener Zeit, auch nochmal durch. Ich lese hier oft Sachen doppelt und dreifach. Manchmal verbergen sich Hinweise, die man beim ersten Lesen übersehen hat.

MfG
:Weihnacht

- - - Aktualisiert - - -

Natürlich auch besten Dank, an alle, die sich bisher beteiligt haben! =D> ("Applaus")

- - - Aktualisiert - - -

Ich gebe dem Ding (meinem Verfahren) jetzt erst einmal einen Namen, bis ich ein Verfahren irgendwo finde, dass genau dieses beschreibt: implicitly learned path navigation, kurz ILPN
Es kann natürlich auch sein, dass es in bisher verwendeten Verfahren versteckt ist, die mit "Landmarken" funktionieren.

Und eine Beschreibung:

Bezeichnet ein Verfahren, nach dem Roboter einem Weg folgen lernen, ohne dass sie sich dessen bewusst sind, wie dies genau geschieht oder dass der Weg berechnet würde. Hierfür wird keine Karte benötigt, sondern die auf dem Weg erfassten Informationen (Sensordaten) werden gespeichert; es werden zusätzlich Daten gespeichert, die einen Schluss auf vorherige Schritte und folgende Schritte zulassen und eine Verbindung herstellen. Der Weg wird auch auch als "Pfad" oder engl. "path" bezeichnet. Aus den impliziten Daten können explizite Daten gewonnen werden, so dass daraus auch eine mehr oder weniger scharfe Skizze der Umgebung erstellt werden kann. ILPN funktioniert nicht aufgrund absoluter Positionen (wie Koordinaten), sondern stellt eine relative Navigation, basierend auf erlerntem Wissen dar.

Nachtrag:

In einer ganz einfachen Variante habe ich so ein Verfahren, im Ansatz, bereits am 26.12.2018, 18:52 hier in meinem Blog veröffentlicht: https://www.roboternetz.de/community...eb-3-Quelltext
Zum besseren Verständnis kann dort der gesamte Quelltext eingesehen werden, wie er damals existierte.

----------------------------------------------------------------------------
Der Vollständigkeit halber habe ich nochmals gesucht, nachdem mir einige Dinge klarer geworden sind. Das Stichwort Landmarken ist ja schon gefallen. Dazu gibt es auch zig Quellen, am Ende dieses Dokumentes, die sich dann wohl allesamt mit Details der Navigation, basierend auf Karten und Marken, befassen: Unifying Map and Landmark Based Representations for Visual Navigation

Zitat:

Zitat von stochri

Wenn Du ein wenig Geld ausgeben willst, kannst Du es mit UWB-Baken
versuchen

Der Link für die Auswertung funktioniert nicht mehr. Ich habe bisher nichts gefunden. Die Arduino-Bibliothek schon. Bloß, ich muss mir das erst mal bildlich vorstellen können. Dafür frage ich mich gerade, welche Daten man von so einer Bake bekommt.

In einem Video habe ich gerade gesehen, dass man da offenbar die Entfernung und die Signalstärke bekommt. Mehr muss ich erst mal nicht wissen.

MfG