Hexapod - "IKU"

[HeXPloreR]

Hallo oberallgeier, danke Dir.

Ja das sind gute Fragen - es gab da so eine CAM irgendwo, mir fällt der Name grade nicht mehr ein, 3.Version oder so...die Gesichter erkennt oder auch Farben im Raum suchen kann...ob die zusätzlich noch was benötigt? Keine Ahnung.
Zum Zitat muss ich sagen das ich mich vorrangig an der Idee der Bewegungsumsetzung von "i.c." festgemacht habe. Nicht explizit an Gesichtserkennung oder upload von Bilder. Und dazu selbstverständlich diesen schönen Körperbau abgeguckt habe.

Zu IKU kann ich nur sagen das sie einen Kopf bekommen wird. Ich habe Sharp Infrarot Sensoren und eine (Funk)Kamera eingeplant. Gesichtserkennung steht bei mit noch nicht an - wenn überhaupt.

Matt's i.c. sieht für mich aus wie eine Ballerina - sollte ich irgendwann in den Genuss kommen einen neuen schöneren Körper aufzubauen, dann werde ich es ganz genauso aussehen lassen. sweet

[HeXPloreR]

Boahhh...ich könnte brechen... schon wieder ein Empfänger der sich abgemeldet hat. Ich habe ja echt kein Problem damit wenn die Dinger keine 11V aushalten und es somit einfach meine eigene Schuldselber ist. Aber dieser hier geht von der einen auf die nächste Minute einfach nicht mehr - für mich gab es hier keinen ersichtlichen Grund warum der seinen Dienst einstellt. Den werde ich also beim großen C vorbei bringen, ist grade mal 2 Monate her wo ich den gekauft habe. Ich bin enttäuscht.

Mein Programm zeigt mir den Empfang im Terminal an, und plötzlich steht da: RC = 0 ' *brechreizunterdrück*

[HeXPloreR]

Kurze Info zur inversen Kinematik:

Im momentanen Programm ist die eigentliche Berechnung für ein Bein über knapp 40 Zeilen Code verteilt. Da man in Bascom nicht mit Klammern arbeiten kann sind die Berechnungen manchmal etwas umständlicher als z.B. in C. Die Berechnung startet jetzt noch an der ersten Beinachse - in der Hüfte - mit dem empfangenen RC-Werten. Später wird diese Berechnung aus der Körpermitte zu den Beinen verteilt werden. Dazu wird die Berechnung der inversen Kinematik nicht erweitert, sondern eine weitere die aus der Körpermitte bis zur Hüfte berechnet angehängt. Die Zuweisung der berechnetet Werte soll dann in eine Schleife mit Zuweisungszähler usw ablaufen.

Der Code für die Berechnung eines Beins hat knapp an der 4kB Codegrenze der Demoversion gekratzt. Ich habe optimiert wo ich es gesehen habe, und möglich war. Einen Wert lasse ich z.B. vorab berechnen, da dieser sowieso aus zwei Konstanten besteht. Allerdings habe ich die Werte später nicht an die SD-21 übergeben können, da das dann die Einbindung der SD-21 über I²C im Programm erforderte, was dann zu viel war. Deshalb die Vollversion.

Ein klitze kleines Fehlerchen habe ich in malthy's Doku für mich im Bildmaterial korrigiert und erweitert. Auch hat sich ein genannter Lösungsweg für mich nicht plausibel erschlossen, da habe ich einen Anderen gewählt, der aber genauso auch mit Winkelergänzungen arbeitet - wohl nur andersrum geht
malthy möchte ich auch an dieser Stelle für die wirklich gute Erklärung der Thematik danken.

[HeXPloreR]

.. schon wieder ein Empfänger der sich abgemeldet hat...*

Vielen Dank an die Mitarbeiter vom grossen C - mein defekter Empfänger wurde anstaltslos gegen einen Neuen umgetauscht. Das ganze hat keine fünf Minuten gedauert ... als ich dann endlich mal dran war, und man das vorherige quer durch den Laden gelatsche mal wegläßt

Ich bearbeite grade die Oberplatten und die Abstandshalter in meiner "Fachwerkstatt" im Keller

Jetzt hoffe ich, das ich bis Sonntag die Zeit finde, weiter aufzubauen und die ersten Bewegungen zu programmieren.

[malthy]

Hallo Hexplorer!

Schön dass ich mal etwas Feedback zu meinem Ansatz bekomme! Ich muss nochmal genau reingucken, so auf den ersten Blick versteh ich noch nicht ganz, wo der Fehler steckt. Aber vielleicht schreib ich dich auch einfach mal per PN an, dann machen wir deinen Thread hier nicht mit irgendwelchem Offtopic-Kleinkram kaputt. Sollte ein echter Fehler in meinem Artikel sein, will ich den natürlich noch korrigieren ...

