Think Modular

[Holomino]

Tja, genau das geht bei meinem kettengetriebenen Modell nicht. Eine einigermaßen schnelle Geschwindigkeitsregelung über die Messung der Gegen-EMK am Antrieb ist zwar durchführbar, hat aber wegen Schlupf und Bodenhaftung mit der Bewegung des Fahrwerks wenig gemeinsam.
Ich messe die Odometrie unabhängig vom Antrieb durch zwei zusätzliche Messräder. Da bekomme ich im 8ms-Zyklus von den Inkrementalgebern +/-0..3 Schritte - das reicht für die Posenberechnung, gibt aber zu wenig Fleisch als Istwert einer Geschwindigkeitsregelung.

Kurz: Ich habe keine Geschwindigkeitsregelung.

[Holomino]

So, kurz zusammengefasst: Ich hatte bislang Bewegungsmodul, Powermodul und ein Protokoll angerissen. Fehlt eigentlich noch die nach außen gerichtete Sensorik.

Fertige Lidars (RPLidar/YDLidar < 100€) sind recht erschwinglich geworden und sind mit UART auch problemlos anzubinden. Bei einem Eigenbau mit einem oder mehreren Distanzsensoren (LidarLite, TFMini, VL53L1X) und einer Drehmimik hat man vielleicht noch einige Freiheitsgrade mehr:
- Man kann mehrere Sensoren auf einen Drehteller packen, ohne dass sie sich gegenseitig die Sicht einschränken.
- Man kann mit einem leicht nach unten geneigten Sensor das Nahfeld abtasten.
- Man kann auch Sensoren einbauen, die nichts mit einer Distanzmessung zu tun haben (z.B. die Richtung einer IR-Diode anpeilen).
Letztlich braucht es zum Eigenbau einen Drehantrieb (Motor), eine Drehwinkelerfassung (damit ein Sensorwert einer Richtung zugeordnet werden kann) und einer Übertragung von Strom und Daten (wenn sich der Teller kontinuierlich 360° drehen soll).

Andere Möglichkeit: Kameras in 2 oder 3D, also Kinect, RealSense oder CAM. Sind über USB angeschlossen nicht so bastelintensiv, legen aber die Messlatte der Hardwareanforderungen bezüglich Auswertesoftware recht hoch an.

Dann gibt's auch noch Hilfsmittel zur Positionsbestimmungen per Funk GPS & Co. Die geben aber keine Informationen über die Umgebung (Hindernisse) preis. Man weiß also, wo man in etwa ist, aber ohne Umgebungskarte nicht, wo man entlangfahren kann.

Was gibt's noch?

[Defiant]

Eine einigermaßen schnelle Geschwindigkeitsregelung über die Messung der Gegen-EMK am Antrieb ist zwar durchführbar, hat aber wegen Schlupf und Bodenhaftung mit der Bewegung des Fahrwerks wenig gemeinsam.

Wenn man will geht es auch. Mein erster Roboter für den ich einen ROS-Adapter geschrieben habe, hatte auch Ketten. War zugegeben eine Aufgabe über Wochen. Langsam anfahren hilft. Um Fehler bei der Rotation auszugleichen gibt es IMUs. Fehler bei der Rotation führen ja bekanntermaßen zu größeren Fehlern in der Position als Fehler in der Translation. Multikopter bekommen es ja auch hin die Geschwindigkeit über Grund zu messen.

Andere Möglichkeit: Kameras in 2 oder 3D, also Kinect, RealSense oder CAM. Sind über USB angeschlossen nicht so bastelintensiv, legen aber die Messlatte der Hardwareanforderungen bezüglich Auswertesoftware recht hoch an.

Muss nicht sein wenn man nur eine oder N-Bildzeilen auswertet erhält man ein einfaches Array. Dies habe ich anfangs mit der XTion gemacht . Hat gut funktioniert, Lidar ist aber überlegen wegen der geringeren (Die XTion war bei unter 80cm blind) und höheren Reichweite sowie konstanteren Genauigkeit (Die Daten der XTion waren ab 3m für Slam nicht mehr zu gebrauchen).

