ESP Zeit messen, immer wieder Ausreißer

[Kolja L. (kolja82)]

Hallo

An einem Getriebemotor ist ein endlos drehbares Poti angeschlossen.
Über den analogen Eingand wird die Spannung gemessen und immer wenn 
diese plötzlich abfällt eine Runde gezählt.
Strom bekommt der Motor immer in kurzen Impulsen, so lange wie der ESP 
für 50 analoge Messungen benötigt, dann pausiert er für 100ms.

Ausgeben lasse ich mir die Rundenzeit und die Anzahl der Schritte die 
für eine Runde notwendig waren.

Eigentlich ganz einfach, aber die Werte haben komische Ausreißer:

ȤlìÉã¬l,øi:ðøready!
Rundenzeit: 24340
Schritte: 217
Rundenzeit: 47594
Schritte: 429
Rundenzeit: 71934
Schritte: 413
Rundenzeit: 45923
Schritte: 45923
Rundenzeit: 45278
Schritte: 408
Rundenzeit: 627097712
Schritte: 416
Rundenzeit: 46277
Schritte: 417
Rundenzeit: 45814
Schritte: 413

Und hier mal der Code:

int servo = D2;
int power = D1;
int readpin = A0;
int marker = 0;
int runde = 0;
int steps = 0;
int step_ist = 1;
unsigned long zeit_0 = 0;
unsigned long zeit_2 = 0;
unsigned long zeit_1 = 0;
int rundenzahl = 0;
int runden_zeit = 0;
int wert1 = 0;
int wert2 = 0;
int rundenzeiten[3];
int j;
void setup()
{
  //  ESP.wdtDisable();
  Serial.begin(9600);
  pinMode(servo, OUTPUT);
  pinMode(power, OUTPUT);
  digitalWrite(power, HIGH);
  pinMode(readpin, INPUT);
  Serial.setDebugOutput(true);
  Serial.println("ready!");
}

void loop()
{
  digitalWrite(servo, HIGH);



  for (int i = 0; i <= 50; i++)
  {
    if (analogRead(A0) > 1000)
    {
      marker = 10;
    }
    if (analogRead(A0) < 1000 && marker == 10)
    {
      j++;
      rundenzeiten[j]=(millis() - zeit_0);
      Serial.print("Rundenzeit: ");
      Serial.println(millis() - zeit_0);
      Serial.print("Schritte: ");
      Serial.println(steps);
      zeit_0 = millis();
      marker = 0;
      steps = 0;
    }
  }
  digitalWrite(servo, LOW);
  delay(100);
  steps++;




}

[Wolfgang (Gast)]

Kolja L. schrieb:
> Ausgeben lasse ich mir die Rundenzeit und die Anzahl der Schritte die
> für eine Runde notwendig waren.

Dann lass dir doch mal zeit_0 und alle drei Zeiten ausgeben, die du für 
deine Rundenzeitberechnung verwendest, also die Ergebnisse aller drei 
Abfragen von millis(), die du jede Runde machst. Damit hast du eine gute 
Chance, rauszufinden, was da schief läuft. Und denke dran: millis() 
liefert einen unsigned long Wert.

[Wolfgang (Gast)]

p.s.
Den Wert von j solltest du bei der Gelegenheit zur Kontrolle gleich mit 
ausgeben lassen ;-)

[Frank (Gast)]

Kann man so machen, würde ich aber nicht.
Bilde doch in deiner Mess-Schleife eine Pseudogeschwindigkeit.
Immer beim Übergang des Potis von Max zu Min gibt es dann einen großen 
Sprung.
Dann weist Du dass es eine neue Umdrehung war.
Ausgaben in zeitkritischen Stellen ist auch immer ziemlich schlecht.

void loop()
{
  abbort = false;
  
  digitalWrite(servo, HIGH);
  oldX    = analogRead(A0); //Damit beim ersten Diff annaehernd 0 rauskommt
  oldTime = millis();       //Zeit beim Start merken
  
  while(!abbort)
  {
    newX  = analogRead(A0); //Neuen Wert vom ADC holen (Position 1)
    diffX = newX - oldX;    //Pseudogeschwindigkeit bilden (deltaWeg/deltaZeit) fuer deltaZeit=1 Schleifendurchlauf
    oldX  = newX;
    newTime = millis();     //Aktuelle Zeit holen
    steps++;                //Schleifenzaehler
    
    if (diffADC > MAXVELOCITY)  //evtl Betrag bilden fuer Links/Rechtslauf
    {
        //Neue Runde detektiert
        //Motor ausschalten
        digitalWrite(servo, LOW);
        abbort = true;
        Serial.print("Rundenzeit: ");
        Serial.println(newTime - oldTime);      
        Serial.print("Schritte: ");
        Serial.println(steps);
    }
    else if( (steps > MAXSTEPS) || ((newTime - oldTime) > MAXTIME) )
    {
        //Motor ausschalten
        digitalWrite(servo, LOW);
        //Timeout oder bzw. Anzahl Steps (fast das gleiche) ueberschritten
        Serial.print("TIMEOUTERROR!!!");
        while(1)
        {
        //Tu was Sinnvolles
        }
    }
    
  }
//Theoretisch wuerde ich noch die Ausgabe aus
//der Schleife ziehen und außerhalb durch einen Status
//o.ä. die Ausgabe machen.
//Dann kannst Du hier noch wenn Du willst eine Differenation und
//Normierung machen und die Geschwindikeit in RPM ausrechnen.
  delay(100);
}

