Druckbare Version
Wer hat Erfahrungen mit den Dagu 4 Channel Motorcontroller ?
Ich habe Probleme mit der Drehzahlerkennung bzw auch dessen Auswertung, finde einfach keinen Anfang es in der Programmierung dazu. Er soll bei enem Rover 5 /2WD zur anwendung kommen.
Vieleicht hat wer Hinweise ?
Ich danke für event. Unterstützung Eurerseits .
Gruss Gerhard
Nein leider keine Ahnung, aber wenn du bei der Seite was bestellst, würde ich vielleicht was mit bestellen :)
Bestellen ?? Nein, leider, habe kein Limit mehr in der Hobbykasse :(
Habe ich leider auch feststellen müssen ;-(
Hallo Gerhard,
der Dagu 4Ch Motor Controller liefert dir ein Quadratur Encoder Signal (2 Rechteck Signale um 90° verschoben) wie es auch Drehgeber oder Inkrementalgeber liefern. Zusätzlich gibt es auch noch ein einzelnes Signal, die Veroderung beider QE Signale.
Für meinen Ardubot habe ich mal eine Arduino Library geschrieben, die Quadratur Encoder mit Timer Interrupt ausliest. Die sollte auch für deinen Encoder funktionieren. Der Code basiert auf dem Drehgeber Artikel aus dem Mikrocontroller.net: http://www.mikrocontroller.net/articles/Drehgeber
Meine Arduino Library findest du hier: https://code.google.com/p/robotfreak...runk%2Fardubot
Das WriteLMR Sketch benutzt die QEs. Ist aber atwas umfangreich:
https://code.google.com/p/robotfreak...R/WriteLMR.pde
Bei Bedarf kann ich auch noch ein einfacheres Beispiel Sketch liefern.
Hallo marvin!
ich danke Dir ganz herzlichst !!
ich werde sowie gleich zeit dafür ist, das ganze ausprobieren und wenn ich darf deine code bei mir mit einarbeiten und verwenden.
Gruss und dank
Gerhard
Ich steige mal verspätet ein.Zitat:
Zitat von oderlachs
:-)
Ich verwende diese 4 CH Dagu Motor Controller Karte:
http://dlnmh9ip6v2uc.cloudfront.net/...n%20manual.pdf
für den Dagu 5 4 Motor 4 Encoder und habe einen Spider Controller vorgeschaltet:
cdn.sparkfun.com/datasheets/Robotics/SpiderControllerDagu.pdf
Auf der Spiderkarte werkelt ein Arduino Mega 2560.
Ich lasse in einer interrupt routine einen zähler (volatile unsigned long encodercount) hochzählen und setze den auf 0 zurück, wenn ich stoppe.
Das funktioniert so weit gut.
Eine Zeitauswertung Zeit in ms und encoderwerte über die vorgeschaltene Spider Karte und einen raspberry ergab, dass die encoder-Werte schön linear
und ohne Aussetzer sind.
Allerdings musste ich feststellen, dass die Angabe 1000 Werte pro 3 Umdrehungen von hier:
https://drive.google.com/file/d/0B__...GI1/view?pli=1
absolut nicht stimmen
Die Motoren haben einzeln gemessen völlig unterschiedliche Werte für eine Umdrehung:
Motor 1 (ich nenne ihn hinten links) : 320
Motor 2 (vorne links): 236
Motor 3 (vorne rechts): 320
Motor 4 (hinten rechts): 280
Meine Frage: sollte ich das Dagu 5 Roboter chassis zurückschicken oder hatte jemand von Euch auch diese unterschiedlichen Messwerte?
Vielen Dank für Deine Informationen. Leider ist mein Hobby zZt auf Eis gelegt, bin im Wohnungswechsel ...da sind die "Spielzeuge" noch alle gut verpackt und verstaut....
Ich möchte auch auf einen 4WD umsteigen , wegen den Mecanum-Rädern von Fingertech...
Werde mich später wieder melden
Gruss und Dank
Gerhard
Hi MEgg,
deine Encoder Werte sind doch gar nicht so schlecht!
Angegeben sind 1000 Encoder-Flanken pro 3 Umdrehungen, also 333 Flanken pro Umdrehung.
Das kommt deinen Werten schon nahe (Mittel: 289): 87% vom Soll.
Dabei stellen sich mir die 2 Fragen:
1. Wie bestimmst du denn GENAU EINE Umdrehung?
Das ist ja beim Kettenantrieb und der Getriebeübersetzung von 86,8:1 fast unmöglich!!
2. Bist du sicher, alle Flanken (per Interrupt) zu erfassen?
Also zur Frage Umtausch: Ich sehe keinen Grund: Das Chassis ist ok.
Ad 1) "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,Zitat:
Zitat von Dirk
wird das so ungefähr schon passen.
Die Zeit/encoder Werte sind auch linear, wenn auch von Motor zu Motor mit unterschiedlicher Steigung, was dann wieder zu den Encoderwerten pro 1 Umdrehung passt.
ad 2) das Programm zum Encoder-Interrupt-zählen macht nur
void encodercountHL_intproc()
{
encodercountHL++;
}
und in der loop ist dann ein
if (Serial2.available())
{
}
in dem ich die PWM Werte und direction via Keyboard input via serieller Verbindung setze, aber das Ausgeben der Zeit/Encoder-Werte erfolgt ausserhalb.
Wenn ich interrupts verlieren würde, würden die Werte imho keine Gerade ergeben.
Ungenauigkeit bei der Ausgabe der Zeit/Encoder-Wertepaare wäre demnach Serial2.available() selbst und das delta zwischen Zeitmessung
und Ausgabe der Encoderwerte (= 3 * Serial2.print() dazwischen).
Hi,
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.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.
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).
Wenn der Verlust an Impulsen auch linear ist: Klar.Zitat:
Wenn ich interrupts verlieren würde, würden die Werte imho keine Gerade ergeben.
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,
Klingt nicht gut.Zitat:
Der andere Motor zeigt 379 !
Und die anderen (du hast ja wohl 4 Encoder-Motoren)?
Erst mal: Danke für Deine Hilfe.Zitat:
Zitat von Dirk
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:
... war doch sehr aufschlußreich.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.
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:Zitat:
Zitat von Dirk
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).
Wenn dir das irgendwann doch nicht reichen sollte:Zitat:
Wenn nichts anderes geht, dann muss das reichen.
-> Dein Programm zur Auswertung der Encoder komplett posten.
Die haben das anscheinend wirklich ohne die Spikes gemessen!Zitat:
Zitat von Dirk
Da ist nichts besonders.Zitat:
Zitat von Dirk
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
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.