Dagu 4 Channel Motorcontroller

Hi,

Zitat:

---

"GENAU" ist das sicher nicht, da mit blossem hinschauen bestimmt, ich könnte noch ne Lichtschranke o.ä. bauen und dann noch mal messen, aber da ich keine Brille brauche, wird das so ungefähr schon passen.

---

Was ich sagen wollte: Es ist kaum möglich, EINE Umdrehung mechanisch genau abzumessen und danach die Encoderflanken zu beurteilen. Nicht umsonst geht es ja eigentlich anders herum: Wenn du den Motor bei 0 Flanken startest und es schaffst, ihn bei 1000 Flanken anzuhalten, müssen lt. Datenblatt 3 Umdrehungen des Abtriebs zu sehen sein.
Die Daten sind mir sowieso nicht ganz klar: Wenn es 333 Flanken pro Umdrehung sein sollen, dann könnte der Encoder ein Quadratur Typ sein und auf der Motorseite sitzen. Dann hieße das: 333/4 oder 1000/12 = 83,3. Demnach hätte das Getriebe eine etwas andere Übersetzung als angegeben (86,8:1). Egal, aber ...
Wenn du das genauer wissen willst:
Schreib ein Programm, das den Motor bei Null Flanken startet und dann bei 10000 anhält (vor dem Ende langsam auf PWM 0 runterregeln). Wenn das dann 30 Umdrehungen sind, stimmen die Angaben. Sind es nur 28,8, dann stimmt die Angabe zur Getriebeübersetzung (86,8:1), aber nicht die zur Flankenzahl je Umdrehung (dann 347).

Zitat:

---

Wenn ich interrupts verlieren würde, würden die Werte imho keine Gerade ergeben.

---

Wenn der Verlust an Impulsen auch linear ist: Klar.

Ich habe es eben pi daumen mit 3 Umdrehungen gemessen.
Der eine Motor zeigt bei den XORd encoder values via interrupt 1015, was eh ca ok wäre, da ich nur so pi Daumen stoppen kann.
Der andere Motor zeigt 379 !

Hi,

Zitat:

---

Der andere Motor zeigt 379 !

---

Klingt nicht gut.
Und die anderen (du hast ja wohl 4 Encoder-Motoren)?

Zitat:

---

Zitat von Dirk

Hi,

Klingt nicht gut.
Und die anderen (du hast ja wohl 4 Encoder-Motoren)?

---

Erst mal: Danke für Deine Hilfe.

Ja, ich hab diese Kombination:
http://robosavvy.com/store/dagu-rove...-encoders.html

Die anderen Werte habe ich wie gesagt nur mit 1 Umdrehung:
Motor 1 : 320
Motor 2 : 236
Motor 3 : 320
Motor 4 : 280

Ich hab auch hier nachgefragt:
http://letsmakerobots.com/blog/budry...comment-133798

Dort meint einer, dass er strikt nur 333 als Wert hat...
Ich bin jetzt einigermassen ratlos.
In einem 3.Forum ist einer der Hersteller (OddBot) unterwegs, ich warte mal, bis der sich meldet.

Den Support von http://robosavvy.com hab ich auch angeschrieben, da auf der Spider Karte ein paar Pins verbogen sind.
Die sind recht hilfreich ansonsten.
Mal sehen, was dabei rauskommt.

Hi,
das hier:

Zitat:

---

Rover 5 Encoder and Motor Specifications:
-----------------------------------------------------------------------

Motor speed: 8,500RPM @ 7.2V
Motor stall current: 2.5A
Output shaft stall torque: 10Kg/cm
Gearbox ratio: 86.8:1
4.166:1 motor -> encoder
20.833:1 encoder -> wheel (two gears: 4.166:1 & 5:1)

Encoder type: Quadrature, hall effect magnetic
Encoder resolution: 166.66 state changes per wheel rotation
Encoder Speed: 272 state changes/sec at 8,500RPM

Drive Wheel Rotational Speed: 1.632 rev/sec @ 7.2V
Drive Wheel Circumference = 7.5" roughly (7.4 - 7.8 )
Rover 5 Speed: roughly 12"/sec.

---