Bei den Sensoren würde ich unterscheiden ob ich sie für Hinderniserkennung oder Positionsbestimmung verwende. Dies sind zwei Anwendungsfälle die meiner Meinung nach nichts miteinander zu tun haben, obwohl ich teilweise dieselben Sensoren einsetzen kann. Außerdem würde ich für Hinderniserkennung unterschiedliche Sensortypen miteinander kombinieren, ich verwende z.B. Lidar und US-Sensoren. Das Lidar liefert keine verlässlichen Abstände bei Spiegeln, Fenstern und Sonnenlicht, die US-Sensoren versagen bei schalldämpfenden Stoffen (Kissen..).

[Holomino]

Bei den Sensoren würde ich unterscheiden ob ich sie für Hinderniserkennung oder Positionsbestimmung verwende. Dies sind zwei Anwendungsfälle die meiner Meinung nach nichts miteinander zu tun haben, obwohl ich teilweise dieselben Sensoren einsetzen kann. Außerdem würde ich für Hinderniserkennung unterschiedliche Sensortypen miteinander kombinieren, ich verwende z.B. Lidar und US-Sensoren. Das Lidar liefert keine verlässlichen Abstände bei Spiegeln, Fenstern und Sonnenlicht, die US-Sensoren versagen bei schalldämpfenden Stoffen (Kissen..).

Das ist korrekt. Auch bei den käuflichen Staubsaugern mit Lidar findet man immer noch Bumper und andere Sensoren, die die Umgebung unterhalb der horizontalen Lidarebene abtasten.

Dieses Thema birgt einige Tücken. Streng genommen müsste der gesamte Roboter von der Ebene der Bodenfreiheit (was er hochsteigen kann) bis zur höchsten Stelle mögliche Kollisionen melden. Bei Rückwärtsbewegungen gilt das auch für's Heck, mit Omniwheels wird's noch wilder.

(Nähkästchen an)
Ich habe hier ein Klo (an der Wand befestigt) und einige Heizkörper, deren Unterkante sich genau 1cm mit der Höhe der Sensorplattform meines Roboters überschneiden. Kein Sensor sieht, wenn der Robbi sich daran festsetzt. Die obersten 2cm meines Roboters sind wirklich unüberwachte Zone. Der Drehteller der Sensorik bleibt aber bei einer Kollision stecken. Zur Zeit (weil ich keine Lust hatte, noch einen Sensor leicht nach oben messend dranzubauen) besteht meine kreative Lösung darin, den Störfall "Plattformmotor ist an, Richtungsdetektion zeigt aber keine Drehung" als Reflex auszuwerten, durch den sich der Roboter freifährt.
(Nähkästchen aus)

Ich denke mal, jedes "Labor Wohnung/Gelände" hat da so seine Fallen. Da die Hindernisdetektion von den tatsächlichen Abmessungen des Roboters abhängt, spricht aber doch nichts dagegen, sie als Beiwerk in den Modulen, die das Mobil physikalisch vergrößern, zu verpacken. Egal wie viele Sensoren welcher Art man braucht: Ein unpassierbares Hindernis zeichnet sich nur durch seinen Standort aus.

[Holomino]

Es fehlt immer noch was - der Braincomputer:
Nachdem wir nun wissen, das wir laufend von Navigations- und Hindernissensorik, Bewegungsmodul und Powermodul mit Daten bombardiert werden, wir auch noch Fahranweisungen und Steuerkommandos zurückschicken müssen, wird es Zeit, sich über den Umfang dieser Aufgabe klarzuwerden.

Zur Anbindung:
Ich hatte ja schon im Eingangsthread den Vorschlag gemacht, Bluetooth als Schnittstelle zur Hardware zu verwenden. Dann kann man z.B. auch das ausgediente Smartphone als Brain nutzen oder zur Entwicklungszeit die typischen 10m Reichweite dazu verwenden, komfortabel am PC oder Notebook zu entwickeln. Für den autarken Betrieb braucht man noch einen Versorgungsstecker. Brains ohne eigenen Akku, z.B. Raspberrys, quittieren eine Notabschaltung ohne geordnetes Herunterfahren im schlimmsten Fall mit einer kaputt geschriebenen SD-Karte. Das sollte man im Powermodul durch eine Ausschaltverzögerung berücksichtigen.

