meint ihr nicht ein microcontroller wie tennsy 4.1 kann die daten nicht verarbeiten vom slam?
meint ihr nicht ein microcontroller wie tennsy 4.1 kann die daten nicht verarbeiten vom slam?
das leben ist hart, aber wir müssen da durch.
Doch sicher - irgendwie. Cruise Missiles flogen letztes Jahrtausend schon autark mit 'nem 300MHz-System.Zitat von morob
Allerdings frage ich mich, warum so eng auslegen, wenn ich fürs halbe Geld einen nominal doppelt so leistungsfähigen Rechner bekomme (z.B. BPI M2 Zero).
ein microcontroller hat mehrere vorteile gegenüber eine rechner
stromverbrauch, echtzeitfähigkeit, ...
es gibt allerdings auch nachteile.
teensy 4.1 ist schon ein ziemliches schlachtschiff.
das leben ist hart, aber wir müssen da durch.
morob:
Mit dem Stromverbrauch gebe ich Dir recht.
Die Echtzeitfähigkeit ist im Verbund mit einem kleineren Controller (ich mache Interruptgeschichten, Regelung, Reflexe … auf einem ATXMega) nicht mehr entscheidend.
Was mich allerdings abschreckt: 1MB RAM ist eine begrenzte Ressource. Bezüglich des Slams kann ich große Umgebungen zwar zwischen RAM und Flash rollen (die Sicht ist ja auf die Sensorreichweite begrenzt). Beim Pathfinder (der braucht ja im Zweifelsfall die gesamte Map, um den Weg von A nach B zu generieren) wird das allerdings kompliziert.
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 (25.06.2020 um 23: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 22:09 Uhr) Grund: PS
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.
denke ich auch, "irgendwie", ich habe es ja (ansatzweise) auch schon mit einem Arduino Due geschafft.
- - - Aktualisiert - - -
Der Punkt ist:
wenn man keine sehr exakte Positionsbestimmungs-Methode hat, dann kann man den Teil mit der Karte vergessen.
Denn der Robot muss ja erst mit seiner genau bestimmbaren Position eine genaue Karte ermitteln, die hinterher, wenn er sich frei im Raum zum Saubermachen bewegt, auch noch als Referenz stimmen muss.
Mit Odometrie, Gyro, Kompass und GPS wird das nichts indoors, da laufen spätestens nach 15 Minuten alle Werte komplett aus dem Ruder.
Daher braucht man exakte externe Navigations-Referenzen (Baken), die per Peilung eine zuverlässige und reproduzierbare Positionsberechnung erlauben.
Ob man dann 1 IR-Sensor drehbar anbringt oder ein halbes Dutzend fest montiert rundrum als Hindernissensoren, ist fast schon reine Geschmackssache.
Allerdings plus Bumper-Stoßstange zusätzlich.
Diesen Satz verstehe ich nicht.
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!
Berechtigungen
Zitieren
Lesezeichen