Encoder Bricklet: Wann endlich?

[gunter]

[move]Encoder Bricklets .................. make the driver Bricks .....................  a lot more usefull![/move]

 

 

Am 14. März schrieb borg:

.... Encoder Bricklets (they make the driver Bricks a lot more usefull)... .

Wie wahr! Und an der Nützlichkeit, Motor-Encoder Werte zu erfassen hat sich zwischenzeitlich auch nichts geändert. Leider ist es um das Encoder-Bricklet ziemlich still geworden, obwohl es seit ca. einem Jahr im Forum herumgeistert und auch schon mal ein Prototypen-Bild zu sehen war.

Um den DC-Brick sinnvoll zu nutzen (z.B. in einem Roboterantrieb ) wird es höchste Zeit für ein Encoder-Bricklet.

 

Gruß, Günter

[Nic]

Würde alternativ ein Schrittmotor nicht ausreichen, wenn es um genauere Positionsbestim. geht als mit einem DC-Motor ?

[gunter]

Würde sicherlich ausreichen.

Aber nun habe ich mal die maxon-Motoren mit Magnetencodern und bin bisher auch sehr zufrieden damit. Ich will, um den Gesamtaufbau zu vereinfachen, alle Aktoren (Motoren und Servos) mit TF-Bausteinen ansteuern. Bisher habe ich die Motoren mit acroname Moto1 bzw. RoboticsConnection Serializer angesteuert. RoboticsConnection ist nicht mehr am Markt und der acroname Motorcontroller ist ziemlich umständlich in der Handhabung: Programmierung mit einem proprietären Subset von C, wacklige RS232-USB Treiber und in den letzten Jahren kaum noch Support. Eigentlich ganz gute Gründe für einen Wechsel zu TF. Ja, bis auf die versprochenen (z.B. tf_archiv, 30.12.2011:"We have a encoder-bricklet in preparation") aber immer noch nicht lieferbaren Encoder-Bricklets.

Günter

[Nic]

Wenn es so ein Encoder-Bricklet geben sollte, müsste aber die Verbindung bzw. der Soll-Ist-Datenstrom direkt an das DC-Brick bzw. Motor gehen. Ich persönlich hätte sonst Magenschmerzen , wenn der Datenstrom erst über Umweg des (langsamen) USB und Host-Systems verarbeitet und wieder den "langen Weg" zurück zum DC-Brick geht. Was die zuverlässige und schnelle Steuerung von Motoren angeht, kann es mir nicht echtzeitnah genug sein.

 

Es sind Pläne bekannt wonach der direkte Datenaustausch zw. Brick und verknüpftem Bricklet möglich werden soll. Bessere Voraussetzungen wird m.E. auch das OnDevice-Programming schaffen. Also das direkte Progr. der Bricks. Beides ist aber (noch) Zukunft.

[borg]

Öhm, ein Encoder Bricklet ist definitiv immer noch geplant. Leider war die Nachfrage nicht riesig, daher ist es ein bisschen liegen geblieben.

 

Das Problem damit ist, wie Nic schon sagt, dass so ein Encoder Bricklet kein "normales" Bricklet sein kann, was über USB regelt. Sondern wir müssten dem DC Brick beibringen, das Encoder Bricklet zu erkennen und seine eigene API entsprechend zu erweitern. Zum Beispiel durch die Angabe von Übersetzungen und Radumfang könnte dann direkt eine Fahrtlänge angegeben werden.

 

Leider ist es sehr viel Aufwand das stabil zum laufen zu bekommen und da andere aufwändige Sachen (Wifi, Ethernet) viel häufiger nachgefragt wurden, ist das Encoder Bricklet ein bisschen ins Hintertreffen geraten .

[gunter]

..., ein Encoder Bricklet ist definitiv immer noch geplant.

 