Zur Aufgabe:
SLAM baut eine Umgebungskarte und verbessert die Pose des Roboters darin. Die Funktion lässt sich am besten durch einen Stitch-Assistenten verdeutlichen, der laufend Teilbilder aus der Navigationssensorik möglichst passend übereinanderlegt und so über die vorgenommene Verschiebung eines eingefügten Teilbildes auf die tatsächliche Pose des Roboters rückschließt.

Sicher wird ein Roboter die Umgebungskarte für seine Fahrten nutzen, das Generieren der Bahnen ist allerdings nicht direkter Bestandteil von SLAM. Ein Pathfinder sucht auf der Umgebungskarte den kürzesten Weg von A nach B, ein Pathfollower führt die Fahrt durch senden von Steuerbefehlen an den Antrieb aus. Tritt im Verlauf der Fahrt ein Fehler (ein neues Hindernis) auf, muss der Pathfinder neu berechnen.
Ein Aufgabenplaner plant Abfolgen (z.B.: Fahre von A über B nach C und zurück nach A). Bei einem Überwachungsroboter z.B. werden so eine Reihe von anzufahrenden Wegpunkten und eine Uhrzeit für die Ausführung vorgegeben. Beim Saugroboter generiert der Aufgabenplaner die Wegpunkte in einem Raster, um die gesamte Bodenfläche abzudecken.

Das alles wollen wir überwachen und auch steuern. Dazu brauchen wir eine lesbare Darstellung der Umgebungskarte, der aktuellen Roboterpose und auch Eingriff in die Aufgabenplanung. Das bitteschön aber nicht am Gerät, sondern bequem vor einem Monitor - sonst müssten wir ja hinterherrennen.

Mal ein Fallbeispiel: Eine 10mx10m=100qm-Wohnung und ein Lidar

Die Umgebung lässt sich theoretisch in einem Occupancy-Grid (2D-Array, in dem je ein Wert eine x-y-Rasterfeld als frei, belegt oder unbekannt beschreibt) von 100x100=10000 Bytes mit den Abmessungen 10x10cm darstellen.
- Praktisch wissen wir nicht, wo und in welchem Winkel zu den Grundabmessunen wir starten. Das vergrößert das Grid ohne weiteres Speichermanagement um den Faktor (2*Wurzel(2))²=8 (Wir starten in der Mitte des OccupancyGrids und lassen in allen vier Himmelsrichtungen Platz für die Diagonale der 10*10m-Wohnung).
- Wir müssen unterscheiden zwischen Umgebung für den Stitch-Assistenten und Hindernisdetektion (was das Lidar nicht sieht, kann es nicht wiedererkennen). In eine zusätzliche Liste werden Hindernisse eingetragen (das Datenaufkommen ist wahrscheinlch niedrig).
- Die Umbewertung eines Feldes von "frei (>0)" auf "belegt (<0)" ist im worst case relativ träge (von 127 auf -1). Lidars haben die Eigenschaft, zwischen zwei Einzelmessungen eine Lücke aufzuweisen. So sieht man Stuhl- oder Tischbeine erst bei Annäherung. Man kann das Lidar aber selber als Hindernissensor interpretieren, also z.B. den letzten Scan in die Hindernisliste schreiben. Über die logische Oder-Verknüpfung von Occupancy-Grid des Lidars und Hindernisliste ergibt sich dann, ob ein Feld belegt ist.
- Die Abmessungen des Roboters und die Auflösung des Grids bestimmen, ob Felder in der Nachbarschaft eines belegten Feldes befahrbar sind. Ein Roboter mit 30cm Umfang stößt bereits auf dem Nachbarfeld eines als belegt markierten Feldes an das Hindernis an. Also muss man im Pathfinder auch diese Nachbarfelder ausschließen. Das kann man tun, indem man in einem neuen Grid (NavigationGrid) einfach die Hindernisse entsprechend der Abmessungen des Roboters vergrößert und im Pathfinder die Position des Roboters weiterhin als Punkt betrachtet.