... war doch sehr aufschlußreich.
Die Encodermotoren des Rover 5 haben also praktisch ZWEI Getriebe bzw. ein Getriebe, in dem der Encoder eine "Zwischenübersetzung" misst.
Gesamtübersetzung = 4,166 * 20,833 = 86,8 : 1 (das ist eher uninteressant!)
Übersetzung zwischen Encoder und Radachse: 20,833 : 1 (das ist wichtig!)

Bei XOR der Quadraturencoderausgänge gibt es 16 Impulsflanken.
Damit pro Radachsen-Umdrehung: Flanken = 20,833 * 16 = 333,3 (somit 1000 auf 3 Umdrehungen).

Bei einem Radumfang von 403mm (das sind die Räder vom Wild Thumper, oder?) wäre das eine Encoder-Auflösung von: 1,2mm
Das ist doch ganz gut zum Weiterrechnen!

Zitat:

---

Zitat von Dirk

Hi,
das hier:

... war doch sehr aufschlußreich.
Die Encodermotoren des Rover 5 haben also praktisch ZWEI Getriebe bzw. ein Getriebe, in dem der Encoder eine "Zwischenübersetzung" misst.
Gesamtübersetzung = 4,166 * 20,833 = 86,8 : 1 (das ist eher uninteressant!)
Übersetzung zwischen Encoder und Radachse: 20,833 : 1 (das ist wichtig!)

Bei XOR der Quadraturencoderausgänge gibt es 16 Impulsflanken.
Damit pro Radachsen-Umdrehung: Flanken = 20,833 * 16 = 333,3 (somit 1000 auf 3 Umdrehungen).

Bei einem Radumfang von 403mm (das sind die Räder vom Wild Thumper, oder?) wäre das eine Encoder-Auflösung von: 1,2mm
Das ist doch ganz gut zum Weiterrechnen!

---

Yep, das sind diese Räder:
http://robosavvy.com/store/dagu-pack...ic-silver.html
Schaut dann so aus:
Anhang 30773

Das habe ich mir auch schon ausgerechnet, dass die "Fahrgenauigkeit" um die 1.59mm ist,
wenn bei mir der kleinste encoder Wert bei einer Umdrehung ca 236 ist.

U = π · d = π * 120mm = 376,991118431mm / 236=1,59741999335 mm / encoder Wert.

Wenn nichts anderes geht, dann muss das reichen.

Diese Räder habe ich auch auf meinem Wild Thumper 6WD.
Ich hatte auch so gerechnet wie du, hatte dann aber eine Abweichung, die ich mir nicht erklären konnte. Dann habe ich mal den Umfang nachgemessen: 403 mm (mit Spikes und auf hartem Grund, also ohne Eindrücken von Spikes und Profil in den Grund).

Zitat:

---

Wenn nichts anderes geht, dann muss das reichen.

---

Wenn dir das irgendwann doch nicht reichen sollte:
-> Dein Programm zur Auswertung der Encoder komplett posten.

Zitat:

---

Zitat von Dirk

Diese Räder habe ich auch auf meinem Wild Thumper 6WD.
Ich hatte auch so gerechnet wie du, hatte dann aber eine Abweichung, die ich mir nicht erklären konnte. Dann habe ich mal den Umfang nachgemessen: 403 mm (mit Spikes und auf hartem Grund, also ohne Eindrücken von Spikes und Profil in den Grund).

---

Die haben das anscheinend wirklich ohne die Spikes gemessen!

Zitat:

---

Zitat von Dirk

Wenn dir das irgendwann doch nicht reichen sollte:
-> Dein Programm zur Auswertung der Encoder komplett posten.

---

Da ist nichts besonders.
Die Interrupt-Routine zählt nur eine volatile unsigned long Variable hoch, die ich im Testprogramm ausgelesen habe.
Der robosavvy-Support, bei denen ich das gekauft hatte und der übrigens sehr schnell antwortet, fragt mich das auch schon zum 2.Mal.
Ausser einem z.B.
void encodercountHR_intproc()
{
encodercountHR++;
}