Das lässt ja noch hoffen. Ich kann auch die technischen und kaufmännischen Probleme verstehen. Aber vielleicht steigert die beschriebene und sinnvolle Kombination von DC-Brick und Encoder-Bricklet die Attraktivität des DC-Bricks für Kunden, die bisher an einen Einsatz des Teils noch gar nicht gedacht haben.

Ihr schafft das schon. Muss ja nicht noch vor Weihnachten sein, aber bald danach … 

 

Gutes Gelingen

Günter

[batti]

Einen Nachtrag hab ich noch dazu. Olaf hatte das bereits angedeutet.

 

Der große Aufwand ist dies in die Firmwares der Bricks einzubauen.

So muss z.B. das Stepper Brick ja den Schrittmotor beschleunigen können, also andauernd die Frequenz verändern, parallel dazu SPI im Stack sprechen können und dann jetzt zusätzlich noch die Ticks vom Encoder mitzählen können.

 

Das ganze natürlich ohne große Sprünge in der Schrittmotorgeschwindigkeit zu haben (wollen ja saubere Rampen fahren können), nicht andauernd Fehler in der SPI Kommunikation haben und natürlich auch keine Ticks des Encoders verpassen.

 

Machbar sollte dies sein, ist aber halt so ein richtiges Timing-gefukkel bis das richtig funktioniert.

[Nic]

Weitere Baustellen: Wie soll der Encoder an die Motoren adaptierbar sein ?

Unterschiedl. Wellendurchmesser, 2.Wellenende vorhanden und Motorflansch Nema 11, 17, 23 etc...

Und sprechen wir hier nur von einem Interface und auch vom Sensor/Signalgeber, welcher die aktuelle Position einer Welle erfasst und als elektrisches Signal ausgibt.

 

Nicht umsonst werden Schrittmotoren mit integr. Encoder komplett angeboten (Close-Loop-System). Z.T. auch mit integr. Endstufe zur Steuerung.

Prinzipiell wäre ich auch an so einem Encoder interessiert, aber die o.g. Probleme werden nicht so schnell zu knacken sein.

[gunter]

Also ich hatte dabei nur an ein Interface gedacht, da die meine DC-Motoren die Encoder schon mitbringen.

[gunter]

Dezember 2011:  "We have an encoder-bricklet in preparation"

März    2012:  “Encoder Bricklets (they make the driver Bricks a lot more usefull).”

Dezember 2012: “Öhm, ein Encoder Bricklet ist definitiv immer noch geplant.“

 

