www.mikrocontroller.net

Forum: Compiler & IDEs Linefollower: I-Anteil wählen


Autor: Andy S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich habe jetzt meinen Roboter soweit aufgebaut, dass er mit einem 
P-Regler eine Dauerschwingung auf einer Geraden schafft.
Jetzt haut er mir aber ab und zu bei stärkeren Kurven ab oder auch wenn 
ich den P-Anteil hochdrehe.

DIe Ansteuerung der Motoren erfolgt momentan über den Motortreiber L6205 
durch Kurzschließen der Motoren über PWM.
Die Betriebsspannung, die kurzgeschlossen wird über den Treiber beträgt 
8V und soll dann später auf 14,8V erhöht werden. Zur Kühlung des 
Treibers dient ein sehr großer CPU Kühler. Ohne Kühler ist aber noch 
dazu zu sagen, dass ich die Motoren Leeralufen lassen muss, da der 
Kurzschlussbetrieb den Treiber zu stark erhitzt.

Ich habe natürlich dank des Display Menüs, das am ROboter drauf sitzt 
immer wieder einen I Anteil dazugegeben, jedoch macht er dann nicht das 
was er soll, sondern bei sehr hohen Ki irgendwas und bei sehr kleinen Ki 
reagiert er zwar auf die Kurve aber entweder verspätet oder auch 
irgendwie.

Ich rechne den I-Anteil folgendermaßen dazu:
esum = esum + e
y = Kp * e + Ki * Ta * esum

laut dieser Homepage:
http://www.rn-wissen.de/index.php/Regelungstechnik

Mein aktueller (noch nicht idealisierten ALgorithmus) sieht zur Zeit so 
aus:
//Vorwärtsrichtung

  //Main-Loop:*********************************************************************
  while(!cancel_mode)
  {
    if( PORTC & (1<<PC0) )
      LED_AUS
    else
      LED_EIN

    //BEARBEITER SENSOREN UND REGELDIFFERENZ############################
    //lese Sensorwerte ein
    sensorL0 = GetADC_8bit(0);
    sensorL1 = GetADC_8bit(1);
    sensorL2 = GetADC_8bit(2);
    sensorL3 = GetADC_8bit(3);
    sensorR0 = GetADC_8bit(4);
    sensorR1 = GetADC_8bit(5);
    sensorR2 = GetADC_8bit(6);
    sensorR3 = GetADC_8bit(7);

    if( (sensorL0 > sensorL2) && (sensorL1 > sensorL2) )
      differenz = 250 + (sensorL0*100) / (sensorL0+sensorL1);
    else if( (sensorL1 > sensorL3) && (sensorL2 > sensorL0) && (sensorL1 > sensorL0) && (sensorL2 > sensorL3) )
      differenz = 150 + (sensorL1*100) / (sensorL1+sensorL2);
    else if( (sensorL2 > sensorR0) && (sensorL3 > sensorL1) && (sensorL2 > sensorL1) && (sensorL3 > sensorR0) )
      differenz = 50 + (sensorL2*100) / (sensorL2+sensorL3);
    else if( (sensorL3 > sensorR1) && (sensorR0 > sensorL2) && (sensorL3 > sensorL2) && (sensorR0 > sensorR1) )
      differenz = -50 + (sensorL3*100) / (sensorL3+sensorR0);
    else if( (sensorR0 > sensorR2) && (sensorR1 > sensorL3) && (sensorR0 > sensorL3) && (sensorR1 > sensorR2) )
      differenz = -50 - (sensorR1*100) / (sensorR1+sensorR0);
    else if( (sensorR1 > sensorR3) && (sensorR2 > sensorR0) && (sensorR1 > sensorR0) && (sensorR2 > sensorR3) )
      differenz = -150 - (sensorR2*100) / (sensorR1+sensorR2);
    else if( (sensorR2 > sensorR1) && (sensorR3 > sensorR1) )
      differenz = -250 - (sensorR3*100) / (sensorR2+sensorR3);

    if( ((sensorL0 < 12) && (sensorL1 < 12) && (sensorL2 < 12) && (sensorL3 < 12) && (sensorR0 < 12) && (sensorR1 < 12) && (sensorR2 < 12) && (sensorR3 < 12)) || (differenz == 250) || (differenz == 150) || (differenz == 50) || (differenz == -50) || (differenz == -150) || (differenz == -250) )
    {
      //Wenn alle weiß sind dann --> Fehlerhafte Größe || Wenn Grenzwerte 250, 150, 50, -50, -150, -250
      differenz = -100;
    }

    if( (differenz == -100) || (differenz > 360) || (differenz < -360) ) //Bei ungültigen Werten, nehme letzten Wert
      differenz = differenz_vorher;
        //UNGÜLTIGE WERTE treten auf wenn:
                  //-) -100 auftaucht... Also wenn alle weiß sind
                  //-) größer, kleiner maximal Werte auftauchen... Also Motor Störungen macht

    //Speichere letzte richtige Differenz****
    differenz_vorher = differenz;
    //***************************************

    //P-Algorithmus*************
    //y = Kp * differenz;
    //**************************

    //PI-Algorithmus************
    esum = esum + differenz;
    y = (Kp * differenz + ((long)( ((float)Ki/(float)skalierfaktor)*Ta* ((float)esum))) );
    //**************************

    //REGELUNG:############################################################################
    if( (differenz < 20) && (differenz > -20) )  //Wenn Sollwert, dann Motoren beide voll
    {
      PWMleft = 400;
      PWMright = 400;
    }
    else if( (differenz > 15) && (differenz < 150) )
    {
      PWMleft = 300 + y;
      PWMright = 250;
    }
    else if( (differenz < -15) && (differenz > -150))
    {
      PWMright = 300 + y *(-1);
      PWMleft = 250;
    }
    else
    {
      PWMleft = 250 - y;
      PWMright = 250 + y;
    }


    //####################################################################################

    //Wenn Bereich überschritten, dann Begrenzung einbauen
    if(PWMleft > 1023)
      PWMleft = 1023;
    else if(PWMleft < 0)
      PWMleft = 0;

    if(PWMright > 1023)
      PWMright = 1023;
    else if(PWMright < 0)
      PWMright = 0;
    //****************************************************

    MotorLINKS = PWMleft;  //Werte den Motoren übergeben
    MotorRECHTS = PWMright;  //Werte übernehmen
  }
  //back***************************************************************************

