Quadruped - und er läuft...

Hallo,

ich, möchte hier mal ein (fast) fertiges Projekt von mir vorstellen.
Die Hexapods hier im Forum haben mich angeregt mich selbst zu versuchen, allerdings mit 2 Beinen weniger. Zielsetzung war/ist zunächst nur das selbstständige, flüssige Laufen. Sensoren sind zunächst nicht vorgesehen, da ich mich als Nächstes mit der drahtlosen Steuerung beschäftigen möchte.

Doch nun zum Roboter:

Die Planung erfolgte mit MegaCad und QCad. So habe ich zunächst fleißig gezeichnet und gerechnet damit die Servomotoren auch fähig sind den Roboter zu bewegen - bei zu langen Beinen kommt man da schnell an die Grenzen...
Zu den Berechnungen ist zu sagen, dass der Roboter auch für eine interne Spannungsversorgung über einen LiPo ausgelegt ist.

Die komplette Mechanik ist aus 5 mm Acrylglas-Resten aus dem Baumarkt angefertigt. Die Teile habe ich auf meiner kleinen CNC gefräst und gebohrt. Angetrieben wird die Mechanik von 12 Miniatur-Servomotoren.

Die Steuerung in Form eines Atmegas 168 wurde auf einer selbstgeätzten Platine aufgebaut. Die Spannungsversorgung für den Atmega (5 V) und die Servomotoren (5-6 V) ist getrennt ausgelegt. Der Atmega wird mit externen 16 MHz getaktet.
Leider ist mir der Fehler passiert, die Reset-Leitung zu nahe an den Motorleitungen zu platzieren. Bei steigenden Strom der Motoren neigte der Atmega dann zum Reseten. (Die Fehlersuche hat ewig gedauert weil ich den Fehler zunächst im Programm gesucht habe)

Die Programmierung erfolgte im AVR Studio 6 und einem AVR Dragon-Programmer. Der momentane Code belegt 75 % des Speichers - ist aber auch noch nicht ganz sauber geschrieben. Die Steuerung der 12 Servomotoren ist dank der Hilfe hier im Forum sehr kompakt geworden, am Längsten dauert die Impulslängenberechnung der Motoren. So dauert die Berechnung alles Servomotoren knappe 5 ms. Da die Servos in Abständen von 20 ms angesprochen werden passt das und es sind noch 15 ms für andere Aufgaben zur Verfügung.

Wie man auf den Fotos erkennen kann besitzt der Roboter noch keine eigene Spannungsversorgung - momentan hängt er noch an einem externen Labornetzteil mit 5 V. Im Betrieb ziehen die Motoren einen Gesamtstrom im Bereich von 1-1,5 A.

Laufen tut er jetzt bereits, aber ein kleines Defizit ist der mangelnde Gewichtsausgleich. Der Roboter neigt dazu, in Richtung der angehobenen Beine zu kippen. Als Lösung suche ich noch nach einer schönen Grafischen Analyse-Methode am Rechner. (so, dass ich den Schwerpunkt abhängig von der Bewegungsposition zur Zeit sehen und optimieren kann)

Ich war aber erstaunt, dass er trotz der schwachen Motoren relativ flink laufen kann - aber da lässt sich auch noch viel optimieren :)

Hier noch 2 Bilder:
Anhang 24325Anhang 24326
(provisorisch mit der RN Mini-Control)

Und ein Video gibt es hier zu sehen: http://www.youtube.com/watch?v=-oMwj...8qQyZw&index=1
(Das Video ist sehr spät entstanden - man verzeihe mir die Schreibfehler)

Gruß Erik

Könntest du mir mal erklären welche einzelnen schritte ich machen muss mit den Beinen beim vorwärts gehen und beim drehen?
Könntest du das mal aufmalen?
Bin auch grade am bauen eines Quadrupeden https://www.roboternetz.de/community...d-by-Ripper121

Also zeichnen lässt sich das schwer, aber ich versuche das mal anhand des Codes zu erklären.
Hier mal der Auszug für 2 nacheinander folgende Beine:

Code:

---


