Zitierenmachbar 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.
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...
Zitat von Holomino
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:
PS,(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...
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.
Geändert von HaWe (25.06.2020 um 13:52 Uhr) Grund: PS
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.
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.
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.
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.
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.
Berechtigungen
Lesezeichen