Elektronisches Umkehrdifferential

Elektronisches Umkehrdifferential mit einstellbarem Kurvenradius (null - unendlich) :-k

An einigen Threads in letzter Zeit glaube ich ein Interesse an der Steuerung von DC Motoren zum synchronen Lauf in gleicher und entgegengesetzter Richtung zu sehen. Das ist ja eine Betriebsart die in der Ansteuerung von Robotern häufig vorkommt und die von Schrittmotoren besonders gut ausgeführt werden kann.

Mit Encodern kann man die Bewegung von DC Motoren recht genau erfassen und mit PWM kann man die Bewegung auch recht genau nachsteuern.

Steuert man nun einen Motor an und wünscht sich die genaue Nachführung des anderen Motors in der einen oder anderen Richtung, dann müsste ein 8pin AVR (so in der Gegend von AT90S2343) in der Lage sein, durch Aufnahme der Rad-Encodersignale Aufsummieren und Vergleichen, alle relevanten Daten bereitzustellen und im Idealfall sogar schon gleich das PWM Signal für den zweiten Motor auszugeben.

Das wäre dann vielleicht soetwas wie ein elektronisches Umkehrdifferential. Mit der selben Schaltung müssten sich auch Fahrten mit einstellbaren Kurvenradien realisieren lassen.

Bild hier  

Elektronisches Multiturn Servopoti
Eine sinnvolle Untermenge davon wäre schon die Erfassung von 2-phasigen Encodersignalen, mit Endschalter zur Positionskontrolle, und der Ausgabe als PWM Wert (elektronisches multiturn Servopoti) was ja auch nicht immer ganz einfach ist.

Bei der Motorsteuerung bei der die Richtung des Leitmotors vorgegeben wird, würde ja vielleicht ein einphasiges Encodersignal ausreichen.

Ich wollte das Thema mal als Vorschlag zur Definition eines Bausteins zur Diskussion stellen. Sicher wird es auch mit SW gehen, aber man wird auch froh sein, wenn der Hauptcontroller gar nicht erst mit der Aufgabe belastet wird.

Manfred

Wenn man es modular bauen wollte, sollte man das teilen: Das Radencodern mit einem Funktionsumfang ähnlich der Maus (Delta-Buffer)
und ein "Differential" mit Speed /Diff-..

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.

Zitat:

---

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