// 100 entspricht einer vollen Beinbewegung
// pro Bewegung legt ein Bein 40 mm zurück
// pro Bewegung werden 3/4 der Zeit für die Vorwärtsbewegung genutzt (Bewegung vorwärts = 100 * 0,533 * 0,75)
// und 1/4 für das Zurücksetzen (Zurücksetzten = [100 * 0,533 - 40] * 3)

// hier wird die aktuelle Zyklusposition ermittelt - die 1. "100" entspricht dem Offset für jedes Bein
weg = (i+100)%100 * 0.533;       

// Abfrage: wo im Zyklus sind wir: weg < 40 entspricht der Vorwärtsbewegung
if (weg > 41)
{
    // Zurücksetzten
    x = 50.0 + (weg-40.0) * 3.0;
    // und das Bein anheben
    z = 60.0;
}else{
    // Vorwärtsbewegung
    x = 90.0 - weg;
    // und das Bein ist unten
    z = 70.0;
}

// die Y-Kooardinate bleibt immer gleich
y = -70.0;

// diese Funktion berechnet die Winkel für die geforderte Beinposition; die erste Ziffer "0" ist die Angabe des Beins
move (0, x, y, -z);        // Bein_vr = 0


// das 2. Bein hat einen Zyklusversatz von 25% = 125
weg = (i+125)%100 * 0.533;
if (weg > 41)
{
    x = 50.0 + (weg-40.0) * 3.0;
    z = 60.0;
}else{
    x = 90.0 - weg;
    z = 70.0;
}

y = 70.0;

move (1, x, y, -z);        // Bein_vl = 1

// optional:
// wait 20 ms - Rechenzeit (ca. 5 ms)

// und weiter gehts im Zyklus
i ++;

---

Also im Prinzip bewegen sich zunächst alle Bein nach hinten um den Roboter nach vorne zu bewegen. Alle Beine sind in ihrem Zyklus um 25 % versetzt - bei 100 % haben alle 4 Beine eine vollständige Bewegung vollzogen (also Vorwärtsbewegung und Zurücksetzten).
Während der Bewegung haben die Beine bei 75 % ihren vollständigen Hub nach hinten erledigt, die restlichen 25 % des Zyklus wird das Bein angehoben und mit der 3-fachen Geschwindigkeit zurückgesetzt.
Das Drehen erfolgt im gleichen Prinzip. (Die Beine bewegen sich auf einem Stück einer Kreisbahn)

Leider ist mein Vorgehen noch nicht optimal - wie geschrieben neigt der Roboter noch zum kippen. Aber das Austarrieren würde ich im Prinzip nur auf die oben beschriebene Bewegung herauf-modulieren. Die Grundbewegung würde so bleiben.

Für dieses Ausgleichen muss ich mir noch einen schönen Code zusammenbasteln/ausdenken. Ich denke zur Zeit daran, den Korpus vom anzuhebenden Bein weg-zudrehen so, dass der Korpus im Prinzip um seine eigene Achse taumelt.

Eine Kombination von mehreren Bewegungen (Drehen, Laufen, "taumeln") habe ich noch nicht vorgesehen - soll aber auch irgendwann realisiert werden...

Ich habe leider grade viel zu tun, aber sobald ich wieder Zeit habe, werde ich mal gucken wie man die Bewegung optimieren kann.

Ich hoffe trotzdem, dass ich dir ein bisschen weiterhelfen konnte?!

Gruß Erik

ok danke :-)

- - - Aktualisiert - - -

wollte mir den Bewegungsablauf von diesem abschauen
http://www.youtube.com/watch?v=490iCZIGy3k

Ein sehr schönes Video, leider viel zu schnell um die Bewegung genau analysieren zu können....

Ich bin jetzt noch darauf gestoßen, dass es üblich ist, die Beine nicht im Kreis sondern über Kreuz vorzusetzten.
Das hatte ich auch schon probiert, der Gang verschlechtert sich dabei nicht, aber ich hatte befürchtet, dass der Gewichtsausgleich dann komplexer ist...
In dem Beispiel_Code von oben hieße das im Prinzip, dass man den Offset der Beine 2 (125=>150) und 3 (150=>125) vertauscht. (also recht schnell)

