Motor-Encoder erzeugt bei hohen Drehzahlen Fehlern

[Xaver]

Hallo zusammen,
[right:abd365b507]http://3.bp.blogspot.com/_qPTJUGegS5w/RfvkFxfGqDI/AAAAAAAAABE/nWNJ4RsGsVU/s200/DSC00519.jpg[/right:abd365b507]


mein Bruder und ich habe Probleme mit unseren Encodern und wir wissen noch nicht einmal ob es ein Denk, Rechen oder Mechanischer Fehler ist. Die Encoder haben wir auf unserem Blog wsgs.blogspot.com ausführlich beschrieben.

Es handelt sich um Encoder für RB-40 Motoren, die am Ende des Motors befestigt werden. Zwei Gabellichtschranken und eine Schlitzscheibe erzeugen zwei um 90° verschobene Signale. Ein Schmitttrigger säubert die Signale für einen µC. Die Auswertung wird durch einen der neueren ATmega328P durchgeführt. Dessen Eingänge lassen sich als Interrupt für steigende und fallende Flanke konfigurieren. Bei jeder Flanke von Signal A oder B wird die Interrupt Service Routine gestartet und die Drehung ausgewertet.
[right:abd365b507]http://1.bp.blogspot.com/_qPTJUGegS5w/SW98EhOdfNI/AAAAAAAAAHs/1M6r8rg5IF8/s320/DSC01080_filtered.jpg[/right:abd365b507]
Die Rechnung:
Da ich mich schon einige male verrechnet habe wollte ich euch bitten über meine Rechnung zu schauen. Meist hilft es ja schon, wenn man es ausführlich hinschreibt.
Die Schlitzscheibe hat 32 schwarze Felder. Bei jedem Feld werden 4 Flanken erzeugt (steigend, fallend Lichtschranke A und steigend, fallend Lichtschranke B). Der Motor macht bis zu 5000 Upm.

Bild hier  

Es werden also fast 11 tausend Interrupts pro Sekunde erzeugt. Der µC läuft deswegen mit 20Mhz und soll dabei zwei Motoren auswerten können (erst mal reicht einer).

Bild hier  

Zwischen jedem Interrupt können also 1875 Maschienenbefehle ausgeführt werden. Nun hängt es von der ISR ab, wie viele Maschinenbefehle sie braucht und wie viele für andere Programmaufgaben übrig bleiben.

Die ISR
Die Interrupt Service Routine erzeugt zwei Werte die zum Test alle 100ms über UART ausgegeben werden.

public volatile long lEncoder;
public volatile long lError;

ISR(PCINT0_vect)   
{   
// lookup table   
 static const int8_t aSteps[] = { 0, -1, 1, ENC_INV, 1, 0, ENC_INV, -1, -1, ENC_INV, 0, 1, ENC_INV, 1, -1, 0 };   
 int8_t iStep = 0; // Schrittweite des Motors   
  
 // alte Phase um zwei Bit nach links verschieben   
 bPhase.bRow = (bPhase.bRow << 2);   
 // alles ausser a und b löschen   
 bPhase.bRow &= 0x0C;    // 0000 1100 = 0x0C   
 // Signal A einlesen   
 bPhase.x.Signal_A = IS_SET_MOT1_SIG_A ? true : false;   
 // Signal B einlesen   
 bPhase.x.Signal_B = IS_SET_MOT1_SIG_B ? true : false;   
  
  // Schrittweite aus Tabelle auslesen   
 iStep = aSteps[bPhase.bRow];   
 if (iStep != ENC_INV)   
 {   
  lEncoder += iStep;   
 }   
 else  
 {   
  lError++;   
 }   
}

Das Problem:
Wenn ich jetzt die Geschwindigkeit des Motors über 2000Upm hoch drehe kommen immer mehr Fehler (lError steigt), bis keine Auswertung mehr möglich ist. Ist der µC zu langsam für die Aufgabe? Oder kann man ihn noch etwas endlasten, wir ISR in Assembler oder Vorteiler?

