"EVa" - Bioloid Hexapod

[HeXPloreR]

Hi,

da hab ich mich wohl zu schnell verguckt ...sind anscheinend tatsächlich noch dran!!
...hmm, ich muß mich wohl nochmal genauer mit meinem Atmega128 beschäftigen. Der AVR32 sagt mir bis jetzt nichts...ich schaue mal gelegentlich was das für einer ist.

Das sieht alles echt klasse aus!!!

Das Temperaturproblem kommt wohl auch zusätzlich daher das ich die Servos immer schön am Limit betreibe bedingt durch mein derzeitiges Gewicht von geschätzt 2,3kg. Muß wohl endlich mal LiPos bestellen...und messen ob das nur der DC-Motor ist der da so warm wird oder die Schaltung drin mir zuviel "verfeuert"

Die Kamera ist eine 2,4Ghz Farbkamera mit Nachtsicht...die sendet nur auf ein Emfängerbildschirm und wenn gewünscht in die Garfikkarte (Video/Audio).
Da wird noch nichts weiter mit gemacht. Wenn es denn überhaupt weiter funktionieren kann. Lese dazu noch.

Idee zur Wegmessung:
Durch Aufteilung der Motionpage für das geradeaus laufen in vier einzelne Pages die nacheinander programseitig durchlaufen werden mit Variablenabfrage, zur Bestimmung des zurück
gelegten
Weges im 1/4 takt bei angenommenen 4cm pro ganzen takt:
1.Page = +1; 2.Page = +1; 3.Page = +1; 4.Page = +1;
wäre dann:
0 (Schrittzähler) = 0 cm
0+1 (1/4) = 1
1+1 (2/4) = 2
2+1 (3/4) = 3
3+1 (4/4) = 4 (beschreibt den durchlauf 1x,die Pages werden durch jeweils +1 auf die variable "schrittzähler" aufaddiert. Der zähler wird ausgegeben und weiterverwendet...

4+1 (1/4) = 5
5+1 (2/4) = 6 cm
....
Allein bei einem Abruch eines Teilschrittes wäre es zusätzlich hilfreich die Servopositionen zu erfassen um den genaueren zurückgelegten Weg zu erhalten. Aber ich denke 1cm reicht mir da vorerst aus...also der Weg des letzen erfolgreich abgesetzen Beins/Teilschritt.

Das könnte schon ganz gut klappen, durch die starre Vorgabe der Bewegung entfällt natürlich das umrechnen von Servopositionen des Beines um tatsächliche Schrittlänge zu erhalten ( unberücksichtigt bleibt der Schlupf).
Drehungen würden auf der Hochachse ausgeführt, und fallen daher nicht unbedingt in die Wegberechnung ein. Um nun einen Drehwinkel zu bekommen könnte man nach einem ähnlichen Prinzip vorgehen.


mfg

By the way: http://de.wordpress.com/tag/kampfroboter/

[HeXPloreR]

Hi @ all,

der oben gezeigte Aufbau ist wegen der doch eher ungeeigneter beinkonstruktion verworfen. Da ich nicht wieder zurück auf einen "normalen kleinen" Hexa umbauen möchte, halte ich weiter an der idee fest einen Bot zu bauen der sowohl auf "zwei" beinen (paare) sowie auf vier bzw sechs beinen ( vier aus den beiden beinpaaren + zwei einfache kleine die noch nicht vorhanden sind ) laufen soll.

Nun warum zwei beinpaare beim humanoiden laufen?
- ich möchte dadurch eine bessere Gewichtsverteilung auf mehrere Servos erreichen und ein zu schnelles erwärmen entgegenwirken. Da die Hauptbeine nach aussen schwenkbar angebraucht sind wurde auch hier mit doppelter auslegung der Servos gearbeitet. Dazu später die zwei kleine Beine um den vorteil des Hexapodengangs (3/3) nach dem morphen wieder zu bekommen aber ohne das gewicht noch weiter extrem zu steigern. Wünschenswert ist ein fliessender übergang von "Hexa > Human > Hexa". Mehr als 3kg sollten am ende nicht auf einem Doppelbein lasten.

Nur wie üblich fehlen mir wieder mal Frameteile zum weiter bauen...kleine alubleche werde ich in nächster zeit herstellen um diese zur stabilisierung der beine zu verwenden, allerdings die richtig wichtigen für die fußmechanik sind für mich nicht machbar....daher: bestellen ---> dann gehts da erst weiter.

Nebenbei arbeite ich weiter an dem programm wobei die statischen Bewegungen (M.E.) vorerst aussen vor bleiben da es wenig sinn macht diese für den bis jetzt halbfertigen aufbau anzulegen.
Damit eine übersteuerung des programms reallisiert werden kann möchte ich eine variablen abfrage programmieren die die eingaben ( vor, zurück, drehen, usw) über den IR-Sensor des zweiten CM-5 entgegennimmt.
Das soll die (test)vorstufe zum drahtlosen übersteuern werden.
Natürlich alles immer noch mit dem bewährten BCP



EDIT:
Nach *wiederbewußtmachen* meiner Ziele (danke an den Arbeitskollegen, und dem Konto check) ist mir doch mal aufgefallen das ich euphorisch immer schöner schnelle und breiter wollte...nun auch ich muß mich danach richten was ich kann und was nicht, und was ich machen möchte. Nun habe ich beschlossen das ein Hexa der sich aufrichten kann um vorallem auf ebenen Flächen aufrecht laufen können sollte, überhaupt kein bischen in meinen Plan passt.
Die idee find ich zwar immer noch klasse, aber wird wegen Umfang der Teile und finanziellen Mittel vorerst in die Schublade degradiert.
Aber ich denke auch das es nicht nötig ist nochmehr Hardware zuerwerben die nicht unbedingt dem Ziel dient.
Primär ist mein augenmerk momentan auf C programmierung und realisierung eines "LaserZielSystem" gerichtet.

mfg

[HeXPloreR]

Hi @ all,

durch die Wegorganisierung eines zweiten Bioloid Comp. Kit, freundlicherweise abgegeben by fabo ist es mir nun möglich den auf dem oben zu sehenden Aufbau weiter zu vervollständigen. Das bedeutet für mich ich kann daran Überlegungen reallisieren und erstmal auf Machbarkeit prüfen... ohne gleichzeitig meine kleinen Hexapod "EVa" wieder komplett zerlegen zu müssen, der wird nun ebenfalls zusätzlich mit einigen Frames weiterbestückt.


Anregungen, Fragen, Kritik --->

mfg

[HeXPloreR]

Der immer noch aktuelle Bauzustand der Bioloid- EVA

Und nun auch mal wieder ein kurzes Video:
http://www.myvideo.de/watch/6439651/neue_EVA

[daniel.weber]

Hallo HeXPloreR,

interessantes Projekt. Ich habe mir auch gerade mal die sehr interessante Diplomarbeit durchgelesen bzw. ich habe sie überfolgen. Leider habe ich die verwendeten Algorithmen nicht ganz verstanden aber dennoch ist die Arbeit sehr lesenswert.

Hast du vor deinem Bot auch auf diese Art das Laufen beizubringen? Würde mich interessieren, ob jemand auf diesem Gebiet schon positive Erfahrungen gemacht und Ergebnisse vorweisen kann (Videos?).

Wäre ja mal interessant zu sehen wie ein Roboter das Laufen selber lernt

[HeXPloreR]

Hallo @ all

@ daniel.weber

tatsächlich ist es sehr interessant zu lesen, aber ich denke nicht das ich versuchen werden meiner EVA eine derartige Lernstruktur auf Grund von Wahrscheinlichkeitsberechnungen beizubringen. Und wofür auch, was lernt er wen er das linke Bein setzen kann?? ...eben, nur das es geht. Was wäre wenn er aber statt dessen das rechte Bein setzen würde, und das auch geht??
Nun ist es so das es ihm selbst überlassen sein sollte welches er setzen "möchte", denn beides führt in dem Fall zum Erfolg. Die Wahrscheinlichkeit würde also sagen links gehts weiter, und läuft ebenso gegen eine Wand oder einen Abgrund.

Aber das kann auch eine Programmierung leisten, die bestimmt welches Bein sich bewegen soll, denn der Erfolg des Beinsetzens hat, meiner Meinung nach nichts mit Wahrscheinlichkeit zu tun, eher mit einer tatsächlichen realen Situation. Das Problem ist meiner Meinung nach die Erfassung und Verrechnung von bestimmten Umgebungswerten die zusammen mit der Bewegung erst eine "eigenständige" Fortbewegung erlauben.
Das Einzige was ich mir gut damit und mit neuronalen Netzwerken vorstellen kann, ist so etwas wie Sollzustände einhalten ( z. B. Körperhöhe bei jedem Schritt halten ---> lernen welche Beine dazu gebraucht werden, welche nicht - die können bewegt werden....)

Ich werde meinem Roboter das laufen so beibringen dass ich ihm sage in welche Richtung sich seine Koordinaten verschieben sollen, bzw er sie selber errechnet um Hindernisse zu umgehen. Das bedeutet er läuft einfach mal los, trifft frontal links auf ein Hinderniss ( breites Tischbein ) nun soll er feststellen das er rechts dran vorbei sollte da dieser weg kürzer ist ( natürlich sind dafür Sensoren erforderlich) ... da er aber eigentlich noch kein Ziel hat ist es egal wie rum er es umgeht, wichtig ist nur das er es tut. Nur wenn er ein Ziel gegeben hat soll er wieder darauf zu halten...ansonsten ist es egal.
...dieses "egal" würde ich ggf zum Raum erforschen benutzen und eine Reliefkarte erzeugen. Diese Karte soll Auskunft über gewisse Dinge wie "kann ich drauf laufen, kann ich nicht, ich kann (war schon mal da) aber von hier aus nicht, usw"...danach soll er dann seinen Weg finden, bzw das Ziel anlaufen.
Brauche ich dazu KI? - ich denke das eine besondere Form von KI oder auch eines KNN dafür noch nicht benötigt wird.
Inverse Kinematik + "ein Körpergefüh"l per Accelerator und Kompass sollten mich diesem Ziel schon näher bringen.

Das vorläufige Endziel soll hierbei sein EVA auf meinem Tisch laufen zu lassen, ohne das sie das Ziel erreichen kann weil er nicht runter kann. Nachdem er den Tisch "abgemessen" hat, sollte er mir mitteilen das die Aufgabe nicht gelöst wurde. Aber da bin ich noch sehr weit von weg...


Es gibt sicher allgemeine Ergebnisse zu den verschiedenen Lernmethoden, aber hab grad auch keinen Link zur Hand.

Leider weiß ich auch nicht ob mit diesem beschriebenen Ansatz schon wirklich etwas erreicht wurde. ...fallls vielleicht jemand noch was dazu weiß....


mfg

http://www.myvideo.de/watch/6439651/neue_EVA

[daniel.weber]

nun gut da wirst du recht haben, man kann sein Ziel auf relativ einfachen Wege erreichen oder über den Kilimandscharo gehen. Beides führt wie du sagst zum Ziel.

Ich fand den Gedanken nur sehr nett, dass mal der Roboter die Arbeit übernimmt und sich langsam ans Laufen herrantastet. Dass man das auch einfacher durch eine feste Programierung erreichen kann, ist klar.

Die Sache mit der Kartenerstellung finde ich auch sehr interessant (es gibt einfach zu viele interessante Dinge *g*). Ich hatte da mal vor einen kleinen Rad Robo zu bauen, der mithilfe von US und IR eine Karte von einem unbekannten Gebiet erstellt, diese Karte auf den PC sendet und ich ihm dann sagen kann, durch klick auf die Karte, wo er hinfährt. Außerdem möchte ich ihm feste Routen geben, die er dann abfährt. Vielleicht wäre das auch eine Idee für dich.

Ich habe mal gegoogelt und einiges zu dem Thema lernender Roboter gefunden, allerdings gibt es nicht wirklich komplexe Roboter. Bis her habe ich nur einfache "Einbeinkriecher" gefunden und das ist nicht wirklich spektakulär.

[HeXPloreR]

Genau das sind ja die Anfänge, diese Kriechdinger....die messen das sie sich bewegen, und probieren verschiedene Kombinationen um diese Bewegung an ihr bauartbedingtes ( Servosstellgeschwindigkeiten, Geometrische Daten des bots...) Maximum zu bringen.
Sag dem Kriechding es soll fünf cm - oder was auch immer für ein Maß - da und da hin laufen, so wird es das tun wenn es kann...und immer besser bzw schneller werden. Sag ihm er darf nur so und so hoch dabei sein so wird er das einhalten, doch ob er sich dann noch bewegen kann....
Du siehst eine Menge Faktoren könnne und müssen dabei zusammen kommen.

ja die Idee mit der Karte auf den PC senden sollte schon sein, damit man auch aktiv eingreiffen und Ziele setzen kann. Eine Route sehe ich nicht vor, wäre aber optional machbar. Aber im Grunde ist es nichts weiter als ein Weg in mehrere Teile gestückelt ( A--> b -->c -->D )....ob er denn nun Absichtlich über "Umwege" gehen muß oder direkt versucht von A --> D ist egal...es sei denn dort wäre etwas zu erledigen.


mfg

[HeXPloreR]

So
...und nun noch etwas in Eigener Sache:

AX-12 - CW (clock wise = Uhrzeiger Sinn) / CCW ( counter clock wise = gegen Uhrzeiger Sinn) Margin:
Gibt an um welchen Wert der angefahren Sollwert des Servos toleriert werden soll. Toleranzen sind schon was tolles, nur Frage ich mich wozu soll das gut sein. Wenn ich sage fahr die Position an, und er mir unterwegs wegen gegebener Toleranz zur "Goal Position" stehen bleibt bzw ab dieser Position keine Torque mehr aufgewendet wird...macht irgendwie nur Sinn wenn man die Gewichtskraft z.B. einen Armes ausnutzen muß oder will.

Wesentlich mehr Sinn macht die Funktion CW / CCW Slope:
Diese senkt die Verfahrgeschwindigkeit/-kraft in einer Rampe bis zur Goal Position ab bzw hebt sie an, was sanfte und materialschonende Bewegungen ermöglicht.

Nun ist es mir noch nicht gelungen eine Bewegungsseite die mit dem Motion Editor erzeugt wurde, in der Bewegung abzubrechen ... jedenfalls nicht ohne die Kraft abzuschalten. Den Status der Bewegungsseite kann man abfragen - 1 = bewegt sich noch, 0 = ist beendet; ebenso kann man die Bewegung einzelner Servos in ähnlicher Weise auslesen.

Einen von dreien CM-5 hab ich nun schon zerstört ( vermutlich beim operieren "am offenen Herzen" mit dem Meißel abgerutscht ) jedenfalls zeigt er mir nichts mehr an...mal schauen ob und wann ich die teile entlöte...

Es ist mir gelungen meinen CM-5 mitt dem schon compilierten C-Beispielprogramm (.hex) zu flaschen...aber das Beispielprogramm, welches auch uncompiliert vorliegt, selbst zu compilieren schlägt regelmässig fehl. Nachlesen im englischen Robosavy Forum ergibt mehrere mögliche (bekannte) Fehler in der makefile usw...


mfg


Neue Infos zum Bioloid, vielleicht findet hier der eine oder andere etwas nützliches:
http://www.dualpob.com/docs/html/files.html

[Sven04]

Hi,

ich habe gelesen, das jemand die AX-12+ auch mit einem AVR32 angesteuert hat und finde die Idee eigentlich super, da auch noch genug Resourcen da sind, um IK zu implementieren. Nun wollte ich mal wissen, mit welcher Baudrate die Servos vom AVR32 aus angesteuert werden und ob es auch noch detailiertere Beschreibungen zum Aufbau der Hardware und der Software gibt?

Gruß,
Sven