- MultiPlus Wechselrichter Insel und Nulleinspeisung Conrad         
Ergebnis 1 bis 10 von 13

Thema: Motoren wollen nicht mit niedrigen PWM Werten

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.715
    .. das ich die Encoder noch nicht vernünftig auslesen kann .. Am Ende sind es doch 2 einfach digitale Eingänge pro Encoder? ..
    Genau. Das Arbeiten der Encoder sieht ungefähr so aus - klick. Meine Dokumentation zur Auswertung sieht so aus - nochnklick - die Farbenliste [White] bis [Red] bezieht sich auf das Kabel für den Motoranschluss!!

    Mit Java kann ich ja nu nicht helfen, aber vielleicht bietet Dir (m)ein C-Code-Schnippsel ne Hilfe oder zumindest nen Anhaltspunkt ? Wobei hier für Dich eher nur die IencdrX-Werte für die (Teil)Umdrehungen/Drehwinkel und die tmrEx-Werte für die Drehzahlmessung von Interesse sind.
    Code:
    // ============================================================================= =
    // ===  Initialisierung der externen Interrupts bei m1284, doc 8272D-AVR-05/12
    //      EXT_INT0 auf PORTD2 Pin 16  --  Encoder IencB0 auf PINC 2 Pin 24  und
    //      EXT_INT1 auf PORTD3 Pin 17  --  Encoder IencB1 auf PINC 3 Pin 25
    // ============================================================================= =
      void XTI_0_1_init( void )    // Initialisiere beide Interrupts auf RISING edge
     {                //  => EICRA ISC00/~01 + ~10/~11 auf 1     doc S68
      EICRA   |=  (1<<ISC01)|(1<<ISC00);    // INT0 triggert auf RISING edge
      EICRA   |=  (1<<ISC11)|(1<<ISC10);    // INT1 triggert auf RISING edge
      EIMSK   |=  (1<<INT0) | (1<<INT1);    // erlaube INT0 und INT1 in EIMSK  
    // Initialisierung der Zeiten:            
      Iencdr0  =  Iz_diff0  =  Iz_yseci0  =  Iz_ysecv0  =  0;
      Iencdr1  =  Iz_diff1  =  Iz_yseci1  =  Iz_ysecv1  =  0;
      tmrE0  =  tmrE1  =  0;        // Timer für Drehzahlerfassung
     }      // Ende von void XTI_0_1_init( void )
    // ============================================================================= =
    
    
    // ============================================================================= =
    // ===  Nicht unterbrechbare ISR für EXT_INT0 auf mega1284      ================ =
    // Der Timer tmrE0 für Laufzeit des EXT_INT0 wird ausgelesen
     ISR(INT0_vect)                 // INT0 triggert auf RISING edge => 
     {                              //   => Wenn Aufruf, dann PORTD2 = high
    //  ToggleBit (PTLED, LCr);     // rtLED toggeln
    // - - - - - - - - - - - - - - - -
    //      Encoderticks Iencdrx nur hochzählen, IencBx rauf- od runterzählen
      Iz_diff0  = tmrE0;    // Hier die Zeit (in x 50µs-tupsi) seit letztem ISR-Aufruf
      tmrE0     =    0;     // Resetten ##>> IN der ISR ohne CLI/SEI möglich
      Iencdr0 ++;           // Incrementiere Encodercounter, zählt NUR aufwärts
      if (IsBitSet (PINC, 2)) IencB0++;     // Rad treibt vorwärts,  math. negativ
      else                    IencB0--;     // Rad treibt rückwärts, math. positiv
     }      // Ende ISR(INT0_vect)
    // ============================================================================= =
    
    
    // ============================================================================= =
    // ===  Nicht unterbrechbare ISR für EXT_INT1 auf mega1284      ================ =
    //  Routine setzt einfach einen Zähler hoch.
    //  Sonst wie ISR für EXT_INT0 für Motor li,re und PWM/Geschw.
     ISR(INT1_vect)                         // hiess mal: ISR(SIG_INTERRUPT1)
     {                                      //
    //  ToggleBit (PTLED, LCr);     // rtLED toggeln
    // - - - - - - - - - - - - - - - -
    //      Encoderticks Iencdrx nur hochzählen, IencBx rauf- od runterzählen
      Iz_diff1  = tmrE1;    // Hier die Zeit (in x 50µs-tupsi) seit letztem ISR-Aufruf
      tmrE1     =    0;     // Resetten ##>> IN der ISR ohne CLI/SEI möglich
      Iencdr1 ++;           // Incrementiere Encodercounter, zählt NUR aufwärts
      if (IsBitSet (PINC, 3)) {IencB1--;}   // Rad treibt rückwärts (math. positiv)
      else                    {IencB1++;}   // Rad treibt vorwärts (math. negativ)
     }      // Ende ISR(INT1_vect)
    // ============================================================================= =
    Ciao sagt der JoeamBerg

  2. #2
    Neuer Benutzer Öfters hier
    Registriert seit
    01.11.2015
    Beiträge
    17
    Vielen Dank für deine Bemühungen. Ich habe folgenden Code finden können und werde damit vorerst mein Glück probieren. Ich melde mich sobald es neues gibt. Ohne funktionierende Encoder fehlt mir ja leider die Abbruchbedingung für den ZeroBoost.

    https://gist.github.com/rwaldron/5db...d3b2c492737c99

  3. #3
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    07.04.2015
    Beiträge
    911
    Zitat Zitat von nofear87 Beitrag anzeigen
    Gibt es Erfahrungswerte wie lange der höhere Anlaufstrom zur Verfügung gestellt werden muss, bevor ich wieder herunterregeln kann?
    Bis sich das Fahrzeug in Bewegung gesetzt hat. Genau dann hat es sich von der Haftreibung (Motor, Getriebe, Räder) gelöst und muss nur noch gegen die Roll-/Gleitreibung arbeiten.

    In der Praxis: Ich stelle zuerst die PID-Regelparameter KP,KI, KD wie gewohnt auf "langen" Strecken ein. Anschließend optimiere ich KZB anhand der kürzestmöglichen Strecke. "Kürzestmöglich" ist nicht immer "1" (ein Encoderschritt), hängt im wesentlichen vom Haftreibungswert, der Schwungmasse des Fahrzeugs und der Auflösung der Inkrementalgeber ab. Ist die kürzestmögliche Strecke für das System zu kurz gewählt, bekommt man auch mit dem ZeroBoost nur dauerhaftes Schwingen. Hat man diesen Wert allerdings auf das physikalisch Mögliche eingegrenzt, kann man ihn durchaus als Toleranz zum Zielpunkt verwenden.

    BTW, ich hab's mir lange nicht erklären können, aber mal zum Nachexperimentieren: Wenn man das Fahrzeug mit erhöhter PWM gerade so zum Rollen bringt, danach die PWM absenkt und anschließend mit dieser "Schleichfahrt-PWM" einfach die Richtung umkehrt, fährt's in der Regel rückwärts ohne erneuten Startboost weiter.
    Ich vermute mittlerweile, dass die drei Haftreibungskomponenten "Räder, Getriebe, Motorlager" bei dieser Richtungsumkehr bedingt durch das Getriebespiel zeitlich verzögert kommen. Sie wirken also nur noch nacheinander, nicht mehr in der Summe.

    Insofern ist beim Einstellen des Zeroboost die Wirkung eines einzelnen Überschwingers unter erhöhten Lastbedingungen nicht einmal schlimm. Auf ner Schwelle balanciert das Rad so nicht, aber über die Schwelle, danach über den Zielpunkt hinaus und dann wieder zurück geht recht zuverlässig.

  4. #4
    Neuer Benutzer Öfters hier
    Registriert seit
    01.11.2015
    Beiträge
    17
    So, ich habe mich mal an dem ZeroBoost versucht. Nehme ich nur einen Motorkanal (sprich bei mir die linken 2 Motoren) funktioniert alles wunderbar.
    Wenn ich den 2ten Kanal ebenfalls zur gleichen Zeit nutze ist unter PWM 30 Schluss. Woran könnte das liegen. Angenommen ich schalte die beiden Kanäle mit etwas Zeitversatz habe ich das Problem das ich dadurch eine Drehung erzeuge.

    Anbei noch ein Beispiel (kommentiere ich nach dem Timeout "motor2" aus fahren die Motoren an Kanal 1 auch mit niedrigeren PWM Werten):
    Code:
    if(speed < 30) {
       motor1.forward(40);
       motor2.forward(40);
       setTimeout(() => {
         motor1.forward(speed);
         motor2.forward(speed);
       }, 300)
     } else {
       motor1.forward(speed);
       motor2.forward(speed);
     }

  5. #5
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.715
    .. Angenommen ich schalte die beiden Kanäle mit etwas Zeitversatz habe ich das Problem das ich dadurch eine Drehung erzeuge ..
    Das ist eine Annahme? Oder hast Du das schon getestet?

    Die Motoren für meine kleine Coladose werden pro Sekunde 100 mal geregelt - bei archie dasselbe. Immer nur ein Motor zur gleichen Zeit, d.h. die Regelroutine läuft für beide Motoren 200 mal pro Sekunde mit gleichmässigen Abständen, 5 ms, von Regelung zu Regelung. Abweichungen der Fahrtrichtung hatte ich damit nicht wirklich festgestellt. Allerdings musste bei Aufnahme der Sprungantwort (fürs MiniD0) auf genaueste Synchronisierung Wert gelegt werden, um Richtungsänderungen beim Anfahren zu vermeiden. Ohne genauere Tests behaupte ich, dass durch die sehr hohe Beschleunigung eines Motors am Bewegungsanfang aus dem Stillstand heraus dieser festgestellte Versatz kam - siehe hier.
    Ciao sagt der JoeamBerg

  6. #6
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    07.04.2015
    Beiträge
    911
    Hast Du vielleicht einen Spannungsabfall in der Versorgung (zu lange Akkuleitung oder zu wenig Stützkondensator am Motorshield)?

Ähnliche Themen

  1. Nucleo mit STM32F446 und J-Link wollen nicht...
    Von White_Fox im Forum ARM - 32-bit-Mikrocontroller-Architektur
    Antworten: 2
    Letzter Beitrag: 29.05.2016, 16:41
  2. Antworten: 49
    Letzter Beitrag: 13.10.2013, 13:08
  3. rfm 12 module wollen nicht
    Von demlinger im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 9
    Letzter Beitrag: 18.01.2008, 16:13
  4. Motoren wollen nicht so....
    Von papa_moll im Forum Asuro
    Antworten: 12
    Letzter Beitrag: 25.01.2007, 14:05
  5. Vergleichen von ganzen Werten und nicht nur Bits
    Von Ausbilder 'Durchdrücker' im Forum Software, Algorithmen und KI
    Antworten: 3
    Letzter Beitrag: 07.04.2005, 17:07

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

fchao-Sinus-Wechselrichter AliExpress