bis zu 20 Servos am Mega8 ausgänge frei wählbar

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

Ps Rückmeldungen sind ausdrücklich erwünscht.

Sehr interessant, den Bubblsort-Algorithmus in die Interruptroutine einzubauen. Da hätte ich wahrscheinlich Bedenken gehabt, dass der zuviel Rechenzeit frißt.

Gruß,
robo

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.

grüße hopix

Mhm irgendwo ist mein Thread verschwunden.

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.

ja danke hanno

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.

Gruß Hopix

hi hanno
hab dann gleich mal wa für inverse kinematik gemacht.
schau mal hier

https://www.roboternetz.de/phpBB2/ze...ighlight=hopix

gruß hopix

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

hallo hanno
zunächst danke für deine Erklärungen. Soweit ist das Problem mit der inversen Kinematik allerdings schon gelößt. Zumindest was die berechnung und positionierung jedes einzelnen Beines angeht. Und wie gesagt alles mit nur einem Atmega8. Ich denke da der Berechnungstakt von ca. 10 Hz durchaus ausreichend ist oder?

Deine weitergehenden Erläuterungen sind sicher auch ganz IO soweit aber doch nicht ein ureigenes Problem eines Laufbots. Diese Problematik tritt doch ebenso bei Radsystemen auf. Wichtiger wäre doch sich zuerst über Schrittfolgen Gedanken zu machen, aber dafür mußte mein Hexabot erst einmal Gestalt annehmen. Für meine derzeitigen Kontrollen habe ich im Moment allerdings nur 1 Bein (mal eben zusammengestellt)zur Verfügung, welches ich wechselweise Teste.

@hopix, ganz ehrlich ich kenn hier einige im Forum die einen Hexa mit inverser Kinematik gebaut haben und de haben alle deutlich mehr Rechenpower verwenden müssen als einen Mega8. In sofern würde es mich etwas verwundern, wenn es bei dir funktioniert.

Schliesslich muss jedes Bein individuell berechnet werden und dafür die PWM signale bereitgestellt werden.

hi hanno

na das war eine klare Stellungnahme, ich danke dir dafür.
Dann werd ich mal meine Digicam aufladen. :-)

gruß hopix

ist nicht böse gemeint, ich bin nur in solchen sachen manchmal etwas ungläubisch und wills erst sehen bevor es stimmt.

hi
nene ist schon OK. Wer möchte schon gerne "Enten" aufsitzen. Für konstruktive Kritik bin ich immer offen.

Allerdings wundere ich mich schon ein bischen und stelle mir folgende Fragen:
Ist dieser Code so unglaublich das ich nicht Ernst genommen werde?
Ist der Code so uninteressant da es doch recht wenig Rückmeldungen hier gibt?
Bin ich ggf. im falschen Forum damit?

Wenn du ein STK500 hast stelle ich dir auch gerne eine .hex datei zur verfügung als DEMO mit den entsprechenden Servoanschlußbezeichnungen ausgelegt für Standardservos.

gruß hopix

PS mal sehen das ich das mit dem Video morgen erledigt bekomme

@hopix sagen wir es anders mein Programm oder Algo dafür umfasst 800 Lines of Code. Der von MeckPommER umfasst pro Atmega32 etwas weniger aber auch insgesammt 800. Damit würde es einen also wundern wenn es mit weniger als 800 Lines geht.

Aber ich hab mir gerade nochmal deinen Code angesehen und weis jetzt auch wo das Problem ist:
Du steuerst nur ein Bein und kommst auf 10Hz ansteuerung.

Für MeckPommER und mich hat sich ergeben, dass Servos mindestens mit 50Hz angesteuert werden müssen und noch dazu 6 Stück, d.h. für jedes Bein bleiben ~3,3ms für die Berechnung. Außerdem ist es Pflicht bzw. notwendig jeden Servo mit Signalen zu versorgen auch wenn seine Berechnung gerade nicht erfolgt. D.h. solange keine neuen Werte berechnet wurden müssen die alten Werte an den Servo übergeben werden.

Außerdem ist dein Algo nur die Bewegung für ein Bein d.h. die Bewegung aller 6 Beine mit unterschiedlichen Startpositionen fehlt komplett (nein die bewegen sich nicht synchron wenn sie mal gestartet haben, sondern alle individuell).

Mit diesem Algo wirst du auch keine Kurfen laufen können und nicht schräg oder seitwärts. Aber gerade darin liegt die Stärke der IK.

