- Labornetzteil AliExpress         
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 15

Thema: Magician Geradeausfahrt und wieder nicht....warum

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Erfahrener Benutzer Roboter Genie Avatar von oderlachs
    Registriert seit
    17.05.2010
    Ort
    Oderberg
    Alter
    73
    Beiträge
    1.175
    Blog-Einträge
    1

    Magician Geradeausfahrt und wieder nicht....warum

    Hallo Freunde!

    Ich habe mir für die ersten Eigenentwicklungen an Steuerprogrammen und Sensortest das Dagu-Magician-Chassis und dazugehörigen Controler gekauft.
    Das Teil lässt sich gut per Arduino IDE oder auch per ISP programmieren.
    Nun habe ich zu allererst wohl ein mech. Problem, anstatt ein elektronisches wegen noch fehlender Odometrieauswertung.

    Der Roboduino, so hab ich ihn getauft, fährt auf textilen Belag einwandfrei, aber auf Fliesen oder anderen blanken Fussbodenbelag fängt er an Kurven zu fahren.

    Was kann ich da machen? ich denke das es die Griffigkeit der Reifen ist, die da unterschiedlicher Art, trotz gleicher Reifen, ist.
    Vieleicht weiss jemand einen Ausweg oder Hinweis...

    Danke Gerhard
    Geändert von oderlachs (09.06.2012 um 17:35 Uhr)
    Arduinos, STK-500(AVR), EasyPIC-40, PICKIT 3 & MPLABX-IDE , Linux Mint

  2. #2
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    02.09.2009
    Ort
    Berlin (Mariendorf)
    Beiträge
    1.023
    Kannst du die Drehzahl per Oszi bzw. Multimeter messen. Evtl. ist die reibungsarme Quasi-Leerlaufdrehzahl der Motoren signifikant unterschiedlich. Die größere Rollreibung auf textilen Untergründen könnte diese Feinheiten überdecken. (Mein von gehackten Servos ungeregelt angetriebener Robidoff fährt auf Dichtringen nach dem Kaltstart sogar über die Zeit hinweg reproduzierbar unterschiedliche Kurvenradien auf PVC-artigem Bodenbelag.)

    Bei moderatem Gewicht und derart breiter Bereifung scheint mir Hartgummi oder "Weichplastik" (wird bei Spielzeug bisweilen verarbeitet) chancenlos. Was für dein Automobil gut ist, hilft auch dem Robi: weicher, gut eingefahrener, rauher Gummi. Evtl. kann man ja die Originalräder nacharbeiten, also die Laufflächen gründlich einebnen und rauh schleifen. Andernfalls griffigeren Belag aufkleben: Gummibänder von den Postzustellern, Fahrradschlauch, provisorisch: Fensterdichtungsband.

  3. #3
    Erfahrener Benutzer Roboter Genie Avatar von oderlachs
    Registriert seit
    17.05.2010
    Ort
    Oderberg
    Alter
    73
    Beiträge
    1.175
    Blog-Einträge
    1
    Hallo RoboHolIC !

    Vielen Dank für Deine Hinweise, ich muss mal sehen habe noch ein paar Räder mit Gummimantel, ob diese auf die Achse passen. Nein einen Osszi habe ich nicht zur Verfügung , jedenfalls nix Modernes. Ich will in meinem Alter auch nix mehr dahingehend neu kaufen und "Billig-Plunder" wäre rausgeschmissenes Geld. Habe noch ein "Grossvater-Modell" mit Röhren glaube ich noch, vieleicht kann ich den dazu bewegen zu Messen, 2 Kanäle hat er ja...
    Vieleicht könnte ich auch die Frequenz der Pulse messen, aber da denke ich nicht viel mit beweisen zu können, da eine Pulsbreite da nicht messbar ist, wo es ja drauf ankommt.
    Habe noch 2 Fairchild GabelLichtschranken, mal sehen ob ich die an den beiden Lochrasterscheiben auf der Achse gutgehend befestigen kann, um ein brauchbares Ergebnis zu liefern, diese jedoch kann ich dann mittels F-Messung auswerten.
    Werte das Ergebnis hier posten, damit Du auch erfährst was das "Corpus Delikti" war.

    Gruss und Dank

    Gerhard
    Arduinos, STK-500(AVR), EasyPIC-40, PICKIT 3 & MPLABX-IDE , Linux Mint

  4. #4
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    02.09.2009
    Ort
    Berlin (Mariendorf)
    Beiträge
    1.023
    Zitat Zitat von oderlachs Beitrag anzeigen
    ... in meinem Alter auch nix mehr dahingehend neu kaufen ...
    Nanana! Und was wäre, wenn es hülfe, die naturgegeben begrenzte Lebenszeit frustärmer zu gestalten?
    Zitat Zitat von oderlachs Beitrag anzeigen
    ... rausgeschmissenes Geld.
    Aber doch nur für deine Erben, oder?
    Ganz im Ernst: Auf einfachem Bastlerniveau ist selbst ein "Opaskop" gegenüber einem DMM ein Quantensprung in der Fehlersuche. Alleine die Prüfmöglichkeit, ob man eine "saubere" Versorgungsspannung hat, ist oft Gold wert - aber so teuer braucht es dafür nichtmal zu sein!

    Vorüberlegung, ausgehend von einem Asuro-ähnlichen Antrieb mit Gleichstrommotoren und Getriebe:
    Es gibt es eine ganze Reihe von Störeinflüssen, die nicht kontrollierbar sind:
    - im Fahrzeug: Schmiersituation, Staub und Haare im Getriebe, Temperaturabhängigkeiten in der Mechanik, der Energiequelle und bei den Halbleitern...
    - in der Umwelt: unterschiedliche Rollreibung links und rechts, Unebenheiten/Hindernisse

    Die beiden Räder werden ohne Drehzahlregelung nie reproduzierbar genau gleich schnell drehen. Genauer betrachtet ist sogar eine Winkelsynchronität und folglich eine Lageregelung der Räder erforderlich, damit sich die Fehler der Drehzahlregelung nicht zu einer Kurvenfahrt aufsummieren können. Eine der Drehzahlregelung übergeordnete Lageregelung sorgt bei Geradeausfahrt für die Gleichheit der jeweils aufsummierten Zählpulse von beiden Rädern. Die Wirkung ist im Idealfall dieselbe wie beim Sperren des Differentials im Geländewagen.

    Eine andere Möglichkeit wäre der Antrieb mittels winkelsynchron steuerbaren Motoren, vulgo: Schrittmotoren. Das liefe aber auf eine mechanische Neukonstruktion hinaus und ist damit Off Topic. Bietet zudem vergleichsweise schlechten Wirkungsgrad und eher niedrige Fahrgeschwindigkeiten.

    In beiden Fällen bleibt der allgegenwärtige Schlupf als theoretische Störquelle. Bei günstiger Materialpaarung von Rad und Untergrund (z. B. Gummi / Laminat) ist er oft unbedeutend.

  5. #5
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    31.05.2009
    Beiträge
    270
    Zitat Zitat von RoboHolIC Beitrag anzeigen
    Die beiden Räder werden ohne Drehzahlregelung nie reproduzierbar genau gleich schnell drehen. Genauer betrachtet ist sogar eine Winkelsynchronität und folglich eine Lageregelung der Räder erforderlich, damit sich die Fehler der Drehzahlregelung nicht zu einer Kurvenfahrt aufsummieren können. Eine der Drehzahlregelung übergeordnete Lageregelung sorgt bei Geradeausfahrt für die Gleichheit der jeweils aufsummierten Zählpulse von beiden Rädern. Die Wirkung ist im Idealfall dieselbe wie beim Sperren des Differentials im Geländewagen.
    .....gibt es u.a. hier: https://www.roboternetz.de/community...ler-PID-Bascom
    mfG
    Willi

  6. #6
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.652
    ... wohl ein mech. Problem, anstatt ein elektronisches wegen noch fehlender Odometrieauswertung ...
    Hallo Gerhard, fehlt Dir nur die Auswertung oder hast Du keine(n) Odometriesensor(en)?
    Ciao sagt der JoeamBerg

  7. #7
    Erfahrener Benutzer Roboter Genie Avatar von oderlachs
    Registriert seit
    17.05.2010
    Ort
    Oderberg
    Alter
    73
    Beiträge
    1.175
    Blog-Einträge
    1
    Hallo JoeAmBerg !
    Freu mich Dich wieder mal zu lesen...
    Ich denke es liegt erstens am Material der Bereifung, zweitens dann daran fdas nicht die Umdrehungszahl kontrolliert und ausgewertet wird. Ich habe mir jetzt aus zwei Gabellichtschranken einen Sensor für die Lochscheiben auf den Achsen gebastelt(siehe Foto).
    Nun muss ich noch sehen wie ich das ganze Softwaremässig einbinde in das Grundprogramm. ich habe dahingehend noch nix selber "gecodet", auch noch nicht so richtig dafür Beispiele/Anregungen gefunden..
    Klicke auf die Grafik für eine größere Ansicht