[Kolja L. (kolja82)]

Nabend

Mein Rechner spinnt gerade total, ich muss da leider erst dran...

Danke für dein Codebeispiel.
So ganz habe ich es noch nicht verstanden und auch noch nicht getestet.
Aber das mit der Ausgabe in den zeitkritischen Bereichen kann ich 
nachvollziehen.

Im Anhang mal ein Bild von zwei Runden des Motors.
Also nur den A0 ausgelesen.

Ziel ist eine relativ genaue Positionierung des Motors.
Im eigentlichen Bereich des Potis (Steigung) ist es ja kein Problem.
Wenn eine Position außerhalb angesteuert werden soll, sollte es wie 
folgt laufen:

Der Motor dreht sich 2 volle Umdrehungen und misst die Rundenzeit.
Daraus errechnet der µC sich die Zeit von einer markanten Stelle 
(Senkrechte)
bis zur Soll-Position.
Die Steps in dem o.g. Code habe ich eingeführt,
um den Bremsweg herauszunehmen und um dem Weg zu einer Position einfach 
Schritte zuordnen zu können.

Aber vielleicht gibt es ja andere / bessere Wege?

Danke und Gruß

Kolja

[Frank (Gast)]

War das mit der Hand gedreht?
Oder mit einer konstanten Drehzahl?

Wenn das nämlich mit konstanter Drehzahl gedreht war, werden dir die 2 
Stellen wo sich nichts ändert die meisten Probleme machen.

Wenn du hingegen einen annähernd sauberen Sägezahn pro Motorumdrehung 
raus bekommst, hast du ja einen linearen Zusammenhang zwischen 
Motorposition und Spannung am ADC.

[Stefan F. (Gast)]

> Aber vielleicht gibt es ja andere / bessere Wege?

Einen vernünftigen Sensor nehmen, zum Beispiel optisch wie beim Asuro 
http://www.cs.hs-rm.de/~linn/vpdv07/asuro3/asuro-website/images/rad_asuro.JPG 
oder mit einem Hall-Sensor.

Es hindert dich ja auch niemand daran, zwei Sensoren zu verwenden. Einen 
für die kleinen Teilschritte und einen, um die Ausgangslage zu 
markieren. Die meisten Tintenstrahldrucker und Aufzugtüren machen das 
auch so - kann also keine schlechte Idee sein.

Dein Poti wird ohnehin nach einigen tausend Umdrehungen kaputt gehen, 
aber das hatten Wir dir ja schon vor ein paar Wochen erklärt.

[Kolja L. (kolja82)]

Nicht mit der Hand, sondern durch den Getriebemotor.
Völlig konstant ist die Winkelgeschwindgkeit wohl nicht,
aber das gilt es jetzt herauszufinden.

Und ja, die 3(!) Ebenen machen mir ja die Sorgen.
Im ersten Teil sind es einmal Werte um 5 und dann Werte um 10.
(So in etwa...)
Jeder Wechsel von 5 auf 10 auf Steigung auf 1000 auf 5 kann ja als 
Marker genutzt werden.

Mir geht es endgültig nicht darum die Anzahl der Runden zu zählen,
sondern eine Position zwischen 0° und 359° anzufahren.

[Kolja L. (kolja82)]

@Stefan
Auch hatte ich schon mal gesagt, dass leider kein Platz für einen 
weiteren Sensor vorhanden ist.
Das Poti gegen eine Drehencoder tauschen würde gehen, aber die gibt es 
ja nicht mit <100 Steps.

[Frank (Gast)]

Kolja L. schrieb:
> Das Poti gegen eine Drehencoder tauschen würde gehen, aber die gibt es
> ja nicht mit <100 Steps.

Gibt es schon:
http://roboter-teile.shopgate.com/item/454d473330
Wenn du da nur die positive Flanke einer Spur nimmst, hast du 360/4 = 90 
Striche pro mech. Umdrehung.