Hier ein Reverenzvideo von Profis:
http://www.youtube.com/watch?v=gsCbvl5Bak8

und natürlich zum verleich mein eigener Roboter:
http://www.youtube.com/watch?v=SEEkO_U-VHM

Schau dir da mal jedes Bein ganz genau an wie es sich im verhältnis zu den anderen bewegt.

So ich bin soweit mit dem video.
http://de.youtube.com/profile?user=d...oP2H0ucEn3fNQ=

hier ist u.a. die 50Hz Servosignale zu sehen.
Keine bange ich schummel nicht :-) es werden 6 Beine berechnet, und die nicht benötigten ergebnisse ins nirvana geschickt. Leider mußte ich bei den Servoausgängen auch ein wenig tricksen sonst hätte ich ja keine Eingabe mehr gehabt. Aber auch hier sein versichert es handelt sich um mehr als nur die 3 zu sehenden Servos.

wollt ihr euch den kompletten code dazu noch mal ansehen?

Zu euren rund 800 lines, Ich habe ja nicht behauptet das mein hexa damit schon laufen könnte. Wichtig ist aber das die Position der Fußspitze jetzt in globalwerten angegeben werden kann. Die gewünschten Positionen sollte man dem mega8 jetzt per Schnittstelle mitteilen, also übergeordnet Bewegungsablauf programmieren. Aber dazu brauche ich erst einmel einen kompletten Hexabot.

Ach ja eines will ich nicht verschweigen ein kleiner fehler steckt da noch in der inversen kinematik, beim überschreiten einer gewissen Position geht der Fuß ganz nach unten. Den Fehler bin ich gerade noch am suchen, ein geschwindigkeitsproblem wir nach meiner einschätzung dadurch aber nicht entstehen.

hopix

Was ist los Jungs? Seid ihr in Ohnmacht gefallen? ;-)

Hallo hopix :-)

Na, das nenne ich doch mal eine Herausforderung, einen Hexapod mit 18 Servos mit einem Mega8 zum Laufen zu bekommen!

Ob das nun geht oder ob du noch was Wichtiges vergessen hast, darüber brauchen wir uns ja nicht groß zu unterhalten, das merkst du ja selber, sollte es so sein :-)
Sicher ist aber, das du neu entwickelst und dabei vielleicht sogar einiges besser machst als wir. I drück you alle Daumen und bin neugierig :-)

Was meiner Meinung nach auch viel Rechenpower frisst ist die Tatsache, das die Beine ja nicht nur einzeln ein anderes Ziel ansteuern müssen, sondern auch ersteinmal deren Ansatzpunkt (oder auch Montagepunkt am Hexapod) im Raum berechnet werden muss.

Mein Ansatz, das Ganze auch mehrere Controller aufzuteilen, war einfach Sicherheitsdenken. Ich wollte nach Möglichkeit nie am Limit des Controllers arbeiten, sondern stets auch noch genug Rechenpower zur Verfügung haben, um weitere Funktionalitäten in die Beine einzubasteln.

Eine dieser Funktionen, für die ein Mega8 dann auf jeden Fall nicht ausreichen dürfte, ist bei meinem Bot die Berechnung, welches Bein denn nun als nächstes zu Bewegen ist. Ich folge da keiner festgelegten Sequenz, sondern lasse die Beincontroller berechnen, wie weit die aufgesetzte Fussspitze eines Beines vom optimalen Standpunkt entfernt ist. Diese Entfernungsangaben werden zum Mastercontroller übermittelt, der dann (auch anhand von nicht realisierbaren Beinkombinationen) ermittelt, welches Bein nun zu setzen ist.

Hier mal mein Marvin auf Wanderschaft :-)

http://www.youtube.com/watch?v=6nKnlEey-go

hi meckpommer
zunächst einmal
Danke fürs Daumen drücken.

Das Problem hierbei sehe ich allerdings weniger in der Rechenpower. Derzeit läuft es mit 8 Mhz internem Takt. Da "nur" 18 Servos benötigt werden kann man ja getrost auf 2 Stk von den 20 maximal möglichen verzichten und hierfür die Quarzanschlüsse freilassen. So kommt noch einiges an Rechenpower hinzu.

Ein Mega32 hat davon ja auch nicht mehr.

Das Problem liegt eher in dem begrenzten Programmspeicher. Der ist schon zu ~ 95% voll. Hier reicht es also gerade noch für die Schnittstelle.