Ich suche aber nach einer Möglichkeit, das ganze grafisch in Echtzeit zu analysieren (simulieren) damit ich zu jedem Zeitpunkt erkennen kann, wo der Schwerpunkt liegt. Mit Excel-Funktionen und Diagrammen komme ich da leider nicht weit...

Vielleicht hätte jemand einen Tip für mich, wie ich das am Elegantesten anstellen kann? Vor C und C++ schrecke ich auch nicht zurück...

Von was der name?

Hier habe ich mal ein video in Frames zerlegt kann man sich jedes Bild einzeln ansehen vom bewegungsablauf hoffe es hilft dir weiter
https://docs.google.com/file/d/0B8Cn...pPS0kwTjQ/edit

Hast du die Servos direkt an dem akku? Weil habe servos die von 4,8-7,2V gehen und einen 7,2V (3Ah) NiMH akku und weis ne ob ich die direkt dran klemmen kann

Die Servos sind bei mir noch nicht am Akku. Ich verwende stattdessein ein Labornetzteil mit 5 V. Bei 6 V ist mir schonmal einer der Servos durchgebraten...
Bei C**** wird der Servo bis 7,2 V angegeben - auch wenn sie günstig sind würde ich das nicht riskieren.

Außerdem läuft er ja mit den 5 V! (bei einer kurzzeitigen Erhöhung auf 6 V ist keine Verbesserung erkenntlich)

Bei guten Servomotoren sollte das Datenblatt weiterhelfen (soweit vorhanden).

Bei HiTec Servos habe ich ohne Problem 7,2 bzw. einen 7,2V Akku angeschlossen. Die Servos werden nicht mal warm. Bei BlueBirds sind mir hingegen schon einige elektrisch gestorben wenn sie über 6V betrieben werden. Es gibt genug Spannungswandler für den Modellbau die aus 7,2...8,4V eine vernünftige 6V Versorgung generieren mit entsprechender Leistung.

Weiter hilft es die Versorgung mit einer kleinen Kondensatorbank zu puffern (100nF+1µF+4,7µF irgendwie sowas), damit lassen sich lange und kurze Spitzen sehr gut einfachen.

Achja und bei Hexas, Quadros oder sonstigen Robotern mit beinen würde ich keine NiMH Akkus verwenden sondern die deutlich effizienteren Lithium Polymer Akkus. Die haben bei gleicher Leistung ein deutlich geringeres Gewicht und kleinere Abmessungen.

Da hier grade von der Spannungsversorgung gesprochen wird - ich bin grade mit der Planung der neuen Steuerung beschäftigt.
Und in diesem Zusammenhang beschäfftigt mich, ob und wie man es erreichen kann alles über einen LiPo zu versorgen.
Wo man auch guckt wird immer empfohlen eine separate Spannungsversorgung für die Logik zu verwenden. Das bringt mich aber bei dem kleinen Quadruped an die Grenze, da der Patz beengt ist.
Gibt es denn nicht gute Spannungsregler die unempfindlich gegenüber solchen Schwankungen sind.
Oder anders gesagt (geschrieben): wie bekomme ich eine gute unempfindliche Spannunsgversorgung für die Logik zusammen mit der Spannungsversorgung für die Servomotoren aufgebaut?

Oder gibt es noch weitere Gründe das man separate Versorgungen nutzt?

Gruß Erik

Vermutlich durch eine galvanische Trennung und eine saubere Entkopplung über Kondensatoren. Jeder Spannungsregler bekommt Probleme, wenn die Eingangsspannung einbricht. Hier hilft es die Servos über geschickte Programmierung nacheinander anzusteuern. Ein Regler vor den Servos könnte auch noch als Puffer dienen. Ich habe bisher kein Problem gehabt einen 9V Block für die Logik unter zu bringen, daher waren solche Gedanken nicht wichtig für mich.

Hallo!

Zitat:

---

Zitat von erik_wolfram

wie bekomme ich eine gute unempfindliche Spannunsgversorgung für die Logik zusammen mit der Spannungsversorgung für die Servomotoren aufgebaut?

