Encoder-Motor Problem

Community-Firmware (cfw), Selbstbaucontroller (TX-Pi, ftduino, usw.), usw.
Forumsregeln
Bitte beachte die Forumsregeln!
Antworten
kessenia
Beiträge: 4
Registriert: 02 Jul 2019, 11:57

Encoder-Motor Problem

Beitrag von kessenia » 03 Jul 2019, 13:11

Hallo zusammen,

vorweg, ich bin neu im Forum und habe auch noch nicht so viel Erfahrung mit Fischertechnik.
Und bitte entschuldigt, wenn ich die falsche Topic erwischt habe. Ich habe auch keine ähnlichen Beitrag gefunden.

Wir haben eine größere Fischertechnik Anlage, die man so kaufen kann. Die Steuerung der Anlage ist in mehreren Python Skripten realisiert, die jeweils mithilfe von ftrobopy(https://github.com/ftrobopy/ftrobopy) eine Verbindung zu den entsprechenden Fischertechnik TXTs aufbauen. Die Skripte selber laufen auf einem anderen Rechner. Auf den TXTs ist die community firmware 0.9.5 installiert.
In der Anlage kommen mehrere Encodermotoren zum Einsatz. Mit denen haben wir aber leider ein Problem. Wenn man die Funktionen setDistance und setSpeed verwendet kommt es immer wieder zu dem Problem, dass der Motor kurz vor Ende stehen bleibt. Man kann jedoch hören, dass der Motor noch versucht zu laufen. Wenn man dann nur ein bisschen am Tisch wackelt, geht es weiter. Das passiert leider nicht nur bei einem der Motoren.

Ich habe mal ein kleines Skript geschrieben, das den Fehler relativ schnell hervorruft:

Code: Alles auswählen

import ftrobopy
from time import sleep

txt = ftrobopy.ftrobopy(host='192.168.1.18',port=65000,update_interval=0.01,special_connection='192.168.1.18')

stops = 8
distance = 50
speed = 512
axis = txt.motor(2)

while True:
    for _ in range(stops):
        axis.setDistance(distance)
        axis.setSpeed(-speed)
        while not axis.finished():
            print(axis.getCurrentDistance(), '/', distance)
            sleep(0.1)
        axis.setSpeed(0)
        sleep(0.5)
    for _ in range(stops):
        axis.setDistance(distance)
        axis.setSpeed(speed)
        while not axis.finished():
            print(axis.getCurrentDistance(), '/', distance)
            sleep(0.1)
        axis.setSpeed(0)
        sleep(0.5)
Dazu habe ich noch eine Aufnahme gemacht: https://youtu.be/9ziAME0P45I

Wenn der Kran stehen bleibt kann man in der Ausgabe immer "49 / 50" ablesen.
Habt ihr eine Ahnung was das sein könnte?

Vielen Dank und Gruß
Arne

Benutzeravatar
PHabermehl
Beiträge: 2429
Registriert: 20 Dez 2014, 22:59
Wohnort: Bad Hersfeld

Re: Encoder-Motor Problem

Beitrag von PHabermehl » 03 Jul 2019, 14:25

Hallo,

ich tippe mal auf Überlast in Verbindung mit der internen Positionsregelung von ftrobopy.

ftrobopy bremst vor Erreichen der Zielposition bereits ab. In der Aufwärtsbewegung braucht Euer Arm aber recht viel Kraft, d.h., er bleibt schon kurz vor Erreichen des Ziels stehen. Und da er dann halt schon wirklich kurz vor dem Ziel ist, gibt der Lageregler nicht mehr genug Spannung auf den Motor, um den mechanischen Widerstand zum Wiederanfahren überwinden zu können. Ein kleiner Schubser hilft dann, um die Zielposition zu erreichen, und da dann das nächste Ziel wieder weiter entfernt ist, gibt ftrobopy auch erstmal Volldampf, so dass der Motor problemlos anläuft.

Da ich die Interna von ftrobopy aber nicht kenne, würde ich vorschlagen, Torsten Stuehn, den Autor von ftrobopy, zu kontaktieren.

Gruß
Peter

PS: da es sich hier um die community firmware handelt, habe ich den Thread auch gleich mal in den passenden Forumsbereich verschoben...
https://www.MINTronics.de -- der ftDuino & TX-Pi Shop!

viele Grüße
Peter

kessenia
Beiträge: 4
Registriert: 02 Jul 2019, 11:57

Re: Encoder-Motor Problem

Beitrag von kessenia » 03 Jul 2019, 17:31

Danke für deine Antwort Peter.

Das mit der Überlast hört sich tatsächlich nach einer möglichen Ursache an. Allerdings bleibt der Kran so gut wie nie hängen, wenn ich distance auf einen höheren Wert wie z.b. 200 setze.

Aber ich werde Torsten mal fragen.

kessenia
Beiträge: 4
Registriert: 02 Jul 2019, 11:57

Re: Encoder-Motor Problem

Beitrag von kessenia » 04 Jul 2019, 12:51

Uns ist auch noch aufgefallen, dass der counter manchmal zurückgesetzt wird.

In der Ausgabe sieht man dann sowas:
0 / 486
7 / 486
18 / 486
26 / 486
4 / 486
8 / 486
...

So fährt der Kran manchmal zu weit, wenn er denn nicht hängen bleibt.

Benutzeravatar
fishfriend
Beiträge: 1793
Registriert: 26 Nov 2010, 11:45

Re: Encoder-Motor Problem

Beitrag von fishfriend » 05 Jul 2019, 00:25

Hallo...
Nur so ein paar andere Ansätze:
Ich selbst hab mit dem Programm noch nichts gemacht, aber
wie wird denn gebremmst? Überfährt der den Wert beim runterfahren? Also macht der evtl. mehr Impulse als beim rauffahren?
Habt ihr die Möglichkeit die Impulse zu zählen? Evtl Extern mit einem anderen Gerät (oder TXT) ?

Wie ist denn die Spannungsversorgung? Hat das Netzteil genug "Strom" und "Spannung"?

Ohne mir weiter das Programm angeschaut zu haben, ist da evtl eine Bremsrampe einstellbar?
So ein sanftes abbremsen um den Zähler genau zu treffen und nicht zu überfahren?
Man sieht das die Zahnräder manchmal etwas nachlaufen.

Läuft die Mechanik gut? Also mal per Hand rauf und runtergedreht? (Silikonöl oder ähnliches?)

Gruß
fishfriend
Holger Howey
ft Riesenräder PDF: ftcommunity.de/knowhow/bauanleitungen
TX-Light: Arduino und ftduino mit RoboPro

kessenia
Beiträge: 4
Registriert: 02 Jul 2019, 11:57

Re: Encoder-Motor Problem

Beitrag von kessenia » 09 Jul 2019, 12:51

Hallo Holger,

danke für deine Antwort. Wie genau der TXT das intern macht, weiß ich leider nicht. Und wir haben auch nicht die Möglichkeit (zumindest nicht auf die schnelle) die Impulse extern zu zählen.

Der TXT für den Kran hängt an seinem eigenen Netzteil mit 9V und 2.5A. Ich habe die Spannung mal mit einem Oszilloskop überwacht, aber die fällt höchstens mal kurz auf 8.5V ab, wenn der Motor anläuft.

Und soweit ich weiß kann man auch keine Bremsrampe einstellen.

Bei der Mechanik haben wir auch schon rumprobiert. Wir haben alles mit ein bisschen Schmieröl behandelt und es läuft eigentlich ganz gut.

Benutzeravatar
fishfriend
Beiträge: 1793
Registriert: 26 Nov 2010, 11:45

Re: Encoder-Motor Problem

Beitrag von fishfriend » 09 Jul 2019, 21:14

Hallo...
Mit Bremsen meinte ich eigendlich ob er aktiv gebremst wird.
Es scheint aber ein normales Programm zu sein was den TXT im Onlinemodus betreibt und nur den Datenverkehr macht (wenn ich das richtig verstanden habe).

Was passiert eigendlich wenn du die Laufrichtung im Programm umdrehst? Also erst hoch, dann runter.

Ich vermute das Impulse verloren gehen.
Bei meinen Modellen löse ich das meist so, dass ich einen Nullpukt habe (z.B. Taster) und den ab und zu anfahre.
Man kann auch immer von diesem Punkt aus fahren. Ist halt auch die Frage ob der Arm irgendwo anstoßen kann.

Ich habe mich bisher nicht mit den alternativen TXT Programmen beschäftigt. Hast du die Möglichkeit mal zu testen wie das mit der original ft Sofware sich verhält?

Ist ein bisschen aufwändiger: Man könnte auch einen zweiten TXT nehmen und den nur die Impulse messen lassen.
Ich habe das Gefühl das bei Distance der Motor nur abgeschaltet wird und evtl noch etwas nachläuft ( stop() = Geschwindigkeit auf 0 ). Auch das könnte man messen, oder den Motor mal per hand drehen...

Was man auch machen könnte ist eine eigene Distance Funktion zu schreiben und den Counter "ständig" abfragt. Das "ständig" hat ein Nachteil - die Daten kommen nur alle 10ms zum PC- Der Motor und der Counter laufen aber weiter. Die normale Distance Methode ist aber im TXT - es kann ja sein das da etwas nicht richtig läuft.
Ich muss allerdings zugeben das ich nicht so den TXT kenne, ich mache aber gerade genau das mit einem TX bzw. Arduino.
Gruß
fishfriend
Holger Howey
ft Riesenräder PDF: ftcommunity.de/knowhow/bauanleitungen
TX-Light: Arduino und ftduino mit RoboPro

Benutzeravatar
EstherM
Beiträge: 1466
Registriert: 11 Dez 2011, 21:24

Re: Encoder-Motor Problem

Beitrag von EstherM » 09 Jul 2019, 21:45

Hallo Arne,
eine Idee:
hat das Ding in der Schleife genug Zeit, den Befehl auch auszuführen? Wenn der Motor gestartet ist, läuft das Programm ja weiter.
Ein anderer Vorschlag wäre, erst einmal nur den Motor anzusteuern, ohne die ganze Mechanik dahinter. Läuft er dann länger, wenn Du eine größere Distanz eingibst? Wenn nein, hatte er überhaupt genug Zeit, die Distanz abzufahren?
Gruß
Esther

Torsten
Beiträge: 308
Registriert: 29 Jun 2015, 23:08
Wohnort: Gernsheim (Rhein-Main-Region)

Re: Encoder-Motor Problem

Beitrag von Torsten » 09 Jul 2019, 22:54

Die Beschleunigungs- und Bremssteuerung erfolgt nicht in ftrobopy, sondern auf der Motorplatine des TXT. Über die Linuxplatine könnte man die Regelung gar nicht so exakt hinbekommen, weil Linux kein Echtzeitbetriebssystem ist.

Es gibt in der Firmware der Motorplatine eine Tabelle, in der das Beschleunigungs- und Bremsverhalten in Abhängigkeit von der Geschwindigkeit gesteuert wird. Diese Tabelle ist fix und wurde für eine "mittlere Belastung" der Motoren ermittelt.

Man hat von aussen (also von der Linux-Platine des TXT) keine Möglichkeit, diese Tabelle zu verändern. Man müsste dafür die Firmware der Motorplatine anpassen, z.B. indem man unterschiedliche Tabellen für unterschiedliche Motorlasten zur Verfügung stellt. Der Sourcecode der Motorplatine ist allerdings nicht Open-Source, deshalb haben wir da wenig Chancen.

Man kann sich als Workaround damit behelfen, einen Encodermotor gleichzeitig an zwei schnelle Counter anzuschliessen. Den zusätzlichen Counter verwendet man sozusagen als "Kontrollinstanz". Das ist aber recht umständlich und man "verliert" dadurch natürlich einen der Counter.

Viele Grüße
Torsten

Benutzeravatar
PHabermehl
Beiträge: 2429
Registriert: 20 Dez 2014, 22:59
Wohnort: Bad Hersfeld

Re: Encoder-Motor Problem

Beitrag von PHabermehl » 10 Jul 2019, 16:16

Hallo Torsten,
danke für die Erklärung. Wäre jetzt nochmal interessant herauszufinden, wer die Rechte hat, und ob da nicht doch ein Kompromiss zu finden ist...
Für solche Projekte ist dann schon wieder der ftduino die bessere Lösung - günstiger und open source, da kann man so ein Problem dann halt selbst lösen...

Gruß
Peter
https://www.MINTronics.de -- der ftDuino & TX-Pi Shop!

viele Grüße
Peter

Benutzeravatar
fishfriend
Beiträge: 1793
Registriert: 26 Nov 2010, 11:45

Re: Encoder-Motor Problem

Beitrag von fishfriend » 11 Jul 2019, 14:47

Hallo...
Es gibt da noch andere Möglichkeiten.
Hört sich erst mal seltsam an, aber welche Motoren habt ihr da verbaut? Die alten "TX"- oder die neuen "TXT"- Motoren?
Ich habe - sehr - sehr - große Probleme mit den alten "TX"-Motoren gehabt. (Da muss ich nochmal mit ft reden)
Deswegen die Nachfrage.

Habt ihr die Möglichkeit mal den Motor zutauschen?

Ich kenne die TXT Schaltung für die Motoren nicht. Hat ft einen eigenen Controller dafür vorgesehen? Oder wo steht diese "Tabelle"?
Zum einen kann ich mir gut vorstellen das man da Zugriff drauf bekommen kann, zum anderen muss es da eine Übergabe des Zählers geben.
Gibt es darüber Informationen?
Gruß
fishfriend
Holger Howey
ft Riesenräder PDF: ftcommunity.de/knowhow/bauanleitungen
TX-Light: Arduino und ftduino mit RoboPro

robofreak
Beiträge: 9
Registriert: 17 Dez 2016, 08:37
Wohnort: 69190 Walldorf

Re: Encoder-Motor Problem - gelöst?

Beitrag von robofreak » 31 Okt 2021, 12:13

Hallo zusammen,
ich habe ähnliche Probleme mit der Ansteuerung von Encoder-Motoren unter Python/ftrobopy.
Ich muss vorausschicken, dass ich die TXT noch nicht so lange mit Python programmiere, sondern bisher meistens mit Robopro gearbeitet habe. Meine nachfolgend geschilderte Anlage hatte ich mit Robopro schon problemlos laufen

Mein System:
Ich steuere mit 2 TXT-Controllern einen kleinen Industrie-Roboter und verwende hierbei mehrere Encoder-Motoren. Diese fahren am einen Ende ihres Laufwegs an einen Stop-Schalter und am anderen Ende fahren sie eine programmierte Distanz(bzw. sollten diese fahren!!)
Problematik:

Bei der empfohlenen Ansteuerung mit dem Code:
motor.SetSpeed(speed)
motor.SetDistance(distance)
und der Ende-Abfrage:
while not motor. Finished()
#irgendwas
motor. Stop()

traten folgende seltsame Effekte auf:
Ich muss dazu sagen, dass ich die gleichen Abläufe mehrmals hintereinander ablaufen lasse.
Bei der jeweils ersten Ansteuerung der Encoder-Motoren innerhalb des Scripts lief alles normal.
Nur bei den weiteren Durchläufen, meist beim dritten, gelegentlich auch beim zweiten, fuhr der jew. Encoder-Motor bis an oder kurz vor?? seine programmierte Distance-Endstellung, dann blieb aber das Script stehen, d.h. der Programmablauf wurde einfach nicht fortgesetzt. Das Ganze passierte nicht bei jedem Motor gleich, und nicht bei der gleichen Zahl von Ansteuerungen, war also sehr schwer nachvollziehbar.
Demzufolge habe ich an der Sache wochenlang rumprobiert.
Da ich mir nicht mehr zu helfen wusste, habe ich mir mal bei einem Motor mit motor.getCurrentDistance() die Sache näher angesehen. Dabei stellte ich fest, dass zum Zeitpunkt der Script-Abbrüche, also bei wiederholtem Start des jew. Motors, der Dreh-Wert zum Zeitpunkt des Aufrufs von motor. Finished() nicht den mit SetDistance() eingestellten Wert erreichte, so dass motor. Finished() niemals „TRUE“ und der Programmablauf nicht fortgesetzt wurde.
Daraufhin habe ich durch Rumprobieren folgenden Code entwickelt, der bei dem Motor die Abbrüche beseitigte:
-----------------------------------------------------------
dreh_max = 1000
motor.SetSpeed(speed)
Motor.setDistance(dreh_max)
while True:
aktuelle_strecke = Motor_Turm_Dreh.getCurrentDistance()
if aktuelle_strecke >= dreh_max:[/img]
Motor_Turm_Dreh.stop()
break

Ich verzichte also komplett auf die Abfrage von motor.Finished() und frage stattdessen die aktuelle Wegstrecke ab. Diese vergleiche ich dann mit dem eingestellten Distance-Wert und setze das Script erst fort, wenn dieser Wert erreicht ist, und siehe da:
Der aktuelle Encoder-Motoren funktionierte erwartungsgemäß und beliebig oft wiederholbar.

Allerdings machte ich den Denkfehler, dass das Abbruch-Phänomen nur den von mir zuerst umprogrammierten Motor betreffen würde und kämpfte dann noch einige Zeit weiter mit den Abbrüchen, bis ich endlich darauf kam, dass ich alle Motoren mit dem og. Code ansteuerte.
Seit gestern nun läuft meine ganze Anlage problemlos in "endloser" Wiederholung.
Vielleicht haben einige ähnliche Probleme und ich konnte ihnen den Stress und das ganze Rumrätseln ersparen.

Gruß an Alle.

Antworten