Deine Idee deiner Beinberechnung gefällt mir, ebenso das Video.
Mal sehen wie ich das hinbekomme.

mfg hopix

Hallo hopix

Wenn du beim mega8 an Speichergrenzen kommst nimm doch den mega168, der hat 16kB statt 8kB.

ja danke helmut
da hab ich auch schon dran Gedacht. Nur, Mega 8 hab ich einige von da und sonst Mega 16/32. Obs dann lohnt sich diesen auch noch hinzulegen?

Den Mega 8 habe ich gewählt um ihn auch in meinen Modellen einsetzten zu können (der Baugröße wegen). Das Prg ist jedoch so gehalten das es leicht portierbar sein sollte.

hopix

hopix

Der mega168 hat auch noch die ssehr interessante Funktionalität der PCINT an jedem Pin. Man kann also im controller über jedes Pin einen Interupt auslösen. Ich verwende den mega8, da der "preiswerteste", also viel Funktionalität und Speicher für 1,70 € bei Reichelt, den mega168 immer dann wenns nicht reicht für 3,20 € bei Reichelt. Beim Wechsel zum mega16 oder mega32 muß man die Hardwarte ändern, zum mega168 nur etwas bei der Software.

danke helmut
das ist ein Argument. Ich glaube ich sollte mir die Bauteile doch ein wenig näher ansehen.
beste grüße hopix

Hallo hopix,

durch Neugierde getrieben, hier nochmals ein paar Anmerkungen von mir:

Was - zumindest bei meinem Bot - an meisten Rechenpower frisst, sind die trigonometrischen Funktionen. Nun gibt es ja verschiedeste Möglichkeiten, diese Funktionen zu realisieren und es würde mich interessieren, wie schnell die Berechnung in der von dir verwendeten Programmierumgebung erfolgt. Könntest du mal einen kleinen Benchmark dazu machen und posten, wieviele z.B. SIN du bei welcher µC-Frequenz schaffst?
Leider benötige ich arg viele dieser Funktionen um die Beine genau zu steuern. Zuerst müssen ja die Montagepunkte der Hüftservos je nach Winkel des Bots im Raum gedreht werden (ich bezeichne die drei Servos eines Beins als Hüft- Knie- und Fußservo). Das sind schon 6 Aufrufe pro Bein.
Dann kommt der zu berechnende Versatz, der Dadurch zustande kommt, das Hüft und Knieservo nicht an einem Punkt liegen. D. h. der Montagepunkt des Knieservos dreht sich um den Hüftservo in der Entfernung der Länge des Oberschenkels. Das bringt nochmal 6 Aufrufe pro Bein.
Dann die Stellung des Knie- und Fußservos, das sind nochmals einige Aufrufe (hab jetzt nicht gezählt, auch geschätzte 6)
Das macht 18 trigonometrische Funktionen pro Bein (bei mir 2 an einem Controller) und das 50 Mal pro Sekunde.
Für alle 6 Beine ergibt das - zumindest bei mir - über 5000 trigonometrische Funktionsaufrufe pro Sekunde und dazu kommen noch jede Menge Multiplikationen etc. - zuviel für einen Mega8

Mein gedankliches Fazit ist derzeit: entweder mache ich das viel zu kompliziert oder Bascom erledigt die trigonometrischen Funktionen nicht sehr effizient oder deinen Beinbewegungen fehlen einige Berechnungen oder oder oder ...

Ich bin auch grade am schauen, ob es schnellere Assembler-Routinen für diese Funktionen gibt. Auch wenn meine Controller mit 2 Beinen noch einiges an Luft haben, so kommen ja noch so spanndende Dinge von Hinderniserkennung bis Treppensteigen, für die die Controller auch noch "ein wenig" Rechenpower übrig haben sollten.

Hi Meckpommer

Benchmark Sinusfunktion
wie gewünscht hier ein Benchmark für die Sinus/Arcsinusfunktion. Er berechnet, angefangen von 0 bis einschließlich 90 Grad jeden Sinus im Raster von 1 Grad Schritten, zur Kontrolle rechne ich diesen in der Schleife über arcsin wieder zurück. Die benötigte Zeit liegt laut Simulation mit AVR Studio bei 4 Mhz Takt bei 312014,5 uS ohne Optimierung wobei ich den Winkel in Degree berechne (siehe faktor). Mit Optimierung ist das mit 310218,0 nur unerheblich weniger.
52,25/43,25 uS gehen davon auf den Programmstart.

