ftrobopy: Encoder-Motoren synchronisieren

[PHabermehl]

Hallo,
kann man mit ftrobopy zwei Encodermotoren ohne Angabe einer "Distanz" dauerhaft synchron laufen lassen?
Ich möchte einen Fahrroboter so lange geradeaus fahren lassen, bis ich die Motoren aufgrund eines Ereignisses, z.B. Ultraschall-Distanz unterschritten, wieder stoppe.

Also -> Motoren synchron ein -> Ultraschall-Distanzsensor-Auswerteschleife -> Motoren stopp, wenn Hindernis gefunden -> ausweichen oder so...

Gruß
Peter

[Torsten]

Hallo Peter,

kann man mit ftrobopy zwei Encodermotoren ohne Angabe einer "Distanz" dauerhaft synchron laufen lassen?
Ich möchte einen Fahrroboter so lange geradeaus fahren lassen, bis ich die Motoren aufgrund eines Ereignisses, z.B. Ultraschall-Distanz unterschritten, wieder stoppe.

Also -> Motoren synchron ein -> Ultraschall-Distanzsensor-Auswerteschleife -> Motoren stopp, wenn Hindernis gefunden -> ausweichen oder so...

Ja, das kann man z.B. so machen:

Code: Alles auswählen

import ftrobopy
import time

txt = ftrobopy.ftrobopy('auto')

m1  = txt.motor(1)      # encoder motor 1 an M1 und C1 angeschlossen
m2  = txt.motor(2)      # encoder motor 2 an M2 und C2 angeschlossen
us  = txt.ultrasonic(1) # ultraschallsensor an I1 angeschlossen

m1.setDistance(0, syncto=m2)
m2.setDistance(0, syncto=m1)
m1.setSpeed(512)
m2.setSpeed(512)
while us.distance() > 15:
  time.sleep(0.01)
m1.setSpeed(0)
m2.setSpeed(0)

txt.stopOnline()
time.sleep(0.01)

Viele Grüße
Torsten

[PHabermehl]

Hallo Torsten
Vielen Dank, ich hatte in der Doku nichts gefunden und wollte keine 'auf gut Glück '-Lösung, die ggf. Auf ungewollten verhalten der ftrobopy basiert und nach dem nächsten Update dann nicht mehr funktioniert...
Gruß
Peter

[ski7777]

Normal sollte es reichen die Motoren einseitig zu synchronisieren. D.h. es reicht zu sagen, M1 synchronisiere zu M2 und umgekehrt ist nichts erforderlich.

Raphael

[Techum]

Hallo zusammen,

vielleicht sollte ich lieber eine neue Frage stellen, aber prinzipiell passt es - führt die Frage oben weiter:

Hier hat doch bestimmt auch schon jemand Kurvenfahrt über counter/Zeit programmiert? Also 2 Motoren unbegrenzt laufen lassen - aber eine countergesteuerte Synchron- oder Kurvenfahrt.
Ich denke mir das so, dass permanent die Geschwindigkeit der beiden Motoren upgedated wird über zwei Parameter: Liniengeschwindigkeit und Drehung.
Die Funktion soll dafür sorgen, dass die beiden Rotationsgeschwindigkeiten permanent an die Sollwerte angepasst werden.
Wichtig wäre, dass das kontinuierlich bis zum Abbruch läuft und nicht ruckt.

Viele Grüße
Techum

[Torsten]

Hallo Techum,

der TXT hat intern die Fähigkeit auch exakt definierte (ruckelfreie) Kurvenfahrten über "nahezu synchronisierte" Encodermotoren auszuführen, fischertechnik nennt das in der Dokumentation des C-Programming-Kit "sync error injection". Es bedeutet wohl, dass automatisch die Geschwindigkeiten bei unterschiedlich gesetzten Distanzen zweier synchronisierter Motoren so angepasst werden, dass beide Motoren in etwa zur gleichen Zeit fertig werden. Soweit ich weiss, wird das z.B. in ROBOPro auch direkt unterstützt.

In ftrobopy könnte man diese Funktion mit einem Trick zwar auch nutzen, es wäre jedoch derzeit noch etwas umständlich. Ich werde Deine Anregung jedoch aufgreifen und das in der nächsten ftrobopy-Version transparent zur Verfügung stellen (bisher hatte noch niemand danach gefragt, deshalb war es nicht auf meinem Schirm).

Da die Methode darauf basiert, beide Motoren in etwa zur gleichen Zeit anzuhalten, ist es allerdings nicht möglich die Motoren "unendlich" laufen zu lassen (weder in ROBOPro noch in ftrobopy). Das liegt ganz einfach daran, dass mathematisch "unendlich + x" = "unendlich" ist.

Als Workaround müsste man lange Distanzen einsetzen (max ist 32767) und den Vorgang in einer Endlosschleife laufen lassen. Das würde dann bei jeder Wiederholung zu einem leichten Ruckler führen (nach jeweils ca. 500 Achsumdrehungen des Kurvenäußeren Motors). Je nach Anwendung wäre das ja evtl. noch akzeptabel ?

