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.