Zusammen braucht man so LidarGrid, Hindernisliste und NavigationGrid. Zusätzlich braucht man noch einmal Speicher in der Größenordnung des NavigationGrid für den Pathfinder.
Ob das Raster so passt, erfährt man erst, wenn man in der Wohnung die schmalsten Wege (zwischen Sofa und Tisch?) sucht. Es ist zwar naheliegend, einen 30cm-Robbi auf einer 30x30cm aufgelösten Karte fahren zu lassen, aber 30cm Auflösung heißt auch nur, dass auf einer Kachel von 30x30cm irgendwo ein Hindernis liegt- vielleicht liegt es am Rand. Dann ist das Befahren des Nachbarfeldes in der Diagonale schon nicht mehr möglich.

Tröstlich: mit einem persistenten Speicher (SD-Karte,...) benötigt man weniger RAM. Änderungen in Lidar- und NavigationGrid könnnen nur in Sensorreichweite auftreten. Außerhalb der Reichweite liegende Kartenteile können also weggespeichert und bei Bedarf wieder hervorgeholt werden. Beim Pathfinder allerdings spart man ohne Vorberechnungen nix (der braucht zur Berechnung eines Pfades die gesamte Karte).

Fazit: Das klingt nicht nach einer Aufgabe für einen Microcontroller (die Funktion des "Stitch-Assistenten" habe ich noch gar nicht aufgezählt), zumal man beim Entwickeln ohne die grafische Darstellung kaum die Arbeit des SLAMs verifizieren kann. Die ganze Sache vielleicht noch per Wifi ins lokale Netz bringen zu wollen, macht es nicht unbedingt einfacher oder kleiner. Die Hardware über Bluetooth anzubinden erlaubt erst einmal den Start auf dem größtmöglichen Brain (das Entwickeln am PC). Herunterstrippen kann man später immer noch.

[Moppi]

Hallo,

ich habe gerade etwas Zeit, heute den ganzen Tag Fehlersuche.
Also für mich ist das zu weit weg, was Du vor hast, bzw. die Gedanken, die Du hegst. Mir würde zuerst mal ein Chassis fehlen, das auch fährt und lädt, bevor ich mich der komplizierten Steuerung mittels Laserscanner usw. widme. Da ich mich mit Lidar noch nicht wirklich beschäftigt habe, kann ich das zwar lesen und verstehen, was Du schreibst, aber mehr erst einmal nicht. Warum man unbedingt jetzt schon Wege auf einer Karte finden können soll, sehe ich auch nicht so ein. Zuerst wäre mal schön, wenn Hindernissen ausgewichen werden kann, würde ich denken. Vermutlich haben wir verschiedene Denk-/Lösungsansätze. Hier steht jetzt Lidar im Vordergrund, und nur das. Das entspricht der Lösung, wie bekomme ich möglichst viele Daten von meiner Umgebung, aus der ich eine Karte erstelle und dann versuche ich mich in Echtzeit durch die riesige Datenmenge zu bewegen, ohne irgendwo anzuecken, immer ein Ziel im Focus. Das kann man auch mit Kameras fortsetzen, womöglich mit mehreren auf einmal, damit man ein möglichst umfangreiches Umgebungsbild erhält, aus dem sich Entfernungsangaben berechnen lassen. Mir ist jetzt auch nicht ganz klar, ob hier ein autonomer, unabhängiger Roboter im Vordergrund steht. Aber ich denke eher nicht. Muss ja auch nicht. Asimo ist es offenbar auch nicht. Und in der Tat wird man dafür nicht nur viel Strom benötigen, sondern auch eine schnelle CPU, am besten mit mehreren Kernen. Ich würde denken, so vier Kerne sollten es schon sein dann. Zwei wäre evtl. etwas zu wenig. Ich kenne mich bei Lidar mit den Datenmengen zu wenig aus, die verarbeitet werden müssen, das betrifft auch die Kartengröße, die dann immer wieder durchkämmt werden und aktualisiert werden muss. Daher hätte ich jetzt gesagt, besser wäre vielleicht eine SSD-Festplatte, statt einer SD-Karte. Aber gut, so langsam sind SD-Karten jetzt auch nicht, vielleicht genügen die gerade noch; da kommt es ja auch auf das System an, das die Daten ausliest.

Das waren erst mal so meine Gedanken dazu. Vielleicht finden sich noch andere Meinungen.


MfG

[Holomino]

