Werbung
...wir sollten das nächste Mal mal ein Erkennungszeichen ausmachen - dann weiss man auch mal im Gewusel, dass man den Gegenüber ja auch durchaus "kennen" könnte. Den Oberallgeier habe ich z.B. am Stand von Malte zufällig kennengelernt.
- Vielleicht eine Ventilatorblume ins Knopfloch oder so -
...aber die Idee ist gut. Ich wäre dafür das wir sone Pins zum anstecken mit mindestens Community und dem Nickname versehen
Andree, eure T-Shirts die waren ja schon sehr gut auffällig. Hattest Du mir nun eigentlich den Tischtennisball vorbeigebracht? - ich muss gestehen, es war mir ein µ zu laut dort, ich habe Deinen Namen nicht richtig verstanden, nur interpoliert
jipp...Andree aus der Hansestadt Bremen hatte Dir einen "Jörg" vorbeigebracht, allerdings ohne Schnörkel...weil das Drucken der Dinger der Lütte vom Vereinskollegen übernommen hat....und der war gegen Ende so unglaublich platt, der ist mir noch im Parkhaus auf der Rücksitzbank eingepennt.
http://www.haz.de/Hannover/Fotostrec...ire-im-HCC#p14
Zitat von Andree-HB
Ja, und ja. Ich hatte mir ein Schildchen, passend zu meiner Umhänge-Eintrittskarte ausgedruckt, große, dicke, deutliche Schrift - und recht früh das Halsband abgelegt; es war einfach ALLES zu heiß. Ich glaub ne Nadel mit aufgeklebtem RN-Logo (dazu Nick, evtl. "RN" - zur Erinnerung) im 20mmx20mm-Briefmarkenformat wäre praktisch. Evtl. für Sommertage auf Luftpostpapier *gg*.
Na ja, vielleicht bei teureren Servos. Aber auch dafür würde ich die Hand nicht ins Feuer legen. Über diese Pleite beim RS-2 hatte ich ja schon berichtet, der größengleiche HK-Typ von Pololu hat da sehr viel weniger Abweichung, erstmal kaum merkbar; wieviel konnte ich bisher aus Zeitmangel nicht er-messen. Aber das kommt - mit Bericht. Bei diesem Messaufbau will ich auch gleich mic´s Perioden-Pausen-Sensorik (mic - danke für die Erinnerung und den Link) aufbauen und testen.... weil der Servo ein geregeltes System ist, kann man sich (unter einigen Randbedingungen natürlich) "sicher" sein...
Geändert von oberallgeier (05.08.2013 um 13:32 Uhr)
Ciao sagt der JoeamBerg
Moin Moin,
ich wollte nur mal einen kurzen Zwischenstand abgeben:
Das Bascom Programm ist nun soweit umgeschrieben das jedes Bein seinen eigenen nächsten anzufahrenden Punkt bekommt.
Vorher hatte ich es ja sinngemäss eher so gelöst dass alle Beine das gleiche tun - sie standen also parallel und hatten dementsprechend auch die gleichen Winkel zurückzulegen um den Körper zu bewegen. Die Beine hatten auch noch keinen rechnerrischen Bezug zum Körper - auch das ist jetzt integriert, alle Berechnungen gehen vom "Centrum" (x=0; y=0, z=0) des Körpers aus. Und die IK berechnet, nachdem der Körper weggerechnet wurde, die einzelnen Werte für die Winkel.
Das herausrechnen des Körpers sollte insofern zum tragen kommen, wenn man den Körper kippen möchte, da sich hier die Winkel und Längen der Projektion des Körpers zum Boden ändern. Es wird hier also (hoffentlich) schon ein Grundstein mitgelegt, den man aber nicht nutzen muss.
Das Programm umfasst jetzt knapp 750 Zeilen Code - wobei man durch meinen vielen Kommis und Trennzeilen, bestimmt ca. 150 abzeiehn kann.
Das ergibt eine Datei die ca. 30 % der 32kB Flashspeicher benutzt.
Konkret bin ich jetzt dabei die Verschiebung des Körpers neu zu programmieren und auch meinen "ersten echten Schritt" zu erreichen.
Das soll auch einige Grundsteine für kurvengehen und dergleichen legen.
Leider sind doch einige Toleranzen in meinem Aufbau. Diese sorgen nun dafür das sich die Hüftservos nicht ganz sauber in einer Ebene drehen, und dadurch die Höhe etwas verreisst.
Das wird so bald wie möglich korrigiert.
Geändert von HeXPloreR (16.08.2013 um 17:15 Uhr)
Hallo allerseits,
ist es wirklich schon wieder ein ganzes Jahr her seit ich hier zuletzt was geschrieben habe
Nun, was gibt es neues ... ich habe nun die Möglichkeit den Körper zur den Seiten und nach vorne/hinten kippen zu lassen.
Nur irgendwie hat sich hier ein (Denk-/Rechen-)Fehler eingeschlichen, anscheinend ist es mir bisher nicht möglich den Roboterkörper korrekt um einen virtuellen Punkt im Roboterkörper kreisen zu lassen.
Es funktioniert mit den äußeren Beinen - also beide Vorderen und beide Hinteren - wunderbar.
Aber mit den mittleren Beinen scheint es so zu sein als wenn die Beine nun schieben - also den Körper wegdrücken. Das soll so nicht passieren.
Ich habe nach meiner Skizze bei einer Verkippung nach vorne einen Winkelversatz berechnet. Nach der Skizze müsste sich dabei der Hüftwinkel der mittleren Beine ja geringfügig ändern da sich der Winkel der Beinhöhe auch entsprechend der Verkippung ändert. Die Nachführung dieses Servos bewirkt nun das schieben.
Ziel sollte es sein das beim Verkippen alle Fußpunkte am gleichen Ort bleiben und nur um ein virtuellen Drehpunkt im Roboterkörper gedreht wird. Dieser Punkt sollte auch fix sein. Das Ziel wird hier dementsprechend nicht erreicht bzw ich bin mit dem bisherigen nicht zufrieden.
Irgedwo hab ich noch einen Fehler in der Berechnung und komme nicht so recht drauf. Da die Verkippung mit den mittleren Beinen etwas anders berechnet ist, im Vergleich zu den vorder und hinteren Beinen, vermute ich hier natürlich mein Problem.
Ist meine Rechenansatz vielleicht grundlegend falsch und ich sollte von den Fußpunkten aus rechnen und den Virtuelle Punkt womöglich auch auf den Untergrund legen?
Momentan berechne ich aus der Mitte des Koordinatensystems (der fixe virtuelle Punkt im Roboter) wo die Fußpunkte wären wenn es gekippt wird.
Vermutlich liegt es an dem Schwerpunkt des Hexas, der ja nun mal irgendwo mittig liegt, deshalb fällt der Körper bei den vorder und hinter Beinen korrekt ab, aber drückt natürlich auf die Mitte und damit auch auf die Beine, die dann diese Verhalten produzieren.
Da es zwei Beine betrifft ist es für mich keine Alternative einen Schritt mit den betreffenden Beinen auszuführen.
Ich versuche demnächst mal die Berechnung umzuschreiben, so das der Abstand der Fusspunkte gleich bleiben muss und daraus dann die korrekten Beinwerte errechnet werden müssen. Ich denke da irgendwo wird der Fehler sein, denn ich ändere ja diesen Abstand - was wohl falsch ist. Logisch: Ändert sich dadurch ja der jeweilige Fußpunkt.
Wer hat eine Idee dazu?
Viele Grüße
Jörg
Geändert von HeXPloreR (25.08.2014 um 11:23 Uhr)
Bei meinem Vinculum habe ich verschiedene Ebenen der IK implementiert um über die komplexe Berechnung die Übersicht zu bewahren. Die beiden Kipp-Bewegungen um die x- und y-Achse (oder Längsachse, Querachse) sind im Prinzip durch die variable Höhe des Körpers zum Boden bzw. eben Abstand Schulter - Boden pro Bein definiert f(L, Q) = h(1..6). Ist die Höhe h für alle Beine gleich, dann steht der Roboter gerade auf dem Boden. Der Abstand der Fussspitze zum Schultergelenk wird automatisch berechnet, denn dieser ist eine Funktion der Höhe.
Der langen Rede kurzer Sinn: ich habe eine Ebene 0, bei der aus der Vorgabe: X,Y Koordinate der Fusspitze + Höhe, die Gelenkwinkel für die Servos hervor gehen.
In der Ebene 1 wird aus der Neigung L und Q das delta h für alle Beine berechnet. f(L,Q) = dh(1...6) + h(1...6). Später wird ein Neigungssensor erkennen wie "schräg" der Roboter steht und daraus eine Ausgleichsneigung bestimmen die er an die Ebene 1 übergibt.
Dabei ist es mir allerdings egal ob der Drehpunkt im Zentrum des Roboters liegt oder außerhalb, denn der Winkel für L und Q bleibt gleich.
Kleiner Nachtrag noch:
Die Koordinaten des Fusspunkts sind natürlich davon abhängig was maximal bei h + dh rauskommen kann. D.h. für Punkte sehr nahe am Körper ist viel h + dh möglich für Punkte sehr weit weg vom Körper nicht.
Vielen Dank HannoHupmann,
ich denke im Prinzip habe ich das auch schon so.... ich rechne auch die winkelabhängige Längenänderungen der X-Y-Achsen beim kippen in die IK mit ein und passe die Z-(Höhen-)Achse dementsprechen an. Wenn wenigstens meine Programmierung nicht falsch ist - von dem angesprochen Problem mal abgesehen - dann funktioniert es so. Allerdings stellt sich eben dieses Problem ein. Ich muss es wohl nochmal ganz langsam und genauestens prüfen und testen.
Eine Frage: Du berechnest also wirklich alle Beine gleich, oder weicht es auch mal irgendwo ab um etwa (mögliche auftretende) Sonderfälle abzufangen? ich frage das deshalb weil ich ja der Meinung bin ein Mittelbein wäre ein Sonderfall bzw anders zu rechnen als vorne und hinten.
Also nochmal das Problem in kurz: senke ich den Vorderkörper ab, steigt im gegensatz dazu der Hinterkörper auf - um den Nullpunkt drehend. Würde man jetzt die mittleren Bein in der Hüfte nicht nachführen würden sich die Fußspitze vom Boden entfernen und mit dem Verkippungswinkel nach hinten zeigen.
Es entsteht als ein kleines Dreieck, welches ich schon mit einrechne um die Änderung der beiden Fußpunkte abzufangen. Doch dabei entsteht das angesprochen Problem der nicht erwünschte leichte Bewegung des Roboters in die Gegenrichtung.
Hat jemand diese Problem auch schon gehabt und kann einen Tipp geben, woran es vemutlich liegt ...
Viele Grüße
Jörg
Geändert von HeXPloreR (25.08.2014 um 14:45 Uhr)
Naja, die IK-Berechnung ändert sich dadurch nicht. Ich berücksichtige die jeweilige Einbaurichtung erst einen Schritt vor der SD21-Werteübergabe indem ich von 1500 (neutral) abziehe oder dazurechne.
Ich habe das vorher gesagt nun zeichnerisch umgesetzt, dabei funktioniert der alternative Ansatz den HannoHupmann angesprochen hat nur wenn man zusätzlich die Längenänderung für diese Richtung beim kippen mitberücksichtigt damit alle Fußpunkte am selben Ort bleiben. Tut man das nicht landet man ungefähr bei dem Problem welches ich gerade schon habe.
Es entsteht also z.B. beim kippen nach vorne zusätzlich auch ein Differenz die von den vorderen Beinkoordinaten abgezogen und auf die hinteren Beinkoordinaten aufaddiert werden muss. Bei meinem Roboter ist das die Y-Länge. Diese Differenz ist umso gößer je höher der Roboter steht bei gleichem Kippwinkel. Dabei verschiebt sich der Roboternullpunkt nicht nur im Bezug zum Weltkoordinaten des Kippwinkels nach vorne, sondern es fällt die Höhe ab wenn man die Mittelbeine auf "dh2" = 0 belässt. Da dieser Höhenabfall sich gleichzeitig auf alle Fußpunkte bezieht kann er vermutlich vernachlässigt werden - könnte aber auch korrigiert werden.. Ob und wie sich das auf den Kippwinkel zur Seite auswirkt werde ich mir ansehen müssen.
Jetzt gilt es also das ganze programmiertechnisch am Roboter nachzuprüfen.
Geändert von HeXPloreR (28.08.2014 um 21:33 Uhr)
Berechtigungen
Zitieren
Lesezeichen