Pro Bot 128 / Projekt: Motorsteuerung verbessern

[Schmirk]

Sicherung verbaut, testcode (mit pwm) geschrieben... Motoren drehen kaum, nur mit Schwung geben.

Testcode geändert (enable High oder low) Motoren drehen kaum.

Multimeter rausgeholt. Hier und da gemessen. Logikspannung, motorspannung am l293d unter 1v, schwankend.

Am Kopf gekratzt, am veränderten pfostenstecker gewackelt. Zack! 5v kommen am ic an.

Motortest: drehen wie verrückt.

Funktionstest mit geradeaus vor und zurück, links/rechts drehen:
Fährt entweder nur geradeaus und dreht rechts oder nur zurück und dreht Links.

Tippe auch hier auf wackelige Kontakte im Stecker. Habe den Stecker beim auseinanderbauen demoliert und diesen "schneidleisten" als klemmen im Stecker traue ich sowieso nicht. Nach Ostern mal neue Stecker besorgen und das flachkabel tauschen.

Kann es noch an was anderem liegen?
Wenn ich die Motordrehrichtungsports auf Ausgang konfiguriere und dann entweder eine 0 oder eine 1 reinschreibe, müssten die doch zwischen High und low wechseln oder? Klappt bei den enable Leitungen ja auch.

[radbruch]

Hallo

Du hast ja sicher auch den "Frei"-Pin neben dem Sockel oben mit dem Kontroller verbunden, oder?

Ärgerlich, dass die Stecker ausgerechnet vor einem langen Wochenende kaputt sind. Alternativ und zu Testzwecken könnte man die auch verlöten.

Gruß

mic

[Schmirk]

Jupp habe ich. Ja ist es. Aber diese Stecker schadfrei wieder zu demontieren ist so gut wie unmöglich. Daher rate ich dazu wenn die Kabel mittig zu trennen, drehen, anzulöten und verschrumpfzuschlauchen. Spiele außerdem kt dem Gedanken noch zwei pins zu opfern, da man anscheinend den b Kanal vom Timer nicht unabÄngig konfigurieren kann.


Frohe Ostern !

[Schmirk]

Heute neue Pfostenbuchsen und nen Meter Flachbandkabel vom großen C geholt, neues Kabel "gebaut" mit den getauschten Leitungen. Kontakte sind nun alle einwandfrei.

Allerdings bleibt das Problem mit der Drehrichtung vorhanden.
Daher tippe ich darauf, dass das Problem vor dem Bildschirm sitzt.
Beide Motoren drehen sich, nur nicht in die gewünschte Richtung.

In meinem Programm definiere ich zuerst die Ports mit
#define Motor_Dir_Left 15
#define Motor_Dir_Right 11
#define Motor_Enable_Left 14
#define Motor_Enable_Right 13

In der Main setze ich dann die Ports auf Ausgang mit
Port_DataDirBit(Motor_Dir_Left,1)
Port_DataDirBit(Motor_Dir_Right,1)
Port_DataDirBit(Motor_Enable_Left,1)
Port_DataDirBit(Motor_Enable_Right,1)



Dann setze ich die Zustände der Ports auf High bzw. low
Port_WriteBit(Motor_Dir_Left,0) 'Richtung vorwärts / INVERTIERT über CD4093
Port_WriteBit(Motor_Dir_Right,0)
Port_WriteBit(Motor_Enable_Left,1) 'Motoren an
Port_WriteBit(Motor_Enable_Right,1)

Eigtl. sollte der Bot dann doch vorwärts fahren. Er fährt aber rückwärts!

Mit diesen Porteinstellungen müsste er ja dann in die andere Richtung fahren. Er fährt aber wieder rückwärts!
Port_WriteBit(Motor_Dir_Left,1) 'Richtung rückwärts / INVERTIERT über CD4093
Port_WriteBit(Motor_Dir_Right,1)

Bei Drehungen mit Ports 0 und 1 bzw. 1 und 0 dreht er immer nur links herum.

Muss ich am ersten Eingang vom NAND-Gatter vlt. noch einen Pulldown anbringen, weil die Zustände sonst nicht klar definiert sind? Aber eigtl. müsste er dann ja einfach iwas machen ohne reproduzierbares Ergebnis.

