fischertechnik community forum

Hallo zusammen,

herzlichen Dank für die rege Diskussion und eure Beiträge. Mir hat die Sache keine Ruhe gelassen und daher habe ich einen Testaufbau gemacht und informiere über meine Ergebnisse.

Modell Plotter; Stromversorgung Arduino Uno über USB vom PC; Stromversorgung Motor Shield über Labornetzteil; Brücke am Motor Shield NICHT gesteckt (Versorgung entkoppelt).

Testprogramm auf Basis Plotbereich von Dirk; MotorY auf Release; Nur MotorX verwendet; Nach drücken des Starttasters fährt der Schlitten bis zum StopX Taster, wartet 2,5 s und fährt dann in die andere Richtung bis Starttaster gedrückt.
Wenn Schlitten gegen StopX fährt, dann MotorX auf Release (zum Test das Release auch mal auskommentiert).

2 Varianten: MotorX->step(1, BACKWARD, DOUBLE); und MotorX->step(1, BACKWARD, SINGLE);

Hier die Ergebnisse:
DOUBLE:
9,0V - ~0,85A
7,5V - ~ 0,60A
6,0V - ~ 0,40A
5,0V - ~ 0,25A

Die Werte gelten dann, wenn der sich der Schlitten frei bewegen kann. Mit MotorX->release(); nach betätigen des StopX Tasters geht der Strombedarf auf 0A. Macht man kein MotorX->release(); steigt der Strombedarf auf 2,2A bei einer Nennspannung von 5V. Bei höheren Spannungen greift die Strombegrenzung meines Labornetzteils von 3,3A.

SINGLE:
9,0V - ~0,55A
7,5V - ~ 0,42A
6,0V - ~ 0,29A
5,0V - ~ 0,16A

Die Werte gelten dann, wenn der sich der Schlitten frei bewegen kann. Mit MotorX->release(); nach betätigen des StopX Tasters geht der Strombedarf auf 0A. Macht man kein MotorX->release(); steigt der Strombedarf auf 1,2A bei einer Nennspannung von 5V

FAZIT:
Dirk hat mit seinem Vorschlag, die Spannung herabzusetzen, auf jeden Fall recht. Mein 5A Netzteil kann ich auf minimal 6V einstellen. Alternativ könnte ich eines meiner Raspberry Pi Netzteile nehmen.
Die Geräuschentwicklung bei 5V ist wesentlich leiser als bei 9V.
Änderung im Plotprogramm von DOUBLE auf SINGLE. Bei SINGLE wird nur eine Wicklung genommen und die Haltekraft halbiert. Das spart ordentlich Strom. Das setze ich als Nächstes um.
Um zusätzliche Abkühlphasen umzusetzen, könnte man an geeigneten Stellen die Motoren "releasen" und mit delay etwas warten.

Beste Grüße
Klaus

Ergänzung:

Ich habe noch den Einfluss des Wertes für Speed getestet.

Bei 5V am Motor Shield und mit Parameter SINGLE gibt es folgende Ergebnisse:

Speed 800: 0,16A
Speed 600: 0,22A
Speed 400: 0,28A
Speed 200: 0,50A

Je schneller, desto weniger Stromverbrauch...

Beste Grüße
Klaus

Bastelklausi hat geschrieben: ↑

22 Feb 2021, 17:45

Je schneller, desto weniger Stromverbrauch...

Da der Widerstand der Spulen mit steigender Frequenz steigt ist das wie erwähnt zu erwarten. Wenn Du nun noch Microstepping machst, also die Spulen mit einem PWM-Signal ansteuerst, dann sinkt der Stromverbrauch weiter und schließlich unter den Wert, den Du haben willst. Und um dann noch volle Leistung zu erhalten musst Du die Spannung erhöhen. Daher liegt z.B. die Spannung des 3D-Drucker-Netzteils weit über der Nennspannung des Motors.

Ach, Klaus, Du bist einfach klasse...
Geniale Analyse. Freut mich, dass die Spannungsreduktion hilft - dazu kommen Deine wertvollen Tipps.
Werde ich gleich auf der Webseite ergänzen, damit hoffentlich niemand seine Schrittmotoren oder das Motor Shield grillt...

Herzliche Grüße,
Dirk

Hallo,

wollte mich mal für das Buch bedanken. Habe es endlich mal geschafft den Buggy aufzubauen. Toll. Gefällt mir sehr gut. Hab auch die pixy2 schon drann. Funktioniert gut.

Für das "Dritte Rad" hab ich folgendes genommen:

https://www.thingiverse.com/thing:3849443

Da läuft der Buggy wie geschmiert auch mit dem dicken Akku-Pack.

Thx Kräml

