1 Maussensor, Drehung berechnen

Hi community!
Ich habe folgendes Problem:
Bei meinem Roboter habe ich einen Maussensor (PAN3101) eingebaut, um die aktuelle Position zu bestimmen. Der Sensor befindet sich ca. 10cm vom Drehmittelpunkt des Roboters entfernt (Siehe grafic im Anhang).

Wie kann ich jetzt aber bestimmen, um wie viel Grad sich der Roboter gedreht hat?

Da sich der Sensor auch mitdreht, kann ich ja nicht einfach die erste Position verwenden, den Winkel bestimmen und dann die zweite Position verwenden, um den Endwinkel mit den Winkelfunktionen zu bestimmen, da müsste der Sensor z.B. immer nach Norden schauen. ](*,)

Fällt euch ein geeigneter Algorithmus/Modus ein?

Hier habe ich noch ein Beispiel, wie die Punkte bei einer ca. 90° Drehung aussehen (Während der Drehung werden immer wieder Punkte gemessen)
(Siehe auch Bild im Anhang rote Punkte)
Start pos: 0|0 //Position zu Beginn der Drehung
New pos: 0|0
New pos: 43|27
New pos: 61|38
New pos: 65|44
New pos: 74|50
New pos: 92|60
New pos: 132|81
New pos: 183|106
New pos: 264|142
New pos: 361|180
New pos: 431|210
New pos: 461|227
New pos: 514|256
New pos: 608|296
New pos: 727|335
New pos: 822|370
New pos: 873|392
New pos: 925|417
New pos: 1008|435
New pos: 1127|469
New pos: 1227|503
New pos: 1337|539
New pos: 1439|577
New pos: 1547|616
New pos: 1647|649
New pos: 1725|687
New pos: 1805|723
New pos: 1846|755
New pos: 1903|791
New pos: 1959|827 //Position bei ca. 90°

Hier noch ein Beispiel bei ca. 45° (siehe Bild im Anhang blaue Punkte)
Start pos: 0|0
New pos: 2|3
New pos: 28|22
New pos: 131|60
New pos: 213|94
New pos: 286|114
New pos: 352|128
New pos: 424|152
New pos: 465|169
New pos: 514|196
New pos: 609|232
New pos: 704|271
New pos: 797|308
New pos: 901|340
New pos: 1013|376
New pos: 1111|413
New pos: 1212|447
New pos: 1257|469

Würde sich der Sensor nicht mitdrehen, dann würden die Punkte einen viertel bzw. achtel Kreis ergeben.

Die zurückgelegt Strecke von X und Y zu der Position nach der Drehung sollte eigentlich gleich sein. Also würde ich den kleineren WErt erst mal mit
1959/ 827 = 2,369 multiplizieren.
Der Abstand Y ist bekannt, z.b. 5 cm. Ist X und Y gleich ( nach Multiplikation)
war es eine 90 Grad Drehung.
Bloss wie rechnet man die gleichzeitige Drehung raus?

Ich verstehe das jetzt nicht ganz, wie du das meinst.
Mit kleineren Wert multiplizieren und wie die Werte dann gleich sein sollten.

Ich habe in der Zwischenzeit auch die Koodrinaten wo sich der mittelpunkt befindet:
Wenn sich der Sensor auf Position 0|0 befindet, so ist der Mittelpunkt auf ca. 0|2524, also auf der Y-Achse um 2524 verschoben.

Theoretisch müsste sich die gemessene Position ja nur seitlich verändern. Bei der Rotation um den Drehpunkt bewegt sich der Sensor ja auf einer Kreisbahn. Wenn der Radius nun verhältnismäßig groß ist, ergibt das als Messergebnis in etwa eine Gerade. Ich kann das ganz gut mit meiner PC-Maus reproduzieren. Du misst also nun die Strecke, die so aus der Sicht des Sensors seitlich zurückgelegt wird. Dies ist der Weg auf dem Kreis mit dem bekannten Radius. Daraus lässt sich dann der Winkel bestimmen. Als Messwert ergibt sich also in deiner Skizze die Bogenlänge zwischen alter und neuer Position. Geteilt durch den radius hast du deinen Winkel im Bogenmaß.