---

Eine einfache Schaltung zum Ausprobieren. Der Elko (C) muss praktisch ermitelt werden, damit der µC nicht resetet. ;)

Code:

---

              VCC zu Motoren

              A
              |  D
              |
              +->|-+---> VCC zum µC
              +|    |+
        Akku  -  === C
              ---  /-\
              -|    |
              ===  ===
              GND  GND

(created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de)

---

Hallo, hallo!

Es gibt große Fortschritte, aber ebenso kleine Rückschläge...
Ich habe den Quadruped mittlerweile komplett überarbeitet - lediglich die Beine wurden noch übernommen (auch wenn man den Unterschied kaum sieht).
Die Steuerung übernimmt ein Atmega 168 TQFP auf einer selbstgefrästen Platine für die Logik, die mit einer Schnittstelle für ein WLAN-Modul ausgestattet ist.
Das ganze läuft mit 3,3 V um eine Pegelwandlung zu ersparen und die Stromaufnahme zu mindern.

Die Spannung für die Servos wollte ich vom vom Microcontroller freigeben - hierfür wollte ich eine FET-Kombination verwenden - doch leider "spinnt" der Leistungs-Mosfet (P-Kanal) - hier habe ich einen Durchgang von Source nach Drain obwohl ich den Eingang unbeschaltet hab. Eventuell - habe ich hier durch das Löten einen Schaden verursacht...
Nichtsdestotrotz habe ich mal einen Schaltplan angehängt - vielleicht sieht hier noch jemand einen Fehler?!

Mit Mühe und Not habe ich alles auf 2 Platinen verteilt bekommen: eine Platine für die Logik, eine für die Leistung. Die geringe Baugröße zeigt sich aber als sehr einschränkend - ich habe kaum noch Platz für die Korrektur auftretender Fehler.

Die WLAN-Übertragung funktioniert soweit versuchsweise - hier muss ich mich noch mit der Computerseitigen Verarbeitung beschäftigen.

Anhang 24752Anhang 24753

Der mittlere (13.) Servomotor soll später einen Ultraschallsensor aufnehmen - dieser ist aber noch nicht beschafft, aber die Anschlüsse sind vorgesehen.

Die Spannungsversorgung der Logik ist wie von PICture beschrieben aufgebaut - die Brauchbarkeit wird sich in der Praxis zeigen!
Erste Versuche waren Positiv - die Pufferung mittels eines 220µF Elkos funktionierte - dazu kommt noch der 3,3 V Spannungsregler mit einer geringen Dropout-Spannung. So dürfte die Diode (1N4001) der größte (problematsiche) Verlust sein.
Trotz der Belastung der Servos resetete der MC nicht! Dieser arbeitet aber hauptsächlich im Schlaf-Modus - das WLAN-Modul wird hier deutlich mehr Leistung benötigen (ca. 100 mW).

Die Schaltung mit zwei MOSFET's ist sehr gut fürs Lernen jede Schaltung stufenweise in Betrieb zu nehmen. Beispielweise:

1. Ohne erster Stufe mit Q2 das untere Ende von R2 zwischen "Batt" und "GND" schalten und max. belastete "SERVO" Spannung kontrollieren.

2. Bei kompletter Schaltung das "PCO" zwischen "H" und "L" schalten und wie oben "SERVO" Spannung prüfen.

Übrigens, ich vermute, dass der Q2 nicht richtig gesteuert wird.

Bei klarem Ziel und negativem Ergebnis entsprechendes ändern bzw. falls notig, eigenes Wissen um nötiges ergänzen. Mann könnte auch konkrete Frage nach genauer Beschreibung des Fehlers im Forum stellen und auf hilfreiche Antwort mit Hoffnung warten.