Vielen Dank schon mal für eure Mühe
Guß Xaver

[ranke]

Einen offensichtlichen Fehler kann ich nicht erkennen, zumal man ja sieht, dass hier mit Bedacht und Sorgfalt gearbeitet wird.
Wonach ich in dieser Situation suchen würde:

1. Für die Reflexlichtschranke habe ich auf die schnelle keine Daten gefunden. Oft ist es im Ausgangsteil nur ein Fototransistor dessen Kollektor mit einem Widerstand an Plus gelegt wird. Eine solche Schaltung ist für höhere Frequenzen (steile Flanken) wenig geeingnet. Möglicherweise wird das Signal bei höheren Frequenzen derart verschliffen, dass die Interrupt-Schaltpunkte des uC nicht mehr erreicht werden, oder dass zufällige Störungen, die sich eingeschlichen haben, relevant für den Schaltpunkt werden.

2. Dein Rechenergebnis mit 1875 Instruktionen zwischen zwei Interrupts ist nur gültig, wenn die erzeugten Flanken der Lichtschranken genau symetrisch sind. Das sind sie in der Praxis natürlich nicht. Es kann also wesentlich knapper werden. Möglicherweise zu knapp. Eine mechanische Instabilität (z.B. Eigenfrequenz der Schlitzscheibe) könnte die Schaltpunkte auch zusätzlich verschieben, indem der Abstand Schlitzscheibe - Fototransistor nicht konstant bleibt.

3. Störungquellen über die Betriebsspannung, Motorzuleitungen etc. hast Du wahrscheinlich schon beseitigt (durch getrennte Leistungsversorgung von Motor und Elektronik, Entstörkondensatoren direkt am Motor, räumliche Trennung von Motor- und Meßleitungen).

[PicNick]

Würde auch überlegen, ob du überhaupt jede Motordrehung 32-mal messen mußt.
Wie weit bewegt sich denn der Robot bei einer 1/32 Motordrehung ?

[pongi]

Eine viel ressourcensparendere Möglichkeit wäre, die Impulse mit einem Timer zu zählen. Die Atmegas haben Timer, die extern getriggert werden, auf diesen Eingang legst du dann dein Signal an. Dann stellst Du einen Interrupt ein, der auslöst, wenn dieser Timer überläuft. Einen anderen Timer benützt du für die Zeitmessung.
Vorgangsweise:
-beide Timer starten bei 0, Timer1 wird extern getriggert, Timer2 über den Clock
-wenn Timer0 einen Überlauf hat, schaust du dir die verstrichene Zeit an, aus der Zeit und der bekannten Anzahl der Impulse kannst Du auf die Geschwindigkeit schliessen.
-ein Überlauf von Timer1 muss noch gehandelt werden, eigentlich hast du beim Überlauf von Timer1 auch eine Geschwindigkeit, denn da hast die fixe Zeit, und die Anzahl der Impulse kannst Du auslesen.

Wenn nicht genug Timer mit externer Triggerung vorhanden sind, könnte man vielliecht die Interruptroutine so verändern, dass in der Routine selbst nur eine Variable bei jedem Impuls erhöht wird (Software-Zähler). Nach einer bestimmten Zeit (Timer) wird dann die Anzahl der Impulse ausgewertet.

Weiter ist zu bedenken, (wie es schon Picknick geschrieben hat), ob eine solche Auflösung generell notwendig ist, denn wenn noch ein Getriebe nachgeschalten ist, ist die Auflösung am Rad definitiv viel zu hoch.

MfG

pongi

[oberallgeier]

Hi Xaver,

... Probleme mit ... Encodern ...

Mehrere Dinge verstehe ich nicht.

Gut, ich habe (noch) kein invertierendes Pendel aufgebaut, aber ich weiß, dass hier eine gute Auflösung benötigt wird. Mit meinen kleinen Gabellichtschranken löse ich eine Größenordnung weniger auf - 1500 Hz, allerdings wird bei mir nur (?) auf steigende Flanke getriggert. Die entsprechende Regelung läuft hervorragend.

