(Für die, die hier öfter lesen: Ich wurde aufgefordert.)
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?
Ähnlich könnte sein, ein eigenes Saugsystem mit der Sicherheit zu bauen, dass Daten nicht ungefragt zum Hersteller versendet werden. Vielleicht kann man auch einen Teleskoparm drauf montieren, der Lichtschalter und Heizungsregler bedient. Oder es soll nur der Teppichkrabbler als Programmierspielzeug werden. Ideen und Realisierungen auch in diese Richtung sind hier gefragt.
All diesen Ideen gemeinsam ist: Es bewegt sich, es hat Sinne und es interagiert über Schnittstellen mit Umgebung und Benutzer. Zumindest die Arbeitszeiten kann man beim Staubsaugerroboter einstellen, meist auch Umgebungskarte und Standort abfragen. Dahinter steckt ein fein abgestimmtes System aus Sensoren, Aktoren, Mechanik und auf jeden Fall auch eine deftige Portion Software.
Eigentlich fast zu viel, um als Hobbyist von der Pike auf all diese Themen zu beackern: Hinter der Bewegung und den Sinnen steckt die Versorgung. Für den autarken Betrieb braucht man Ladetechnik, zum Andocken an eine Ladestation braucht es wieder Sensorik. Vorlagen, Konzepte oder der schlichte Meinungsaustausch sind also wünschenswert. Letztlich noch die Idee, hier im Forum einzelne Module herauszunehmen und praktische Lösungen für den Nachbau so zu gestalten, dass sie untereinander kombinierbar sind.
Um der Diskussion an diesem Punkt etwas Fleisch zu geben, anbei (neben ein paar Bildern aus dem RP6-Nachfolger-Thread) das Modulschaltbild meines letzten Modells:
Anhang 34456
Power: Es hat auch bei mir etwas gebraucht, diesen Teil mental als USV zu deklarieren. Letztlich steht mein "Movie" (so heißt das Ding) hauptsächlich in Bereitschaft am Ladegerät. Der "Stromausfall" ist dann der eigentliche Betrieb. Weitere Anforderungen (Laden, Balancing, Temperatur-/Spannungsüberwachung der Zellen, Ein-/Ausschalter, zusätzliche Spannungsausgänge) machen die Hardware recht komplex, aber der Anspruch, den Movie 24/7 in Bereitschaft zu halten, besteht nun mal.
Peripherie: Der Sternpunkt der Hardware. In diesem Fall bot es sich an, neben einigen Hardwarefunktionen der Sensorplattform auch das gesamte Bewegungsmodul direkt über den Peripheriecontroller zu steuern. Ich hatte die Pins. Bei komplexeren Fortbewegungsmethoden (z.B. Beine) kann man daraus auch ein einzelnes DriveModul machen. Letztlich beschränkt sich die Schnittstelle auf eine begrenzte Anzahl von Fahrbefehlen und die zyklische Rückmeldung einer Pose (x-/y-Koordinaten und Blickwinkel des Roboters).
Sensorplattform: Um die drei Sensoren in 2D messen zu lassen, musste etwas Drehbares her. Vorteil des Eigenbaus gegenüber einem fertigen Lidar (RPLidar z.B.): Ich kann mehrere Sensoren mit vollständiger 360°.Rundumsicht auf dem Drehteller zusammenstellen, ohne dass sie sich gegenseitig die Sicht einschränken. So misst das LidarLite bei mir in horizontaler Ebene die Umgebung, der VL53L1X, leicht nach unten geneigt, im Nahfeld niedrige Hindernisse unterhalb vom LidarLite. Der TSOP detektiert das Leuchtfeuer der Ladestation.
Brain: Für mich ein Rechner, auf der die GUI-Applikation läuft. Zum Entwickeln ein PC oder Notebook, zum Testen (hinterherdackeln in BT-Reichweite) ein Tablet, on Board ein Banana Pi M2 Zero (Formfaktor Rasperry ZeroW, aber mit Quadcore). Lose angekoppelt über Bluetooth sind die Brains quasi per Knopfdruck austauschbar. Der OnBoard-Brain lässt sich in Wifi-Reichweite per RemoteDesktop oder Browser (NodeJS) bedienen. Die Funktion des "autark fahrens" benötigt diese Verbindung nicht (OnBoard ist die benötigte Reichweite zwischen Brain und Peripherie immer 10cm).
Ende der Modulbeschreibung. Jetzt kommen einige spezielle Anmerkungen:
Zum Vergleich: Im Wiki-Artikel über den RP6 sind im Kapitel Sensorik ALLE Sinne aufgeführt, auch z.B. das Monitoring von Akkuspannung, Odometrie, ... Das betrachte ich nicht so. In modularer Bauweise kann ich mir den Luxus erlauben, die interne Sensorik eines Moduls zu kapseln. Inkrementalgeber an Antriebsrädern werden im DriveModul zur Pose transformiert, AD-Werte im Powermodul werden maximal noch im langsamen Zyklus als Monitoring-Werte zur GUI gereicht. Also: Wenn ich von Sensoren spreche, meine ich die nach extern gerichtete Sensorik mit Hardwarebezug (! Eine Kamera kann man auch noch direkt am Brain anstöpseln).
Der Leim, der die Module zusammenhält, besteht bei mir aus UART-Schnittstellen und einem über alle Ebenen gehenden Protokoll. Alternativ wäre ein Bus (I2C,CAN,...) denkbar, dann aber ist die Schnittstelle zum Brain eine Sonderlocke. So, wie ich es ausgeführt habe, sind die Module auch direkt mit dem Brain kompatibel (ich habe auf den Modulen einfach eine optionale vierpolige Buchsenleiste für einen HC-06-Baustein drauf). Ich kann also unabhängig vom Rest z.B. ein neues Sensorsetup bauen und in der Applikation auch schon Teile testen.
Das verwendete Protokoll basiert auf der Übertragung von strukturbasierten Telegrammen. Bsp:
Code:
typedef struct
{
uint8_t CmdID; //0
double Diameter; //1
double WheelDiameter; //5
double WheelStepsPerRound; //9
double WheelDistance;//13
}__attribute__ ((packed)) PhysicsParams_t;
So etwas (in diesem Fall ein Hilfsparametersatz aus dem EEPROM der Peripherie zur Berechnung der Pose aus den Daten der Inkrementalgeber) lässt sich bei mir vom Sender auf den Schreib-FIFO einer UART legen oder vom Empfänger aus dem Lese-FIFO anhand des CmdID-Feldes identifizieren, casten und weiterverarbeiten.
Durchreiche: Kommt ein Messwerttelegramm von der Sensorplattform zur Peripherie, werden Winkel des Drehtellers und Korrekturparameter (z.B. die Sensorplattform selbst sitzt nicht mittig auf dem Roboter und es müssen X/Y-Offsets aufgeschlagen werden) sowie die aktuelle Pose des Roboters (aus dem DriveModule) ergänzt. Danach wird dieses ergänzte Telegramm zum Brain gesendet. Andere Telegrammtypen können auch einfach durchgereicht werden (z.B. wird die vom Brain versendete Struktur zum Setzen von Ladeparametern uninterpretiert an das Powermodul weitergereicht).
Bezüglich der Applikation auf dem Brain: Das Zauberwort SLAM (Simultaneous Localization And Mapping) lässt sich im Rahmen einer Simulation recht schnell nachvollziehen. Der steinige Weg, eine Hardware dafür zu entwickeln, ist zwar das Ziel, aber kein Garant für den Erfolg. Ich habe mir also die Mühe gemacht, die Aplikation so aufzubauen, dass Experimente in Richtung SLAM aus drei unterschiedlichen "Welten" mit Daten gefüttert werden können:
- Die RealWorld ist die API zur tatsächlichen Hardware. Neben der Schnittstelle zum SLAM-Algorithmus sind hier auch Diagnose- und Parametrierungswerkzeuge in Richtung Hardware implementiert.
- SimulationWord generiert aus Polygondefinitionen eine virtuelle Umgebung und bildet die typischen Bewegungen und Messungen eines einfachen Roboters mit Lidar und Bumpern nach. Messwert- oder Bewegungsfehler können simuliert werden.
- FileRecordWorld spielt in der RealWorld aufgezeichnete Testfahrten ab. Damit werden auch offline Datenanalysen oder Tests möglich.
Ich denke mal, ROS ist ähnlich strukturiert. Im Gegensatz zu ROS ist meine Applikation in C# geschrieben. Vordergründig erst einmal für Windows entwickelt, lässt sich diese GUI unter dem Mono-Framework auch mit Linux verwenden.
Ich hoffe, ich habe meinen Rahmen so zumindest grob, aber vollständig umschrieben. (Ich bin sicher, ich habe zu viel geschrieben!)
Mögen die Spiele nun also beginnen.
Zitieren
Zitat von jmoors
Lesezeichen