mag ja sein, aber immerhin hättest du Beladungs-Kapazität und andererseits brauchst du ja pro Bein nicht das volle Leergewicht / 6 abfedern, sondern nur einen Teil, vlt auch nur hälftig, und dazu kommt, dass die Rückstellungszeit ja nur kurz ist gegen die Belastungs- und Vortriebszeit.
Sicher macht es aber mechanisch keinen Sinn, die Servos volle Kraft leisten zu lassen, nur um das Grundgewicht ständig zu stemmen, bei null Rückstellkraft.
Das wäre das gleiche, als wenn du dich statt zu gehen ständig in Kosakentanzhaltung mit 90° angewinkelten Knien vorwärtsbewegen würdest.
naja, war ja nur ein Tipp für mehr Traglast, und ein paar Zugfedern wären ja keine große Sache....
Danke für deinen Tipp. Recht hast du ja schon.
Wenn man es so betrachtet, wäre ein Radantrieb doch viel effektiver. Der muß nur Energie in den Vorschub investieren. Im Tierreich liegen die Reptielen mit seitlich angeschlagenen Beinen auch die meiste Zeit auf dem Bauch. Und die Tiere die immer stehen, haben die Beine unter dem Rumpf.
P.S. Die Rückstellzeit ist in etwa gleich lang wie die Vortriebszeit(im Laufmodus 3-3).
wie gesagt, war ja nur ein Tipp, aber auch Muskel-und Sehnensysteme bei Tieren haben durchaus eine federartige Vorspannung, und der evolutionäre Schritt, die seitlichen Beine unter den Körper zu bringen und durch die "passive Stützung" die Energie-Effizienz zu verbessern, war ja auch mit einer Erhöhung der Lauf-Effizienz verbunden.
Was die Bewegungssteuerung angeht, interessiert mich aber auch dein "Bewegungs-Algorithmus":
Wie genau sieht dein Progamm aus, wie steuerst du jede Bein-Einzel-Bewegung, um die gewünschte Gesamt-Bewegung des Rumpfes zu erreichen, z.B. bei Kurven oder auf der Stelle drehen und verschiedenen Bogen-Geschwindigkeiten und -Richtungen, auch rückwärts und seitwärts?
die Frage ist gut... Da könnte man bestimmt ein paar Stunden am Stammtisch rum bekommen. Ich versuch mich mal kurz zu fassen.Zitat von HaWe
Das Steuerungskonzept sieht bis jetzt so aus: Der 1x µC liest die Potis/Tasten von der Kabelvernbedinung ein. Dort werden die noch mit einer "keine Eingabe erfolgt" Zeitkonstante verwurstet und per UART an den 2. µC gesendet. Also hat der 1.µC z.Zt. nicht wirklich viel zu tun.
Geradeaus (Vorwärts/Rückwerts):
Es wird für jedes Bein die bekannte IST-Position genommen, und die Position des Beins längs zum Roboter neu berechnet. Also -+ 0 bis 1mm pro Schleifendurchlauf, je nach Potistellung. Der Seitliche Abstand bleibt dabei konstant, es sein den dieser weicht vom Soll (Standartwert) ab. Das wird dann beim Umsetzen des Beins behoben.
Kurvenlauf (Vorwärts/Rückwärts):
Aus der Bekannten IST-Position des Beins (im Bezug zur Robotermitte) wird die Globale Position zum Kurvenmittelpunkt errechnet. Für jedes Bein einzeln. Der Kurvenmittelpunkt liegt immer auf einer Achse Vetikal (Seitich) zur Robotermitte. Aus dem UART empfangenen Daten sind Vorwärts/Rückwärts (0 bis 1mm) und der Kurvenradius bekannt. Es wird um "Vorwärts/Rückwärts" die Sehnenlänge verschoben. Und aus den neuen Globalen Position auf jedes Bein einzeln zurück gerechnet. Somit ergibt sich für jedes Bein eine neue Längs- und Seiten- Position.
Um die eigene Achse drehen (Links/Rechts):
wie Kurenlauf nur das der Radiusmitelpunkt in der Mitte des Roboters sitzt.
Seitliches laufen kann er nicht.
Um die Schrittfolge der Beine einzuhalten sind gleich zwei funktionen implementiert. Erstens wird immer jedes Bein um (Vorwärts/Rückwärts) verschoben. Bei Kurvenlauf im Verhältniss des Einzelbein-Radius zur Robotermitte (Strahlensatz). Überschreitet ein Bein z.B. beim Umsetzen sein Grenzwert, wird dieser bei "Bein nicht am Boden" wieder aufgeholt.
Auserdem ist für jeden Laufmodus (3-3/4-2/5-1) die Beinspreizung in % hinterlegt (Konstante). Befindet sich das Bein im Rückhub (Umsetzen) wird die IST-Position in % zur Sollposition in % verglichen. Bei Abweichungen wird das Bein verlangsamt, beschleunigt oder der Rückhub sogar abgebrochen. Ist ziemlich kompliziert implementiert, da es so viele Optionen gibt (3 Laufmodi mit Vor/Rück, Kurve, Kreisdrehung)
Jedes Bein wird ein paar mm vor Ende seiner maximalen Auslenkung (längs zur Robo) bereits vom Boden abgehoben, um bei Richtungsumker des Beins nicht den Roboter abzubremsen. Gleiches gilt für das ende des Umsetzvorgangs. Das Bein nimmt erst wieder fahrt mit dem Roboter auf ehe es auf den Boden aufsezt. Das Spart so ca. 4A, und der Robo läuft um einiges flüssiger.
Die Grenzwert längs zum Roboter werden im Kurvenlauf auf den Beineinzelradius angepasst. Somit ist die Schrittlänge jedes Beines variabel. Geradeaus sind alle gleich. Aber bei Kurvenlauf, werden die kurveninneren Schrittlängen eingekürzt.
So ich denke das ist es jetzt mal ganz knapp, und hoffe ich hab mich verständlich ausgedrückt. Falls nicht werde ich versuchen deine Fragen zu beantworten.
mfg Thomas
danke für die Info!
Ich meinte allerdings keine Kurzbeschreibung, sondern vor allem auch den genauen Programmcode. Könntest du den bitte auch mal hier einstellen?
vG
Helmut
Ob dir mein Code hilfreich ist, wage ich zu bezweifeln. So toll sind meine Fähigkeiten dann nicht. Aber wer weiß vielleicht kannst du mir auch paar Tips geben.
Was hast du mit der SW vor? Rein zum basteln, oder ein kommerzielles Projekt?
ich selber interessiere mich nur hobbymäßig für Hexapods, besitze aber noch keine Hardware dafür und auch noch keinen Programmier-Plan.
Geändert von HaWe (01.08.2016 um 17:05 Uhr)
Für eine PN ist die Nachricht zu lang. Dateien Hochladen (keine Bilder) schaffe ich hier nicht. Am besten wäre wohl eine "echte" email...
für welche Plattform (AVR, Arduino, Raspberry) und ggf. in welcher Sprache programmierst du denn (C, C++, Bascom, Python, Java,....) ?
Bascom habe ich aufgeben. Ist in C für ATXmega.
Berechtigungen
Zitieren
Lesezeichen