Als Denkfehler sehe ich an, dass Du direkt am Motor die Drehzahl erfasst >>>um das Lagerspiel auszublenden<<<. Ok, dann regelst Du den Motor - und kannst bei genügend guter Auflösung innerhalb des Lagerspiels regeln - dabei bleiben die Räder stehen *ggggg* und nur das Getriebe ruckelt hin und her, bei 1:100 schon eine denkbare Geschichte. Das bringts doch nicht!

... Dies sollte die größte Messgenauigkeit und schnellste Erfassung der Motoren ergeben, da das Lagerspiel nicht mit erfasst wird...

Wenn ich ein invertierendes Pendel aufbaue, würde ich erstmal auch nicht den Motor bzw. das Getriebe auf seine Abtriebsdrehzahl regeln (und schon garnicht ohne das Getriebespiel in die Regelung einzubeziehen), sondern eine Lageregelung aufbauen ungefähr so: kippt links => Motor rechts, kippt rechts => Motor links. Aber das ist ja DEIN Projekt.

Sehen wir doch mal, was die Regelung theoretisch bringt. Da Du keine Angabe über die Getriebeübersetzung machst, nehme ich versuchsweise an, dass Du ein Getriebe 1:100 hast. Du könntest also (nach Deinen Angaben: 32 Felder x 4 Flanken) über 12.000 ticks pro Radumdrehung auflösen (32 x 4 x 100). Geschätzter Raddurchmesser nach Deinem Blog-Bild: 60 mm => Auflösung theoretisch 15 tausendstel Millimeter (0,016). Wenn ich ohne Hemmungen sprechen darf: da vermute ich, dass das Unsinn ist - sorry - also: Frage: ist das nicht etwas hochgestochen? Wie mehrfach angedeutet: das Getriebespiel ist damit NICHT vom Erdboden - und es ist ausserhalb des angestrebten Regelkreises.

... Ein Schmitttrigger säubert die Signale für einen µC ...

Uuuuups - wusste garnicht, dass ich soooo schlampig arbeite: meine Gabellichtschranke geht mit einem nicht allzu kurzen Kabel - entlang der PwM-versorgten Motorzuleitung - ohne sonstwas zum µC. Störungen: nicht erkannt. Dein Aufbau ist ja vermutlich sehr sauber - aber ist das notwendig/erforderlich?

So, das waren nur meine ersten Eindrücke - die helfen Dir vermutlich garnicht. Also brauchen wir noch einen Rat:

Rat 1:

... Die Interrupt Service Routine erzeugt zwei Werte die zum Test alle 100ms über UART ...

Datenübertragung in einer ISR (? - wirklich in der ISR - oder doch ausserhalb?) von DER Frequenz. Junge Junge! Rechne mal den Zeitbedarf für die Datenübertragung. Oder - einfacher - schalte mal diese Datenübertragung ab und teste Deine Lichtschranke (Daten im Test abspeichern und offline übertragen).

Rat 2:
Lichtschranke 1 auf INT0, Lichtschranke 2 auf INT1. Triggern auf steigende Flanke. Nachteil: es könnte sein, dass Du so die Drehrichtungsumkehr schlechter mitbekommst. Vielleicht könntest Du nach dieser Methode aber erstmal das Ding nach Deinem Konzept zum Laufen bekommen - ist ja nur die halbe Interruptfrequenz.

Viel Erfolg - oder viel Glück

[pongi]

An der Uni musste ich auch eine Regelung für ein Doppelpendel entwerfen. Ich habe mich damals für eine absolute Messung des Winkels am Gelenk entschieden. Damit hats dann sehr gut funktioniert. Vielleicht überdenkt ihr das Konzept nocheinmal.

[oberallgeier]

In diesem Bericht wird (ebenfalls) über Messfehler beim Auslesen der Encoder berichtet, die nicht bereinigt werden konnten.