Diese Zeile:
esum = esum + differenz;
    y = (Kp * differenz + ((long)( ((float)Ki/(float)skalierfaktor)*Ta* ((float)esum))) );
möchte ich noch erklären.

Da alle Reglerparameter Kp, Ki, und Kd ganze Zahlen sind und ich für den 
I Anteil 1/Ti*s habe, muss ich leider dividieren und skalieren, damit 
der Bereich halbwegs passt.
Das ganze wird dann wieder zu long und dann weiter multipliziert.

Die Zykluszeit beträgt 300us und sollte meiner Meinung nach schnell 
genug sein. Die cny70 reagieren so ca im 70 us Bereich und deshalb 
sollte das auch passen.

Was ich jetzt in den Regler reinschicke ist der Bereich, den ich mir 
durch die Sensoren ausrechne.
Der Bereich geht fließend und linear von -345...345. Es gibt zwar sehr 
sehr kleine Lücken dazwischen, aber die sind jetzt nicht der Rede Wert.
Die Differenz ist -100 wenn Fehlerhafte Werte auftreten und dadurch soll 
dann die letzte DIfferenz genommen werden.
Bei der alten Sensotplatine ist -100 öfters so zwischendurch gekommen 
ohne einen Grund, also haue ich den Messwert einfach raus.

Meine Frage jetzt nach den ganzen Erklärungen:
Stimmt es wie ich den I-Anteil dazurechne?
Ich glaube nämlich nicht weil ich für den skalierfaktor verschieden 
großes eingestellt habe um mit dem 1/sTi sehr sehr klein zu werden, aber 
jedoch kein Erfolg.

Wo mache ich den Fehler?

lg andy

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur ein Verdacht und Schuss ins Blaue, weil alle Variablendefinitionen 
fehlen mit denen man den Verdacht erhärten oder ausräumen könnte...

Hast du eine Debugschnittstelle USB oder RS232 vorgesehen?

Wenn ja, gib die Einzelwerte und das Ergebnis darauf aus. Rechne die 
Formel mit dem Taschenrechner (oder per Tabellenkalkulation) nach.

Vielleicht hast du im Programm Probleme mit einem Überlauf oder einem 
Abschneiden von Nachkommastellen.