Auf Dauer ist das wie schon gesagt nichts mit dem Poti. Der geht 
wahrscheinlich ziemlich schnell hinüber und/oder ändert seine Funktion 
abhängig vom Abnutzungsgrad.

Für was willst du denn den Motor positionieren können?
Sprich, was für eine Anwendung steckt dahinter?

[Frank (Gast)]

Bei dem angegebenen Encoder musst du halt auf null referenzieren. Bist 
also nur relativ. Nicht absolut.

[Kolja L. (kolja82)]

Der Verlinkte Motor ist etwas zu schwach.
Wir haben hier Modellbauservos mit ca 10kgcm.

Daher darf ein möglicher Encoder auch nicht so groß sein.
Ein Mehrgangpoti mit knapp 200 Durchmesser passt definitiv nicht...

Die Anwendung ist eine Ventilsteuerung.
Auf das Servohorn kommt eine Nuss (13mm) und dann wird es anstatt dem 
Hahn auf das Ventil montiert.

Gruß Kolja

[Kolja L. (kolja82)]

Relativ reicht, da wir die Absolute Position gar nicht wirklich 
benötigen.

[Frank (Gast)]

Kolja L. schrieb:
> Relativ reicht, da wir die Absolute Position gar nicht wirklich
> benötigen.

Also auch nicht Singleturn absolut?
Wie genau musst du denn eine Umdrehung auflösen können?

[Kolja L. (kolja82)]

Für meine Begriffe, ist singelturn absolut doch relativ,
oder wie definierst du das?

Als Auflösung wären 5° schon toll.
Im o.g. Serial Output sind es ca 400 Schritte pro Umdrehung,
so viel muss nicht.

Kannst du deine Idee mit der Pseudogeschwindikeit noch mal erläutern?
Oder Passt das nicht wegen den waagerechten Bereichen?

Danke und Gruß

[Frank (Gast)]

Kolja L. schrieb:
> Für meine Begriffe, ist singelturn absolut doch relativ,
> oder wie definierst du das?

Es gibt inkrementelle Geber. Wie der von mir oben verlinkte.
Die auswertende Elektronik wacht auf und weis erst mal nicht wo sie 
überhaupt steht. Sie hat keine absolute Winkelposition pro 
Motorumdrehung.
Deshalb muss der Motor erst gegen einen Referenzpunkt fahren. Jetzt weis 
die auswertende Elektronik, dass sie bei der mechanischen Position 0° 
ist und kann über das Zählen der Impulse relativ verfahren. Schaltet man 
die Elektronik ab, fängt das Szenario mit der Referenzierung wieder 
komplett von vorne an.

Dann gibt es Singelturn Absolut Geber. Wie z.B. ein Resolver. Mit ihm 
kann man (wenn er mechanisch einmalig richtig eingestellt wurde) die 
Motorposition innerhalb einer Motorumdrehung absolut bestimmt werden. 
Die auswertende Elektronik kann die Überläufe der mechanischen Umdrehung 
mitzählen und somit auch auf mehrer Umdrehungen genau die Position 
bestimmen. Schaltet man allerdings die Elektronik ab und verdreht den 
Motor, weis die Elektronik nur die Motorlage. Nicht aber die 
Multiturninformation Der Motor kann ja während dem Ausschalten verdreht 
werden ohne dass es die Elektronik mitbekommt.

Dann gibt es noch die Multiturn Geber. Sie haben meist noch ein internes 
Getriebe und können nach dem Aufwachen sofort die Multiturninformationen 
liefern (innerhalb eines Gewissen Wertebereichs).

Das was Du also scheinbar benötigst ist entweder einen Inkrementalgeber 
mit einem Referenzpunkt, oder einen Singelturn Absolutwertgeber.

[Kolja L. (kolja82)]

Also mir reicht es, wenn ich immer einen definierten Schritt vorwärts 
drehen kann und es möglich ist den letzten Wert auch wieder anzufahren.
Das wäre am einfachsten zu erreichen, wenn der Motor rückwärts laufen 
würde,
aber dann brauche ich einen Motortreiber.
Außerdem ist ein Linkslauf wegen der Montage auf dem Ventil ungünstig, 
da diese sich dann lösen könnte.
Daher ist mein Schritt zurück, alle Schritte - einer vorwärts.

[Frank (Gast)]

Kolja L. schrieb:
> Kannst du deine Idee mit der Pseudogeschwindikeit noch mal erläutern?

Ich dachte Du willst nur ganze Umdrehungen zählen. Dann hätte es bei 
absichtlich falsch angewandter Subtraktion immer einen schönen Pikser 
bei jeder Umdrehung in der Geschwindigkeit gegeben (siehe Anhang 
Optimal.png).

