- 3D-Druck Einstieg und Tipps         
Seite 9 von 9 ErsteErste ... 789
Ergebnis 81 bis 85 von 85

Thema: Kurve fahren

  1. #81
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    29.05.2005
    Beiträge
    1.018
    Anzeige

    Praxistest und DIY Projekte
    Hi mausi_mick,

    tut mir leid, dass ich mich jetzt erst wieder einmal melde. (Arbeit, Arbeit, Jammer, Jammer)

    Ich habe mir gerade mal deine letzte Version runtergeladen und ein bisschen begutachtet.

    Du treibst ja mittlerweile einen enormen Aufwand für eine möglichst präzise Fahrt. Alleine die Geschwindigkeitsreduzierung kurz vor dem Erreichen des Ziels ist schon nicht schlecht.
    Wie ich gefunden habe, hast du ja weiterhin auch noch die Situation abgefangen, dass in der Loop zum Abfahren der Wunschstrecke die Warteschleife für mindestens einen gefahrenene Tick benutzt wird.
    Das scheint sich ja wohl doch zu einem zentralen Teil der ganzen Funktion ge(mausi_mick)ert zu haben.

    Eine Stelle, eigentlich ja 2, ist/sind mir aufgefallen.
    Wenn du in der Fahrt-Loop mit "if (tick_zi >= tick_end)" prüfst, ob die Summe der zu fahrenden Tiks am Ziel angekommen ist, verläßt du die GoTurn2()-Funktion mit einem "return (0)".
    Dann aber ist nicht geprüft, ob jede Seite ihre Sollstrecke gefahren ist. Fehlt also einer Seite ein Tick, muss er auf der anderen Seite gefahren worden sein. Somit ist die Differenz immer 'doppel'schlecht.
    Hier ist noch 'ein ganz kleines bisschen' Potenzial die Genauigkeit zu steigern. Eventuell dadurch, dass die noch fehlenden Tiks der einen Seite doch noch gefahren werden.
    Sollte aber bestimmt nicht beim 'Drehen auf der Stelle' passieren, da hier ja die Summe der Tiks den Drehwinkel bestimmt, und somit genauer ist, als wenn die 'Fehlseite' noch weiter bewegt wird.
    Beim Geradeausfahren allerdings steht der Asuro dann besser in der gewünschten/erwarteten Richtung.

    Andererseits zeigen deine Angaben im Vergleich zur Originalfunktion ja schon sehr schön, dass sich dein Aufwand enorm gelohnt hat. Allerdings ist die Größe der Software ja auch enorm geworden.

    Ich werde das ganze mal meinem Asuro verpassen und dann mal berichten. (wann, wann, jammer, jammer )

    Viele Grüße Sternthaler

    Ach ja: Klasse Arbeit und viele informative Beiträge von dir.
    Auch wenn aktuell nicht allzuviel geantwortet wurde. Ich werde versuchen mich zu bessern.
    Lieber Asuro programieren als arbeiten gehen.

  2. #82
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    29.05.2005
    Beiträge
    1.018
    Upps, besser spät als nie.

    Hallo zusammen. Hallo mausi_mick,

    leider muss ich von einem völligen Versagen auf meinem Asuro berichten.

    Die Maschinen laufen beide gut an, und dann geht es nur noch in einer recht engen Linkskurve immer im Kreis.
    Auch ein paar Versuche mit angepassten Werten für die Tik-Zählerei im Encoder-Teil haben keine Besserung gebracht.
    Da mir mein Asuro im Moment etwas suspekt vorkommt (scheint ein wenig Staub angesetzt zu haben), habe ich mir den vom Nachbarn gekrallt, dort aber auch keinen Erfolg gehabt. Gleiches Resultat.

    Ich stehe aktuell vor einem Rätsel, habe aber immer noch absolut keine Zeit das Problem auf meinem Asuro zu suchen.

    Gruß Sternthaler
    Lieber Asuro programieren als arbeiten gehen.

  3. #83
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    12.07.2006
    Ort
    Puchheim
    Alter
    76
    Beiträge
    455
    Hallo Sternthaler,

    bin erst heute aus Mexiko zurück, hatte Deinen Kommentar dort schon gelesen, aber keine Zeit ? zu antworten. Lag wohl doch eher an den Antwortszeiten, der Tastatur, den Temperaturen ...

    Ich hab auch den Eindruck, dass das Programm zu gross ist. Auch ist das
    Anfahrverhalten und das Abbremsen am Ende noch nicht optimal. Beim Anfahren merkt man auch die "Totzeit", bis die Regelung greift. Die Werte fürs Anfahren und Abbremsen sind eigentlich auch geschwindigkeitsabhängig, sodass das Programm noch aufwändiger würde.
    Besser wäre es wohl - wie bei Waste und Dir schon realisiert - mit einem PID-Regler zu arbeiten.
    Ein anderes Problem ist - gerade beim Kurve fahren - vielleicht auch darin zum sehen , dass ASURO ein Dreirad ist, wobei das 3. Rad (Tennisball) eigentlich schlechte (Reib-)Werte aufweist.
    Um diesen Einfluss zu minimieren, müsste man es entlasten (bei mir z.T. realisiert durch Verlageren des Schwerpunkts durch Akku mit 4 Mignon (AA)-Zellen).

    Mit der Messung der Ticks mit dem Gabel-LS bin ich sehr zufrieden, bringt im unteren Geschwindigkeitsbereich einiges . Den Aufbau könnte man wohl noch eleganter und weniger aufwändig gestalten, zumal der Schmitttrigger nicht notwendig ist.

    Gruß

    mausi_mick

  4. #84
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.652
    Hallo mausi_mick,

    Zitat Zitat von mausi_mick
    ... Anfahrverhalten und das Abbremsen am Ende noch nicht optimal ...
    Ich habe ja leider seit Monaten den asuro beiseite gelegt und viel an meinem Dottie gebaut. Dabei hatte ich aber (auch) sehr viel Wert auf die Regelung gelegt und hatte damit einigen Aufwand. Mittlerweile läuft die Regelung mit 405 Hz (hat sich so ergeben) recht ordentlich - alles integer, weil mit FP der Zeitaufwand viel zu hoch ist.

    Ich hatte mir die Zeitkonstanten der einzelnen Motore bestimmt aus der Sprungantwort und dann ein bisschen an den Faktoren rumgepopelt. Die Motore fahre ich "entlang" der Sprungantwort hoch und stelle fest, dass das ihrer Lebensdauer bekommt (sind ja diese 5ervos ohne irgendeine eigene Elektronik, nur mein 2-Blatt-Encoder) - aber in rund 20 ms ist die Drehzahl (und die Regelung) da - wenn etwa 50 .. 70 % volle Drehzahl angesteuert wird. Ok, ich habe im Dottie einen mega168 mit 20 MHz.
    Code:
    /* ===  Regelungsroutine für Motor 12  ========================================== */
    /* Die gemessene Zeitdifferenz Iz_diff0 wird zur Regelung verwendet   
                                                                                      */
      void rgl_mo_12(void)      // (Wird) Regelung für Motor 12
    {                               
    //  PORTC |=  (1<<PC4);           // LED auf PC4/I2C/SCA einschalten = Start ISR
    //  PORTC &= ~(1<<PC4);           // LED auf Port PC4/I2C/SCA ausschalten
    //  PORTC ^=  (1<<PC4);           // Zeitmessung: LED auf Port PC4/I2C/SCA toggeln
    
    // Anmerkung für mausi_mick:
    //        tupsi    = T imer U nits P er S ensor I nterrupts, Sensor = Encoder
    //       stupsi    = Soll-tupsi
    //       stupsi12  = Soll-tupsi für Motor 12 (12 = Ausgänge des L293D)
    //       idrz      = Ist-Drehzahl
    //                                         
      if (stupsi12 <= 5)            // Soll überhaupt gefahren werden?
      {                              
        OCR0A = 0;
        return;
      }                            
      tupsi12      = Iz_diff0;                      // Übernahme Iz-Wert in Regelung
      ndrz12       = stupsi12;
      if ( tupsi12 > 100 )  { tupsi12  = 100; }     // Eingrenzen
      idrz12      = 1000 / tupsi12;
      ie_mot12     = ndrz12 - idrz12;               // Vergleich => Regelabweichung
      iesum12      = iesum12 + ie_mot12;
      if  (iesum12 < -10) { iesum12  = -10;}
      if  (iesum12 >  500) { iesum12  =  500;}
      iy12         = iesum12/2;
      iy12         = iy12 + ie_mot12 + ie_mot12 + ie_mot12 + ie_mot12 + ie_mot12;
                    // Diese Rechenoperation benötigt in float 0,20 bis 0,25 ms!
                            
      if ( iy12    <   0 )   { iy12   =    0;}
      if ( iy12    > 255 )   { iy12   =  255;}
                    
      OCR0A = iy12;                 // Ansteuerung der PWM direkt statt "setPWMlinks"
    //  PORTC ^=  (1<<PC4);           // "war-hier-Signal": LED auf PC4 toggeln
                                        
      return;                          
    }               
    /* ============================================================================== */
    Meine Fähigkeiten in C (heisst bei mir immer noch Cäh) sind zwar recht gering und mein Code ist schauderhaft (nach interner Mitteilung eines Forummitglieds *ggggg*), aber vielleicht hilft Dir das etwas?
    Ciao sagt der JoeamBerg

  5. #85
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    12.07.2006
    Ort
    Puchheim
    Alter
    76
    Beiträge
    455
    hi oberallgeier,

    danke für Deine Regelungsroutine.

    Bin/war aber leider z.Zt. mit häuslichen Problemen (Toplader Waschmaschine stand "kopf" (Ladeöffung offen und unten, Trommel gefüllt, Wäsche nass, Trommel nicht drehbar, da Ladeklappen an Trommelwand verklemmt) und mit (Basic-)MonoWheel beschäftigt (hatte mir im Urlaub Gedanken gemacht, ob und wie man MW vielleicht doch noch zum Kurve fahren bringt).
    Dazu will ich erst mal den am Baby-MW eingesetzten Winkelsensor SCA61T anstelle der beiden Sharp-Abstandssensoren verwenden.
    Vorteil:
    Geringerer Stromverbrauch (< 5mA) , weniger Entstöraufwand
    Einbauposition/-ort beliebig (IC muss nur horizontal eingebaut werden),
    einfachere,kürzere Verdrahtung,
    geringeres Gewicht/Volumen
    höhere Genauigkeit (10 Bit Wandler ?)
    Senkrechte auch in geneigtem Gelände (Hang) erfassbar, wo Differnzabstandssensor versagt
    weniger Programmieraufwand, geringere MC-Belastung (nur ein AD-Wandler)
    Nachteil : Preis (kostet mehr al 50 € gegeüber ca 25€)

    Werd mich daher in der nächsten Zeit nicht mit dem ASURO-Kurven-Thema beschäftigen können.

    Gruß

    mausi_mick

Seite 9 von 9 ErsteErste ... 789

Berechtigungen

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

LiFePO4 Speicher Test