Grundsätzlich ist aber auch die Frage, was man von seinem "Modell" erwartet, und worauf man bereit ist zu verzichten.
Wenn man bereit ist, dauerhafte Schmutzecken zu akzeptieren, die ständig "vergessen" werden, kann man sicher auch mit sehr einfachen Konsruktionen leben.
Diesen Satz verstehe ich nicht.Zitat von HaWe
Insbesondere unter dem Gesichtspunkt, dass ein käuflicher Staubsauger keine externen Referenzen zur Navigation verwendet und trotzdem funktioniert, verstehe ich ihn nicht!
Neinneinneinnein, ich versteh ihn nicht!
ich denke, (gute) käufliche Geräte arbeiten ganz anders, mit viel komplizierterer Hard- und v.a. Software, als was wir ohne weiteres zur Verfügung haben mit "unseren" Kenntnissen und Methoden.
ich habe z.B. einmal ein pdf gefunden, bei dem die Positions- und Navigations-Berechnungen über 2 komplett unabhängige extended Kalman Filters aus Odometrie mit 2xRotationssensoren und 9DOF IMU mit völlig unterschiedlichen Filtereinstellungen funktionieren, deren Zustandsraum-Modellierungen abhängig sind vom detektierten Untergrund. (Schon bei 1 Standard-Kalman für 2 Sensoren = 2DOF komme ich an meine Grenzen.)
Auf diese Weise konnte mit erheblichem mathematischen Aufwand auch ohne externe Referenzen eine gute Positionierung und Navigation ermöglicht werden.
zu Extended Kalman Filters s. z.B. https://www.cbcity.de/das-kalman-fil...rklaert-teil-1,
https://www.cbcity.de/das-kalman-fil...rklaert-teil-2;
https://en.wikipedia.org/wiki/Extended_Kalman_filter .
Wer aber jemals für seinen Roboter so einen Kalman selber errichten und optimieren wollte, wird schnell gemerkt haben, dass man dann irgendwann scheitert, wenn man kein Mathematiker ist und auch nicht die exakten kompletten Sensor-Messstatistiken zu allen Einzelsensoren für die mathematisch-statistischen Modelle hat - oder mit großen Messfehlern leben muss.
Im obigen pdf von dir https://kaeni.de/hack-des-xiaomi-mi-...nte-einblicke/ läuft ja auch die lokale Software zusammen mit der Software auf einem Hersteller-Server über HTTPS, da kann man sich vorstellen, was da wohl mathematisch dahintersteckt.
Zum Selbermachen halte ich diesen Weg für aussichtslos, ich zumindest habe es versucht und musste aufgeben.
Der einzig praktikable Weg für Hobby-Bastler ohne Mathematikstudium ist daher IMO eine Navigation über externe Baken.
Geändert von HaWe (25.06.2020 um 19:25 Uhr) Grund: typo
du kannst den ram speicher aufrüstenbei teensy 4.1
das leben ist hart, aber wir müssen da durch.
Frei nach https://www.heise.de/ct/artikel/An-d...ks-290662.html ein ganz einfacher SLAM (ohne Lösung für Closed loop oder kidnapped robot-Problem) für Lidaranwendungen
Eingangsseitig emmitiert die Hardware bei einer Sensormessung Abstandswert, Messwinkel und die aus den Odometriedaten ermittelte Pose des Roboters (X/Y/Orientation). Messungen werden auf dem Rechner bis zur vollständigen Umdrehung der Sensorplattform gesammelt und als ScanPackage an den SLAM-Algorithmus versendet (Es kommen also "viele" Messungen als Rundumblick gleichzeitig an).
Aufgabe 1: Der erste Scan wird anhand der subjektiven Roboterpose eingetragen (siehe obiger Artikel). Die Pose der letzten Messung im ScanPackage wird gepuffert. Eine zweite Pose (AlgPose) wird auf die Werte der subjektiven Pose initialisiert.
Aufgabe 2: Neues ScanPackage, neue letzte subjektive Pose. Bilde ein PoseChange (dx/dy, Blickwinkeländerung)
Aufgabe 3: Nimm einen Zufallsgenerator und variiere die drei Bestandteile von PoseChange um z.B. +/-20%. Bei 100 Variationen bekommst Du 100 leicht unterschiedliche PoseChanges zurück.
Aufgabe 4: Schlage jede generierte Variation von PoseChange einmal auf AlgPose auf und teste, wie die Sensorwerte in die bisherige Map passen (Test gibt einen Gewichtungswert (Anzahl der passenden Punkte frei-frei und besetzt-besetzt/Anzahl aller Punkte des Scans) für die Variation zurück)
Aufgabe 5: Trage die Sensorwerte der Variation mit dem größten Gewicht in Deine Map ein und schlage den dazugehörigen PoseChange auf die AlgPose auf.
That's it
Ohne Studium machbar, vielleicht etwas unbequem die Transformationen der Posen und Linien, aber auch nur Mittelstufenmathe.
Neben dem Raster und der Anzahl der Variationen darf man sicher noch den Test/Update verfeinern (z.B. messdistanzabhängige Fehler in der Gewichtung berücksichtigen und so eine Varianz um den gemessenen Punkt einführen). Auch kann man vielleicht mal am Zufallsgenerator spielen.
Sicher eine Menge Holz: Das testen von beispielsweise 100 Linien mit sagen wir durchschnittlich 30 Rasterpunkten in vielleicht 100 Variationen durch den Bresenham sind halt 300000 Rasterpunkte und Vergleiche zur Bearbeitung eines Scan-Paketes. Bei einem RPLidar mit 5 U/s und 360 Messungen/U wird das noch enger. Aber man muss ja nicht alle Messwerte im SLAM berücksichtigen. Für einen schneckigen Staubsauger erst recht nicht.
Code:public double Test(Pose pose, LidarScanData scan) { int mulSum = 0; int pointSum = 0; //Create absolute points from pose and scan data List<Line> transformed = TransformScanToPoints(scan, pose); //for each scan line foreach (Line ln in transformed) { if (ln != null) { int x0 = (int)Math.Round(ln.P1.X / Raster); int y0 = (int)Math.Round(ln.P1.Y / Raster); int x1 = (int)Math.Round(ln.P2.X / Raster); int y1 = (int)Math.Round(ln.P2.Y / Raster); int dx = Math.Abs(x1 - x0), sx = x0 < x1 ? 1 : -1; int dy = Math.Abs(y1 - y0), sy = y0 < y1 ? 1 : -1; int err = (dx > dy ? dx : -dy) / 2, e2; //rastering (Bresenham's line algorithm) for (; ; ) { int mul = (x0 == x1 && y0 == y1) ? this[x0, y0] : -this[x0, y0]; if (mul > 0) mulSum++; pointSum++; if (x0 == x1 && y0 == y1) break; e2 = err; if (e2 > -dx) { err -= dy; x0 += sx; } if (e2 < dy) { err += dx; y0 += sy; } } } } return (double)mulSum / (double)pointSum; } public List<Line> Add(Pose pose, LidarScanData scan) { //Create absolute points from pose and scan data List<Line> transformed = TransformScanToPoints(scan, pose); //for each scan line foreach (Line ln in transformed) { if (ln != null) { int x0 = (int)Math.Round(ln.P1.X / Raster); int y0 = (int)Math.Round(ln.P1.Y / Raster); int x1 = (int)Math.Round(ln.P2.X / Raster); int y1 = (int)Math.Round(ln.P2.Y / Raster); int dx = Math.Abs(x1 - x0), sx = x0 < x1 ? 1 : -1; int dy = Math.Abs(y1 - y0), sy = y0 < y1 ? 1 : -1; int err = (dx > dy ? dx : -dy) / 2, e2; for (; ; ) { //setPixel(x0, y0); this[x0, y0] = (SByte)Math.Max((int)this[x0, y0] - 1, -128); if (x0 == x1 && y0 == y1) { this[x0, y0] = (SByte)Math.Min((int)this[x0, y0] + 5, 127); break; } e2 = err; if (e2 > -dx) { err -= dy; x0 += sx; } if (e2 < dy) { err += dx; y0 += sy; } } } } return transformed; }
Geändert von Holomino (26.06.2020 um 00:53 Uhr) Grund: A1 Korrektur Init der ALgPose
das Problem ist, dass die Odometriedaten wegen Räder-Schlupf und Drift nicht zuverlässig genug sind, um die aktuellen Positionen zu ermitteln. Man kann u.U. noch nicht einmal öfters hintereinander exakte 90° Winkel fahren bei Teppichen, mit Teppichkanten, und wechselweise 1 Rad auch teilw. auf glattem Steinboden. Auch das Heading (Fahrtrichtung) lässt sich mit Gyro+Kompass indoors nicht sicher bestimmen (Kompass hat Fehlweisungen indoors durch metallische Störquellen, und der Gyro hat unvorhersehbare Drift in eine Richtung).
Daher kommt man mit dem obigen Beispiel nicht weit, das war ziemlich exakt genau das, bis wohin ich auch gekommen bin: nach ein paar Minuten steht der Robot irgendwo, aber nicht dort, wo er es berechnet hat, und in jede Richtung ausgerichtet, außer in die, in die er stehen soll. Die "Karte" entspricht also eher einer Phantasie gemalt von einem 3-jährigen als dem tatsächlichen Raum.
Folglich braucht man entweder super-getunete extended-Kalmanfilter oder externe Baken mit dm-Wellen für die Navigation.
(PS, Übrigens wird wschl Arduino C++ Code benötigt, aber das nur nebenbei)
Geändert von HaWe (25.06.2020 um 23:09 Uhr) Grund: PS
Was Du denkst, interessiert mich nicht.
Was mich aber interessiert, sind Leute wie Moppi oder Morob, die fragend oder prüfend einen Blick auf die Sache werfen. Und ich gehe jetzt einmal als im Eingangspost erwähnte Person davon aus, dass die bislang von mir eingestellten "Kinderkritzeleien" genug Neugier erweckt haben, dass es sich auch lohnt, Rückfragen zu beantworten.
Und denen gegenüber ist an Deinen Äußerungen aus meiner Sicht eine Menge Korrekturarbeit zu leisten.
Geändert von Holomino (26.06.2020 um 02:59 Uhr)
Irgendwie muss man einen Roboter zielgerichtet steuern. Ich bin noch nicht sicher, welcher Ansatz, der mir einfällt, dabei vielleicht auch nicht zuende gedacht ist. Da mangelt es an Erfahrung. Das Erstellen von Karten ist eine naheliegende Sache, auf die man von selbst auch immer wieder mal kommt. Interessant ist vor allem, wenn schon jemand mit selbst erstellten Karten gearbeitet hat, weil der weiß, ob sich der Aufwand lohnt. Es besteht auch die Möglichkeit, das so jemand sagt: ist alles gut und schön, aber im Grunde kann man das, was ich an Nutzen darin sehe, einfach auch mit anderen Algorithmen lösen, wie dass ein Roboter in der Wohnung zuverlässig von A nach B fährt. An anderer Stelle hatte ich schon beschrieben, wie ich mir so etwas auch vorstellen kann.
Wie geht denn SLAM mit sich ortsveränderlichen Objekten um, wie Haustieren, oder Schuhe, Spielzeug, die in der Wohnung zufällig herumstehen und von einer Minute auf die andere verschwinden und an anderer Stelle auftauchen können? Deshalb ist es doch wichtig, dass ein Roboter solche Objekte erkennen und umfahren kann, auch dass ein Roboter damit rechnen muss, dass die Objekte kurze Zeit später verschwunden sind. Wenn diese Aufgabe gelöst ist und zum Beispiel ein Algorithmus eingesetzt wird, der Räume Bahn um Bahn abfährt (um mal beim Staubsauger zu bleiben) und wenn der Roboter in der Lage ist, einzelne Räume auch ohne richtige Karte zu finden, eben zum Beispiel immer an der Außenwand lang fährt, braucht es dann SLAM, wie in Wikipedia beschrieben? Was ist denn an SLAM offenbar und macht es damit unabdingbar?
MfG
PS: ich finde das mit den Bildern von Holomino eine gute und brauchbare Sache, weil man daraus auch sicher Dinge ablesen kann, wenn man sich selbst näher damit beschäftigt.
In welcher Sprache ein Code verfasst ist, ist für Beschreibungszwecke nicht so wichtig. Solang es ein Code für irgendeine Hochsprache bzw. irgendein "Basic" ist, kann man dann schon sehen, was im Code passiert. So Sachen wie "foreach" kann man nochmal nachschlagen.
Geändert von Moppi (26.06.2020 um 07:09 Uhr)
oh je, hier ist ja zuviel passiert gestern...ich muss zugeben ich hab das nicht gelesen und beziehe mich direkt auf den Vorposter:
Ich verwende ja ROS, was auch gerne von den Forschungsstätten verwendet wird und damit nicht grundsätzlich alles falsch macht. Staubsaugerroboter wie der Neato sollen angeblich auch ROS als Unterbau verwenden. Bei ROS gibt es im Navigation-Stack die lokale und die globale Karte. Die globale ist die per SLAM erstellte Karte, die lokale Karte ist was der Roboter aktuell sieht, z.B. ein Feld von 3x3m. Deine ortsveränderliche Objekte sind für die Lokalisierung in der globalen Karte kein Problem, da hier eh nur mit Wahrscheinlichkeiten gearbeitet wird und die Sensorwerte sowieso zu ungenau sind um eine 100% Überlappung zu erreichen. Zum Umfahren dieser Objekte wird die lokale Karte verwendet. Auf der globalen Karte wird erstmal nur der "grobe Weg" mit A* oder ähnlichem errechnet. Anhand dieses Weges wird dann auf der lokalen Karte kontinuierlich mit den aktuellen Sensorwerten und komplizierteren Wegfindungen neu geplant.
Geändert von Defiant (26.06.2020 um 13:20 Uhr)
@Holomino
Ich bezog mich auf die "Karten", bis wohin ich eben selber gekommen bin, die also MEINE Versuche ergeben haben.
Deine Grafiken kannte ich nicht, sie waren hier auch nirgends verlinkt, sie sehen aber vergleichsweise -zig mal besser aus: Ich habe per Odometrie niemals auch nur annähernd rechte Winkel in den Karten an den Wandecken erhalten. Schon beim schräg überfahren einer Teppichkante kam es zu etlichen Grad Kursabweichung, die die Odometrie überhaupt nicht bemerkt hat, auch kam es zu Schlupf unter den Reifen beim Anfahren und Wenden, und das war dann absolut nicht praxistauglich - spätestens beim mehrmaligen Überfahren und Manövrieren nach 15 oder 30 Minuten.
Da ich andere zuverlässigere Odometrie- oder Navigationsverfahren (deine?) nicht kenne, und auch "mein" Kalman bei dem driftenden Gyro und abgelenktem Kompass zusammen mit der Odometrie nicht zu stabilisieren war, habe ich für mich entschieden: nie mehr ohne dm-Wellen-Baken, falls ich nochmal damit anfangen sollte.
Berechtigungen
Zitieren
Lesezeichen