Ich hoffe jmd. kann mir hier die Erleuchtung bringen, was ich falsch mache...

- - - Aktualisiert - - -

Grad nochmal in den Schaltplan geschaut. Ja da müssen wohl Pulldowns an Pin 1+2 und 9+8 vom nand-Gatter, da wo die Controllerleitungen dran hängen. Ist ja mehr oder weniger dasselbe wie bei den Enable-Eingängen vom Motortreiber.

- - - Aktualisiert - - -

Pulldowns sind eingelötet. Keine Besserung :'(

[Schmirk]

Liegt es evt. am verwendeten Portbit für Motor_Dir_Left ? Habe den Bit Nr. 11 (X1_5 / MISO) verwendet. Kann man diesen Bit normal benutzen oder wird er evt. durch andere Funktionen überlagert?

- - - Aktualisiert - - -

Es geht doch nichts über ein gepflegtes Selbstgespräch...
Der Miso-Bit gehört zur SPI-Schnitstelle. D.h. ich muss entweder SPI_Disable() aufrufen um den Bit verwenden zu können oder einen anderen Bit benutzen. Hoffe das ist die Lösung. :-D

[radbruch]

Hallo

Ich leide mit dir, kann dich aber leider nicht unterstützen, weil ich den orginalen Kontroller nicht besitze. Und die Zeit zum Einlesen habe ich im Moment leider auch nicht.

Es geht doch nichts über ein gepflegtes Selbstgespräch...

Jepp, da kann ich nur zustimmen :)

Gruß

mic

[Schmirk]

Geteiltes Leid ist halbes Leid :-D

Heureka!
SPI_Disable() hat den Durchbruch gebracht. Der Bit den ich für die Drehrichtung benutze ist sonst nicht programmierbar. Nun fährt er schonmal in die richtige Richtung.

Als nächstes geht es per try and error an die minimaleinstellung für das pwm Signal. Bei der Einstellung 50:50 Puls/Pause tut sich mal so gar nix.

[Schmirk]

Nach Tests mit diversen PWM-Frequenzen von 5kHz bis runter auf 222Hz hat sich gezeigt, dass ich den größten Einstellbereich (100-ca.35%) für die Geschwindigkeit bei 222Hz habe, da bei dieser Frequenz auch im niedrigen Drehzahlbereich noch genügend Drehmoment vorhanden ist, um den ProBot zu bewegen.
Außerdem ist so auch das nervige fiepen weg, dass im hörbaren Bereich zwischen 2-5kHz liegt.

Nun stellt sich mir die Frage, ob so eine niedrige Frequenz evt. schädlich für den Motor ist.

https://www.roboternetz.de/community/threads/25135-PWM-Motor-Frequenz
In diesem Thread heißt es unten, dass kleine DC-Motoren mit niedrigen Frequenzen (500-600Hz) gut laufen.
Je größer der Motor, desto höher sollte die Frequenz sein. Mit 500 Hz habe ich auch getestet; da ist dann allerdings schon bei 40% kein vorankommen mehr.
Oder sollte ich vlt. in den Bereich von 5-10kHz wechseln? Allerdings steht im Datenblatt vom L293D:
This device is suitable for use in switching applications at frequencies up to 5kHz.

[Schmirk]

http://www.mikrocontroller.net/artic...uerung_mit_PWM

Das ist ein sehr interessanter Artikel zur pwm Frequenz für Motoren.

Demnach sollte ich vlt. Doch mal den Bereich >5kHz testen.

Mal schauen, ob ich ne Max Frequenz für den l293d Iwo finde außer der Angabe von 5kHz im Datenblatt.

[Schmirk]

Nach langer langer Pause hier mal ein Update:
Vor Kurzem habe ich meinen zwischenzeitlich auf den Dachboden verbannten Probot rausgekramt, da mich die Bastellaune packte.

Wem der folgende Text zu lang ist bitte runterscrollen zu "Meine Vermutungen"

