Hexapod - "IKU"

[oberallgeier]

Hallo HeXPloreR,

alle Achtung, ein hübsch umfangreiches Projekt - und schon ne Masse Arbeit die Du reingesteckt hast.

... meinen fast fertigen Hexapod "IKU" ... Ich orientierte mich dabei an Matt Denton's "i.c. Hexapod" ...

Hat Du eine Vorstellung davon, wie/womit die Gesichtserkennung bei dem Hexapod von Matt Denton funktioniert? oder funktionieren kann? Bei micromagicsystems.com steht "... pan/tilt head that includes a CCD video camera linked to an off board PC running face recognition software ...". Mich würde ein bisschen so ungefähr der Umfang interessieren - Umfang hard- und softwaremässig. Und eher nur aus Interesse *ggg*. Gibts nicht schon "embedded" Cams mit Gesichtserkennung - ohne dass ein Rechner dran hängen muss? Zumindest mit ner Art Gegenstandserkennung?

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