Steuerung Kommandos

Hallo zusammen!

Ich finde ich hier nichts gescheites, ein Haufen an Ergebnissen, in denen ich suchen kann, ob ich da was finde. Das kann tagelange Lesearbeit bedeuten. Deshalb hier direkt gefragt:

Es gibt doch hier so einige Leute, die schon fahrbare Roboter gebaut haben, die sich auch normal in einer Wohnung bewegen und z.B. die Ladestation finden.
Ich bin gerade an einem Punkt, wo ich mir Gedanken um die Steuerkommandos mache. Und das ist auch die Frage: welche Steuerkommandos benötigt man?

Mir fallen da ein: vor, zurück, rechts, links
Das kann ich noch verfeinern in bestimmte Strecken/Abschnitte: 10cm vor, 10cm zurück .. oder ... 15° rechts, 30° links
Kommt man denn damit aus? Oder sogar nur mit den vier Himmelsrichtungen (theor. möglich) und einem gewissen Maß für die Strecke (in Zentimeter meinetwegen: Normalmodus; in mm: Feinmodus - wären bei mir theor. 2,513mm Auflösung)? Dann könnten die Kommandos lauten: fahre 15cm rechts, dann 30cm links (würde der Roboter dann zuerst rechts 90° drehen und 15cm fahren, dann links 90° drehen und 30cm fahren).

Würde mich über Erfahrungen freuen und wenn noch weitere Kommandos sinnvoll sind, diese auch genannt werden.

MfG

- Die Grundfunktion "fahre per Joystick" (also einfach die Umrechnung der x-/y-Joystickachsen in PWM-Werte) finde ich zum Testen wichtig.

- Synchron drehen(um einen angegebenen Winkel) oder geradeausfahren (Strecke vor-/rückwärts) sind gut für Andocken oder Ausrichten verwendbar.

- Beim Bahnverfolgen (ein Master gibt Dir laufend Punkte vor, die Dich um die Kurven eines vorgegebenen Pfades führen) sieht's erst richtig elegant aus, wenn Kurven- und Streckenfahrt fließend ineinander übergehen.

Komplexere Dinge setze ich üblicherweise aus einer Sequenz synchroner oder bahnverfolgender Befehle zusammen. Für das Freifahren nach einer Kollision merke ich mir z.B. in einem kleinen Ringpuffer in einem Raster (5cm?) Punkte des zuletzt gefahrenen Meters. Nach der Kollision fahre ich diese Punkte rückwärts (in der Liste und auch der Robbi fährt rückwärts) an und teste an jedem Punkt durch synchrone Drehung 45° links/rechts, bis das Gefährt wirklich frei steht (muss man bei einer kreisförmigen Grundfläche nicht machen, die habe ich aber nicht).