Die schiefe Gerade aus deiner Grafik kann ich mit meiner Maus reproduzieren, wenn ich die Maus in einem anderen Winkel halten, wenn sie rotiert. Du könntest das entweder rausrechnen (Länge der schiefen Gerade bestimmen) oder den Sensor etwas drehen.

(So, jetzt muss ich erst mal wieder die Cursorgeschwindigkeit erhöhen. Hatte sie auf ganz langsam gestellt, um besser testen zu können... ;))

Hallo PRobot,

die Sache ist einfach, zumindest sieht sie einfach aus. Für Dich ist vermutlich Dein Ansatz von der Geometrie her verwirrend, weil er mit der "normalen" Anschauung nur wenig gemeinsam hat. Vielleicht wird es Dir folgendermassen etwas klarer:

Denke Dir bitte Deinen Maussensor als einen festen, unverrückbaren Punkt im Weltall (ok ok - vielleicht blos als unverrückbaren Punkt in Deinem Lageplan). Wenn Du Deinen Roboter laufen läßt, dann drehst Du das Weltall (den Lageplan) unter Deinem Maussensor hin und her >> der Roboter bleibt stabil auf dem Achsenursprung. Auf Deine hübsche Zeichnung bezogen heißt das, dass die beiden dargestellten Achsenkreuze sich decken - es gibt dann also nur ein Achsenkreuz! Lediglich Deine Unterlage wandert im Uhrzeigersinn um den "Mittelpunkt" herum. Probier das doch mal auf einem Blatt Papier nachzuspielen.

Nicht zum Lesen gedacht:
Die mathematisch positive Drehrichtung ist gegen den Uhrzeigersinn.
Dein Achsenkreuz teilt "die Welt" in vier Quadranten. Zwischen der positiven X-Achse (X+) und der positiven Y-Achse (Y+) liegt der erste Quadrant, zwischen X- und Y+ liegt der zweite Quadrant, der dritte Quadrant liegt zwischen X- und Y- und schließlich der vierte Quadrant zwischen der positiven X-Achse und der negativen Y-Achse.

Bei Deiner Drehung wandert also die Welt unter Dir durch und läuft durch den zweiten Quadranten. Die alte Position verschiebt sich also durch die Drehung auf einem positiven Y-Wert und einem negativen X-Wert, wobei die X- und die Y-Koordinate des alten Mittelpunktes dieselben sind.

Nicht zum Lesen gedacht: in einem vollständigen ebenen Koordinatensystem gibt es diese beiden Achsen X und Y und noch einen Orientierungswinkel - sagen wir alfa. Dieser Winkel bestimmt die Drehung innerhalb der Ebene. Für den eben besprochenen Fall dreht sich der Mittelpunkt bei der von Dir gezeichneten Bewegung im mathematisch negativen Sinn (im Uhrzeigersinn) um 90° - Du siehst es nur einem Punkt nicht an, wie er gedreht ist, weil er eben ein Punkt ist. Da die Maus "nur" X- und Y-Koordinaten kennt, gibt es auch keine Information über die Drehung. Probiere doch mal Deine Maus auf dem Tisch zu drehen - Du wirst sehen, dass der Mauszeiger sich nicht mitdreht - der geht nur auf und ab am Bildschirm. Für komplexe graphische Eingaben gibt es "Mäuse" die auch die Drehung mitkriegen :)

Aber in einer vollständigen geometrischen Beschreibung des Punktes hat der sich eben auch gedreht.