[Xaver]

Vielen Dank schon mal für eure Hilfe.

@ranke: Wie ich gerade sehe, gibt es diese sehr kleinen Lichtschranken (4x5x5mm) leider bei Pollin nicht mehr. Im Datenblatt wird eine Reaktionszeit von 10µs versprochen, was 100kHz entspricht. Sollte also reichen. Ich kann aber leider nicht überprüfen wie sehr die Signale verschiffen werden, daher habe ich ja auch einen Schmitt-Trigger dahinter geschaltet. Die Hysterese sollte die Signale wieder verbessern.
Diesen Punkt werde ich aber sicher anschauen, wenn ich ein Oszi finde.
Das mit den nicht symmetrischen Flanken war mir auch bei meinen ersten Versuchen aufgefallen. Die Scheibe ist sicher nicht ganz eben und eiert ein ganz wenig. Auch ist es nicht leicht nur mit bloßem Auge die Lichtschranken an der Scheibe auszurichten. Ich dachte aber, dass dies kein Problem sei und nur die Dauer einer Periode zählt. Die Signalverläufe von A und B sind nur etwas verschoben, so dass zwei Flanken dicht hintereinander kommen und dann eine längere Pause ist.
Kommen zwei Flanken dicht hintereinander, so wird bei der ersten, die ISR angestoßen und bei der zweiten der Interrupt zwar gesetzt, aber erst im Anschluss an die erste ISR bearbeitet. Dann liegen die Signale ja immer noch an und sollten daher auch richtig verarbeitet werden. Der dritte Interrupt kommt wieder ganz normal.

@pongi
Leider habe ich nicht so viele Timer in µC. Einen verwende ich bereits für die PWM, ein zweiter ist für periodische Abfragen (mach alle 100ms etwas) und die Uhrzeit zuständig. Der letze Timer wird wohl ein RC-Signal von einer Fernsteuerung auswerten und im Moment mache ich ja eigentlich auch nichts anderes als bei jedem Interrupt einen Zähler hochzusetzen und alle 100ms nachzuschauen welchen Wert dieser hat.

@oberallgeier
Noch ist unser Robi kein Pendel und er fährt ganz „normal“ mit Stützrad. Für die Regelung der Motoren ist es auch gar nicht von so großer Bedeutung, außer die nötige Reaktionszeit und die häufigen Richtungswechsel. Daher soll bei der Motorregelung dieses ja mit bedacht werden. Durch die häufigen Richtungswechsel müssen also beide Flanken ausgewertet werden, sonst gehen Richtungswechsel verloren. Naja und je schneller, desto besser.
Das mit dem Lagerspiel habe ich ehrlichgesagt gar nicht richtig bedacht und du hast absolut recht, das es keinen Sinn macht die Motordrehung hoch genau zu messen, um hinterher das Lagerspiel auszuregeln.
Nun denn, ich habe eine Getriebeübersetzung von 1:40 und Reifen mit einem Umfang von 31cm.
Bild hier  
Hmm, 0.07° Auflösung nach dem Getriebe, das ist ja echt verdammt wenig. Dann würde ich ja auch 0,06 mm Strecke messen können. Also mit Panzern auf Spatzen schießen kann man als Vergleich ruhig heranziehen.
Die Übertragung der Daten wurde aber nicht in der ISR, sondern im Hauptprogram gemacht.

Ziel war es eigentlich die Regelung der Motoren alle 10 ms durchführen zu können. Das schnellst was wir geschafft haben waren aber 20ms mit Fehlern. Wir haben mal das ganze in einem Diagramm aufgezeichnet. Der Motor ist ohne Belastung angeschlossen. Der Sollwert (grüne Linie) wird immer weiter erhöht, bei 255 gehalten und dann auf 0 gesetzt. Die lila Linie zeigt die Drehzahl des Motors in Flanken/20ms, wobei gut zu sehen ist, dass der Motor am Anfang noch etwas steht und sich dann der Solllinie nähert. Ab etwa 210Flanken/20ms (etwa 4900 upm) steigt der Fehlerzähler und die wirkliche Drehzahl wird nicht mehr richtig gemessen.

