Thema: Elektronisches Umkehrdifferential

Eine sehr gute Idee, dieser Baustein.

Man wird allerdings ausprobieren müssen (und zwar im einzelnen Anwendungsfall mit den entsprechenden Motoren, der Untersetzung und der bewegten Masse), ob die Regelung der Motoren gut genug ist, daß man von einem geraden Lauf ohne seitlichen Versatz sprechen kann.

Jede Regelabweichung erzeugt nämlich einen unwiederbringlichen Versatz in der Laufrichtung oder mindestens einen Parallelversatz aus der ursprünglich gefahrenen Linie.

Etwas ausführlichere Erklärung:
Wenn nach erkannter Regelabweichung beide Motoren wieder auf die gewünschte GESCHWINDIGKEIT angeglichen werden, ist trotzdem schon die alte Fahrtrichtung futsch.
Wenn man versucht, während eines geraden Laufs die absolut gefahrene STRECKE beider Motoren gleichzuhalten, bleibt die Fahrtrichtung im großen und ganzen erhalten, aber durch die "Schlenkerer" wird die Fahrspur vielleicht parallel versetzt.

Aus dem Grund hatte ich für diese Aufgabe einen potenten 16bit-Controller mit zwei Hardwaremäßigen Encodereingängen vorgesehen. Und hatte vor, über ständige Überwachung der beiden von den Motoren gefahrenen Wegstrecken wirklich eine zweidimensionale Position ab der Ausgangsstelle zu tracken. Das bedeutet wahrscheinlich eine Menge Fließkomma-Rechnerei, deshalb der dicke Microcontroller.

Wohlgemerkt: Ich bin selbst noch Lichtjahre von der Realisierung dieses Konzepts entfernt bin und breite hier nur großkotzig meine Ideen aus. Nur der Controller wartet schon in der Schublade.

Also nochmal: Wäre schon eine gute Idee, und wenns genau genug funktioniert, ists eine Alternaive zu Schrittmotoren. Ich kanns nicht richtig einschätzen. Vielleicht wird man trotz allem Aufwand nicht besser, als wenn man einfach mit zuvor ausprobierten Werten die PWM der beiden Motoren auf Geradeauslauf justiert.

Manfred, bin ja auch in München. Vielleicht hilft es etwas, wenn ich eine Plattform aus Motoren, Lichtschranken, Motortreibern und Akku zur Verfügung stelle. Und die Versuchsstrecke. Die Plattform ist allerdings etwas größer und damit unrepräsentativ. Vielleicht sollte ich noch eine typische RB35-Konfiguration zusammenstricken.

Etwas ausführlichere Erklärung:
Wenn nach erkannter Regelabweichung beide Motoren wieder auf die gewünschte GESCHWINDIGKEIT angeglichen werden, ist trotzdem schon die alte Fahrtrichtung futsch.
Wenn man versucht, während eines geraden Laufs die absolut gefahrene STRECKE beider Motoren gleichzuhalten, bleibt die Fahrtrichtung im großen und ganzen erhalten, aber durch die "Schlenkerer" wird die Fahrspur vielleicht parallel versetzt.

Das ist schon mal eine sehr gute Antwort zum weiter diskutieren.
Du unterscheidest zwischen dem Ereichen der gleichen Geschwindigkeit und dem Erreichen des gleichen Drehwinkels.

So genau hatte ich es gar nicht beschrieben. Der Algorithmus im Controller, der die Encodersignale aufnimmt und in PWM umsetzt ist noch offen und er wird später einige Optimierungen brauchen.

Ich stelle mir vor, dass eine Version auch nach Regelparametern und Zeitkonstanten angepasst werden muß. Es ist auch möglich noch einmal zu integrieren und nicht nur den Drehwinkel auszugleichen sondern das Integral des Drehwinkels über der Zeit, um in Richtung einer Spurkorretur zu gehen. Vielliecht ist es aber auch gar nicht so kompliziert.

Mit welcher Frequenz sollte man die Fortbewegung überwachen? Welche Wegauflösung? Gibt es eine Schätzung dafür?
Manfred

Hallo Manfred,