Anderes Beispiel: Ein Kapitän bekommt die "neuen" Koordinaten seines Schiffes mit der Frage wie gefahren werden soll. Bevor er aber nun "Volle Kraft voraus" kommandiert, muss er ja wissen in welche Richtung der Schiffsbug zeigt :). Noch ein kurzes Beispiel: Du fährst im Zug - derZug fährt eine gewisse Strecke in einem 90 ° Bogen - Du guckst immer gerade aus - aber in Wahrheit hast Du bei der Abfahrt z.B. nach Osten geblickt und nach Ankunft des Zuges nach Norden.

Ist diese Erklärung hilfreich für Dich?

hallo,

@oberallgeier: irgendwie hab ich das mit drhendem weltall, schiff und zug net wirklich geblickt, sorry.

so, jetzt aber zur frage. ansich ist das ganze doch realtiv simpel:
y ist uninteressant. nur x interessiert für die drehung.
dalpha=dx/r

mfg jeffrey

Zitat:

---

Zitat von jeffrey

... das mit drhendem weltall, schiff und zug net wirklich geblickt, sorry...

---

Da muss doch eher ich mich entschuldigen.

Zitat:

---

Zitat von jeffrey

... ansich ist das ganze doch realtiv simpel:
y ist uninteressant.

---

In einem ebenen, rechtwinkeligen Koordinatensystem ist in praktisch allen Fällen Y ein interessierender Wert. Sonst ist es ja ein eindimensionaler Raum - ein Linienkosmos.

Zitat:

---

Zitat von jeffrey

... nur x interessiert für die drehung...

---

X ist eine (geradlinige, translatorische) Koordinate, die mit Drehung nichts zu tun hat.

Zitat:

---

Zitat von jeffrey

... dalpha=dx/r ...

---

Ok, und weiter ? ? ?

hallo,
ich meinte y ist uniteressant für die drehung;-)
weil y zeigt immer entlang des radius, also wird es sich bei einer drehung nicht ändern.
jetzt muss man nur noch dalpha aufsummieren, und hat alpha. und somit den gesuchten drehwinkel.
also man muss vorher noch maussensorwerte in cm umrechnen, also

dalpha=dx*a/r

also mann muss halt noch berechnen, nachlesen, messen, ... wieviel maussensorwert/cm man hat, damit x und r die gleiche einheit haben. wenn wir mal 2000/vierteldrehung nehmen. dann kommt kommt a=0,00785 raus.
allerdings wären dann die 45° eigentlich 55°
der y wert dürfte sich bei einer reinen drehung und der sensoranordnung wie in der skizze auch nicht ändern, tut er aber :-(
mfg jeffrey

Erstmal danke für die Antworten!!!

Der Abstand vom Sensor zum Mittelpunkt ist 2524 Koordinaten in Y

@uwegw
Also wenn ich die gesamte zurückgelegte Stecke (länge der schiefen Geraden) mithilfe des Pythagoras-Satzes berechne, diese dann durch den Radius (2524) teile und dieses Bogenmaß dann in den Winkel umwandle, erhalte ich:
bei ca. 90° einen Winkel von 48,27°
WURZEL(1959²+827²)/2524 = 0,842 Bogenmaß *180/PI = 48,27°

bei ca. 45° einen Winkel von 30,45°
WURZEL(1257²+469²)/2524 = 0,531 Bogenmaß *180/PI = 30,45°

@jeffrey
Mit deinem Vorschlag, nur die X-Koordinate zu verwenden, erhalte ich auch falsche winkel:
bei ca. 90° einen Winkel von 44,5°
1959/2524 = 0,7761 Bogenmaß *180/PI = 44,5°

bei ca. 45° einen Winkel von 28,5°
1257/2524 = 0,498 Bogenmaß *180/PI = 28,5°

Diesen Lösungsweg habe ich auch bereits angeschnitten, aber wie ihr seht, füht dies zu falschen winkeln.

hi,
kann es sein, dass du messfehler hast, weil bei beiden ansätzen kommen doch etwa ahnliche werte raus, oder beim abstand vermessen? oder radius und durchmesser verwechselt? verschiedene auflösungen in x und y richtung?
weil wenn deine skizze richtig ist, dann stimmt mein ansatz;-)
mfg jeffrey