Hallo, ich habe mir gestern nochmal die Platine in Ruhe angeguckt, dabei habe ich u.a. festgestellt, dass obwohl ich das Gate des Leistungstransistors komplett von allen Potenzialen freigelötet habe, dass ein Widerstand von 5k Ohm zur Masse bestand.
Daraufhin habe ich die Platine nochmals gründlich gereinigt bis dieser Widerstand geringer wurde (die Brücke war wohl unter dem MOSFET).
Außerdem habe ich die Widerstände abgeändert um eine bessere Aussteuerung zu erreichen:R2 und R4 betragen jetzt nurnoch 1k Ohm.
Damit merkt man das der Tranistor schaltet - aber im Ruhezustand wenn am Gate V_batt anliegt lässt er Trotzdem 1,5 V durch - auch mit Last. Also ich vermute er hat trotzdem ein Ding weg, oder ist für solche kleinen Spannngen doch ungeeignet.

Aber nichtdestotrotz reicht diese Schaltwirkung um die Servomotoren zu deaktivierenn: die gewünschte Funktion ist vorerst erreicht :)
Dabnke nochmals für die Hinweise!

Jetzt bin ich fleißig am Progarmmieren: ich denke Ende der Woche wird er sich zeigen lassen können - und hoffentlich noch besser laufen können!

Ich hab mal eine Frage zum Bewegungsablauf von diesen Dingern. Ich seh immer, wie sie sich auf den "Zehenspitzen" nach vorne ziehen.

Ich seh aber auch immer solche Routinen, bei denen der Körper bei fixen Trittpunkten in alle Richtungen verschoben wird. Hat schonmal jemand versucht daraus ein Bewegungsprinzip zu machen ... dass man den Körper bei (zumindest gedacht) fixen Trittpunkten in die Richtung schiebt in die man will und die Beine dann eines nach dem anderen hebt und in die Grundstellung zurückzieht, also so dass der Auftrittpunkt wieder in einer bestimmten Distanz zum Aufhängepunkt des Beines ist.
Als nächstes könnte man das dann gleichzeitig machen.

Also ganz klar werde ich aus dieser Erläuterung nicht - deshalb schilder ich einfach mal den Ablauf bei mir:

1. Der Korpus bewegt sich mit einer konstanten Geschwindigkeit zum Boden nach vorne
2. Die Beine werden damit relativ zum Korpus, mit festen Trittpunkt auf dem Boden nach hinten bewegt (er schiebt sich vorwärts) (ähnlich wie beim Rudern)
3. Die Beine bewegen sich versetzt (jeweils um 25% eines 100% Bewegungszyklus), damit immer ein Bein die Möglichkeit hat einen Schritt vorwärts zu machen
4. Ist ein Bein am Ende seiner relativen Bahn zum Korpus angekommen - macht es den Schritt nach vorne (Anheben und so weit wie möglich nach vorne - relativ zum Körper - bewegen)
5. Die Schrittbewegung nach Vorne muss deutlich schneller erfolgen: dabei bewegen sich die Beine 4 mal schneller nach vorne, als sie es die 75% des Bewegungszykluses tuen um "aufzuholen"

Ich hoffe diese Erklärung ist eindeutig!

Derzeit arbeite ich grade am Gewichtsausgleich: wird ein Bein angehoben neigt der Roboter zum Kippen in dessen Richtung - dafür muss ich noch eine Kompensation erarbeiten!
Die Steuerung mittels WLAN zeigt sich aber als sehr nützlich - Änderungen können sofort übernommen werden!

Ja, dieses Rudern mein ich mit "nach vorne ziehen". Aber ich glaub, was ich mir vorstelle funktioniert bei quadrupeds nicht so gut. Bei 6 Beinen schon eher, weil ein Hexapod auf 5 Beinen kein bisschen weniger stabil ist.

Was ich meinte ist, während alle Beine auf dem Boden bleiben den Körper in Bewegungsrichtung zu verschieben, und dann die Beine einzeln wieder in die Grundstellung relativ zum (jetzt verschobenen) Körper zu setzen.

