Microcontroller > Robotics

Witty self-balancing Bot

(1/7) > >>

Rene:
Hallo Witty - Programmierer

Hat jemand von euch sich schon etwas mit der Programmierung des Wittys vertraut gemacht? Ich bin mir immer noch nicht sicher, auf welcher Ebene man da einsteigen sollte.

Man merkt, dass Jean-Daniel ein Hardwaremensch ist. Er denkt in Registern und einzelnen Bits. Die Programmierung dient nur dazu, die Hardware in den gewünschten Zustand zu versetzten.
Dadurch wird der Code unglaublich kompakt und leistungsfähig, ist aber gar nicht so einfach zu verstehen.

Ich als Softwaremensch und Informatiker denke in Klassen und Datenstrukturen. Die Hardware ist nur dazu da, das was ich zusammenprogrammiert habe zu visualisieren. Solche Programme sind auf Mikrokontrollern aber oft zu gross und zu langsam.
Ich als Arduino - Programmierer stecke irgendwo dazwischen. Ich setze mich mit der Hardware auseinander, muss aber nicht die Funktion jedes einzelnen Bits kennen.

Die beim Witty mitgelieferten Bibliotheken steuern nicht nur die Hardware, sie ersetzen auch beinahe alles, was die Arduino - Umgebung so komfortabel macht.
Grundsätzlich würde es ja genügen, die Anwendung der mitgelieferten .h - Files zu verstehen und die eigenen Programme darauf aufzubauen. Obwohl auch einige Anleitungen und Beispiele zu den .h - Files vorhanden sind, kommen aber immer wieder Detailfragen zu einzelnen Funktionen auf. Und dann hilft nur ein Blick auf die Implementation dieser Funktionen.

Wie weit möchtet ihr gehen oder bin ich der Einzige, der einen Arduino-Pin nicht im Kopf dem richtigen Bit im richtigen Register zuordnen kann? Dürfen wir zum Beispiel in unserem PID-Regler die Arduino - Funktion millis() und micros() verwenden oder müssen wir dazu einen eigenen Timer - Interrupt aufsetzen?

Übrigens PFM anstelle von PWM für die Motorgeschwindigkeit ist absolut genial und MUSS verwendet werden!

Gruss
René
 

boxtec-support:
Hallo zusammen,

Es besteht natürlich überhaupt kein Zwang irgendeine von JDs Libraries zu verwenden, ich glaube aber sobald man alle der Hardware Features die der Witty hat (gleichzeitig) einsetzen will, kommt man um diese kompakten Bibliotheken oder zumindest ein Teil davon nicht herum.
Jean-Daniels Idee war auch, dass man explizit die Libraries anpassen soll, daher sind sie in allen Beispielen mit "" inkludiert und nicht mit <>. Diese sind in dem Zusammenhang auch eher als Beispiele zur eigenen Erweiterung gedacht.

Ich glaube, dass das Balancieren wohl die schwierigste Aufgabe wird, nicht unbedingt nur aufgrund der Aufgabe und dem zeitkritischen Charakter der Regelung, sondern vor allem weil man den Code jedesmal zum Testen erst auf den Witty spülen muss um dann zu sehen, dass er (noch) nicht so tut wie er sollte und dabei aber nicht mal eben ein paar Zeilen seriellen Debugging Output zum Analysieren zur Verfügung hat sondern nur die Beobachtung des Scheiterns.
Die Idee von Jean-Daniel ist hier z.B. über den APA102 Strip gewisse Debugging Informationen binär anzuzeigen.

Für mich selber, wird daher die erste Aufgabe darin bestehen, den Witty einfach mal balancierend geradeaus fahren zu lassen, bisher sind die Erfolge da aber eher bescheidener Natur..
Vielleicht können wir aber vorab auch für unsere Hackathons konkrete Ziele finden und ggf. die Arbeiten aufteilen wenn das gewünscht ist.

Bzgl. der Libraries: Anpassungen, Erweiterungen, Fehlerbehebungen und auch weitere Beispiele sind jederzeit sehr willkommen, wer direkten Zugriff auf das git von Witty will, soll sich bitte direkt bei mir melden.
Die Witty Library ist übrigens seit dem Wochenende auch Teil des Arduino Library Managers und kann direkt über diesen installiert (und aktualisiert) werden.

Viele Grüsse - Christoph

dinoi:
Hallo Zusammen