Ich würde warnen, zu früh in eine Detailkonzeption zu gehen, sondern erst noch die Positionierung in möglichen Gesamtsystemen zu analysieren. Das impliziert, sich zu überlegen, welche Aufgabenstellungen da eigentlich denkbar oder sinnvoll sind.
Der Auftrag, sich mit einer bestimmten Geschwindigkeit geradeaus oder um einen bestimmten Radius zu bewegen, scheint einerseits unstrittig.
Aber meistens will das Fahrzeug zuerstmal ja von A nach B und nicht in einem bestimmten Bogen fahren, wenn der Unterschied verständlich ist.
Wie verläuft die Sache, wenn unterwegs von anderen Sensoren drohende Kollisionen gemeldet werden ? Wie kann eine solche Wechselwirkung ablaufen ?

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. :-k [-(

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.

Bei den unterbrechenden Kollisionswarnungen meinte ich folgendes Szenario:
Auf Basis der "bin auf A, will nach B" Gegebenheit
erfolgt (z.B) der Auftrag Bogen mit radius etc.
Kommt bei der Ausführung mittendrin eine Stop-Situation, ist die Frage : Wo bin ich denn JETZT ?
Also müßte permanent die Position X,Y, Richtungsvect. erarbeitet werden.
Der inzwischen zurückgelegte Weg im Bogen würde da garnicht sosehr helfen.

Eigentlich bräucht' man ein System (dessen Komponenten noch zu verteilen wären), das die Werte
A (X, Y, vec) ==> B (X, Y, vec) als Bezier-Kurve interpretiert, also ggf. eine S-Kurve hinlegt, aber jeden Punkt davon als Px( x,y, vec ) darstellen kann, damit dann ggf. ein neuer Auftrag zustandekommt.

Ziemliche Viecherei, das Ganze.

PicNick, Du beschreibst genau die Endlösung, die ich in letzter Konsequenz auch haben möchte. Deshalb hab' ich mir schon mal einen mächtigen fleißkommafähigen schnellen 16bit-Controller besorgt.

Aber bis dahin ist die 2Motorsteuerung für Geraden und Kurven - in einen AVR verpackt - ein guter Zwischenschritt, den vielleicht viele gebrauchen können.

Sicher, es ist sicher super, überhaupt mal einen Kurs verfolgen zu können, ohne die ganze CPU abzufackeln.
Ich würde modularisieren: Eine anständige Encoder-Auswertung ist ja nicht strittig, da könnt schon mal wer anfangen.
Auf der anderen Seite (PWM oder Stepper), werd' ich noch ein bißchen bei den unscharfen Mengen rumstöbern.

Hallo Manfred

Zitat:

---

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.

---

Schritte zu verlieren ist vermutlich gar nicht das Problem, sondern eher keine Schritte zu viel zu machen. Da wird eine Steuerung gar nicht ausreichen, das geht schon in Richtung Positionsregelung.

Eigenständige Kurskorrektur bei Hindernissen? Das scheint mir des Guten zuviel. Slave bleib bei deinen Leisten, würde ich sagen.
Ich glaube mit einer Positionsregelung hat der Slave schon genug zu tun.

Waste

Wenn das mißverstanden worden ist : Ich meinte nicht, daß die Kurskorrektur elektrisch erfolgen sollte, sondern daß das Prozedere, wer wem was mitteilt in solchen Fällen abgeklärt sein sollte.
Einfach "Stop" ist eine Möglichkeit. Aber wie geht's weiter ?

Ich würde sagen, so wie wenn man einen Schrittmotor verwenden würde und nicht mehr. Da muss auch der Hauptprozessor überlegen wie es weiter geht.

Ganz einfach den Charme eines Schrittmotors in so eine Lösung packen.

Waste

Meine Bewunderung für die Diskussion, so ein komplexes Thema wie die grundsätzliche Funktionsverteilung in einem zweckgebundnen Multicontrollersystem in ihrer Bandbreite darzustellen und den Faden nicht zu verlieren.

Wenn wir vorne anfangen, und die Schrittmotor Ansteuerungssignale umsetzen, so dass ein DC-Motor die Schrittmotor Ansteuerung ausführt, welche Kommandos sind zu erfüllen?

Wird ein Takt vorgegeben der im Schrittzyklus befolgt werden muss oder geben wir eine Rampe vor mit der der Schrittmotor anfährt, die damit auch Schrittweise erfüllt werden muss.

Eine Alternative wäre eine Frequenz vorzugeben, eine Geschwindigkeit einzuschalten, und den DC Motor mit seiner fest eingestellten Regelcharakteristik eine Rampe daraus machen zu lassen.
Manfred

Was ich gerne mal verfolgen würde, wäre, aufgrund der ausgegeben PWM Werte eine Erwartungshaltung an die Encoderei zu stellen und damit zu vergleichen. drehen sich die Räder durch, isses schlüpfrig und man läßt ein wenig mit der PWM nach.

Zitat:

---

Zitat von Manf

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

---

Ich hab das durch die Hirnwindungen sickern lassen. Ich finde, die maximale Encoder-Check-Frequenz ist eigentlich durch die Encoder selbst gegeben, mit der ZEIT hat das nix zu tun.
Wenn ich den Beginn einer Meß-Sequenz durch den Wert = 0 für Count-links, count-rechts definiere. kann erst irgendwas gemessen oder berechnet werden, wenn einer dieser Werte ungleich null ist.
ABER
Ausschlaggebend für Berechnungen ist das Verhältnis Ticklinks : Tickrechts
Also ist erst eine Berechnung denkbar, wenn es auf beiden Seiten wenigstens einmal geschnackelt hat.
Die Ausnahme, daß ein Motor abgedreht ist, also auch keine Werte von dieser Seite kommen KÖNNEN , muß also als Feedback vom PWM-Teil geliefert werden.

Also, ich muss sagen, je mehr ich mich mit dem Thema beschäftige, umso mehr sehe ich die Vorzüge solch einer Lösung. Man denke nur an eine Schleichfahrt. Wie schwierig ist das bei normaler Ansteuerung. Je nach Untergrund und Lust und Laune der Motoren fährt er gerade noch oder nicht mehr. Jede kleine Welle im Teppich ist da ein unüberwindliches Hindernis. Mit solch einer Lösung sollte das kein Problem mehr sein.

Hier sind meine Vorschläge zu den Kommandos. Vorerst nur für Geradeausfahrt, die weiteren können wir später noch ergänzen:
1. Geschwindigkeit ist ein eigener Parameter, der vorab eingestellt wird, aber auch während der Fahrt verändert werden kann
2. fahre unbestimmte Zeit
3. fahre bestimmte Strecke (oder x Zyklen)
4. stoppe in x Zyklen
5. stoppe sofort (Notstopp)
6. gib gefahrene Strecke zurück
7. Reset des Streckenzählers (Encoder)
Inwieweit man jetzt noch die Rampe beim Anfahren und Bremsen definieren kann, ist noch zu diskutieren. Womöglich braucht man es um Schlupf zu verhindern.

Das war das, was mir so auf die Schnelle eingefallen ist, erhebe keinen Anspruch auf Vollständigkeit.
Waste

Zitat:

---

Zitat von PicNick

Die Ausnahme, daß ein Motor abgedreht ist, also auch keine Werte von dieser Seite kommen KÖNNEN , muß also als Feedback vom PWM-Teil geliefert werden.

---

Motor abgedreht, was meinst du damit?

Ich hatte postuliert, daß sowohl vom linken als auch vom rechten Encoder wenigstens EIN Wert kommen muß, um irgendwas berechnen zu können.
Wenn nun aber gerade ein motor gestoppt ist, (für eine Drehung), KANN ja von einer Seite nix kommen, dieses Null gilt aber dann als rechenbarer Wert.

Zitat:

---

Die Auflösung sollte meiner Meinung nach bei Drehungen oder Kurven so 1 - 2 Grad sein.

---

Eine Annahme haben wir ja für die Encoderauflösung. Ein bis zwei Grad Drehung der Fahrzeugrichtung.

Bei ASURO haben wir beispielsweise eine Spurweite von 105mm. Fährt er er mit einem Rad eine Drehung um 360° während das andere Rad steht, dann legt diese Rad eine Strecke von 2 Pi mal Spurweite also 660mm zurück.

Bei einem Reifendurchmesser von 38,5mm ist der Reifenumfang 121mm.
Die Strecke von 660mm sind damit 5,5 Radumdrehungen für 360° Richtungsänderung. Damit ist 1° Richtungsänderung eine 66stel Radumdrehung, (entsprechend 2° eine 33stel Radumdrehung).

Damit liegt die angenommene Auflösung der Encoder etwas unterhalb der Auflösung der Schrittmotoren mit 180 Schritten pro Umdrehng.

Die Auflösung für die Fahrstecke liegt dann bei 1,8mm-3,6mm. Soviel zu dem Beispiel.
Manfred

Ist ja schon mal ein Anfang. Bei grösseren Rädern kann es übrigens an die 180 Schritte pro Umdrehung ran gehen.
Ein Grund für eine höhere Auflösung könnte sein, dass die Regelung bei langsamer Fahrt dadurch einfacher wird.
Vielleicht gibt es noch andere Gründe für eine höhere Auflösung?
Waste

Ich habe versucht aus den bisherigen Äußerungen eine Skala der Komplexität aufzustellen:

1. Vitueller Schrittmotor mit DC Motor Kern.
2. Virtueller Schrittmotor mit Rampenfunktion
3. Zweimotorige Achse mit synchronisierten virtuellen Schrittmotoren
4. Zwei-Dimensionale Odometie Unterstützung
5. Autonom navigierendes Fahrwerk mit Positionskontrolle

Ich bin grundsätzlich für geringe Komplexität am Anfang, die Idee war aber eigntlich schon, über die ersten beiden Schritte noch ein kleines Stück hinauszugehen und das Zusammenwirken von 2 Motoren zu betrachten.
Die Synchronisierung der zwei Motoren sollte unabhängig vom zentralen Controller laufen.
Dann käme als Kommando (Steuerparameter) noch das Geschwindigkeitsverhältnis der Motoren hinzu (im einfachsten Fall mit den beiden Werten -1; +1)



Hier noch eine Bemerkung vom Beginn der Diskussion:

Zitat:

---

Zitat von PicNick

Wenn man es modular bauen wollte, sollte man das teilen: Das Radencodern mit einem Funktionsumfang ähnlich der Maus (Delta-Buffer)
und ein "Differential" mit Speed /Diff-..

---

Bei den kleinen Controller käme es wohl nicht darauf an, für jeden Motor einen zu nehmen und noch einen für die Synchronisation, (immerhin spart man eine Leistungsbrücke, vom Kühlkörper nicht zu reden). Es ist aber noch zu klären (ggf. auch zu bestätigen), ob die Synchronisation oberhalb der Einzelmotorsteuerung richtig angeordnet ist.

Manfred

Auf die physische Verteilung der Funktionsblöcke sollten wir uns auf dem Analyse-Level noch garnicht sosehr einlassen. Ich war ungeschickt mit dem Ausdruck "bauen".

Oberhalb/Unterhalb: Ich kann's mir nicht recht anders vorstellen. Die Synchronisation wird wohl nicht mit den diversen Timern rumwursteln, das müssen die "Motor"-Objekt wohl drunter selber machen.
Die Einzel-Encoder selbst und die eigentlichen Motoren sind auf jeden Fall
ganz unten. Ob aber die "Synchronisation" eher zu den Encodern oder den Motoren gehört, könnt ich nicht sagen.

Ich meine nur ganz schlicht mann sollte noch mal überlegen, ob man einen Virtuellen Schrittmotor als seine Einheit realisiert, der seine Encodersignale nur selbst auswertet und streng nach Zeitrampe fährt.

Als Alternative kann man die Encodersignale auch noch eine halbe Ebene höher zur Synchronisation zwischen zwei Schrittmotoren einsetzem die damit dann gegebenenfalls ein bisschen einfacher oder präziser synchronisiert werden können.
Manfred

Jetzt wollt ich grad was Gescheites schreiben, aber ich glaub, ich muß erstmal nachdenken drüber, ihr verzeiht mir das sicher

Da es immer ganz gut ist sich auch an einem konkreten Beispiel zu orientieren, habe ich wieder erst einmal auf ASURO zurückgegriffen.

Ich bin dabei auf das folgende Motordiagramm gekommen. Die Leerlaufdrehzahl und der Leerlaufstrom sind ohne Getriebe aufgenommen. Vielleicht wird man 4,5V, gespeist durch Labornetzteil auch nicht ganz erreichen.

Von hier aus kann man eine Fahrgeschwindigkeit bei mittlerer Last und die Frequenz der Encoderimpulse bestimmen.
Manfred

Bild hier  

Hallo Manf,
wie hast Du denn bei dem Diagramm das Drehmoment ermittelt ?
Ist das Diagramm eine Messung oder eine Rechnung ?

Gruss,
stochri

Dieses Mal wurde es nach den oben aufgeführten Eingabeparametern gemacht:
Spannung
Leerlaufstrom
Ri
Leerlaufdrehzahl
Die wurden gemessen und danach wurden die Kurven mit dem Tool berechnet.
https://www.roboternetz.de/phpBB2/viewtopic.php?t=10737

Hier wurde auch ein praktisches Beispiel zur Drehmomentbestimmung gezeigt. Die Kette ist im Bild leider nicht sehr deutlich zu erkennen.
https://www.roboternetz.de/phpBB2/viewtopic.php?t=10672

Manfred

Bild hier  

Nich schlecht, die Idee mit der Kette.
Ob sich wohl für die Asuro Motoren eine Kette finden lätßt, die klein genug ist. Obwohl ... Halskette

Gruss,
stochri

Der Thread ist nun schon etwas in die Jahre gekommen. Da das Thema in der Robotik immer wieder auftaucht, habe ich mir auch schon so meine Gedanken gemacht.

Das Problem ist ja klar, laufen die Motoren nicht gleich, so fährt der Roboter eine Kurve. Die Motoren müssen dann synchronisiert werden. Will man hingegen eine Kurve fahren, so Würde man gerne Winkel, Radius und Geschwindigkeit vorgeben. Im Asuro wurde ja bereit eine Kurvenfunktion implementiert. In diesem Thread ging es aber darum: Wer was machen sollte.

Ganz rechts sind die Motoren mit den Encodern zur Messung der Drehzahl. Bei mir sind die Encoder an den Motoren, weshalb das Getriebe und so erst dahinter kommt. Jeder Motor hat eine eigene Drehzahlregelung, die aus der Differenz von Soll-Drehzahl und Encoderwerten den neuen Motorstellwerten generiert.
Bei dem Differential muss ich immer an mein LEGO-Auto denken, es kann zum einen die Gesamtgeschwindigkeit des Roboters übertragen und zum anderen das Verhältnis von linken zu rechten Motor bestimmen (Drehung um die eigene Achse / Gear). Deswegen sollte das Soft-Differential auch zwei Regler enthalten: den Gear-Regler und den Speed-Regler. Der Speed-Regler bezieht sich hierbei auf die Geschwindigkeit des gesamten Roboters (Robotermittelpunkt). Diese Vergleichen wieder die jeweiligen Sollwerte, mit den aus den Encodern ermittelten Ist-Werten.

Diese Sollwerte (Soll-Radius und Soll-Geschwindigkeit) sollten von einem übergeordneten Controller (z.B. Tabelle für das Haus vom Nicolaus) erstellt werden.

Bild hier  

Ein schones Beispiel von diese Gedanke ist der RP6. Die basiscontroller (AVRmega32) steurt die 2 Motoren ueber PWM. Ruckmeldung von encoder geht ueber INT0/1. Auflosung von Encoder ist ca 0.25 mm. Eine ganse SW bibliotheek in C ist schon forhanden mit die genannte Auftragen (Fahre mit konstant speed, Abstand, Winkel drehen, stop). Die Regelung von der Strecke/Geschwindigkeit ist eine I-Regelung. Jeden 200 mS wirden mit die Pulsen von Interrupts Speed und Distance berechnet, und der PWM wird angepasst. Odometrie idn die Sinne das immer die genaue Position in Raum bekannt ist, wird nicht gemacht. Da ist der mega32 ueberfoerdert. Aber auch die genauigkeit von eine "Tracks" robot beim drehen verhindert eine langere Erfassung von Position. Siehe auch mal die Beschreibung von der RP6 in RN-Wissen