da hast du dir was Schönes vorgenommen, insbesondere wenn du auch die Zeitkonstanten durch Trägheitsmomente berücksichtigen willst. Aber gerade durch eine Art Positionsregelung sehe ich den Vorteil solch einer Lösung. Weil aus meiner Erfahrung der Nachlauf wegen dem Aufwand meistens unberücksichtigt bleibt und sich dadurch der Fehler im Laufe der Zeit so vergrössert, dass eine Navigation nicht mehr möglich ist. Aber wenn man sich selber nicht mehr um diese Problematik kümmern muss, weil so ein Chip die Sache übernimmt, dann finde ich das ein paar Euro wert.

Die Auflösung sollte meiner Meinung nach bei Drehungen oder Kurven so 1 - 2 Grad sein. Daraus ergibt sich dann über Grösse der Räder und Abstand der Räder die Auflösung des Drehwinkels. Eine grössere Auflösung ist meiner Meinung nach nicht sinnvoll, da durch Schlupf und Spiel im Getriebe das nicht mehr nutzbar ist.

Ich stelle mir das so vor, dass der Chip das komplette Motorenmanagement beider Motoren übernimmt und nicht nur den 2. Motor regelt. Aber vielleicht war das auch schon deine Vorstellung und ich habe es nur falsch aufgefasst. Dem Chip werden dann die Befehle zur Steuerung in etwa sinngemäss so übergeben:
fahre 120mm geradeaus
fahre geradeaus
gib gefahrene Wegstrecke zurück
fahre Linksbogen mit 90 Grad
drehe 180 Grad rechts
usw.

Gruss Waste

Wenn man den Gedanken freien Raum läßt, dann kommt man sicher auch bald zu einer integrierten Motorsteuerung für Motoren aller Größen, die komplexe Wege verfolgt und den Hauptcontroller beauftragt darüber nachzudenken, was das ganze für einen Zweck haben könnte. [-(

Wo waren wir stehengeblieben?
Die Wegauflösung: über Winkel, dazu werden wir ein mittleres Beispiel suchen.

Die Steuerungskommandos:
1. Geradeausfahrt
2. Richtungsänderung auf der Stelle
3. Kurskorrektur nach Ausweichmanövern? das erscheint zu komplex.

Die Motivation darüber nachzudenken ist:
Es gibt Gründe, Schrittmotoren einzusetzen. Diese Motoren bewegen sich mit hohem Strom und hoher Sicherheit, keine Schritte zu verlieren. Ein DC Motor bewegt sich mit dem Strom, der zur Bewegung benötigt wird. Der Unterschied könnte durch eine Steuerung ausgeglichen werden, um die Vorteile beider Systeme zu nutzen.
Manfred

Das wird eine gute Diskussion.

Vorschlag für die Steuerungskommandos von meiner Seite:
1. Geradeausfahrt mit unbestimmter Wegstrecke
2. Stop (muß schnell reagieren)
3. Auslesen der gefahrenen Strecke
4. Drehen auf der Stelle um einen bestimmten Winkel
5. Geradeausfahrt einer bestimmten Strecke, trotzdem durch Stop unterbrechbar!
Optional noch:
6. Fahren bestimmter Bögen, ebenfalls durch Stop unterbrechbar
7. Aneinanderhängen von einigen Kommandos zum Fahren bestimmter Wegstrecken und Bögen, ohne daß der Roboter dazwischen stoppt.

Die Reaktion auf Hindernisse kann man nicht ganz wegdenken. Deshalb das Stoppen auf externes Kommando. Im Zusammenspiel mit einem trägen Windows-Rechner wäre mir ein direktes Reagieren des Microcontrollers auf Sensorsignale fast lieber. Aber ein elegantes Ausweichen wäre übertrieben. Mir genügt Stehenbleiben und dem Hauptrechner Zeit zum Denken geben.

Abschätzung zum Takt von Algorithmus und Lichtschranken:
Aufgrund der Trägheit selbst kleinster Motoren muss der Algorithmus nicht öfter als 10mal pro Sekunde laufen. Oder? So richtig kenne ich mich da nicht aus. Und zwischen den Durchläufen muss eine vernünftige Anzahl von Lichtschrankenimpulsen zusammenkommen, es genügt wohl ein Byte voll. Das ergibt bei einer gegebenen Endgeschwindigkeit des Roboters die Auflösung.

Werde als Beispiel mal die Auflösung meines Roboters berechnen, die sich einfach aus den mechanischen Möglichkeiten ergab.

Tom.