Das muss ich jetzt nochmals genauer nachprüfen.
Ich bin ja auch bereits auf denen Lösungsansatz gekommen. Da die Winkel aber nicht stimmten, schrieb ich eben diesen Beitrag.
Radius und Durchmesser habe ich nicht verwechselt. Also werde ich morgen nochmals mehrere Messungen durchführen.

Zitat:

---

Zitat von PRobot

Das muss ich jetzt nochmals genauer nachprüfen.
Ich bin ja auch bereits auf denen Lösungsansatz gekommen. Da die Winkel aber nicht stimmten, schrieb ich eben diesen Beitrag.
Radius und Durchmesser habe ich nicht verwechselt. Also werde ich morgen nochmals mehrere Messungen durchführen.

---

Moin moin,

Einfache Frage: Der Radius ist ja bekannt, Hardwaremäßig vorgegeben.
Warum nicht einfach so genau wie möglich einen Vollkreis fahren und die
Wegstrecke (W=360 Grad) fest abspeichern. Danach sollten sich kleinere
Winkel doch leicht anhand der Wegstrecke ausrechnen lassen? Allerdings
klappt das so dann nur um echte Drehungen um die Mittelachse. Bei einer
Kurve dreht sich aber auch der Mittelpunkt um einen Radius, die y Achse
des äußeren Rades verlängert sich und damit der Umfang/Weg/Winkel.
Y MUß also auch als Veriable in die Berechnung eingehen....