Ergänzung noch:
- Geschwindigkeitsvorgaben: Man möchte nicht unbedingt seine Ladestation im Schnellgang überfahren.
- Beim Bahnverfolgen sollte man entscheiden können, ob die Rückwärtsfahrt erlaubt ist. (sieht einfach Panne aus, wenn der Robbi um einen spitzen Winkel geführt wird und ab da rückwärts weiter fährt.

ich habe noch
- auf der stelle drehen, li/re
- schieben seitlich li/re
- schiebe schräg li/re/vor/rück
aber das ist nur bei den omniwheels

ansonsten hatte ich nur beim freifahren eine kombination rück- und rechts ausweichen, also nach rückwärts rechts drehen...

Verschiedene Kommandos hängen auch am verwendeten Modell. Also bei meinem sind es ja nun zwei Antriebsräder. Damit kann ich entweder jeweils um ein Rad drehen, oder um einen Punkt zwischen den Rädern (normalerweise wäre das der Mittelpunkt, wenn ein Rad gleich schnell rückwärts dreht, wie das andere vorwärts dreht), das Hilfsrad würde jeweils, zusammen mit dem Chassiskörper, nachgezogen. Meine Frage zielte darauf ab, was man überhaupt benötigt, um alle notwendigen Fahrmanöver ausführen zu können. Mehr fällt mir auch nicht ein, als vor, zurück und rechts, links, und dann noch drehen links oder rechts. Ich habe mir vorgestellt, wie ich das Teil mit einer Fernbedienung steuern würde. Da wäre auch nicht mehr vorhanden. Da könnte ich mir vorstellen: Drehen in eine Richtung in Minischritten (also 5° oder 10° vielleicht) und 90° drehen. Drehen im Kreis setzt sich dann irgendwie daraus zusammen.

Diese Omniwheels sind ein Spezialfall. Bei denen würde auch die Steuerung nach den vier Himmelsrichtungen ausreichen und das Gefährt tut das dann auch so. Schräg fahren kann da auch noch nützlich sein, ja stimmt. Bei normalen Rädern muss man erst eine Drehung vollziehen, wobei der notwendige Platz vorhanden sein muss.
Joystick habe ich nicht. Würde ich für meinen Zweck so auch nicht benötigen, dass das in unendlich kleinen Abstufungen Kurven fahren tut. Würde meine Experimente eher komplizieren.

Sieht so aus, als ob nicht mehr dabei heraus kommt. Einzig stellt sich mir noch die Frage, ob zwei Drehmodi sinnvoll wären. Also einmal der, wo ein Rad fest steht, dann dreht sich das Chassis um dieses Rad, das ist der Kreismittelpunkt. Und dann der Modus, wo der Kreismittelpunkt zwischen den Rädern liegt. Da kann man in eine Richtung auch noch unterschiedlicher drehen: Kreismittelpunkt ist linkes Rad, Kreismittelpunkt ist rechtes Rad und Kreismittelpunkt ist dazwischen. Vorsichtshalber sieht man die vielleicht alle drei vor? Würde ich schon so denken.

Dann hätte ich alles, glaube ich. Danke, bis hier!


MfG

Zitat:

---

Zitat von Holomino

.. Synchron drehen .. geradeausfahren .. Bahnverfolgen (ein Master gibt .. Punkte vor, die Dich um die Kurven eines vorgegebenen Pfades führen) ..

---

Hmmm. Klingt irgendwie nach Vorgaben von bestimmten/bestimmbaren einzelnen (Teil-)Strecken "s". Kontinuierliche Vorgaben kurzer Streckenabschnitte in einem knappen Zeitraster führen dann zum fahren. Somit gilt v = ds/dt - wobei HIER ds und dt noch nicht infinit klein seien. Aber in der Realität ist so auch eine fein dosierbare Geschwindigkeit möglich - und wir kommen in die übliche Geschwindigkeitsdefinition v = ds/dt (ds, dt, ds-nach-dt infinitesimal kleine Teilstückchen).

Irgendwie finde ich in dem (schick knappen *gg*) Thread nicht das, mit dem ich viele meiner 2rädrigen fahren lasse: jedes Rad (gleiche Raddruchmesser vorausgesetzt!!!) bekommt eine eigene Geschwindigkeitsvorgabe - also NICHT die Vorgabe eines bestimmten Zielpunktes. Geschwindigkeitsvorgaben sind bei mir üblicherweise 2-byte-signed-integer :

Code:

---

  ix12 = ATSfak / tupsi12 / 10; // ix12 => Ist-Geschwindigkeit in mm/s

---

ATSfak .... Antriebsstrang-faktor enthält Übersetzung(en), Raddurchmesser,
.............. Motorzeitkonstante, *gg*Schlupf*gg* etc. etc
tupsi ....... time units per sensor interrupt - bei mir 50µs
ix ........... Ist-UMFANGSgeschwindigkeit EINES Rades in mm/s
..12 ........ Wert für den Motor 12 (Motor hat ja 2 Anschlüsse
...............der andere Motor heißt dann ..34 *gg*

Bei ix12 . = .. ix34 fährt das Dingelchen gerade aus
Bei ix12 . = . -ix34 dreht das Dingelchen um den Radstand-mittelpunkt
Bei ix12. =|=. ix34 fährt das Dingelchen >irgendeine< Kurve (oder Turn),
.................. deren Zentrum auf der Geraden der Radauflagen liegt,
...................innerhalb oder ausserhalb der Radauflagen.

Gut, ihr fahrt (alle?) mit Omniwheel, aber gibt das DEN Unterschied? Na ich hoffe, dass das zum Thema passt oder hilft.

Zitat:

---

- Beim Bahnverfolgen (ein Master gibt Dir laufend Punkte vor, die Dich um die Kurven eines vorgegebenen Pfades führen) sieht's erst richtig elegant aus, wenn Kurven- und Streckenfahrt fließend ineinander übergehen.

---

Jaaa. Und mit entsprechenden Algorithmen kann man aus aus diesen Teilstrecken auch schöne Kurven errechnen.
Andererseits - NUR durch Vorgabe verschiedener Geschwindigkeiten kann man auch kurvig fahren - siehe MiniD0 oder archie (zB dieses Video). Bei archie z.B. wird per IR-Fernbedienung (von altem TV) mit den Tasten [<VOL], [VOL>] jeweils eine Geschwindigkeit erhöht oder mit [OK] ix12 gleichgesetzt mit ix34. Mit [SWAP] wird das Vorzeichen beider Vorgaben geändert, mit [-/--] wird ein Vorzeichen geändert. Anm.: im autonomen Modus werden die Vorgaben "vom Gerät" selbst errechnet.

Ich habe mich jetzt für vier Kommandos entschieden, um die ersten Versuche zu starten: vor, zurück, links drehen, rechts drehen. Weiteres kann ich später einbauen.
Damit habe ich erst mal was, womit ich meine Gedanken vervollständigen kann. Als nächstes spiele ich gedanklich die Abläufe durch, die zwischen den Controllern stattfinden und auf ihnen ablaufen müssen.

MfG

Bei ROS gibt es einfach nur die cmd_vel-Nachricht, die eine 6-DOF-Geschwindigkeit entgegennimmt. Bei den typischen 2-Räder-Robotern sind das dann translation/x in m/s und rotation/z in rad/s. Damit lassen sich die verschiedenen Richtungen Vorwärts/Drehen/Schrägfahren durchführen.

Heute habe ich das noch weiter verallgemeinert. So dass ich zunächst nur Schritt Vor, Schritt Zurück, Schritt Rechts Drehen und Schritt Links Drehen habe. Ich denke, das ist der gemeinsame Nenner aller Bewegungen, die hier ausreichend sein sollen.

Die Frage war, wofür ich mich entscheide. Eine genaue Positionierung mit Zielvorgaben oder eine Positionierung ohne genaue Vorgaben. Wenn ich einmal mit genauen Angaben anfange, laufe ich Gefahr, dass immer weiter so fortzuführen, weil es vielleicht oft die einfachste Variante in Szenarien ist. Sie ist aber aus verschiedenen Gründen nicht die Vorteilhafteste. Daher habe ich mich also gefragt, welchen Weg ich in diesem Fall gehen soll. Von genauer Positionierung zur Verallgemeinerung, oder umgekehrt. Der Weg, von einer eher allgemeinen Bewegungsangabe auszugehen, ermöglicht es, noch nicht vorhandenen Funktionen (und Sensoren) zu ermitteln und im erforderlichen Umfang nachzurüsten. Das ist der Weg, den ich gehe.

MfG

so ganz kann ich es nicht nachvollziehen, Moppi,

meine vorstellung bei der roboterbewegung war immer die, dass er quasi mitten in einem unbekanntem raum steht. Fängt dann nach vorne zu wandern, die US-sensoren sorgen dafür, dass er nicht mit irgendwelchen gegenständen kollidiert. Taucht ein hindernis auf, stoppt er, fährt stück zurück dreht etwas nach links, oder rechts und versucht weiter geradeaus zu kommen. Das widerholt sich im prinzip. In diesen ablauf kann ich z.b. auch mit einer fernbedienung eingreifen, aber auch da ist die hindernis erkennung an und übergeordnet. Ist dein ansatz anders?

Für den Anfang ist da nichts anderes dran. Was anders ist, ist, dass mir die Funktionen alle noch fehlen. Ich habe ein leeres Gerüst, dass es zu füllen gilt. Und ich habe mehrere µC, auf die sich die Arbeit verteilen soll.
Ich habe verschiedene Möglichkeiten, die Funktion für eine Bewegung dann in die Programmierung einzubinden. Ohne Parameter und mit Parameter z.b.. Und die Frage hier ist dann, wie ich das von einem µC auf einen anderen µC übertrage. Dazu habe ich jetzt für alle Schnittstellen das Polling eingeführt, weil das bei I2C so gehandhabt wird. Zurzeit habe ich nur I2C und UART (seriell). Aber die Befehlsgestaltung muss ich irgendwie festlegen, damit ich die Befehle weiter verarbeiten kann (also was an Datenblöcken über die Schnittstelle gesendet wird). Wenn ich jetzt was übersehe, was später aber als sehr wichtig sich herausstellt, dann muss ich u.U. eine ganze Kette von Prozeduren programmtechnisch umstricken. Womöglich dann nur deshalb, weil mir vielleicht eine wichtige Bewegung fehlt (die ich vielleicht zusammenstellen kann, aber die man evtl. besser gleich als eigene Funktion hätte einbinden können).

MfG

- - - Aktualisiert - - -

Was später hinzu kommt ist, dass der Roboter sich situationsabhängig bewegen soll. Dazu kommen dann verschiedene Bewegungsstrategien, wenn man so will, für verschiedenste Situationen (Ebene#1). Bis dort hin sollte es rel. einfach sein. Ich muss nur die Grundlagen schaffen, zu denen auch eine schnelle Verarbeitung der situationsbedingten Daten zählt, und das Suchen nach dem geeignetsten Bewegungsablauf. Später will ich versuchen, nach dem gleichen Prinzip hinzubekommen, dass der Roboter (aufgrund Umgebungsbedingungen oder Anweisungen) selbst neue Bewegungsmuster erlernen kann, die auf die Situation passen (Ebene#2), in der er sich gerade befindet (dazu gehört auch, dass er ein Ziel hat). Ich habe noch keine Idee, wie lange das dann dauern könnte, bis er das selbst erlernt hätte. Aber angenommen, das ginge sogar sehr schnell (in wenigen Sekunden), dann könnte ich die Ebene#1 vielleicht weitgehend umgehen und die meisten Situationen gleich selbst meistern lassen, in Ebene#2. Das könnte auch Speicherplatz sparen. Weil normal ist Ebene#1 sehr speicherintensiv (deshalb jetzt schon mal 2 GByte SD-Karte). So weit bin ich aber noch lange nicht. Jetzt gibt es noch nicht mal eine wirklich gescheite Funktion, die ihn geradeaus fahren lässt.

MfG

PS:
Weil ich schon vom Speicher sprach, habe ich mich jetzt damit genauer auseinandergesetzt. Die Dateiverwaltung für eine SD-Karte auf einem nodeMCU 1.0 wird die Anzahl an Verarbeitungsblöcken nicht verwalten können, oder es wird irre langsam. Theoretisch wären bei FAT16 65536 möglich, aber wo sollen so viele Dateinamen gespeichert werden? Werden die Reihenweise von SD-Karte gelesen, ist das auch nicht so vorteilhaft. Deshalb habe ich jetzt beschlossen, die Verarbeitungsblöcken in eine Datei zu packen, die hat dann eine bestimmte Größe, der Zugriff auf einzelne Blöcke darin wird dann aber schneller sein. Ich muss dann bei der Suche nicht über das FAT gehen, sondern kann direkt adressieren, da eine direkte Adressierung bereits vorliegt; ich habe die bisher auf Dateinamen umgelegt - das werde ich ändern. Damit steht auch schon fest, wie viel Platz ich für die Programmierung des Systems auf dem Datenträger maximal benötige und tatsächlich anlege. Zurzeit sind das dann erst einmal 2 MByte (die ich vermutlich aber gar nicht brauchen werde, aber ich weiß jetzt ja noch nicht, was sich an Programmblöcken ansammeln wird). Tut der 2 GByte-SD-Karte jetzt nicht weh.