Archiv verlassen und diese Seite im Standarddesign anzeigen : Think Modular
Holomino
07.11.2020, 18:58
(Für die, die hier öfter lesen: Ich wurde aufgefordert (https://www.roboternetz.de/community/threads/75392-Zukunft-des-Forums/page9).)
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:
34456
35305
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 (https://rn-wissen.de/wiki/index.php?title=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:
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.
Hallo,
finde ich zunächst mal gut, dass es doch so schnell was geworden ist, dass Du das hier so ausführlich rein setzt!
Also erst mal großes Danke dafür!
Zwar etwas schwer zu verstehen, wenn man nicht in der Materie drin steckt, aber ich kann den Rahmen erkennen.
Ich weiß, dass andere wieder Vorschläge haben (werden).
Ich habe auch meine eigene Vorstellung, wie mein Roboter mal funktionieren soll. Ich gehe dabei sicher ähnlich,
aber wieder anders vor. Mein Gedankengerüst auf dieses Modell zu übertragen, fällt mir eher schwer.
Ich versuche mal ein Brainstorming:
aufkommende Fragen:
- Programmierwerkzeuge und welche Programmierumgebung ist notwendig
- worauf ist die Software lauffähig, benötigte Hardware (Mindestanforderungen)
- wie lässt sich die Software weiter entwickeln
was ich mir vorstellen könnte (Wünsche):
- Softwareausführung möglichst lauffähig auf vielen Geräten (Desktop-Computer, Mikrocomputer, Betriebssystem egal)
- einfach, leicht zu bedienen = kurze Einarbeitungszeit
- benötigte Hardware: alles was gängig ist an AVR bzw. favorisieren würde ich die Arduino-Serie (ab Nanao aufwärts) und die ESP für WIFI
- Programmierungebung wäre hier Arduino - IDE in C++, mit allem, was es dazu gibt und geben wird
Protokolle / Datenverbindungen:
- UART/Serial, I2C
Speicher erweiterbar:
- SD-Karte, Filesystem(?), Speichergröße (ESP)?
- Hardwaremodule?
Anzumerken ist, dass jeder, aufgrund dessen, was er bisher gebaut hat oder noch baut, irgendwie vorbelastet ist.
Deswegen könnten wir jetzt alle unsere Ideen in relativer Kurzform vorbringen? Holmino war nun recht ausführlich, das muss ich nicht noch mal machen,
habe an anderer Stelle schon sehr viel geschrieben, was ich zurzeit mache. Inkas Vorhaben kennen hier eigentlich auch alle.
Vielleicht finden sich noch mehr und wir sammeln, was jedem so einfällt?
Freundlichen Gruß
Ich denke auch schon längere Zeit über einen DIY-Robi nach. Zuerst dachte ich an einen R2D2 ähnlichen Robi, wie im Droidbuilders-Portal ein paar mal beschrieben. Ich hatte mir auch die R2D2s der Astroch-Mechs auf der MakerFair in Dortmind angeschaut und kann dazu nur eins sagen: Respekt! Das sind klasse Show-Roboter für Events, aber nichts für mich, denn ich will eine Art technische Versuchsplattform.
Daraus resultiert Anforderung 1: Das Teil soll eine technische Experimentierplattform sein, d.h. modular erweiterbar. Ich möchte alle möglichen Sensoren darauf montieren können, u.a. auch in einem drehbaren Turm, um zum Beispiel Geräusche mit einem Mikrofon-Array orten zu können
Da wir ein eigenes Haus haben, soll das Teil auch überall hin können. Es muss sich also auch über Treppen fortbewegen können. Deshalb schaue ich mir gerade die openDog V1-Videos von James-Bruton (https://youtu.be/0BoPoWF_FwY). Das Ding ist schon gut gemacht, aber heftig teuer: 12 Motoren á 80€ + 12 Kugelumlaufspindeln á 50 € + 12 Motor-Regler á 40€ + (vermutlich) 500€ für die Profile und Zubehör + ganz viele selbst gedruckte Teile + .... Bevor das Teil vor einem steht, hat man ganz sicherlich irgendwas oberhalb von 3000€ verbraten! Dennoch finde ich das Teil irgendwie cool. Aber mit 6 Beinen würde mir so etaws besser gefallen. Die Größe finde ich aber OK und das Teil ist Mega-Stabil!
Daraus resultiert Anforderung 2: Das Teil soll Treppen auf- und absteigen können. Das ist schon eine heftige Anforderung, auch wegen der Programmierung und Erkennung von Treppen.
Anforderung 3 wurde von Holomino schon genannt: Autarkes operieren.
Anforderung 4: Kommunikation. Der Robi soll mich z.B. per Email oder SMS anfunken, wenn etwas im Haus ist, wie eine Alarmanlage. Bedeutet: Das Teil muss einen WLAN-Adapter haben, denn Robis mit Kabel sind uncool. Der Robi soll auch eine Verbindung ins Internet haben, um mir z.B. Spotify abzuspielen --> Gute Lautsprecher!
Anforderung 5 wurde auch schon von Holomino genannt: Der Robi soll selbst zur Ladestation finden und sich selbst laden, wenn die Batterie leer läuft.
Als Steuerungsplattform habe ich mir einen zentralen RasPi gedacht, der diverse Module (Arduinos, andere RasPis) ansteuert. Jedes Modul (Mikrofon-Array, Kameras, Fortbewegung, etc.) soll seinen eigenen Computer haben.
Als Programmiersprache habe ich mir Python gedacht, da Python einfach, plattformübergreifend und universell ist. Außerdem kann man Java- und C-Libraries einbinden. Im letzten Jahrtausend hatte ich ab und an mal C und viele andere Sprachen programmiert, je nachdem, was gerade angesagt war. Somit stelle ich mir den Einstieg in Python nicht besonders schwer vor. Die Entwicklungsumgebung ist mir egal, solange sie Offline funktioniert und kein Vermögen kostet, am liebsten Open Source, damit ich keine Rücksicht auf irgendwelche Einschränkungen des Herstellers nehmen muss.
Wie denkt ihr darüber?
Gruß, Jürgen
Vielleicht solltest Du Dich mit einem Hexapod-Robotern auseinander setzen? Wenn Dir das andere zu teuer ist, die Zeit zum Bau ist ja auch noch nicht eingerechnet.
Beim Hexapod kommst Du bei 18 Motoren eventuell auf 1000€, wenn Du keine Micro-Servos einsetzt. Um 20cm Stufenhöhe zu schaffen, sollte das Gerät aber auch nicht zu klein sein. Und da kommst Du an den Punkt, dass Du eher einen kleinen Roboter möchtest. Baust Du einen mit Ketten, der eine Treppe rauf fahren kann, muss der auch eine bestimmte Größe haben. Vielleicht ist ein Flugmodell, das auch fährt, dann eher was, um die Baugröße zu reduzieren. Allerdings wirst Du dann auch hier eine gewisse Größe haben müssen, um das Gewicht von wenigstens 2kg bis 3kg zu stemmen.
MfG
White_Fox
08.11.2020, 12:57
Mir fehlt grundsätzlich etwas der rote Faden: Was soll das Konstrukt am Ende -- so in Etwa -- können?
Modularisierung ist schön, gut und hilfreich - keine Frage. Aber da gibt es normalerweise einen sehr eng gesteckten Rahmen.
Es soll beispielsweise am Ende auf jeden Fall ein Auto werden, die Autos sind alle irgendwie ähnlich und unterscheiden sich nur marginal: Alle haben einen Motor, alle haben ein elektronisches Unterhaltungsystem, alle haben vier Räder. Alle haben an jedem Rad eine Bremse, alle werden an derselben Achse angetrieben. Und alle Autos sind normale Straßenautos.
Man kriegt aus diesem Baukastensystem nie und nimmer ein Schiff oder ein Fluggerät zusammengeschraubt. Und auch keinen Panzer. Man kriegt nichtmal ein richtiges Rennauto oder etwas anständig Geländegängiges damit hin.
Modularisierung ist fast immer auch nur dann von Vorteil, wenn man in größeren Stückzahlen baut und entwickelt. Modularisierung bedeutet auch, technisch niemals die Anforderungen zu treffen, sondern durch die Modularisierungsforderung gibt es zusätzlich Einschnitte. Seien es z.B. ungenutzte Leitungen im Kabelbaum, eigentlich falsch gewählte Kommunikationsprotokolle (z.B. CAN für Daten, die eigentlich höhere Echtzeitanforderungen hätten) oder dergleichen.
Für Einzelstücke gibt es da kaum Vorteile. Höchstens, wenn man mehrere hinreichend ähnliche Sachen hin und wieder baut.
Die Frage wäre: Soll es jetzt ein Roboterarm werden, oder doch ein USV? Modularisieren kann man alles, und wenn man es auf Bauteilebene herunterbricht.
Holomino
08.11.2020, 15:18
Wie denkt ihr darüber?
Ich denke, Du solltest mindestens noch einen Arm zum Bedienen von Türklinken einplanen.
Modularisierung bedeutet für mich wieder verwertbare Komponenten zu haben, die ich auf verschiedenen Plattformen einsetzen kann. Z.B. wenn jemand mein Peilturm mit Kameras, Mikrofon-Array, usw., gefällt, setzt er diesen vielleicht auf ein funkferngesteuertes Auto.
Ich verstehe diesen Thread so, dass er die Konstruktion von anderen Threads anstößt, die jeweils ein Modul repräsentieren. Ein Modul kann ein fahrbare Basis auf Rädern, 2-, 4- oder 6 Beinen sein, ein Modul zur Erfassung der radioaktiven Strahlung, usw. Deswegen ist es wichtig, die Komponente von außen steuerbar zu machen, d.h. eine sauber definierte und dokumentierte Schnittstelle zu haben.
Als zentrale Komponente schwebt mir, wie schon oben erwähnt, ein RasPi vor, da es ein ausgewachsener Computer ist. Was geht euch dazu im Kopf herum?
VG, Jürgen
Als zentrale Komponente schwebt mir, wie schon oben erwähnt, ein RasPi vor, da es ein ausgewachsener Computer ist. Was geht euch dazu im Kopf herum?
ich hatte zunächst nur einen atmega 2560 im outdoor drin, der wurde nun zum fahrdienstleiter mit hinderniserkennung "degradiert" und ein zero-w ist erstmal als head vorgesehen...
ansonsten hatte ich bei meinen bisherigen robotern diese funktionen:
- experimentiershield als verdrahtung und anschlussmodul
- US-hinderniserkennung
- IR-linienfolgemodul
- induktive ladevorrintung
- BT-modul zur kommunikation mit der umwelt
- IR-modul zum fernbedienen
- gyro-modul zur positionsbestimmung
die module/sensoren waren eingebaut und funktionierten auch, die weiterentwicklung bzw. verfeinerung der nutzung ist ausgeblieben, weil - das kennt wahrscheinlich jeder hier - was neues gebaut wurde. Also kein spezialist in verwendung dieser module, höchstens "reingerochen" in die verwendeung...
Holomino
08.11.2020, 16:36
Ich verstehe diesen Thread so, dass er die Konstruktion von anderen Threads anstößt, die jeweils ein Modul repräsentieren. Ein Modul kann ein fahrbare Basis auf Rädern, 2-, 4- oder 6 Beinen sein, ein Modul zur Erfassung der radioaktiven Strahlung, usw. Deswegen ist es wichtig, die Komponente von außen steuerbar zu machen, d.h. eine sauber definierte und dokumentierte Schnittstelle zu haben.
Das ist mittlerweile auch so mein Gedanke. Ich habe mich vor zwei Jahren ehrlich gesagt dumm und dusselig nach einer griffigen und vollständigen Lösung für die simple Funktion des automatischen Ladens gesucht. Letztlich habe ich die fünf Versionen bis zum endgültigen Ziel alleine durchgezogen.
Zumindest bei Moppi weiß ich aus einem älteren Thread (https://www.roboternetz.de/community/threads/74272-FET-Schalter), dass er das noch vor sich hat.
Bei anderen weiß ich's nicht, hab's aber auch schon mal (hier (https://www.roboternetz.de/community/threads/73479-Powerweiche) und hier (https://www.roboternetz.de/community/threads/71909-Powerpack-f%C3%BCr-den-Dauereinsatz), und auch der hier (https://www.roboternetz.de/community/threads/73178-Ladekontakte) gehört eigentlich noch dazu) probiert.
Jetzt könnte ich so was mal anstoßen weil ich etwas in den Händen habe.
Gerdchen
08.11.2020, 16:48
Daraus resultiert Anforderung 1: Das Teil soll eine technische Experimentierplattform sein, d.h. modular erweiterbar. Ich möchte alle möglichen Sensoren darauf montieren können, u.a. auch in einem drehbaren Turm, um zum Beispiel Geräusche mit einem Mikrofon-Array orten zu können
Da wir ein eigenes Haus haben, soll das Teil auch überall hin können. Es muss sich also auch über Treppen fortbewegen können.
Daraus resultiert Anforderung 2: Das Teil soll Treppen auf- und absteigen können. Das ist schon eine heftige Anforderung, auch wegen der Programmierung und Erkennung von Treppen.
Wie denkt ihr darüber?
Gruß, Jürgen
Mir gefallen die Konzepte dieser beiden Rover/Roboter, besonders auch wegen der unabhängig verstellbaren Fahrwerksbeine mittels Spindelantrieb. Dadurch könnte sogar eine gewisse Treppensteigfähigkeit erreicht werden. Obendrauf ein Manipulator, oder was anderes. Als technische Experimentierplattform eventuell eine Überlegung wert. Auch der konstruktive Aufwand erscheint machbar.
https://robotik.dfki-bremen.de/uploads/tx_dfkiprojects/Systemblatt_Sherpa_de.pdf
https://robotik.dfki-bremen.de/uploads/tx_dfkiprojects/Systemblatt_SherpaTT_de.pdf
Gerdchen
Ich bin gerade auf Flir.com gestoßen. Da gibt es https://www.flir.com/products/kobra/ Robots mit Kette, die Treppen steigen können. So ein System halte ich für realisierungsfähig, ohne direkt 3000€ für das Fahrgestell zu investieren. Die Ketten und Getriebe wird man sich sicherlich drucken müssen. Wäre doch eine interessante Basis.
Gerdchen
08.11.2020, 19:08
Ich bin gerade auf Flir.com gestoßen. Da gibt es https://www.flir.com/products/kobra/ Robots mit Kette, die Treppen steigen können. So ein System halte ich für realisierungsfähig, ohne direkt 3000€ für das Fahrgestell zu investieren. Die Ketten und Getriebe wird man sich sicherlich drucken müssen. Wäre doch eine interessante Basis.
Tolles Teil. So ein "Kettensystem" ist natürlich äußerst agil und auch einfacher zu realisieren. Kettenantriebe haben allerdings ein Problem, wenn eine Kette versagt, dann
fällt meistens das gesamte System aus. Wenn eine sofortige Instandsetzungsmöglichkeit besteht ist das auch kein Drama. Bei einem Einzelradantrieb kann auch mit nur einem funktionsfähigen Rad noch gefahren werden (bin ein Fan von solchem Raumfahrtkrempel).
Holomino
08.11.2020, 21:11
Man kriegt aus diesem Baukastensystem nie und nimmer ein Schiff oder ein Fluggerät zusammengeschraubt. Und auch keinen Panzer. Man kriegt nichtmal ein richtiges Rennauto oder etwas anständig Geländegängiges damit hin.
Hi White_Fox,
dunnerdieWaldFee, Du schraubst die Messlatte ganz schön hoch. Trotzdem versuche ich's mal:
Alle Plattformen haben als Bewegungsmodul die gemeinsame Eigenschaft, per innerem Regelkreis ihre Positionsänderung grob zu schätzen. Selbst Flugzeuge können das per IMU, Höhen- und Geschwindigkeitsmessung. Grob heißt hier mit Abweichungen, aber relativ schnell.
Wie Du nun über eine höhere Instanz die innere Regelung korrigierst, ist variantenreich: Korrektur über Lidar, Kamera, Radar, GPS oder die Sterne. Du wirst nicht für jede Variation ein neues Bewegungsmodul erfinden wollen.
Meine These: Wenn Du aus der höheren Instanz einer geplanten Bahn folgen willst, reicht eigentlich als Schnittstelle der Befehl MoveRelative(dx,dy,[dz]) und die zyklische Rückmeldung Moved(dx, dy, [dz]) aus dem Bewegungsmodul.
Das geht mit Fahr-/Flug-/Schwimmzeug auch um Kurven. Die Äußere Regelung zieht das Gefährt durch die Korrekturen praktisch wie am Gummiseil auf dem geplanten Pfad hinter sich her.
Erstaunlich dabei: Ein PKW hat nicht die gleichen Freiheitsgrade wie ein Panzer (kann nicht auf der Stelle drehen). Ein Flugzeug kannst Du nicht ohne weiteres auf einen Punkt hinterm Flugzeug lenken (es wird nicht rückwärts fliegen). Trotzdem bleibt die o.g. Schnittstelle zum Bewegungsmodul praktisch gleich. Den Wendekreis von Auto oder Flugzeug kannst Du nur in der höheren Instanz durch Neuplanung der Bahn berücksichtigen, weil nur die (im Gegensatz zum Bewegungsmodul) die Informationen zur Kollisionsvermeidung hat.
Es gibt sicher weitere interessante Aspekte:
Steht jmoors' spekulative Raupe vor der Treppe, wird das dann vom Bewegungsmodul oder von der höheren Instanz erkannt? Gibt die höhere Instanz also 2D-Befehle und die Raupe gibt alles, um die Treppe selbständig hochzumöllern? Oder gibt die Instanz den Befehl in 3D und das Bewegungsmodul hebt darauf brav entsprechend der Angabe der z-Komponente das vordere Kettenpaar?
Wenn ich einen Roboterarm auf einem Differentialantrieb montiere, nutze ich die Drehachse des Bewegungsmoduls? Wenn ja, wie drehe ich dann über MoveRelative(dx,dy,[dz])? Statt rauszufahren und wieder im richtigen Winkel einzuparken, wäre hier ein Turn(angle) sicher komfortabler.
Letztlich nur die Frage: Kann Dein Roboterfahrgestell das oder kannst Du Dir vorstellen, Deinem Roboter diese Schnittstelle beizubringen, so dass ich mein Programm und meine Sensorik draufbauen kann?
Holomino
10.11.2020, 20:22
So, nach 48h sacken lassen und meinem letzten Beitrag an WhiteFox mal hier die Frage in die Runde: Seht Ihr weitere Bezüge zwischen den Einzelteilen eines Roboters? Was wäre z.B. an Infos zwischen Akku und Navigation sinnvoll? Hat hier schon jemand z.B. die Restreichweite seines Akkus ermittelt und so das Ansteuern der Ladestation mit eingeplant? Was braucht man dafür?
Hier würde ich auch gerne 2 Cent reinwerfen:
Damit werden auch offline Datenanalysen oder Tests möglich.
Ich denke mal, ROS ist ähnlich strukturiert.
Ja. ROS hat mit rosbag (http://wiki.ros.org/rosbag) eine Bibliothek um alle Nachrichten in dem von ROS verwendeten publish/subscribe-System aufzuzeichnen und wieder abzuspielen. Mit Gazebo (http://gazebosim.org/) steht ein umfangreicher Simulator zur Verfügung. Warum man das allerdings alles nachprogrammieren möchte, ist mir immer noch unverständlich. Glücklicherweise muss ich es nicht verstehen ;)
Ich möchte alle möglichen Sensoren darauf montieren können, u.a. auch in einem drehbaren Turm, um zum Beispiel Geräusche mit einem Mikrofon-Array orten zu können
Wieso man ein Mikrofon Array auf einem drehbaren Turm montieren möchte, verstehe ich auch nicht. Gängige Module (https://wiki.seeedstudio.com/ReSpeaker_Mic_Array_v2.0/) sind darauf jedenfalls nicht angewiesen.
Da wir ein eigenes Haus haben, soll das Teil auch überall hin können.
Hast du es mal mit einem Roboter je Stockwerk versucht?
Anforderung 3 wurde von Holomino schon genannt: Autarkes operieren.
Da bin ich wieder bei ROS
Anforderung 4: Kommunikation. Der Robi soll mich z.B. per Email oder SMS anfunken, wenn etwas im Haus ist, wie eine Alarmanlage. Bedeutet: Das Teil muss einen WLAN-Adapter haben, denn Robis mit Kabel sind uncool. Der Robi soll auch eine Verbindung ins Internet haben, um mir z.B. Spotify abzuspielen --> Gute Lautsprecher!
Sollte im Jahr 2020 mit Raspbbery Pis oder ESP32 alles keine Herausforderung sein.
Anforderung 5 wurde auch schon von Holomino genannt: Der Robi soll selbst zur Ladestation finden und sich selbst laden, wenn die Batterie leer läuft.
Ladestation finden ist abgedeckt durch #3 Autarkes operieren. Zum Laden braucht es auch nur noch zwei Kontakte und einen Lade-IC.
Mir fehlt grundsätzlich etwas der rote Faden: Was soll das Konstrukt am Ende -- so in Etwa -- können?
Für mich der wichtigste Satz. Die Zielgruppe fehlt mir allerdings auch.
Holomino
10.11.2020, 21:02
Warum man das allerdings alles nachprogrammieren möchte, ist mir immer noch unverständlich. Glücklicherweise muss ich es nicht verstehen ;)
Kannst Du auch nicht.
Simulator und Teile der Navigation sind so alt, dass es ROS noch nicht gab. Tatsächlich war ich da im Jahr 2000 etwas früh dran.
Es hat lange rumgelegen (sauber abgehangen), weil es bezüglich Sensorik und Hardware kaum praktische Möglichkeiten der Umsetzung gab, aber mittlerweile verwende ich es wieder gerne (man kann so schön die Fehler von früher und heute vergleichen)
Sieh es einfach als Alternativmodul.
So, nach 48h sacken lassen und meinem letzten Beitrag an WhiteFox mal hier die Frage in die Runde: Seht Ihr weitere Bezüge zwischen den Einzelteilen eines Roboters? Was wäre z.B. an Infos zwischen Akku und Navigation sinnvoll? Hat hier schon jemand z.B. die Restreichweite seines Akkus ermittelt und so das Ansteuern der Ladestation mit eingeplant? Was braucht man dafür?
akkuspannung
stromverbrauch
position von der ladestation
point of break :)
und ein wenig mathematik
Hat hier schon jemand z.B. die Restreichweite seines Akkus ermittelt und so das Ansteuern der Ladestation mit eingeplant? Was braucht man dafür?
Holomino? Du musst doch wissen, wann der Akku so weit leer ist, dass Du noch sicher die Ladestation erreichen kannst, wie machst Du das denn jetzt?
MfG
"Holomino? Du musst doch wissen, wann der Akku so weit leer ist, dass Du noch sicher die Ladestation erreichen kannst, wie machst Du das denn jetzt?"
Das kann man über die Akkuspannung messen. Das machen Ladegeräte auch so. Sie bestimmen über die Spannung den Ladezustand des Akkus.
"Zitat von jmoors Beitrag: "Da wir ein eigenes Haus haben, soll das Teil auch überall hin können." Hast du es mal mit einem Roboter je Stockwerk versucht?"
Nein, das möchte ich nicht. Ein Robi reicht aus. Das ist auch eine Kostensache. Ich möchte nicht 3000€ für zwei Robis ausgeben. Meine Flugzeuge sind schon teuer genug.
Holomino
11.11.2020, 09:00
akkuspannung
stromverbrauch
position von der ladestation
point of break :)
und ein wenig mathematik
Ist das bei Dir noch Theorie oder bereits durchgeführte Praxis?
Wenn's schon Praxis ist: Wie schätzt Du mit Akkualterung oder unterschiedlichen Temperaturen/Entladeströmen die Restkapazität, wenn Du wegen des autarken Betriebs den Akku niemals vollständig entladen kannst?
Das kann man über die Akkuspannung messen. Das machen Ladegeräte auch so. Sie bestimmen über die Spannung den Ladezustand des Akkus.
Ich lasse mich da sehr gerne belehren aber ich kenne kein Ladegerät, dass mir beim Ladestart sagt, welchen SOC meine Li-Akkus in % haben. (https://www.elektroniknet.de/power/energiespeicher/ladezustand-von-akkus-bestimmen.823.html)
Ist das bei Dir noch Theorie oder bereits durchgeführte Praxis?
Wenn's schon Praxis ist: Wie schätzt Du mit Akkualterung oder unterschiedlichen Temperaturen/Entladeströmen die Restkapazität, wenn Du wegen des autarken Betriebs den Akku niemals vollständig entladen kannst?
Ich lasse mich da sehr gerne belehren aber ich kenne kein Ladegerät, dass mir beim Ladestart sagt, welchen SOC meine Li-Akkus in % haben.
ich gebe offen zu meine theorie, aber ich muss es demnächst auch angehen. da sind viele schätzfaktoren drin, man muss immer reserven einplanen.
ich verwende blei oder nimh akkus zur zeit noch, die lipo sind schick aber für die ladestation zu kompliziert, es sei denn du verwendest nur ein zelle.
ich gebe offen zu meine theorie, aber ich muss es demnächst auch angehen. da sind viele schätzfaktoren drin, man muss immer reserven einplanen.
ich verwende blei oder nimh akkus zur zeit noch, die lipo sind schick aber für die ladestation zu kompliziert, es sei denn du verwendest nur ein zelle.
vielleicht zu blauäugig, aber ich sehe das nicht sooo kritisch. Seit 2008 verwende ich NiMh akkus, die werden induktiv ständig auf dem schreibtisch geladen - wie ein smartphone. Nicht optimal, aber wirksam und relativ einfach, so eine ladestation...
beim outdoor habe ich das erst mal lipo, da verlasse ich mich auf die akkuhersteller (ja, die chinesen) und darauf, dass das ladegerät - eigentlich ein simples steckernetzteil mit 12V== und 1A - das tut, was es soll. Stationär erstmal. Induktiv will ich es ähnlich machen wie vorher die NiMh akkus...
und - ich habe ein e-auto bestellt. Da hat man mir gleich gesagt, verabschieden Sie sich von den begriffen "leer" und "voll". Das ist verbrenner geschichte. Immer laden, wenn eine ladestation greifbar und Sie eine halbe stunde zeit haben...
vielleicht zu blauäugig, aber ich sehe das nicht sooo kritisch. Seit 2008 verwende ich NiMh akkus, die werden induktiv ständig auf dem schreibtisch geladen - wie ein smartphone. Nicht optimal, aber wirksam und relativ einfach, so eine ladestation...
beim outdoor habe ich das erst mal lipo, da verlasse ich mich auf die akkuhersteller (ja, die chinesen) und darauf, dass das ladegerät - eigentlich ein simples steckernetzteil mit 12V== und 1A - das tut, was es soll. Stationär erstmal. Induktiv will ich es ähnlich machen wie vorher die NiMh akkus...
und - ich habe ein e-auto bestellt. Da hat man mir gleich gesagt, verabschieden Sie sich von den begriffen "leer" und "voll". Das ist verbrenner geschichte. Immer laden, wenn eine ladestation greifbar und Sie eine halbe stunde zeit haben...
was nimmst du zum induktiven laden würde mich mal interessieren, macht das ganze etwas einfacher, einfach auf die ladestation fahren und einschalten :)
was nimmst du zum induktiven laden würde mich mal interessieren, macht das ganze etwas einfacher, einfach auf die ladestation fahren und einschalten :)
versuchs mal damit (https://rn-wissen.de/wiki/index.php/Induktive_Ladestation_f%c3%bcr_den_RP6) :-)
"Holomino? Du musst doch wissen, wann der Akku so weit leer ist, dass Du noch sicher die Ladestation erreichen kannst, wie machst Du das denn jetzt?"
Das kann man über die Akkuspannung messen. Das machen Ladegeräte auch so. Sie bestimmen über die Spannung den Ladezustand des Akkus.
Tatsächlich war meine Frage an Holomino gerichtet, um zu erfahren, wie er das zurzeit macht. Ohne mit irgendwelchen Ideen vorpreschen zu wollen. Ich verstehe das auch nicht so recht, ich kann mir nicht vorstellen, dass er fährt, ohne die Akkuspannung zu messen. Holomino, magst Du es beantworten?
MfG
Sollte man solche Fragen nicht in andere Threads auslagern? Hier Teilprobleme zu besprechen macht das ganze irgendwie unübersichtlich.
Holomino
11.11.2020, 18:33
Sollte man solche Fragen nicht in andere Threads auslagern? Hier Teilprobleme zu besprechen macht das ganze irgendwie unübersichtlich.
Bevor ich einen Thread à la "Think modular - Versorgung ohne Sorgen" eröffne, würde ich hier doch gerne noch erfahren, was Du (und andere) so an Plänen oder Realisierungen zu diesem Thema am Start hast (haben). Das respektvolle Gegenüberstellen der Lösungen können wir dann ja im neuen Thread machen.
Moppi: Details klären wir dann im neuen Thread, ok?
Bevor wir jetzt das Rad neu erfinden, so oder so ähnlich wird es jeder machen: Berechnung Akku Laufzeit (https://www.haushalts-robotic.de/blog-wissen/allgemein/akkupacks-zusammengesetzt/)
Davon ausgehend kann jeder das finden, was er benötigt. Interessant ist, die verbrauchte Energie jederzeit auf eine bestimmte Strecke auszurechnen.
Man könnte eine Art Standardverbrauch, auf diese bestimmte Strecke, ansetzen. Man kann pro Elektronikbaustein und Aktor einen Verbrauchswert ermitteln und hinterlegen. Je nachdem, was an Elektronik dann zugeschaltet ist und welche Aktoren aktiv sind (und wie lange) könnte der Energiebedarf ganz gut berechnet werden, denke ich. Das Problem wird dann das Auffinden der Ladestation, dazu muss man immer wissen wo die sich befindet und wie weit weg sie sich befindet. Oder es ist bekannt, dass die Ladestation in einer bestimmten Zeit auf jeden Fall gefunden wird (in einer Wohnung gibt es ja so weite Strecken nicht). Dann ermitteln, wie lange der Roboter mit welchem Energieverbrauch unterwegs sein kann, bis die Akkuspannung eine festgelegte untere Grenze erreicht. Dann müsste man alles haben, um die Unbekannten berechnen zu können. Außerdem könnte man ermitteln, welche Elektronischen Teile oder Aktoren aktiv sein können, um die Ladestation noch zu erreichen. Einberechnen müsste man wohl auch immer eine Reserve.
Gruß
Gerdchen
11.11.2020, 20:14
Eventuell wäre zum Akkuladen auch eine Konstruktion wie bei Oberleitungen mit Schleifkontakten und gespanntem Draht denkbar. Da könnte der Robi dann seitlich, oder wie auch immer ranfahren. Das würde auch die Positionierung vereinfachen, braucht nicht so exakt sein wie bei kleineren Kontakten. Edelstahldraht und kupferhaltige Kohlebürsten könnten eine denkbare Materialpaarung sein.
Oder die Kohlen sind federnd gelagert und das Gegenstück starr.
Gerdchen
Holomino
12.11.2020, 11:09
Sehr schön, die Ideen fließen ja. Bei den konkreten Realisierungen ist's noch nicht so prall, aber das kommt bestimmt noch.
Nichtsdestotrotz, nächstes Rätsel: Reflexe.
An Fahrzeuge baut man Bumper oder Whisker, vielleicht auch nach unten gerichtete Treppenabsturzsensoren. Ähnliche Mimiken (Drucksensoren, künstliche Haut) sind bei "Gliederfüßlern" denkbar. Allen gemeinsam: Sie lösen Reflexe im Bewegungsmodul aus. Stößt sich der Roboter das Schienbein, muss er mindestens anhalten oder sich sogar befreien, damit folgende Bewegungsanweisungen überhaupt ausführbar sind.
Wo also bauen wir die Reflexsensoren hin? Ins Sensormodul? Oder ins Bewegungsmodul?
Auch hier wieder: Bereits vorhandene Realisierungen, Ideen und respektvolle Diskussion - alles erwünscht.
Meine Meinung:
Ich habe ein quadratisches Kettenmodul, dass sich nach einer Kollision erst freifahren muss, um danach z.B. auf der Stelle wenden zu können. Bumper o.Ä. habe ich nicht, aber ich habe zwei zusätzliche Messräder mit Inkrementalgebern am Roboter, mit denen ich unabhängig vom Schlupf der Ketten die Odometrie mache.
Ob die Ketten nun vor der Wand durchdrehen oder blockieren ist egal, Kollisionen sehe ich daran, dass bei aufgedrehter Motorregelung keine Bewegung an den Messrädern erkannt wird.
Im Diskussionsansatz mit White_Fox hatte ich's ja schon angedeutet. Odometrie als innerer Regelkreis ist Sache des Bewegungsmodus. Insofern war es für mich auch keine Frage, in welches Modul die Reflexe zu implementieren sind.
Sehr schön, die Ideen fließen ja.
Schön! Nicht? Und Dein Vorschlag dazu?
MfG
Holomino
12.11.2020, 11:55
Mein Vorschlag: Wir kauen hier ganz simpel weiter Module und Schnittstellen anhand bereits realisierter Lösungen und zukünftigen Anforderungen (Ideen) durch. Der Ton ist respektvoll, also ist alles im grünen Bereich.
Ich sehe in meinem Job als TO auch nicht mehr, als ab und zu mal einen neuen Schnipsel einzuwerfen. Die Entscheidung, das Konzept zu prüfen und vielleicht etwas draus zu machen, liegt bei Euch.
Ach, ich war schon verwundert! :)
Hmm ... weiß nicht. Ich hatte schon begonnen, mir Gedanken zu machen. Ich dachte schon dieser Beitrag (https://www.roboternetz.de/community/threads/75423-Think-Modular?p=662425&viewfull=1#post662425) sei weg. Dazu gab es keinen Anschluss. Ich fände es dann nicht schlecht, auf die einzelnen Dinge auch einzugehen.
MfG
-----------------
etwas ab vom Thema:
Ich habe mir die Struktur hier noch mal angesehen und mit dem verglichen, was schon geschrieben wurde.
Es gibt das Forum: Tausche Dich aus und suche Unterstützung für deine Projekte!
Es gibt das Wiki: Lass dein Wissen und deine Schaltungen auch anderen zukommen.
Es gibt Mikrocontroller-Elektronik: Frei verfügbare Projekte, Schaltpläne, Stücklisten unter einer CC-Lizenz.
Ich versuche mich danach zu richten. Schaue aber auch, was sich woanders noch für Möglichkeiten auftun.
Holomino
12.11.2020, 13:53
Ach, ich war schon verwundert! :)
Hmm ... weiß nicht. Ich hatte schon begonnen, mir Gedanken zu machen. Ich dachte schon dieser Beitrag (https://www.roboternetz.de/community/threads/75423-Think-Modular?p=662425&viewfull=1#post662425) sei weg. Dazu gab es keinen Anschluss. Ich fände es dann nicht schlecht, auf die einzelnen Dinge auch einzugehen.
Den Teil mit den Programmierwerkzeugen/-sprachen mag ich Dir gerne kommentieren:
Wenn ich ein LidarLite einsetze, habe ich keine Ahnung vom internen Ablauf in FPGA und Controller. Nach außen bildet es eine Schnittstelle.
Wenn Du von mir ein Platinenlayout und ein HEX-File zum brennen des Controllers bekommst, kann es Dir egal sein, ob ich das Programm in C, C++, Basic oder Assembler geschrieben habe, solange Du Deine Anforderungen vollständig erfüllt siehst. I2C/UART oder andere Protokolle sprechen keine Programmiersprache. Sie sprechen Bytesch.
Dieser Thread bietet Dir in erster Linie die Möglichkeit, selber Anforderungen zu definieren, mit den Anforderungen anderer zu vergleichen, zu Strukturieren, Gemeinsamkeiten zu finden und Hürden zu überbrücken.
Eine Hürde ist die Programmiersprache. Eine mögliche Brücke ist eine Schnittstelle.
das hier
https://youtu.be/dAIdv0qamD8 (https://youtu.be/dAIdv0qamD8)
ist z.b. - zumindest würde ich es als ein modul bezeichnen - welches aus meiner RP6 ära stammt. Es diente der hindernisüberwachung und der suche nach der ladestation (in dem Aluröhrchen ist ein standard TSOP-IR empfänger). Es kann auch auf dem servo hin und her bewegt werden. Damit war es z.b. alleine mit dem IR-sensor möglich auf 5m entfernung die richtung zur ladestation zu finden...
wenn jemand tiefer einsteigen möchte (https://rn-wissen.de/wiki/index.php?title=IR-bake_f%C3%BCr_den_RP6) ...
@Holomino
Ich denke, eine Zeichnung/Verdrahtungsplan, wie man was anschließt (Fritzing?), miteinander vebindet, sagt mehr als viel Geschriebenes. Ich habe Schwierigkeiten mich rein zu denken und ich glaube, dass mir noch Informationen fehlen, um das richtig zu erfassen. So ein Verdrahtungsplan wäre gut.
Aus dem Plan geht dann hervor, wie die Hardware beschaffen sein muss, um Deine Lösung einzubinden. Wie die Software auf das Gerät kommt, ist dann erst mal Nebensache. Als Erstes würde mich dann zunächst so ein Plan mit den Mindestanforderungen interessieren (also mindestens ein Mega..., mindestens das ... beides ist dann über diese und diese Pins so und so verbunden, Sensoren oder Aktoren werden an den und den Pins angeschlossen, welche Schnittstellen werden verwendet - digitale Pins oder RX/TX oder ...).
Jetzt ist mir noch was zur Software eingefallen, als ich drüber nach dachte. Die nächste Frage für mich wäre, welche Schnittstellen gibt es. Gibt es ein API, wenn, mit welchen Funktionen (Beschreibung). Daraus kann ich mir ein Bild machen, in welchem Umfang sich die Software nutzen lässt. Vielleicht stand es schon irgendwo, dann konnte ich es noch nicht richtig erfassen.
Um etwas rein zu kommen, hier von mir eine allgemeine Übersetzung der Struktur, der Datenblöcke, die übertragen werden sollen:
Offset 0: (1 Byte) CmdID
Offset 1: (4 Byte) Diameter
Offset 5: (4 Byte) WheelDiameter
Offset 9: (4 Byte) WheelStepsPerRound
Offset 13: (4 Byte) WheelDistance
Nächste Frage dazu gleich: Warum immer 4 Byte? Ich hatte jetzt erst auf 2 Byte getippt, deswegen hatte ich es eben etwas falsch, weil ich dachte Werte von 0 bis 65535 müssten ausreichend sein?
MfG
Holomino
13.11.2020, 13:56
Bezüglich der Datenstruktur:
Als Europäer habe ich mein System (hier Fahrzeugdurchmesser, Radabstand, Raddurchmesser, an anderer Stelle Sensorauflösungen, ...) auf mm parametriert. Es könnten aber auch inch oder cm sein. Letztlich wichtig. Größen und resultierende Posenberechnungen (https://www.heise.de/ct/artikel/Wo-bin-ich-290526.html)sind aufgrund der unterschiedlichen Einheitengenauigkeit (Den Radabstand nur in ganzzahligen inch angeben zu können, schränkt die Freiheiten ein) Fließkomma.
Sicher nicht ganz offensichtlich, dass bei der Anzahl der Inkremente pro Umdrehung (WheelStepsPerRound) ein Inkrementalgeber mit 50 Steps/Round direkt am Motor mit anschließendem Getriebe 13:25 eben kein ganzzahliges Verhältnis ergibt. Also auch hier eine Fließkommaangabe.
Letztendlich die Frage: Macht das die Schnittstelle nicht unnötig fett? (White_Fox)
Meine Antwort: Bei mir nicht. Trotzdem das Bewegungsmodul bei mir gleichzeitig noch Durchreiche für Sensorik und Powermodul ist, also 4..6kB/s an Daten emittiert und 2..3kB/s eingehende Daten verarbeitet, langweilt sich mein Controller bei 60% Prozessorlast. Auch deshalb baue ich modular.
Holomino
14.11.2020, 10:34
Ist schon Advent? Darf ich schon "Zeit für ein neues Türchen" sagen?
Das Settings-Türchen
Gut, dass Moppi auf diese Struktur zurückgekommen ist. Sie wird vom Bewegungsmodul zur Posenberechnung verwendet. Vielleicht kann man sie als Betriebsparameter bezeichnen. Ähnliche Dinge sind bei mir Regelparameter für Antriebsmotoren, Kalibrierungsdaten im Powermodul, Einstellungen für den Lidarbetrieb,...
Kurz: Alles Parameter, die für die Inbetriebnahme eines Moduls wichtig sind und bei mir im EEPROM des jeweiligen Controller landen.
Frage: Was hat das aber mit dem modularen Aufbau zu tun? Die o.g. Struktur kann man doch im Hexapoden nicht anwenden?!
Antwort: Kann man nicht. Wenn ich von jemand anderem ein Bewegungsmodul verwenden will, benötige ich eine allgemeingültige Bewegungsmodulschnittstelle, in der unter Anderem auch die Bahnverfolgungsfunktion sitzt und zusätzlich eine Schnittstelle zum parametrieren des spezifischen Moduls.
Diese Unterteilung bezogen z.B. auf mein Powermodul:
Allgemein:
- Wir hatten weiter oben gesagt, eine Nachricht über den SOC ist allgemein wichtig, um die Restreichweite einbeziehen zu können.
- Rückmeldung "an Ladestation angedockt"
- Der Befehl Laden ein-/ausschalten
- Befehl "ganzes Teil abschalten" (z.B. für den Transport)
Spezifisch bei mir:
- Monitoring
- Ladeparameter
- Kalibrierungsdaten
- Andock- und Abschalteinstellungen
35310
So sehen die spezifischen Einstellungen bei mir in der GUI aus. Das ist C#, also für den einen oder anderen hier eine Hürde. Das Protokoll dahinter ist Bytesch (Binärprotokoll über UART). Das sollte jede Programmiersprache und jede Hardwareplattform können. Damit fällt diese Hürde (hoffentlich).
Frage: Was hat das aber mit dem modularen Aufbau zu tun? Die o.g. Struktur kann man doch im Hexapoden nicht anwenden?!
Antwort: Kann man nicht. Wenn ich von jemand anderem ein Bewegungsmodul verwenden will, benötige ich eine allgemeingültige Bewegungsmodulschnittstelle, in der unter Anderem auch die Bahnverfolgungsfunktion sitzt und zusätzlich eine Schnittstelle zum parametrieren des spezifischen Moduls.
Dafür muss man einen passenden Wrapper haben. Vom Prinzip wird jeder Roboter irgendwie in die vier Himmelsrichtungen gesteuert. Dann kommt vielleicht noch "oben" und "unten" dazu, falls man das benötigt (der Roboter kann Hindernisse ja auch selber überwinden). Also bräuchte man einen teilautonomen Roboter, der dann noch Anweisungen benötigt, welche Richtung er wie weit gehen soll. Einfach ausgedrückt.
(Binärprotokoll über UART). Das sollte jede Programmiersprache und jede Hardwareplattform können. Damit fällt diese Hürde (hoffentlich).
Wenn die Datenpakte entsprechend beschrieben sind. Ich kenne das nur als Tabelle, zum Beispiel bei WAV-Dateien oder Byteblöcke, die an einen bestimmten Port übertragen werden müssen (Soundkarte). Und darin wird eben immer für jeden Parameter angegeben der Offset in den Daten, die Datengröße (Byte, Word etc.) und die Beschreibung, zum einzelnen Parameter. Das ist dann allgemein gülig. Wie man das dann in Assembler oder in C++ erstellt (früher auch viel Pascal), ist eine andere Frage.
MfG
Gerdchen
14.11.2020, 16:21
Dafür muss man einen passenden Wrapper haben. Vom Prinzip wird jeder Roboter irgendwie in die vier Himmelsrichtungen gesteuert. Dann kommt vielleicht noch "oben" und "unten" dazu, falls man das benötigt (der Roboter kann Hindernisse ja auch selber überwinden). Also bräuchte man einen teilautonomen Roboter, der dann noch Anweisungen benötigt, welche Richtung er wie weit gehen soll. Einfach ausgedrückt.
MfG
Ich verstehe das so.
So ähnlich, wie beim Fly-by-Wire. Da wird dem Flieger ja auch nur gesagt, wo er langfliegen soll. Wie er das macht und auf Störungen reagiert ist dann Sache der dahintersteckenden Technik.
Holomino
15.11.2020, 00:12
Zusammenfassung bis hierher:
- Ein Modul hat eine bytebasierte Schnittstelle und ist programmiersprachenunabhängig.
- Ein Modul muss unterschiedliche Datenblöcke (Telegramme) empfangen und versenden können. Inhalte und Länge eines "Telegramms" sind telegrammtypbezogen.
- Deshalb muss man ein Telegramm identifizieren können. Eine Kennung (CmdID) muss her.
Für Menschen, die noch nie eine Vernetzung zwischen zwei Controllern (oder Controller und PC) praktisch aufgebaut haben (das ist keine Bildungslücke, viele angewendete Protokolle schmeißen unvollständige Daten einfach weg, ohne den Grund zu nennen. Als Anwender hat man von XML bis Binär nur selten die Gelegenheit, in den APIs die Parse-Bedingungen nachzuvollziehen). Es gibt zusätzliche Anforderungen:
- Übertragbarkeit: Kann ich ein Protokoll zwischen zwei Controllern auswerten? Kann ich das auch z.B. zwischen Controller und PC?
- Störsicherheit: Was passiert bei einer Störung? Was passiert, wenn z.B. ein Sender sendet. während ich den Empfänger flashe oder neu starte? Wie synchronisiert sich ein Empfänger nach einer Störung anhand des Protokollrahmens neu?
Finger hoch: Wer hat so ein Protokoll? Wie sieht der Rahmen aus? Synchronisiert sich das Protokoll nach einer Störung automatisch?
Finger hoch: Wer hat so ein Protokoll?
Darf ich die offensichtliche Antwort verlinken? (https://design.ros2.org/articles/ros_middleware_interface.html)
Bevor ich einen Thread à la "Think modular - Versorgung ohne Sorgen" eröffne, würde ich hier doch gerne noch erfahren, was Du (und andere) so an Plänen oder Realisierungen zu diesem Thema am Start hast (haben).
Meine Lösung ist relativ simple gehalten und hier (https://www.roboternetz.de/community/threads/70677-Wild-Thumper-ROS-Roboter/page3?p=662568&viewfull=1#post662568) beschrieben. Ist etwas von meinem Staubsaugerroboter abgeguckt.
Übertragbarkeit: Kann ich ein Protokoll zwischen zwei Controllern auswerten? Kann ich das auch z.B. zwischen Controller und PC?
Hierzu kommt mir sofort in den Sinn, Datenblöcke so einfach wie möglich zu gestalten, auch so, dass sie schnell verarbeitet werden können.
Hierzu zähle ich persönlich auch die Datentyp-Größe in Bit. 4 Byte große Fließkommawerte sind schon gewaltig. Ich handhabe das immer so, dass ich schaue, was wirklich benötigt wird (vielleicht noch etwas Reserve). Ein Controller, der einen Schrittmotor ansteuert oder einen Servo, benötigt kein Fließkomma. Das muss erst umgerechnet werden. Das wiederum kostet nicht nur Rechenzeit, sondern am Ende auch Energie. Solche Operationen sollten nur ein Mal an zentraler Stelle, erledigt werden. Bei Universaldaten, wo man nicht sicher ist, ob der Empfänger vielleicht doch zunächst mit Nachkomma arbeitet, ist die Frage immer, wieviele Nachkommastellen sind nötig um ein Ergebnis zu bekommen, dass genau genug ist. Heißt: wenn am Ende eine Nachkommastelle genügen würde, um ein Ergebnis zu bekommen, was genau genug ist (weil ich eine Motorsteuerung doch irgendwo nur mit Werten von 0 bis 255 füttere), warum soll ich dann mehr schicken? I.R. genügen 2 oder 3 Nachkommastellen. Bei 2 Byte / 16 Bit, kann ich Werte von -32767 bis +32767 abbilden. Das könnten auch sein: 3.2767, 32.767, 327.67, 3276.7 Bei 3 Byte sind das -8388607 bis + 8388607 (8.388607 bis 838860.7; bei 3 Nachkommastellen: +/-8388.607). Wie die Werte zu interpretieren wären, hängt dann von der Block-ID (CmdID) ab. So kann man auch unterschiedliche Datentypgrößen, für unterschiedliche Zwecke, verwenden. Ich will nur meine Sicht darstellen, vielleicht lohnt es sich drüber nachzudenken, ich will nicht nörgeln.
Störsicherheit: Was passiert bei einer Störung? Was passiert, wenn z.B. ein Sender sendet. während ich den Empfänger flashe oder neu starte? Wie synchronisiert sich ein Empfänger nach einer Störung anhand des Protokollrahmens neu?
Als Grundlage vielleicht: http://152.96.52.69/webMathematica/canum/bronstein2008/kap_5/node183.html
Als Protokollrahmen nehme ich mal die Hardwarekommunikation (per serieller Schnittstelle oder I2C z.b.). Bei Sender und Empfänger verwende ich bisher immer einen Timeout. Ist vielleicht nicht unbedingt die zeitsparendste Variante, aber wenn keine Fehler bei der Übertragung auftreten sollten, durchaus rel. einfach umzusetzen: wenn eine Seite mit der Kommunikation nicht klar kommt, wartet die dann einfach eine bestimmte Zeit, bis die Gegenseite in einen definierten Zustand zurück fällt. Die Kommunikation kann dann neu begonnen werden.
Wer hat so ein Protokoll?
So weit ich das bei meinen Anwendungen sehe, ist dass immer von der jeweiligen Schnittstelle abhängig und wie dann die Kommunikation aufgebaut ist, also individuell.
Ich komme hier mit den Begriffen "Protokoll" und "Protokollrahmen" noch nicht zurecht. Universalprotokolle und -protokollrahmen kenne ich (auf Hardwareebene) nicht, das sind ja dann irgendwie immer Wrapper, die zusätzliche Rechenzeit benötigen. Wrapper auf niedrigen Ebenen führen zu erhöhten Hardwareanforderungen (schnellere CPUs, mehr Speicher, mehr Energiebedarf = "größere" Akkus und / oder geringere Laufzeit, bis zum Nachladen des Hauptenergiespeichers)
Bei dem oben verlinkten Text zu "ROS" steht es so ähnlich auch drin:
"Er skizziert die angestrebten Anwendungsfälle sowie deren Anforderungen und Einschränkungen. Darauf aufbauend wird die entwickelte Middleware-Schnittstelle erläutert."
MfG
Holomino
15.11.2020, 17:32
Darf ich die offensichtliche Antwort verlinken? (https://design.ros2.org/articles/ros_middleware_interface.html)
Natürlich darfst Du das. Und Du darfst auch weiterhin die Vorteile bezüglich ROS lobpreisen.
Der Link löst aber mein Problem nicht. Ich halte ein Stück selbstgebaute Hardware mit UART in der Hand. Da muss ich mich entscheiden, welchen Protokollrahmen ich verwende. Nehme ich vielleicht z.B. sowas (https://www.robotshop.com/media/files/content/y/ydl/pdf/ydlidar-x2-360-laser-scanner-datasheet.pdf) (Seite 2)?
Synchronisiert sich dieses Protokoll bei Störungen? Ich sitze hier im Graben und fummel am Code meines Moduls rum. Ich progge den Controller ab und zu neu. Das unterbricht zwar die Daten, aber die Verbindung nicht. Ich hab auch keine Lust, nach jedem Neuproggen die Gegenstelle zu rebooten. Da muss also (auf beiden Seiten) was her, was unterbrochene Telegramme wegschmeißt. Je schlanker, desto besser. Meine Ressourcen auf dem Controller sind begrenzt.
Das mit dem "darf" war jetzt nicht so wörtlich gemeint. Ich habe nur das Gefühl ich gehe euch ein wenig damit auf die Nerven.
Der Link löst aber mein Problem nicht. Ich halte ein Stück selbstgebaute Hardware mit UART in der Hand.
ok, klingt nach einem Job für rosserial (Nur ROS1) (http://wiki.ros.org/rosserial). Wobei ich selber allerdings ein eigenes einfaches i2c-Protokoll zur Kommunikation mit meinem µC verwende. Der Neustart der ROS-Node die die I2C-Hardware an das ROS-Ecosystem anbindet muss ich dann zwar manuell neustarten, aber das stört mich nicht hinreichend genug um das zu ändern. Geht ja auch hinreichend schnell, da alle anderen Nodes weiter laufen können. Theoretisch könnte ich auch einen automatischen Restart bei Bus-Fehlern einbauen..
Mir persönlich war rosserial zuviel Overhead zum Einsatz auf einem 8-Bitter.
Der Vollständigkeit halber: Bei ROS2 wurde rosserial durch micro-ROS (https://micro-ros.github.io/) abgelöst. Das braucht aber wohl "größere" µC wie einen ESP32. Ich denke nicht, dass es auf einem AVR lauffähig ist. Ich habe keine Erfahrungen mit micro-ROS.
Update: Hier gibt es was mit micro-ROS auf Arduino: https://discourse.ros.org/t/micro-ros-on-arduino/17009
Wenn Du eine Hardware hast und nach Protokolllösungen suchst, habe ich hier was gefunden (https://sbc-support.com/uploads/tx_srcproducts/26-794_DE_Handbuch_Serial_Communication_xx7.pdf). Die Blockdiagramme enthalten auch den Fall des Abbruchs. Es gibt immer zwei Möglichkeiten: das Protokoll wird nicht eingehalten (es gibt eine Zeitüberschreitung, weil Verbindung getrennt -> Timeout -> Abbruch) und die übertragenen Daten stimmen nicht (Prüfsumme einführen CRC bspw.) -> dann werden die gesendeten Daten, i.R. ein ganzes Datenpaket (s. Protokollrahmen), verworfen/ignoriert und das letzte Datenpaket nochmals angefordert. Dafür brauchst Du mindestens eine Paketnummer und, im Falle der Überprüfung, eine Prüfsumme, die enthalten sein müssen. Außerdem muss der Empfänger mitteilen können, ob das letzte Paket i.O. war. Dafür kann man eine extra Datenleitung verwenden, entweder für Sender und Empfänger eine oder eine gemeinsame Leitung; im Protokoll muss dann festgelegt sein, wann wer von beiden diese Leitung nutzt, den/einen Status mitzuteilen (weil einer muss den Leitungszustand auswerten und einer setzen). Andere Möglichkeit, wenn das Paket nicht i.O. war: der Empfänger tut so, als ob die Leitung unterbochen wurde, es wird dann dieses Prozedere ausgeführt.
MfG
Holomino
16.11.2020, 14:22
Das mit dem "darf" war jetzt nicht so wörtlich gemeint. Ich habe nur das Gefühl ich gehe euch ein wenig damit auf die Nerven.
Eigentlich nicht. Solange wir hier ROS als eine Alternative aus mehreren Möglichkeiten behandeln können, kann ich vergleichen und Dir Löcher in den Bauch fragen.
Apropos Löcher:
Im Nachbarthread hattest Du beschrieben, dass auch Du Spannung und Strom vom Akku misst. Magst Du vielleicht einmal beschreiben, wie bei Dir in ROS der Weg dieser Werte bis in die Oberfläche aussieht (Messaufbau brauchste nicht zu beschreiben, aber so ab dem Teil, ab dem die Werte an irgendeinem AD-Wandlerpin landen)?
...
Naja, so richtig auf der Suche bin ich nicht. Ich dachte nur, es kommen schon praktische Implementierungen von Euch, bevor ich die von mir angewendete Lösung vorstelle.
Wenn ich Nachrichten übertragen oder lesen will, möchte ich dies möglichst benutzerfreundlich in meinem Code gestalten.
Anwendungsspezifisch schreibe ich z.B. eine Struktur von Typ DUMMY auf die UART:
//Anywhere from header
#define MagicID_DummyTelegram 0x42
typedef struct
{
uint8_t CmdID; //0
uint8_t Mode; //1
uint16_t Val; //2
}__attribute__ ((packed)) Dummy_t; //Length 4 Byte
//Anywhere in declaration
Dummy_t dummy;
//Anywhere in code
dummy.CmdID = MagicID_DummyTelegram;
dummy.Mode = 0x80;
Dummy.Val = 0xEEFF;
SendTelegram((uint8_t*) &dummy, sizeof(dummy));
Auf dem Empfängercontroller könnte die Empfangsroutine so aussehen
//Anywhere from header
#define MagicID_DummyTelegram 0x42
typedef struct
{
uint8_t CmdID; //0
uint8_t Mode; //1
uint16_t Val; //2
}__attribute__ ((packed)) Dummy_t; //Length 4 Byte
//Anywhere in code
void TelegramReceived(uint8_t *data, uint8_t len)
{
switch (data[0]) // get CmdID
{
case MagicID_DummyTelegram:
{
Dummy_t* dummy = (Dummy_t*) &data[0]; //Cast
if (dummy->Mode == 0x80) //and do something
SetLEDBrightness(dummy->Val);
}
break;
case AnotherMagicID:
.
.
.
}
}
Ein mögliches Protokoll dazu:
- Ein Telegramm beginnt mit einem Startbyte (0xFF)
- Ist ein Byte in den Telegrammdaten gleich dem Startbyte, wird es doppelt gesendet
- Ohne Kenntnis über Länge und Bedeutung des Telegrammes benötigt die Empfangsroutine eine Längenangabe.
Über den Draht gehen aus dem obigen Beispiel also:
0xFF (Startbyte)
0x04 (Strukturlänge)
0x42, 0x80, 0xEE, 0xFF, 0xFF (Strukturinhalt, Beachte: 1. Element ist die CmdID, 0xFF in den Strukturwerten wird doppelt gesendet)
Genauere Implementierungsdetails (was bei mir bezüglich FIFO und Parsen zwischen den Endpunkten SendTelegram und TelegramReceived liegt) findet Ihr z.B. im VL53L1X-Thread...
Controller: 34152
PC: 34153
...wobei mich aus meiner beschränkten Sicht heraus z.B. der Vergleich und die Kompatibilität zu ROS, Arduinoprogrammierung oder BASCOM interessieren würde.
Naja, so richtig auf der Suche bin ich nicht. Ich dachte nur, es kommen schon praktische Implementierungen von Euch, bevor ich die von mir angewendete Lösung vorstelle.
Das geht eben nicht immer bei Dir hervor, da tappt man etwas im Dunkeln. Du formulierst immer so, als ob Du generelle Fragen hast.
Was mich angeht, so verwende ich I2C und serielle Schnittstelle über UART, am ATmega328P-PU und nodeMCU. Alles, was man dort benötigt, sind die Bibliotheken für diese Schnittstellen, um das Protokoll muss man sich weitestgehend nicht selber kümmern. Ansonsten hätte ich noch eine parallele Übertragung, vor allem als Versuch, soll aber auch funktionieren (die verfügbaren Pins gaben das so her), dafür ist kein UART notwendig. Dort steht das Protokoll aber auch fest, als Programmablauf. Ich verwende dazu 3 Datenleitungen und für jeden angebundenen µC zwei Kontrollleitungen (eine führt von einem µC zum andern, und eine andere zurück), jeder µC kontrolliert seine eigene Leitung (Status f. Empfang, senden...). Sollte ein Datenpakettransfer fehlschlagen, bricht der Empfänger nach einer Weile ab, dann ist der Fertig. Wenn der Sender bemerkt, dass der Empfänger nicht antwortet, bricht der auch ab. Beim nächsten Schleifendurchlauf ist der Datenblock nicht versendet und wird daher nochmals übertragen. Das Spiel wiederholt sich dann so oft, bis die Daten übertragen werden konnten, oder bis der Akku leer / die Elektronik kaputt ist.
Du hast aber eine andre Lösung für Dich gefunden, wäre Zufall, wenn das einer schon mal so gemacht hätte und daher fertige Protokolle, Software und Datenpaket-Beschreibungen parat hat.
Was ganz einfaches und aber sicheres (halbiert die Datenübertragungsrate), habe ich mal für sie Serielle Datenübertragung gemacht. Findet man in meinem Fotoalbum, als Flußdiagramme/PAP. (https://www.roboternetz.de/community/album.php?albumid=150) Kann man rein schauen, aber das ist sicher nicht, was Du suchst(?).
Im Übrigen fände ich PAPs besser. Ist nicht auf eine Programmiersprache fixiert. Erreicht man meist eine breitere Masse an Leuten.
MfG
Holomino
16.11.2020, 15:48
Natürlich frage ich zuerst ganz unvoreingenommen. Ich bin nicht der brennende Busch. Meine Lösung ist erst einmal nur eine unter vielen.
Wenn Du schreibst, Du verwendest Bibliotheken: Ich kenne Arduinos nur sehr oberflächlich, praktisch gar nicht. Ich kann mir die Serial.h anschauen und daraus erahnen, dass da wohl ein FIFO verwendet wird. Die textuelle Übertragung einer Konsolenausgabe habe ich auch schon mal als Codebrocken gesehen. Aber wo muss ich suchen, wenn ich eine vollasynchrone Datenübertragung zwischen zwei Arduinos (beide Teilnehmer blasen sich ohne Softwarehandshake gegenseitig mit Daten zu. Jede Seite kann die unterschiedlichen Nachrichten im empfangenen Datenstream aufbröseln. Das Aufbröseln darf bei einer Störung Daten verlieren, aber nicht ins Stocken geraten) haben will?
Gibt's da fertige Libs? Wenn ja, welche? Wie fix sind die? Was geht über den Draht? Kann ich das Protokoll mit BASCOM o.ä. nachprogrammieren?
Einen PAP zu zeichnen wäre obsolet, wenn sich ein Arduinofreak einmal den Code anschaut und die Übersetzbarkeit prüft. Wenn das hier keiner machen will, bestell ich mir so'n Teil und mache es selber - kann ja wohl nicht so schwierig sein.
Im Nachbarthread hattest Du beschrieben, dass auch Du Spannung und Strom vom Akku misst. Magst Du vielleicht einmal beschreiben, wie bei Dir in ROS der Weg dieser Werte bis in die Oberfläche aussieht (Messaufbau brauchste nicht zu beschreiben, aber so ab dem Teil, ab dem die Werte an irgendeinem AD-Wandlerpin landen)?
Spannung & Strom werden von einem A/D-Pin eines AVR gemessen, dort in Volt & Ampere umgerechnet und per I2C an den Einplatinencomputer gegeben. Die ROS-Node holt diese Information aus den entsprechenden I2C-Registern ab. Hier ist der Quellcode für die Implementierung in C (https://defiant.homedns.org/gitweb/?p=ros_wild_thumper.git;a=blob;f=src/wt_node.cpp;h=e8303a6e53e803f35ad1f87294c1863db307 3581;hb=HEAD#l331) und Python (https://defiant.homedns.org/gitweb/?p=ros_wild_thumper.git;a=blob;f=scripts/wt_node.py;h=bffabce5d178bb9fec2954587565c3363fa2f ea3;hb=HEAD#l174). Der ROS-Welt werden die Werte einmal als diagnostics (http://nlamprian.me/blog/software/ros/2018/03/21/ros-diagnostics/) und einmal als BatteryState (http://docs.ros.org/en/melodic/api/sensor_msgs/html/msg/BatteryState.html)-Message zur Verfügung gestellt. Letztere lässt sich überall abfragen, z.B. in einem Terminal:
user@wildthumper:~> rostopic echo -n 1 battery/voltage
11.470000267
---
oder grafisch mit Tools wie PlotJuggler (https://github.com/facontidavide/PlotJuggler). Bei mir allerdings meistens im Browser (http://robotwebtools.org/), vor allem wenn ich nur kurz den aktuellen Wert lesen möchte.
zum einbinden in den Arduino-Quelltext braucht man:
#include "serial.h"
zur Initalisierung der seriellen Schnittstelle:
Serial.begin(bps);
hier ein anderes Beispiel: https://www.arduino.cc/reference/en/language/functions/communication/serial/begin/
Zum Schicken von Daten, Serial.write() oder Serial.print(). Zum Empfangen Serial.read(). So weit mir bekannt, kann jeder Teilnehmer jederzeit senden und jederzeit empfangen.
Man kann noch eine Funktion angeben, die dann aufgerufen wird, wenn Daten eingetroffen sind (wenn man nicht dauernd nachschauen will).
Wenn die Funktion dann aufgerufen ist, macht man nichts anderes, als Serial.available() - ob und wieviele Daten verfügbar sind - und dann liest man die.
Ich nutze die Sachen auch nur, muss ich nicht alles selber programmieren. Ist der Vorteil daran.
Wie schnell so ein Datenaustausch am Ende ist, teste ich, wenn ich es wissen will, im Programm selber. Beim Hexapod war es schnell genug, um flüssige Bewegungen hervorzubringen, trotz zwischendurch Positionsdatenblöcke für bis zu 3 oder 4 Beine am Stück übermittelt wurden. Also für etwa 9 Servos. Vielleicht auch mal mehr. Kann ich jetzt aber nicht mehr überprüfen, weil das Gerät demontiert ist.
Ob wir hier echte Arduino-Freaks haben?
MfG
--------------------------------------
Nachtrag 27.11.2020:
Das mit der "serial.h" will ich so nicht stehen lassen, weil es offenbar nicht richtig ist. Heute bin ich dazu gekommen, dies direkt auszubrobieren. Wie ich da auch "serial.h" kam? - Weiß ich auch nicht mehr. Wenn ich es benötige, füge ich persönlich "HardwareSerial.h" per #include hinzu. Da ich gerade jetzt damit zu tun habe, hier nur die Richtigstellung.
Holomino
17.11.2020, 14:22
Spannung & Strom werden von einem A/D-Pin eines AVR gemessen, dort in Volt & Ampere umgerechnet und per I2C an den Einplatinencomputer gegeben. Die ROS-Node holt diese Information aus den entsprechenden I2C-Registern ab. Hier ist der Quellcode für die Implementierung in C (https://defiant.homedns.org/gitweb/?p=ros_wild_thumper.git;a=blob;f=src/wt_node.cpp;h=e8303a6e53e803f35ad1f87294c1863db307 3581;hb=HEAD#l331) und Python (https://defiant.homedns.org/gitweb/?p=ros_wild_thumper.git;a=blob;f=scripts/wt_node.py;h=bffabce5d178bb9fec2954587565c3363fa2f ea3;hb=HEAD#l174). Der ROS-Welt werden die Werte einmal als diagnostics (http://nlamprian.me/blog/software/ros/2018/03/21/ros-diagnostics/) und einmal als BatteryState (http://docs.ros.org/en/melodic/api/sensor_msgs/html/msg/BatteryState.html)-Message zur Verfügung gestellt.
Super, ich kann kein ROS, Du hast keine Lösung für Lithium-Zellen. Abgesehen davon, dass wir weder über Ströme, Spannungen noch Stecker gesprochen haben:
Sieht auf der Softwareseite fast schon so kompatibel aus, als ob ich Dir eine Mitschnittdatei aus meinem Projekt schicken könnte, wo Du Dir in ROS die Telegramme auseinander fummelst und die entsprechenden Nodes meines Powermoduls anbindest.
Es wurde ja auch viel entwickelt um ROS unabhängig von einer spezifischen Hardware zu bekommen. Ich könnte zumindest unterstützen, wenn du für deinen Roboter eine ROS-Anbindung haben möchtest. Allerdings wären die Spannungs- und Stromwerte nicht meine oberste Priorität, sondern der Antrieb.
Abgesehen davon, dass wir weder über Ströme, Spannungen noch Stecker gesprochen haben
Ja, sollte zuerst gemacht werden. Software lässt sich viel leichter ändern und an verschiedene Gegebenheiten anpassen als Hardware.
Rabenauge
17.11.2020, 21:13
Als Freak würde ich mich nicht gerade bezeichnen, aber ich mach viel mit der seriellen Schnittstelle (die ist einfach praktisch).
Zuerst @Moppi: du musst die serial.h nicht extra einbinden.
Das macht die IDE sowieso.
Wichtig ist nur, diese Schnittstelle auch zu starten:
Serial.begin(115200);
Tipp: wie hoch man hier mit der Baudrate wirklich gehen kann, einfach ausprobieren, das geht oft noch deutlich höher, wenn mans eilig hat)
Teilweise muss man aber auch mal runter gehen, beispielsweise, wenn man BT-Module dazwischen hat, und der Empfang nich mehr so gut ist.
Und: man kann diese Kommunikation auch wieder beenden mit
Serial.end();
Das macht beispielsweise dann Sinn, wenn man die Pins gleichzeitig für _irgendwas_ anderes benutzen will.
Ja- das geht auch asynchron.
Beide Teilnehmer haben einen (in der Grösse definierbaren) Empfangspuffer. Dort landet das, was die Gegenstelle spricht, erstmal ohne weiter beachtet zu werden. Man muss halt aufpassen, dass dieser Puffer nicht überlaufen kann, daher auch die Möglichkeit, den grössenmässig zu definieren.
Wenn der Empfänger dann Zeit hat, kann er nachsehen, ob da was ist und was...
Eine "Rückkopplung" gibt es nicht- der Sender kann senden, was und wie oft er will- er weiss _nicht_, ob es auch ankommt!
Das kann man aber natürlich in Software lösen, wenn man beide Leitungen benutzt.
Dadurch kriegt man die ganze Sache eigentlich so robust, wie man sie haben will.
Man kann das auch abspecken- wenn der Empfänger _nur_ Empfänger zu sein braucht (weil er nix zu melden hat) kann man eine der Leitungen auch weglassen.
Das funktioniert, hat aber den Nachteil, dass man eben keine Sicherheit hat, dass auch alles richtig angekommen ist.
Manchmal braucht man die aber auch nicht.
Im Grunde kann man damit sogar mehrere Rechenknechte kommunizieren lassen (nur nich jeden beliebig mit jedem).
R1 kriegt eine Strippe an Tx, die führt zu Rx an R2. Der bekommt nun eine an Tx, die zu Rx an R3 führt...und so weiter.
Da keiner der Rechner weiss, mit was er da eigentlich redet, funktioniert das tadellos- man könnte nun noch R3 mit R1 verbinden und schon weiss R1, ob seine Kommandos wirklich befolgt wurde...
Abenteuerlich, aber das geht.
Auch möglich: ein Sender gibt Befehle an _mehrere_ Empfänger.
Die kann man einfach alle mit ihrem Rx an den TX des Masters hängen.
Logischerweise kriegen die alle dann das Gleiche....dort könnte man, wenn man Feedback will, auch noch Kommandos einbauen, bei denen der Master den Slaves sagt, von wem er eine Antwort wünscht- man muss halt sicherstellen, dass alle anderen dann die Klappe halten.
Hier kann man sich lustige Protokolle basteln...
Aufpassen muss man aber bei vielen Arduinos doch etwas: die serielle Schnittstelle (man kann die auch in Software nachbilden, das funktioniert...manchmal..auch) wird zugleich zum programmieren benutzt.
Viele Arduinos (Uno, Nano, ProMini...) haben aber nur die eine- man sollte also ein anderes Gerät, was da dann im Betrieb dran hängt, zum schweigen bringen, ehe man versucht, ihn zu programmieren.
Es reicht, wenn man die Leitung, die zu Rx geht, unterbricht.
Die Tx muss nur raus, wenn das dort dran hängende Gerät nicht "mithören" darf (Arduino sendet auch beim programmieren was retour, damit der Rechner, von dem aus er programmiert wird, weiss, dass es klappt).
Es geht auch, wenn das angeschlossene Gerät einfach die paar Sekunden die Klappe hält- weil die Dinger eben _nicht_ unterscheiden können, woher das Gesabbel eigentlich kommt.
Schöner ist hier der Mega2560- der hat drei der Dinger in Hardware.
Da kann man recht sorglos basteln...
Hift das weiter?
Zuerst @Moppi: du musst die serial.h nicht extra einbinden.
Das macht die IDE sowieso.
Bitte beachte die Fragestellung zuvor! Sinngemäß: wo finde ich den Code dafür, welche Datei?
MfG
PS: Bin heute etwas empfindlich dahingehend. Habe ein MRT an die Uniklinik geschickt, zum Termin in der Orthopädie, was ich bekommen habe ist ein ein Chirurg, der Einzelheiten der MRT nicht erläutern konnte, weil nicht sein Fachgebiet. Weiß nicht, ob das gerade gesellschaftlich in Mode ist, einfach mal irgendwas zu machen, anstatt das Richtige? Jetzt fange ich noch mal von vorne an, wieder neuer Termin... usw. Vielleicht können wir hier wenigsten auf so "unbedeutende Kleinigkeiten" achten?
--------------------------------------
Nachtrag 27.11.2020:
Das mit der "serial.h" will ich so nicht stehen lassen, weil es offenbar nicht richtig ist. Heute bin ich dazu gekommen, dies direkt auszubrobieren. Wie ich da auch "serial.h" kam? - Weiß ich auch nicht mehr. Wenn ich es benötige, füge ich persönlich "HardwareSerial.h" per #include hinzu. Da ich gerade jetzt damit zu tun habe, hier nur die Richtigstellung.
Letzter Punkt dazu:
Die IDE bindet nicht zwangsläufig eine "serial.h" oder richtiger die "HardwareSerial.h" ein. Oder anders ausgedrückt: "Serial" ist nicht zwangsläufig vorhanden, also nicht immer im aktuellen Scope deklariert. Es gibt Ausnahmen. Und weil ich es gerade in der Mache habe, hier ein Beispiel, wie das z.B. in der der Arduino-IDE ausschaut, wenn es eben nicht vorhanden (eingebunden) ist:
xFunktion.cpp:7: error: 'Serial' was not declared in this scope
Serial.println("funktion 1");
^
Wie kann man das Lösen? Zum Beispiel so:
#include <HardwareSerial.h>
extern HardwareSerial Serial;
Holomino
18.11.2020, 11:59
..., sondern der Antrieb.
Ein bisschen spooky (für mich):
Ich nehme mal an, dass SetVelocity(1, PI/2) aus Deinen Quellen (https://defiant.homedns.org/gitweb/?p=ros_wild_thumper.git;a=blob;f=src/wt_node.cpp;h=e8303a6e53e803f35ad1f87294c1863db307 3581;hb=HEAD#l331) den Robbi einen Kreis fahren lässt?
Ist das (http://docs.ros.org/en/melodic/api/geometry_msgs/html/msg/Twist.html) die einzige Möglichkeit in ROS, die Bewegung zu steuern? Ober gibt's für Omniwheels, Synchrodrive und Spinnen noch andere Bewegungsanweisungen?
Ja, wobei 1m/s translation und 90°/s rotation schon sehr schnell ist. Ich fahre normal eher mit 20-50cm/s und 20°-60°/s.
Holomino
18.11.2020, 12:34
Ist denn dann z.B. das Bremsen vor einer Kurve beim Folgen eines Pfades Bestandteil des Pathfinders (oder Pathfollowers)?
Bei dem base_local_planner (http://wiki.ros.org/base_local_planner?distro=noetic) den ich verwende nicht. Es gibt noch diverse andere Planner, die man stattdessen verwenden kann. Ob einer von denen vor der Kurve bremst kann ich nicht sagen - hatte das Problem noch nicht. Es gibt aber die max Beschleunigung für Translation und Rotation, d.h. der Planner wird kein Kommando von 0°/s auf 90°/s absetzen, sondern die Geschwindigkeit Schrittweise erhöhen.
Holomino
18.11.2020, 13:28
Hmm, ich kann mir schwer vorstellen, einer Spinne, die sich über Hindernisse tastet, Geschwindigkeitsvorgaben zu machen. Ebensowenig kann ich mir vorstellen, einem Synchrodrive mit dAngle/s das seitwärts losfahren beizubringen.
Kann es sein, dass z.B. mit https://wiki.ros.org/follow_waypoints auch die Interpolation des Pfades über die Angabe von Zwischenpunkten (-posen) möglich ist? (Die könnten Spinne oder Synchrodrive-Roboter ja zumindest linear ansteuern).
Du kennst doch die min. und max. Geschwindigkeiten deines Laufroboters. Wenn dieser sich nur mit max. 10cm/s vortasten kann, dann ist das genau die Geschwindigkeit, die dem Localplanner vorgegeben wird. Die vom Localplanner vorgegebene Geschwindigkeit wird natürlich irgendwo von der Hardware abstrahiert, d.h. bei deinem Synchrodrive muss irgendwo ein Stück Software sitzen das sagt "Drehe Räder um seitlich zu fahren".
Nein, follow_waypoints kannte ich noch nicht, aber von der Beschreibung her wird nur eine Liste der Wegpunkte abgearbeitet:
- move_base ist der Zustandsautomat der versucht immer _genau eine_ Position anzufahren, z.B. einen Punkt in der Küche, der Roboter steht aber gerade im Wohnzimmer und ich muss mehrere Hindernisse umfahren um dahinzukommen.
- Der Globalplanner berechnet anhand der globalen Hinderniskarte (global costmap, die komplette bekannte Karte) dann mit einem A*-Algorithmus einen Pfad vom Wohnzimmer zur Küche
- Der Localplanner nimmt den Pfad des Global planners und ermittelt anhand der lokalen Hinderniskarte (local costmap, bei mir eine Fläche von 3x3m, enthält von den Sensoren erfasste und nicht auf der Karte vorhandene Hindernisse) die Geschwindigkeiten die der Roboter jetzt zu fahren hat.
- Will man den Roboter jetzt ein Viereck patrouillieren lassen hat man vier Punkte die nacheinander abzufahren sind, das ist dann der Job von follow_waypoints. Man hat dann aber keine Kontrolle über Zwischenpunkte, sofern man sie nicht als Ziel vorgibt.
Holomino
18.11.2020, 15:20
Noch mal für die ältere Generation (mich):
Mein Bewegungsmodul hat als Befehl DriveToPoint(dx,dy). Wie es dabei Richtungswechsel, Strecke, Anfahren und Bremsen als fließende Bewegung löst, ist in der Regelung (im Controller) verknüpft.
Beim Pfadverfolgen zieht mein Pathfollower (extern, nicht im Controller, aber über eine Schnittstelle angebunden) durch die laufende Angabe von Punkten das Bewegungsmodul praktisch wie an einem Gummiband hinter sich her. Kommt der Roboter dem aktuellen Zielpunkt näher, entspannt sich das Gummiband und das Teil wird aufgrund der geringeren Regelabweichung langsamer. Also generiert mein Pathfollower sinnigerweise auf Geraden große dx/dy (er zieht am Gummiband) und lässt den Roboter beim Umfahren von Hindernissen an den Pfadecken die dx/dy Werte solange anstehen, bis der Roboter am Knick angekommen ist (das Gummiband entspannt sich).
Nu die Frage: Was müsste ich in ROS für diesen Befehl verwenden?
Dein Bewegungsmodul ist relativ weit oben in der SW-Architektur nehme ich mal an? DriveToPoint(dx,dy) ist im Prinzip genau das, was move_base macht, siehe auch http://wiki.ros.org/navigation/Tutorials/RobotSetup.
Um mit dem ROS-Navigation Stack kompatibel zu sein muss deine Hardware
1. die Geschwindigkeitsbefehle verarbeiten können. Wenn der Localplanner sagt "fahr mit 1m/s vorwärts" oder "rotiere mit 30°/s" dann soll die Roboter-Hardware dies auch möglichst exakt ausführen.
2. Feedback als Odometry (aktuelle Position und Geschwindigkeit) geben
Das mit dem Gummiband habe ich ehrlich gesagt noch nicht ganz verstanden, aber es klingt ein wenig wie teb_local_planner (http://wiki.ros.org/teb_local_planner).
Update: Geht es darum, dass der Roboter sanft anfahren und bremsen soll?
Holomino
19.11.2020, 16:17
Dein Bewegungsmodul ist relativ weit oben in der SW-Architektur nehme ich mal an? DriveToPoint(dx,dy) ist im Prinzip genau das, was move_base macht, siehe auch http://wiki.ros.org/navigation/Tutorials/RobotSetup.
Wenn Du unter Wikipedia nach Kaskadenregelung (https://de.wikipedia.org/wiki/Kaskadenregelung) schaust, ist die Angabe von Geschwindigkeiten aus ROS praktisch der grüne Block in der Zeichnung (die Drehzahl- oder Geschwindigkeitsregelung). DriveToPoint ist der blaue Block, also der Lageregler.
Wenn Du jetzt mit dem Roboter einen Pfad um Hindernisse abfährst, oder eine CNC-Fräse schnurrt die Kontur eines Werkstückes ab: Beides basiert auf dem sequentiellen Abfahren einzelner Punkte (dem Übergeben von Zielpunkten an den Lageregler). Das kann auch unter ROS nicht anders sein.
Wo genau befindet sich in ROS der blaue Block der Lageregelung?
Und wie wird dieser Block auf unterschiedliche Bewegungsmodelle angepasst? Omniwheels und Synchrodrive kann man die y-Komponente der Translationsgeschwindigkeit übergeben. Bei Auto mit Lenkung oder Differentialantrieb ist das schwierig. Die können nicht schräg fahren.
- - - Aktualisiert - - -
Kann es sein, dass die Daten für die Lageregelung in ROS in global_plan/local_plan von base_local_planner sitzen (http://docs.ros.org/en/api/nav_msgs/html/msg/Path.html) und man sich auch daran mit der Hardware anbinden kann? Oder sind das nur geloggte Daten?
Der "blaue Block" ist am ehesten der Local Planner. Er ist dafür da, dem Pfad des global Planners zu folgen, hat aber dabei einige Freiheiten um Hindernissen auszuweichen oder Unzulänglichkeiten (z.B. kein seitwärts oder rückwärtsfahren) der Hardware auszugleichen.
Ob eine Bewegung in der Y-Achse möglich ist macht beim base_local_planner (http://wiki.ros.org/base_local_planner) der Parameter "holonomic_robot". Ackermann kann der base_local_planner nicht, dafür ist dann der teb besser geeignet.
-
Nein, deine Hardware hat mit dem Pfad nichts zu tun, die soll nur die aktuelle Geschwindigkeit des local planners ausführen. Der local planner folgt wiederum dem Pfad (dein Link) den der global planner berechnet hat.
Holomino
20.11.2020, 13:06
Nein, deine Hardware hat mit dem Pfad nichts zu tun, die soll nur die aktuelle Geschwindigkeit des local planners ausführen.
Bleibt mir also nur festzustellen, das ROS mit eigenständig lagegeregelten Fahrgestellen nicht kann.
Ist mir zwar völlig unklar, warum ich das zyklische Ausregeln der Lagedifferenz zu einem Bahnpunkt auf nem Linux vornehmen soll, aber ich habe ROS ja auch nie angewendet.
Letztlich auch kein Problem, wenn man in der allgemeinen Schnittstelle zu einem Bewegungsmodul zusätzlich zur DriveToPoint(dx,dy) noch entsprechend der ROS-Spec ein DriveSpeed(translate, rotate) einbaut (Ist nicht unüblich, die Lageregelung in der Schnittstelle überbrückbar zu gestalten, z.B. Servo Controller (http://elm-chan.org/works/smc/report_e.html)). Dann kann das Bewegungsmodul auch ROS.
Kleine Korrektur: ROS selbst dürfte alles können, nur das Navigation Stack kann eventuell nicht, was du möchtest. Ist mir allerdings auch nicht klar, wieso man das Anfahren einer Position seinem Fahrkontroller überlassen möchte, dieser hat zumindest bei mir keine Sensorinformationen. Warum du das auf alle "eigenständig lagegeregelten Fahrgestelle" verallgemeinerst ist mir auch nicht klar, https://robots.ros.org/category/ground/ hat jedenfalls Roboter dieser Kategorie, z.B. Seekur.
Zum Thema Linux: ROS 1 & 2 sollen angeblich auch unter Windows laufen.
Holomino
21.11.2020, 16:21
Nein, deine Hardware hat mit dem Pfad nichts zu tun, die soll nur die aktuelle Geschwindigkeit des local planners ausführen.
Warum du das auf alle "eigenständig lagegeregelten Fahrgestelle" verallgemeinerst ist mir auch nicht klar, https://robots.ros.org/category/ground/ hat jedenfalls Roboter dieser Kategorie, z.B. Seekur.
Du solltest Dich nun einmal entscheiden.
Beim Seekur steht auch nur "velocity control and position integration". (position integration != position control ?!)
Du solltest Dich nun einmal entscheiden.
Ich kann dir gerade nicht folgen, wobei nicht entscheiden?
Seekur: Ich habe keine Ahnung was die Marketing-Abteilung von denen damit sagen will. Aber "velocity control" wär ja was ich oben sagte, das man für die Odometrie-Position die velocity aufintegriert macht man doch immer so?
Holomino
21.11.2020, 18:55
..., das man für die Odometrie-Position die velocity aufintegriert macht man doch immer so?
Würdest Du mit Inkrementalgebern an den Rädern die Position anhand der Geschwindigkeiten aufintegrieren?
Ja stimmt, war nur etwas verwirrt weil ich in einem Roboter einen ESC habe von dem ich nur die Geschwindigkeit auslesen kann.
Holomino
22.11.2020, 16:35
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
27.11.2020, 11:27
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?
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. (https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.22.4097&rep=rep1&type=pdf) 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 (http://wiki.ros.org/depthimage_to_laserscan). 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
30.11.2020, 09:00
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
03.12.2020, 15:20
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.
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
07.12.2020, 15:38
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?
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...
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.
Wie soll das gehen? Versuchst du ohne Karte von Ost-Frankfurt in eine bestimmte Straße in West-Frankfurt zu fahren?
nein, er fährt von einem bestimmten punkt in der wohnung in der strasse in der ich wohne und orientiert sich anhand empfangener signale der ladestation. Fährt los, sucht die station, ladet, wenn nötig und fährt einfach im raum weiter....
Ich schätze wir reden hier in verschiedenen sphären, Ihr seid schon in Frankfurt, ich in meiner wohnung...
Dann lass mich das umformulieren. Ich dachte in Deutschland kommen Autovergleiche gut an, hab mich wohl geirrt. Beispiel:
- Deine Ladestation steht im Wohnzimmer
- Dein Roboter ist im Wohnzimmer
- Dazwischen ist Sofa, der direkte Weg der Signale der Ladestation sind deswegen geblockt.
Frage: Wie findet dein Roboter die Ladestation?
im auto nutzt man einen navi :-)
ich habe zwei baken. Eine direkt an der ladestation, eine zweite an einer anderen (zur ersten wand 90° versetzt) wand, die funkt in einer anderen frequenz.
Nur zum verständnis: das ganze liegt jetzt ca. 5 jahre zurück. Ich habe mich damals, beim RP6, mit dem thema baken etwas intensiver auseinander gesetzt. Die sind inzwischen eingemottet, bin inzwischen umgezogen, also weiss ich nur, dass es damals ging, kann es jetzt aber nicht wiederholen...
Holomino
07.12.2020, 17:52
Wie soll das gehen? Versuchst du ohne Karte von Ost-Frankfurt in eine bestimmte Straße in West-Frankfurt zu fahren?
Na, "irgendwann" wird man da wohl auch ankommen. Ob man es dann merkt, ist eine andere Frage.
ich habe zwei baken. Eine direkt an der ladestation, eine zweite an einer anderen (zur ersten wand 90° versetzt) wand, die funkt in einer anderen frequenz.
eine andere möglichkeit gibt es noch (erlebt beim staubsaugerroboter) :
- "sorry- ich weiss nicht wo ich bin"... oder - häufiger
- "kann leider die ladestation nicht finden, bitte stellen Sie den roboter an einen anderen ort und versuchen Sie es erneut"...
da ist es mit den zwei baken doch noch komfortabler - und autonomer...
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ß
Holomino
08.12.2020, 14:42
Die sind inzwischen eingemottet, bin inzwischen umgezogen, also weiss ich nur, dass es damals ging, kann es jetzt aber nicht wiederholen...
Das ist Schade. Kannst Du denn hier etwas mehr über die Technik (Funk/IR, Frequenz, Reichweite, Peilwinkelgenauigkeit) erläutern?
Weil mir war noch was zu dem späteren "herunterstrippen" eingefallen: ich denke dieser Ansatz sitzt am falschen Ende.
Ich kann es nur aus meiner Sichtweise erläutern: Nachdem ich im Simulator eine befriedigende Lösung gefunden hatte, habe ich mir überhaupt erst die Mühe gemacht, eine Hardware dafür zu finden.
Selbst mit dieser Vorgehensweise liegen noch viele Irrwege und produzierter Schrott bis zum ultimativen Gerät vor Dir, das alle Fallstricke Deiner Wohnung oder Deines Gartens umschifft.
Unter dem modularen Aspekt spricht auch nichts dagegen, sich zuerst ein Fahrgestell mit einfachen Hindernisdetektoren zu bauen oder zu kaufen und es auf Herz und Nieren in der eigenen Umgebung per zufälliger Fahrt zu testen. Spätestens wenn man Odometrie anbaut und aufzeichnet, wird einem sowieso klar, wie unperfekt dieses System ohne Bezugspunkte zur Umgebung ist (einfach, weil sich Fehler während der Fahrt ohne Korrektur beliebig fortpflanzen).
Dann wird es Zeit, sich um die Anbindung der Umgebung zu kümmern. Neben den raster- oder vektororientierten 2- oder 3D-Karten gibt es sicherlich auch andere (featureorientierte) Lösungsansätze. Allerdings glaube ich nicht, dass ein Featureknotennetz bezüglich Sensorik, Parametrierung und Verifikation aus menschlicher Sicht einfacher zu behandeln ist. Auf eine Karte guckst Du nach Deiner Position und Du weißt, wo Du bist. Letztlich ist aus Sicht des Slams die Rasterkarte ein Abfallprodukt, das man als Mensch zufällig gut versteht. Man kann damit arbeiten, Dinge untersuchen (z.B. mal über die Wohnung ein Temperaturprofil oder die WLAN-Abdeckung aufzeichnen) oder auch etwas bedienen (der sophisticated Wecker, der morgens ins Kinderzimmer fährt und die Blagen solange mit pädagogischen Sprüchen vollquäkt, bis sie endlich aus den Betten hoppeln).
Also: Standortbestimmung und Zielpunktvorgabe in lesbarer Form sollte es schon sein.
Ich kann es nur aus meiner Sichtweise erläutern: Nachdem ich im Simulator eine befriedigende Lösung gefunden hatte, habe ich mir überhaupt erst die Mühe gemacht, eine Hardware dafür zu finden.
Selbst mit dieser Vorgehensweise liegen noch viele Irrwege und produzierter Schrott bis zum ultimativen Gerät vor Dir, das alle Fallstricke Deiner Wohnung oder Deines Gartens umschifft.
So kann ich das besser nachvollziehen, welcher Gedanke dahinter war. Wenn Du das so noch mal machen willst. Ich weiß nicht. Ist das sinnvoll?
wie unperfekt dieses System ohne Bezugspunkte zur Umgebung ist (einfach, weil sich Fehler während der Fahrt ohne Korrektur beliebig fortpflanzen).
Ja so ist das natürlich. Frage ist, ob das stört oder ob man auch mit Ungenauigkeiten arbeiten kann. Ob ein Fahrgestell mal ein paar Millimeter weiter links oder rechts fährt oder am Ende einer Strecke 3cm versetzt ankommt, ist u.U. gar nicht so wichtig. Da kommt es dann auf die Regelung an. Eine Positionsbestimmung in einem bestimmten Rahmen muss ja irgendwie gegeben sein, wenn sich das Gerät nicht rein zufällig selbst bewegen soll.
Ich sehe wohl die Vorteile einer Karte. Aber auch die großen Datenmengen, die in Echtzeit verarbeitet werden sollen. Allerdings mangelt es mir hier an Erfahrung mit Laserentfernungsmessung, bezüglich der Daten. Ich würde das glaub ich zielgerichtet und damit selektiv einsetzen. Nicht unbedingt in der Form, ein Rundumbild zu erstellen. Auch wenn das in Summe gesehen eine sehr gute Möglichkeit wäre. Weil man dann eben z.b. so eine Karte auch auslesen und sich selber anschauen könnte und weil ein Algorithmus, der einen Weg in der Karte zum Ziel findet, super ist, weil sich so eben insgesamt auch jeder Zeit die Position im Raum bestimmen lässt (bezugnehmend auf die Umgebungshindernisse). Ist eine Frage der Zielsetzung, mehr kann ich zurzeit dazu nicht sagen. Wenn Du das ohnehin schon so machst und weiterhin so vor hast, ist es so. Eine einfachere oder andere Lösung kann ich noch nicht präsentieren. Inkas Anforderung wäre, dass sich das Gerät selbst im Raum bewegt und Baken folgt, tifft es auf Hindernisse, werden die umfahren und eine Bake bspw. zielgerichtet verfolgt. Das Gerät muss nur die Richtung der Bake erkennen (drehbarer IR-Empfänger bspw. oder mehrere IR-Empfänger im Kreis angeordnet) und sich dann in diese Richtung drehen und drauf zu fahren. Mein Versuchsansatz ist ein anderer, der mich dann erst einmal mehr interessiert (dazu gab es aber einen längeren Thread, wo ich das Für und Wider in der Diskussion sehr hilfreich fand, mir klarzuwerden, ob das funktionieren könnte). Weil mich mehr interessiert, dass ein Gerät einen Punkt in einem Raum mehr oder weniger genau selber anfahren kann (oder auch in einer ganzen Wohnung mit mehreren Räumen eigenständig die Räume findet) im Grunde, ohne dafür direkt eine Karte einzusetzen, mit Wegberechnung. Aber auch möglichst ohne Baken oder anderes Künstlich aufgestelltes. Inwiefern weiter Hilfsmittel notwendig sind, um das Ziel zu erreichen, wird sich im Laufe der Experimente herausstellen.
MfG
Das ist Schade. Kannst Du denn hier etwas mehr über die Technik (Funk/IR, Frequenz, Reichweite, Peilwinkelgenauigkeit) erläutern?
Die IR-baken wären natürlich reaktivierbar, ob sich das lohnt weiss ich nicht. Es wäre eine baustelle mehr, irgendwann werden es zu viele. Meine überlegungen und vorgehensweise von damals kann man hier (https://rn-wissen.de/wiki/index.php?title=IR-bake_f%C3%BCr_den_RP6) nachlesen...
Holomino
10.12.2020, 01:20
Die IR-baken wären natürlich reaktivierbar, ob sich das lohnt weiss ich nicht.
Wieso nicht? So eine IR-Bake habe ich auch an der Ladestation.
Was mir nicht so gut gefällt: IR-Baken senden aktiv und wollen versorgt werden. Bei steigender Anzahl wird man im Dauerbetrieb eine Menge Steckdosen belegen.
Standortbestimmung und Zielpunktvorgabe in lesbarer Form sollte es schon sein.
Vom Prinzip wäre ich dabei, aber ich würde das in möglichst kleiner Form realisieren. Als Beispiel würde ich einfach einen ESP-12 nehmen, weil davon welche habe und das damit ausprobieren. Ich könnte mir vorstellen, dass das passt. Fürs Wissen müsste ich es tatsächlich versuchen. Ich hatte schon mal mit LIDAR geliebäugelt, wegen einer genauen, alternativen Entfernungsmessung. Aber bei 200 EUR ... ich weiß nicht. Ich kenne mich auch mit den Softwarelösungen (Slam) nicht aus. Ich denke aber, ich würde es einfach so machen, wie ich es mir vorstelle. Kann so schwer nicht sein, eine Karte zu erstellen, also im Grunde einen Datensatz, in dem ich meine Hindernisse markiere. Eventuell braucht es ein paar Durchläufe, um die Daten zu überarbeiten und etwas länger würde es brauchen (weil ich so was ähnliches schon umgesetzt habe), um einen Pfad zum Ziel zu finden. Der Algorithmus wäre etwas umfangreicher vielleicht und würde auch einen Moment länger laufen (Rechenzeit). Hier würde mich mal noch interessieren, wie schnell denn so was sein soll? Wie schnell soll so eine "Karte" aktualisiert werden und wie schnell muss ein Weg gefunden werden? Also mal in Sekunden ausgedrückt vielleicht? Wenn man vorgibt: 30 bis 60mal pro Sekunde, ist es natürlich mit sehr viel Rechenpower verbunden. Also, wie sind die Anforderungen und vor allem, warum?
MfG
Holomino
10.12.2020, 01:56
Also mein aktuelles Lidar ist ziemlich langsam mit einem Rundumscan/s (das ist auch die Aktualisierungsrate der Lidar-Karte). Der Sensor (LidarLite V1) hat eine Messperiode von 13ms, also etwa 75 Messungen/Scan. Es kommt jetzt etwas auf die Robotergeschwindigkeit (->Scans/s) und die Größe der Umgebung (->Messungen/Scan) an. Mit 15..30cm/s lässt sich bei mir auf jeden Fall auch ein 5x6m Raum im 5cm-Raster auflösen.
Was bei mir in der Simulation und auch in der Praxis (https://www.roboternetz.de/community/threads/67177-Flaschenhals-im-Slam) auffällt: Die Reichweite ist wichtig. Andere Verfahren legen allerdings auf die Extraktion von Features (Ecken oder Linien) Wert. Da geht es dann eher um die Anzahl der Messungen/Scan.
Ja gut, hätte ich jetzt nicht gedacht, dass die Reichweite doch so ausschlaggebend ist, aber das relativiert sich gleich (zwei Sätze weiter im Text). Die Rotationsgeschwindigkeit hatte ich auch schon im Kopf, muss man anpassen. Kommt ja nun drauf an, wie weit man vorausschauen muss. Das ist auch von der Bewegungsgeschwindigkeit abhängig (jedenfalls für mich logisch). Ein Roboter, der nur langsam in der Wohnung fährt, muss keine 10m vorausschauen oder gibt es dafür gute Gründe? Für mein Verständnis setzt sich eine Gesamtkarte zusammen, wenn der Roboter mehr und mehr Bahnen im Raum abgefahren hat. Die Messreichweite mit 50cm sollte ausreichen, wenn nicht sogar viel weniger. Ich vermute hier kommt es auch drauf an, wie schnell der Roboter ausweichen könnte und überhaupt sich bewegen würde. Wenn der ganz langsam fährt, genügt auch eine sehr geringe Reichweite. Allerdings muss er dann weitere Strecken fahren, um einen Raum zu erkunden, bzw. um festzustellen, ob es in eine Richtung überhaupt weiter geht oder da ein Hindernis auftaucht. Da kommt mir sofort der Gedanke, das hier etwas anders zu lösen. Nämlich nur das unmittelbare Nahfeld aufzuzeichnen und wenn mehrere mögliche Pfade zum Ziel berechnet wurden, hier dann jeweils die Messreichweite in genau diese eine Richtung zu erhöhen und also alle Pfade selektiv in einer höheren Reichweite zu scannen. Damit er eben nicht alle abfahren muss.
Also das war jetzt nur so, was mir dazu einfallen würde. Ich muss erst damit arbeiten. Aber mir ging es ja auch um die Geschwindigkeit, wie schnell das sein soll, mit den Scans und den Berechnungen. Um so direkter man den Weg zum Ziel ausspionieren möchte (um also direkt von Anfang an den passenden Pfad von A nach B zu finden) benötigt man eine vollständige Karte der Umgebung. Ich denke hier würde man die Pfadsuche ein Mal ausführen müssen, zu Beginn eben. Das dürfte auch etwas dauern, meinetwegen auch 5 Sekunden. Vermutlich würde man den Pfad dann in die Karte übernehmen und fertig. Damit sind die Punkte klar, die man immer wieder auf dem Weg zum Ziel ansteuern muss. Der Rest spielt sich nur im Nahfeld ab (mit einer tauglichen Reichweite). Aufgrund der geringeren Datenmenge sollten diese Algorithmen weniger Rechenzeit benötigen (womöglich sehr viel weniger).
Trotz allem würde mich interessieren, was Du als Anforderung siehst, welche Berechnungsgeschwindigkeit, bis die nächste Entscheidung getroffen werden kann, wo der Roboter lang fährt. Also wie oft pro Sekunde?
MfG
Holomino
10.12.2020, 15:27
Trotz allem würde mich interessieren, was Du als Anforderung siehst, welche Berechnungsgeschwindigkeit, bis die nächste Entscheidung getroffen werden kann, wo der Roboter lang fährt. Also wie oft pro Sekunde?
Das Update des Sollwertes für die Lageregelung (dem Punkt auf dem Pfad, den ich als nächstes in gerader Linie ansteuern kann) basiert bei mir auf mehreren Ereignissen:
- Die Auswertung des SLAMs (Takt 1s) korrigiert ja die Position. Wenn ich also nach dieser Korrektur sehe, dass der Roboter vom Pfad abweicht, muss ich ihm einen neuen Sollwert verpassen.
- Der Roboter gibt zyklisch (250ms) seine Odometrie-Pose zurück. Erreicht er dabei auf dem Pfad einen Knick, bekommt er einen neuen Sollwert. (Richtungsänderung und Strecke macht der Regler alleine)
- Nach Neuberechnung des Pfades (oder eines Teilstückes) wird der Sollwert instant aktualisiert. Ursache der Pfadänderung kann eine neue Zielvorgabe sein (fahre woanders hin) oder auch ein auf dem Pfad liegendes neu detektiertes Hindernis (Teilneuberechnung zum Umfahren des Hindernisses). Auf jeden Fall treten diese Ereignisse nicht zyklisch auf.
Ein Roboter, der nur langsam in der Wohnung fährt, muss keine 10m vorausschauen oder gibt es dafür gute Gründe?
Bei SLAM braucht man Features, ohne kann der Algorithmus sonst nicht entscheiden ob er an Position x oder x+1 ist. Beispiel: Flur einer Uni, da sieht jeder m² identisch ist. Um so weiter man sehen kann um so höher die Wahrscheinlich das vielleicht eine Tür ist oder ein Stuhl den man als Feature nehmen kann.
Ja, dann steht das wohl fest. SLAM ist vorhanden und soll verwendet werden. Wenn also ein Anforderungsprofil erstellt würde, sollte dann erster Stelle "SLAM" stehen. Das dafür Notwendige lässt sich daraus ableiten. Wie: zentrale Rechnereinheit (CPU/Board) und daraus folgend die Stromaufnahme. An der zweiten Stelle des Profils könnte stehen: Laufzeit xxx. Daraus kann man dann schon ganz grob zur notwendigen Akku/Batteriekapazität kommen und zum Gewicht des Akkus. Das Gesamtgewicht des Roboters sollte vielleicht dann schon an dritter Stelle des Anforderungsprofils stehen. Drum herum muss noch ein wenig Leistung für angeschlossene Peripherie eingeplant werden.
Ja, dann steht das wohl fest. SLAM ist vorhanden und soll verwendet werden.
Hab ich vorher noch nicht gelesen, dass SLAM fest steht? Ich dachte die Idee wäre Modular?
(...) sollte dann erster Stelle "SLAM" stehen. Das dafür Notwendige lässt sich daraus ableiten. Wie: zentrale Rechnereinheit (CPU/Board) und daraus folgend die Stromaufnahme.
Ein ESP32 z.B. sollte reichen wenn der SLAM-Algorithmus per W-Lan angebunden wird. Muss ja kein Rpi4 mit 1A an Board sein.
An der zweiten Stelle des Profils könnte stehen: Laufzeit xxx. Daraus kann man dann schon ganz grob zur notwendigen Akku/Batteriekapazität kommen und zum Gewicht des Akkus. Das Gesamtgewicht des Roboters sollte vielleicht dann schon an dritter Stelle des Anforderungsprofils stehen. Drum herum muss noch ein wenig Leistung für angeschlossene Peripherie eingeplant werden.
Bedingt sich natürlich alles gegenseitig. Ich würde mit dem Antrieb anfangen, dann kommt die Laufzeit und damit die Akkukapazität. Aber nochmal: Ich dachte die Idee wäre Modular zu sein, also keine Festlegung von Akku, Gewicht etc weil austauschbar?
Hab ich vorher noch nicht gelesen, dass SLAM fest steht? Ich dachte die Idee wäre Modular?
Die Diskussion geht doch darum dass es SLAM sein soll?
Ein ESP32 z.B. sollte reichen wenn der SLAM-Algorithmus per W-Lan angebunden wird. Muss ja kein Rpi4 mit 1A an Board sein.
Weiß ich nicht. Ich würde vollständige Geräte bevorzugen. Wegen der Ortsunabhängigkeit. So ist es sonst ortsgebunden, in der Reichweite des WLANs.
Ich dachte die Idee wäre Modular zu sein, also keine Festlegung von Akku, Gewicht etc weil austauschbar?
Irgendwo benötigt man doch eine Mindestanforderung, um entwicklungstechnisch darauf aufzubauen? Muss man erst mal durchspielen, so Pi*Daumen und sehen, was dabei heraus kommt. Dann erfährt man was über die Mindestgröße die das haben soll. Auch evtl. über die Baugröße der Module und deren Leistung (Akku/Batterie). Dann sieht man, ob das irgendwie unter einen Hut zu bringen ist. Wenn allein der Akku am Ende 500g wiegt, braucht man u.U. stärkere Motoren im Antrieb oder einen anderen Antrieb. Damit ändert sich evtl. die Größe des Antriebs und damit des Roboters und wieder das Gewicht. Modularität hat ja auch Grenzen. So passt eine Akkueinheit von Toyota auf einige Fahrzeugtypen mit Straßenzulassung, aber nicht auf einen Staubsaugroboter. Und der Akku vom Staubsaugroboter wird keinen Toyota-PKW antreiben können.Deshalb denke ich, so eine Grundvorstellung von der Größe muss vorhanden sein. Wel dann kann man Bereiche festlegen, wie Akkuleistung von .. bis .. mAh. Mal kleiner, mal größer. Aber ich glaube, ich mache mir da jetzt zu viele Gedanken. Mal sehen, wie Holomino das sieht.
MfG
Ich will bei meinem Weihnachtsprojekt weg vom SLAM, sondern fahren nach Farben machen, das heißt mit Tiefenbild. Ich werde berichten wie es läuft, fest montierte Lidar Sensoren, will ich nur wegen der Kollision verwenden.
Wie gesagt ich werde berichten.
Ich hatte auch schon mal an ein ES gedacht, mit Einsatzparameter, bin da aber irgendwie abgekommen.
Weiß ich nicht. Ich würde vollständige Geräte bevorzugen. Wegen der Ortsunabhängigkeit. So ist es sonst ortsgebunden, in der Reichweite des WLANs.
Manchmal frage ich mich in welchen Dimensionen du denkst. Du kannst natürlich auch LTE anstatt W-Lan verwenden oder den W-Lan AP mit einem Ethernetkabel mit dem Rest der Welt verbinden. Du musst ja nicht den ESP32 per Wlan anbinden, du kannst gerne einen Core I7 verbauen für Slam, ich glaube niemand hält dich dabei auf. Aber wenn andere einen ESP32 verwenden wollen und SLAM dann irgendwo in der Cloud rechnen wollen, wieso nicht?
So passt eine Akkueinheit von Toyota auf einige Fahrzeugtypen mit Straßenzulassung, aber nicht auf einen Staubsaugroboter.
Das ist der zweite Satz weswegen ich mich frage in welchen Dimensionen du denkst.
Deshalb denke ich, so eine Grundvorstellung von der Größe muss vorhanden sein.
Nein, wichtig ist nur wie ich den Akku anschließe. Ob der Akku 1000kg wiegt und damit 500kW Motoren antreiben soll oder 500g wiegt und 1kW antreibt ist egal wenn du in deinem Moduldesign des Akkus spezifizierst "Spannung wird per I2C in Register 0 ausgelesen" dann kann dein Mikrocontroller ohne Änderung beide Akkutypen auslesen.
Du kannst natürlich auch LTE anstatt W-Lan verwenden oder den W-Lan AP mit einem Ethernetkabel mit dem Rest der Welt verbinden.
Nichts von dem, wozu auch? Kannst gerne "Cloud Computing" machen, ich habe dagegen nichts einzuwenden.
Holomino
14.12.2020, 15:54
Ich hatte auch schon mal an ein ES gedacht, mit Einsatzparameter, bin da aber irgendwie abgekommen.
Was ist ein ES?
Irgendwo benötigt man doch eine Mindestanforderung, um entwicklungstechnisch darauf aufzubauen?
Das ist eine interessante Frage, auf die ich auch noch keine Antwort gefunden habe. In einigen Modulen ist es einfach (im Powermodul z.B. geht nicht weniger als eine Zelle. Rechengeschwindigkeiten, Zyklen oder Datenprotokolle lassen sich eindeutig quantifizieren). Den Zusammenhang zwischen korrektem Kartieren und Sensorsetup allerdings kann ich schon in 2D nur noch in der Simulation abschätzen.
Es hat im letzten Jahrtausend einige Navigationsansätze mittels "deduced reckoning" alleine über Odometrie und Hindernissensoren im Nahfeld gegeben. Später wurde das dann liebevoll in "dead reckoning" umbenannt. Letztlich ist die Aufgabe vergleichbar mit der Funktion eines Blinden, der nur mit den Tastsinnen (Händen) eine fremde Wohnung erforscht. Das schraubt halt die Hardwareanforderungen herunter, legt aber gleichzeitig die Softwareanforderungen (auch der Blinde geht mit dem grundlegenden Wohnungs-Vorwissen "Ecken, Wände, Räume" los und stellt unterwegs verschiedene Hypothesen auf, die er ggf. im Verlauf verifiziert oder verwirft) gewaltig hoch.
ES = Expertensystem
eigentlich nur eine Python Software, die verschiedene Dinge abfragt und Dir ein Vorschlag macht.
Holomino
14.12.2020, 16:34
Meine Güte, ich war schon bei Stephen King.](*,)
Das ist eine interessante Frage, auf die ich auch noch keine Antwort gefunden habe.
Weist Du nicht, welche Größe? für drinnen vielleicht nicht mehr als 30x30cm in der Grundfläche, nach oben geht vielleicht etwas mehr. So zum Anfang. Größer dann für die, die zuhause oder gar draussen mehr Platz haben. Größer geht ja dann immer.
Den Zusammenhang zwischen korrektem Kartieren und Sensorsetup allerdings kann ich schon in 2D nur noch in der Simulation abschätzen.
Würde mich interessieren, was Du damit genau meinst.
Letztlich ist die Aufgabe vergleichbar mit der Funktion eines Blinden, der nur mit den Tastsinnen (Händen) eine fremde Wohnung erforscht.
Na ja, im Grunde ist ein Roboter das. Solange, bis die Technik irgendwann mal einwandfrei sehen und Objekte erkennen wird, wie ein Mensch, auch in der Geschwindigkeit.
MfG
lach, sowas lese ich nicht mal, dann lieber Frank Schätzing :D
Es hat im letzten Jahrtausend einige Navigationsansätze mittels "deduced reckoning" alleine über Odometrie und Hindernissensoren im Nahfeld gegeben. Später wurde das dann liebevoll in "dead reckoning" umbenannt.
Bitte Begriff nochmal erklären: "dead reckoning". Für mich war das bisher im Falle von Bodenrobotern z.B. die Positionsbestimmung mittels Odometrie. Wo da Hindernissensoren reinspielen verstehe ich nicht.
Letztlich ist die Aufgabe vergleichbar mit der Funktion eines Blinden, der nur mit den Tastsinnen (Händen) eine fremde Wohnung erforscht. Das schraubt halt die Hardwareanforderungen herunter, legt aber gleichzeitig die Softwareanforderungen (...) gewaltig hoch.
Kannst du den Punkt bitte auch erläutern? Ich lege doch die Hindernisse immer in eine Costmap ab, ob die Hindernisse durch ein Lidar, IR/US/ToF-Sensoren oder Taster kommen ist doch erstmal egal. Für mich bedeutet das quasi identische SW-Anforderungen, bzw im Falle von Lidar muss ich mehr Daten verarbeiten, also höhere SW-Anforderungen.
Holomino
14.12.2020, 20:42
...
Was wir mit unseren Lidars praktisch in der "Breite" (Datenmenge) mehr haben, ging beim Dead Reckoning in die Tiefe (die Korrelationen über den zeitlichen Ablauf). Das war quasi ein Dauer-Closed-Loop-Ansatz, in dem immer wieder die rudimentären "Scans" an ihren Aufnahmeorten im Rahmen einer Hypothese (den Odometriefehlern) korrigiert wurden.
Half aber auch nichts. Das praktische Fehlen einer detektierbaren Tiefenbegrenzung (man kann auch länger fahren) sowie der ganz ordinäre Blindflug über Flächen ohne Hindernisse hat schließlich noch in den Versuchen gemündet, die Odometrie zu verbessern (zu der Zeit kam z.B. auch der SynchroDrive auf).
Hindernisssensoren im Nahfeld, also Bumper oder US hatten die Teile damals auch schon. Später kamen dann Gyro und Kompass dazu, aber so richtig durchgesetzt hat sich das wohl jenseits der Laborebene nie.
Aber wo ich Dir mal wieder Löcher in den Bauch fragen darf: Was sind denn bei ROS die sensorischen Minimalanforderungen zum Kartieren? Ein Lidar ist ja auch nix anderes als der Ersatz für mehrere Abstandssensoren. Wie weit kann man in ROS Messgenauigkeit, Reichweite Winkelauflösung und Wiederholrate in Bezug auf Raster, Umgebungsgröße und Robotergeschwindigkeit herunterschrauben?
Weist Du nicht, welche Größe?
Rein funktional gebaut ist mein letztes Modell ca. 16x17x15cm. Zu groß für die Mini-Sumo-Klasse (10x10cm)
Holomino
24.12.2020, 10:09
Gefunden: https://hackaday.io/project/161085-phoebe-turtlebot
Ein an den TurtleBot angelehnter Nachbau mit ROS und SLAM für 250$ (ca. 200€).
Leider kein Powermanagement und scheinbar auch keine zusätzliche Hindernisdetektion, so richtig autark wird es also wohl nicht sein.
Mal (kommendes Jahr) sehen, ob es nicht etwas günstiger geht und die o.g. fehlenden Funktionen trotzdem drin sind.
schicker Entwurf, was man so alles findet.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.