Ich weiß nicht, ob das so eine gute Idee ist, den Körper sich in einer geraden Bahn bewegen zu lassen. Bei den Quadrupeds, die ich bisher in Videos gesehen habe, bewegen sie sich mit dem Körper immer recht weit zu dem Schwerpunkt des Dreiecks, das von den auf dem Boden verbleibenden Füßen gebildet wird, um eben beim Anheben des vierten Fußes nicht so leicht umzukippen. Dadurch bewegen sie sich mit dem Körper ständig hin und her, siehe beispielsweise hier. Das Problem ist nämlich, dass sonst der Körperschwerpunkt etwa über der Kippachse liegt, wodurch der Roboter eben leicht zum Kippen neigt.

Ok, das stimmt so natürlich!

Das ist das was ich mit "Kompensation" meinte - im Prinzip wollte ich das so lösen:
Das Bewegungsmuster bleibt gleich, aber: der Schwerpunkt "kreiselt" dann um einen Imaginäre Punkt der sich gradlinig bewegt.

Das Kreiselt ist dann nichts anderes als, dass der Torso eine Kreisbewegung um den Imaginären Punkt, synchron zur Bewegung durchführt - diese lässt sich einfach auf die vorhandene Bewegung überlagern. Kreisbewegung ist dann um 180° zum anhebenden Bein versetzt.

[kleines] Update:

Ich habe heute fleißig programmiert und experimentiert - nun ist es möglich per Pfeiltasten Vorwärts, Rückwärts, Seitwärst zu laufen oder zu drehen - das klappt alles wunderbar!
Für die Kompensation habe ich abhängig von der Bewegungsart einen Radius zwischen 10 und 15 mm zum "imaginären Punkt" gewählt um die der Torso kreiselt - damit läuft er erstaunlich stabil und hat keine Kippneigung mehr!

Auch die Lösung mit dem Akku erwies sich als sehr gut:
Das 4,8V 4 Zellen Akku-Pack (NiHM 2300 mA) erfüllt alle Erwartungen - nach dem ich mehrere Stunden probiert habe - konnte ich gute 25 Minuten durchweg laufen.
Das heißt es sind vermutlich 30-45 Laufzeit mit einer Ladung möglich! Nach dieser Zeit resetet dann das WLAN-Modul auf Grund des Spannunsgeinbruchs. Ansonsten reicht der Akku gut für die 12 Mini-Servos! Lediglich ein kleines Zittern bleibt.
Für die Versorgung vom Microcontroller und dem WLAN Modul habe ich ja die Variante mit einer Diode und einem Elko erprobt - das Ergebnis: in Verbindung mit dem Akku und einem 220 µF Elko funktioniert das super - keinerlei Probleme. Einzig mein 15 V 3 A Labornetzteil funktioneirt damit nicht - vermutlich ist der Einschaltstrom so groß, dass das Netzteil kurzzeit einbricht/abschaltet. Ziehe ich das WLAN Modul ab starte die Servos und setzte es wieder auf läuft es. (Aber sehr umständlich/unschön).

Mein nächstes Ziel wird es jetzt sein die Bewegungsarten flüssig zu verknüpfen so, dass alle Bewegungen ineinander verlaufen, bzw. kombiniert werden können, dass die Höhe sowie der Nick dynamisch geändert werden können. (Derzeitig existieren alle Gangarten als separater Zyklus)
Außerdem bekommt der Roboter noch eine schöne ABdeckung spendiert (die ich mir noch ausdenken muss).

Anbei: alle Daten werden derzeit auf meinem Laptop berechnet und simultan übertragen - je weiter der Roboter von meinem Laptop entfernt ist, desto langsamer wird er. Das liegt daran, dass er auf seine Datensätze wartet.
Wenn alles fertig ist, werde ich Versuchen die Daten auf dem Microcontroller zu übertragen so, dass er nurnoch seine Befehle per WLAN erhält oder komplexe Daten extern berechnen lässt.

Außerdem: das Gewicht des Quadrupeds beträgt 380 g!

Gruß Erik

Endlich habe ich es geschafft!

Mit Android hat es ein bisschen gedauert, aber jetzt läuft es. Deshalb ein kleines Video:

http://youtu.be/uFDf7osGMAE


Gruß Erik

Hmm, wie funktioniert die WLAN-Kommunikation prinzipiell? Das Modul am Roboter simuliert eine serielle Verbindung und am Tablet mit Sockets?