Anbei das Programm dazu.

#include <avr/io.h>
#include <math.h>
double winkel;
double sinus;
double winkel_back;
static double faktor_degree = 180/M_PI;
// winkelberechnung im degree
void main (void)
{ for (winkel = 0; winkel <= 90; winkel +=1)
{ sinus= sin(winkel/faktor_degree);
winkel_back = asin (sinus)*faktor_degree;
}
asm volatile("nop");
}

Wenn du mags kannst du mir die Ergebnisse deines Benchmark ja Mitteilen. Ich bin schon gespannt erwarte aber nur unwesentliche Unterschiede. Da diese wie ich glaube auf ähnlichen Algorythmen beruhen.

Derzeit arbeite ich beim mega8 mit 8Mhz internem Takt.

So nun weiter. Du sprichst hier von 6 Aufrufen (ich verstehe das so das du trigon funktionen damit meinst) pro Bein. Also ich komme da auf 3, ich muß allerdings dazusagen das ich den Offset zwischen Drehpunkt Hüfte-Knie derzeit noch vernachlässige. Natürlich verwende ich auch noch Berechnungen zum rechtwinkligen Phytagoras, diese sollten von der benötigten Rechenzeit aber eher eine untergeordnete Rolle spielen. Hier mein Code dazu.



uint8_t winkel_berechnen (double l,double b,double h)
{ /* in länge breite höhe */
double w1,w2,w3, ZW;

ZW = sqrt(l*l+(b)*(b));
w1 = asin (l/ZW)*faktor_degree; /*erscheint IO*/
ZW = sqrt(h*h+ZW*ZW);/* schräge lage b-h*/
if (ZW < schenkel2*2)
{ w3 = 2*asin((ZW/2)/schenkel2*faktor_degree; /*erscheint IO*/
w2 = 180-90-(w3/2)-asin(h/ZW)*faktor_degree;/* erscheint IO*/
if (w2 > 90)
w2 = 90;
winkel1 = w1;
winkel2 = w2;
winkel3 = w3;
return (1);

return (0);
}

Die Winkel zum oben genannten Code sind Hüft(1) Bein(2) Fuß(3)



Da du erwähnst das du für den Hüfte-Knie Offset nochmal 6 (trigon?) berechnungen benötigst gehe ich davon aus das deine Uberlegungen ein wenig "hinten rum" gedacht sind. Ebenso verhält es sich meines erachtens mit Knie-Fuß (6 geschätzte von dir).

Meine Überlegungen sehen dazu folgendermaßen aus.

Nimmt man an das das Bein komplett angewinkelt ist und rechtwinkelig weg steht, so ist die einzige Möglichkeit den Fuß weiter zu entfernen das Fußgelenk. Die einzige Möglichkeit den Fuß nach vorn/hinten zu setzten Das Hüftgelenk. Das Kniegelenk hat also die aufgabe beide feststehenden Größen miteinander zu verbinden und wird deshalb zuletzt berechnet.

Nun berechne ich zuerst die Richtung des Hüftgelenks als Vector zwischen l(änge) und b(reite) mit einem Zwischenergebnis der Entfernung des Fußes in der Horizontalen (dieses wird später nochmals verwendet).

Als nächstes wird (als zwischenergebniss)die Entfernung des Fußes im Raum berechnet (also die Raumdiagonale zwischen Pos 0,0,0 und Fußpunkt) unter verwendung des ersten Zwischenergebnisses als Kathete und der h(öhe).

Die If abfrage vergesen wir hier mal sie dient der Fehlerabfrage wenn die Raumkoordinate außerhalb des erreichbaren liegen.

Bei W3 wird der Winkel des Fußes berechnet, er steht durch die oben erwähnte Raumdiagonale fest. Man teilt die Raumdiagonale durch 2 (Gegenkathete) und verwendet die Beinlänge (Hypothenuse). Das Ergebniss ist der halbe Fußwinkel.

Bis jetzt habe wir 2 Winkel bereits berechnet, der 3. (w2) ist der Kniewinkel, Bedenkt man das die Summe aller winkel im Dreieck 180 Grad betragen muß und ich mit rechtwinkligen Dreiecken rechne steht der Gesamtwinkel des Hüftgelenkes zur raumdiagonalen schon fest (180 -90- w3/2) hiervon ist lediglich der Winkel der Raumdiagonalen zur Ebene abzuziehen.

Das wars schon!

Zugegeben so rein mit Text klingt es schwierig, ich habe daran auch ein wenig "geknüstert". Am besten ist wenn du dir Bilder dazu machst dann geht das.

Also brauche ich durch meine vereinfachungen (beide schenkel gleich lang; Offset vernachläsigt) 2* Phytagoras 3* Trigon. Das ganze klappt neben dem Interrupt der 20/18 Stervosignale mit 50HZ in ca. 1/10 Sec (berechnung für alle 6 Beine).

Zugegeben für eine Bahnsteuerung noch en bischen zu wenig, aber Point to Point mit 10 HZ ist doch schon mal was und als Option hab ich ja noch die 16 Mhz.


Als letztes sei noch angemerkt, es war von mir nie beabsichtigt alles (komplette Botteuerung) in einen Mega8 zu packen. Errinnert euch an den Anfang mir ging es eigentlich erst einmal darum reichlich Servos mit eimen ATmega8 anzusteuern. Da ich hierzu nichts wirklich befriedigendes im Netzt gefunden hatte hab ich mir gedacht das dieses evtl. auch für andere interressant sein könnte. Aufgrund der Verbleibenden Rechenpower habe ich mich dann mal an die Inverse Kinematik gewagt. Mal sehen wie es weitergeht.

gruß hopix

Hallo hopix,

ersteinmal vorweg: klar hast du nie behauptet, einen bot mit IK komplett in einem mega8 zu realisieren. Es geht mir auch nur darum, das du scheinbar etwas ganz anders machst als ich, und mir das genau anzuschauen und zu hinterfragen kann mich nur weiterbringen :-)
Nur weil mein Bot laufen kann, bedeutet das ja nicht automatisch, das ich schon eine gute Lösung gefunden habe. Manchmal sieht man vor lauter Variablen die einfachere, elegantere Lösung nicht.

Zunächst mal zur SinCos-Geschwindigkeit. Ich sehe, das du das alles in Double realisierst, was noch etwas zeitaufwändiger als meine single-Berechnungen zu sein scheint. Über den Daumen kommst du auf ca. 2300 Trigs pro Sekunde, wenn ich die 4MHz mal auf 16MHz hochrechne. Das scheint mir nicht wirklich viel zu sein. Ich hatte das mal getestet bei mir und bin bei einem mega32 bei 16MHz und singleberechnung auf etwa 9000 gekommen (kann mich auch irren - ohne garantie ^^)

Die Unterschiede, soweit ich sie momentan sehe, liegen in folgendem:
- mein bot rechnet alle beine mit 50Hz
- oberschenkel und unterschenkel meines bots sind nicht gleich lang
- mein bot rechnet den Offset zwischen Drehpunkt Hüfte-Knie mit ein

Beim Anblick deiner Gleichung zur Beinberechnung scheint mir was zu fehlen, was vielleicht erklärt, woher meine zusätzlich benötigten Trigs kommen:
- Wo das jeweilige Bein im Raum anfängt, also der 0,0,0-Punkt ist, hängt von der Drehung des Bots im Raum ab und von der Distanz der "Beinanfänge" am Bot zu dessen Rotationspunkt ab.
- Der Bot bewegt sich im Raum. Wenn sich ein Bot dreht und er nicht mit seinem Mittelpunkt im Mittelpunkt des Raumes ist, so erfordert die Berechnung seiner neuen Koordinaten im Raum etwas mehr Aufwand.

Was die Steuersignale angeht, so erzeuge ich diese auch ein wenig anders. Ist ja auch etwas einfacher, da ich ja pro Controller nur 6 Signale erzeugen muss. Ich generiere die mit einem Interrupt und einem 16-Bit Timer nacheinander. Das hat den Vorteil, das die µC-Auslastung unter 1% liegt.

Gruß MeckPommER

P.S.: das mit dem single-Trigs benche ich am Wochenende nochmal aus.

hi meck
das mit dem anschauen anderer Lösungswege ist sicherlich hilfreich und richtig. Manchmal verrennt man sich halt.

Bei meinem Benchmark handelt es sich jedoch nicht wie du ggf. verstanden hast um Sin & Cos sondern um Sin und dessen Umkehrfunktion. Das mit den 2300 Trigs hab ich auch herausbekommen hierbei muß allerdings berücksichtigt werden das die Schleife auch eine gewisse Zeit benötigt, ebenso die Umrechnung auf degree. Das mit dem double solltest du nicht so ernst nehem intern wird diese mit einfachem float ausgeführt.

Unterschiede:
du benutzt 50Hz, ob meine 10 Hz reichen muß sich erst noch zeigen. Hast du dir mein Video schon eimal angesehen?
Ober<>Unterschenkel das macht die Berechnung natürlich "interessanter".
Offset ich denke die Berücksichtigung dessen wird mir keine Probleme bereiten, wobei ich diesen durch den geplanten mech. Aufbau auch wesentlich kleiner halten kann als bei deinem Bot. ~ Servobreite.

Das mit deinen Servosignalen stellt sich natürlich eheblich einfacher dar, Timer 1 CompareA CompareB dann noch den Overflow, sowas brauch selbstverständlich kaum Rechenzeit. Schränkt aber den Einsatz der Software ein. Der Vorteil meines Codes ist doch das man ihn für so ziemlich alles einsetzten kann, man kann bis zu 20 Servos einsetzten und die gewünschten Ausgänge frei wählen. Das Ganze wird natürlich durch die Rechenzeit erkauft.

gruß hopix

Hi hopix,

japp, volle Zustimmung - 20 Servos mit frei wählbaren Ausgängen, das ist ne tolle Leistung. Grade die Sache mit den frei wählbaren Ausgängen war mir auch wichtig, darum habe ich die PWM-Erzeugung auch zu Fuß gemacht mit einem Timer gemacht der mir die Ausgänge schaltet, die ich möchte. Nach meiner Methode geht das aber nur bis ca. 10 Servos.

Du machst Servosteuerung und nebenbei IK.
Ich mache IK und nebenbei Servosteuerung.

Offset ist bei meinem Bot natürlich extrem groß, das stimmt. Aber auch ein kleines Offset kann sich stark und unangenehm bemerkbar machen, kommt auch auf die Beinlänge an.

Meine Vermutung, da ich auch schon mal ein wenig experimentiert habe: 10Hz Werteerzeugung "geht", ist aber nicht sehr geschmeidig. Wird nicht zuletzt Geschmackssache sein ob du damit zufrieden bist. Ich empfand es als zu ruckelig. Hätte selber nicht gedacht, das mir 10Hz nicht reichen.

Das mit dem Benchmark ist mir bewußt, nur Benchmarkmäßig bin ich ersteinmal davon ausgegangen, das alle Trig-Funktionen ähnlich lang dauern und asin und cos gleichschnell sind.

Neugierde: wenn die Trigs alle intern in single ausgeführt werden, warum dann das drumherum an Variablen in Double? Wäre es nicht effektiver, alles durchgehend in single zu rechnen? Ich könnte mir vorstellen, das dies nicht nur Variablenplatz spart sondern auch spürbar schneller ist.

Gruß MeckPommER

hi mec

Die routine ist auch bis 22 Servos leicht erweiterbar. Aber ehrlich gesagt macht das ja wenig Sinn. Woher sollten dann die Kommandos kommen, nur aus einer internen Schleife? :-)