Der CT`bot hat aber genau diese hier beschriebene Mouse Anordnung
und dort ist sehr genau beschrieben wie die das Gelöst haben, inklusive
C Quellcode......

Gruß Richard

Zitat:

---

Zitat von oberallgeier

[i]Nicht zum Lesen gedacht:

---

Moin moin,

NETT. :-) Aber wenn man mal bei Google Earth mit der Mouse herumschupst
kann man an der Koordinaten sehr schön sehen was Du versuchst in
Worten zu fassen. :-))

Gruß Richard

PRobot,

falls Du noch eine Lösung suchst: In der angehängten pdf-Datei habe ich aufgeschrieben, wie ich's machen würde.

Ciao,

mare_crisium

Edit: Anhang gelöscht. Neuere Verison siehe Anhang an meinem Posting vom 19.08.2008.

@Richard:
Danke für den Hinweis auf den CT'bot. Finde ich schon mal sehr interessant. Werde dort mal den relevalten Code suchen

@mare_crisium
Die PDF werde ich auch noch genauer durchlesen :D

PRobot,

ok, falls Du zu dem PDF Erklärungen brauchst (Vektorrechnen ist nicht so jedermanns Sache ;-) ), dann meld' mal (im Forum oder per PN). Der Vorteil der auf Vektoren aufgebauten Methode ist, dass man damit den ganzen Navigationsalgorithmus (Koppelnavigation) leicht aufbauen kann.

Ciao,

mare_crisium

Danke für das Angebot.
Da wir Vektorrechnen in der Schule bereits durchgenommen haben, ist das kein Problem für mich.

Ich hatte in den letzten Tagen noch ein anderes Problem, weshalb ich mit dem Programmieren der Drehung nicht beginnen konnte:
Die Maus, aus der ich den PAN3101 verwende, beinhaltet keine schwarze Abdeckung (Siehe bild: HDNS 2200).
Wenn ich den Maussensor auf einem glatten Boden verwende, misst er nicht richtig. Decke ich aber die Led so ab, dass (fast) das gesamte Licht durch den Lichtleiter geht, wird viel genauer gemessen. Also muss ich mir erst noch einen HDNS 2200 Ersatz aus Schaumgummi basteln. Dann kann ich mich an das Problem der Drehung wenden.

Also ich habe es jetzt mit dem Schaumstoff versucht, die messung auf einem Relativ glatten Boden funktioniert trotzdem nicht. Werde versuchen müssen, einen Laser anstatt dem roten licht verwenden zu müssen. Aber dazu ein eigener Beitrag.

Ich habe auch zum c't Project die Seite gefunden, wo über dem Maussensor beschrieben wird:
http://www.heise.de/ct/06/13/226/

Zitat:

---

Zitat von mare_crisium

PRobot,

falls Du noch eine Lösung suchst: In der angehängten pdf-Datei habe ich aufgeschrieben, wie ich's machen würde.

Ciao,

mare_crisium

---

Ich habe es jetzt mit dieser Anleitung versucht, ich komme aber nicht auf sinnvolle Ergebnisse:

Folgende Werte habe ich durch Versuche und Abmessen herausgefunden:
//Abstand zwischen dem Mittelpunkt des Roboters und dem Maussensor-Messpunkt
MOUSE_RAIUS_MM 62.6

//Abstand zwischen dem Mittelpunkt des Roboters und dem Maussensor-Messpunkt
MOUSE_RAIUS_TICKS -2524.4444

//1 Tick des Maussensors entspricht folgendem Wert in mm (MOUSE_RAIUS_MM/MOUSE_RAIUS_TICKS)
MOUSE_TICKS_MM 0.024797535

//Winkel zwischen Maussensor und der Roboter-Längsachse
MOUSE_ANGLE 6.0013

Folgende Mausposition müsste eine Weglänge von 100mm (1m) und einem Winkel von 0° entsprechen, also 1m nach vorn geradeaus gefahren:
X: 795
Y: 7584

Wenn ich mit diesen Werten aber versuche, die Daten auszurechnen, wie es im PDF von mare_crisium beschreiben ist, komme ich auf folgende Fehlerhafte Ergebnisse (die Werte in den Klammern sollten Eigentlich herauskommen):
Roboter Pos X (Wp): 175,15mm (100mm)
Roboter Pos Y (Wp): 71,25mm (0mm)

Weglänge: -33,38mm (100mm)
Drehwinkel: 160,316° (0°)

Es kann sein, dass ich beim Ausrechnen einen Fehler gemacht habe, oder die Formel fehlerhaft ist.
Könnt ihr das bitte kontrollieren. Danke.

Hi, PRobot,

schön, dass Du's mit die Methode verstanden und mal ausprobiert hast :-) .

Wir haben beide Fehler gemacht: Ich habe einen Vorzeichenfehler in den Formeln für w_p und w_q und folglich auch in (1.5) und (1.6) gemacht. Die angehängte pdf-Datei (V03) ist korrigiert. Du hast den Fehlausrichtungswinkel falsch gemessen. Wie in Abb. 2 gezeigt, soll der Winkel der Fehlausrichtung der Maus zwischen der x-Achse des Maussensors und der Fahrtrichtung gemessen werden. An Deinen Daten sehe ich aber, dass die meisten Mausticks in y-Richtung anfallen; d.h. die y-Richtung der Maus zeigt fast in Fahrtrichtung. Der Fehlausrichtungswinkel muss deshalb 84° sein, nicht nur 6°.

Ich habe die Rechnung mit Excel nachgestellt (mit den korrigierten Formeln) und dabei auch 84° als Fehlausrichtungswinkel eingesetzt. Dann kommt das richtige Ergebnis heraus.

Was meinst Du?

mare_crisium

P.S.:Die Wegstrecke beträgt aber immer viel weniger als 1m. Auch, wenn ich aus Deinen x- und y- Angaben mit Pythagoras die Gesamtstrecke ausrechne. Es bleibt immer so bei 189mm.

Edit: Anhänge gelöscht. Neuere Version in meinem Posting vom 19.08.2008.

Hi mare_crisium!
Danke für die ausgebesserte formel und der .xls.
Jetzt komme ich auch auf richtige Ergebnisse.
Zu der Weglänge:
Ich habe im xls mal herumprobiert, für Alpha müsste 0,0131138 stehen, dann würde auch hier 100mm herauskommen.

Aber da muss ich nochmals genau den Abstand zwischen Sensor und Roboter-Mittelpunkt messen.

PS:
Einen kleinen Fehler habe ich noch in deiner Excel gefunden:
Bei den Ergebnissen mit korrigierter Formel hast du x' und y' vertauscht, da y' ca. 100 werden sollte und x' ca. 0.

Danke nochmals für die Mühe. Jetzt werde ich gleich eine Drehung versuchen und dort dann schauen, welche Ergebnisse ich erhalte.

Also wenn ich die Punkte aus dem ersten Post einsetzt, bekomme ich einen Winkel von 42° (soll 90°)
und 27° (soll 45°).

Kann es sein, dass sich in der Winkel-Formel noch ein kleiner Fehler eingeschlichen hat, oder liegt der Fehler in der Messung?

Zitat:

---

Zitat von PRobot

Also wenn ich die Punkte aus dem ersten Post einsetzt, bekomme ich einen Winkel von 42° (soll 90°)
und 27° (soll 45°).

Kann es sein, dass sich in der Winkel-Formel noch ein kleiner Fehler eingeschlichen hat, oder liegt der Fehler in der Messung?

---

hallo,
werte in dieser größenordnung kommen auch bei meiner formel raus.
mfg jeffrey

Zitat:

---

Zitat von PRobot

Also wenn ich die Punkte aus dem ersten Post einsetzt, bekomme ich einen Winkel von 42° (soll 90°)
und 27° (soll 45°).

Kann es sein, dass sich in der Winkel-Formel noch ein kleiner Fehler eingeschlichen hat, oder liegt der Fehler in der Messung?

---

Moin moin,

Irgendwie scheint es so als wenn Dein Mousesensor nicht wirklich
sauber ausgerichtet ist? Wenn Du den Bot gaaanz gerade und ohne
zu verkanten, an eine Führungsschiene wie z.B für Kreissägen. Einen
Meter entlangschiebst sollte der Mittelwert der Y Achse null sein oder
der "Virutuelle Ball" läuft Diagonal. :-((

Ich würde jetzt erst einmal den Mousesensor so lange justieren bis
bei gerader Strecke y = 0 +/- Fehler ist. Der Sensor selber kann ja
falsche Werte liefern, wenn die Mouse mit der Hand am PC geführt
wird gleicht MENSCH so etwas sofort unbewußt aus.

Ist das dann OK, das gleiche mit der x Achse, nur wenn y/x richtig
zur Fahrzeugachse justiert sind, lohnt es sich weiter Fehler im Prog.
oder in den Formeln zu suchen...! 2 Fehler 4 Möglichkeiten, 4 Fehler..

Echt intessiant, ich liebauge auch mit diesem Prinzip. :-)

Was die zu großen Wegstrecken Werte betrifft, inch, Zoll und Hersteller
Fusch? Damit kann man leben wenn man einen Korrekturfacktor
ermittelt und in die Formel einbring. Bei den Billigteilen dürfte es
Herstellerbedingt enorme Abweichungen geben.

Gruß Richard

PRobot, jeffrey,

mit den Daten aus dem 1. Posting von PRobot komme ich zu demselben Ergebnis wie Ihr beiden. Meiner Meinung nach kommt die Abweichung daher, dass man nicht einfach die Endwerte nehmen darf. Man muss die Daten von Anfang bis zu Schluss "integrieren"; die Methode dazu hatte ich zusammen mit SternThaler entwickelt. Ich bastele noch an einer Excel-Tabelle die das für dieses Beispiel bewerkstelligt. Dauert nur noch ein bisschen, ich melde mich dann :-) .

@richard,

wir Amateure können eben keine so super mechanische Präzision erreichen (ausser Klingon77!). Mit ein bisschen Rechnen kann man das aber wieder geradebiegen :-) !

Ciao,

mare_crisium

PRobot,

ich brauche noch eine Angabe von Dir, damit ich nicht zuviel dummes Zeug rechne: Die x- und y-Ticks in Posting1 werden kontinuierlich grösser. Ich nehme deshalb an, Du hast die gemessenen Mausticks laufend aufsummiert. Ist das so?

Ciao,

mare_crisium

Schade, dass PRobot sich nicht mehr meldet... :-(

Für alle, die dem Thread soweit gefolgt sind, hier die Antwort auf die Fragen von PRobot und jeffrey:

Die Formel, mit der die Fehlausrichtung der x- und y-Richtungen des Maussensors ausgeglichen wird, war so richtig, wie sie in der Version V01 aufgeschrieben war. In der angehängten Datei _V04 habe ich das wieder richtiggestellt. Ausserdem habe ich im Text auch die Messmethode eingebaut, die Richard für den Fehlausrichtungswinkel vorgeschlagen hatte.

Bei PRobot zeigt die y-Richtung der Maus in Fahrtrichtung. Das entspricht einer Rechtsdrehung (im Uhrzeigersinn) um 90°. Rechtsdrehungen haben in der Mathematik ein negatives Vorzeichen. Deshalb ist in PRobots Fall der Fehlausrichtungswinkel -84° und nicht +84°, wie ich zuerst geschrieben hatte. In der angehängten Rechentabelle _V04 ist das jetzt auch richtig eingetragen. Ausserdem enthält die Tabelle die Umrechnung der Daten aus dem ersten Posting von PRobot in den Fahrweg des Roboters. Wie ich das mache, ist in der Tabelle "Erklärungen" nachzulesen.

Bei der Berechnung des Fahrwegs und der Fahrzeugdrehung aus den Daten von PRobot gehe ich davon aus, dass er die Mausdaten aufsummiert hat. Wenn das nicht so wäre, dann hätte sein Autochen während der Fahrt dauernd beschleunigt und das erscheint mir unwahrscheinlich ;-) . Die Drehwinkel, die PRobot vorhersagt, 45° und 90°, kommen trotzdem nicht heraus. Einer der Gründe dafür kann sein, dass der Faktor zum Umrechnen der Mausticks in Wegstrecken falsch ist. In der Tabelle ist dieser Wert variabel - mit 0,05 mm/Tick kommt für beide Datenreihen ungefähr das gewünschte Ergebnis heraus.

mare_crisium

P.S: Die aktuelle Version der Datei OptWegmessungMe_Vxx.pdf in meinem Posting vom 12.09.2008 in diesem Thread.

Hallo mare_calculatium,

Zitat:

---

Zitat von mare_crisium

... Für alle, die dem Thread soweit gefolgt sind, hier die Antwort auf die Fragen von PRobot und jeffrey ...

---

Da ich diese Mausgeschichte vor einiger Zeit mal in meinem Projekt einbauen wollte (hatte es dann aber verworfen - zu grosses Bauvolumen, ichhattezuwenigAhnungvondemZeug etc.) muss ich das natürlich lesen.

Du rechnest solche Probleme ja schneller, als ich das aufarbeiten kann. Jedenfalls Kompliment und vielen Dank.

Übrigens kann ich mir das nicht verkneifen, sieh das bitte nicht als Pingeligkeit (vor allem nicht Dir gegenüber) an:

Zitat:

---

Zitat von mare_crisium

... Rechtsdrehungen haben in der Mathematik ein negatives Vorzeichen ...

---

Ganz streng formuliert ist das nur eine Vereinbarung, die hier für rechtshändige (auch rechtsdrehende genannt), kartesische Koordinatensysteme angewandt ist; es ist kein Naturgesetz. Da "man" ohne Not üblicherweise rechtsdrehende Koordinatensysteme voraussetzt oder ansetzt, gilt das meist - und darauf sind dann die üblichen, bekannten Formeln aufgebaut. Es könnte natürlich Ausnahmen geben, obwohl mir erstmal keine sinnvolle einfällt. Wieso die Drehung "linksrum" in einem "rechtshändigen" Koordinatensystem positiv angesetzt wird, ist in der Skizze in diesem Artikel gezeigt (ich habe jetzt extra nicht geschrieben, dass es damit einsichtig würde *ggg*) - es hat halt etwas mit der Anordnung der Koordinatenachsen zu tun, ganz lasch gesagt.

Buon giorno, Oberallgeier,

Na, lieber

Zitat:

---

Zitat von oberallgeier

mare_calculatium,

---

als

Zitat:

---

mare_calciocarbonatum

---

:-) !

Hast ja recht mit den verschiedenen Konventionen bzgl. Drehrichtungen und Koordinatensystemen. Nachdem ich aber mit den +84° statt der (richtigen) -84° 'reingefallen war, wollte ich für diese Sache eine ganz unmissverständliche Vereinbarung festschreiben.

Die Rechentabelle verwendet übrigens den Algorithmus zur Koppelnavigation, den wir damals gemeinsam mit SternThaler durchgearbeitet hatten.

Ciao,

mare_crisium

Da habe ich euch endlich gefunden ;-). Ich grüße euch.

Hallo mare_crisium, wie du weisst, bin ich ja nicht der wirkliche Mathematiker.
Du musst also genau aufpassen was ich jetzt schreibe, und entscheiden, ob das überhaupt relevant ist.

In deinem EXCEL-Blatt ist mir bei der Grafik im Reiter "Posting1_Datensatz1" aufgefallen, dass die Messpunkte nicht besonders lineare Abstände haben.
Zuerst hatte ich an eine Beschleunigung der Drehbewegung gedacht. (Start bei Koordinate [0|0]) Komisch fand ich dann aber die 'Ausreißer' im Bereich [-2|12]
Nun habe ich einfach mal deine im Excel angegeben delta_x und delta_y-Paare per Pythagoras als 'Wegstrecke' ausgerechnet. Hier hätte ich als Grafik eher etwas wie eine Parabel erwartet wenn eine Beschleunigung im Spiel wäre. Das ganze sieht mir aber eher aus wie 'Kraut und Rüben'.

Ich vermute, natürlich nur unter der Annahme, dass mein Mathe-Ansatz überhaupt eine Bedeutung hat, dass die Messwertaufnahme fehlerhaft ist. (Nicht schooon wieder.)
Entweder sind die Datenpunkte nicht mit konstanten Zeitabständen aufgenommen, oder der Sensor liefert Mist. (Oder Beides, was nicht zu hoffen wäre.)
Dagen spricht aber wohl, dass das berechnete Ergebnis ja schön kreisförmig ist. Wobei ich schon wieder einen unprofessionellen Jammerpunkt habe. Die Masstäbe der X- und Y-Achsen im berechneten Ergebnis wollen mir nicht so recht einleuchten.

Ansonsten bin ich davon überzeugt, dass ihr rechts und links auseinanderhalten könnt und mich auf dem laufenden haltet wenn sich da etwas ändert ;-).

Gute Nacht und
Gruß Sternthaler

P.S.: Hi, hi, hi. mare_calciocarbonatum ist nicht bei Google und Wikipedia bekannt. Muss ich da etwa ausnahmsweise mal selber denken :P ?

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

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

Zitat:

---

Zitat von Sternthaler

Holla zusammen.

Laut Datenblatt kommt auf ein "READ_DATA"-Kommando ein "FA nn nn nn"

---

Welches Datenblatt benutzt du?
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 :-b.

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

Hi, SternThaler,

Deine Demonstration mit der am Schwanz festgehaltenen Maus ist einfach umwerfend!! :-) Ich wünschte, mir würden 'mal solche Sachen einfallen.

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 ;-) zufall. das sind dann knappe 8 cm. bei nem kreisumfang von 62,8 cm ist das fast ne 8tel-drehung (wenn ich mich net verrechnet hab, sind des dann 45,8°)
bei der 90° drehung gab´s dann halt paar messfehler, denk ich.
mfg jeffrey
ps: ich hab die rechnung von strenthaler net nachgeprüft;-) aber bitte prüft mal meine sache nach.