Hallo,
Einige Wochen später, komme ich nochmal auf den Delta Roboter mit RoboPro programmiert zurück. Das sieht noch nicht zufriedenstellend für mich aus. Im arduino code "Delta_zu_xyz.ino", Unterprogram "gehe_zu" arbeiten die 3 Motoren praktisch unabhängig, d.h. wenn bei einem Motor die Differenz zwischen aktuellem Winkel und gewünschtem Winkel kleiner als die eingestellte Toleranz ist, bleibt der jeweilige Motor stehen, auch wenn die Anderen noch weiterlaufen. Der gemessene Widerstand, verschiebt sich aber z.T. nachträglich noch um bis zu 10% (40 Einheiten von 400). Ein bischen tuning der Verstärkungs- und minimum PWM Werten brachte eine kleine Verbesserung aber keinen Durchbrauch. Wenn das Programm die Motoren erst stopped, wenn alle Werte innerhalb der Toleranz liegen, kommt es zu z.T. unendlichen Schwingungen. Bemerkung: Das kann man sehr schön mit dem Oszilloskop beobachten.
Frage: ist das ein Problem von ROboPro (10 ms Schleifendauer) oder auch bei Arduino zu beobachten?
Danke Joachim

Hallo Joachim,

ich kann dir nur sagen, dass der Erfolg beim Delta von sehr vielen Parametern abhängt. ich habe ewig gebraucht, damit es mit der Kombination AdafruitMotorShield + S-Motoren sicher funktioniert. Eine Umsetzung auf ftdunio ist mir nicht gelungen. Das Auslaufverhalten der Motoren war ganz anders. Auch die nette Bremsfunktion des ftduino brachte keine Hilfe. Wer es also anders als im Buch beschrieben zum Laufen bringen möchte, muss einiges an Zeit und Experimentierlust mitbringen.

Viele Grüße

Thomas

Hallo zusammen,
beim Bau des Buggys mit einer traditionellen Fernsteuerung bin ich auf ein Problem gestoßen, dessen Lösung ich gerne teilen würde.

Die vorgeschlagene Bibliothek IRremote ist inzwischen bei Version 3.03 angekommen und hat sich etwas geändert. Daher funktioniert der Code auf Seite 68 bis 73 des Buches nicht mehr so, wie er dort steht.

Zur Abfrage der Codierung der IR-Signal sieht der Code jetzt z.B. so aus: und entsprechend im Steuerprogramm: Vielleicht habe ich ja auch was übersehen, aber so funktioniert das Programm bei mir (bzw. bei meinem Buggy).

Gruß
Esther

Hallo Esther,

vielen Dank für den Hinweis! Werde ich gerne (mit Quellenangabe) auf die Buch-Webseite nehmen...
Das ist immer ein "Risiko", dass sich Schnittstellen von Bibliotheken ändern. Macht man ja eigentlich auch nicht.

Herzliche Grüße,
Dirk

- erledigt -

Delta Roboter mit RoboPro.
Nach über einem Jahr habe ich in de4 Weihnachtspause einen zweiten Anlauf genommen den Delta Roboter mit Robopro zu programmieren. Diesmal habe ich den Sketch Delta_Ansteuerung umgesetzt, da @geometer darauf hinwies, dass es nicht einfach ist, beim delta_xyz sketch alles richtig zu justieren.
Ich möchte ein paar Erfahrung mit meinem bisher größten Robopro Programm (1.3MB) teilen.
Zuerst habe ich aber noch eine Frage bezüglich der Lage der z-Ebene. Beim Einmessen liegt das Handgelenk ja bei etwa 15mm+5.5mm+7.5mm = 28mm. Ich habe noch nicht verstanden wie das in den Gleichungen berücksichtigt wird. Ich glaube im Buch ist zudem ein kleiner Fehler. Die Schulterhöhe ‚h‘ wird mit 215.5mm angegeben, befindet sich m.M. nach auf 217.5mm.
Fürs Einmessen gibt es natürlich auch ein Robopro Programm, das die Werte in .csv Listen abspeichert.

