Hexapod

[HannoHupmann]

Dann hast du die falschen LiPos :-P. Ganz in ernst, es gibt im Moment keine Akkus die annähernd an das Energie/Gewichtsverhältnis der Lipos ran kommen und bezahlbar sind! Abgesehen davon bekommt man heute Lipos schon für 30 bis 50€ mit ausreichender Leistung. Dann kann man schwächere Servos einsetzen und spart sich dort wieder einiges. Die grundsätzliche Herangehensweise ist einfach immer: so leicht wie nur möglich!

Laufalgos gibt es mehr als genug im Forum. In meinem Vinculum Projekt gibt es sogar einige Seiten dazu, wo ich über verschiedene Versionen diskutiere. Für eine genauere Aussage, solltest du die Frage etwas näher spezifizieren.

EDIT: Die Fragestellung ist übrigens fast schon so alt wie die Entwicklung von Hexas selbst: Modulares Konzept bei der Steuerung oder doch lieber ein zentraler Controller? Bisher habe ich im Forum immer wieder beide Lösungen gefunden und auch genug User die von modular auf zentral gewechselt haben oder in die andere Richtung von zentral zu modular. Ist also immer eine Frage der persönlichen Vorlieben, denn die Aufgabe bleibt ähnlich komplex.

[wrock]

So, erst mal zur Ansteuerung...hab mir folgendes Überlegt:

Aktuell sieht die Befehlstruktur so aus:

1. CommandForward wird aufgerufen
2. neue Position wird per IK aus der aktuellen Position berechnet
3. Laufalgorithmus startet
4. bei fertigstellung des kompletten wird auf den nächsten Befehl gewartet.

Vorteil: einfach implementiertung
Nachteil: Feedback der Servos kann nicht verarbeitet werden, neue Befehle werden erst nach Abschluss des Algos neu verarbeitet-->sehr langsame Reaktionszeit


Neuer Ansatz:

1. CommandForward wird aufgerufen
2. neue Position wird per IK aus der aktuellen Position berechnet
3. befehl für Fuß1 wird geschickt
4. es wird auf fertigstellung per Polling gewartet(in unserem Fall bekommen wir die Winkel zurück)
5. die IST-Position wird mit der SOLL-Position verglichen,
6. falls unterschiedlich oder neue wir bekommen einen neuen Befehl(z.b richtungsänderung) wird die Position neu berechnet,
7. ansonsten wird der Laufalgorithmus abgearbeitet-->befehl für Fuß2 wird geschickt

Vorteil: Nach jedem Schritt kann reagiert werden, ob nun auf Unebenheiten, Blockierungen oder neue Befehle.
Nachteil: Es kann immer nur ein Fuß bewegt werden-->Geschwindikeits defizit


Kompromiss[beste Lösung?]

1. CommandForward wird aufgerufen
2. neue Position wird per IK aus der aktuellen Position berechnet
3. Befehl für Fuß1, Fuß3, und Fuß6 werden geschickt, abhängig vom Laufalgorithmus können sowieso nur eine gewisse Anzahl an Füßen in Bewegung sein(dirty bit)-->kein Zeitverlust
4. Polling auf Fuß1, Fuß2 und Fuß3 für Rückmeldung
5. Sobald 1 Fuß rückmeldung gibt, wird die IST-Position wird mit der SOLL-Position verglichen,
6. falls unterschiedlich oder wir bekommen einen neuen Befehl(z.b richtungsänderung) wird die Position neu berechnet,
7. ansonsten wird der Laufalgorithmus abgearbeitet

Vorteil: keine Leerzeit, Feedback/Reaktionsfähigkeit sehr hoch
Nachteil: kompliziertere Implementierung?

[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.