Steuerung Kommandos

[Moppi]

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

[Defiant]

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.

[Moppi]

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

[inka]

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?

[Moppi]

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.