Hexapod - mal etwas anders

[lemmings]

der ganze Datenverkehr überdenkenswert. Jedes Bein muss in Echtzeit wissen, ob ein anderes Bein Probleme hat oder überlastet ist, etc.

Mit dem Datenverkehr hast du Recht, das ist noch nicht endgültig.

Mal eine grundsätzliche Überlegung - ein Bein, was Probleme hat (der Boden ist weg oder an der falschen Stelle) zieht notfalls die INT-Leitung (ja, sorry, hatte ich nicht erwähnt) und eskaliert an den Hauptprozessor. Das wäre generell "Alles Stop" - nicht so schön.

Beispiel "da liegt ein Streichholz":
Über die Stromaufnahme kommt bei einem Bein zu früh "Boden", d.h. der jeweilige Fuss setzt auf dem Streichholz auf.
Zu diesem Zitpunkt weiss ich in etwa, wie gross das Hindernis ist und der Controller für das jeweilige Bein kann "im Rahmen sinnvoller Grenzen" eigenmächtig zwischen Adaption und Hindernis, welches zu Stop & Eskalation führt, entscheiden.

Beispiel "Abgrund":
Wenn der Boden wider Erwarten nicht auftaucht und auch im Rahmen der Adaptions-Grenzen weg ist, es also ein echter Abgrund ist ind nicht nur eine 3mm Schwelle zwischen 2 Räumen - Reaktion: Bein einziehen (wegen Schwerpunkt verlagern vom Abgrund weg), Fehlerstatus setzen INT ziehen und warten.

Der Hauptcontroller muss also alle 50ms alle Informationen von allen Beinen abholen, diese auswerten und auch wieder Steuerkommandos an alle Beine senden.

Nein, er gibt nur den Takt für die vordefinierte Schrittfolge vor. Die 50ms Auflösung habe ich willkürlich gewählt, weil ich glaube, dass die Bewegung dann flüssig aussieht und um überhaupt etwas zum Rechnen zu haben.

aber wie sieht es mit Reaktionen des Bots auf die Umwelt aus?

Kleine Hindernisse sollten die Beine kompensieren, grössere Hindernisse müssen althergebracht umgangen werden - ansonsten liegt noch 16 I/O Pins und ein unbenutzter I²C Bus am Hauptkontroller brach, an die man nach Belieben Sensoren hängen kann.

Zudem muss der Hauptcontroller ja erstmal die ganzen Bewegungsabläufe berechnen, die Aufgrund deiner Idee der Ausbalancierung auch nicht statisch sein können.

ich denke, das läuft auf ein paar Grundgangarten hinaus, die dann im 8k Flash der ATtiny84's abgelegt sind und eine gesunde Definition von dem, was das einzelne Bein noch selbständig adaptieren darf oder ab wann es besser ist, das Hindernis zu umgehen.

wenn der Bot von einer Sequenz auf eine andere "wechselt", in einer Kurve zum Beispiel, würde er stets für einen Moment "hängen", bis die neue Schrittfolge übertragen wäre.

Guter Einwand! Danke.

Ich hab's noch nicht durchgedacht (wollte es wie die kleinen Hindernisse "on the fly" adaptieren) - was aber bei Kurven auf einem Prozessor ohne Hardware-Multiplikation blöd ist

Der Hauptprozessor weiss doch schon vorher, dass eine Kurve kommen wird - Kurven könnten doch anhand der aktuellen US-Messung vom Hauptprozessor vorberechnet und während der Zeit zwischen den Schritten übertragen werden (die ATtiny's haben auch 512 Byte RAM - gut für so "Scratch-Geschichten")

Aber wie "weiß" ein Bein, in welcher Stellung die Servos weniger belastet werden, ohne dabei den Boden unter dem Fuß zu verlieren?

Hmmmm....

Ich glaube, dass die wenigste Energie benötigt wird, wenn sich das Ding auf den Boden legt, also sollte wir das den Hexapod nicht selbst entscheiden lassen. (sonst liegt er den ganzen Tag nur faul rum und spart Energie.

Mal sehen

Erst einmal Suche ich nach einer sinnvollen Alternative, die es vermeidet, einen ATmega mit Soft-PWM zu vergewaltigen um dann festzustellen, dass der einzige Prozessor nur mit dem Erzeugen der PWMs beschäftigt ist und zu sonst nichts mehr Zeit hat.

Die Trennung interner/externer Bus und das "über Board werfen von I²C auf dem internen Bus" hat sehr viel Druck aus dem Timing genommen.

Vielen Dank bisher für's Feedback.

Ralph