fischertechnik community forum

Ich versuche immer mal wieder, auf ftDuino-Basis einen robust balancierenden Roboter ("Segway") hinzubekommen. Zu meiner Schande muss ich gestehen, dass ich es mehr schlecht als recht hinbekomme. Manchmal balanciert es einige Sekunden, aber nie wirklich über längere Zeit stabil. Stabil heisst, dass er auf glatten Oberflächen ruhig an einer Position stehen bleibt und auf leichte Schubser mit minimalen Ausgleichbewegungen reagiert.

Also rufe ich hiermit einen Wettbewerb aus. Der Roboter soll bis auf den ftDuino und ggf. einen Beschleunigungssensor nur aus aktuellen Original-ft-Teilen bestehen. Wäre natürlich noch cooler, wenn der ft-Kombisensor zum Einsatz käme. Aber das ist keine Bedingung.

Was habt ihr davon? Der erste hier im Thread bis spätestens Ende August '20 veröffentlichte nachbaubare Roboter (Code Open-Source und Mechanik z.B. auf Foto gut genug erkennbar) gewinnt je nach Wahl entweder einen ftDuino (ok, den hat der entsprechende User wahrscheinlich schon) oder einen der frischen ft-HATs für den Raspberry-Pi.

Hallo MasterOfGizmo,

MasterOfGizmo hat geschrieben:Stabil heisst, dass er auf glatten Oberflächen ruhig an einer Position stehen bleibt und auf leichte Schubser mit minimalen Ausgleichbewegungen reagiert.

Das geht auch rein elektromechanisch
Der Schwerpunkt des gesamten Gerätes muss lediglich unterhalb der Achslinie der Raddrehpunkte liegen.

Ansonsten viel Vergnügen mit strukturinstabilen Regelkreisen und Matlab.

Grüße
H.A.R.R.Y.

Hallo Till,

es gibt ja einige gut dokumentierte Arduino-Projekte. Daher wäre vielleicht zu präzisieren: Darf der Code adaptiert sein oder soll es im Wesentlichen eine Eigenentwicklung sein? Und muss die Lösung auf der ftDuino-Library basieren?

lg
Jan

Es dürfen beliebige quelloffene Codes adaptiert werden und ob auf den ftDuino die Original-ftDuino-Bibliothek genutzt wird oder nicht ist mir auch egal. Allerdings wird man ja irgendwie die Motoren ansteuern wollen und da bietet sich die ftDuino-Bibliothek ja an.

Ja, das ist richtig. Ich dachte nur spontan daran, dass das (hier überflüssige) polling der Analogeingänge bei einer zeitkritischen Anwendung wie hier Probleme machen könnte, ohne allerdings zu wissen, wie viele Ressourcen das polling wirklich schluckt und ob Du es in der Lib deaktivierbar gemacht hast.

Ein zweiter Punkt war noch, dass manche Lösungen z.B. beim MPU6050 den Interrupt verwenden, den man wahrscheinlich an C1 oder C2 betreiben könnte, aber eben nur, wenn man ihn von Hand anspricht. Wobei ich auch hier nicht weiß, ob und wie das u.U. damit in Konflikt gerät, dass die Lib sie eben als Zählereingänge konfiguriert.

lg
Jan

Hallo Till,

cool - ich bin dabei.

Herzlicher Gruß,
Dirk

Hallo...
Ich habe noch einen fertig aufgebauten Roboter hier stehen. Der muss "nur" noch programmiert werden.
Ich hatte den auf der Modellschau in Münster mit.
Der hat zwar einen Uno drauf, aber dass kann man ja ändern. Einzig "gosse" nicht ft-Räder sind da das Problem.

Ich habe mich schon länger damit beschäftigt und kann sagen das die Abfragen und die ganze Steuerung gar nicht sooo Zeitkritisch sind.
Leider sind die Abfragen die ich nutzen wollte so 10ms. Der Plan war erst das mit RoboPro zu machen. Das liegt aber genau an der Abfragegrenze...
Wenn man sich die Werbevideos oder Youtube-Projekte anschaut "sieht" man manchmal die Regelung, wenn der so hin und her geht.

Zumindest kann man das für ft 1:1 übernehmen. Es gibt ja auch noch Fernsteuerung über Handy...
Man lernt eine Menge über Regelung, wenn man will - oder bentzt einfach die vorgegebenen Sachen und ändert nur die Einstellungen.
Da gibt es eine Menge an (meist englischer) Dokus drüber.

Mit freundlichen Grüßen
fishfriend
Holger Howey

Hallo,
https://s33836ab9cdaf391a.jimcontent.co ... ressed.pdf
ab Seite 45 ist auch ein bischen Fischertechnik zu sehen.

Hier ein wenig Motivation.

Die Kollegen aus Billund haben sowas standardmäßig im Programm:

Video Balance-Roboter mit Lego EV3

Video Balance-Roboter mit Lego Spike

Für die ftDuino-Lösung hat Jan ja hier ein nettes Sensorgehäuse für den MPU6050-Sensor entworfen:

Gehäuse für MPU6050 Lage-Sensor

Tatsächlich war der Sensor der erste I²C-Sensor, den ich überhaupt je an einem ftDuino getestet habe. Daher findet er sich auch ganz vorne im I²C-Kapitel des Handbuchs:

Kapitel 6.13: Nutzung des I²C-Bus