Mir ist jetzt auch nicht ganz klar, ob hier ein autonomer, unabhängiger Roboter im Vordergrund steht.

Hier soll es um den modularen Aufbau mobiler autonomer Roboter gehen. Vor dem Hintergrund, dass solche Systeme mittlerweile z.B. auch als Staubsauger systematisch unsere Wohnung abgrasen und damit technisch offensichtlich für wenig Geld machbar sind, ist die Frage: Was steckt drin? Wie spielt es zusammen? Was muss ich tun, um Ähnliches zu erreichen?

(Aus meinem Eingangspost)

Sieh es so: Die letzten 8 Seiten listen ganz grob eine Bastler-Minimalkonfiguration für diese Aufgabe auf.
Das ist schon eine Menge Holz. Eigentlich warte ich die ganze Zeit mit Spannung darauf, dass jemand sagt: Es geht doch viel einfacher.
Tut es das?

[inka]

Es geht doch viel einfacher. Tut es das?

ohne jetzt Deine ausführungen in frage stellen zu wollen, bin ich der meinung, dass es tatsächlich einfacher geht:

Ich stelle für meine roboter erstmal nicht die forderung auf, dass sie in der lage sein müssen eine karte der umgebung zu erstellen. Trotzdem können sie sich autonom bewegen. Mir reicht es schon, wenn sie durch den raum fahren können ohne anzustossen und bevor der saft zu ende ist in der lage sind eine ladestation zu finden. Und dazu reicht ein atmega 2560, ein US-modul ein bischen odometrie und ein linienfolgemodul...
Der antrieb spielt dabei erstmal eine untergeornete rolle, egal ob schrittmotoren, DC-motoren, mit ketten, normalen rädern oder omniwheels...

Auch ist es mit diesen wenigen mitteln möglich den roboter auf den weg zu schicken damit er mit einem separaten videomodul aufnahmen macht, die man sich dann "zuhause" in aller ruhe anschauen kann. Ich denke ich bin da ganz in Moppi's nähe...

[Moppi]

Eigentlich warte ich die ganze Zeit mit Spannung darauf, dass jemand sagt: Es geht doch viel einfacher.
Tut es das?

Ich bin mir nicht sicher, was Du genau damit meinst. Aber da ich zu 286er- und 386er - Zeiten ein Buch gekauft hatte (PC-Underground), bin ich davon überzeugt, dass vieles einfacher geht. Bei dem Buch waren Beispiele, von Assemblerprogrammen dabei. Fertige. Also das waren Demos, wo jeder Programmierer (oft auch mehrere zusammen) ihr Können presentiert haben (da gab es so Wettbewerbe oder so was .. irgendwo). Das konnte man nicht nur anschauen, sondern das war echt der Hammer! Man kennt ja noch die Speicherausstattung der damaligen Rechner und die langsamen Grafikkarten. Aber die Demos waren allesamt flüssig am Laufen. Am meisten hat mich eine Sphäre beindruckt, die sich über den Bildschirm bewegte und wo ein Spiegelbild drauf zu sehen ist (auch etwas komplizierter - sowas wie ein Gesicht etwa). Ohne Koprozessor, mit den mickrigen Rechenleistungen und in Farbe natürlich. Meist war sogar noch Musik drunter gelegt. Ich glaube ich hatte eine SB 2.0 (war ja damals Standard). Von so was gab es ein paar Demos. Und im Buch wurden Techniken erklärt, wie man 3D-Berechnungen anstellt auch mit nur maximal 16Bit-Operationen. Also Punkte im Raum berechnen, die mit Lininen verbinden, wie man Bilder in die Perspektive skaliert und die dann auf berechnete Flächen setzt. Seit dem ich das Buch gelesen habe, weiß ich, dass sehr viele Sachen oft ganz einfach zu lösen sind, man muss nur wissen wie. Das fängt dann eben vor allem damit auch an, dass man sich wirklich überlegt, wie viel Bit benötige ich, um einen bestimmten Wert / Größe zu speichern. Oft tun es auch nur halb so viele Bits, wenn man genau drüber nachdenkt, welchen Maximalwert man abbilden will und welche Auflösung man aus praktischer Sicht dafür benötigt. Alles in allem betrachtet, kann ich mir daher vorstellen, dass man auch mit einem nodeMCU 1.0 genügend Rechenleistung und Speicher hätte, um Lidar-Daten auszuwerten und in einer Karte zu speichern. Nur der Flash vom nodeMCU 1.0 ist nicht so brauchbar, da gibt es ein paar Tücken. Kann man aber durch eine SD-Karte ersetzen. Aber so weit bin ich jetzt noch nicht.

