hi,
die zeitabstände sind doch solange es nur um die winkel, bzw. die strecke geht egal, denke ich zumindest. erst wenn die winkelgeschwindgikeit gesucht wrd, spielt die zeit eine rolle.
mfg jeffrey
Hi!
Es tut mir leid, dass ich mich so lange nicht melden konnte, aber mein Internet funzte zu beginn nicht und dann fuhr ich in den Urlaub.
@mare_crisium
Danke nochmals für deine Rege teilnahme am Problem. Wie du bereits Richtig angenommen hast, werden die Koordinaten aufsummiert.
Um die Messfehler auszumerzen, habe ich mich bereits nach einer besseren LED für den Sensor umgesehen, welchen ich ende September erhalten werde.
Werde mir jetzt die Berechnung v04 ansehen.
Danke nochmals!!!!!!
Holla zusammen.
@jeffrey
Ja, ich gebe dir Recht, dass die Zeit wohl keine Rolle für die Positionsberechnung spielt.
Ich wollte damit nur andeuten, dass die aufgenommenen X-/Y-Werte eben nicht stetig erfolgen.
Wenn man sich das Datenblatt zum Sensor ansieht, dann ist der Defaultmode so eingestellt, dass man nicht kontinuierlich vom Sensor Daten gepusht bekommt, sondern dass man sie selber abholen muss. (Kommando DIASBLE "Disable stream mode" ist Default.)
Somit stellt sich mir die Frage, wie PRobot die Sensorabfrage macht. (Natürlich auch, ob eine andere Initialisierung vorgenommen wird.)
Weiter wird als Defaulteinstellung eine Auflösung von 8 counts/mm angegeben. Finde ich schon ominös, dass in mm und nicht in inch angegeben wird. Nochmals ominös ist, dass mit der maximal einstellbaren Auflösung von 16 counts/mm gerade mal eine Auflösung von 16*2,54=40,64 cpi erreicht wird. Angegeben wird der Sensor aber mit 400 cpi.
Mit diesem Default von 8 counts/mm müsste ein alpha-Wert im EXECL von mare_crisium von 0,125 eingetragen werden.
Wenn man nun mal ganz blöde diesen Wert durch 2,54 mm/inch teilt, dann kommt man auf 0,049.
Dies kommt dem von mare_crisium oben angegeben Wert von 0,05 für einen halbwegs sinnvollen Output merkwürdig nahe.
Halbwegs deshalb, da dann die gefahrenen X- bzw. Y-Strecken aber nur ca. 32 mm ausmachen.
Es bleibt dabei, dass eigentlich 62,6 mm in X- und Y-Richtung gefahren sein müssten.
Und deshalb bleibe ich dabei, dass mir der Maßstab für X und Y, und auch die in mm angegeben Entfernungen, in der Grafik im Excel-Blatt nicht so recht einleuchten.
kaktus hatte am 30.07..2008 ja schon darauf hingewiesen, dass bei einem 90°-Turn die aufgenommenen X- und Y- Zählerwerte identisch sein müssen. Er hatte vorgeschlagen den großen durch den kleinen Wert zu teilen und hatte den Faktor 1959/ 827 = 2,369 angegeben.
Auch hier kommen wir den 2,54 mm/inch wieder 'gefährlich' nahe.
Eine an den Haaren herbeigezogene Annahme:
Wie würde es aussehen, wenn eine der Koordinaten in mm und die andere in inch vom Sensor gesendet werden?
Wie überhaupt werden die Daten transportiert?
@PRobot
Kannst du hier weiterhelfen, was du vom Sensor bekommst?
Laut Datenblatt kommt auf ein "READ_DATA"-Kommando ein "FA nn nn nn"
Leider nur mit einem Verweis auf die 'IBM PS/2 Mouse Technical Reference'. (Käuflich für 7,90 Dollar zu erwerben.)
Was zum Teufel sind die nn nn nn? 3 Byte? Laut Datenblatt liegen Information zur Richtung und Stärke der Bewegung vor. "... mathematically determining the direction and magnitude of movement."
Wenn "nn nn nn" X, Y, Beschleunigung sind, dann müssten X und Y vorzeichenbehaftet sein. Die delta_x- und delta_y-Werte liegen immer unter diesen dann möglichen +/-128
Liegt eventuell ein Überlauf in den Koordinatenangaben vom Sensor vor? Messrate zu klein?
Das könnte dann zu der von mir angesprochenen 'Kraut und Rüben'-Kurve führen, da beim Abschneiden von höchstwertigen Bits nur der 'flatternde' Anteil der letzten 7 Bit benutzt werden.
Mehr fällt mir im Moment nicht mehr ein.
Gruß Sternthaler
Lieber Asuro programieren als arbeiten gehen.
hoi,
also 1 inch= 25,4mm, dann stimmen auch die 400.
und weiterhin bin ich immernoch der meinung, dass bei einer reinen drehung, und der sensoranordnung aus dem ersten bild sich nur die x-werte ändern.
mfg jeffrey
Welches Datenblatt benutzt du?Zitat von Sternthaler
Hier das Datenblatt des PAN3101:
http://www.pixart.com.tw/upload/PAN3...1121170653.pdf
Die Bewegung wird in einem Register gespeichert, welches von -128 bis 127 geht. Bei einem Overflow wird ein weiteres Register auf 1 gesetzt.
Ich lese die daten über einen Timer alle 1ms aus. Das dürfte reichen, damit kein Overflow kommt.
Hi, PRobot,
ich hatte schon gefürchtet, wir hätten Dich vergrault. Bei der Maus, mit der ich herumexperimentiere, kann ich dummerweise den Sleep-modus nicht abschalten. Ich werde mir wohl direkt einen Agilent Sensor kaufen. Bei Segor habe ich einen für ca. 3 EUR gesehen. - Bei mir krabbelt die Maus auch nicht mehr auf dem Untergrund umher: Seit ich ihr eine Brille verpasst habe, schwebt sie so 3-4 cm über dem Boden. Wichtig ist dabei, dass die LED den Messfleck unter einem möglichst flachen Winkel ausleuchtet. Im Internet stellt ein Maus-Hacker eine Lösung vor, bei der er die LED am Ende eines knickbarenTrinkhalms (mit so 'ner Ziehharmonika drin) knapp über dem Boden montiert hat. Wenn Dich die Sache interessiert, können wir gern noch ein bisschen über das Thema fachsimpeln.
@jeffrey,
Deine Erklärungen bezüglich der Stückelung der Fahrdistanz sind vollkommen richtig. Mir ist beim Durchsehen des Algorithmus aufgefallen, dass Geschwindigkeit und Zeit immer als Produkt in die Formeln eingehen. Das bedeutet, dass man genausogut direkt die Wegstrecken einsetzen kann. Nachdem mir dieser Seifensieder aufgegangen ist, habe ich den Algorithmus nochmal überarbeitet. Ist aber noch nicht veröffentlicht.
@SternThaler:
bist mir also doch wieder auf die Schliche gekommen! Bei Deinen Fragen bezüglich der Mausabfrage beziehst Du Dich auf eine Maus mit PS/2-Bus. Probot fragt den Chip direkt ab, indem er einzelne Register adressiert und ausliest. Im Anhang ist eine ganz gute Beschreibung der Datenfelder der PS/2-Mausprotokolls. Bei den PS/2-Mäusen werden für x und y immer dieselben Masseinheiten verwendet; das kann bei Probots Maus aber anders sein. Deine Überlegungen (inch/mm) zum Wert von alpha sind vermutlich richtig.
Inzwischen habe ich auch verstanden, warum Probot die x- und y-Werte aufaddiert: So macht man das nämlich, wenn man die Bewegung des Mauszeigers auf dem Bildschirm darstellt. Dabei spielt es keine Rolle, wie die Maus gedreht wird – und deshalb kann man diese Methode nicht auf den Roboter übertragen.
Deinen interessanten Pythagoras-Ansatz muss ich noch weiter ausprobieren. Im Grunde ordnet der Algorithmus die gefahrene Bahnlänge der e_p-Richtung zu und die Drehungen der e_q-Richtung. Die Bahnlänge s kann man aus der Ableitung der Bahnkurve berechnen:
s = integral (wurzel(1 + (dy/dx)^2) dx )
Da linst Dein Pythagoras wieder um die Ecke! Leider ist es unwahrscheinlich haarig, dieses Integral für beliebige Bahnkurven zu lösen. Deshalb ist es auch so schwer auszurechnen, wie man die Räder steuern muss, um eine bestimmte Bahnkurve zu fahren; beim Kreis geht’s noch ganz gut, aber schon an der Ellipse habe ich mir die Finger wundgerechnet.
Ich lass' von mir hören, wenn ich Deinen Vorschlag besser überblicke.
Ciao,
mare_crisium
Edit: Anhang gelöscht wg. Upload-Quota
Die Sache mit dem Pytagoras geht wohl in die falsche Richtung. Den Winkel zwischen Sensor und der Achse könnte man relativ einfach duch eine Drehung (als Matrixmultiplikation) ausgleichen. Ohne einen Winkelfehler hat man eine Bewegung auf Grund der linearen Bewegung und eine Senkrecht dazu. Die Lineare Bewegung hilft einem für die Drehung gar nicht weiter, die brauchen wier also auch nicht zu betrachen. Bleibt also nur die Bewegung Senkrecht zur linearen Bewegung um den Winkel zu berechenen. Wenn man sich das einfach machen will dreht man einmal um 360 Grad und mißt den Proportionalitätsfaktor. Viel besser wird man den Abstand auch kaum per Schieblehre oder so bestimmen können.
Zusammen mit der Winkelkorrektur sollte also eine einfache Lineare Form für den Winkel rauskommen, also:
Winkel = a * dx + b * dy
Aus der geradlinigien Bewegung kriegt man das Verhältnis a/b, damit da halt keine Drehung raus kommt.
Wenn ich das richtig sehe sollte die Skalierung der Meßwerte vom Abstand zwischen Sensor und Boden abhängen, denn der beeinflußt die Vergrößerung der optischen Abbildung. Für eine Genaue Messung sollte man hier also auf einen konstanten Abstand achten. Die Idee den Abstand zu Vergrößern kann da wirklich helfen, denn viel Abstand werden die relativen Schwankungen geringer.
Ich grüße alle; auch die Wiedergefundenen.
Heute mal ein kleines bisschen früher, damit ich eventuell weniger Unsinn schreibe.
Hier erst einmal etwas zu meinen verbrochenen Scheußlichkeiten:
==> Stimmt, ich bin auf den PS/2-Mode reingefallen.
Die von mir benutzte Doku ist somit nicht mehr relevant.
@mare_crisium Danke für diesen Hinweis. Ich hätte jedenfalls den Mode benutzt.
==> Hört auf Besserwessi: Meine Pythagoras-Rechnung vergesst ganz schnell wieder.
Mir ging es nicht darum irgendwelche Integrale in den Raum zu werfen oder zu provozieren, sondern nur darum, ein feeling für die Messmethode zu erhalten. Einfach nur alle delta-X und -Y als Teilweg-Stückchen als Excelgrafik zu sehen. (Sozusagen die Nettodaten)
jeffrey hat natürlich Recht. Meine unterstellte Auflösung liegt nur an meiner Dummheit. Da bin ich echt froh, dass dieser Punkt geklärt ist, da ich gestern total verzweifelt war mit den popeligen 40 cpi.
Aus der Doku von PRobot kann man entnehmen:
Werte von -128 bis 127 finden sich in 3 Register-Paaren:
delta_X: 0x03 0x17 0x43
delta_Y: 0x02 0x18 0x42
Und für die Overflow-Bits gibt es nur das Register 0x16
Bei der Beschreibung zu 0x16 steht, dass dann die Register 0x17 und 0x18 zu lesen sind.
Nutzt du diese 3 Register? Wie initialisiert du den Sensor?
Und da ich es nicht lassen kann noch eine kleine Rechnung (jeffrey wird sie hoffentlich schon wieder zurechtrücken
Bei der default-Einstellung mit 800cpi bekommen wir nun ein alpha von 800cpinch / 25,4mm = 31,496.. cpmm = 0,03175 mm/count
Mit dem Wert müssten dann aber bei dem angegebenen Maus_abst von 62,6 mm ein Weg von 1972 Tiks gefahren werden.
Und das passt verflixt gut mit dem letzten von PRobot angegeben X-Wert.
Und woher kommen die Y-Werte?
Auch der Aussage von jeffrey, dass sich bei der Drehbewegung nur die Werte einer Koordinate ändern, stimme ich mittlerweile voll zu.
Dies kann ohne Probleme mit einer kabelgebundenen Maus nachgeprüft werden.
Halte das Kabel kurz hinter der Maus fest und bewege sie kreisförmig um diesen Drehpunkt. -> Der Mauszeiger läuft wie am Lineal geführt nur in der Waagerechten.
Somit müssen die Y-Werte dann die Fehler sein, die durch eine nicht korrekte Einbaulage entstehen.
Wir warten also am besten auf mare_crisiums neu Rechnung, und alles wird sich in Wohlgefallen auflösen. (Wie immer.)
Nun ist aber gut.
Gruß Sternthaler
Lieber Asuro programieren als arbeiten gehen.
Hi, SternThaler,
Deine Demonstration mit der am Schwanz festgehaltenen Maus ist einfach umwerfend!!
mare_crisium
hoi,
ich denke nicht, dass die y-werte nur durch die falsche einbaulage kommen, dazu sind die 6° fehler viel zu wenig, da wären das dann um die 200, bei 2000 schritten in x-richtung.
ich denke eher, dass das daher kommt, dass die drehung nicht genau um den mittelpunkt erfolg.
wenn man mal die 400 cpi (für was steh denn das c?) zugrunde legt, dann stimmt doch die 45°-drehung ganz gut.
1257/400=3,14 hat nix mit pi zu tun
bei der 90° drehung gab´s dann halt paar messfehler, denk ich.
mfg jeffrey
ps: ich hab die rechnung von strenthaler net nachgeprüft
Berechtigungen
Zitieren
Lesezeichen