Archiv verlassen und diese Seite im Standarddesign anzeigen : SLAM für autonomen Roboter nötig?
Hallo,
ich bin nochmal auf das Thema SLAM aufmerksam geworden. Jetzt habe ich gestern einen älteren Thread von Holomino gelesen, wo er auch eine Karte erstellt.
Nun stelle ich mir grundsätzlich die Frage, inwiefern man SLAM überhaupt zur Navigation eines Roboters benötigt.
SLAM beinhaltet immer das Erstellen einer Karte. Das kann sinnvoll sein, wenn ich als Mensch eine Karte von einer Umgebung benötige.
Bezugnehmend auf diese Karte kann ich dann dem Roboter Anweisungen geben, wo er hin fahren soll.
Zur Navigation von einem Startpunkt, zu einem Zielpunkt scheint es mir unnötig, eine Karte zu erstellen. Wenn ich an eine Navigation draussen denke,
wo dann GPS möglich ist, wird man kaum SLAM benutzen. Oder sehe ich das falsch?
Bei den Saugrobotern werden heute teils auch Karten der Wohnung erstellt, die dann irgendwo ins Netz auf einen Server geladen werden, beim Hersteller des Roboters
vermutlich, ich hatte so was beiläufig von Vorwerk gelesen, dass Roboter nicht mehr funktionieren, wenn es Serverprobleme gibt. Wozu wird dort eine Karte der Wohnung erstellt,
wen interessiert der Grundriss der Wohnung? Sicher nicht den, der darin wohnt.
MfG
also für Saugroboter etc. ist es doch klar: um wirklich alle Stellen anzufahren und keine auszulassen - oder tatsächlich ganz bestimmte Bereiche auszusparen, wenn der Robi da grundsätzlich nicht hin- oder durchfahren fahren soll aus irgendwelchen Gründen.
Witzig, ich finde es offensichtlich, dass man eine Karte benötigt. Als Mensch hast du ja auch eine Karte im Kopf wenn du von A nach B fährst. Und die Karte sagt dir, dass du von Hamburg nach Köln nicht über Berlin fährst. Genau das selbe für Roboter:
Wenn es die Aufgabe ist einen effizienten Weg von der Küche zum Wohnzimmer zu finden brauche ich doch eine Karte. Die Alternative solange rumzufahren bis ich zufällig im Wohnzimmer gelandet bin halte ich nicht für praktikabel.
Ja, draußen verwendest du GPS, aber das funktioniert ja nicht innerhalb deiner Wohnung, da 1. Man da kein GPS empfängt und 2. die Genauigkeit nicht hoch genug ist. Deswegen verwendet man drinnen gerne SLAM. Umgekehrt würde man im Auto eher nicht zu SLAM tendieren weil viel zu aufwendig.
Zum Thema Staubsaugerroboter:
1. Eine Odometrie ist immer mit Schlupf behaftet, aber du möchtest gleichzeitig feststellen, dass du jedes Feld einer Karte effizient angefahren hast.
2. Staubsaugerroboter mit Laserscanner fahren ja den sog. boustrophedon path (http://ri.cmu.edu/pub_files/pub1/choset_howie_1997_5/choset_howie_1997_5.pdf) ab. Also wie man als Bauer sein Feld pflügen würde. Es wäre allerdings deutlich schwieriger diesen Weg effizient zu planen wenn man keine Ahnung hat, wie sein Feld aussieht.
Kompletter Unsinn ist allerdings die Karte auf einen zentralen Server hochzuladen. Das ist vielleicht als Feature ganz nett, wenn man von der Arbeit mit dem Smartphone einen Bereich auf der Karte zeichnen kann wo der Roboter jetzt gefälligst zu saugen hat, das ging allerdings technisch auch ohne Herstellercloud...
Ich hoffe die Stichpunkte haben weitergeholfen.
um wirklich alle Stellen anzufahren und keine auszulassen - oder tatsächlich ganz bestimmte Bereiche auszusparen
Dass man Bereiche sperrt, indem man Markierungen setzt, in Form von Baken oder so, ist wohl nicht mehr aktuell? Wenn ich Bereiche über die Karte markiere, die er nicht anfahren soll, dann ist die Karte wieder für den Menschen gemacht, damit der sich orientieren kann. Stellt also eine Kommunikationsvereinfachung dar.
Mal anders gedacht: wenn ich davon ausgehe, dass anhand aller Sensoren ein fast beliebiger Punkt eindeutig wiedererkennbar ist - also zumindest Punkte, die weiter auseinanderliegen - und ich navigiere von A nach B. Angenommen, Punkt K ist Küche, Punkt T ist Toilette, Punkt W ist Wohnzimmer. Dann kann der Roboter die Punkte ansteuern (ich setze voraus, dass der den Weg erlernt hat, ohne Karte), ich kann aber auch bestimmte Punkte weglassen, dann steuert der die nicht an, um also so Bereiche in der Wohnung auszuschließen.
Was bezweckt man im Gegensatz mit SLAM - Bereiche Zentimetergenau abzufahren? Das würde dann einen gewissen Sinn ergeben, dass ich z.B. ein 50cm Quadrat in einem Raum besonders behandeln kann. Im Übrigen geht es doch auch immer darum, dass der Roboter Stellen/Hindernisse, die er nicht bearbeiten kann (um beim Saugroboter zu bleiben), autonom umfahren muss, schon deswegen, weil mit reichlich ortsveränderlichen Hindernisse zu rechnen ist.
MfG
oberallgeier
24.06.2020, 08:47
.. wen interessiert der Grundriss der Wohnung? Sicher nicht den, der darin wohnt ..Das kann man/ich so nicht stehen lassen. Meine Wohnung hat acht Räume (ohne Vorrats- und Besenkammer, ohne Kellerräume, Garage und Treppenhaus) und eine Süd- und eine Westterrasse. Wenn man da irgendwo ist und auf die Toilette muss könnte es praktisch sein, wenn man den Grundriss im Kopf hat und nicht zufällig durch die Wohnung stapft um den zugehörigen Raum zu finden.
Der Roboter mit ordentlichen Raumkenntnissen kann - wenn er es kann - sich einen regelmässigen Säuberungsplan zurecht legen und den abarbeiten. Die "Standardroboter" können das nicht. Daher müssen die eben mehrfach - auf mehr oder weniger zufälligen Routen, je nach Sensorausrüstung - hin und her fahren und manchen Fleck auch doppelt oder mehr- bzw. vielfach saugen. Die Gesamtheit dieser Zufälle bringt dann statistisch ein vollständiges Gesamtergebnis. Den Vergleich mit dem Toilettengang ohne Lageplan will ich jetzt nicht ausweiten.
Bei meinem WALL R (https://www.roboternetz.de/community/threads/36121-Autonom-in-kleinen-Dosen-R2_D03-Nachfolger-R3D01?p=382774&viewfull=1#post382774) habe ich auch keinen wirklichen Plan der Umgebung. Da hilft eine der möglichen Richtlinien für Blinde (oder Leute mit mehr als ein Promille): immer an der Wand lang. Seine Fahranweisung lautet etwa: Gib Gummi bei mehr als 1,5 m Freiraum nach vorne mit LEICHTER Rechtskurve, bei weniger Freiraum nach vorne proportional zum Freiraum abnehmende Geschwindigkeit UND mit abnehmendem Freiraum zunehmenden Lenkeinschlag links. Und so fährt WALL R dann eben nicht total irre (siehe hier (https://www.roboternetz.de/community/threads/40453-WALL-R-l%C3%A4uft-%28autonomes-Fahrzeug%29)) - lässt aber den Raum "in der Mitte" weitgehend unbefahren. Möglich wäre bei WALL R auch ein Anfahren einer Wand bis auf einen vorbestimmten Abstand, dann ne Art Wende um mehr als ein paar Grad bis weniger als 180° - und schon könnte der den ganzen Raum für zufällige Fahrmuster durchkreuzen.
Witzig, ich finde es offensichtlich, dass man eine Karte benötigt. Als Mensch hast du ja auch eine Karte im Kopf wenn du von A nach B fährst. Und die Karte sagt dir, dass du von Hamburg nach Köln nicht über Berlin fährst. Genau das selbe für Roboter
Kann ich nach vollziehen und ich verstehe den Ansatz.
Ich kann mir aber vorstellen, dass so ein Verfahren zumindest rechenintensiv ist.
Ich habe es noch nicht ausprobiert, deswegen frage ich mal. Um mich an Strategien ran zu tasten, was dann auf mich zu kommt, wenn das Chassis zuverlässig fährt (sieht im Moment gut aus). Muss ja irgendwie eine gewisse Vorplanung machen.
Ich hoffe die Stichpunkte haben weitergeholfen.
Hilft im Moment alles weiter, weil ich mich praxisorientiert das erste Mal jetzt mit dem Thema auseinander setze. Theoretisch ist vieles manchmal recht einfach, praktisch tauchen dann aber u.U. Probleme auf, die nebenbei auch noch zu bewältigen sind.
@oberallgeier
Danke für das Beispiel ohne SLAM! Eben so was reicht doch bei den meisten Saugrobotern aus, würde ich meinen.
MfG
also für Saugroboter etc. ist es doch klar: um wirklich alle Stellen anzufahren und keine auszulassen - oder tatsächlich ganz bestimmte Bereiche auszusparen, wenn der Robi da grundsätzlich nicht hin- oder durchfahren fahren soll aus irgendwelchen Gründen. hast du schon mal etwas wie einen Saugroboter gebaut und mit einem Algorithmus programmiert, der wirklich keine Dreck-Ecken irgendwo stehen lassen darf? Probier's einfach mal, ohne Karte. Auch das permanente Aussparen von Bereichen ist ohne Karte IMO eine frustrane Angelegenheit.
Witzig, ich finde es offensichtlich, dass man eine Karte benötigt.
Ein Ansatz mit Karte und mit SLAM plus eindeutige Navigation und Positionsbestimmung ist für mich genau wie auch für Defiant absolut unverzichtbar und absolut offensichtlich.
Ich kann mir aber vorstellen, dass so ein Verfahren zumindest rechenintensiv ist.
Ja ist es, für eine kleine Wohnung reicht ein raspberry pi 3 (oder vergleichbar) gerade eben. Besser ist in jedem Fall schon ein Intel Core i5/7. Wobei man hier auch Einstellen kann. Eine Auflösung von 10cm/Feld benötigt natürlich weniger CPU-Zeit als 2.5cm/Feld.
ich habe das grundsätzlich auch schon auf einem Arduino Due hingekriegt, wobei die Kartenfelder etwa so groß waren wie der Robot selber (denn er sollte ja auch auf einem Pfad, der 1 Feld breit ist, tatsächlich auch fahren können). Vorteil beim Due: er kann kooperatives Multithreading (Due Scheduler), das ist essentiell. Die aktuelle Position (float) wurde dann auf eine 100x100 Integer Karte projiziert.
Ein SAMD51 wäre noch leistungsfähiger, hier bin ich aber nicht sicher, ob MT Libs auf ihm laufen.
(edit: doch klar: z.B. ein Teensy 3.5/3.6 mit TeensyThread!!)
Einen ESP32 empfehle ich wegen der vielen Inkompatibilitäten und wackeligen Libs grundsätzlich nicht mehr.
Mein RaspberryPi2B hat aber ebenfalls für SLAM reibungslos gearbeitet (mit pthread MT).
Einziges Problem immer: die reproduzierbare Lokalisierung:
Odometrie alleine ist ungeeignet, Gyro hat unkompensiert zuviel Drift, Kompass und GPS aber nur für outdoors wirklich gut geeignet, Sensorfusion mit Kalman- und/oder Montecarlo-Filtern (am besten 2 parallel, je nach Untergrund wegen Schlupf), Baken zum Anpeilen sind an sich state of the art, und hier am besten dm-Wellen wie bei Pozyx (das war mir aber dann doch zu teuer um es selber zu benutzen). Um die ganzen Rechnereien parallel in Zeitscheiben nicht-blockierend und priorisiert durchzuführen, dazu genau wird das MT benötigt.
Holomino
24.06.2020, 10:21
Ich habe mal letztens versucht, herauszubekommen, was denn nun in so einem käuflichen Lidar-Roomba an Prozessor/Speicher verbaut ist. Nach einer Stunde suchen war ich allerdings genauso klug wie vorher.
Kann hier vielleicht mal jemand sein Schätzchen aufschrauben?
Nachtrag. Hab doch noch was gefunden.
https://kaeni.de/hack-des-xiaomi-mi-vacuum-robot-gewaehrt-brisante-einblicke/
Die Daten sehen einem Raspberry schon ziemlich ähnlich.
Wobei die Hardware wohl eher als abgestripptes Laufzeitsystem zu verstehen ist. Die Navigation wird wohl nicht auf dem Roboter selbst entwickelt worden sein.
hast du schon mal etwas wie einen Saugroboter gebaut und mit einem Algorithmus programmiert, der wirklich keine Dreck-Ecken irgendwo stehen lassen darf?
Also es geht ja darum, dass ich gerade was baue, wo ich noch nach Entscheidungshilfen suche, welche Lösungen ich erwäge.
Deshalb ist die Frage nicht nachzuvollziehen.
Da ich aber mit einem normalen Staubsauger auch nicht 100% jede Ecke erreiche und auch Stücken frei bleiben, die ich mal nicht erwische, erübrigt sich für mich die Frage, ob ein Roboter das können muss. Geht allein schon deshalb nicht, weil es auf die Konstruktion ankommt. Kein Roboter kommt in unserer Wohnung an jede Ecke dran.
Ein Ansatz mit Karte und mit SLAM plus eindeutige Navigation und Positionsbestimmung ist für mich genau wie auch für Defiant absolut unverzichtbar und absolut offensichtlich.
Nein, es ist eben nicht absolut offensichtlich. Offensichtlich ist es aber eine Lösung für ein Problem.
MfG
selbstverständlich geht es nur um Stellen, wo er grundsätzlich hinkommen kann, auch wenn sie möglicherweise etwas versteckt sind, du Scherzkeks ;)
durch zufälliges Herumfahren wirst du NIE alle zugänglichen Stellen abdecken, und auch nicht durch paralleles Abfahren von versetzten Geraden (Boustrophedon Pfad)! 8)
Holomino
24.06.2020, 13:13
Doch, da gibt es durchaus Probleme.
Versuch einmal mit Deinem o.g. 10cm-Raster eine 12cm breite Passage zu durchfahren. Auf das Raster quantisiert gibt es die nicht. Schon gar nicht in der Diagonale.
Nachtrag. Hab doch noch was gefunden.
https://kaeni.de/hack-des-xiaomi-mi-vacuum-robot-gewaehrt-brisante-einblicke/
Die Daten sehen einem Raspberry schon ziemlich ähnlich.
Wobei die Hardware wohl eher als abgestripptes Laufzeitsystem zu verstehen ist. Die Navigation wird wohl nicht auf dem Roboter selbst entwickelt worden sein.
Interessant, und eine ganz schön mächtige Soft- und Hardware-Architektur!
ARM Quadcore Prozessor mit 1,5 GHZ pro Kern, 512 MB RAM, 4 GB eMMC-Flash, ARM Cortex M3 STM32 MCU zur Steuerung der Sensoren). Der Roboter kommuniziert per Cloud-Protokoll ausschließlich über das Internet mit der Mi-Home Anwendung, nicht über das lokale Netzwerk.
- - - Aktualisiert - - -
Doch, da gibt es durchaus Probleme.
Versuch einmal mit Deinem o.g. 10cm-Raster eine 12cm breite Passage zu durchfahren. Auf das Raster quantisiert gibt es die nicht. Schon gar nicht in der Diagonale.
doch, klar, ich bin immer über den Mittelpunkt eines jeden Rasterfeldes gefahren (berechnet und gemessen), mit IR Sensoren nach allen Seiten, um die Begrenzungen und zufällige, temporäre Hindernissen zu erfassen. Pathfinding über AStern und Bug2-Algorithmen. Außerdem war mein Robot knapp 40x40cm groß, und die Quadrate zB. 50x50. War aber bei mir kein Staubsauger-Robot.
PS, und ich behaupte ja nicht, dass es nie Probleme gibt, aber ohne Karte klappt es Null.
Holomino
24.06.2020, 13:46
Mal schnell gezeichnet:
35135
Schwarz das Raster. Blau die tatsächliche Passage.
Was genau hast Du da im Fall b) gemacht?
im Fall b) hat der Roboter nicht versucht, zwischendrin durchzufahren, sondern außenrum.
Aber ich musste auch nur einen Pfad von A nach B finden, und nicht alle möglichen Felder befahren zum Saubermachen, denn es war ein Liefer-Robot, der von Start aus einen möglichst kurzen Pfad zum Ziel finden musste, kein Staubsauger-Robot.
Beim Staubsauger-Robot wird es sicher noch weit komplizierter, s.z.B. dein pdf - aber dann geht es bei Stellen, die nur per Umwege erreichbar sind (wie im Labyrinth) erst Recht nicht ohne (höher auflösende) Karte, damit nichts "vergessen" wird.
Holomino
24.06.2020, 14:14
Ich glaube eher, dass der Roboter sich zwar zur globalen Orientierung eine ausreichend auflösende Map speichert, aber zumindest die Feinheiten (Kanten, Taschen) mit einer einfachen Rechtsfahrregel (Abstandsregelung ohne das Raster) abfährt. Der Sauger muss ja auch z.B. um Stuhlbeine herum. Solche Dinge im cm-Raster in die Map einzuzeichnen, würde spätestens beim Pathfinding eine immense Rechenleistung erfordern.
ja, das sehe ich auch so (Rechtsfahrregel oder aber Mäander-Muster), plus aber Algorithmen, wie auf temporäre Hindernisse zu reagieren ist, um bisherige (jetzt momentan verstellte) Passagen zu umfahren, um dennoch an eine versteckte Stelle (laut bekannter Karte) zu kommen.
Gleiches gilt ntl für stationäre Hindernisse, die versteckte Ecken verstellen.
Pathfinding per AStern oder Bug2 ist aber nicht so schrecklich aufwändig, s.z.B. alte TomTom-Navigationsgeräte. Die hatten auch keinen Quadcore-ARM.
PS, in seiner Karte muss der Robot nur schauen, wo bekannte freie Stellen sind, und markieren, wo er schon war und wo nicht, wo er also noch hin muss.
PS, in seiner Karte muss der Robot nur schauen, wo bekannte freie Stellen sind, und markieren, wo er schon war und wo nicht, wo er also noch hin muss.
Das ist doch mal eine konstruktiver Ansatz. Sicherlich ein guter Ansatz, falls - aus welchen Gründen auch immer - "der Faden" verloren gegangen ist.
Was das zufällige Umherfahren angeht: davon bin ich nicht so überzeugt. Irgend einen Plan/Algorithmus wie gefahren wird, muss so ein Roboter schon haben.
Gestern habe ich durch Spielereien einige Bauteile geschrottet, deshalb warte ich auf neue, dann geht es weiter. Dann mach ich mich als nächstes ans Kurven fahren und was sonst damit zusammenhängt in irgendeine Richtung zu fahren.
Derweil können die andern Informationen verarbeitet werden. Die Fortbewegungsweise und die Sensorengenauigkeit wird ein Konzept erforderlich machen. Mal schauen welches, das ergibt sich dann. Am wichtigsten wird sein, wie gut man einen bestimmten Punkt anhand der Sensordaten wiedererkennen kann; also die eigene Positionsbestimmung, wenn man so will.
@HaWe
Was Deine abwertenden Äußerungen angeht, scheinst Du heute einen schlechten Tag erwischt zu haben. Deshalb nehme ich das nicht so persönlich. Ändert aber nichts an der zumindest vorübergehenden Listenteilnahme.
MfG
@HaWe
Was Deine abwertenden Äußerungen angeht, scheinst Du heute einen schlechten Tag erwischt zu haben. Deshalb nehme ich das nicht so persönlich. Ändert aber nichts an der zumindest vorübergehenden Listenteilnahme.
abwertend?
schlechter Tag?
wie kommst du darauf?
Ich bin heute super-konstruktiv mit absolut historischen Maximalwerten und habe auch sonst heute einen echten geradezu euphorischen Spitzen-Tag! :p
Und wie absolut sinnvoll eine Karte ist, habe ich doch auch schon in meiner ersten Antwort geschrieben, genau wie Defiant nach mir 8)
PS,
trotzdem wird dir das alles nichts nützen mit dem Pathfinding und Kartenbereiche-anfahren, wenn du kein exaktes, zuverlässiges Ortungssystem hast (Positionierung, Navigation), denn damit steht und fällt alles.
Daher habe ich das ganze auch aufgegeben.
Holomino
24.06.2020, 17:38
Vielleicht sollten wir hier auch zuerst einmal über ein machbares Sensor-Setup reden.
machbar ist nicht das Problem (Odometrie, Gyro, Kompass, GPS...)
Das Problem ist die Zuverlässigkeit, Störungssicherheit und Exaktheit der berechneten Positionierungswerte über 15min hinaus...
und da kenne ich nur Pozyx, und das ist sehr teuer...
Vielleicht sollten wir hier auch zuerst einmal über ein machbares Sensor-Setup reden.
Viel fällt mir da nicht ein. Ultraschall ist eine praktikable Sache. Bei Infrarot habe ich gesehen, dass die Abstandsmessung durch Reflexionseigenschaften der Oberfläche beeinflusst wird und von deren Farbe. Sehr schmale Objekte zu erkennen funktioniert wahrscheinlich nur gut, bei einer kleinen Distanz zum Objekt. Da werden dann wohl Berührungssensoren herhalten müssen. Ultraschall und Berührung wären, für das Erste, meine Favoriten. Ich habe da noch wenig Erfahrung, da muss ich noch probieren.
MfG
Ultraschall benöitigt wegen der vergleichsweise geringen Schallgeschwindigkeit lange delays zwischen Ping-senden und Reflexe-empfangen, und man braucht mehrere davon, rundrum: wenn in eigenen Timeslice-Scheduler-Threads, dann ist es möglich, aber trotzdem sehr langsam insgesamt.
Sharp IR DistanzSensoren (ADC) lassen sich deutlich schneller abfragen (klar: Lichtgeschwindigkeit), inkl Auswertung quasi in Echtzeit, und sind daher besser zu händeln.
Noch besser ist ntl LIDAR.
Stehen die Hindernis-Flächen aber sehr schräg zur Messrichtung, ist die Erkennung in allen Fällen sehr schlecht bis unmöglich, denn die Wellen werden weg-reflektiert.
Mit manchen Textiloberflächen haben auch fast alle Sensoren Probleme (Vorhänge, schwarze oder "flauschige" Polstermöbel etc.).
Daher braucht man immer noch zusätzliche Stoßstangen-Bumper-Taster, falls Distanzsensoren mal versagen.
USS haben allerdings 1 Vorteil gegenüber IR/Laser: sie reagieren grundsätzlich auch auf Glas-Hindernisse.
Diese genannten Sensoren dienen aber alle nur zur Hindernis-/Objekterkennung, nicht vorrangig zur Positionsbestimmung und Navigation, man kann mit ihnen also nicht eine Position im Raum oder (per Projektion) in einer Referenz-Map bestimmen. Alleine mit Distanzsensoren kann man also eine Art "Bumper-Car" oder "Wall-Follower" bauen, aber keine SLAM-Roboter.
Dazu benötigt man zusätzlich noch ganz andere Sensoren:
(Odometrie, Gyro, Kompass, GPS...)
Das Problem ist die Zuverlässigkeit, Störungssicherheit und Exaktheit der berechneten Positionierungswerte über 15min hinaus...
und da kenne ich nur Pozyx, und das ist sehr teuer...
PS,
man kann dm-Wellen- tags und Baken natürlich auch mit "nackter IC-Hardware" selber programmieren, dann wird es zwar sehr viel billiger, aber auch sehr viel komplizierter.
meint ihr nicht ein microcontroller wie tennsy 4.1 kann die daten nicht verarbeiten vom slam?
Holomino
25.06.2020, 14:13
meint ihr nicht ein microcontroller wie tennsy 4.1 kann die daten nicht verarbeiten vom slam?
Doch sicher - irgendwie. Cruise Missiles flogen letztes Jahrtausend schon autark mit 'nem 300MHz-System.
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).
Doch sicher - irgendwie. Cruise Missiles flogen letztes Jahrtausend schon autark mit 'nem 300MHz-System.
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.
Holomino
25.06.2020, 14:39
Alleine mit Distanzsensoren kann man also eine Art "Bumper-Car" oder "Wall-Follower" bauen, aber keine SLAM-Roboter.
Dazu benötigt man zusätzlich noch ganz andere Sensoren:
Das gängig in Staubsaugern verbaute RPLidar ist prinzipiell nichts anderes als ein drehbarer Sharp-IR-Sensor (Triangulation - gleiches Messprinzip).
Bezüglich Stabilität: Ich habe mal einen Langzeittest in der Simulation ein paar Tage laufen lassen (Roboter mit Lidar fährt über Zielpunkte durch ein kleines Labyrinth). Das hat meine Befürchtungen bezüglich des "Zulaufens der Map" (Die Karte verschwimmt so weit oder verschiebt sich, dass die Zielpunkte nicht mehr erreicht werden können) zerstreut.
meint ihr nicht ein microcontroller wie tennsy 4.1 kann die daten nicht verarbeiten vom slam?
denke ich auch, "irgendwie", ich habe es ja (ansatzweise) auch schon mit einem Arduino Due geschafft.
- - - Aktualisiert - - -
Das gängig in Staubsaugern verbaute RPLidar ist prinzipiell nichts anderes als ein drehbarer Sharp-IR-Sensor (Triangulation - gleiches Messprinzip).
Bezüglich Stabilität: Ich habe mal einen Langzeittest in der Simulation ein paar Tage laufen lassen (Roboter mit Lidar fährt über Zielpunkte durch ein kleines Labyrinth). Das hat meine Befürchtungen bezüglich des "Zulaufens der Map" (Die Karte verschwimmt so weit oder verschiebt sich, dass die Zielpunkte nicht mehr erreicht werden können) zerstreut.
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.
Holomino
25.06.2020, 15:00
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.
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.
Holomino
25.06.2020, 16:12
Daher braucht man exakte externe Navigations-Referenzen (Baken), die per Peilung eine zuverlässige und reproduzierbare Positionsberechnung erlauben.
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!
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!
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-filter-einfach-erklaert-teil-1,
https://www.cbcity.de/das-kalman-filter-einfach-erklaert-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-vacuum-robot-gewaehrt-brisante-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.
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üsten :) bei teensy 4.1
Holomino
25.06.2020, 21:35
Frei nach https://www.heise.de/ct/artikel/An-der-naechsten-Ecke-links-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.
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;
}
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)
Holomino
25.06.2020, 23:36
(PS, Übrigens wird wschl Arduino C++ Code benötigt, aber das nur nebenbei)
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.
33833
31296
30220
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.
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.
@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.
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.
ich bin jetzt sogar am denken mir einen preiswerten lidar zu besorgen und das ganze mit noch ein paar sensoren mit einem teensy 4.1 zu testen. ich habe laminat in der wohnung. ich kann meine modellraketen zur zeit nicht starten :(
danke für den artikel, mal einen artikel als basis, den man versteht :)
ich bin kein fan von ros, ich habe es mir angesehen und mir auch das buch besorgt, welches hier im forum angesprochen wird. auf den punkt es ist mir zu "kompliziert" das ros. :D
ja, ich abeite arduino software, nicht alles optimal, aber was ist schon optimal.
Wenn du mit ROS auf deinem Roboter anfängst würde ich vorher die Simulation mit dem Turtlebot 3 (https://emanual.robotis.com/docs/en/platform/turtlebot3/simulation/#turtlebot3-simulation-using-gazebo) empfehlen. Da sieht man dann das komplette Zusammenspiel ohne sich zuerst mit den Unzulänglichkeiten seiner Hardware auseinandersetzen zu müssen.
Holomino
26.06.2020, 12:11
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.
Ich finde Deine Gedanken überhaupt nicht schlecht. Ich bin selber nicht begeistert von dem zu betreibenden Aufwand.
Für mich ist das eigentlich nur der sopisticated Ersatz der Märklin-Eisenbahn aus Kindertagen, bei dem man sich die Mühe spart, Schienen zu verlegen, der trotzdem auf Knopfdruck oder zeitgesteuert in die Küche fährt, zurückkommt und wieder am Lader andockt.
Und ich hatte auch lange Zeit das offensichtliche Problem, das Spielzeugkits für nen Hunni weit vor meiner Zielsetzung aufhörten und danach praktisch nur noch Akademikerlösungen und Industrieprodukte zu finden sind.
Aber ich hatte Dir an anderer Stelle auch schon einmal vorgeschlagen: Bau Dir eine Simulationsumgebung in der Programmiersprache Deiner Wahl. Die drei Wochen Arbeit lohnen sich! Das hat mir geholfen und es wird mit aller Wahrscheinlichkeit auch Dir helfen.
Ich könnte Dir ja mein C#-Gehuddel einfach übergeben, allerdings muss man sich meiner Ansicht nach sowohl in der Programmiersprache als auch in der Umgebung heimisch fühlen, um konstruktiv weiterarbeiten zu können.
Meine letzten Gedanken bezüglich der "einfacheren" Navigation, also dem Entlanghangeln an Wänden (ggf. mit Überqueren von Türdurchgängen) mit dem Ergebnis einer Linienliste habe ich noch nicht aus den Augen verloren, wobei "einfacher" für mich weniger die Programmierung (einmal gesofteter Quellcode kostet nix) und eher die Sensorik betrifft. Praktisch allerdings habe ich auch nur meinen uralten Linebuilder (bildet Linien aus der Punktwolke eines Rundumscans) herausgekramt, angepasst und verbessert.
Ich verwende ja ROS, was auch gerne von den Forschungsstätten verwendet wird und damit nicht grundsätzlich nicht alles falsch macht.
Der doppelten Negierung Deines Satzes warst Du Dir bewusst?:p
Aber mal ne Frage dazu: Verwendet ROS auch eine Rasterkarte?
Der doppelten Negierung Deines Satzes warst Du Dir bewusst?:p
Danke, hab es geändert.
Aber mal ne Frage dazu: Verwendet ROS auch eine Rasterkarte?
Ja natürlich: http://wiki.ros.org/costmap_2d
Bau Dir eine Simulationsumgebung in der Programmiersprache Deiner Wahl.
Habe ich ja eigentlich auch, meine Wohnung :)
Praktisch allerdings habe ich auch nur meinen uralten Linebuilder (bildet Linien aus der Punktwolke eines Rundumscans) herausgekramt, angepasst und verbessert.
Ich sehe an Deinen Ausführungen aber, dass Du andere Denkansätze verfolgst.
Wenn das Gerät mal richtig fährt, also dazu gehören jetzt noch Kurvenfahrten und Richtungswechsel, dann besteht die nächste Aufgabe darin, noch mal zu schauen, ob ich mir das Phänomen mit den Schritten wirklich sinnvoll zunutze machen kann. Indem ich über die Odometrie ein Korrekturverhalten hinbekomme, dass auch bei höheren Geschwindigkeiten die Richtung gehalten wird. Sonst müsste ich so was wie einen Kompass einsetzen. Oder, eine andere Idee war jetzt, jeden Motor mit einem Beschleunigungssensor zu versehen, um auch bei jedem Mikroschritt die Beschleunigung zu erfassen, nicht nur die Lichtschranke an der Welle. Sinnvoll könnte ich mir auch vorstellen, Hindernisse in Bodennähe zu erkennen, wie Absätze (Teppichkanten oder Leisten), damit man dort langsam drüber fährt, wegen einem ungewollten Richtungswechsel.
Wenn das dann mal funktioniert, dass das Gerät anständig fährt, würde ich die ersten Experimente mit Ultraschall machen und sehen, welche Ergebnisse ich bekomme. Irgendwie muss so ein Roboter dann ja doch die eigene Position erkennen können, von der er startet. In dem Zusammenhang werde ich auch noch mit RFID-Tags herumprobieren, das soll bis zu einigen Metern funktionieren, weiß nur noch nicht wie und ob das mit Passiven auch über größere Entfernung (1m oder auch 2m) funktioniert. Gibt viel zu tun.
MfG
Holomino
26.06.2020, 13:40
Ja natürlich: http://wiki.ros.org/costmap_2d
Irre, ich finde sogar die Funktion meines "ErodedGrid" wieder, in dem ich statt des Roboters die Hindernisse mit einem Radius eintrage, um dem A* die nicht befahrbaren Punkte nahe an den Hindernissen wegzunehmen.
35139
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.