Den Code hatte ich kurz mal überflogen aber noch nichts weiteres damit gemacht.
Die Register nutzte ich bis jetzt in keinem Projekt somit kann ich hier nicht viel Wissen beitragen.
Wie Ihr, glaube ich auch, als erstes sollten wir den bestehenden Code bzw. die Bibliotheken verstehen.
Vorschlag: Wir ergänzen möglichst viel Code mit Kommentaren, was wird gemacht, wieso welcher Pin.
Wenn wir nichts verstehen, dann fragen wir JD. Ich bin gerne bereit Ihm in Französich zu schreiben,
dann kann er auch auf Französisch antworten. ( Was Ihm sicher einfacher fällt ).
Alle französischen Kommentare übersetzten wir in English.

Daher würde ich vorschlagen, dass wir alle direkt im Git eine Fragen/Antworten Datei anlegen wo jeder seine Fragen reinstellt und dann sende ich die an JD. Da können wir dann mehrere Zyklen machen. Wir sollten auch keine Hemmungen haben "Dumme" Fragen zu stellen.

Und ebenfalls würde ich vorschlagen wir editieren direkt im Git die Files und ergänzen sie oder wir machen einen eigenen Branch.

Bezüglich Debugging hätte ich noch zwei weitere Ideen.
a) Ein dünnes Kabel für Tx und GND welches flexibel und leicht ist. Das hält mann dann über dem Witty damit kann dieser trotzdem Balancieren oder hinfallen :-)
b) Wir hängen noch ein HC-05 Modul an, das sendet dann die Debugging Infos zum Computer/Smartphone

Debugging ist für mich sehr wichtig, jedoch sollten wir vorsichtig damit sein, es braucht Zeit und das Balancieren ist zeitkritisch.

Sobald wir dann den bestehenden Code verstehen, können wir damit spielen und Ihn anzupassen.
Jedoch denke ich sollten wir zuerst das normale fahren (mit Stütze) gut in den Griff bekommen.
Und dann die Gyro Daten auslesen und interpretieren können, soweit ich gesehen habe gibt es dazu noch nicht viel von JD.

Die nächsten Tage habe ich mir vorgenommen mit dem Witty richtig zu starten.

Gruss Reto

boxtec-support:
Hallo Reto,

Das Vorgehen, die Libs zu verstehen (und ggf. auch inline zu dokumentieren) finde ich super.

Ich würde für die Fragen vorschlagen, das Forum hier zu nutzen, so können wir einander vorerst gegenseitig helfen und alles was ungelöst bleibt an JD geben (er wird sich über jemand der französisch mit ihm spricht sehr freuen  :) ). Da mittlerweile Releases aus dem Repo gebaut werden und eine Q&A Datei dann unweigerlich auf den PCs der Nutzer die die Witty Lib installieren/updaten landen würde ist das vrmtl. nicht ideal, ausser wir verwenden z.B. das Projekt Wiki dafür.

Was wir an Erkenntnissen und Verständnis gewinnen, kann dann entweder in die Kommentierung der Quellen und/oder separate Dokumentation fliessen. Ich stelle mich da auch gerne als markup Schreiberling zur Verfügung. Wer einen Account für unser git möchte, bitte mit gewünschten Login und Emailadresse bei mir melden.

Die Idee mit dem Kabel zum Debugging ist gut, aber dann kann der Witty ja nicht mehr um die eigene Achse rotieren resp. wird praktisch durch das Kabel balanciert. Ein HC-05 ist aus meiner Sicht der bessere Weg und sollte eigentlich direkt mit einem Adapter in den Kommunikationsheader oben einsteckbar sein.

Ich hoffe an Auffahrt etwas damit spielen zu können.

Grüsse - Christoph

dinoi:
Hallo Christoph

Ok ja das ist perfekt, dann lass uns gleich mal beginnen. Ich habe heute etwas damit gespielt.

Die einzelnen Funktionen im WittyDemo2.ino habe ich ausprobiert, wobei das (2) pfm bei mir nicht funktioniert. Die Motoren bewegen sich überhaupt nicht, funktioniert das bei Euch?

Das Bild im Dokument https://www.didel.com/Witty.pdf finde ich gut, das im Git ist da weniger aktuell.

Beim (4) "demonstrate log dim" habe ich die Baud Rate im TerSer.h File erhöht. Bei 57600 funktioniert das bestens bei 115200 kommt nur Müll, wie ist das bei Euch?
Ich denke 9600 sind für uns zu wenig.
 
Bezüglich HC-05 und Debugging, hat jemand die Steckerbelegung von gem Gaia Stecker gefunden? Hat jemand so einen kleinen 1.27mm Stecker?

Danke und Gruss
Reto

Navigation

[0] Message Index

[#] Next page