Mit RoboPro kann man den Datenfluss Messen der Spannungen => Berechnung der Winkel => Lage des Ellenbogengelenks bis zu den x,y,z Koordinaten übersichtlich mit Unterprogrammen von „links nach rechts“ kodieren. Deshalb habe ich im Gegensatz zum sketch fast völlig auf globale Variable verzichtet. Die Interpolation der Winkel aus den Messtabellen ist auch recht übersichtlich. Bei den komplexen Berechnungen, z.B. winkel_hand, sind textbasierte Sprachen allerdings signifikant bequemer.
Alle Berechnungen habe ich mit Gleitkommazahlen durchgeführt, da auch die Umwandlung Ganzzahl <=> Gleitkomma Rechenzeit benötigt, aber mehr noch weil das System auch nicht sehr numerisch stabil ist. (es werden an einigen Stellen zwei ähnlich große Zahlen voneinander abgezogen.) Aus mechanischer Sicht heißt es, kleine Winkeländerungen bewirken wegen der langen Hebel recht große Auslenkungen.
Natürlich ist so ein großes Programm nicht auf Anhieb korrekt. Bei der Fehlersuche war die Anzeige der Variablenwerte sehr hilfreich. Dazu habe ich den Debugmodus mit Einzelschritten genutzt. Nachdem die Widerstandswerte (eigentlich sind es Spannungen) ermittelt und dann im Einzelschritt festgehalten werden kann man die Ausgaben jedes Unterprogramm von Hand nachgerechnen. Damit ließen sich die Fehler eingrenzen. Lief das Programm aber im online (oder offline) Modus durch, zitterte die Hand stark. Das tolle, eingebaute Oszilloskop zeigte das Problem. Liefen die drei Motoren, erzeugten diese etwa 100mV Spannungsschwankungen auf der Versorgungsspannung von 8.4V. Der TXT wurde mit dem fischertechnik Steckernetzteil betrieben. 33uF Entkopplungskapazität haben Abhilfe geschaffen. Wenn also präzise Analogmessungen gebraucht werden und gleichzeitig Motoren laufen sollen, reichen die im TXT eingebauten Kondensatoren nicht aus.

Kurzfazit – Es ist sicher mit Robopro mühsamer als mit C oder Python solch stark arithmetik lastige Programme zu schreiben, aber es geht wenn man Spaß am Tüfteln hat. Zudem kann man den Ablauf gut verfolgen oder mit dem Oszilloskop das Einschwingverhalten beobachten.

jona2004 hat geschrieben: ↑

30 Jan 2022, 12:05

Delta Roboter mit RoboPro.

…

Kurzfazit

Das schreit ja förmlich nach einer ausführlichen Beschreibung. Möchtest Du das Projekt nicht teilen? Die ftpedia wäre da bestimmt eine gute Adresse für, oder?

Grüßle
Der Kali

Hallo jona2004,

freut mich natürlich sehr, dass Du den Delta-Roboter mit RoboPro und TXT zum Laufen bringst!

jona2004 hat geschrieben: ↑

30 Jan 2022, 12:05

Delta Roboter mit RoboPro.
Zuerst habe ich aber noch eine Frage bezüglich der Lage der z-Ebene. Beim Einmessen liegt das Handgelenk ja bei etwa 15mm+5.5mm+7.5mm = 28mm. Ich habe noch nicht verstanden wie das in den Gleichungen berücksichtigt wird. Ich glaube im Buch ist zudem ein kleiner Fehler. Die Schulterhöhe ‚h‘ wird mit 215.5mm angegeben, befindet sich m.M. nach auf 217.5mm.

217,5 mm ist korrekt. Wir posten den Fehler bei nächster Gelegenheit auf der Internetseite. Das bedeutet, dass die Hand immer 2 mm höher platziert wird, als man im Programm angibt. Die Höhe, die man angibt, ist der Mittelpunkt der Bohrungen der Gelenkwürfelklauen+Lagerhülse an der Hand über dem Boden. Ich hatte immer ein „Tool” (Magnet, Saugnapf, Achse) unter der Hand. Daher habe ich die z-Koordinate immer indirekt bestimmt oder mit dem Maus-Sketch ausgemessen. Bei der Rechnung machen die 2 mm Höhenunterschied wenig aus, solange sie konsistent in Hin- und Rückrichtung falsch gemacht werden. Daher ist mir dieser Fehler durchgeschlupft.

jona2004 hat geschrieben: ↑

30 Jan 2022, 12:05

... Lief das Programm aber im online (oder offline) Modus durch, zitterte die Hand stark. Das tolle, eingebaute Oszilloskop zeigte das Problem. Liefen die drei Motoren, erzeugten diese etwa 100mV Spannungsschwankungen auf der Versorgungsspannung von 8.4V. Der TXT wurde mit dem fischertechnik Steckernetzteil betrieben. 33uF Entkopplungskapazität haben Abhilfe geschaffen. Wenn also präzise Analogmessungen gebraucht werden und gleichzeitig Motoren laufen sollen, reichen die im TXT eingebauten Kondensatoren nicht aus.

Ah, spannend!

Dirk und ich wünschen Dir auf jeden Fall noch viel Erfolg und Freude mit dem Delta.

Viele Grüße

Thomas