Da die Timeline eine Weile nicht aktualisiert wurde, konnte man sich der Hoffnung hingeben, dass es vielleicht doch noch was wird,  mit einem Encoder-Bricklet. Nach den neuesten Aktualisierungen gibt`s aber ne Wetterstation. Auch schön!

Wenn es aus kaufmännischen Gründen (geringe Nachfrage) oder technischen Gründen (timing, …) für Euch nicht sinnvoll ist, ein Encoder-Bricklet oder einen angepassten DC-Brick anzubieten, dann wäre es ganz hilfreich, wenn Ihr sagt: “Tut uns leid, aber ein Encoder-Bricklet kommt nicht. Zumindest nicht innerhalb der nächsten 6 Monate.“ Wäre schade, aber man kann dann aufhören vor sich hin zu hoffen und eine Alternative planen.

 

Gruß, Günter

 

[batti]

Hallo Gunter,

 

Sorry! Wir können deinen Einwand komplett nachvollziehen.

Ich habe mal ein Foto von Encoderscheiben und dem Encoder Bricklet

angehängt. Seit Ende 2011 existieren diese. Nach einem Funktionstest haben wir aber nicht mehr viel daran getan.

 

Warum haben wir nichts damit gemacht?

Es fehlt noch an der Software. Es ist angedacht, dass DC und Stepper Bricks das angeschlossene Encoder Bricklet erkennen und dann erweiterte API freischalten (z.B. setSpeed etc.).

Die Software dafür zu schreiben ist leider einiges an Aufwand, da neben der Implementierung einer Regelung vorallem das interruptbasierte Handling der Ticks vom Encoder nicht ganz einfach ist. Problematisch wird das, wenn z.B. gerade im Stack kommuniziert wird und dann ein Interrupt auftaucht bei dem der Schrittzähler inkrementiert werden muss, man aber gerade eigentlich das nächste Byte per SPI durch den Stack schieben musste. Je nach Priorisierung kann dies dann dazu führen, dass die SPI Nachricht kaputt ist und neu gesendet werden muss oder dass der Tick vergessen wird. Im ersten Fall könnte das dazu führen, dass auf Grund zu vieler Ticks die SPI Kommunikation überhaupt nicht mehr möglich ist (keine Nachricht kommt durch).

 

Bei der Lösung dieser möglichen Probleme muss man also sich noch einige Gedanken machen und wird einiges Testen müssen. Wir sehen die Encoder Geschichte als eine wichtige Erweiterung, die die Treiber Bricks interessanter machen werden. Die Nachfrage dafür war, im Vergleich zu anderen "Wünschen", aber vergleichsweise gering. Daher haben wir das immer weiter vor uns hergeschoben.

 

Beim Stepper Brick ist diese Software Geschichte nochmals schwieriger als beim DC Brick. Um das ganze mal endlich vorran zu bringen wollen wir mit der Implementierung für den DC Brick beginnen. Für diesen ist dies wohl am sinnvollsten. Ich habe den Punkt auf die Timeline gesetzt.

 

Grüße,

 

Bastian

[FlyingDoc]

Warum integriert ihr den Schrittzähler nicht direk auf dem Encoderbrickled?

 

Dieser enthält dann zum Beispiel die Position die abgefragt werden kann und wird dann bei Abfrage wieder auf 0 gesetzt.

 

So könnte man die Anzahl und Richtung der Impulse abfragen und es würden keine Impulse verloren gehen.

 

 

[gunter]

Habe die Timeline gesehen.  15.Woche!!! 

Auch wenn’s die 17. wird, das ist mal eine richtige gute Nachricht. Dazu Sonnenschein. So sehen gute Tage aus.

 

Viel Erfolg

Günter

 

[borg]

Warum integriert ihr den Schrittzähler nicht direk auf dem Encoderbrickled?

 

Dann müssen wir die Schritte per I2C o.ä. abfragen und können dies wieder nur 1000x pro Sekunde tun (wie normalerweise üblich). Das reicht aber von der Frequenz her nicht um eine richtig gute PID Regelung der Motorgeschwindigkeit zu machen.

 

Zusätzlich würde das natürlich auch Komplexität und Preis des Bricklets erhöhen.

[AuronX]

Habe die Timeline gesehen.  15.Woche!!!

 

Habe ich mich gerade verzählt oder ist das in gut einem Monat?

 

Dafür, dass das was du gerade geschrieben hast nach ziemlich fiesen Problemen klinngt halte ich das für einen straffen Zeitplan... Aber Ahnung hab ich natürlich keine. Hoffe nur der arme Gunter muss dann nach Ostern nicht traurig sein...

 

Wird das Encoder-Bricklet auch stand-alone nutzbar sein um Umdrehungen zu zählen?

[borg]

Soooo, ich hab schlechte Nachrichten .

 

Wir können die Encoder Bricklet Hardware die wir hier haben leider nicht verwenden. Es gibt da leider zwei Problemchen.

 

* Das ganze ist mechanisch nicht ausgereift. Die eigentliche Lichtschranke direkt auf die Leiterplatte zu setzen ist definitiv keine gute Idee, wir hatten ziemliche Probleme das in unserem Beispielaufbau vernünftig anzubringen

 

* Der Encoder den wir auf dem Bricklet haben, hat einen zu kleinen Abstand zwischen den Lichtschranken. Obwohl wir mit einer Frequenz von 10kHz abgefragt haben, konnte ich nur eine Drehzahl von ~1200rpm erreichen.

 

Wir haben uns beratschlagt und sind zum Schluss gekommen, das ein Zähler auf dem Bricklet selbst doch die beste Lösung ist (wie von FlyingDoc vorgeschlagen). Dadurch ist das Encoder Bricklet jetzt leider erst wieder ein ganzes Stück nach hinten gerutscht, wir haben jetzt in nächster Zeit erst einen ganzen Schwung anderer neuer Hardware.

 

Die Arbeit die da bisher reingeflossen ist, geht aber natürlich nicht verloren. Ich hab den ganzen Code erstmal auskommentiert mit ins git eingecheckt:

https://github.com/Tinkerforge/bricklib/commit/ea9fa7e221b2d9eb2f4f0ceac81942a9b5e43d39

https://github.com/Tinkerforge/dc-brick/commit/6a1f82b3bdd9cb9d6ed6ab5e7ffd17320cdf77bc

https://github.com/Tinkerforge/generators/commit/bddf195c9098607d982f5801ccd5c40150063ee7

 

Tut mir leid dass das nichts geworden ist, aber es bringt nichts wenn wir unausgereifte Hardware veröffentlichen mit der wir hier noch nicht  einmal vernünftige Ergebnisse erzielen können .

[gunter]

Schade eigentlich.

Irgendwie habe ich das mit dem Encoder-Bricklet wohl auch missverstanden.

Da meine Motoren Encoder haben, hatte ich mir unter einem Encoder-Bricklet eine Anschlussmöglichkeit für diese Encoder  (Kanal A und B, Vcc, Gnd) vorgestellt mit einem Zähler auf dem Bricklet. Als Grundlage für eine PID-Regelung des DC-Bricks und das Ganze in Python programmierbar.

Schön wär´s gewesen.

Günter

 

[Lars Ro]

Ich will hier auch noch mal das Encoder-Bricklet etwas pushen.

 

Meine Anwendung wäre die Abfrage eines Endlos-Drehreglers, also hätte ich am liebsten ein Rotary-Encoder-Wheel-Bricklet inkl. Drehrad. Da sind die 1200 RPM auch ausreichend.

 

Darüber hinaus finde ich eine DC-Motorsteuerung auch sehr interessant. AFAIK arbeiten die typischen 6-Achs-Roboter auch mit DC-Motoren plus Encoder (statt Schrittmotoren), weil das fehlerfrei läuft. Schrittmotoren können unter starker Belastung und/oder ungünstiger Programmierung wohl schon mal einen Schritt "auslassen". Und ein Selbstbau-Roboter wäre natürlich was...

Aber erst nach der CNC-Fräse, dem 3D-Drucker und dem Bestückungsautomaten.

 

 

Zur Realisierung:

 

AFAIK ist auf dem (beim DC-Brick verwendeten) ATSAM3S2B ja ein Hardware Quadrature Decoder, der auch mit sehr hohen Frequenzen vmtl. überhaupt keine Probleme hat. Auf dem ATSAM3S4C des Master-Bricks sind sogar zwei. Leider scheinen die entsprechenden Pins (TIOA und TIOB? Find mich da nicht zurecht.) nicht auf den Bricklet Connectoren zu liegen.

 

Da würde ich mal frech eine neue Hardware-Revision der Bricks vorschlagen, die die benötigten Signale mit Pins 2 und 3 eines Connectors verbindet. Da nicht genügend Hardware Decoder für alle Connectoren vorhanden sind, würde bei den "einfachen" Connectoren jeder Tick per Software abgefragt. Das erlaubt nur recht geringe Umdrehungsgeschwindigkeiten. "High Speed" bieten erst die mit einem Hardware Decoder verbundenen (und deshalb speziell gekennzeichneten) Connectoren. Bei den bisherigen Bricks gibt es eben nur die "einfachen".