Quadruped - und er läuft...

[erik_wolfram]

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:

(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

[Ripper121]

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

[erik_wolfram]

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:

// 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