Viele Grüße
Torsten

[Techum]

Hallo Torsten,

vielen Dank für die schnelle Anwort.

Als Workaround müsste man lange Distanzen einsetzen (max ist 32767) und den Vorgang in einer Endlosschleife laufen lassen. Das würde dann bei jeder Wiederholung zu einem leichten Ruckler führen (nach jeweils ca. 500 Achsumdrehungen des Kurvenäußeren Motors). Je nach Anwendung wäre das ja evtl. noch akzeptabel ?

Selbst wenn der Roboter in der Sporthalle fährt, sollte das kein Problem sein!
Klingt vielversprechend!

Viele Grüße
Techum

[Dirk Fox]

Hallo Torsten,

das ist ja cool - die Option ist mir in ROBO Pro bisher entgangen... Ich kann also zwei Motoren mit verschiedenen Distanzvorgaben versehen und sie synchronisieren, und dann fährt mein Roboter eine Kurve und stoppt beide Motoren gleichzeitig? Grandios.

Spurfolger einmal anders

Herzliche Grüße,
Dirk

[Torsten]

Hallo Techum,

Ich habe mir das mit den synchronen Kurvenfahrten nochmal genau angeschaut und versucht es zu verstehen. Es funktioniert doch nicht ganz so einfach, wie ich es zuerst vermutet hatte. Meine Erste Aussage stimmt jedoch:

der TXT hat intern die Fähigkeit auch exakt definierte (ruckelfreie) Kurvenfahrten über "nahezu synchronisierte" Encodermotoren auszuführen, fischertechnik nennt das in der Dokumentation des C-Programming-Kit "sync error injection".

Ich habe ein kleines Beispiel-Video dazu auf Youtube hochgeladen: https://youtu.be/9_lruUhcWDQ

Man hat damit die Möglichkeit die Motorcounter durch hinzufügen von "(+/-)Deltas" während einer Synchronfahrt zu manipulieren. Durch geschickte Wahl der Deltas und der Zeiten zwischen den Manipulationen, kann man einen Roboter so im Kreis laufen lassen, dass er wieder (nahezu) exakt zum Ausganspunkt zurückkommt. Der TXT passt die Geschwindigkeiten der Motoren automatisch immer wieder an einen Synchronlauf an. (Mathematisch durchfährt man keinen perfekten Kreis, sondern ein Vieleck.) Da das Ganze in einer einzigen "Distanzfahrt" geschieht ist das relativ ruckelfrei. Im Gegensatz zu einer "Vieleckfahrt" bei der man immer wieder eine bestimmte Distanz gerade fährt dann ein bischen dreht und so weiter.

Im Prinzip könnte man natürlich auch zwei Motoren mit leicht unterschiedlichen Geschwindigkeiten laufen lassen. Die Wahrscheinlichkeit, dass man dann nach einer (größeren) Kreisfahrt den Ausgangspunkt wieder trifft ist allerdings geringer als bei synchronisierten Kurvenfahrten.

Diese "Sync Error Injection"-Funktion wird bereits auf der Ebene der Motorplatine des TXT unterstützt und sie wird auch über alle Protokolle nach oben hin bis zu ROBOPro weitergereicht. Leider habe ich in ROBOPro jedoch keine Option gefunden, mit der man diese Funktion aktivieren kann. Vielleicht weiss ja jemand hier im Forum, ob das irgendwo in ROBOPro machbar ist. Es müsste irgendwo bei den Synchronisationsoptionen der Encodermotoren mit dabei sein: anstelle einer Motornummer 1...4, mit dem synchronisiert werden soll, muss man eine Nummer 5...8 zur Synchronisierung angeben. Dann hat man die Möglichkeit die schnellen Counter während einer einzigen Distanzfahrt zu manipulieren.

Ich habe das Ganze mal in ftrobopy (ab Version 1.99) eingebaut und mit einem Beispiel Python-Script versehen. Um die idealen Parameter für eine Kreisfahrt herauszufinden muss man etwas herumprobieren.

Falls es zu diesem Thema weitere Erkenntnisse gibt, währe ich für Rückmeldungen dankbar.

Viele Grüße
Torsten

[Techum]

Hallo Torsten,

vielen Dank für Deine schnelle Lieferung.
Ich habe mir beeindruckt Deine Kreisfahrten angesehen. Das sieht sehr vielverprechend aus. Ich erkläre mal mein Problem. Man sieht es eigentlich ganz gut beim losfahren auf den Teddybär. https://www.youtube.com/watch?v=llnVXh4ysPs&t=60s etwa Sekunde 37 im Video. Wenn der Robotor aus der Drehbewegung kommt, fährt er nicht gerade los (ich mache das inzwischen mit einem Synchron-Start - ist aber irgendwie "gefummelt").
Außerdem habe ich mir Drehzahl und Drehgeschwindigkeit der beiden Encodermotoren ermittelt und einen sehr deutlichen Unterschied festgestellt.
Beide weisen im relevanten Bereich zwischen 150 und 512 zwar etwa eine lineare Beziehung zwischen setSpeed() und counter/Zeit auf, die Kennlinien sind aber sehr unterschiedlich. Bei mir (im eingebauten Zustand):