mit
void setup()
{
...
attachInterrupt(digitalPinToInterrupt(MOTOR_HR_INT ), encodercountHR_intproc, CHANGE);
...
}
gibt es da nicht viel.
Das ganze Programm hat auch keine delay() drin und wenn ich interrupts verlieren würde, müsste das bei allen Motoren relativ gleichmässig sein.
Wenn ich den Rover stoppe oder die Richtung wechsle, setze ich die encodercountHR auf Null, die Richtung wird durch eine Boolean festgehalten.
Dass die Motoren noch eine Weile weiterlaufen, wenn ich sie stoppe und dadurch noch ein paar Ticks hochzählen, hattest Du sicher auch.
Anscheinend ein relativ grosses Trägheitsmoment je nach Reifengewicht und Geschwindigkeit - logo.

Die Ausschnitte sehen erstmal gut aus, wobei ich den Dagu Controller nicht habe und somit Defines wie MOTOR_HR_INT nicht kenne und nicht genau weiß, an welchen µC-Pins deine Encoder sitzen.
Zumindest ist klar: Du liest Interrupt-basiert ein, demnach dürften alle Impulsflanken (CHANGE) erfasst werden.

Wenn du nur zwischen 300 und 350 Impulse pro Umdrehung zählst, stimmt etwas anderes nicht.

Bist du z.B. sicher, dass du die Encoder des Rover 5 (alle 4 Pins je Rad !) mit dem Eingang des Dagu Controllers (GND, Encoder Input A, Encoder Input B, +5V) verbunden hast?
Wenn nein: Korrigieren.
Wenn ja: Weiter ->

Bist du z.B. sicher, dass du den Arduino-Eingangspin für die Encodersignale mit dem Ausgang "Interrupt Output" des Dagu Controllers für alle 4 Räder verbunden hast?
Wenn nein: An den einzelnen Ausgängen (Encoder Output A/B) liegen nur die Einzelsignale der Encoder an, das würde gut zu deinen 3xx Impulsen pro Umdrehung passen und dein Problem erklären.
Wenn ja: Schließ mal probeweise den Einzelausgang (Encoder Output A oder B) an den Arduino-Eingangspin an: Was passiert? Wieviele Impulse pro Umdrehung?

Zitat:

---

Zitat von Dirk

Die Ausschnitte sehen erstmal gut aus, wobei ich den Dagu Controller nicht habe und somit Defines wie MOTOR_HR_INT nicht kenne und nicht genau weiß, an welchen µC-Pins deine Encoder sitzen.
Zumindest ist klar: Du liest Interrupt-basiert ein, demnach dürften alle Impulsflanken (CHANGE) erfasst werden.

Wenn du nur zwischen 300 und 350 Impulse pro Umdrehung zählst, stimmt etwas anderes nicht.

Bist du z.B. sicher, dass du die Encoder des Rover 5 (alle 4 Pins je Rad !) mit dem Eingang des Dagu Controllers (GND, Encoder Input A, Encoder Input B, +5V) verbunden hast?
Wenn nein: Korrigieren.
Wenn ja: Weiter ->

Bist du z.B. sicher, dass du den Arduino-Eingangspin für die Encodersignale mit dem Ausgang "Interrupt Output" des Dagu Controllers für alle 4 Räder verbunden hast?
Wenn nein: An den einzelnen Ausgängen (Encoder Output A/B) liegen nur die Einzelsignale der Encoder an, das würde gut zu deinen 3xx Impulsen pro Umdrehung passen und dein Problem erklären.
Wenn ja: Schließ mal probeweise den Einzelausgang (Encoder Output A oder B) an den Arduino-Eingangspin an: Was passiert? Wieviele Impulse pro Umdrehung?

---

Ja, jeder Interrupt Output ist mit einem Interrupt input des Spider controllers verbunden und jeder Anschluss des Dagu Rovers (rot, gelb, weiss,schwarz)
ist mit dem 4CH Motor Controller verbunden.
Sieht momenant etwas drahtigelig aus, ich muss das aber sowieso noch mal umbauen:
Anhang 30795

Die 2 violetten, der blaue und der abgedeckte grüne Anschluss sind die Interrupt-Anschlüsse.

Damals habe ich zum Testen aber jeden Motor einzeln an einen bestimmten Pin gehängt, damit fällt weg, dass dieser Pin das hätte beeinflussen können oder die Software am Arduino den Fehler verursachen
würde.
Den einzelnen Anschluss von Encoder Output A und B wie auf
http://dlnmh9ip6v2uc.cloudfront.net/...n%20manual.pdf
dargestellt, habe ich schon probiert, aber ich werde das noch mal machen.