- MultiPlus Wechselrichter Insel und Nulleinspeisung Conrad         
Seite 19 von 25 ErsteErste ... 91718192021 ... LetzteLetzte
Ergebnis 181 bis 190 von 246

Thema: Autonom in kleinen Dosen: R2_D03 + Nachfolger R3D01

  1. #181
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.686
    Anzeige

    E-Bike
    Es ist ein bisschen vorangegangen. Die Speicherung möglichst vieler Parameter ist auch beim mega328 ein Platzproblem. Immerhin sind jetzt die wichtigsten sichtbar geworden. Beobachtet werden derzeit die ersten hundert Encoderticks, also rund 70 mm der ersten Teilstrecke von 150 mm. Wer will, kann das Video, siehe Link oben, dazu ansehen - es ist die erste Teilstrecke bis zum Multiturn. Anmerkung: der besseren Anschauung wegen wurden die Parameterwerte yp, yi und yd - jeweils nur für dem Motor 12 - mit einem offset dargestellt. Der ist im Diagramm genannt (z.B. ist die Nulllinie für yp12 die 30-er Linie). Anmerkung2: eine Unachtsamkeit bei der Programmierung hatte dazu geführt, dass uint16- und int16-Werte in der Regelungroutine gemischt waren. Dabei hatte ich feststellen müssen, dass die Typwandlung offenbar drastisch viel Zeit braucht. Derzeit können in jeder INTx-ISR alle drei Reglerparamterwerte erfasst werden - davor, mit Typumwandlung - ging das nur mit einem Parameter. Den übersetzten Code hatte ich aber aus Bequemlichkeit nicht durchgesehen.

    Deutlich zu sehen ist der hohe Einfluss des integralen Regleranteils. Der führt dazu, dass noch in der Vorwärtsphase - eindeutig ohne irgendeinem vorgegebenen Bremsvorgang - der P-Anteil deutlich negativ werden muss (liegt also weit unter der 30er-Linie), weil der integrale Anteil so hoch geworden ist (35 - weil er mit offset 10 dargestellt wird). Eine geringere Verstärkung im integralen Anteil - schon z.B. bei Ki = 20 - führt zu deutlicherem Schwingen. Derzeit fahre ich mit Ki=22 bei einem Minimum an Schwingen. Dies wird festgestellt nach der Methode des genauen Hinsehens auf den Verlauf von diff0 - sprich: auf die inverse Geschwindigkeit. Der Wert diff0 ist die Zeit vom vorherigen Encoderinterrupt bis zum Beobachtungszeitpunkt, also bis zum aktuellen Interrupt.

    ................Bild hier  

    Der Lohn der Arbeit ist die ausführliche Vorstellung, wie die Regleranteile verlaufen und die Möglichkeit, besser gegen schnelle, kleine Schwingungen im Lauf vorgehen zu können. Bei den derzeitigen Testfahrten habe ich keine Verbesserung der Reproduzierbarkeit der unterschiedlichen Läufe gesehen. Aber das will ich noch in mehreren Fahrten mit derselben Einstellung testen.

    Nachtrag 26Aug09-11:11
    Das Diagramm nutzt einem Interessenten nur dann, wenn der Berechnungsgang der Regelungsroutine bekannt ist. Daher folgt hier der Code mit der kompletten Regelungsroutine, ergänzt um eine Legende zum Diagramm. Die Messdaten werden in den ISR des extINT0 übernommen und in einer Inforoutine dargestellt. In dieser Info-/Ausgaberoutine wird auch der offset für die Achsenkorrektur der Regelungswerte (+10, +30 und +40) eingerechnet und der Wert Izeit_1 in Millisekunden umgerechnet. Das Ergebnis wird seriell ans Terminal ausgegeben.

    Code:
    /* >> 
      Sicherung 25Aug09 1800   ..C2\D01-3_40\D01-3_40_mot_x02.c ###>>> noch nicht
     ===================================================================================
      Target MCU        : m328p
      Target Hardware   : MiniD0
      Target cpu-frequ. : In der Quelle wählbar
     ===================================================================================
            Enthaltene Routinen:        Auszugsweise nur rgl_mo_12
     ===================================================================================
      *** Versionsgeschichte:
     ==================== 
     x02 24Aug09 1500 Messdatensatz ändern zum möglichst kompletten Messen EINES Motors
     x01 04Aug09 1450 Übernahme, erste Anpassungen+Änderungen für Messwerterfassung
     ===================================================================================
      *** Aufgabenstellung : Software für R3D01    
      Original: ....C2\D01_20test328\D01_20_mot_x50.c   07Jul09 1630
     ================================================================================ */
    
    
    // =================================================================================
    // ===  Regelungsroutine für Motor 12  =============================================
    // Die gemessene Zeitdifferenz Iz_diff0 zwischen zwei Encoderinterrupts
    //   wird zur Regelung verwendet  
    // Erläuterungen/Legende für die Diagrammdarstellung der Regelungswerte
    //                                 
    //      Izeit_1 Die Bordzeit, erzeugt aus einem Zähler für 50µs-Interrupts
    //      diff0   Abstand vom letzten zum aktuellen Interrupt in 50µs-Einheiten
    //      iyP12   P-Anteil der Regelung, im Code unten iyp12, in der Darstellung um
    //                      30 nach oben versetzt (Linie 30 ist Nulllinie)
    //      iyI12   I-Anteil der Regelung, sonst sinngemäß wie P-Anteil
    //      iyD12   D-Anteil der Regelung, sonst sinngemäß wie P-Anteil
    //      iy12    Gesamter Regelungsanteil, eingegrenzt auf [0, 255]; 
    //                      damit wird die PWM/OCR=B angesteuert
    //      ncx0    bzw. Lncgs0 Anzahl der gefahreren Interruptticks der Odometrie
    //                      1 nxc0 sind theoretisch 0,83 gefahrene Millimeter
    //                                
      void rgl_mo_12(void)          // Regelung für Motor 12 mit 2 Interr pro Umdr.
    {                                 
      if (sspeed12 <= 15)           // Soll überhaupt gefahren werden?
      {                               
        OCR0B = 0;                  // Unter x mm/s soll nicht gefahren werden
        return;                       
      }                              
      tupsi12      = Iz_diff0;              // Übernahme Interruptabstand in Regelung
      ndrz12       = sspeed12;              // Nenn = Solldrehzahl = Soll-speed
                                      
      sei();                        // Erlaube Interrupts ##### nested Interrupts
                                      
      ix12         = 8300 / tupsi12;        // => Ist-Geschwindigkeit in mm/s
      ie_mot12     = ndrz12 - ix12;         // Vergleich => Regelabweichung
                                              
      if (tupsi12 > 500) {tupsi12 = 500;}   // 22apr09-0847 Begrenze auf 500 statt 250
                                              
      isum12      += ie_mot12;                    
      if  (isum12  < -1000 ) { isum12  = -1000; }
      if  (isum12  >  1000 ) { isum12  =  1000; }
                                      
      iyp12        = ie_mot12 / Kp12;       // P-Anteil berechnen, Kptheor = 0,25 !!
      iyi12        = isum12   / Ki12;               // I-Anteil berechnen
      iyd12        = (ie_mot12 - ie_alt12) / Kd12;  // D-Anteil berechnen
                                       
      iy12         = iyp12 + iyi12 + iyd12;    // Gesamtkorrektur berechnet
                                      
      ie_alt12     = ie_mot12;              // Merke Regelabweichung für D-Anteil
                                    
      if ( iy12 <   0 ) { iy12   =    0;}   // Stellwert (PWM) begrenzen
      if ( iy12 > 255 ) { iy12   =  255;}
                                      
      OCR0B = iy12;                 // Ansteuerung der PWM direkt statt "setPWMlinks"
                                        
      return;                          
    }               
    // =================================================================================
    
    
    // =================================================================================
    // =====  ENDE    Subroutinen  =====================================================
    // =================================================================================
    Geändert von oberallgeier (01.04.2018 um 18:02 Uhr) Grund: Neuer Bildserver
    Ciao sagt der JoeamBerg

  2. #182
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.686
    Nachtrag 26Aug09-11:11
    Das Diagramm nutzt einem Interessenten nur dann, wenn der Berechnungsgang der Regelungsroutine bekannt ist. Daher folgt hier der Code mit der kompletten Regelungsroutine, ergänzt um eine Legende zum Diagramm. Die Messdaten werden in den ISR des extINT0 übernommen und in einer Inforoutine dargestellt. In dieser Info-/Ausgaberoutine wird auch der offset für die Achsenkorrektur der Regelungswerte (+10, +30 und +40) eingerechnet und der Wert Izeit_1 in Millisekunden umgerechnet. Das Ergebnis wird seriell ans Terminal ausgegeben.
    Ciao sagt der JoeamBerg

  3. #183
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    15.07.2008
    Ort
    Höchberg
    Beiträge
    155
    Hallo,

    freut mich zu hören das du mit deiner dose immer weiter kommst.

    Im Fieber von meinen Quadrokopter und Bau von einer V-22 Osprey bin ich auf eine Idee gestoßen, die es insich hat.

    Motto:

    "Lasset die Dosen die Lüfte autonom erobern!"


    Also, man nehme:

    Bild hier  

    +

    Bild hier  

    +

    Bild hier  





    Soll ich das Projekt anfangen?


    Gruss, Max

  4. #184
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.686
    Grüß Dich Max,

    ja, das ist eine originelle Variante. Na ich weiß nicht - wenn Du damit durch die Lüfte fauchst und dann landest, könnte es sein, dass jemand meint - das Ding gehöre doch nicht auf den Boden - leere Dosen gehören in den Alumüll. Diese Versuchung besteht. Dagegen sind Dosen (bei mir sogar mit Halm) auf dem Tisch nicht unbedingt abzuräumen. Dank mal darüber nach.

    Damit will ich Dich keineswegs hindern, Deine Idee durchzusetzen. Welche payload hat den so ein kleiner Hubschrauber? Die Dose (also eher nur die Zarge - ohne Boden und ohne Deckel mit Reißlasche) hat alleine 10 g, der Deckel mit Reißlasche fast 2 g und der dicke Boden 2. Insgesamt 14 g - ohne Befestigungsmaterial. Ein bisschen Sensorik und so . . . aber Du wirst das schon richtig planen, denke ich.

    Was macht denn Deine Dose auf Rädern? Gibts dazu ein update gegen den Stand vom Januar?
    Ciao sagt der JoeamBerg

  5. #185
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    15.07.2008
    Ort
    Höchberg
    Beiträge
    155
    Hallo,

    ohne Umabuten am Heli geht da nix voran. BL-Kit rein und dann dürfte man leichtbauweise das Ding in die Luft bekommen.

    Wegen Halmen: Die Halme verstärken und als landgestell benutzen?


    Meine Dose auf Rädern fährt PC gestützt durch die Wohnung.
    Für einen Regelalgorythmus auf dem µC selber hatte ich ehrlich noch keine Lust. Ich habe 90% der Zeit in die Entwicklung/Programmierung von meinen Quadro und dem aktuellen Projekt, eine Bell-Boeing V-22 Osprey.

    Idee hatte ich deshalb, wenn ich ehh schon eine Quadroregelung hierhabe, die so zu erweitern das der Heli alleine fliegt, und dann noch weitere Sensoren integrieren um die Lage im Raum festzustellen.


    MFG Max

  6. #186
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.686
    Langsam komme ich wohl einer verbesserten Regelung näher (ja ja ja - DIESER Schritt ist ja, genaugenommen, trivial).

    Die Analyse der Testfahrten anhand der Diagramme zeigte, dass deutliche Schwingungen auch bei längerer, gleichförmiger Fahrt existieren. Dies geht sicher auf "Rundungsfehler" - sprich - auf systembedingte Fehlmessungen zurück, weil meine Zeitrechnung in 50µs-Quanten eben nicht kontinuierlich ist (hihi - Zeitmessung ist NIE kontinuierlich *gggg*). ALSO habe ich - als einzige Änderung - mal den Zeittakt des Timers von 50µs auf 25 µs gesenkt. Fazit ist, dass mein Noch-immer-Erlkönig nun über die Teststrecken fetzt. Klar, Formel-1-Wochenende!

    Aber seht euch mal das Diagramm an. Ich habe aus Platzgründen nur jeden vierten Encoderinterrupt - sprich: jede zweite Motorumdrehung - die Daten mitgeschrieben. Aber andere Messungen in diesem Testabschnitt sind feiner erfasst und zeigen die gleiche Tendenz, die Regelungsfreaks wohl klar ist. Schnellerer Zeittakt heißt genauere Zeiterfassung - und damit wird das Ergebnis der Regelung - die Geschwindigkeit - deutlich ruhiger. Im neuen Diagramm ist sowohl die Istdrehzahl I_drz12 als auch die Soll(Nenn-)Drehzahl Nenndrz12 erfasst.

    Natürlich sieht der Geschwindigkeitsanstieg (sprich Istdrehzahl I_drz12, rote Linie mit Kreisen an den Stützpunkten) etwas langsam aus - die Vorgaben sind aber sozusagen doppelt so hoch, als Vorgabe über 300 mm/s. Am Ende des hier dargestellten Diagramms wird bereits zum ersten Turn abgebremst. Fahraufgabe noch immer die Prüfstrecke aus dem Video.

    ................Bild hier  

    Es wird weitergearbeitet.
    Geändert von oberallgeier (17.10.2016 um 19:16 Uhr) Grund: Neuer Bildserver
    Ciao sagt der JoeamBerg

  7. #187
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.686
    Leider habe ich die Art der Messwerterfassung nicht deutlich erläutert.
    ... Was ich allerdings nicht so richtig nachvollziehen kann, ist das 'Raster' mit dem alle Kurven, außer "(ncx0 = lncgs0) * 10", versehen sind ...
    Die für mich einfachste Möglichkeit war es, die Messwerte innerhalb der ISR für den externen Interrupt aufzunehmen. Sprich: die Aufnahme der Messwerte orientiert sich an den Weglängen.

    Damit verbunden ist die Möglichkeit, die Messwerterfassung ab einer vorher bestimmbaren Weglänge zu starten. Dazu wird in der extINT-ISR ein counter von x, z.B. 1999 runtergezählt und bei 1000 wird ncx0 - der Pointer auf das aktuelle Messwertfeld - von 200 auf 0 gesetzt. Die Messwerterfassung prüft diesen Pointer auf <100. Ist dies der Fall, wird ncx0 eins raufgesetzt und die Messwerte in das entsprechende Feldelement geschrieben. Ist der Messwertpointer auf 200 wirkt er deswegen als negierendes Flag für die Messwertaufnahme.

    Nachteil: Wenn der Motorencoder schneller Interrupts erzeugt als die Regelung läuft, wird der Regelungsstatus mehrfach erfasst. Dies ist bei schneller Fahrt der Fall. Dumm gelaufen - und leider sieht das auch schrecklich aus.

    So ist für mich aber die zeitliche Zuordnung der einzelnen Werte einfach durchzuführen. Andernfalls müsste ich zusammen mit den Regelungsparametern noch die entsprechende Zeit notieren, bei der die Parameter erfasst würden. Systematisch an sich kein Problem. Da ich das SRAM des m328 mit der aktuellen Datenerfassung schon zu rund 95% ausgefüllt habe, wäre dafür ein aktuell präsentierter Messwert zu streichen. Diesen Nachteil sehe ich gravierender als den derzeit bestehenden Zustand.

    Ich hoffe, dass die Datenerfassung bzw. -präsentation jetzt nachvollzeibar(er) ist.

    Nachtrag :
    Das Schema der Timer und der Regelung ist weiter oben in diesem Thread schon mal präsentiert worden.
    Ciao sagt der JoeamBerg

  8. #188
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.686
    Die letzten Prozente Genauigkeit zu holen kostet ja bekanntlich unverhältnismässig viel Aufwand. So geht es mir gerade.

    Ein bisschen bin ich vorangekommen. Die ausführlichen Diagramme, Beispiele siehe oben, zeigten mir, dass gelegentlich der Ansteuerungswert iy12/~34 der PwM unter Null geht - dann wird das beschränkt auf den Nullwert. Es ist in den Diagrammen klar zu sehen, dass in diesem Fall auch die Ist-Geschwindigkeit wirklich hoch ist - und ein Auslaufenlassen bedeutet real ne recht niedrige Verzögerung. PwM kann nicht negativ werden. Regelungstechnisch bedeutet es ganz klar, dass die Istgeschwindigkeit zu hoch ist und schnell(!?) gesenkt werden müsste. ALSO musste eine Fallunterscheidung her und ein Bremsvorgang bei zu hoher Drehzahl. Erforderlich wäre sogar ein Bremsvorgang mit dosierter Verzögerung.

    Code:
    // ### Auszug aus Modul ~mot~:
    //      Hier ist der "alte", einfache code. Wird durch Fallunterscheidung ersetzt
    //if ( iy12 <   0 ) { iy12   =    0;}   // Stellwert (PWM) begrenzen
    //if ( iy12 > 255 ) { iy12   =  255;}     
    // ---------------------------------------------------------------------------------
    // -----  Hier folgt der geänderte/neue code - ab 17.Sept. 2009  -------------------
    //      Aufgabenstellung des neuen Codes:
    //      Wenn iy  <  0   =>      Bremsen durch aktive Motorbremse
    //           iy  >= 0   =>      Bei iy > 255 begrenzen auf 255
    //                                  iy = 0 <=> PWM = 0 = Leerlauf, sonst "Normaler"
    //                                  Lauf, ABER Motorbremse ausschalten
    // ### Auszug aus Modul ~com~:
    volatile int8_t  mdir12, mstop12;               // Fahr+Richtungsflags #####>>>>>
            //  mdir12  >0  => vorwärts     = 0 => stop     <0 => rückwärts
            // Stopflag mstop    ( =0 => "Normalfall")      =1 => Bremsen
    Damit wird in etwas aufwendiger Weise bei Werten unter Null die Bremse eingeschaltet. Dummerweise ist jetzt weiterer Aufwand nötig, weil der Motortreiber bei Rückkehr "Normalbetrieb" ab dem Wert Null wieder auf "vorwärts" oder "rückwärts" geschaltet werden muss. Macht nix. Je zwei Flags: mdir12 und mstop12 und ihre ~34-Pendants erlauben die Organisation der Bremserei.

    Und der Gewinn? Ich will euch mit langweiligen Diagrammen nicht anöden (pssst - ich hab noch garkeine gemacht) - aber die Standardtestfahrt sieht schon besser aus. Das Vehikel läuft recht präzise die vorgegebene Strecke (siehe Kreuzchen am Schreibtisch im Testfahrtvideo) - weder zu kurz, noch zu lang, und ich habe den deutlichen Eindruck, dass die Änderungen auch das Vorbeifahren (Länge wird erreicht, aber Endpunkt liegt "daneben") deutlich verringert haben.

    Was steht noch aus? Ich beabsichtige eine anderen Fahrvorgabe. Es sollen a) saubere Beschleunigungsrampen gefahren und b) die Wegpunkte abgeprüft werden. Mal sehen, ob es dann besser geht. Später kommt dazu c) Übertrag des Vor-/Nacheilens von einem Antrieb sinngemäß auf die Regelung des anderen - und damit endlich das ursprüngliche Ziel einer Art Differential-Sperrwirkung.

    Nachtrag 19. Sept. 2009, 17:13
    Interessant wäre es für mich zu erfahren, ob jemand mit diesem Bremsen bei PWM-Vorgabe unter Null schon gearbeitet oder sonstwie Überlegungen oder Erfahrungen dazu hat.
    PS: Schon dumm, wenn man beim Editieren statt [edit] auf [x]=Löschen klickt
    Ciao sagt der JoeamBerg

  9. #189
    Moderator Robotik Visionär Avatar von radbruch
    Registriert seit
    27.12.2006
    Ort
    Stuttgart
    Alter
    61
    Beiträge
    5.799
    Blog-Einträge
    8
    PS: Schon dumm, wenn man statt [edit] auf [x]=Löschen klickt
    Aua!

    (Aber für mich besser als unnötig auf Bild hier   zu klicken ;)

    Schönes WE

    Gruß

    mic
    Bild hier  
    Atmel’s products are not intended, authorized, or warranted for use
    as components in applications intended to support or sustain life!

  10. #190
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    12.09.2009
    Beiträge
    182
    Hey das Teil fin ich geil!!!

Seite 19 von 25 ErsteErste ... 91718192021 ... LetzteLetzte

Berechtigungen

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

12V Akku bauen