Autor: Andy S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan B. schrieb:
> Nur ein Verdacht und Schuss ins Blaue, weil alle Variablendefinitionen
> fehlen mit denen man den Verdacht erhärten oder ausräumen könnte...

Dasind alle Definitionen die relevant dafür sein sollten:
//Regler Variablen
volatile signed long y = 0, esum = 0, ealt = 0, differenz = 0;
volatile unsigned int Kp;   //Reglerparameter Proportional
volatile unsigned int Ki;  //Reglerparameter Integral
volatile unsigned int Kd;  //Reglerparameter Differncial
signed long P_Anteil_komplett = 0, I_Anteil_komplett = 0;
int16_t PWMright = 0, PWMleft = 0;
volatile unsigned int skalierfaktor;
signed int differenz_vorher = 0;

Kp = eeprom_read_word(&P_Anteil);
Ki = eeprom_read_word(&I_Anteil);
Kd = eeprom_read_word(&D_Anteil);
skalierfaktor = eeprom_read_word(&Skal);

Stefan B. schrieb:
> Hast du eine Debugschnittstelle USB oder RS232 vorgesehen?

Ja, UART und 4-Zeilen LCD

Das LCD ist leider auf den Roboter drauf und der Roboter ist gerade bei 
einem Freund für 3 Tage weil er das Gehäuse machen muss.
Also muss ich warten, deshalb muss ich jetzt leider nur mit Software 
auskommen.

Die Differenz hat aber keinen Überlauf, genau so wenig wie das y bei I 
Anteil = 0. Wie es dann mit I Anteil ausschaut habe ich nicht daran 
gedacht ausgegeben.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann mal abwarten, was die Debugausgabe bringt.

Um das zu Simulieren: Wie ist Ta definiert? Wie sind die Sensoren 
physikalisch angeordnet? So?

                               Robotmitte
sensorL0 sensorL1 sensorL2 sensorL3 sensorR0 sensorR1 sensorR2 sensorR3

Autor: Andy S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan B. schrieb:
>                                Robotmitte
> sensorL0 sensorL1 sensorL2 sensorL3 sensorR0 sensorR1 sensorR2 sensorR3

Genau.

Autor: Tueftler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Ist dein Roboter nicht an sich schon ein I-Anteil?
kurze Änderung der Richtung, also kurzes Ausschalten eines Motores hat 
eine kontinuierliche Änderung der Position (änderung des Abstands zur 
Linie) zur Folge.
Das heisst du hast momentan eine PI-System, dessen Polstelle immer auf 
der Imaginären Achse liegt, wie ich gerade sehe.... also immer 
grenzstabil und im Zweifelsfall auch noch Schwingungsfähig.
Tu mal einen D-Anteil dazu, das hat meiner Meinung nach mehr Aussicht 
auf Erfolg.
Hmm hoffentlich liege ich jetzt nicht total daneben.... vielleicht kann 
mich für diesen Fall ja jemand der davon Plan hat korrigieren...

Tueftler

Autor: Andy S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Tueftler schrieb:
> Ist dein Roboter nicht an sich schon ein I-Anteil?

Im Prinzip denke ich auch dass das so ist, aber ich möchte schneller 
werden und eine Möglichkeit ist es den P-Anteil hochzudrehen, und dann 
bekomme ich ein Schwingen und dann brauche ich deshalb einen I.

Ich habe aber einen D-Anteil dazugegeben und er hilft eh.

Weiteres Problem:
Wenn der Roboter die Linie nicht mehr sieht, dann soll der letzte Wert 
behalten werden. DIes sage ich ihm mit dem hier:
if( (sensorL0 < 12) && (sensorL1 < 12) && (sensorL2 < 12) && (sensorL3 < 12) && (sensorR0 < 12) && (sensorR1 < 12) && (sensorR2 < 12) && (sensorR3 < 12) )
    {
      differenz = differenz_vorher;
    }

Jedoch treten in diesem Zustand trotzdem immer wieder falsche Werte auf 
aber nur wenn sich die Linie rechts verloren hat.
Wenn die Linie links verschwindet, dann behält er den letzten Wert bei 
und steuert auch dadurch die Motoren richtig.
Ich weiß jetzt nicht ob das SOftwarefehler sind oder sich irgendetwas 
von die Motoren einkoppelt.