Na sowas. Es hat keine fischertechnik-Lösung gegeben. Da bleibt der Preis in der Familie. Der Rest der Familie hat es zwar nicht ganz nach Vorgabe gelöst und statt des ftDuinos den Lego-Spike-Controller genommen. Aber das lasse ich mal durchgehen. Ein Bild des Sieger-Modells kann ich gerne nachreichen, wenn es Interesse gibt.

Der Spike ist ganz originell. Er basiert komplett auf Micropython und wird in Form des "LEGO Mindstorms 51515 Robot Inventor"-Sets wohl bald auch den EV3 beerben. Das ist insofern interessant, als Lego damit aus dem "schneller, breiter, höher"-Rennen aussteigt. Damit erhöht sich rein technisch der Abstand zwischen TXT und dem jeweils aktuellen Lego-Produkt deutlich. Vom didaktischen Standpunkt ist es interessant zu sehen, dass Lego dem "Blöckchen-Programmieren" nun gleichberechtigt eine textuelle Programmierung zur Seite stellt. Ja, das ging auch alles immer mit dem EV3 und dem TXT, aber eben nie ab Werk und immer mit relativ großen Hürden für Einsteiger. Ob es Spass macht, am Android-Tablett Python-Programme zu schreiben ist natürlich eine andere Frage. Aber wie man sieht implementiert man da auch recht einfach einen PID-Regler und lässt mal einen Roboter balancieren. Da Lego viel Intelligenz in die Sensoren auslagert muss man dann in Python nicht mehr viel machen, wenn man stabile Werte aus dem Beschleunigungssensor oder Farbwerte vom Farbsensor. Dabei können alle aktuellen Lego-Sensoren, die ich bisher in der Hand hatte immer deutlich mehr als Lego bisher nutzt. Interessant ist auch, dass der Spike entgegen allen anderen aktuellen Lego-Controllern klassisches Bluetooth statt BLE nutzt. Das könnte der Tatsache gesschuldet sein, dass BLE unter Windows problemtisch ist. Es scheint dennoch eine IOS-App für den Spike zu geben. Da muss Lego eine Lösung für das von Dirk erwähnte HC-05-Problem (klassisches Bluetooth geht mit IOS nicht, viewtopic.php?f=33&t=6220&hilit=hc05#p46229) gefunden zu haben.

Aber immerhin könnte sich fischertechnik nun ganz klar auf der "dicke CPU mit echtem Linux"-Seite platzieren und sich deutlich von Lego distanzieren. Wird interessant zu sehen sein, was als nächstes aus dem Waldachtal kommt und wie gut sich der deutlich einfachere Spike in den diversen Robotics-Wettbewerben schlägt. Wann man mal live dabei war und verzweifelte Kinder an abgestürzten und langsam wieder bootenden TXTs und vor allem EV3s zugesehen hat, dann scheint Einfachheit hier durchaus ein valider Pluspunkt zu sein. So einen Spike schaltet man einfach ein und dann läuft der sofort los.

MasterOfGizmo hat geschrieben: ↑

07 Sep 2020, 14:49

Ein Bild des Sieger-Modells kann ich gerne nachreichen, wenn es Interesse gibt.

Ja, mach doch mal. Mich interessieren v.a. die verwendeten Motoren und die Größenverhältnisse. Bei mir ist der schnelle Erfolg am Spiel der U-Getriebe gescheitert, das die Reaktion zu träge machte. Ich hatte da zwar noch Ideen, um das Spiel softwareseitig zu kompensieren, aber wg. Sommer, Corona und Konkurrenzprojekten lag das bei mir erst mal auf Eis.

Und warum habt Ihr ausgerechnet im Hause MoG keinen ftDuino verwendet?

vg
Jan

juh hat geschrieben: ↑

07 Sep 2020, 16:31

Ja, mach doch mal. Mich interessieren v.a. die verwendeten Motoren und die Größenverhältnisse. Bei mir ist der schnelle Erfolg am Spiel der U-Getriebe gescheitert, das die Reaktion zu träge machte.
...
Und warum habt Ihr ausgerechnet im Hause MoG keinen ftDuino verwendet?

Hier ist das gute Stück. Ggf. mache ich auch ein kurzes Video davon in Aktion.
Bei meinen Experimenten habe ich auch oft das Getriebespiel usw. als Schuldigen ausgemacht. Aber die Legomotoren hier haben gefühlt locker 3-4 Grad Getriebespiel. M.E. deutlich mehr als die üblichen ft-Motoren. Die Motoren stecken auch nur halbwegs lose am Spike und habe auch da sicher nochmal ein Grad Spiel. Meines Erachtens ist die Auswertung des Beschleunigungssensors einer der Knackpunkte. Da punktet der im Spike verbaute dadurch, dass er u.a. direkt einen Winkel liefern kann und sie dafür wohl Accelerometer und Gyros zusammenführen. Der balanciert dann recht "ruhig", was dazu führt, dass auch die Ausgleichsbewegungen eher gemütlich sind und irgendwelches Spiel anscheinend wenig Einfluss hat. Aber wie gesagt war ich mit meinen eigenen Resultaten nie so recht zufrieden, weshalb ich auch nicht genau sagen kann, was genau den hier nun so zuverlässig macht.

Und warum der Spike? Wir sind ein recht Baukasten-agnostischer Haushalt und es gibt hier eigentlich alle ft- und alle Legocontroller sowie diverses Third-Party-Zeug. Da greifen sich die Kids dann, was gerade im Weg liegt. Der ftDuino hat ja auch einen (unveröffentlichten) BrickDuino-Bruder, der an das Billund-System passt.