Hallo Fischertechniker,
unter dem Weihnachtsbaum lag auf eigenen Wunsch das Buch "Fischertechnik Roboter mit Arduino".
Angefangen habe ich mit dem Delta Roboter und habe ihn zunächst 1:1 nach dem Buch aufgebaut.
Als Controller habe ich den ftduino vorgesehen.
Das Tic Tac Toe mit Nunchucksteuerung habe ich zum Laufen bekommen aber die Positionier- und Wiederholungenauigkeit durch die Potis und das Getriebespiel war ziemlich groß. Beim Solitär habe ich dann aufgegeben und mir überlegt den Antrieb auf Schrittmotoren umzubauen. Um die Bewegungsmechanik spielfreier zu gestalten, habe ich die Unterarme durch Kohlefaserrohre ersetzt und mit Kugelköpfen aus dem Modellbau versehen.
So verändert war auch Solitär kein Problem mehr und auch die anderen Programme für die direkte und inverse Kinematik ließen sich einwandfrei umsetzen.
Bei der Mathematik habe ich an manchen Stellen passen müssen und die Berechnungen als gegeben hingenommen.
Noch sind viele Kapitel aus dem Buch ungelesen und ich bin mir sicher das es mich noch lange beschäftigen wird .

Hallo Claus,

die Steuerung des Delta-Roboters ist auf das Adafruit-MotorShield V2 ausgelegt. Es hat viel Zeit gekostet, mit diesem Shield ein stabiles und schnelles Verhalten hinzubekommen.

Der ftduino kam auf den Markt, als das Buch schon fast fertig war. Da er uns so gut gefiel, haben wir damals auch darüber nachgedacht, für jedes Modell noch eine ftduino-Variante vorzustellen.

Ich habe damals selbst probiert, den Delta mit dem ftduino anzusteuern. Die ftduino-Motortreiber verhalten sich aber ganz anders als das Adafruit-MotorShield. Wenn ich mich recht erinnere besonders die Kurzschlussbremse, die für das Abstoppen der schnellen Bewegungen wichtig ist.

Beim Delta lief eine Steuerung mit dem ftduino nicht direkt. Ich habe genau die Ungenauigkeiten beobachtet wie Du.

Mit viel Zeiteinsatz (vermutlich ein/zwei Wochen) hätte ich vielleicht eine ftduino-Ansteuerung noch hinbekommen, vielleicht aber auch nicht. Ich habe mich damals aus Zeitmangel dagegen entschieden.

Das soll aber keinesfalls gegen den ftduino sprechen. Den finde ich prima und die Verkabelung ist natürlich mit den Buchsen für die ft-Stecker sehr praktisch.

Viele Grüße

Thomas

Hallo Thomas,
Danke für die Erläuterung. Trotz oder gerade wegen der anfänglichen Schwierigkeiten habe ich viel über den ftduino (Arduino) und seine Programmierung gelernt. Eure Codes waren gute Grundlage für die Schrittmotorsteuerung, besonders die Berechnungen hätte ich alleine wohl nicht hinbekommen.
Ich habe übrigens die Schrittmotoren über den ftpwrdrive angesteuert. Damit wird Solitär in 61 Sek. abgeräumt. Da geht es schon ordentlich zur Sache.
Leider kann ich kein Bild anhängen. Keine Ahnung warum.

Mach doch mal ein Video und stell es bei youtube ein.
Würde mich interessieren wie du unseren ftPwrDrive so einsetzt.

schröttel hat geschrieben: ↑

13 Feb 2025, 23:08

Leider kann ich kein Bild anhängen. Keine Ahnung warum.

Erst unten auf "Dateianhänge" klicken, Datei auswählen und hochladen. Danach dauert es zumindest bei meinem alten Browser eine kurze Zeit, bis die Schaltfläche "Datei im Beitrag anzeigen" erscheint. Die muss man dann noch einmal anklicken.

Ich konnte das Bild nicht hochladen weil es einfach zu groß war. Das könnte das Programm auch ruhig melden.

Mir ist jetzt schon öfter die Hand in das Gestell oder gegen den Boden gefahren. Ich habe zwar einen Notaustaster installiert, aber der Ftpwrdrive schaltet nur die Motoren aus aber die Spulen bleiben unter Strom wenn man das vor dem Motorstart so eingestellt hat. Da hilft nur Stecker ziehen.
Wie könnte man sinnvoll den Arbeitsraum einschränken, damit es nicht mehr zu Kollisionen kommen kann?
Die Z-Achse Richtung Boden könnte man beschränken, indem man eine minimale Höhe definiert die die Z-Koordinate nicht unterschreiten darf.
Auf dieser unteren Ebene müsste ja ein ziemlich flacher Kegel dessen Spitze die Koordinaten (0,0,Z) hat , wobei Z die Höhe bei Anschlag der Oberarme am Rahmen angibt, den Arbeitsraum beschreiben. Aber wie kann man das im Programm abbilden?