Aber durch die freie belegbarkeit ist man in der Wahl der Ansteuerung eben recht ungebunden.

Zum Offset warte ich erst einmal ab bis ich erfahrungen mit der Mechanik gesammelt habe, da bist du mir ja um Längen voraus. Es sollte evtl. reichen die in der horizontalen Kathete hinzuzuzählen (nur dort).

Ich glaube auch das ich mit 10 Hz auf Dauer nicht glücklich werde aber für den anfang ist´s Ok, die Rundungen werden halt etwas eckig bei großen Bewegungen.

Um deine "Neugierde" zu befriedigen, schneller wirds dadurch nicht, habs gerade versucht.
Zur erklärung, das stammt wohl daher da ich früher einmal PC´s programmiert habe da sind die Leistungen ja bedeutend höher. Es war eben mehr ein Reflex Double zu verwenden.

hopix

Hi hopix,

ich möchte jetzt einen Servocontroller für meinen Hexapod programmieren (avr-gcc). Der Controller soll nur die PWM Signale erzeugen und keine Berechungen ausführen.

Die Positionen sollen via UART mit einer Geschwindigeit >=38400 Baud zum Controller gesendet werden. Außerdem wollte ich einen Baudratenquarz mit 14.7456MHz verwenden um keine Probleme bei der UART Komunikation zu bekommen.

Für meinen Controller wollte ich auf deinem Source-Code aufbauen und dich fragen, ob du noch eine aktuellere Version hast?

Viele Grüße,
Sascha