Das aktuelle Programm mit Display Ausgabe ist im Anhang.
Wegen diesem Fehler auf der linken Sensorseite kommt er auch immer wenn 
er die Linie verfolgt bei solchen Mustern auch raus oder wenn er zu weit 
aufschwingt (hoher P-Anteil).

Die Fehlerhaften Werte treten nicht auf wenn ich die Motoren 
ausgeschaltet lasse und den Bereich ausmesse, also vermute ich mal, dass 
es an die Motoren liegt und sich über die Sensoren was einkoppelt.

Wenn die Motoren schon ganz ganz langsam drehen, dann passiert dieser 
Fehler, aber nur auf der rechten Seite.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit einem I Anteil Schwingungen unterdrücken? Das Konzept kannte ich 
noch gar nicht.

Autor: Tueftler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der I-Anteil wird gerne benutzt, um Bleibende Regelabweichung, bzw. 
Schleppfehler zu vermeiden.
Schleppfehler: konstante zeitliche Änderung der Führungsgröße, 
Regelgröße folgt im konstanten Abstand zur Führungsgröße, holt diese 
jedoch nicht ein.

Deshalb braucht man bei konstanter Führungsgröße wenigstens ein I-Glied 
im System.
Bei sich linear ändernder Führungsgröße muss man wenigstens zwei 
Integratoren haben, damit die Regelabweichung zu null wird. usw...

Dass I-Anteile auch gegen Schwingungen gut sind, wusste ich auch noch 
nicht.
Grüße
Tueftler

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richtig, man braucht ein I-Glied im System. Das System besteht hier aber 
nicht nur aus dem Regler. Die Regelstrecke gehört auch dazu und bei der 
Position im Bezug auf die Radgeschwindigkeit hat man schon ein I-Anteil.

Ich stimme deiner ursprünglichen Argumentation natürlich zu. Und wenn 
man Schnelligkeit möchte wird eben der D-Anteil benötigt, wie du auch 
schon geschrieben hast.

Autor: Tueftler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja... wie bereits geschrieben, ist sein Fahrzeug ja bereits wenigstens 
ein Integrator..... also wird ein weiterer im Regler meiner Meinung nach 
keine Verbesserung mehr bringen können.

Autor: Andy S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Tueftler schrieb:
> Ja... wie bereits geschrieben, ist sein Fahrzeug ja bereits wenigstens
> ein Integrator..... also wird ein weiterer im Regler meiner Meinung nach
> keine Verbesserung mehr bringen können.

Hmm, ok dann lasse ich diesen mal weg, ich dachte nämlich dass ich das 
ganze über Ziegler Nicholz mache, also P-Anteil so hoch machen, bis eine 
Dauerschwingung auftritt und dann mit I rein, damit ich den rest der 
Differenz noch ausgleiche und das ganze stabiler wird.

Ich habe jetzt ein Video hochgeladen, welches mein aktuelles Problem 
zeigt.
Die Fehlerhaften Werte kriege ich nicht mehr rein. Grund waren die 
Motoren die mit einer zu niedrigen PWM Frequenz geschalten werden --> 
längere Kurzschlusszeit --> mehr Störungen.
Jedoch habe ich jetzt andere Probleme.

http://www.filmupload.de/view_video.php?viewkey=7a...

Dieses Video zeigt was immer wieder bei dieser Strecke passiert.

Das aktuelle Programm habe ich angehängt und die Sensoren genauso.

Im Video ist ganz gut zu sehen, dass Monty (Robotername) versucht wieder 
an die Linie ranzukommen, es aber nicht schafft.
Ich verstehe aber überhaupt nicht aus welchem Grund?

Wenn ich mit der Hand ihn über die Linie fahren lasse ohne dass die 
Reifen den Boden berühren, dann passen die Werte.
Wasmich wunder ist dass er auch wenn nur wenig ABweichung ist er 
trotzdem rauskommt.

Kp = 3 und Kd = 3  im Video.

Ich kann leider nicht so schnell schauen was passiert und diesen Zustand 
wo er vergisst was vorher war finde ich leider auch nirgends in der 
Software.

Wenn ich mit den Motoren langsamer werde, dann passtes geoßteils wenn 
MOTOR_MAX = 500 ist. Ab und zu kommt er aber dennoch raus und zwar immer 
nach dem selben Muster wie im Video.

