Hallo alle
ich bis soeben als neues Mitglied hier angemeldet und wollte direkt mal etwas von mir vorstellen.
Es ist noch in der Erprobungsphase, aber ich denke es macht schon Sinn hier mal die Meinung von anderen dazu zu hören.
Bei dem Code handelt es sich um eine Interruptroutine für einen ATmega8 (leicht auch auf andere anzupassen) zur Ansteuerung von bis zu 20 Servos wobei die Pinbelegung frei wählbar ist. Die CPUbelastung liegt hier so wie ich das sehe bei ca. 30 %, für eigene sachen dürfte also noch genügend rechenleistung bereitstehen.
Also gennau das richtige für den von mir geplanten Hexapot.
mfg
hopix
Fürn hexa solltest 50Hz für die Servosignale schaffen und inverse kinematik online berechnen, fürchte der Mega 8 reicht da bei weitem nicht aus. Aber man kann ja mehrere Parallel schalten.
hi hanno
50 Hz na klar (selbstredend) ohne dem geht es nicht. Sonst würde das für die Servos auch nicht gut gehen.
Einfache sachen/bewegungen sollten auch direkt im mega8, bei voller Servoauslegung (20), gehen ist ja noch etwas an Rechenleistung über.
Die übergeordnete Logik kann dann bei Bedarf ein weiterer Controller übernehmen, hierfür sind 2 weitere ports frei für die Komunikation. Von "mehreren parralel" würde ich eher Abstand nehmen es sie denn man legt die Beine einzeln aus. Genau das stebe ich jedoch nicht an, so kann man die Kollisionskontrolle warscheinlich noch in dem selben controller implementieren was die Kommunikation erheblich entlastet.
Der Vorteil von dieser Software ist jedoch die flexibilität. Mann muß ja nicht alle Servoausgänge benutzen wenn man die nicht braucht und gewinnt dadurch zusätzliche kappazität, und wenn man doch noch eins benötigt ist das kein Problem.
Du solltest den Code einmal versuchen ich glaube das es sich lohnt, desweiteren gehe ich davon aus das da noch einiges rauszuholen ist.
Ich komme aber im Moment nicht drauf was du mit "inverser Kinematik" meinst. Da könntest du mir bitte nochmal helfen.
gruß hopix
Nachtrag:
um die Routine an die verschiedenen einzusetzenden Servos anzupassen
entweder
generell in den #define Anweisungen carsm_min /carsm_max
oder
einzeln (bei verschiedenen verwendeten Servos) in der Routine "servoset_generell" bei den Einträgen servo_gen[x].absmax/min.
Die von mir zur Probe eingesetzten carson mimi Servos vertragen einen Puls von ca ,62 ms bis 2,36 ms das ist ggf für andere Servos schon zu wenig/viel. also lieber erstmal vorsichtig rantasten.
gruß hopix
Sehr interessant, den Bubblsort-Algorithmus in die Interruptroutine einzubauen. Da hätte ich wahrscheinlich Bedenken gehabt, dass der zuviel Rechenzeit frißt.
hi robo
na ja ne Bubblesort von 20 Werten ist ja nicht so zeitraubend. Und sicherheitshalber arbeite ich die erst nach den zeitkritischen Sachen ab obwohl hier einiges an Zeit totgeschlagen wird (das zum Thema "noch einiges rauszuholen").
Desweiteren habe ich schon die nächste Version in Arbeit worin eine, gerade bei einer Servowegbegrenzung, erhebliche erhöhung der Auflösung enthalten ist, bisher wurde die leider intern mit begrenzt.
Neben der erweiterten Dokumentation wird eine #define für Standardwerte der Servos sowie eine Demo enthalten sein.
Schau mal bei Wikipedia nach inverser Kinematik dann weist du was ich meine. Kurz gesagt wird über die Längen der Beine und Sinus und Cosinus zurückgerechnet welchen Winkel die Servos für die eingestellt werden müssen um die Zielpositionen zu erreichen.
Sinus und Cosinus und deren Umkehrfunktionen sind leider keine einfachen Berechnungen und daher sind Controller gut die bereits entsprechende Tabelle im Speicher implementiert haben.
das war mir im Grude schon klar nur das man dieses so nennt war mir noch nicht geläufig. Habs mir aber bereits grob angeschaut.
Na ja das wird dann auch wohl die nächste Baustelle. Ich denke um die Sache zu vereinfachen sollte man Ober und Unterschenkel zunächst in der gleichen Länge auslegen.
@hopix, also vorweg gleich mal, das mit der Inversen Kinematik hört sich schrecklich kompliziert an, ist es aber für Hexas nicht.
Man braucht auch nicht die Längen gleich auslegen, Länge der Schenkel oder des Fusses sind einfach zwei Konstanten fertig aus. Wie gesagt mit cosinus, arccosinus, sinus und arcsinus und vielleicht noch etwas Tangens lässt sich alles berechnen.
Bei meinem Roboter sieht das in etwa so aus.
Es gibt eine Berechnung um den Abstand der Fussspitze zum Hüftgelenk als Funktion der Winkel von Schulter und Fuss zu berechnen (abhängig von der Konstanten Höhe des Systems).
Dann gibt es einen Algo der eine virtuelle Linie erzeugt auf der sich die Fussspitze bewegen muss. Diese Linie koreliert mit der Bewegungsrichtung des Roboters. Z.B. soll der Roboter gerade laufen, dann ist die virtuelle Line parallel zum Roboter. Soll er schräg laufen dann wird sie um den entsprechenden Winkel gedreht.
Damit hat man auch schon die ganze translatorische Bewegung erschlagen.
Um den Roboter um einen beliebigen Punkt im Raum zu drehen (der kann auf dem Roboter liegen dann rotiert der Roboter um die eigene Achse oder ausserhalb dann läuft er z.B. um eine Flasche herum) wirds etwas komplizierter. Die Länge der virtuellen Linie und der Winkel ändert sich für jedes Bein (wieder in Abhängigkeit von der Position des Drehpunkts). Alternativ kann man die Linie auch gleich lassen und die Geschwindigkeit der Bewegung des entsprechenden Fusses verändern.
Wie die einzelnen Längen und virtuellen Linien mit den Servowinkeln zusammenhängen ist reine Geometrie.
Fertig sieht es bei mir dann so aus: move_trans(90.0, 3)
Sprich eine Bewegung mit Winkel 90° (gerade nach vorn) für 3 Schritte
oder: move_rotation(0, 400, 270.0)
x-Position und y-Position des Drehpunkts im mm vom Robotermittelpunkt aus und dann um 270,0° um diesen Punkt drehen.
Mit nur noch diesen beiden Funktionen steuer ich den ganzen Roboter in der Bewegung.
Zitieren
Lesezeichen