Nach etlichen Stunden des Messens und Grübelns habe ich die Ursache gefunden, warum er keine Verbindung mehr zum PC herstellen konnte. Es lag an defekten Mikrotastern, die den Reset- und Boot-Pin des Controllers auf Masse ziehen müssen beim einschalten, um so die PC-Verbindung zu ermöglichen.
Von diesem Teilerfolg beflügelt habe ich mich wieder mit der Optimierung der Motorsteuerung und der Odometrie beschäftigt und bin auf etliche Probleme gestoßen.

Ziel ist es, eine Funktion mit PID-Regler zu programmieren, die es ermöglicht per Eingabe entsprechender Variablen den Roboter zu steuern. Eine Funktion, die mir als Grundlage dient, ist in der Originalbibliothek des Probots bereits vorhanden, "GO_TURN(Distanz, Drehung, Geschwindigkeit)".

In Anlehnung an den PID-Regler "nach Waste" für den Asuro habe ich das Programm umgeschrieben und auf meine Bedürfnisse angepasst. Generell funktioniert es so:

- Distanz (in cm) = abhängig vom Vorzeichen der Variablen vorwärts/rückwärts eine bestimmte Strecke fahren.
Die Motor-Dir Pins des Motortreibers L293 werden hierzu entsprechend auf High oder Low gesetzt.
Die Messung/Berechnung der Strecke erfolgt per Vergleich des SOLL- und IST-Wertes für die notwendige Anzahl an "Encoder-Ticks" der Odometrie des Probots, z.B. 100cm = 500 Ticks. Diese werden per ISR erfasst.

- Drehung (in Grad) = wie zuvor, jedoch für links/rechts auf der Stelle drehen

- Geschwindigkeit (0-255) = SOLL-Wert Startgeschwindigkeit, Ansteuerung des Enable Pins eines L293 per PWM, der die Motoren antreibt. Ab einem bestimmten Minimalwert wird nach unten begrenzt, da die Räder sonst stillstehen.

- Bedingt durch die Verbindung der einzelnen Komponenten ist aktives Bremsen durch kurzschließen der Motor-Dir Pins am L293 aktuell nicht möglich. Sollte es sich im späteren Verlauf zeigen, dass dies sinnvoll oder notwendig ist, kann ich am Controller problemlos weitere Pins nutzen.

Nun zu meinem Problem und den Lösungsansätzen:
Grundsätzlich funktioniert das Programm so wie es soll, allerdings fährt der Roboter keine Gerade, sondern einen betrunkenen Bogen, sprich die Korrekturwerte für den P, I und D Anteil passen nicht. Zum Testen und Debuggen habe ich in den Code der Mainfunktion Textausgaben eingefügt, um folgende Werte die innerhalb des Programmablaufes relevant sind im PC-Terminal anzeigen zu lassen:

- Encoder Count Left und Right (IST-Werte) / Encoder Count Gesamt (SOLL-Wert),
errechnet aus (Summe Left+Right)/2
- Error (Encoder Count Right abzgl. Encoder Count Left)
- aus Error berechnete Stellgrößen für P, I und D-Anteil
- Anzahl der Schleifen, sprich wie oft die While Schleife für den Regler insgesamt durchlaufen wurde bis der SOLL-Wert für die zurückgelegte Strecke erreicht wurde.

Hierbei trat nun folgendes Problem auf:
Es hat sich gezeigt, dass bei bestimmten PWM-Frequenzen, jedoch nicht wirklich reproduzierbar, die Odometrie des Probots falsche Werte liefert. Einer der beiden Sensoren meldet sobald die Motoren anlaufen direkt in der ersten Schleife z. B. einen Wert von 200-300 Ticks und der andere 0 Ticks. Die Räder drehen sich aber noch nicht einmal!
Dadurch wird die While Schleife verlassen und die Funktion als erledigt angesehen, da die Gesamtticks bereits den SOLL-Wert überschreiten.