Im gleichen Bild sieht man auch, wie das Signal optimaler Weise aussehen 
würde. Ein schöner Sägezahn. So hättest Du dann jeder Spannung einen 
Winkel zuordnen können:
0V = 0°
1V = 359°

Durch die Stellen wo Du aber keine Steigung hast (siehe rote 
Markierungen in Bild ServoPoti.jpg) bekommst Du keine weiteren 
Informationen. Sprich, es gibt Bereiche die Dein Motor durchfährt, indem 
Du keinen aktuellen Winkel feststellen kannst. Im Prinzip ist an der 
Stelle Deine Regelung blind.
Wenn Du nun genau in so einen Bereich positionieren willst, wird dein 
Regler immer zwischen diesen Stellen toggeln. Er versucht die Position 
zu erreichen. Fährt hinein, die Position ändert sich aber nicht. 
Irgendwann kommt wieder eine Position, aber zu groß. Scheiße, der Regler 
denkt sich wieder da drehe ich mal um. Dann fährt er wieder in die 
andere Richtung, bekommt aber wieder keine aktuelle Position...usw. usw.

[Kolja L. (kolja82)]

Danke für die ausführliche Hilfestellung!

Das Sketch soll erst drei Runden fahren.
Eine Runde bedeutet das überschreiten eines eindeutigen Punktes.
ich habe es mit dem Marker gemacht (wenn größer 1000 wird er gesetzt und 
wenn der Wert dann wieder unter 1000 fällt, ist der eindeutige Punkt 
gefunden.)
Du machst das über die Pseudogeschwindigkeit (hab ich jetzt verstanden, 
gute Idee)
Da die erste Runde keine vollständige ist (meistens jedenfalls) wird 
diese vernachlässigt und nur aus den benötigten Schritten von Runde 2 
und 3 der Mittelwert gebildet.

Dann wollte ich schauen, wie gut ich damit einzelne Positionen anfahren 
kann.

Wenn das reicht (wovon ich nicht ausgehe) ist gut,
wenn nicht, muss ich mir weitere eindeutige Punkte suchen.
Vielleicht finde ich die ja auch über die Pseudogeschwindigkeit,
was ja eigentlich die Steigung ist.

Dann könnte man immer von dem letzten überfahrenden Punkt anfangen die 
Steps zu zählen.

Ein Poti, welches ein so schönes Bild macht, wie du in deinem Zweiten 
dargestellt hast,
kann es mechanisch leider nicht geben.
Einen kleinen Totbereich gibt es immer...

[Kolja L. (kolja82)]

Steigung ist natürlich nicht richtig, da subtrahiert und nicht dividiert 
wird...

Lieder habe ich jetzt wieder Probleme mit

Soft WDT reset

ctx: cont 
sp: 3ffef980 end: 3ffefb80 offset: 01b0

>>>stack>>>
3ffefb30:  3ffe83c8 3ffeea58 00000000 40202548  
3ffefb40:  3ffeea54 feefeffe 3ffeeb34 40202fcc  
3ffefb50:  3fffdad0 3ffe8374 3ffeeb34 3ffeeb58  
3ffefb60:  3fffdad0 00000000 3ffeeb51 402028a0  
3ffefb70:  feefeffe feefeffe 3ffeeb60 40100114  
<<<stack<<<

und muss erts das lösen...

[Frank (Gast)]

Kolja L. schrieb:
> Vielleicht finde ich die ja auch über die Pseudogeschwindigkeit,
> was ja eigentlich die Steigung ist.

Kolja L. schrieb:
> Steigung ist natürlich nicht richtig, da subtrahiert und nicht dividiert
> wird...

Steigung und Geschwindigkeit ist beides richtig.
Die Differenziation bzw. "Steigung" der Position bezogen auf die Zeit 
ist ja gerade die Geschwindigkeit.

Ich hatte nur, um nicht dividieren zu müssen, auf die Zeitdifferenz 1 
normiert.

$$m = \frac{\Delta y}{\Delta x} = \frac{y_2-y_1}{x_2-x_1}=\frac{newX-oldX}{1-0} = newX-oldX = v[Positionsänderung/1]$$

[Kolja L. (kolja82)]

Jup, Ableitung des Weges nach der Zeit, so hieß dass doch damals.
Das /1 hatte ich übersehen.

[Frank (Gast)]

Ein "ä" mag er natürlich nicht:

$$m=\frac{\Delta y}{\Delta x}=\frac{y_2-y_1}{x_2-x_1}=\frac{newX-oldX}{1-0}=newX-oldX=v[Positionsaenderung/1]$$

[Kolja L. (kolja82)]

Der ist aber auch zimperlich beim interpretieren ;-)

Ich glaub mein Rechner stürzte wegen des defekten BT Modules immer ab.
Jetzt ist es raus :-)