Sonntag, den 07. August 2011 um 16:38 Uhr
Michael Fauth
Da mittlerweile die Portierung auf den STM32 abgeschlossen ist, war zeitgleich auch eine neue Benutzeroberfläche fällig. Wie anhand der Bilder unschwer zu erkennen ist, läuft die Software jetzt unter Windows. Als Entwicklungsumgebung kommt Visual Studio 2010, und als Sprache C# zum Einsatz. Man verzeihe mir die lustige Sprachmischung, ich kann mich oft einfach nicht zwischen Deutscher und Englischer Namensgebung entscheiden :D
Hier ein paar Eindrücke der neuen Software, deren Umfang jedoch noch recht bescheiden ist.
Die Kommunikation erfolgt über einfache ASCII Befehle wie sie unten in der Console beispielhaft zu erkennen sind. Das vereinfacht das Debuging enorm, da jeder Befehl zumindest für mich weitgehend selbsterklärend ist. Die Software setzt jeden Befehl lediglich in eine passende ASCII Repräsentation um, die gesamten Berechnungen finden dann lokal im Bot statt.
Zuletzt aktualisiert am Sonntag, den 07. August 2011 um 21:32 Uhr
Neigunskompensation
Sonntag, den 07. August 2011 um 16:09 Uhr
Michael Fauth
Pünktlich zu den Semesterferien gibt es mal wieder etwas neues zu berichten. Der Bot ist nun in der Lage, einen geneigten Untergrund zu erkennen, und dabei den Körper immer horizontal, bzw. in einer beliebigen Lage zu halten. Da Bilder, bzw. ein Video ja bekanntlich mehr sagen als 1000 Worte, werde ich mich an dieser Stelle kurz fassen ;)
Zuletzt aktualisiert am Sonntag, den 07. August 2011 um 16:34 Uhr
Gehirn mit STM32 und Funk
Freitag, den 04. März 2011 um 13:45 Uhr
Michael Fauth
Leider hat sich in letzter Zeit immer mehr herausgestellt, dass die Lösung mit dem IGEPv2 einige Probleme mit sich bringt. In erster Linie bereitet die Anbindung an den CAN Bus Schwierigkeiten. Den Flaschenhals stellt hierbei die Verbindung des IGEPv2 mit dem CAN Adapter dar. Diese Schlüsselstelle läuft über einen UART und ein selbst entwickeltes Protokoll. Leider macht es sowohl auf der Seite des Linux Boards, als auch auf dem CAN Adapter große Probleme, die harten Ansprüche an das Timing einzuhalten. Gleichzeitig verfügt der CAN Adapter mit seinem Mega8 nur über begrenzen Speicher, was die Pufferung der CAN und der UART Kommunikation extrem erschwert.
Des weiteren habe ich diverse Probleme mit der Linux Programmierung, bisher habe ich zum erstellen der Grafischen Benutzeroberfläche das GTK Toolkit verwendet. Anfangs war dies ideal, da ich schnell zu recht guten Ergebnissen gekommen bin. Eine ansprechende Visualisierung von Messwerten hat sich aber beispielsweise als extrem aufwändig erwiesen. Somit ist auch hier ein wechsel der Umgebung naheliegend.
Auch kann ich zwischenzeitlich die Hardware Anforderungen der IK recht gut abschätzen, und habe mich daher für eine Betriebssystemlose Controller Lösung entschieden. Diese hat den großen Vorteil, das ich sowohl Hard- als auch Software von Grund auf selbst entwickeln kann, und somit alles selbst in der Hand habe ohne mich beispielsweise auf seltsame Linux-UART Bibliotheken verlassen zu müssen und bei der Fehlersuche zu verzweifeln.
Zuletzt aktualisiert am Freitag, den 22. Juli 2011 um 14:49 Uhr
IMU Unit
Freitag, den 04. März 2011 um 12:57 Uhr
Michael Fauth
Nun habe ich es also endlich geschafft. Es gibt eine neue Platine, welche eine erste Orientierung im Raum ermöglicht. Es ist mir damit möglich, die Absolute Neigung im Raum, sowie die Ausrichtung in Bezug zum magnetischen Nordpol festzustellen. Eine Auswertung dieser Daten erfolgt derzeit aufgrund diverser Softwareprbleme noch nicht, es wird in nächster Zeit eine größere Änderung im Bereich der IK-Berechnugen geben. Allerdings funktioniert die Darstellung auf dem Display, welches Zeitgleich um eine grundlegende Menüstruktur ergänzt wurde und nun zwischen den einzelnen Menüs direkt am Bot gewechselt werden kann.
Im Rechten Bild Zeigt der Grüne Strich stets in Richtung Norden, auch dann, wenn der Bot geneigt ist. Diese Neigung wird durch den Roten Punkt dargestellt, befindet sich dieser in der Mitte des Kreises, steht der Bot horizantal ausgerichtet. Eine Abweichung von der Mitte entspricht einer Neigung in die entsprechende Richtung. Zusätzlich dazu sind die zugehörigen Zahlenwerte im oberen Bereich ablesbar.
Zuletzt aktualisiert am Freitag, den 04. März 2011 um 13:38 Uhr
OLED Display
Dienstag, den 24. August 2010 um 12:12 Uhr
Michael Fauth
Seit kurzem kann man sich direkt am Roboter einen kleinen Überblick über verschiedenen Betriebsdaten verschaffen. Dazu wurde ein 128x128 Pixel großes OLED Display montiert. Momentan sieht die Anzeige so aus, ein wechseln der Anzeige oder gar ein richtiges Menü ist noch nicht implementiert, aber geplant.
Kurzer Überblick über die Bedeutung: Oben links eine (sehr) vereinfachte Draufsicht auf den Bot. Ein grüner Punkt steht für ein Bein mit Bodenkontakt.
Oben Mitte: Laufzeit seit anlegen der Akkuspannung und seit diesem Zeitpunkt verbauchte Akkukapazität.
Oben rechts: Funktion der Taster.
Mitte: f/s: Anzahl der Frames per Second auf dem CAN Bus Net. B/s: Die Nettodatenrate auf dem Bus in Byte/Sekunde. Brut.B/s: Die Bruttodatenrate auf dem Bus inkl. Protokolloverhead etc. in Byte/Sekund
Die aktuelle Stromaufnahme und direkt darunter ein Diagramm welches den Stromverlauf der letzten 30 Sekunden darstellt. Der Verbrauch ist auf dem Bild konstant und daher eine durchgehende grüne Linie. Ganz unten: Aktuelle Akkuspannung als Zahl und auf einem Balken aufgetragen.
Zuletzt aktualisiert am Mittwoch, den 11. August 2010 um 20:22 Uhr
Inverse Kinematik
Freitag, den 23. Juli 2010 um 13:37 Uhr
Michael Fauth
Heute war es also endlich so weit. Nach unzähligen Problemen konnte ich endlich die ersten koordinierten Bewegungen bewundern. Die Inverse Kinematik ermöglicht es, die Position des Bots alleine durch einen Punkt im Raum, sowie einem Drehwinkel pro Raumachse zu bestimmen.
Die größte Schwierigkeit hierbei ist es, die Winkel der 18 Gelenke zu jeder Zeit so zu bestimmen, dass der Punkt, an dem ein Bein den Boden berührt - zumindest so lange nicht anders von der Software vorgegeben - stets der selbe bleibt.
Nun aber zu allererst mal ein kurzes Video welches diesen Erfolg auch belegt. Die theoretische Abhandlung folgt dann weiter unten.
Zuletzt aktualisiert am Freitag, den 23. Juli 2010 um 18:54 Uhr
Servosteuerung
Montag, den 17. Mai 2010 um 21:45 Uhr
Michael Fauth
Insgesamt 18 Servos wollen mit einem Signal gefüttert werden. Um für Zukünftige Anwendungen gerüstet zu sein habe ich die Schaltung jedoch auf 21 Kanäle ausgelegt.
Die wichtigsten Funktionen im Überblick:
Ausgabe von 21 Servo Signalen mit einer theoretischen Auflösung von 16 000 Stufen pro Servo im Bereich von 0,5 - 2,5 ms Impulsdauer. Praktisch ist die Auflösung durch sich möglicherweise überschneidende Interrupts geringer. Dies spielt jedoch kaum eine Rolle, da die Servos ohnehin nicht in der Lage sind so genau zu stellen
Strommessung auf jedem einzelnen Servo Kanal
Ausgabe der Messwerte auf dem CAN Bus
50 mal pro Sekunde die Soll- Position der Servos empfangen, umrechnen, und entsprechend stellen
Zuletzt aktualisiert am Montag, den 26. Juli 2010 um 10:30 Uhr
Gehirn
Montag, den 17. Mai 2010 um 13:27 Uhr
Michael Fauth
Nachdem ich unzählige Seiten mit Formeln und Zeichnungen voll geschmiert hatte, war mir klar dass ich mit meinen geliebten Atmel AVR Mikrocontrollern wohl keinen Blumentopf gewinnen werde. Schon alleine die nötigen Berechnungen um die Positionen der ersten Gelenkpunkte im Raum unter Beachtung aller Neigungswinkel zu berechnen, laufen auf recht rechenintensive Matrix Multiplikationen hinaus.
Zuletzt aktualisiert am Freitag, den 23. Juli 2010 um 18:13 Uhr
Stromversorgung
Freitag, den 14. Mai 2010 um 18:23 Uhr
Michael Fauth
Ein Thema das mich lange beschäftigt hat, war die Stromversorgung des Roboters. Dass einzige was von Beginn an klar war: Energielieferant sollte ein 3S LiPo Akku werden. Das wiederum bedeutete, das ich einen Spannungsbereich von ca. 8V - 13V abzudecken hatte. Um in Zukunft nicht wegen einer fehlenden Versorgungsspannung ein Modul nicht realisieren zu können, habe ich gleich vorweg folgende Versorgungsspannungen eingeplant...
Zuletzt aktualisiert am Freitag, den 23. Juli 2010 um 18:13 Uhr
Mechanik
Freitag, den 07. Mai 2010 um 19:04 Uhr
Michael Fauth
Auch wenn mich eigentlich in erster Linie die Programmierung eines solchen 6-Beiners reizt, so wollte ich weder einen Bausatz kaufen, noch irgend eine aus der Not entstandene Konstuktion zusammen zu frickeln. Ich kam also nicht darum herum, mich zuerst intensiv mit der Mechanik auseinander zu setzen. Die Überlegungen, die ich zu diesem Zeitpunkt anstellte, gingen von der Wahl der Servos, über die Dimensionen und die Formen der einzelnen Teile, bis hin zur Wahl geeigneter Gegenlager für die Servos. Kurz um - ich war erst mal beschäftigt. Da Mechanik nicht gerade mein Spezialgebiet ist, durfte ich mich auch erstmals näher mit CAD Software beschäftigen.
Irgendwann war aber auch dieser Schritt geschafft, und es war ein halbwegs vollständiges 3D Modell erstellt.