Wow, der macht sich ja richtig gut :)
Bin auch beeindruckt, dass die Beine sich trotz des einfachen Aufbaus so flüssig bewegen und auch der Laufalgorithmus ist schön flüssig ohne dass er ins Wanken gerät. Wieviel wiegt eigentlich das Fliegengewicht? Ist ja auch schon sehr kompakt gebaut. Wenn ich den Sensor am Kopf so sehe kann ich davon ausgehen, dass der noch autonom werden soll?

Hallo,

also die WLAN Übertragung ist recht simpel: ja - es wird ein Socket verwendet - dieser wird von dem RN 171 Modul bereit gestellt. Per TCP-Protokoll wird alle 200 ms ein Befehlssatz aus 7 Bytes übergeben, die dann vom WLAN-Modul via USART an den Microcontroller übergeben werden.

Das mit dem flüssigen Gang hat eine Weile benötig. Ich hatte mir zunächst ein SImulations-Programm für die SImultane Analyse erstellt. Letztendlich hat aber die zeichnerische Lösung zum Erfolg geführt. Im Video, auf dem unebenen Weg, kippt er noch ziehmlich häufig, auf ebenen Boden passiert das nicht.

Das Gesamtgewicht beträgt knapp 400g.

Sehr erstaunlich: nach ordentlichem Aufladen des Akkus habe ich jetzt Teilweise Laufzeiten von bis zu 45 min gehabt - das erfreut mich sehr!

Der Sensor war für den autonomen Betrieb gedacht - durch die Verringerte Betriebsspannung (3,3 V) hat er noch eine brauchbare Reichweite von ca. 20-30 cm. Leider ist der Atmega mit seinen 8 MHz (Begrenzt durch die Betriebsspannung von 3,3 V) sehr ausgelastet - es stehen nichtmal mehr als 25 % der Ressourcen zur Verfügung.

Wie es jetzt weiter geht weis ich noch nicht genau - eigentlich würde ich das ganze jetzt gerne eine Nummer größer bauen um mehr Möglichkeiten zu haben...

Gruß Erik

Also ich finde den auch wirklich Klasse gebaut. Besonders gefällt mir wie der Sensor angebaut ist - sieht irgendwie aus ...wie "Drohne besser" ;)

Schön dein kleiner. Jetzt will ich auch so einen, wieviel hat der denn ca. Gekostet?

Mit was für einem Akku läuft der? schon LiPo oder immernoch die 4 NiMH Zellen?

Wo berechnest du die IK? Auf dem Mega oder extern?

Würde es dir Ausmachen, den IK Algorithmus zu Posten? Bin da sehr interessiert dran, eigentlich mehr an dem Punkt mit dem Bein anheben. Beim Rest ist es auch immer schön zu sehen, wie das andere gelöst haben.

Hallo,

eine genaue Übersich der Kosten habe ich nicht, aber es wird sich so zwischen 150 - 200 € einpendeln.
Hier ein paar der wichtigsten Komponenten, natürlich kommt viel Kleinkram hinzu.

1x WLAN-Modul RN 171 35 €
13x Servo zu 5 €
1x NiHm-Akku 4,8V 2300mAh 20 €
1x Distanzsensor 13 €

Bei dem Akku handelt es sich um einen NiHm-Akku mit 2300 mAH - der war eigentlich mal für einen anderen Roboter gedacht - hat sich hier aber hervoragend bewährt. Die Laufzeit von 30-45 min finde sich sehr zufriedenstellend. Und von den Maßen und dem Gewicht des Akkus passt es auch. Die meisten LiPo's wären zu lang gewesen um sie im Torso gut unter zu bekommen.

Der Code ist eigentlich sehr einfach geschrieben - das sieht man auch im Video: das Absetzten der Beine ist sehr abrupt. Alle Beine laufen zu 25 % der Laufzyklus versetzt zueinander - das werte ich dann mittels Modulo-Operation aus und die Beine verhalten sich dann entsprechend ihrer Position.

Code:

---

while (schlafen)
{
    sleep_mode ();
}
schlafen = 1;
           
