Liste der Anhänge anzeigen (Anzahl: 1)
Flaschenhals im Slam?
Hallihallo,
folgende Grafik zeigt die von meinem aktuellen Robbiprojekt erzeugte Karte meines Kellers. Als Linien schwarz eingezeichnet der über Raddecoder gemessene Kurs, blau der korrigierte Kurs.
Start ist mittig links, danach einmal durch den unteren Bereich, dann nach oben durch die Waschküche (der große Raum oben), anschließend wieder zurück zum Ausgangspunkt.
Die Kurskorrekturen habe ich aus den Rundumscan-Daten erzeugt, die als Kreuzchen und Linien (über einen Algorithmus gebildet) die Konturen der Hindernisse grob abbilden. Dabei habe ich erst einmal nur die von der aktuellen Position gemessenen Hindernislinien mit den in der Karte bereits vorhandenen Linien verglichen.
Anhang 30064
Mit einem Pfeil rot gekennzeichnet mein Problem: Der zweimal durchfahrene "Flaschenhals", der als Bindeglied die Waschküche mit dem Rest verbindet und dessen Messungen (wie bei allen Messungen) Fehler aufweisen, die eine Winkelverschiebung der beiden Kartenteile relativ zueinander bewirken (Die Waschküche steht zum Rest des Flurs unten etwas schräg und NEIN, DER MAURER HAT NICHT GETRUNKEN).
Jetzt also meine Frage: Kann man das irgendwie kompensieren? Wie macht ein offizieller SLAM-Algorithmus das? Oder treten bei der Verwendung von SLAM beim Durchfahren solcher Flaschenhälse die gleichen Winkelfehler von Kartenteilen zueinander auf?
Mir fallen für dieses Problem eigentlich nur zwei Lösungen ein:
- die Pfuschlösung: GEHE VON RECHTWINKELIGEN UMRISSEN AUS UND KORRIGIERE DIE LAGE DER HINDERNISSE UND DER POSITION ENTSPRECHEND.
- Die Messlösung: verbessere die Flaschenhalsmessung durch wiederholte Messungen und Mittelwertbildung. Dann aber das Folgeproblem: woher weiß der Robbi, wo ein Flaschenhals liegt?
Fällt Euch da etwa Besseres ein?
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo Damfino,
"Wie oft wurde der Keller abgefahren? Kann mir vorstellen dass das mit nur 1 Durchgang nicht genau wird. SLAM sollte bei jedem Durchgang die Positionen der Hindernisse vermessen und die Karte korrgieren bzw erweitern."
Das Problem ist, dass meiner Ansicht nach der SLAM-Algorithmus den Flaschenhalsfehler nicht systematisch angehen kann, wenn der Bezug zwischen zwei Kartenteilen auf zu geringen Datenmengen basiert (z.B. nur ein Türdurchgang, der zwei größere Kartenteile miteinander verbindet).
Startpunkt: Dort sollte doch schwarze und blaue Linie identisch starten, oder sehe ich das nicht?
Schlecht zu erkennen, Die blaue Linie überlagert hier die schwarze.
Ist beim Flaschenhals ein Hinderniss (Rohre, andere Oberfläche) das die Messung verfälscht?
Es ist eigentlich der Übergang zwischen Kellerflur und Waschküche, in dem ich "GUTE BEZUGSPUNKTE" verliere.
Wie schaut der Roboter aus, wie ist der Messaufbau?
Odometrie ok
Kompass?
Radar?
Zwei Motoren mit Inkrementalgebern (2,1mm Schrittauflösung, 40 cm Radabstand), geregelter Beschleunigungs-/Bremsrampe sowie angenäherte Berücksichtigung der Regelungsabweichungen in den Odometriedaten geben eine schon "gute" Annäherung (Im Beispielbild oben bin ich ca. 40m Strecke gefahren).
Weniger gut sind die Daten des Rundumsensors (128 Scans/ 360°), basierend auf zwei Sharp-Distanzsensoren (20..150cm, 100..550cm fusioniert). Die haben einerseits erhebliche Messfehler auf größere Distanz, andererseits beinhalten sie auch so einige zu filternde Fehlmessungen an reflektierenden Flächen (jo, ich war auch überrascht, dass eine grau gestrichene Metalltür ein reflektierendes Objekt ist)
Kompass habe ich nicht, weil ich keinen Weg gefunden habe, Fehler durch elektromagnetische Felder (Waschmaschinenmotor, Heizung, Metall, Leitungen,...) auszuschließen.
Ich reduziere das Problem noch mal aufs Wesentliche:
Wenn ich aus einem sehr großen Raum (Bezugspunkte durch Lidar o.Ä. nur an einer Wand messbar) durch einen Türdurchgang in einen zweiten sehr großen Raum fahre, wird die Lage beim durchqueren des Türdurchganges alleine an den Türflanken festgemacht (2 kurze Linien). Wenn jetzt diese beiden Linien auch nur ein wenig falsch in die Map eingetragen werden (Winkelfehler <1°), ergibt dies für absolute Positionen im zweiten Raum später doch einen relativ großen Fehler.
Anhang 30067
Die Grafik zeigt meinen Flaschenhals: Ausgehend von A hat der Robbi gute Bezugsmessungen (schwarze Linie) bis B
Bei B sind die vorhergehenden Bezugspunkte mit Ausnahme der beiden kurzen grünen Linien nicht mehr verwendbar. Sind diese beiden Linien nur etwas ungenau, liegen alle folgenden Messungen (blaue Linie) und die eingetragene Position um den Winkelfehler aus der Messung von B falsch.
Die Erkennung des Fehlers und dessen Korrektur kann frühestens an C erfolgen. Entweder orientiert sich der Algorithmus nun an den Matches der Messungen zwischen A und B, trägt neue Punkte sozusagen als 0-Wandstärke ein und korrigiert die Position entsprechend oder, wenn es ein Linienalgorithmus ist, kann die Syntax maximal sagen: "Oh, hier liegen zwei gegengerichtete Linien übereinander, das ist nicht plausibel"
Ein auf MonteCarlo basierender SLAM-Algorithmus KÖNNTE die richtige Lage des Türdurchganges als Partikel für einen gewissen Zeitraum beinhalten. Allerdings ist die Wahrscheinlichkeit, dass genau dieser Partikel durch höher gewichtete Alternativen vernichtet wird, genauso groß, wie der Erhalt der richtigen Alternative. Aus praktischen Gründen entwirft ein solcher Algorithmus ja nur eine festgelegte Anzahl von Altenativmaps und ggf. fliegt die richtige Alternative schon aus dem Map-Pool heraus, bevor der Fehler erkennbar wird.
Liste der Anhänge anzeigen (Anzahl: 1)
Und schwupp, bin ich ein Stückchen weiter.
Man nehme...
...einen Sensor mit höherer Reichweite, der beim durchqueren des Flaschenhalses auch die gegenüberliegende Wand zuverlässig misst.
Anhang 30220
Dann wird's besser:p!!!