Bei mir ist die IK noch etwas länger, ich habe 54 Zeilen gebraucht. Ich habe allerdings auch versucht so "explizit" wie möglich zu programmieren, einfach um das Verständnis zu erleichtern. Es gäbe da bestimmt noch Optimierungsbedarf. Du verwendest vermutlich auch Gleitkommaarithmetik, die frisst ja immer Platz (und Zeit). Wenn man die rausschmeißen würde, bekäme man die Sache bestimmt noch komapkter und schneller. Naja, den Ehrgeiz hatte ich damals nicht, da ich noch analoge Servos verwende, bei denen die Updaterate ja eh nur bei 50 Hz liegt.

Also so oder so: vielen Dank für's Feedback und ggf melde ich mich nochmal bei dir. Ansonsten bin ich gespannt auf den Fortschritt deines Projektes!

Gruß
Malte

[HeXPloreR]

Hallo Malthy,
ist nur was klitze kleines (kein echter Fehler) - kein Grund zur Beunruhigung Ändert nichts daran das es gut funktioniert mit Deinen Erklärungen.

Ja, benutze Single-Variablen. Leider ist das erstmal der einfachste Weg für mich, sollte es damit (Zeit)Probleme geben muss ich wohl nachbessern. Oder auf mehrere µC ausweichen.
Momentan beschicke ich eine SD-21 über I²C - soweit ich weiß, aktualisiert die auch nur alle 20ms. Allerdings halten die Digital Servos in der Zeit dazwischen ihre Position, wärend man bei den Analaogen genau merkt wann sie ihr Signal bekommen. Die habe ich aber nur in der Hüfte (Coxa-Servos) eingebaut, da sollte es kaum zu merken sein im Betrieb.

Ob ich wohl zwei oder drei normal arbeitende µC - also nicht als Slave's - an den I²C Bus hängen kann, und die zirkulär auf den Bus zugreifen lassen könnte? Sollte ja gehen, wenn man die Sendetermin per Freigabe mit einem Pin auf High steuert. Hmm, muss ich mir mal genauer überlegen.

Wenn man Gleitkommas rausschmeisst, muss man dann nicht mit noch gößeren Zahlen (bzw Variabken) rechnen? Daher dachte ich es schadet dem Verständniss nicht, wenn es erstmal damit läuft. Da hat man schonmal einige Fehlerquellen aussen vor gelassen. Hoffentlich.

Ich habe nichts gegen OT - vor allem wenn es keines ist

Ich bin genauso gespannt ob das alles so klappt - vielen Dank Dir auch.

[malthy]

Die Gleitkommazahlen braucht man ja auch wegen der Trigonometrie, die Funktionswerte kann man ja nur in Singles schreiben. Und die entsprechende Library (FP_TRIG) nimmt dann auch noch Platz weg. Ich habe vor kurzem mal eine Implementierung eines CORDIC Algorithmus in Assembler für Bascom verwendet (nicht von mir implementiert), damit kann man dann auf Singles verzichten und auch auf die FP_TRIG Library. Ging eigentlich problemlos. Ich bin auch immer versucht mich nochmal wieder an meinen Hexa zu setzen, dann würde ich es glaube ich mit dem CORDIC Ansatz machen. Habe das Projekt ja nie wirklich zu Ende - oder sowas ähnliches - gebracht ...

[HeXPloreR]

CORDIC-Algorithmus? - okay, sieht nach viel Grundlagen lesen und verstehen aus. Ich denke aber auch diese Annäherung reicht völlig aus, vor allem wenn man die Auflösung der Servos bedenkt - und die PWM(Positions)werte wieder Ganzzahlen sein müssen. Ist gemerkt. Vielen Dank für diesen Hinweis.

Ich muss gestehen, das mich die Informationsflut im Netz das eine oder andere Mal doch recht verwirrt hat. Bis ich diese Projekt angefangen habe, um mich genauer auszurichten und gezielter Informationen zu finden. Anstatt mal irgendwie alles so halb gelesen zu haben und davon dann auch nur einen kleinen Teil verstanden zu haben.
Vermutlich war der CORDIC-Algo da schon irgendwann mal mit bei, aber wenn man noch nicht weiß was damit anzufangen ist dann tut man den wohl eher einfach so ab. Der scheint tatsächlich alles zu beinhalten was nötig ist. Schiebeoperationen habe ich in diesem Zusammenhang jedenfalls schon mal gelesen.

Ich denke wenn man erstmal Deine Erklärungen so weit verstanden hat, kann man das auch gut mit CORDIC abarbeiten. Ich muss nur aufpassen, denn ich habe die Achsen getauscht - ich komme mit der Z-Achse als Höhenachse besser klar