Dagu 4 Channel Motorcontroller

[MEgg]

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:


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.

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

Wenn nichts anderes geht, dann muss das reichen.

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

[MEgg]

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!

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.

[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?

[MEgg]

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:


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.