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

[Hellmut]

Hallo hopix

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

[hopix]

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

[Hellmut]

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.

[hopix]

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

[MeckPommER]

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.

[hopix]

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

[MeckPommER]

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.

[hopix]

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

[MeckPommER]

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

[hopix]

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