Pro Bot 128 / Projekt: Motorsteuerung verbessern

[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]

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]

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]

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).

[Schmirk]

Meistens sitzt das Problem vor dem Rechner...
Habe übersehen, dass ich die Funktion PRO_BOT128_INIT() bei den diversen Versuchen mit Geschwindigkeit etc. aus versehen "auskommentiert" habe !!!
in dieser funktion werden am anfang alle variablen und ports definiert und auch die interrupts gesetzt... sprich ohne aufruf dieser funktion am anfang ist der probot nicht lebensfähig!

mein programm läuft nun soweit und die encoder zählen brav mit. versuche grad vernünftige werte für die PID anteile per try and error zu ermitteln.
problem dabei: der linke motor scheint zu schwächeln. werde mir mal anschauen, wie das andere leute hier für ihren asuro gelöst haben. der linke motor braucht länger um das rad in bewegung zu setzen. nach einer kurzen strecke fährt mein bot dann grade. aber eben nicht in die ursprüngliche richtung, sondern bedingt durch den frühstart des rechten motors immer mit versatz nach links. dieser effekt ist beim vorwärtsfahren deutlicher als beim rückwärtsfahren.

Lösungsansätze:
1. Regelgröße speed_left manuell vor Übergabe an den PWM-Timer um einen bestimmten wert erhöhen bzw. speed_right verringern.

2. rechter motor darf erst gas geben, wenn am linken motor der erste interrupt durch die zählscheibe ausgelöst wurde.

3. akkupack (6x1,2v hinten auf motorplatine) auf die experimentierplatine montieren, möglichst zentral zum drehpunkt. durch die masseträgheit übersteuert er speziell bei schnellen drehungen um die eigene achse. je kleiner der winkel, desto deutlicher die übersteuerung.

Ziele:
1. genauigkeit verbessern bei wegstrecke bzw. drehung um einen bestimmten winkel.
2. funktion für kurvenfahrten integrieren. z.b. drehung um 90° mit einem vorgegebenen bogenmaß um einen imaginären drehpunkt.

3. wenn das steht sehe ich mal weiter was mir dann einfällt. würde z.b. gerne ein lc-display einsetzen auch zum debuggen im gelände und nicht nur am pc.

4. Ultraschallsensor auf servo montieren als umgebungsscanner

es gibt viel zu tun!

[Schmirk]

bin mir zwar nicht sicher, ob das hier überhaut noch jmd. mitliest aber ich schreib mal weiter (mein) tagebuch:

1. Motorsteuerung läuft soweit, aber gerade fährt der kleine noch nicht. muss wohl nich weiter an den PID Werten feilen...

2. Die Motorspannung am L293D kommt bei mir direkt aus dem Akku (6*AA Zelle, frisch geladen ca. 8,4v) Mir ist aufgefallen, dass hier durch die getrennte versorgungsspannung gar kein kondensator mehr im stromkreis ist. habe nun einen elko mit 100 microfarad parallel zu GND dazwischengeklemmt. nächste versuchsreihe steht noch aus.

3. mittels I2C portexpander pcf8574 habe ich ein 2x16 zeichen lcd auf der breadboard platine hinzugefügt. hat dank der vorhandenen I2C lcd lib (fast) auf anhieb geklappt. problem war anfangs ein zu kleines poti am kontrastpin, wodurch das lcd nichts angezeigt hat.

4. für erste gehversuche mit SPI habe ich außerdem 8 stück rote 3mm low current leds auf der vorderen hälfte der breadboard platine angeordnet und über ein 74hc595 schieberegister an den spi bus angeschlossen. hat auch (fast) auf anhieb geklappt. hab halt einfach mal den takteingang am falschen mc pin angelötet (bis 7 zählen ist schon schwierig)...
mittels byte arrays kann ich mir nun neben dem lcd auch über diverse blinkmuster der leds z.b. zustände oder aktuelle funktion anzeigen lassen.
oder ein nightrider lauflicht für den "coolness-faktor"

5. da die alten bumper, bestehend aus mikrotastern mit schaschlikspießfühlern bei den diversen probefahrten bzw. bei schnellen drehungen um die eigene achse zu nahe an einer wand gebrochen sind (schaltwippe) habe ich mir aus einem gebogenen eisstiel und zwei drucktastern einen neuen bumper gebaut, der hoffentlich stabiler ist. funktion allerdings noch nicht getestet.
brauchen ziemlich viel druck zum auslösen (ca. 250 g).

nächste schritte:
-zusätzlicher distanzsensor mit tendenz zu einem sharp ir auf servo
-stromversorgung überarbeiten
. aktuell gelöst mit 7805er für die logikspannung. besser wäre eine ultralowdrop variante oder schaltregler
-libraries nochmal sauber durcharbeiten
-programm mit subsumptionsarchitektur aufbauen und den bot mit ein paar aufgaben unter einbeziehung aller verfügbaren Sensoren und aktuatoren rumfahren lassen
-selbständiges anfahren einer ladeschaltung
-weltherrschaft ^^

werde gleich mal ein paar fotos für interessierte einstellen.

- - - Aktualisiert - - -

unterste Platine mit neuem Frontbumper (rechts), Spannungsversorgung (links), Schmitt Trigger Huckepack auf Motor Dir IC, um die Signale der Radencoder zu verbessern (Mitte)

mittlere Platine mit "Front-Scheinwerfern" (rechts) Danke nochmal an den user bnitram für die Hilfe dabei), Anschlüssen für die Versorgungsspannung und dem 4 poligen Kabel für den SPI Bus zum Schieberegister auf der oberen Platine (SCK, SCLK, RCLK und OE)

obere Platine ohne LCD mit Portexpander PCF8574 (Mitte), Schieberegister 74HC595 (oben), Pinleiste für das LCD (rechts) und den LEDs am Schieberegister (rechts außen)

so sieht er aktuell zusammengebaut aus...

Stromversorgungsplatine mit 7805 und reichlich Anschlussklemmen
Front-Scheinwerfer
Radencoder mit Reflexlichtschranke CNY70 und selbstgedruckter Encoderscheibe (selbstklebende Folie mit Laser bedruckt auf Aluminiumfolie), Auflösung 32 Ticks