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

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.

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

Zitat:

Zitat von oderlachs

... 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

... 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.

Zitat:

Zitat von RoboHolIC

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 ;)

Zitat:

... 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)?

Liste der Anhänge anzeigen (Anzahl: 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..
Anhang 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

Hallo Gerhard

Zitat:

Zitat von oderlachs

... 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

Hier mein Testlaufprogramm ganz einfach erst mal :

Zitat:

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

}

Zitat:

Zitat von oderlachs

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.

wenn wir mal "tellen"... ich richte mich nach Deiner freien Zeit ;) erklär ich dir das mal kurz...bzw wenn mein Listing mit lfd Bemerkungen in den Zeilen fertig ist schicke ich Dir das per mail...das ist dann verständlicher..zunächst werde ich die Segmentscheibenauswertung machen, am Steckbord so als "Steckverkabelung"..
will da mal erst mittels FZä.. die Umdrehungen messen im Leerlauf...möchte dann so stück für stück weiterausbauen um ales zu verstehen was ich da mache und was sich dadurch tut...zumindestens alles was geht(..zu verstehen ;=) )

nochmals zur Erklärung den Codeschnipsel habe ich einfach genommen, um überhaupt erst mal zu erfahren was das Board und der Robo damit macht, erste Funktionskontrolle sozusagen...nur mal eben sehen ob die Motoren Laufen, das Board geht usw., ja auch wegen der Garantie :)

Gerhard

Edit 14.6.12: Heute ist die GLS auf der Lochraster fertig verdrahtet und getestet. Es stehen folgende Spannungspegel am Ausgang an:
1. Hell = 0,110V
2. Dunkel = 4,7V

Ich hoffe das dies zur Auswertung gehen wird, heute Abend werde ich das am FZ testen, zum Anbau auf das Chassis muss ich noch einen 3x10mm Schlitz in die Lpl. fräsen, mal sehen ob ich das ohne Fräsständer "Drehmeln" kann/schaffe

Edit 2: Die Messung der GLS-Impulse (Die Scheibe hat 6 Lichtschlitze) ergab bei beiden ca. 14,5 HZ , gemessen mit einem Multimeter mit f-messbereich, ich weiss das ist nicht Ideal, aber erst mal akzeptabel um allzugrosse Abweichungen zu erkennen.

Edit 3: ernüchterne Erkenntnis, ich weiss nicht was ich da an Frequenz gemessen habe, als ich nochmals die rein digitalen Werte messen wollte, durch lkangsames Drehen der Räder musste ich feststellen das sich nix ändert und die Segmentscheibe IR- u. Lichtdurchlässig ist....grolll, gräm...grrr

Zitat:

... ernüchterne Erkenntnis ... musste ich feststellen ... Segmentscheibe IR- u. Lichtdurchlässig ...

Stimmt, das hatten schon viele von uns mühselig gelernt - dass IR und sichtbares Licht zwei verschiedene Stiefel sind. Ich hatte das auch mal gerafft und dieses (klick) Torpedorohr aus Schrumpfschlauch durch Messingröhrchen ersetzt (klick). Mit Messing, später auch Alufolie gings dann perfekt.

Vielleicht war ich auch ein wenig übereifrig, denn es war ja Schutzfolie auf den Plastteilen vom Chassisbausatz. Doch anders hätte dies wieder nicht zwischen den Gabellichtschranken gepasst, die ich da hatte schienen wie dafür geschaffen von den Abmessungen. Auch habe ich wieder dazu gelernt, sowas vorher künftig zu testen und nicht erst alles auf ne Lochraster löten(...quetschen). Bin froh das ich das kurzschlussfrei mit meinen "guten Augen" hinbekommen habe. Eine Hand Lötkölbchen, andere die Lupe und den Zinnspender im Mund gehalten ;) .
Auf jeden Fall gefällt mir das besser als wie beim Asuro, will nix dagen sagen, aber so ist ales fast aus eigenen Ideen und Vorstellungen entstanden, wenn ich auch so einiges an vorgefertigten Teilen/Modulen verwende. Früher hätte ich das Board vielleicht noch selber geätzt, gelötet usw. und das Chassis auch noch selber ausgesägt...geht leider nicht mehr.
Bis es weiter geht muss ich auf Schrauben warten, habe nicht genügend lange M2 Schrauben, um die "Stirntaster" zu montieren, falls der Robby mal gegen die Wand rennt... ;)
Fotos über Arbeitsfortschritte folgen im Web...
Gruss Gerhard

Ja es ist schon ein Vietrteljahr wieder ins Land gegangen, die Gartenarbeiten werden weniger, die am Roboter dafür mehr...siehe Roboduino Webseite unter News und Fotogalerie.
Auch habe ich das mit dem Drama der Segmentscheiben hinbekommen in Sachen Odometrie. Scheiben sind mit selbstklebender Alufolie (Baumarkt oder Klempnerei)
überklebt und beide GS auf einen Interrupteingang zw. Zählung der Umdrehungen gelegt.
Zunächst habe ich erst mal eine optische Kontrolle der beiden Lichtschranken gebaut zum testen, die Motorsteuerung dadurch kommt später. Ist ja mein erstes Eigenkonzept.
Hier die prüfcode :

Code:

/* ========================================================================== */ /* */ /* interrupt_test1.c */ /* (c) 2012 Gerhard Hinze */ /* */ /* Description */ /* This example code is in the public domain. */ /* ========================================================================== */ void setup() { pinMode(12, OUTPUT); //LED 1 (left) pinMode(13, OUTPUT); //LED 2 (right) attachInterrupt(0, blink_l,LOW); // Gabellichtschranke linker Antrieb attachInterrupt(1, blink_r,LOW); // Gabellichtschranke rechter Antrieb } void loop() { } void blink_l() // Gabellichtschranke links schaltet { if ( digitalRead(12)!= true) { digitalWrite(12, HIGH); //LED Green } else { digitalWrite(12,LOW); } } void blink_r() // Gabellichtschranke rechts schaltet { if ( digitalRead(13)!= true) { digitalWrite(13, HIGH); //LED Red } else { digitalWrite(13,LOW); } }

Wer Fehler und Mängel findet oder Anregungen hat, da bin ich dankbar für eine Antwort

Zitat:

Zitat von oderlachs

... die Griffigkeit der Reifen ist, die da unterschiedlicher Art, trotz gleicher Reifen ...

Na ja, dieses Problem hatte ich auch mal (klick - und lesen nach "...Verzögerungen gabs massenhaft..."). Geholfen hatten bei mir Lagen eines alten Fahrradschlauchs, die konnten mit wenig Zug auf den erforderlichen Durchmesser gebracht werden. Tip: man kann einen Schlauch auch in Streifen passender Breite und Länge zerschneiden und zu einem Ring stumpf (!!! - genau - an den Schnittkanten) zusammenkleben mit Sekundenkleber. Hält bombenfest - wenn die Schnittfläche sehr gerade und glatt ist / Rasierklinge / , fettfrei natürlich etc. Achtung: beim Zusammenpressen der Endstücke besteht die Gefahr mit den Fingern kleben zu bleiben . . . (Erfahrungsbericht: hatte mal auf diese Weise einen durchgeriebenen Gummi-Flachriemen für eine Staubsauger-Walzenbürste geklebt - hielt danach noch so vier oder fünf Jahre, bis zum Ende des Staubsaugers).