PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : [Asuro] Berechnmung der Tic's in 'go()'



helmut_w
10.07.2007, 12:35
In "encoder.c - V002 vom 27.01.07" von Sternthaler
steht innerhalb der Funktion "go()" unter
"\par Hinweis: ", dass das mit der
'// calculation tics/mm' beim Autor Sternthaler
nicht funktioniert. *)

Wir haben das Ganze für _unseren_ Asuro 'mal
durchgerechnet. Dabei gibt es die folgenden
"Messwerte":
Rad-Durchmesser: 38,5 mm
Untersetzung: 50 Zähne zu 10 Zähne = 5 (: 1)
Schwarze Segmente: 6, also 12er-Teilung

Es stellt sich nun die Frage: "Welche Strecke
fährt unser Asuro bei _einem_ Tic in encoder[0]?

Der Umfang des Rades berechnet sich zu
Durchmesser mal Pi (mit Pi = 3,14..);
und ergibt bei uns ca. 121 mm.

Die Strecke für einen Tic:
************************************************** **
* Umfang : Untersetzung : Gesamt-Teile der Scheibe *
************************************************** **
= 121 : 5 : 12
= 2,0168 mm; also rund 2 mm!

Um nun die Tic's (für "enc_count") für eine
gewünschte Strecke (hier: "distance") zu
bekommen, muss man einfach diese Strecke durch
2 mm (pro Tic!) teilen!
(z.Bsp. 1 m = 1.000 mm : 2 mm = 500 tic's)

Aber warum steht im Programm das Folgende?
// calculation tics/mm
enc_count = abs(distance) * 10000L;
enc_count /= 19363L;

Also "abs(distance)" braucht man, um immer
positive Werte für die Zählung zu bekommen.

Und " : 2 " kann man auch so schreiben: " * 1/2 "

Damit die Berechnung nun _ganz_genau_ wird,
muss ich natürlich auch meine _genaue_ Strecke
für so einen Tic einsetzen, also 2,0168 mm!

Und dass dies auch bei "Integer" funktioniert,
nahm der Programmierer einen "Long-integer"-Wert
(uint32_t mit 4 Byte bzw. 32 bit Länge) und
erweiterte den Bruch "1/2" oben (also im Zähler)
und unten (im Nenner) jeweils mit 10.000L
(um die weiteren 2 Bytes gegenüber dem
"normalen" Int-Wert auszunutzen!)

Damit kommen bei _unserem_ Asuro nun genau 496 tics
'raus; mit den Vorgaben in "encoder.c - V002
vom 27.01.07" sind es 516 tics, weil in diesem
Falle die Strecke pro Tic nicht 2,0168 mm, sondern
1,9363 mm war!:))

*) Vielleicht gibt es beim Asuro von Sternthaler
einen anderen Rad-Durchmesser, oder die zweiten
beigelegten Teilungs-Scheiben wurden verwendet!?

Ich hoffe, dass mit diesen kleinen Ausführungen
nun jeder "Asuro-ianer" sein Programm damit an-
passen kann! (Übrigens gibt es weitere Vorschläge
von SlyD im Arrex-Forum zur _kleinen_ Programm-
Verbesserung unter "[ASURO] Probleme mit der
Variablen 'extern int encoder[2]'".)

cu Helmut

Sternthaler
10.07.2007, 23:55
Hi,
hier dann mal meine Asuro-Dimensionen:

Rad-Durchmesser: 38,2 mm --> *PI = 120 mm/Umdrehung
(Ist das Ding schon abgefahren? Oder muss ich mal Luft nachfüllen?)
Untersetzung auch 5/1
Schwarze Segmente: hoppla, nicht 6, sondern 8, also 16er-Teilung
(Die 2.te beigelegte Scheibe hat 4 mal schwarz, also 8er-Teilung. Den Asuro hatte ich vor ca. 2 Jahren gekauft.)

Damit also bei mir:
Die Strecke für einen Tic:
= 120 : 5 : 16
= 1,5 mm
Nun ist also klar warum bei meinem Asuro die Strecken nicht passten.

Aber genau dafür gibt es ja den Thread ASURO emittelt Werte für Lib V2.70 myasuro.h selber (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=31073)

Das Programm liefert mir, bei pingeliger Streckenmessung, 15150 als Wert für den Umrechenfaktor.
Liegt also dann bei 1.515 mm/Tik. Kann man echt nicht meckern.

Hier noch eine Anmerkungen zu deinem Eintrag im AREXX-Forum: (http://www.arexx.com/forum/viewtopic.php?p=1565)
- Die Variable encoder[] als volatile zu definieren ist richtig. Wird in der Lib neue Asuro Lib V2.70 (Release Candidate 3) (https://www.roboternetz.de/phpBB2/viewtopic.php?t=26594) geändert.