Name:	odometrie.jpg
Hits:	16
Größe:	69,9 KB
ID:	22568

    Als erstes möchte ich in einer Messschaltung feststellen, ob schon rein elektrisch/mech. von der Umdrehung her schon Unterschiede zwischen den beiden Motoren besteht. Nur fehlt momentan die Zeit um kontinuierlich daran durchweg zu arbeiten.

    Gruss Gerhard
    Arduinos, STK-500(AVR), EasyPIC-40, PICKIT 3 & MPLABX-IDE , Linux Mint

  8. #8
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.652
    Hallo Gerhard

    Zitat Zitat von oderlachs Beitrag anzeigen
    ... aus zwei Gabellichtschranken .. Sensor für die Lochscheiben auf den Achsen ...
    Na prima, damit kann man ja schon ne ganze Menge anfangen. Hier mal kurz skizziert wie ich meine Geschwindigkeiten und Wege messe.

    1. Ein Timer mit 50 µs - bei meinen 20 MHz-Controllern habe ich also satte 1000 Maschinenzyklen zwischen den Timer-Interrupts. Der Timer zählt diese Zeitscheiben (timer units) hoch bis zu - sagen wir 20 000 - danach wird er auf "Eins" gesetzt. Der Timer wird mit dieser Interruptserviceroutine "ausgelesen".


    Code:
    // ============================================================================== =
    // ===  Nicht unterbrechbare ISR für timer2 ===================================== =
    // Routine zählt hoch im Takt 20 kHz = 50 µs.  Der Zählerwert wird von den ISR für
    //      EXT_INT0 und -INT1 ausgelesen und den Werten Iz_yseci zugewiesen.
    ISR(TIMER2_COMPA_vect)          // Vektor 7
    {
      if (Izeit_1 < Izthrznt)       //Interrupt-Timer = 0 ... 19 999 ... (1 sec blink)
                                    //  Izthrznt ist der Zeithorizont, meist 19 999
                                    //      entsprechend einer Sekunde
                                    //  Izeit_1 ist die "Bordzeit" als Teil einer Sek
      {                             //
        Izeit_1 ++;                 //  ###>>> Izeit_1 ist aktuell int16_t ==>>
               //  Izeit_1 bleibt bis 32000 in der int16-Grenze
      }                             //
      else                          //
      {                             //
        Izeit_1 = 1;                // ansonsten: Rückstellen auf Eins
      }                             // Ende if (Izeit_1 < Izthrznt)
    // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     return;
    }                               //
    // ============================================================================== =
    2. Ein Interrupt (hier bei steigender Flanke der Gabellichtschranke) ausgelöst am Eingang EXT_INT1 (und für den anderen Motor auf EXT_INT0. Die Zeitscheiben zwischen zwei Interrupts werden notiert z.B. als Iz_ysec1 => Istzeit_für_mot_1. Ausserdem wird gleich die Zeitdifferenz zwischen zwei Interrupts berechnet, damit kann schnell die Drehzahl berechnet werden. Beachte: die vierflügelige Encoderscheibe wird nur bei jedem zweiten Schlitz ausgewertet => das ist die Zeit für eine halbe Motorumdrehung. Diese Zeitscheiben nenne ich in meinem Programm tupsi (t imer u nits p er s ensor i nterrupt) - das ist also eine inverse Geschwindigkeit. Und die Vorgabe dazu sind die stupsi - Soll-tupsi.

    Anmerkung: Es gibt alle Sekunden einen Rechenfehler durch den Zeitüberlauf von Izeit_1. Der wird aus Gründen der Rechengeschwindigkeit vernachlässigt, der dadurch entstehende Fehler stört in der Praxis nicht. Fehlerhäufigkeit ist dabei durchschnittlich 0,5% der Encoderzeit-Messungen.


    Code:
    // ============================================================================== =
    // ===  Nicht unterbrechbare ISR für EXT_INT1 auf Pin 5/PD3/mega168  ============ =
    // Routine setzt einfach einen Zähler hoch.
    //      Diese Encoderroutine schreibt die verstrichenen Zeiteinheiten zu 50µs auf,
    //        die seit dem letzten Encoder-Interrupt verstrichen sind.
     ISR(INT1_vect)                         // hiess mal: ISR(SIG_INTERRUPT1)
     {                                      // 
        if (nenc1     <  mxnc1)             // mxnc1 ist eine Art "Divisor" für die 
                                            //   Encoderscheibe => es wird nur jeder 
                                            //   mxnc1-te (hier 2) Scheibentick gezählt
        {                                     
          nenc1       =  nenc1 + 1;         // Interrupt hochzählen (4-Flügel-Encoder)
          Lncdrges1   ++;                   // Gesamte Encoderticks einfach hochzählen
        }                                     
        else                                    
        {                                   // Zähle NUR jeden vierten Interrupt
          nenc1       =  1;                     
          Iencdr1 ++;                       //zähle Counter/encoder1 hoch
          Ienc1alt  = Iencdr1;                   
          Iz_yseci1 = Izeit_1;              //Weise Iz_ysec1 dem akt. Timerwert zu
          Iz_diff1  = Iz_yseci1-Iz_ysecv1;  //Neue Zeit-Differenz1 ausrechnen
          Iz_ysecv1 = Iz_yseci1;            //der aktuelle Zeitwert wird "Alter"
    // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    //    Es werden jetzt die aktuellen Daten festgehalten für Messfahrt
        }                                     
     }
    // ============================================================================= =

    Nun habe ich manchmal in einem kurzen Testlauf at runtime in der ISR (zu Punkt 2) die Encoderzeiten = Zeitbedarf für eine halbe Motorumdrehung, in einem hundertelementigen Feld festgehalten, dazu die fortlaufende Bordzeit (wegen der späteren Diagramm-Zeitachse) und nach dem Testlauf die Daten über UART ausgegeben. Damit kann ich prächtig die beiden Motoren auf Gleichlauf und sonstige dynamisch interessante Eigenschaften prüfen.

    In diesen Messfahrten (klick für Beschreibung und Diagramme) habe ich das simultane Anfahren meiner Motörchen getestet, Fehler festgestellt und behoben *ggg*.

    Und hier (klick mal) habe ich beschreiben, wie ich die Reifen für meinen WALL R so griffig mache, das ich Rutschen verhindern kann (seit diesem Postings fahren die Formel1-Piloten mit Soft, Supersoft, Inter etc *ggg*).

    Natürlich kann ich mit alle dem NUR die Umfangsgeschwindigkeit der Antriebsräder berechnen/messen. Der Schlupf verhindert, dass diese Geschwindigkeit auch zu 100,000 % die wahre Fahrgeschwindigkeit des zugehörigen Rades ist :-/

    Viel Erfolg
    Geändert von oberallgeier (12.06.2012 um 16:30 Uhr) Grund: Hinweis auf Schlupf der Antriebsräder
    Ciao sagt der JoeamBerg

  9. #9
    Erfahrener Benutzer Roboter Genie Avatar von oderlachs
    Registriert seit
    17.05.2010
    Ort
    Oderberg
    Alter
    73
    Beiträge
    1.175
    Blog-Einträge
    1
    Hier mein Testlaufprogramm ganz einfach erst mal :


    int MLD = 7; //Motor Links Richtung (Low/High)

    int MLV = 9; //Motor Links Speed (0...255)

    int MRD = 8; //Motor Rechts Richtung (Low/High)

    int MRV = 10; // Motor Rechts Speed (0..255)

    void setup() {

    pinMode(MLD, OUTPUT); // Left direction

    pinMode(MLV, OUTPUT); // left speed

    pinMode(MRD, OUTPUT); // Right direction

    pinMode(MRV, OUTPUT); // right speed

    }



    void loop () {



    digitalWrite(MLD,HIGH); // Dir Vorwärtz

    digitalWrite(MRD, HIGH); // Dir Vorwärtz

    analogWrite(MLV, 200); //PWM Speed Control

    analogWrite(MRV, 200); //PWM Speed Control



    }
    Arduinos, STK-500(AVR), EasyPIC-40, PICKIT 3 & MPLABX-IDE , Linux Mint

  10. #10
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.652
    Zitat Zitat von oderlachs Beitrag anzeigen
    Hier mein Testlaufprogramm ganz einfach ...
    Einfache Tests ziehe ich immer den komplizierten vor.

    Eins ist mir bei Deinem Programmschnippsel nicht klar - aber ich kenne/kann eben nicht den arduino-Dialekt: die Routine void loop ist ja kein loop sondern ein einfaches Setzen von Geschwindigkeiten und Drehrichtungen !? Ich kann mir eben nix vorstellen unter dem Befehl digitalWrite oder analogWrite. Wird da etwas geschrieben? Ich vermute daß damit nur die eben genannten Werte für den Motortreiber gesetzt werden.

    Nur mal so: wenn Du beim Testen aktuelle Daten über UART ausgibst, dann wird das nicht sehr zeitnah sein - weil die serielle Ausgabe eben dauert - im Vergleich zu ner millisekundenlangen (oder eher -kurzen) Motorzeitkonstante.
    Ciao sagt der JoeamBerg

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. lenkung bei 90% geradeausfahrt
    Von schwabe84 im Forum Mechanik
    Antworten: 3
    Letzter Beitrag: 17.10.2008, 02:23
  2. Odometriewerte - Geradeausfahrt
    Von harry3 im Forum Asuro
    Antworten: 5
    Letzter Beitrag: 05.07.2007, 17:47
  3. Wieder Probleme mit dem Brenner. Warum?
    Von tornado im Forum PIC Controller
    Antworten: 8
    Letzter Beitrag: 22.06.2007, 17:00
  4. Geradeausfahrt programmieren
    Von Moebius im Forum Asuro
    Antworten: 11
    Letzter Beitrag: 13.06.2007, 14:54
  5. Geradeausfahrt
    Von Jon im Forum Software, Algorithmen und KI
    Antworten: 8
    Letzter Beitrag: 30.04.2007, 12:48

Berechtigungen

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

12V Akku bauen