Fazit
Ich werde also die Schlitze auf 16 halbieren und die Regelung verlangsamen.

[oberallgeier]

Hallo Xaver,

schön, dass wir da einer Meinung über sinnvolle Genauigkeit (bzw. über Spatzen und Kanonen) sind.

... Ziel war es eigentlich die Regelung der Motoren alle 10 ms durchführen zu können ...

Bei meinem Dottie wird mit 405 Hz geregelt: da gibts ne Schaltfrequenz in meinem Aufbau, die allerlei macht - u.a. einen ADC auslesen. Der wird über 12 "Lesungen" gemittelt. Es lag nahe, in der Lesung 4 und 8 die Regelung laufen zu lassen - und in 12 rechne ich eben die ADC-Statistik. Langsamer regeln wäre mir egal gewesen - nur passte es eben so rein. Überrascht war ich eigentlich auch nicht, dass die integer-Regelung so exakt läuft (hab ich schon mal an einer ziemlich grossen Maschine ähnlich gemacht). Zumal meine Drehzahlmessung den "Überhang" an Zeit bei einer abzuwartenden Interruptbedienung dem nächsten Messwert zuschlägt. Da geht mir praktischerweise nix verloren. Bei der Geschwindigkeit von Dottie ist das, genaugenommen, (auch) mit Kanonen . . . das hatten wir ja gerade.

Ach so - die kleinen Gabellichschranken: ich verwende die GP1S096HCZ von Sharp - 2,9 mm x 2,6 mm x 3,5 mm, gekauft bei CSD für etwas über 1/2€. Bestellnummer 20836.

[ranke]

Im Datenblatt wird eine Reaktionszeit von 10µs versprochen, was 100kHz entspricht. Sollte also reichen. Ich kann aber leider nicht überprüfen wie sehr die Signale verschliffen werden, daher habe ich ja auch einen Schmitt-Trigger dahinter geschaltet. Die Hysterese sollte die Signale wieder verbessern.

Hierzu noch ein paar schnelle Gedanken:

Bei der Berechnung der maximalen Frequenz verwechselst Du Anstiegszeit und Periodendauer. Fig. 7 und 10 des Datenblatts geben eine genauere Einsicht in die Anstiegszeit. Es ist also problemlos möglich Anstiegszeiten von deutlich über 100 us zu erreichen. Das Ganze wurde ohne kapazitive Last gemessen, diese ist in der Realität immer vorhanden, es könnte also doch kritisch werden.

Noch eine Überlegung zur Gleichspannungsanpassung des Fototransistors zum nachgeschalteten Schmitttrigger:
Bei höheren Frequenzen wird die Ausgangsspannung des Fototransistors - bedingt durch die endliche Anstiegszeit - erst trapezförmig, dann dreieckig, und mit zunehmender Frequenz nimmt die Amplitude des Dreiecks ab.
Durch die abnehmende Amplitude könnte es passieren, daß die Wechselspannung irgendwann nicht mehr die beiden Schaltschwellen des Schmitttriggers überstreicht.
Theoretisch sollte man dadurch einen schlagartigen Ausfall der entsprechenden Lichtschranke erwarten, in der Praxis werden (z.B. wegen mechanischer Toleranzen) immer erst einzelne Flanken verloren.

Kommen zwei Flanken dicht hintereinander, so wird bei der ersten, die ISR angestoßen und bei der zweiten der Interrupt zwar gesetzt, aber erst im Anschluss an die erste ISR bearbeitet. Dann liegen die Signale ja immer noch an und sollten daher auch richtig verarbeitet werden. Der dritte Interrupt kommt wieder ganz normal.

Da hast Du recht, ich hatte nicht bedacht, dass man Interruptroutinen verschachteln kann.