Wie soll das gehen? Versuchst du ohne Karte von Ost-Frankfurt in eine bestimmte Straße in West-Frankfurt zu fahren?

Diese Denkweise drängte sich mir auch auf, als ich das alles so las. Ich denke, genau darum soll es sich drehen: um autonomes Fahren eines Fahrzeugs (Tesla). Dass das autonome Fahren im Vordergrund steht, inkl. Wegfindung (Navigatonssysteme). Das kann man natürlich auch auf eine Wohnung skalieren. Aber ob es sinnvoll ist? Dafür muss man feststellen, welchen Zweck man verfolgt. Und welche Hardware man einsetzen möchte oder könnte. Ehrlich gesagt, bin ich aber dafür noch kein guter Gesprächspartner, weil ich mich zu wenig bis gar nicht mit diesen Themen beschäftigt habe (bis jetzt). Im Moment reize ich gerade den Speicher eines ATmega328P aus. Und da komme ich jetzt an Grenzen (gebe mir dennoch Mühe, dass das funktionieren kann).

Ich bin noch weit entfernt von dem, was hier so angedacht ist. Bin aber auch nicht so der Freund davon, nur weil es viel einfacher ist, üppige Hardware und überdimensionierte Programme für einfache Lösungen einzusetzen, die man vielleicht normal mindestens mit einem ESP32 hinbekommt. Nur müsste man dann ggf. selbst mehr programmieren, was mehr Zeit in Anspruch nimmt und man muss dann auch wissen, wie man das programmieren kann. Ich glaube, an letzterem mangelt es oft, weil dazu gehört einfach Übung, Übung und nochmals Übung; so dass man alles irgendwann irgendwo schon mal gemacht hat: Bilder auf ner GRafikkarte ausgeben (VESA Standard, weil es etwas einfacher ist), Animationen ablaufen lassen, auch direkte Programmierung der Grafikkarte, Sound direkt ausgeben (Soundblaster, weil alles gut dokumentiert ist), im nächsten Schritt lernen, wie man Linien zeichnet, um Fenster und Buttons darzustellen, lernen, was Memory Mapping in dem Zusammenhang bedeutet, erste Grafische Oberflächen selbst programmieren (sozusagen Pixel für Pixel), Mausabfragen durchführen (Maustreiber macht es einfacher, ohne geht auch), lernen, wie man direkt eine Tastatur programmiert und abfragt (Protokoll .... Register), vielleicht irgendwann auf Festplattenkrontroller zugreifen um die Festplatte zu schreiben und zu lesen (ROM-Bios macht es hier etwas einfacher) usw. Beispielhaft jetzt für die x86ger gesprochen, aber bei den µCs und Verwandten sieht es ähnlich aus. Kurz, ich beschäftige mich gerne mit der Materie im Detail selbst, damit ich weiß, warum was und wie genau funktioniert. Dann bekommt man vieles auch auf schmaler Hardware zum laufen. Hier gibt es schon eine Überleitung. Weil mir war noch was zu dem späteren "herunterstrippen" eingefallen: ich denke dieser Ansatz sitzt am falschen Ende. Wer will denn bitte etwas auf kleineres System umschreiben, was vielleicht mit Fremdsoftware auf einem größeren Computer läuft? Da wird sich dann niemand finden. Einfacher ist es, wenn man klein angefangen hat, auf schmaler Hardware, Sachen auf einen größeren Rechner zum Laufen zu bringen (da sind dann die Programmiersprachen mächtiger und einfacher und die Dinge lassen sich leicht nachbauen). So etwa nach dem Motto: größer geht immer, kleiner fast nimmer. Aber ich wollte eigentlich auch nicht so weit ausholen. Nur noch eins zum Schluss: manche Sachen werden sich sicher nicht ohne mächtigere Hardware machen lassen.

Gruß