Eine Recherche im C-Control Forum ergab, dass dieser Effekt anscheinend durch einen Konstruktionsfehler des Probots entsteht. Auf der Motorplatine verlaufen die Leiterbahnen für die Signale der Radencoder in Teilbereichen direkt über den Leitungen für die Motoransteuerung, auf denen das PWM-Signal übermittelt wird (Oberseite und Unterseite der Platine). Das PWM-Signal beeinflusst dadurch die Encodersignale und zusätzliche Interrupts werden hierdurch ausgelöst. Um das Problem zu umgehen wird vorgeschlagen, die Leiterbahnen zu kappen und ein geschirmtes Kabel direkt von den Sensoren zu den Pfostensteckern zu legen, die Motor- und Controllerplatine verbinden. Weiterhin wird u.a. auch in dem Probot-Buch empfohlen zwischen den Sensoren und dem Controller Schmitt-Trigger einzubauen, um die Signalflanken schön rechteckig zu formen.

Beide Tipps habe ich nun bereits umgesetzt. Die Signale der Encoder werden in ein IC vom Typ 4093 (HCF4093B) gegeben, dass an den Ausgängen 0 oder 5 Volt an den Controller überträgt.
Außerdem habe ich den originalen Encoder-Sensor bestehend aus einem Fototransistor und einer IR-Diode, die im 90° Winkel zueinander angeordnet sind und auf eine Schwarz-Weiß Zählscheibe mit 8er Teilung blicken, gegen einen CNY70 auf der Unterseite der Platine ausgetauscht. Auch die Zählscheibe habe ich gegen eine mit 32er Teilung aus bedruckter Transparentfolie mit einem Hintergrund aus Alufolie getauscht, um die Auflösung zu erhöhen. Um ein brauchbares Low-Signal für den Schmitt-Trigger zu erhalten musste ich außerdem den Vorwiderstand der beiden in Reihe geschalteten IR-LEDs aus den beiden CNY70 von 220 auf 100 Ohm reduzieren.
Wenn der Fototransistor durchsteuert zieht er den Eingang vom Trigger nun auf Low (ca. 1,2 Volt), wenn er sperrt liegt am Triggereingang >4,2 Volt an.

Durch Messen (Multimeter) und einen manuellen Check der Interruptfunktionen hat sich gezeigt, dass die Interrupts durch händische Drehen des Rades nun zuverlässig ausgelöst werden.

Ein Problem behoben, nächstes Problem folgte direkt im Anschluss:
Die oben beschriebene GO-TURN Funktion liefert mir nun nur noch Werte von 0 für alle Regel- und Stellgrößen!?
Der Encoder-Count links und rechts wird nicht erhöht und die Abbruchbedingung für die While Schleife somit nicht erreicht. Auch der Regler kann mit einem Error von 0 natürlich nichts regeln.
Sprich die Räder drehen sich permanent. Allerdings gibt es nun auch keine Störungen mehr durch das PWM-Signal.
Aber es würde ja auch keinen Spaß machen und man würde nichts dazu lernen, wenn alles auf Anhieb klappt.

Meine Vermutungen:
1. Ist es möglich, dass durch die 4-fach höhere Auflösung der Ablauf der Encoder-ISR (jeweils eine für das linke bzw. rechte Rad) gestört wird, da die Interrupts schneller ausgelöst werden als die ISR sie abarbeiten kann? Die Scheibe ist 32 fach (16x schwarz/16xAlufolie) aufgeteilt und der Interrupt wird bei jeder steigenden und fallenden Flanke ausgelöst, sprich bei jedem Wechsel von schwarz zu weiß und umgekehrt. In der ISR selbst werden nur die Variablen für den Zählstand um 1 erhöht und das Interruptflag gelöscht. Hat bei einer geringeren Auflösung mit Original-Encodern funktoiniert.

2. Kann es sein, dass durch die schnelle Drehung der Zählscheibe bei Antrieb per Motor keine brauchbaren Pegel mehr für den Schmitt Trigger verfügbar sind? Also der Pegel iwo im Bereich der Hysterese des Schmitt-Triggers dümpelt, so dass er nicht "durchschaltet". Als Laie stell ich mir das als "50% graue Scheibe" vor.

Für etwaige Denkanstöße und Winks mit Zaunpfählen danke ich im Voraus!

Werde heute Abend mal Scheiben mit geringerer Auflösung probieren und versuchen per Multimeter die Frequenz zu messen (habe in dem Ding eine Funktion für Anzeige in Hertz).