Archiv verlassen und diese Seite im Standarddesign anzeigen : Hexapod
Einleitung:
Die Hexapot Meisterschaften (https://www.youtube.com/watch?v=pXMnbNoccgA) sind nun schon eine Zeit lang her, und die Version ist auch schon längst überholt.
Nichts desto trotz wurde der Hexapod immer weiter entwickelt und nun gehen wir es auch dieses Jahr wieder weiter.
Änderungen zum alten Konzept:
Im der vorherigen Version wurde der Schritt von der Sandbox zum Pandaboard gewagt, und so eigentlich wieder von Grund auf begonnen. Das Gestell wurde Grunderneuert und hat nun eine andere Form.
Auf dem Pandaboard wurde Ubuntu mit einem Pseudo-RealTime Patch verwendet, was im nachinhein immer wieder Probleme mit der Pwm-Erzeugung geführt hat.
Realisierung:
Anstatt des Pandaboards wird nun das Raspberry Pie Board verwendet, der für den Laufalgorithmus zuständig ist.
Außerdem werden Pro Bein eine uController verwendet, der für die Pwm-Erzeugung der 3 Servos zuständig ist.
Die uController werden per i2c angesteuert.
Es werden nach wie vor Analoge Servos verwendet, allerdings werden diese so modifiziert das es möglich ist den Strom zu messen (Leitung ans Poti) und so endlich eine Feedbeck der Beine zu bekommen.
Einkauf:
Größter Kostenpunkt sind die 18 analogen Servos.
Vom Pandaboard aufs Rasperry wird ordentlich an Geld gespart
Das Gestell wird wie im Vorjahr aus Sperrholz vom Lasercutter geschnitten
Letzte bestehende Grundlage/alter Stand:
http://robomotion.hagenberg.servus.at/
28053
HannoHupmann
23.04.2014, 17:10
Ehrlich gesagt bin ich von der Bein-Ansteuerung alles andere als begeistert. Grundsätzlich stellt sich natürlich eh erst mal die Frage ob es ich bei dem Projekt noch um ein Hobbyprojekt handelt, wohl eher nicht, aber egal. Zurück zum Thema: durch die modulare Ansteuerung wird es sehr schwierig die Beine später sauber zu synchronisieren. Hier favorisiere ich einfach einen Lösung mit einem µC der alle PWM Signale erzeugt. Es gibt bereits genug µC auf dem Markt die die locker 18 Servos steuern können.
Weiter sind Stromsensoren pro Servo, zwar nicht völlig unnütz aber eine Positionsüberwachung deutlich sinnvoller. Da das Poti eh schon angezapft wird, könnte man den Spannungsteiler auch noch auf einen AD Eingang des µC legen und so einen Regelkreis aufbauen.
LiPo Akkus sind heute Pflicht für Hexas und ein eigener Spannungsregler dürfte bei HiTec Servos gar nicht notwendig sein. Ansonsten tut es hier sicher ein SBEC mit 20A den es für etwa 20€ von der Stange zu kaufen gibt. Alle Lösungen mit Spannungsreglern sind nicht umsetzbar.
So und weil ich gerade so schön am meckern bin gleich noch: das Design ist meiner Meinung nach unpraktisch!
Grundsätzlich stellt sich natürlich eh erst mal die Frage ob es ich bei dem Projekt noch um ein Hobbyprojekt handelt, wohl eher nicht, aber egal.
Ist im Rahmen des Studienprojekts :)
Zurück zum Thema: durch die modulare Ansteuerung wird es sehr schwierig die Beine später sauber zu synchronisieren. Hier favorisiere ich einfach einen Lösung mit einem µC der alle PWM Signale erzeugt. Es gibt bereits genug µC auf dem Markt die die locker 18 Servos steuern können.
Haben da nichts anständiges gefunden was uns Preis/Leistungsmäßig gefallen hätte, deswegen die Verwendung von 6 ATTIN24P.
Außerdem könnte es mit dem Timing kritisch werden, da wir ja auch noch 2 ADC Werte pro Servo haben(Position und Strom)
Schaltung (http://www.directupload.net/file/d/3601/zzts6vri_jpg.htm)
LiPo Akkus sind heute Pflicht für Hexas und ein eigener Spannungsregler dürfte bei HiTec Servos gar nicht notwendig sein. Ansonsten tut es hier sicher ein SBEC mit 20A den es für etwa 20€ von der Stange zu kaufen gibt. Alle Lösungen mit Spannungsreglern sind nicht umsetzbar.
Wir sind von der vorherigen Version auf die aktuelle von LiPos wieder weg. Weil die Regler die Spitzenströme nicht abfangen können, was bei der letzten Version zum Zusammenbruch geführt hat.
das Design ist meiner Meinung nach unpraktisch!
finde ich jetzt persönlich auch nicht so prickelnd, allerdings funktioniert sie, und da wir in absehbarer Zeit was laufendes haben wollen, ist das Design vom Gerüst mal hinten angestellt.
durch die modulare Ansteuerung wird es sehr schwierig die Beine später sauber zu synchronisieren. Hier favorisiere ich einfach einen Lösung mit einem µC der alle PWM Signale erzeugt.
Das würde ich nicht unbedingt so eng sehen. I2C auf einem AVR läuft bei bis zu 400 kHz, das entspricht optimistisch gerechnet 50 kB/s Datenrate (natürlich geht noch einiges für Adressierung flöten, außerdem ist die Flankensteilheit der I2C Signale ein begrenzender Faktor), was 20 µs/Byte entsprechen würde. Wenn man also entsprechend kurze Telegramme zur Positionsübermittlung verwendet, kann man ohne weiteres eine schnellere "motorische Kommunikation" realisieren, als im menschlichen Nervensystem.
Ich hab's damals bei meinem Hexapoden auch so gemacht, es gibt einen Controller je Bein, alle Beincontroller werden als I2C Slaves von einem Master kontrolliert. Jedes Bein bekommt vom Master einfach die Sollposition für die Fußspitze, rechnet seine eigene IK und stellt die drei Gelenke dementsprechend ein. Das war kein Problem:
http://youtu.be/cV995qrkcao
(dass die Bauweise des Hexas ansonsten aber ziemlich wabbelig war stimmt auch... :-))
Gruß
Malte
HannoHupmann
23.04.2014, 19:48
Meine Güte, das mit den Reglern und den Spitzenströmen wurde hier im Forum jetzt schon mehrfach diskutiert. Eigentlich wird es in jemdem Hexabot Threat noch mal erklärt. Also auch hier wieder. Natürlich kann kein Regler der Welt die Spitzen glätten die bei einem Hexa auftreten. Manche Systeme aus Servos und Akku sind stabil genug um einfach darüber hinweg zu sehen, andere reagieren etwas empfindlicher. Daher gilt es eine großgenuge Anzahl von Kondensatoren einzubauen, die die ganzen Spitzen glätten. Ich rede hier allerdings nicht von ein paar kleinen 100nF oder 100µF sondern eher von 6800µF für jedes Bein. Leistungselektronik ist eben ganz was anderes als 5V Logikspannung.
LiPos sind da einfach erste Wahl und ja man muss ein wenig mehr Aufwand betreiben für die Ansteuerung, aber dafür passt am Ende auch das Gewicht.
@Malty es geht mir nicht um die Datenmenge sondern um die Tatsache, dass man die Daten nicht synchron an alle Beine schicken kann sondern immer leichte latenzen mit einbaut. Das kann am Ende zu Problemen führen, außer es ist einem egal, wann sich die Beine bewegen.
Es gibt µC mit 80Mhz, das reicht dicke um alle Beine anzusteuern.
Die Datenmenge die pro Zeit verschickbar ist, ist ein Maß dafür, in welchem absoluten Zeitfenster die unterschiedlichen Slaves mit Steuerdaten versorgt werden können. Wenn dieses Fenster hinreichend klein wird - und das ist für diese Anwendung mMn bei I2C der Fall - ist damit kein praktisches Problem mehr verbunden. Die Leute haben früher (mich eingeschlossen) mit analogen Servos gebaut, deren Regelung lief bei ca. 50 Hz! Und die standard Digitalservos kann man maximal auch nur mit etwa 300 Hz updaten. Wenn man ein verlässliches Timing in dieser Größenordnung hinbekommt, ist alles im grünen Bereich. Und das geht mit I2C. Wegen der eher lächerlichen Trigonometrie die man für eine Hexapoden-IK benötigt gleich einen riesigen Controller zu verwenden finde ich auch nicht gerade elegant. Okay, ob's ökonomisch ist, für jedes Bein einen eigenen Controller einzusetzen, darüber kann man natürlich auch streiten :-).
Gruß
Malte
Das sich das mit dem Timing beim i2c ausgeht denk ich nämlioch auch. Es werden ja keine große Datenmengen verrschickt(wahrscheinlich nur ServoID und Winkel). Das sollte dann kein Problem sein.
Natürlich muss auf die Latenz geachtet werden. Allerdings kommt dann auch wieder die Reaktionszeit der Servos hinzu, was das Ganze weniger kritisch macht.
Die LiPos die wir haben sind recht schwer und brauchen einen haufen platz, da sind mir normale Akku batterien lieber...
Edit: werden hier eigentlich auch irgendwo laufalgorithmen behandelt? hab bis jetzt noch nichts gefunden
HannoHupmann
24.04.2014, 10:13
Dann hast du die falschen LiPos :-P. Ganz in ernst, es gibt im Moment keine Akkus die annähernd an das Energie/Gewichtsverhältnis der Lipos ran kommen und bezahlbar sind! Abgesehen davon bekommt man heute Lipos schon für 30 bis 50€ mit ausreichender Leistung. Dann kann man schwächere Servos einsetzen und spart sich dort wieder einiges. Die grundsätzliche Herangehensweise ist einfach immer: so leicht wie nur möglich!
Laufalgos gibt es mehr als genug im Forum. In meinem Vinculum Projekt gibt es sogar einige Seiten dazu, wo ich über verschiedene Versionen diskutiere. Für eine genauere Aussage, solltest du die Frage etwas näher spezifizieren.
EDIT: Die Fragestellung ist übrigens fast schon so alt wie die Entwicklung von Hexas selbst: Modulares Konzept bei der Steuerung oder doch lieber ein zentraler Controller? Bisher habe ich im Forum immer wieder beide Lösungen gefunden und auch genug User die von modular auf zentral gewechselt haben oder in die andere Richtung von zentral zu modular. Ist also immer eine Frage der persönlichen Vorlieben, denn die Aufgabe bleibt ähnlich komplex.
So, erst mal zur Ansteuerung...hab mir folgendes Überlegt:
Aktuell sieht die Befehlstruktur so aus:
CommandForward wird aufgerufen
neue Position wird per IK aus der aktuellen Position berechnet
Laufalgorithmus startet
bei fertigstellung des kompletten wird auf den nächsten Befehl gewartet.
Vorteil: einfach implementiertung
Nachteil: Feedback der Servos kann nicht verarbeitet werden, neue Befehle werden erst nach Abschluss des Algos neu verarbeitet-->sehr langsame Reaktionszeit
Neuer Ansatz:
CommandForward wird aufgerufen
neue Position wird per IK aus der aktuellen Position berechnet
befehl für Fuß1 wird geschickt
es wird auf fertigstellung per Polling gewartet(in unserem Fall bekommen wir die Winkel zurück)
die IST-Position wird mit der SOLL-Position verglichen,
falls unterschiedlich oder neue wir bekommen einen neuen Befehl(z.b richtungsänderung) wird die Position neu berechnet,
ansonsten wird der Laufalgorithmus abgearbeitet-->befehl für Fuß2 wird geschickt
Vorteil: Nach jedem Schritt kann reagiert werden, ob nun auf Unebenheiten, Blockierungen oder neue Befehle.
Nachteil: Es kann immer nur ein Fuß bewegt werden-->Geschwindikeits defizit
Kompromiss[beste Lösung?]
CommandForward wird aufgerufen
neue Position wird per IK aus der aktuellen Position berechnet
Befehl für Fuß1, Fuß3, und Fuß6 werden geschickt, abhängig vom Laufalgorithmus können sowieso nur eine gewisse Anzahl an Füßen in Bewegung sein(dirty bit)-->kein Zeitverlust
Polling auf Fuß1, Fuß2 und Fuß3 für Rückmeldung
Sobald 1 Fuß rückmeldung gibt, wird die IST-Position wird mit der SOLL-Position verglichen,
falls unterschiedlich oder wir bekommen einen neuen Befehl(z.b richtungsänderung) wird die Position neu berechnet,
ansonsten wird der Laufalgorithmus abgearbeitet
Vorteil: keine Leerzeit, Feedback/Reaktionsfähigkeit sehr hoch
Nachteil: kompliziertere Implementierung?
HannoHupmann
27.04.2014, 18:58
Klassischerweise wird für Roboter die Steuerung durch mehre Ebenen gegliedert. Im Thread zu meinem Vinculum habe ich ausführlich beschrieben wie sowas bei einem Hexabot aussieht. Die meisten Projekte hier im Forum sind ähnlich aufgebaut, wenn auch vielleicht nicht ganz so klar differenziert. Deine Vorschläge sehen mir ehrlich gesagt etwas zu umständlich aus.
Mit einer Rückgabe der tatsächlichen Winkelposition baut der Fachmann einen Regelkreis auf und lässt diesen parallel zur Berechnung laufen.
Mit einer Rückgabe der tatsächlichen Winkelposition baut der Fachmann einen Regelkreis auf und lässt diesen parallel zur Berechnung laufen.
Regelkreis funktioniert in diesem Fall glaub ich nicht, weil wirs ja entkoppelt haben und mit i2c ansteuern. Aber die 2te/3te Steuerungsmethode sollte auf eine ähnliche funktionalität hinauslaufen
HannoHupmann
28.04.2014, 09:49
Regelkreis funktioniert immer, wenn man ihn richtig implementiert! Der wird schon auf den µC pro Bein untergebracht, alles andere macht keinen Sinn. Das hat mit der Vorgabe über i2c gar nichts zu tun, von dort kommt der Soll-Wert, der wirt mit dem Ist-Wert verglichen und der µC Regelt auf den Soll-Wert. Ein wunderbar geschlossenes System, welches sich ganz wunderbar modular aufbauen lässt, wenn es schon dabei bleiben soll.
Regelkreis funktioniert immer, wenn man ihn richtig implementiert! Der wird schon auf den µC pro Bein untergebracht, alles andere macht keinen Sinn. Das hat mit der Vorgabe über i2c gar nichts zu tun, von dort kommt der Soll-Wert, der wirt mit dem Ist-Wert verglichen und der µC Regelt auf den Soll-Wert. Ein wunderbar geschlossenes System, welches sich ganz wunderbar modular aufbauen lässt, wenn es schon dabei bleiben soll.
und der fuß irgendwo blockiert? bzw. auf etwas draufgetreten ist? dann kann er doch gar nicht auf den SOLL wert, dann muss mit dem aktuell IST wert weitergerechnet werden-->der Wert wird bei der IK benötigt.
oder nicht?
HannoHupmann
28.04.2014, 10:10
Doch natürlich, kommt eben darauf an was man macht! Wird das Poti abgefragt, dann kann man darüber einen Regelkreis aufbauen aus Soll und Ist-Wert. Wird der Strom an Servo abgefragt, kann man diesen überwachen.
Aus beiden Sensorwerten allein lässt sich aber nicht einfach erkennen, dass der Roboter irgendwo hängen bleibt.
Möglich ist es mit der Kombination: Der Positionsregelkreis meldet, dass die Sollposition nicht erreicht wird und gleichzeitig meldet der Stromsensor einen Anstieg im Stromverbrauch. Nun könnte man annehmen, dass das Bein irgendwo hängen geblieben ist! Alternativ kann es aber auch einfach sein, dass der Roboter sich gerade "hochdrückt" und daher mehr Strom verbraucht und die Sollposition noch nicht erreicht.
Mit Kontaktsensoren am Bein (unten und seitlich) könnte man deutlich besser erkennen ob der Hexa "hängen bleibt"
Einfach mal als Hausaufgabe überlegen: Wie sehen die Sensorsignale (Poti und Stromverbrauch) bei "Bein bleibt hängen" von "Bein bewegt sich wie gewünscht" aus und worin müssten sie sich unterscheiden.
bei bewgung des fußes:
Wenn er wo hängenbleibt bekommen wir einen erhöhten stromverbrauch bei einem wert von servo 1, 2 und 3 die nicht SOLL ist.(zusätzlich könnte überprüft werden welcher servo a meisten strom benötigt, um die belastungsart zu erkennen)
bei bewegung des körpers:
belastung passiert haupsächlich bei servo 2 und 3 da diese heben und servo 1 haupsächlich nach vorne schiebt?
blockiert dann, wenn servo 1 nicht bei der SOLL position ankommt
also geht es im endeffekt um die unterscheidung von bein bewegen, und körper bewegen
mit modular meinst du trennung von laufalgrithmus und regelung, was in unserem fall auf dem raspberry einfach 2 thread bedeuten würde(1 für die berechnung/ steuerung, 2 für den regelkreis)
hört sich zumindest in meinen ohren ganz sinnvoll an :D
soooo.....
Der Laufalgorithmus wurde wieder hinten angestellt, und es wurden einige strukturelle Änderungen im Code vorgenommen.
Bis jetzt wurde ein kompletter Schritt mehr oder weniger in einem Viereck ausgeführt(aktuelle position, fuß heben, fuß nach vorne, fuß runter-->endposition)
Hat natürliich funktioniert, aber eine schöne Bewegung ist was anderes.
Da wir ja die Aktuelle und die Ziel position haben, hab ich mir volgendes Überlegt:
Zwischen der Anfangs und der Endposition wird der Mittelpunkt berechnet+ein Offset(je nachdem wie "hoch" er steigen soll)
Durch die 3 Punkte im Raum Spanne ich eine Ebene in der ich die 3d Koordinaten in 2d umwandle, und dann durch diese eine Parabelgleichung berechne.
Mit dieser Parabelgleichung kann ich beliebig viele Punkte auf meinen weiteren Weg zu Ziel Position berechnen-->was dann die Gesamtbewegung schön flüssig machen sollte
edit: annäherungsweise(ausgehend davon das y von ist, und soll postion 0 ist) kann man sich die ganze umrechnung sparen und mit x und z die parabel berechnen
long long time ago.....haben wir ja angefangen, n paar mal auf die seite gelegt, und weil am wochenende ein Hakaton war haben wir uns mal wieder rangesetzt und die Inverse Kinematik mit der Body ik implementiert
first view:
viel koffein, alkohol und n schlechtes video
https://www.youtube.com/watch?v=rtoEjyTfzdg&feature=youtu.be
infos:
das gehirn ist ein Raspberry Pie der über i2c auf 6x attinys die befehle an die Servos schickt
noch viel zu tun, wobei fast alle problem softwarelastig sind
+ wieder motivert ihn weiter zu entwicklen
lg
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.