i = (i + speed)%100;
       

weg = (i + 100) % 100;
y_offset = 6 * sin(weg / 100.0 * 2.0 * M_PI - 0.75 * M_PI);
weg = (i + 150) % 100;

if (weg > 74)
{
    x = 30.0 + (weg - 75.0) / 100.0 * 60 * 3.0;
    z = -50.0;
}else{
        x = 90.0 - weg / 100.0 * 60 * 4.0 / 3.0;
        z = -60.0;
}

y = -60.0 + y_offset;

move(0, x, y, z);        // Bein_vr


weg = (i + 175) % 100;

if (weg > 74)
{
    x = -90.0 + (weg - 75.0) / 100.0 * 60 * 3.0;
    z = -50.0;
}else{
    x = -30.0 - weg / 100.0 * 60 * 4.0 / 3.0;
    z = -60.0;
}
       
y = -60.0 + y_offset;

move(1, x, y, z);        // Bein_hr

weg = (i + 125) % 100;

if (weg > 74)
{
    x = -90.0 + (weg - 75.0) / 100.0 * 60 * 3.0;
    z = -50.0;
}else{
    x = -30.0 - weg / 100.0 * 60 * 4.0 / 3.0;
    z = -60.0;
}
   
y = 60.0 + y_offset;

move(2, x, y, z);        // Bein_hl


weg = (i + 100) % 100;

if (weg > 74)
{
    x = 30.0 + (weg - 75.0) / 100.0 * 60 * 3.0;
    z = -50.0;
}else{
    x = 90.0 - weg / 100.0 * 60 * 4.0 / 3.0;
    z = -60.0;
}

y = 60.0 + y_offset;

move(3, x, y, z);        // Bein_vl

---

Mit dem Befehl "Sleep-Mode" bezwecke ich nur, dass die Bewegungsberechnung nur alle 20 ms ausgeführt wird.

Die Variabel "i" zählt nun fortlaufend für den Zyklus und wird mittels %100 für einen Zyklus von 100 % ausgewertet. Die Versätze der Beine erreiche ich durch das Adddieren der jeweiligen 25 %:
weg = (i + 100)%100
weg = (i + 125)%100
weg = (i + 150)%100
weg = (i + 175)%100

Wenn der "weg" des jeweiligen Beins unter 75 % der Bewegung liegt wird eine Vorwärtsbewegung ausgeführt, wenn sie über 75 % liegt wird angehoben und zurück gesetzt. (z = - 60 - unten; z = -50 - oben)
Die Bewegung wird dann abhängig vom jeweiligen Bein (der Koordinatenursprung sitzt im Roboter-Torso, die X-Achse zeigt geradeaus) im Bereich von (+/-)90 bis (+/-)30 mm mit einer Schrittweite von 60 mm ausgeführt. Für eine gleichmäßige Bewegung wird während der 75 % Vorwärtsbewegung mit 4/3-facher Geschwindigkeit bewegt und beim Rücksetzten (der restlichen 25 %) mit 3-facher Geschwindigkeit.

Die Nummerierung der Beine ist im Uhrzeigersinn (0, 1, 2 und 3). Das Vertauschen der Versätze 150, 175, 125 und 100 für die Beine 0, 1, 2 und 3 hat sich zeichnerisch als die optimale Abfolge erwiesen, da der Schwerpunkt so immer stabil ist. Zusätzlich wird noch eine Sinusbwegung (y_offset) in Laufrichtung aufmodeliert um eine zusätzliche Sicherheit zu erhalten.

Der Befehl "Move" berechnet dann die Servowinkel für die entsprechenden Koordinaten - die Position des Hüftgelenks der jeweiligen Beine wird dort berücksichtigt und subtrahiert.

Da sich gezeigt hat, dass es keinen großen zeitlichen Nachteil bei der Berechnung gibt verwende ich fast nur Fließkomma-Variabeln. Am längsten dauert die Berechnung der Servowinkel durch die Winkel-Funktionen Sinus, Cosinus und Tangens.

Ich hoffe diese Erläuterung hilft dir ein bisschen weiter!

Gruß Erik