Hexapod

[HannoHupmann]

Klassischerweise wird für Roboter die Steuerung durch mehre Ebenen gegliedert. Im Thread zu meinem Vinculum habe ich ausführlich beschrieben wie sowas bei einem Hexabot aussieht. Die meisten Projekte hier im Forum sind ähnlich aufgebaut, wenn auch vielleicht nicht ganz so klar differenziert. Deine Vorschläge sehen mir ehrlich gesagt etwas zu umständlich aus.
Mit einer Rückgabe der tatsächlichen Winkelposition baut der Fachmann einen Regelkreis auf und lässt diesen parallel zur Berechnung laufen.

[wrock]

Mit einer Rückgabe der tatsächlichen Winkelposition baut der Fachmann einen Regelkreis auf und lässt diesen parallel zur Berechnung laufen.

Regelkreis funktioniert in diesem Fall glaub ich nicht, weil wirs ja entkoppelt haben und mit I2C ansteuern. Aber die 2te/3te Steuerungsmethode sollte auf eine ähnliche funktionalität hinauslaufen

[HannoHupmann]

Regelkreis funktioniert immer, wenn man ihn richtig implementiert! Der wird schon auf den µC pro Bein untergebracht, alles andere macht keinen Sinn. Das hat mit der Vorgabe über I2C gar nichts zu tun, von dort kommt der Soll-Wert, der wirt mit dem Ist-Wert verglichen und der µC Regelt auf den Soll-Wert. Ein wunderbar geschlossenes System, welches sich ganz wunderbar modular aufbauen lässt, wenn es schon dabei bleiben soll.

[wrock]

Regelkreis funktioniert immer, wenn man ihn richtig implementiert! Der wird schon auf den µC pro Bein untergebracht, alles andere macht keinen Sinn. Das hat mit der Vorgabe über I2C gar nichts zu tun, von dort kommt der Soll-Wert, der wirt mit dem Ist-Wert verglichen und der µC Regelt auf den Soll-Wert. Ein wunderbar geschlossenes System, welches sich ganz wunderbar modular aufbauen lässt, wenn es schon dabei bleiben soll.

und der fuß irgendwo blockiert? bzw. auf etwas draufgetreten ist? dann kann er doch gar nicht auf den SOLL wert, dann muss mit dem aktuell IST wert weitergerechnet werden-->der Wert wird bei der IK benötigt.

oder nicht?

[HannoHupmann]

Doch natürlich, kommt eben darauf an was man macht! Wird das Poti abgefragt, dann kann man darüber einen Regelkreis aufbauen aus Soll und Ist-Wert. Wird der Strom an Servo abgefragt, kann man diesen überwachen.

Aus beiden Sensorwerten allein lässt sich aber nicht einfach erkennen, dass der Roboter irgendwo hängen bleibt.

Möglich ist es mit der Kombination: Der Positionsregelkreis meldet, dass die Sollposition nicht erreicht wird und gleichzeitig meldet der Stromsensor einen Anstieg im Stromverbrauch. Nun könnte man annehmen, dass das Bein irgendwo hängen geblieben ist! Alternativ kann es aber auch einfach sein, dass der Roboter sich gerade "hochdrückt" und daher mehr Strom verbraucht und die Sollposition noch nicht erreicht.

Mit Kontaktsensoren am Bein (unten und seitlich) könnte man deutlich besser erkennen ob der Hexa "hängen bleibt"

Einfach mal als Hausaufgabe überlegen: Wie sehen die Sensorsignale (Poti und Stromverbrauch) bei "Bein bleibt hängen" von "Bein bewegt sich wie gewünscht" aus und worin müssten sie sich unterscheiden.

[wrock]

bei bewgung des fußes:
Wenn er wo hängenbleibt bekommen wir einen erhöhten stromverbrauch bei einem wert von servo 1, 2 und 3 die nicht SOLL ist.(zusätzlich könnte überprüft werden welcher servo a meisten strom benötigt, um die belastungsart zu erkennen)

bei bewegung des körpers:
belastung passiert haupsächlich bei servo 2 und 3 da diese heben und servo 1 haupsächlich nach vorne schiebt?
blockiert dann, wenn servo 1 nicht bei der SOLL position ankommt


also geht es im endeffekt um die unterscheidung von bein bewegen, und körper bewegen
mit modular meinst du trennung von laufalgrithmus und regelung, was in unserem fall auf dem raspberry einfach 2 thread bedeuten würde(1 für die berechnung/ steuerung, 2 für den regelkreis)

hört sich zumindest in meinen ohren ganz sinnvoll an

[wrock]

soooo.....
Der Laufalgorithmus wurde wieder hinten angestellt, und es wurden einige strukturelle Änderungen im Code vorgenommen.

Bis jetzt wurde ein kompletter Schritt mehr oder weniger in einem Viereck ausgeführt(aktuelle position, fuß heben, fuß nach vorne, fuß runter-->endposition)
Hat natürliich funktioniert, aber eine schöne Bewegung ist was anderes.

Da wir ja die Aktuelle und die Ziel position haben, hab ich mir volgendes Überlegt:

Zwischen der Anfangs und der Endposition wird der Mittelpunkt berechnet+ein Offset(je nachdem wie "hoch" er steigen soll)

Durch die 3 Punkte im Raum Spanne ich eine Ebene in der ich die 3d Koordinaten in 2d umwandle, und dann durch diese eine Parabelgleichung berechne.

Mit dieser Parabelgleichung kann ich beliebig viele Punkte auf meinen weiteren Weg zu Ziel Position berechnen-->was dann die Gesamtbewegung schön flüssig machen sollte


edit: annäherungsweise(ausgehend davon das y von ist, und soll postion 0 ist) kann man sich die ganze umrechnung sparen und mit x und z die parabel berechnen