* M1: counter/t = 3.64 * speed + 94.5
* M2: counter/t = 4.25 * speed - 303.9

Fest steht aber, wenn der Roboter auf relativ kurze Distanz deutlichere Kurskorrekturen machen muss, dann reicht dieser Ansatz ohne Feedback nicht mehr aus. Das, was Du da machst, ist also genau das, wonach ich suche.
Wenn ich es recht verstehe, bestimmt man durch den Wert von Inject den Radius. Syncherror ist die Schrittweite. Mit Flip=False oder True bestimmt man die Drehrichtung.

Was mir noch fehlt, ist die Trimmung. Bei gleicher Parametrisierung unterscheiden sich die Kurvenradien (Rechtskurve/Linkskurve) gravierend.
Müsste man hier auf die gesetzen Geschwindigkeiten zurückgreifen?
Ich habe versucht, Dein Programm mit einem sich ändernden Radius zu speisen, das will aber noch nicht recht. Ich gebe für heute mal auf.

Schönen Abend noch!
Techum

[Techum]

Hallo Torsten,

noch ergänzend: Wenn ich die inject-Routine erstmals aufrufe, kann ich quasi jeden beliebigen kontrollierten Kreisbogen nach links oder rechts setzen. Mit Geschwindigkeitsanpassung s.o. kommen auch vergleichbare Radien heraus.
Wenn ich aber die Anzahl der Durchläufe der Endlosschleife aus Deinem Beispiel begrenze und die Routine mit einem anderen Radius neu aufrufe, dann bekomme ich nur noch Geradeausfahrten. Muss man die Synchronisationsbits zuerst wieder zurücksetzen? Z.B. kurz einen klassischen Synch-Befehl senden?

Viele Grüße und eine schöne
Vorweihnachtszeit
Techum

[Techum]

Hallo Torsten,

erstes Ziel: Schlangenlinien. Also Bogen links, Bogen rechts und immer so fort. Gleicher Bogenradius.
Wenn ich vor jedem Bogenwechsel einen Motor Synch sende, also:

txt.SyncDataBegin()
m1.setDistance(0, syncto=mr)
m2.setDistance(0, syncto=ml)
txt.SyncDataEnd()
txt.updateWait()

dann geht es schön im Wechsel nach links und rechts. Mit vorheriger Trimmung (Anpassung der Geschwindigkeit gemäß Kennlinie) kommt eine gerade Schlangenlinie heraus.
Allerdings wird "erratisch" immer mal ein Bogen ausgelassen. Das ist mir nicht klar, da vor jedem Bogen die gleichen Bedingungen herrschen sollten.
Stattdessen geht es dann geradeaus. Ggf. kommt da einer der

mr1.setDistance(0, sn=6)
m2.setDistance(0, sn=5)
"nicht an"? Kann ich das überprüfen?

Da das nicht so oft passiert (alle 10-15 Bögen vielleicht, hintereinander habe ich es noch nicht gesehen), wird der Roboter sein Ziel vermutlich trotzdem erreichen.

Ich benutze 1:1 Deinen Code. Statt "while True" immer 100 Durchläufe. Flip setze ich je nach Richtung True oder False.
Die Korrekturen zur Geschwindigkeitsanpassung sind recht gravierend, das dürfte Verwackler bei Fahrten mit Kamera geben

Ich baue es so mal ein.
Nochmals vielen Dank!

Techum

[Torsten]

Hallo Techum,

die Aussetzer, die Du beschreibst, habe ich bisher noch nicht beobachtet. Verwendest Du das Script im Online oder im Offline Modus ?

Viele Grüße
Torsten

[Techum]

Hallo Torsten,

online, wobei das neue Projekt auch offline laufen müsste. Muss mal probieren, ob es offline auch auftritt. Melde mich.

Techum

[hypnotoad]

Hallo,

ich nutze synchronisierte Encoder-Motoren für meinen Plotter mit ftrobopy. Soweit ich das verstehe muss man eine Regelschleife aufbauen, die schaut, wie weit der Hauptmotor ist, um dann den Fehler vom Nebenmotor so einzustellen, dass er langsamer fährt. Das funktioniert relativ gut in den meisten Fällen. Es gibt aber Probleme beim anfahren und beim bremsen, da der Hauptmotor sanft startet und stoppt, aber der Nebenmotor durch die Regelschleife zu schnell anfängt und zu spät aufhört.

Hat sich hiermit schon jemand beschäftigt? Soweit ich das sehe ist es ganz normale Regelungstechnik.

lg,
Ralf