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.
Zitieren
Lesezeichen