Ich glaube an der Schnelligkeit der Sensoren und vom Algorithmus liegt 
es nicht, da beide insgesamt weniger als 300us brauchen.
Bei früheren Versuchen sind die Motoren noch stärkere Schwingungen 
gefahren und viel viel schneller, jedoch hatte ich nur eine elypse als 
Strecke und nicht sowas.

Vielleicht ist auch der Sensorbereich zu klein, denn das baut dann eine 
Begrenzung in den Regelkreis. Das erklärt aber nicht warum er den 
letzten Wert nicht speichert.

Irgendwelche Ideen wieso das nicht so hinhaut?

lg andy

Autor: Andy S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe jetzt das Problem mit dem rauskommen gelöst. Es lag am 
Algorithmus und den 300us. Ich kann aber immer noch nicht galuben, dass 
das zu langsam ist.

Hier ist das jetzt zu sehen:
http://www.filmupload.de/view_video.php?viewkey=fe...

ICh habe einfach die Abfrage geändert:
//Main-Loop:*********************************************************************
  while(!cancel_mode)
  {
    //BEARBEITER SENSOREN UND REGELDIFFERENZ############################
    //lese Sensorwerte ein
    sensorL0 = GetADC_8bit(0);
    sensorL1 = GetADC_8bit(1);
    if( (sensorL0 > 17) && (sensorL1 > 17) )
      differenz = 250 + (sensorL0*100) / (sensorL0+sensorL1);
    else
    {
      sensorL2 = GetADC_8bit(2);
      if( (sensorL1 > 17) && (sensorL2 > 17) )
        differenz = 150 + (sensorL1*100) / (sensorL1+sensorL2);
      else
      {
        sensorL3 = GetADC_8bit(3);
        if( (sensorL2 > 17) && (sensorL3 > 17) )
          differenz = 50 + (sensorL2*100) / (sensorL2+sensorL3);
        else
        {
          sensorR0 = GetADC_8bit(4);
          if( (sensorL3 > 17) && (sensorR0 > 17) )
            differenz = -50 + (sensorL3*100) / (sensorL3+sensorR0);
          else
          {
            sensorR1 = GetADC_8bit(5);
            if( (sensorR0 > 17) && (sensorR1 > 17) )
              differenz = -50 - (sensorR1*100) / (sensorR1+sensorR0);
            else
            {
              sensorR2 = GetADC_8bit(6);
              if( (sensorR1 > 17) && (sensorR2 > 17) )
                differenz = -150 - (sensorR2*100) / (sensorR1+sensorR2);
              else
              {
                sensorR3 = GetADC_8bit(7);
                if( (sensorR2 > 17) && (sensorR3 > 17) )
                  differenz = -250 - (sensorR3*100) / (sensorR2+sensorR3);
                else
                  differenz = differenz_vorher;
              }
            }
          }
        }
      }
    }

    //PI-Algorithmus************
    y = Kp*differenz + (Kd/Ta * (differenz - differenz_vorher));
    //**************************
.
.
.

Wie ich dieses Überschwingen jetzt wegbekomme ist eine andere Frage.

Für Vorschläge wäre ich offen.

lg andy

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Parameter 'Kd', 'Kp'. Außerdem 'y' und 'Ta', welchen Datentyp haben 
die? Die Division durch Ta ist eigentlich unnötig, bzw. kann sogar vom 
Preprozessor übernommen werden.

Auch sieht deine Verschachtelung etwas komisch aus. Für sowas gibt es 
'else if'.

Autor: Andy S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:
> Die Parameter 'Kd', 'Kp'. Außerdem 'y' und 'Ta', welchen Datentyp haben
> die?
//Regler Variablen
volatile signed long y = 0, esum = 0, ealt = 0, differenz = 0;
volatile unsigned int Kp = 0;   //Reglerparameter Proportional
volatile unsigned int Ki = 0;  //Reglerparameter Integral
volatile unsigned int Kd = 0;  //Reglerparameter Differncial
signed long P_Anteil_komplett = 0, I_Anteil_komplett = 0;
int16_t PWMright = 0, PWMleft = 0;
volatile unsigned int skalierfaktor = 0;
volatile signed int differenz_vorher = 0;

Simon K. schrieb:
> Die Division durch Ta ist eigentlich unnötig, bzw. kann sogar vom
> Preprozessor übernommen werden.

Du hast recht,habs grad weggeschmissen

Simon K. schrieb:
> Auch sieht deine Verschachtelung etwas komisch aus. Für sowas gibt es
> 'else if'.

Anders gehts schwer weil ich nochmal messen muss.
Das ganze ist aber nur schnell wenn sich links etwas tut, weil wenn 
rechts etwas passiert dann braucht es genau so lange wie vorher.

Ich habe jetzt aber eine Idee und zwar nur die Sensoren auszumessen, an 
denen sich auch wirklich etwas tut,
Ich hätte da an 8 OPVs gedacht die mir sagen welche 2/3 etwas machen und 
ich diese in die Ifs reingebe also z.B. so:
if( (OPVsensorL0 == 1) && (OPVsensorL1 > 1) )
{
        Messe die 2 Sensoren aus die etwas tun.
  differenz = 250 + (sensorL0*100) / (sensorL0+sensorL1);
  else
  {
          if( (OPVsensorL1 == 1) && (OPVsensorL2 == 1) )
             differenz = 150 + (sensorL1*100) / (sensorL1+sensorL2);
    else
          {
      .
            .
            .

Also die OPVs (in dem Fall Komparatoren sagen mir welche Sensoren gerade 
über 15 (Spannung) haben und aufgrund dessen messe ich dann diejenigen 
Sensoren aus.
Weil im Prinzip messe ich sowieso immer mindestens 2 Sensoren und mehr 
ein und die Abfragen werden ja dadurch nicht mehr.

Was haltet ihr davon bzw käme da noch was in Frage?

lg andy

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Häng mal das komplette Programm an. Du musst bei 'int' (und anderen 
integralen Datentypen) extrem aufpassen wegen Wertebereich und 
Auflösung.
Ich vermute dein Roboter schwingt deswegen über, weil sich 'y' die ganze 
Zeit irgendwo zwischen -1 und 1 bewegt. Da du aber einen integralen 
Datentypen hast und keinen der Gleitkomma o.ä. unterstützt hast du nur 3 
Punkte innerhalb dieses Bereichs (-1, 0 und +1). Und dadurch gibt es 
eben eine extrem grobe Auflösung.

Eine Möglichkeit wäre es, erst mal float zu benutzen und im Nachhinein 
auf Fixkomma (Also z.B. mit *256 skalierten Integern) umzubasteln.

Autor: Andy S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:
> Ich vermute dein Roboter schwingt deswegen über, weil sich 'y' die ganze
> Zeit irgendwo zwischen -1 und 1 bewegt.

Ich glaube kaum dass das so ist weil ich sehe was das y ist. Ich habe 
eine LCD Ausgabe und der Grund warum er schwingt ist weil der Controller 
einnerseits langsam ist und 2tens die Motoren ziemlich schnell sind.

Ich werde jetzt einfach mal eine Abfrage reinmachen, und schau ob das y 
wirklich zu 0, -1, 1 wird, und wenn das passiert, dann soll er stehen 
bleiben und mir das anzeigen, vielleicht liegts ja wirklich an dem.

Aber du hast es eh gesehen, eine einfach änderung der Abfrage, sodass er 
nicht immer alle ADCs einließt bewirkt schon dass er die Linie jetzt 
einmal nicht mehr verliert, ich denke wenn ich noch mehr optimiere 
sprich Idee mit den OPVs dann wird das noch besser hoffe ich, wobei ich 
vermute dass ein Restschwingen noch überbeleibt, aber das macht der 
P-Regler und auch noch der kleine Sensorbereich.

Vielleicht finde ich ja eine perfekte Einstellung, aber bei den ganzen 
Begrenzungen im Regler sprich Sensoren, Motoren (die nicht sofort eine 
Änderung bewirken --> Totzeit) etc. glaube ich kaum dass der Roboter 
perfekt und schnell fahren wird.

Das Programm ist im Anhang

lg andy

Autor: Andy S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:
> Ich vermute dein Roboter schwingt deswegen über, weil sich 'y' die ganze
> Zeit irgendwo zwischen -1 und 1 bewegt.

Wieso eigentlich?
-1, 1 darf ruhig in Frage kommen, wüsste nicht warum nicht?

lg andy

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.