boxtec Forum
Microcontroller => Robotics => : Rene May 23, 2019, 02:56:50 PM
-
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é
-
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
-
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
-
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
-
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 (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
-
Bezüglich HC-05 und Debugging, hat jemand die Steckerbelegung von gem Gaia Stecker gefunden?
Hallo Zusammen
Die Steckerbelegung habe ich gefunden, von rechts nach links. GND ist an Pin 1.
GND
VCC
Tx
Rx
Reset
Jedoch habe ich eine weitere Frage, in den Dokumenten habe ich 3 Versionen von Pinouts gefunden, welche ist die richtige ;) Siehe Anhang.
Gruss Reto
-
Hallo Reto
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?
Beim pfm-Test in WittyDemo2 bin ich auch nicht weiter gekommen. Habe dann aber etwas selbst experimentiert und mit Inter2.h und Pfm.h herumgespielt.
Das Ergebnis ist im angehängten PFMTest.zip zu finden.
Damit pfm funktioniert, muss in regelmässigen Abständen DoPfm() aus Pfm.h aufgerufen werden. Dieser Aufruf kann vom Timer2 - Interupt ausgelöst werden. Ich bin von Inter2.h ausgegangen und habe daraus ein eigenes IntTimer2.h gemacht. Der Interrupt wird alle 58 Mikrosekunden ausgelöst, wobei in der ISR dafür gesorgt wird, dass die eigentlichen Interrupt - Funktionen nur alle Millisekunden aufgerufen werden.
Die Interrupt - Funktionen können im Hauptprogramm definiert werden und dann mit addIntFunction() in die Liste eingetragen werden. Ich habe als Beispiel eine blinkende Led und den Aufruf von DoPfm() eingetragen.
Gruss
René
-
Hallo René
Perfekt besten Dank, Dein Beispiel funktioniert sehr gut. Mit pfm kann man die Motoren sehr genau ansteuern.
Übrigens das Beispiel: TestG521.ino hat die Variablen vom Gy521.h nochmals deklariert. Die habe ich entfernt dann funktioniert es auch:
//int16_t GyX,GyY,GyZ;
//int16_t AcX,AcY,AcZ;
Gruss Reto
-
Hallo Reto
Perfekt besten Dank, Dein Beispiel funktioniert sehr gut. Mit pfm kann man die Motoren sehr genau ansteuern.
Das war nur ein erster Versuch. Ich habe versucht das Ganze in Klassen zu verpacken. Das scheint auch ein gangbarer Weg zu sein, aber so richtig habe ich das noch nicht im Griff (C++ ist nicht gerade meine Lieblingssprache). Allerdings muss ich vor der Fülle von #define - Statements in Witty.h momentan kapitulieren.
Gruss
René
-
motor und intTimer2 habe ich jetzt in Klassen verpackt. Erstaunlicherweise braucht das kaum mehr Speicherplatz.
Mit dem Gyro kämpfe ich noch, bisher habe ich es noch nicht geschafft, damit vernünftige Werte zu erhalten. Ich werde aber (hoffentlich) in Kürze eine vernünftige Klasse nachliefern können.
Gruss
René
-
Salut René,
der gyro liefert sehr sprunghafte Ergebniss, so dass man sie glätten muss:
Hier der Auszug aus meinem derzeitigen testcode:
MPU6050 accelgyro;
int16_t ax, ay, az;
int16_t gx, gy, gz;
#define Gry_offset 0 //The offset of the gyro
#define Gyr_Gain 16.348
#define Angle_offset 0 // The offset of the accelerator
float Angle_Delta, Angle_Recursive, Angle_Confidence;
void Filter()
{
accelgyro.getMotion6(&ax, &ay, &az, &gx, &gy, &gz);
//Angle_Raw = (atan2(ay, az) * 180 / pi + Angle_offset);
Angle_Raw = (atan2(az, ay) * 180 / pi + Angle_offset);
omega = gx / Gyr_Gain + Gry_offset;
// Filters datas to get the real move
unsigned long now = micros();
float dt = (now - preTime) * 0.000001;
preTime = now;
float K = 0.8;
float A = K / (K + dt);
Angle_Delta = (Angle_Raw - Angle_Filtered) * 0.64;
Angle_Recursive = Angle_Delta * dt + Angle_Recursive;
Angle_Confidence = Angle_Recursive + (Angle_Raw - Angle_Filtered) * 1.6 + omega;
Angle_Filtered = Angle_Confidence * dt + Angle_Filtered;
}
In der Setuproutine lasse ich den Filter mindestens 100 mal laufen und sehe bei meinem Witty, wie sich der Winkel stabilisiert. Wenn sich der Robot aufstellt, mache ich das im loop dann auch.
Ich hoffe, das spart Dir einiges an Zeit.
Ciao, Mathias
-
Ich hoffe, das spart Dir einiges an Zeit.
Hallo Mathias,
ja, das wird es sicher. Vielen Dank. Es zeigt mir aber auch, dass ich wohl nicht darum herumkomme, mich mit den Grundlagen dieses Sensors zu befassen.
Gruss
René
-
Hallo Zusammen
Das hier finde ich einen guten Beitrag mit guten Erklärungen zum Thema "Balancieren".
Er zeigt schön auf wie er das löst.
https://www.instructables.com/id/Arduino-Self-Balancing-Robot-1/ (https://www.instructables.com/id/Arduino-Self-Balancing-Robot-1/)
Gruss Reto
-
Salut Reto,
der Artikel ist herrlich und sehr gut geschrieben. Der Code, den ich verwende basiert auf einem Robot, der anscheinend an diesem Instructable stark angelehnt ist. Leider bootet der Witty sobald ich den Motor einschalte ... Ich habe mir auch einen stärkeren Akku besorgt, hatte aber noch nicht die Zeit, den Einspeisungpunkt auf der Platine zu finden
Ciao, Mathias
-
Hallo Zusammen
Mir sind 2 Dinge noch aufgefallen:
a) Bei mir wird der sehr Gyro sehr vom Motor gestört. Ist Euch das auch aufgefallen?
a) In dem Beitrag auf Instructable schreibt der Autor, dass sein Roboter stabiler wäre wenn er etwas grösser wäre.
Irgendwie habe ich das Gefühl beim Witty auch, dass er fast zu sehr schon ausbalanciert ist zu zu leicht ist.
Das ist cool aber evtl. nicht gerade ein Vorteil. Was denkt Ihr?
Gruss Reto
-
Hallo Reto,
Zu a): das ist mir so im Zusammenhang nicht aufgefallen, aber wäre eine plausible Erklärung für zwischendurch ausreissende Werte vom Gyro.
Zu b): Wäre es ev. eine Idee den Gyro auf Headers ein paar mm in die Höhe zu bringen (mehr Ausschlag in den Messwerten) und eine doppelt so grosse Batterie zu montieren?
Ich hab heute von Jean-Daniel Headers für Euch erhalten und etwas was mit b) helfen würde, aber das zeig ich Euch morgen dann :D
Grüsse - Christoph
-
Hallo Christoph
Ich habe den Gyro auf einem "Kissen" gelagert und stelle eine Verbesserung vor allem beim Lagesensor fest. Hier zwei Messungen. Der Witty ist durch das USB Kabel stabilisiert und die Räder drehen in der Luft. Die Motoren fahren von 0 auf Max 70. Ich denke Ihr seht den Unterschied zwischen mit "Kissen" und ohne.
Blau => Motor
Grün => Beschleunigungssensor
Rot => Lagesensor
In der Hälfte der Zeit habe ich den Witty noch um ca. 90 Grad aufgerichtet. Der Lagesensor geht von 90° in die Nähe von 0°.
Cool, dann bin ich mal gespannt.
Gruss Reto
-
Hallo zusammen,
Wie besprochen, habe ich Mathias' Sketch mal in git importiert:
https://git.boxtec.ch/boxtec/witty
Grüsse - Christoph
-
Hallo Christoph
Mal ein Frage zu Git. Je nach Browser sieht das anders aus.
Beim Safari kommen gewissen Teile in einer Fremdsprache (siehe Anhang).
Bei Google Chrome habe ich dasselbe Ergebnis, nur fragt der Browser jetzt ob er Bulgarisch zu Englisch übersetzen soll. Die Übersetzung ist dann korrekt.
Nur bei Firefox wird ungefragt die englische Version angezeigt.
Das ist eigentlich kein Problem für mich, ich frage nur aus Neugierde.
Gruss
René
-
Hallo Rene,
Danke für das Feedback. Ich selber hab den Effekt noch nie gesehen, habe aber auch nur einen Firefox zur Verfügung. Ich habe aber im gitea Issue Tracker zwei Meldungen gefunden die einerseits das Problem beschreiben, aber andererseits geschlossen wurden weil das Problem nicht reproduziert werden konnte.
Wenn Du ganz unten in der Seite auf englisch setzt, bleibt das dann gesetzt (auch über Browser-Neustarts hinweg) ?
(https://forum.boxtec.ch/index.php?action=dlattach;topic=3771.0;attach=1198;image)
Grüsse - Christoph
-
Hallo Zusammen
Unser Coding funktioniert. Ich habe nur noch ein paar Parameter angepasst und schon balanciert der Witty. :)
Natürlich balanciert er noch nicht so ruhig aber immerhin funktioniert es prinzipiell. Hier ein kurzes Video:
https://youtu.be/oOQ5vPMR7Ec (https://youtu.be/oOQ5vPMR7Ec)
Das Coding findet Ihr hier: https://git.boxtec.ch/boxtec/witty/src/branch/Reto
Zum Vorgehen. An die Werte der Parameter kp, ki, kd muss mann sich annähern.
Zudem habe bei den Test's festgestellt, dass der Spannungsunterschied zwischen
USB und Lipo recht gross ist. Daher habe ich in das Kabel vom FTDI Chip noch
ein 3.3 Volt Spannungsregler eingebaut.
Danach habe ich noch eine Routine eingebaut um über die Serielle Schnittstelle
diese Parameter verändern zu können. Wenn zum Beispiel kp=4.280 eingegeben wird
setzt er kp auf 4.280. Damit kann man sehr schnell die Parameter testen.
Natürlich hat das Kabel einen kleinen Einfluss auf das Balancieren. Daher habe ich
versucht ein sehr dünnes flexibles Kabel zusammenzubauen. Unten ein Bild.
Der Wechsel auf den Lipo war dann schon noch mit kleinen Parameter Korrekturen verbunden
aber der Unterschied ist viel kleiner.
Viel Spass
Gruss Reto
-
Hallo zusammen
Ich habe die Diode überbrückt damit der Akku etwas mehr Spannnung liefert. Der Code ist von Reto, Angle_to_balance auf 0 gesetzt, damit Witty aufrecht stehen kann. Das funktioniert noch nicht so richtig, er braust nach kurzer Zeit in eine Richtung los.
Das Video:
https://youtu.be/WC2ZVXS3w2Q
Gruss
René
-
Hallo René
So schlecht sieht es aber nicht aus. Die Parameter etwas einstellen und dann funktioniert es ;-)
Ja ich habe noch etwas vergessen zu erwähnen. Die Motoren arbeiten Vor- und Rückwärts nicht gleich.
Das kannst Du mit diesen Parametern RMotor_offset_bck, LMotor_offset_bck usw. ausgleichen.
Bei war Rückwärts schwächer bei Dir scheint jetzt Rückwärts noch schwächer zu sein. Denn er fährt immer mehr Vorwärts.
Ich würde mal mit den beiden *bck Variablen spielen. Evlt. noch höher als bei mir einstellen oder auf 0 und vergleichen
ob Dein Problem sich verändert.
Hier übrigens die Anleitung für das Balancieren selber, das scheint bei Dir aber nicht schlecht zu sein:
// Tuning:
// 1. Set Ki and Kd to zero and gradually increase Kp so that the robot starts to oscillate about the zero position.
//
// 2. Increase Ki so that the response of the robot is faster when it is out of balance. Ki should be large enough so that the angle of inclination does not increase. The robot should come back to zero position if it is inclined.
//
// 3. Increase Kd so as to reduce the oscillations. The overshoots should also be reduced by now.
Viel Erfolg.
Gruss Reto
-
Hallo Reto,
Gratuliere, hab Deinen Code auf zwei Wittys ausprobiert, der früheste Prototyp hat zeitweise recht beeindruckend balanciert und sich sogar nach Anstubsen wieder in Balance kriegen können. Beim neueren sehe ich ähnliche Effekte wie Rene. Aber insgesamtn sicher nur eine Frage des Feintunings, die Funktion ist da!
Grüsse - Christoph
-
Hallo Reto
Bei war Rückwärts schwächer bei Dir scheint jetzt Rückwärts noch schwächer zu sein. Denn er fährt immer mehr Vorwärts.
Ich würde mal mit den beiden *bck Variablen spielen. Evlt. noch höher als bei mir einstellen oder auf 0 und vergleichen
ob Dein Problem sich verändert.
Leider gibt das keine Veränderung. Das Verhalten scheint ausschliesslich vom Schwerpunkt bestimmt zu werden.
Eigentlich möchte ich auch nicht einfach nur stehen bleiben. Das Ziel wäre, in jede beliebige Richtung fahren zu können und auch Kurven sollten möglich sein.
Zum Glück bleibt noch etwas Zeit bis zum nächsten Treffen.
Gruss
René
-
Hallo René
Ich denke die Motoren von Dir brauchen weniger Strom als andere und daher sind sie im Moment zu stark angesteuert.
Ja klar das Ziel ist dann fahren und steuern aber zuerst musst er ruhig und kontrolliert stehen können.
Ansonsten ist dann auch eine Fahrt nicht unter Kontrolle.
Dann würde ich mal so beginnen. Alle Motor offset Variablen, kd und ki auf 0 setzen.
Das kp auch relativ tief ansetzen und so Vorgehen:
// Tuning:
// 1. Set Ki and Kd to zero and gradually increase Kp so that the robot starts to oscillate about the zero position.
//
// 2. Increase Ki so that the response of the robot is faster when it is out of balance. Ki should be large enough so that the angle of inclination does not increase. The robot should come back to zero position if it is inclined.
//
// 3. Increase Kd so as to reduce the oscillations. The overshoots should also be reduced by now.
Wenn du dann in einem Stadium einen Unterschied zwischen Vorwärts und Rückwärts oder Links und Rechts feststellst kannst Du dann mit den Motoren Offets das korrigieren.
Viel Erfolg
Gruss Reto
-
Hallo Reto
Die Offset - Variablen sind auf 0. Bei Änderung von Kp, Ki und Kd wird er unstabiler, bezüglich 'davonlaufen' ändert sich nicht viel. Die verwendeten Parameter sind also gar nicht so schlecht.
Der Schwerpunkt ist auf der Seite des Plastikteils. In diese Richtung fährt er auch.
Wenn ich das Plastikteil entferne, liegt der Schwerpunkt auf der Seite des Akkus. Der Roboter fährt dann in diese Richtung.
Ich habe einen etwas abenteuerlichen Aufbau gemacht, so dass der Schwerpunkt über der Motorachse liegt. Und schon steht der Roboter. Er stabilisiert sich sogar wieder, wenn ich ihn anstosse. Er ist etwas wackelig auf den Rädern, aber das könnte sicher noch genauer eingestellt werden. Es besteht auch eine kleine Differenz zwischen den beiden Motoren.
Das Video: https://youtu.be/gf3MpruhwGg
Damit verhält er sich wie ein bemanntes Fahrzeug (Segway). Dort steuerst du Richtung und Geschwindigkeit auch durch Verlagerung des Schwerpunktes.
Kannst du bei dir auch einen ähnlichen Effekt feststellen?
Gruss
René
-
Hallo Réne
Ah jetzt sehe ich das Problem. Das heisst also du musst den Winkel zum Balancieren auf den Schwepunkt einstellen damit er still stehen kann. Zwar nicht mehr "gerade" aber still. Das heisst dann auch zum vorwärtsfahren müssen wir nur den Winkel verstellen und er fährt vorwärts. Ich habe heute meine Tochter beim Einradfahren beobachtet und das ist genau das gleiche. :)
Ich habe auch mit dem Einrad geübt aber das hat weniger etwas mit balancieren zu tun :o
Gruessli Reto
-
Mit der Veränderung des Winkels funktioniert es mehr oder weniger. Die Parameter müssten vermutlich noch etwas optimiert werden. Momentan habe ich etwas wenig Zeit, werde aber demnächst einmal versuchen etwas herumzufahren.
https://youtu.be/DHGm8FWX3EM
Gruss
René
-
Hallo zusammen
Das nächste Witty - Treffen ist ja in Kürze und ich bin noch kein Stück weiter. Inzwischen habe ich mehr oder weniger alle Teile des Wittys im Griff, mit Ausnahme des Balancierens. Seit ihr da schon weiter gekommen ?
Gruss
René
-
Hallo René
Nein ich hatte Aufgrund von Urlaubsreisen nicht viel Zeit gehabt.
Dafür hatte ich mich etwas im Einrad fahren geübt und daher das Balancieren live erlebt.
Da ich es noch nicht sauber hinkriege gibt es auch kein Video - besser so :o
Ich habe schon überlegt ob ich einen Gyro Sensor anziehen sollte und dann die Daten auswerten soll um zu sehen was ich falsch mache aber es ist bei der Überlegung geblieben. :)
Grüessli Reto