1 Maussensor, Drehung berechnen [Archiv]

Archiv verlassen und diese Seite im Standarddesign anzeigen : 1 Maussensor, Drehung berechnen

PRobot

30.07.2008, 20:22

kaktus

30.07.2008, 22:18

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?

PRobot

30.07.2008, 22:46

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.

uwegw

30.07.2008, 23:20

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... ;))

oberallgeier

31.07.2008, 10:53

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?

jeffrey

31.07.2008, 11:21

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

oberallgeier

31.07.2008, 11:32

... das mit drhendem weltall, schiff und zug net wirklich geblickt, sorry... Da muss doch eher ich mich entschuldigen.

... 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.

... nur x interessiert für die drehung...
X ist eine (geradlinige, translatorische) Koordinate, die mit Drehung nichts zu tun hat.

... dalpha=dx/r ...Ok, und weiter ? ? ?

jeffrey

31.07.2008, 11:52

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

PRobot

31.07.2008, 18:06

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.

jeffrey

31.07.2008, 18:15

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

PRobot

31.07.2008, 22:13

Richard

31.07.2008, 23:45

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

Richard

31.07.2008, 23:50

[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

mare_crisium

01.08.2008, 16:50

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.

PRobot

02.08.2008, 08:04

@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

mare_crisium

05.08.2008, 12:39

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

PRobot

09.08.2008, 18:41

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.

PRobot

09.08.2008, 19:28

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/

PRobot

12.08.2008, 10:59

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.

mare_crisium

13.08.2008, 00:57

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.

PRobot

13.08.2008, 10:26

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.

PRobot

13.08.2008, 11:07

jeffrey

13.08.2008, 13:02

Richard

13.08.2008, 17:50

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

mare_crisium

13.08.2008, 18:07

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

mare_crisium

13.08.2008, 21:40

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

mare_crisium

19.08.2008, 16:00

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.

oberallgeier

19.08.2008, 16:30

Hallo mare_calculatium,

... 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:

... 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 (http://de.wikipedia.org/wiki/Drehrichtung) 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.

mare_crisium

20.08.2008, 15:27

Buon giorno, Oberallgeier,

Na, lieber

mare_calculatium,

als
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

Sternthaler

08.09.2008, 02:15

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 ?

jeffrey

08.09.2008, 11:36

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

PRobot

08.09.2008, 18:27

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!!!!!!

Sternthaler

09.09.2008, 02:40

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

jeffrey

09.09.2008, 11:32

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

PRobot

09.09.2008, 19:11

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/PAN3101_V10_20051121170653.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.

mare_crisium

09.09.2008, 22:31

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

Besserwessi

09.09.2008, 23:55

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.

Sternthaler

10.09.2008, 02:17

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

mare_crisium

10.09.2008, 09:24

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

jeffrey

10.09.2008, 12:06

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.

PRobot

10.09.2008, 15:56

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?

Hi!

/*!
* Uebertraegt ein write-Kommando an den Sensor
* @param adr Adresse
* @param data zu schreibendes byte
*/
void pan_write(unsigned char adr, unsigned char data){...}

Initialisierung:

//Reset PAN3101
pan_write(0x00,0x80); //Full chip reset
// kein Sleep modus
pan_write(0x00,0x01);

/*Liest die Daten aus dem PAN3101
Wird true zurückgegeben, haben sich die Koordinaten seit dem letzten Abruf
geändert, ansonsten nicht.*/
int pan_readPos(void){
unsigned char ino;
signed char buf_x,buf_y;

int ret;

//Endlosschleife

ino=pan_read(0x16);

//wenn 7tes bit vom Register 0x16 gesetzt ist wurde die Maus bewegt => Bewegungsdaten abfragen
if(ino&(1<<7)){
//Deltax Register auslesen
buf_x=pan_read(0x17);
//und zu der Positionvariable addieren
pan_posx += buf_x;

/* Nachschaun ob das Überlauf-Bit im Register 0x16 gesetzt ist
wenn das der Fall ist muss je nach Vorzeichen der Deltax Variable x
noch 128 (überlauf nach oben) dazugezählt oder eben 128 abgezogen werden
*/
if(ino&(1<<3)){
if(buf_x<0){
pan_posx-=128;
}else{
pan_posx+=128;
}
}

//ab hier nochmal das Gleiche für die yRichtung

buf_y=pan_read(0x18);
pan_posy += buf_y;

if(ino&(1<<4)){
if(buf_y<0){
pan_posy-=128;
}else{
pan_posy+=128;
}
}
ret= 1;
} else
ret = 0;

//hier kann jeder seine Ausgabevariante selber wählen ;)

//(*x) = pan_posx;
//(*y) = pan_posy;

return ret;
}

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 bin auch definitiv davon Überzeugt, dass sich der Y-Wert bei einer Drehung genau um den Mittelpunkt nicht ändern darf (laut Mathematischer logik).

PRobot

10.09.2008, 20:39

Ich habe jetzt einen Fehler beim Anschluss des Maussensors gefunden:
Der "PS2 Chip", welcher vorher zuständig war, die Daten des Sensors auszuwerten und an den PC weiterzuleiten, war ncoh mit dem Maussensor verbunden und hat mir wahrscheinlich immer Daten "gestohlen".

Wenn ich jetzt Alpha neu messe, bekomme ich einen viel kleineren Wert:

Gefahrene Strecke in Ticks auf 100mm
1516,6|29663

Umrechnungsfaktor
ɑ = 0,003371203

Fehlausrichtung: ψ 1,519713139 = 87,07314896°

Dazu habe ich auch eine .xls erstellt.

@mare_crisium
Dabei habe ich herausgefunden, dass ich bei der Gefahrenen Strecke in Ticks den Absolutwert (positiven Wert) nehmen muss, damit ich für wq eine Zahl um 0 erhalte. Ansosnten ist der Wert für wq 10 mm was meiner Meinung nach falsch ist.

In der PDF wäre auch empfehlenswert anzugenben, in welcher einheit "d" in die Drehwinkel-Formel eingesetzt werden muss.

Sternthaler

10.09.2008, 21:05

Hallo zusammen

@PRobot
danke für die Codeschnippsel. Das sieht ja sehr gut aus.

Bei der Berücksichtigung von einem eventuellen Überlauf:
buf_x=pan_read(0x17);
//und zu der Positionvariable addieren
pan_posx += buf_x;

/* Nachschaun ob das Überlauf-Bit im Register 0x16 gesetzt ist
wenn das der Fall ist muss je nach Vorzeichen der Deltax Variable x
noch 128 (überlauf nach oben) dazugezählt oder eben 128 abgezogen werden
*/
if(ino&(1<<3)){
if(buf_x<0){
pan_posx-=128;
}else{
pan_posx+=128;
}
}addierst bzw. subtrahiert du die 128.
Ist es richtig, dass abgezogen wird, wenn buf_x < 0 ist?
Ich werfe dese Frage nur in der Raum, das ja die Werte in Register 0x17 und 0x18 als 2'er complement angegeben sind.
Ich bin mir sicher, dass es so korrekt sein müsste, aber dies könnte nochmal eine Stelle zum Nachdenken sein.

Und in deinem EXCEL komme ich in dem Block 'Umrechnungsfaktor' mit dem Wert '1 mm = 296,63 Ticks' nun auf 7534,402 Tiks / inch
Das glaube ich nicht ;-)

@jeffrey
Erst mal was einfaches: Das c steht für count (count per inch = cpi)
Deine Rechnung konnte ich so nachvollziehen. Aber Vorsicht mit den, mal von mir in den Raum geworfenen, 400 cpi (die ja mal nur 40 waren). Dieser Sensor müsste 800 cpi zu haben. Ich hatte mich ja auf eine Doku gestützt, die hier nicht relevant ist.

Jetzt muss ich erst einmal nach Hause
Gruß Sternthaler

mare_crisium

10.09.2008, 22:08

Howdy, PRobot,

prima, dass Du den Fehler gefunden hast! Durch Deine Rechentabelle habe ich auch einen in meinem pdf _V04 gefunden :-( . Im Anhang meine Version Deiner Rechnung. Die Absolutwerte brauchst Du nicht zu nehmen. V_05 der pdf-Datei kommt demnächst.

Ciao,

mare_crisium

Besserwessi

11.09.2008, 21:01

Die Y Werte kommen sowohl durch die Einbaulage als auch durch den Winkel des Sonsors. Wie schon oben geschrieben kann man den Winkel des Sensors einfach durch eine Drehmatrix korrigieren. Die XLS Files kann ich leider nicht lesen, deshalb wiess ich nicht welche Formeln da drinstehen. Nach dem Korrigieren der Drehung gibt dann die eine Achse (hier wohl X) die Drehung und die andere den zurückgelegten Weg. Wenn der Sensor wie gezeichent etwas ausserhalb der Mitte ist, kriegt man halt eine kleinen Weg auf einem Kreis, wenn man den Robot um die Mitte dreht.

mare_crisium

12.09.2008, 23:14

Guten Abend zusammen,

hier ist die versprochene neue Version in der ich den (hoffentliche letzten :-) ) Fehler beseitigt und die Kalibiermethode von PRobot eingebaut habe.

@jeffrey,
Ja, es ist möglich, dass der Asuro trotz identischer Messwerte von beiden Odometern nicht geradeaus fährt: Es reicht aus, wenn die beiden Raddurchmesser sich unterscheiden.

@Besserwessi,
die .xls-Dateien kannst Du lesen, wenn Du Dir OpenOffice herunterlädst und installierst.

Ciao,

mare_crisium

Edit: Anhang gelöscht wg. Upload-Quota

PRobot

13.09.2008, 15:20

Hi mare_crisium
jetzt scheint die Berechnung zu stimmen.
Ich bekomme jetzt auch die richtigen werte für Wegstrecken und -längen:
Wegstrecke wp 1000,000000 mm
Wegstrecke wq 0,000000 mm
Weglänge si 1000 mm
Drehwinkel -1,22288E-16 -7,00659E-15

Um die Drehung zu berechnen, muss ich wie folgt vorgehen:
*Die Startposition wird gespeichert (z.B. 0|0)
*Der Roboter dreht sich auf dem Mittelpunkt
*Nach der Drehung wird die Endposition gespeichert (z.B. 1622|107) (diese koordinaten sollten 45° entsprechen)
*Die deltaX (=1622) und deltaY (=107) in die Winkel Formel von mare_crisium einsetzten
*Das Ergebnis sollte Theoretisch in diesem Fall 45° ergeben
*Die Messwerte liegen bei mir aber immer ungefähr 16% oberhalb des *Richtwertes, also muss ich das Ergebnis noch mit 0,84 multiplizieren.
*Somit erhalte ich ein Ergebnis mit ca. 2-3 Grad abweichung

Jetzt muss ich das alles nochmals genauer in Versuche ausprobieren, wie sich der Roboter verhält

mare_crisium

13.09.2008, 23:47

Hi, PRobot,

prima, dass es jetzt klappt :-) ! Den ersten Teil Deines Postings verstehe ich so, dass Du den Maussensor nun so justiert hast, dass eine seiner Messrichtungen in Fahrtrichtung zeigt.

Der zweite Teil macht mir aber noch zu schaffen, weil der Faktor 0,84 nicht sein darf. Ich habe also Deine die Daten in die Rechentabelle eingegeben (x (Ticks) = 107 in Spalte A, y (Ticks) = 1622 in Spalte B). Ausserdem habe ich den maus_winkel auf 0 und alpha auf 0,0313 gesetzt. Als Zwischenergebnis zeigt mir die Spalte J einen Drehwinkel von 46,5°. Das wäre ja gar nicht mal so schlecht. Aber aus den Spalten L und M bekomme ich dann einen Drehwinkel von nur 39° heraus.

Die Erklärung, warum der aus Spalte L und M berechnete Winkel so weit daneben liegt, ist folgende: In Spalten L und M wird numerisch integriert. Dieses Verfahren liefert nur dann brauchbare Werte, wenn viele, möglichst kleine Teilschritte verarbeitet werden; grosse Teilschritte führen zu einem sehr ungenauen Ergebnis.

Könntest Du noch einen Versuch machen, bei dem Du während der Drehung möglichst viele Zwischenwerte speicherst? Dann sollte auch das Ergebnis aus Spalte L und M genauer werden. Nur mit einem Faktor kannst Du Integrationsfehler nicht ausgleichen.

Ciao,

mare_crisium

P.S.: Ich hänge noch ein pdf an, dass Dir den Bahnintegrations-Algorithmus erklärt.

Eidit: Anhang siehe mein Beitrag vom 28.09.2008

PRobot

17.09.2008, 21:51

Ich habe jetzt einige Messungen durchgeführt, wo ich den Roboter mit der Hand manuell im Kreis gedreht habe und alle 250ms die Position gemessen wird.
Ich habe folgende Messungen durchgeführt:
5 x gemessen für 90°
5 x gemessen für 45°
3 x gemessen für 180°

Ich habe auch gleich Versucht, die Messdaten in die Excel-Datei von mare_crisium auszuwerten.
Ich kann nur folgendes zu mare_crisium's Arbeit sagen: :APPLAUS: :APPLAUS: :APPLAUS:
Ich erhalte folgende Endwinkel bei den Messreihen:
90° 1. Messung: -114,7°
90° 2. Messung: -93,7°
90° 3. Messung: -94,4°
90° 4. Messung: -91,3°
90° 5. Messung: -108,0°

45° 1. Messung: -47,3°
45° 2. Messung: -40,5°
45° 3. Messung: -45,2°
45° 4. Messung: -41,8°
45° 5. Messung: -53,9°

180° 1. Messung: -175,9°
180° 2. Messung: 171,4°
180° 3. Messung: -171,7°

Also die Werte (zumindest bei 45° und 90 °) sind verdammt nahe am sollwert.

Noch etwas ist mir aufgefallen:
Wenn der letzte Wert der y-Koordinate der Spalte m (also "e_p (normiert)") negativ ist, so ist auch der Winkel negativ.
Bei der 2. Messung bei 180° ist dieser Wert aber Positiv und somit auch der Winkel positiv.
Also muss ich den Betrag vom Endwinkel nehmen, um zu bestimmen, wie viel sich der Roboter in die entsprechende Richtung gedreht hat.

Hier noch die .xls (Diesmal im Zip Format, da die Datei ansosten zum Hochladen zu groß ist) wo ich die Messdaten und die Dazugehörige Auswertung habe.

Jetzt muss ich nur noch einen Alghorithmus entwickeln, welcher das dann alles Ausrechnet, was aber nur ein kleines Problem im Vergleich zu dem Ganzen hier ist. O:)

Also Danke nochmals an alle und natürlich an erster Stelle an mare_crisium

mare_crisium

19.09.2008, 21:02

PRobot,

vielen Dank für das Lob - es freut mich, dass ich Dir weiterhelfen konnte. In Deiner Datei habe ich die Diagramme und die Berechnungen in Spalten T und U geändert. Der Diagrammtyp muss "X-Y-Diagramm" sein und der Datenbereich muss die Spalten T und U umfassen. In Spalten T und U musst Du Spalte H als "s_i" nehmen, weil Dein Robby in Richtung der y-Achse fährt. Die Diagramme zeigen jetzt sehr schön die Bahn an, die Dein Robby gefahren ist. - Leider kann ich nicht zippen, deshalb habe ich von Deinen Tabellen immer nur die ersten beiden beibehalten.

In dem Konzept stecken aber noch mehr Möglichkeiten: Wenn man den Ort des Fahrzeugs (wie in _V103a.pdf beschrieben) und seine Fahrtrichtung kennt (den Vektor e_p (normiert)), kann man auch den Richtungswinkel zu einem Zielort ausrechnen. Die z-Komponente des Kreuzproduktes von e_p (normiert) und dem Einheitsvektor zum Zielpunkt liefert den Sinus dieses Winkels und eignet sich ganz prima, um den Robby geregelt auf das Ziel losfahren zu lassen.

Im übrigen sind heute meine ADNS2610 angeliefert worden :-) .

Ciao,

mare_crisium

Edit: Anhang gelöscht wg. Upload-Quota

PRobot

26.09.2008, 17:38

Ich habs geschafft: \:D/
Jetzt habe ich einen funktionierenden Code zur berechnung der Drehung mit Hilfe von mare_crisiums Dokumentationen und .xls erstellt:
(Falls ihr Verbesserungsvorschläge habt, bitte melden)
Dazu sind 2 Funktionen nötig:
-Eine zum Initialisieren der Variablen, welche beim Start des Roboters aufgerufen wird
-Eine, welche immer nach einer kurzen Drehung die aktuelle Position auswertet.

Also hier der Code (einfach in eine Header File kopieren und im Programm includieren)
ACHTUNG: Die defines müssen an euren Maussensor angepasst werden. Zur näheren Beschreibung und zur Berechnung siehe in der Dokumentation von mare_crisium weiter vorn im Thread.

/*
################################################## #
27.09.08 - TurnAlgorithm.h
---------------------------------------------------
Header File welche diverse Funktionen zum Berechnen
der Drehung beinhaltet

################################################## #
*/

#include <stdlib.h>
#include <math.h>

//PI mit 2 multipliziert (= 360°)
#define PI_DOUBLE 6.283185307179586476925286766559

//PI mit 2 dividiert (= 90°)
#define PI_HALF 1.5707963267948966192313216916398

// Benötigte Variablen zur Berechnung
#define TURN_ALGO_ALPHA 0.0336681 //Benötigter Wert zum Umrechnen von Ticks in mm
#define TURN_ALGO_DIST 62.6 //Abstand zwischen Maussensor-Messpunkt und Roboter-Mittelpunkt in mm
#define TURN_ALGO_MOUSE_ANGLE -1.62187951 //Fehlausrichtungswinkel der x-Richtung der Maus zur Längsachse des Roboters im Bogenmaß
#define TURN_ALGO_COS_MOUSE_ANGLE -0.05106097 //cos(TURN_ALGO_MOUSE_ANGLE)
#define TURN_ALGO_SIN_MOUSE_ANGLE -0.99869554 //sin(TURN_ALGO_MOUSE_ANGLE)

/**
* Initialisiert die Variablen, welche benötigt werden, um die Drehung zu berechnen
* @param CurrX Beinhaltet die aktuelle X-Position des Sensors
* @param CurrY Beinhaltet die aktuelle X-Position des Sensors
* @param LastX Pointer auf die Variable mit der letzten X-Koordinate (übergabe an Funktion TurnAlgo_update)
* @param LastY Pointer auf die Variable mit der letzten Y-Koordinate (übergabe an Funktion TurnAlgo_update)
* @param Last_e_p_norm_x Pointer auf die Variable mit dem letzten Wert von e_p (normiert) x (übergabe an Funktion TurnAlgo_update)
* @param Last_e_p_norm_y Pointer auf die Variable mit dem letzten Wert von e_p (normiert) x (übergabe an Funktion TurnAlgo_update)
* @param Last_e_q_norm_x Pointer auf die Variable mit dem letzten Wert von e_q (normiert) x (übergabe an Funktion TurnAlgo_update)
* @param Last_e_q_norm_y Pointer auf die Variable mit dem letzten Wert von e_q (normiert) y (übergabe an Funktion TurnAlgo_update)
* @param turnAngle Pointer auf die Variable welche den Winkel beinhalten wird (übergabe an Funktion TurnAlgo_update)
*
*/

void TurnAlgo_init(int CurrX, int CurrY, int *LastX, int *LastY, double *Last_e_p_norm_x, double *Last_e_p_norm_y, double *Last_e_q_norm_x, double *Last_e_q_norm_y, double *turnAngle)
{
*LastX = CurrX;
*LastY = CurrY;
*Last_e_p_norm_x = 1.0;
*Last_e_p_norm_y = 0.0;
*Last_e_q_norm_x = 0.0;
*Last_e_q_norm_y = 0.0;
*turnAngle = 0.0;
}

/**
* Wird nach jeder kurzen Drehung aufgerufen, um den neuen Winkel zu berechnen
* @param CurrX Beinhaltet die aktuelle X-Position des Sensors
* @param CurrY Beinhaltet die aktuelle X-Position des Sensors
* @param LastX Pointer auf die Variable mit der letzten X-Koordinate (übergabe an Funktion TurnAlgo_update)
* @param LastY Pointer auf die Variable mit der letzten Y-Koordinate (übergabe an Funktion TurnAlgo_update)
* @param Last_e_p_norm_x Pointer auf die Variable mit dem letzten Wert von e_p (normiert) x (übergabe an Funktion TurnAlgo_update)
* @param Last_e_p_norm_y Pointer auf die Variable mit dem letzten Wert von e_p (normiert) x (übergabe an Funktion TurnAlgo_update)
* @param Last_e_q_norm_x Pointer auf die Variable mit dem letzten Wert von e_q (normiert) x (übergabe an Funktion TurnAlgo_update)
* @param Last_e_q_norm_y Pointer auf die Variable mit dem letzten Wert von e_q (normiert) y (übergabe an Funktion TurnAlgo_update)
* @param turnAngle Pointer auf die Variable welche den Winkel beinhalten wird (übergabe an Funktion TurnAlgo_update)
*
*/
void TurnAlgo_update(int CurrX, int CurrY, int *LastX, int *LastY, double *Last_e_p_norm_x, double *Last_e_p_norm_y, double *Last_e_q_norm_x, double *Last_e_q_norm_y, double *turnAngle)
{
double delta_x = (CurrX - (*LastX)) * (double)TURN_ALGO_ALPHA; //Delta X in mm
double delta_y = (CurrY - (*LastY)) * (double)TURN_ALGO_ALPHA; //Delta Y in mm
double delta_y_norm = delta_x * (double)TURN_ALGO_SIN_MOUSE_ANGLE + delta_y * (double)TURN_ALGO_COS_MOUSE_ANGLE; //Delta Y in mm mit berücksichtigung der Fehlausrichtung
double delta_angle = delta_y_norm / (double)TURN_ALGO_DIST;

double e_p_not_norm_x = (*Last_e_p_norm_x) + delta_angle * (*Last_e_q_norm_x); //e_p (nicht normiert) x
double e_p_not_norm_y = (*Last_e_p_norm_y) + delta_angle * (*Last_e_q_norm_y); //e_p (nicht normiert) y
double e_p_not_norm_sum = sqrt(pow(e_p_not_norm_x,2) + pow(e_p_not_norm_y,2)); //Betrag von e_p (nicht normiert)

double curr_e_p_norm_x = e_p_not_norm_x/e_p_not_norm_sum;
double curr_e_p_norm_y = e_p_not_norm_y/e_p_not_norm_sum;

*LastX = CurrX;
*LastY = CurrY;
*Last_e_p_norm_x = curr_e_p_norm_x;
*Last_e_p_norm_y = curr_e_p_norm_y;
*Last_e_q_norm_x = e_p_not_norm_y * (-1);
*Last_e_q_norm_y = e_p_not_norm_x;

*turnAngle = atan2(curr_e_p_norm_y, curr_e_p_norm_x) * (-1); //Winkel im bereich von [-179,179]
if (*turnAngle < 0)
*turnAngle = PI_DOUBLE + *turnAngle;

}

Ich habe das alles so realisiert, dass der Drehfunktion die Variablen der Vorherigen dreh-berechnung als Pointer übergeben werden.

In der TurnRobot funktion kann ich einfach einen Winkel übergeben, zu dem hingedreht werden soll, also nicht, um wieviel gedreht wird. Würde man der Funktion zu umschreiben, dass man übergibt, um wie viel gedreht wird, dann wäre die Fehlerwahrscheinlichkeit sehr viel höher.
Man kann auch mal einfach Geradeaus fahren, und danach Drehen. Die absolute Winkelangabe sollte dann trozdem funktionieren.

Ein Aufruf könnte dann wie folgt aussehen

int TurnAlgo_LastX;
int TurnAlgo_LastY;
double TurnAlgo_Last_e_p_norm_x;
double TurnAlgo_Last_e_p_norm_y;
double TurnAlgo_Last_e_q_norm_x;
double TurnAlgo_Last_e_q_norm_y;
double TurnAlgo_currAngle;

// -------------- Main-Funktion --------------
int main(void)
{
/*###Initialisierungsphase###*/
// ... eigene Initialisierungen

TurnAlgo_init(0, 0, &TurnAlgo_LastX, &TurnAlgo_LastY, &TurnAlgo_Last_e_p_norm_x, &TurnAlgo_Last_e_p_norm_y, &TurnAlgo_Last_e_q_norm_x, &TurnAlgo_Last_e_q_norm_y, &currAngle);

while(1)
{
//Hauptschleife
}
}

/**
*Dreht den Roboter zum angegebenen Winkel
* @param degree Grad, auf die gedreht werden soll
*/
void turnRobot(int endDegree)
{
int startPos_X, startPos_Y;
pan_getPos(&startPos_X, &startPos_Y);

TurnAlgo_update(startPos_X, startPos_Y, &TurnAlgo_LastX, &TurnAlgo_LastY, &TurnAlgo_Last_e_p_norm_x, &TurnAlgo_Last_e_p_norm_y, &TurnAlgo_Last_e_q_norm_x, &TurnAlgo_Last_e_q_norm_y, &TurnAlgo_currAngle);

double startAngle = TurnAlgo_currAngle;

double endAngle = (M_PI * endDegree) / 180.0;

//Winkel in Bereich von 0 bis 360° (= PI_DOUBLE) umrechnen
while (endAngle >= PI_DOUBLE)
endAngle -= PI_DOUBLE;
while (endAngle <0)
endAngle += PI_DOUBLE;

double diff = endAngle - TurnAlgo_currAngle;

//Gibt an, ob sich der Roboter gegen den Uhrzeiger (mathematischer Drehsinn) = 0 oder mit dem Urhzeiger = 1 dreht
int turnDirection = 0;

//Überprüfung, ob Differenz mehr als 180° (= PI), wenn ja, andere Drehrichtung verwenden, da dort der Weg kürzer ist.
if (diff > M_PI)
{
turnDirection = 1;
diff -=PI_DOUBLE;
}
else if (diff < M_PI*(-1))
{
turnDirection = 0;
diff +=PI_DOUBLE;
}
else if (diff > 0)
turnDirection = 0;
else if (diff < 0)
turnDirection = 1;
else
{
return; //Nothing to do
}

int speedL;
int speedR;

if (turnDirection == 0) //Drehrichtung = 0
{
speedL = -245;
speedR = 255;
}
else if (turnDirection == 1) //Drehrichtung = 1
{
speedL = 255;
speedR = -245;
}

int newPos_X, newPos_Y;

//Schleife wird auch innerhalb unterbrochen, sobald der endAngle erreicht ist
while (startAngle!=endAngle)
{
moveRobot(speedL, speedR, 3);
pan_getPos(&newPos_X, &newPos_Y);

TurnAlgo_update(newPos_X, newPos_Y, &TurnAlgo_LastX, &TurnAlgo_LastY, &TurnAlgo_Last_e_p_norm_x, &TurnAlgo_Last_e_p_norm_y, &TurnAlgo_Last_e_q_norm_x, &TurnAlgo_Last_e_q_norm_y, &TurnAlgo_currAngle);

if (TurnAlgo_currAngle == endAngle)
break;
if (turnDirection == 0)
{
if ((startAngle < endAngle) && (TurnAlgo_currAngle >= endAngle))
break; //Beim startWinkel 170° abziehen, da es vorkommen kann, dass der TurnAlgo_currAngle den Winkel 259° anstatt 0° hat und dann unterbrochen werden würde
else if ((startAngle > endAngle) && (TurnAlgo_currAngle >= endAngle) && (TurnAlgo_currAngle < startAngle - 2.9670597283903602807702743064306)) //Bereich liegt über dem 4. und 1. Quartal
break;
}
else if (turnDirection == 1)
{
if ((startAngle > endAngle) && ((TurnAlgo_currAngle <= endAngle) || (TurnAlgo_currAngle > endAngle + M_PI)))
break; //Beim startWinkel 170° addieren, da es vorkommen kann, dass der TurnAlgo_currAngle den Winkel 1° anstatt 0° hat und dann unterbrochen werden würde
else if ((startAngle < endAngle) && (TurnAlgo_currAngle <= endAngle) && (TurnAlgo_currAngle > startAngle + 2.9670597283903602807702743064306)) //Bereich liegt über dem 4. und 1. Quartal
break;
}

}
}

Danke an alle die mitgeholfen haben.

Edit: Code verbessert

Edit 2 (Dez. 2014): PDF von mare_crisium zur Berechnung erneut hochgeladen: (siehe post #62):
https://www.roboternetz.de/community/threads/37472-1-Maussensor-Drehung-berechnen?p=609113&viewfull=1#post609113

mare_crisium

27.09.2008, 18:45

PRobot,

prima :-) ! Beim Durchsehen des Algorithmus (mit beschränkten C-Kenntnissen) ist mir nur aufgefallen, dass Du e_q_norm_y mit 0.0 initialisierst; der Startwert muss aber 1.0 sein.

Auf die Variablen e_q_norm_x und e_q_norm_y kannst Du ganz verzichten, wenn Du schreibst

double e_p_not_norm_x = (*Last_e_p_norm_x) - delta_angle*(*Last_e_p_norm_y)
double e_p_not_norm_y = (*Last_e_p_norm_y) + delta_angle*(*Last_e_p_norm_x)

Das ist eine mögliche, aber keine notwendige Vereinfachung des Programms.

Freut mich, dass Du's hingekriegt hast. Berichte 'mal über die Testfahrten!

Ciao,

mare_crisium

Edit: Fehler in Formel für e_p_not_norm_y korrigiert: Zeiger (*Last_e_p_norm_x) durch Zeiger (*Last_e_p_norm_y) ersetzt (Danke, für den Hinweis, SternThaler :-) !

Sternthaler

28.09.2008, 03:05

Guten Morgen zusammen.

@mare_crisium
e_q_norm_y mit 0.0 oder 1.0 initialisieren?
Ich kann diese Variablen nicht finden? Meinst du die Variable Last_e_q_norm_y, die in der Funktion TurnAlgo_init() auf 0.0 gesetzt wird?

Falls dein Vorschlag mit der Vereinfachung oben im Programm von PRobot schon enthalten ist, dann ist dort ein Unterschied zu deinem Vorschlag:
Du mare_crisium schreibst:
double e_p_not_norm_x = (*Last_e_p_norm_x) - delta_angle*(*Last_e_p_norm_y)
Gefunden bei PRobot habe ich:
double e_p_not_norm_x = (*Last_e_p_norm_x) + delta_angle * (*Last_e_q_norm_x)

Und auch bei "double e_p_not_norm_y = ..." finde ich einen Unterschied.

Ansonsten kann ich der Mathematik (leider) nicht mehr folgen.
Nur bei deinen im letzten Post angegeben Excel-Diagramme bekomme ich in den Kopf, dass es sich um wunderbare Halbkreise handelt ;-). Jubel, habt ihr gut gemacht.

Lasst euch bloß nicht von meinem Geschreibsel stören. Wahrscheinlich ist das sowieso nicht relevant.
Gruß Sternthaler

radbruch

28.09.2008, 03:42

Lasst euch bloß nicht von meinem Geschreibsel stören.
Ist doch immer wieder nett etwas von dir zu lesen :)

mare_crisium

28.09.2008, 13:37

Einen schönen Sonntagmorgen!
@ SternThaler,

Ihr habt zwar noch Oktoberfest, aber deshalb musst Du Deine Mathekenntnisse nicht gleich unter die Moass stellen!

Deine erste Anmerkung ist richtig: Ich meine "Last_e_q_norm_y".

Der zweite Unterschied, den Du bemerkt hast, ist genau die Vereinfachung, die ich vorschlagen wollte: e_q_norm_x ist gleich (-1)*e_p_norm_y und e_q_norm_y ist e_p_norm_x. Erinnerst Du Dich: Das ist der Trick, mit dem man einen Vektor um +90° drehen kann ;-). PRobot hat den Vorschlag noch nicht eingearbeitet.

Ansonsten kann ich der Mathematik (leider) nicht mehr folgen.

Na, damit Du wieder Mut schöpfst, hänge eine neue Version des Algorithmus an, in der ich versucht habe, die Sache mit ein paar zusätzlichen Zeichnungen verständlicher zu machen.

@ radbruch:
Gönn' doch dem armen Haifisch auch mal ein Erfolgserlebnis!!

Ciao,

mare_crisium

Edit: Anhang gelöscht wg. Upload-Quota

jeffrey

28.09.2008, 16:58

hoi,
also beim letzten bild stimmt irgendwas net ganz. sonst hab ich des ganze net wirklich durchgelesen. aber da es funktioniert scheint es au zu stimmen ;-)
mfg jeffrey

mare_crisium

28.09.2008, 18:19

jeffrey,

danke für den Hinweis. Hab's ausgebessert.

mare_crisium

Sternthaler

29.09.2008, 00:06

Hai zusammen. (Wenn er denn mal was zu futtern bekommt? Ha, ha, ha.)

@radbruch: Lass bitte, bitte den armen Smilie leben. Für den Hai spende ich mal ne Makrele.
Und hier kann man sehen, dass die Beiden Freunde sind (so passiert auch der Makrele nix.): http://www.taucher.net/edb/Embudu_Village__Sued-Male_Atoll_b63.html
(ca. 1/4 der Seite scrollen)

Jetzt weiß ich wenigstens, warum ich dem Ganzen wohl nicht folgen konnte.
Liegt vor allem nicht am Oktoberfest, da ich etwas weiter nördlich, recht dicht beim Liborifest, zu finden bin. Wir trinken hier Bier nicht im Moass, sondern in Massen ;-). Und am Samstag war es aber mal wieder Wein mit Freunden.

Mathe, und 90°-Drehung:
Gut, dass du mare_crisium, noch mal deinen Koppelnavigations-Algorithmus mitschickst. Ich bin mir recht sicher, dass es sich bei deinem Vorschlag um die Formel (2.7) handeln müsste.
Dann aber sollte doch die Berechnung bei deinem Vorschlag zum Ermitteln von e_p_not_norm_y mit:
double e_p_not_norm_y = (*Last_e_p_norm_y) + delta_angle*(*Last_e_p_norm_x)
erfolgen? Oder etwas doch nicht?
Seht ihr nun warum ich lieber auf die Wiesen gehen sollte? Ich kann nämlich nur bei euch nachlesen was ihr so tolles macht, es aber nicht selber nachrechnen, so dass am Ende eben nur merkwürdige Hinweise kommen können. Die gebe ich euch natürlich auch dann in Moassen, selbst wenn ihr nicht danach fragt ;-).

Einen ruhigen, erfolgreichen Wochenbeginn wünscht euch
Sternthaler

mare_crisium

29.09.2008, 02:23

Guten Morgen, zusammen!

@Tierfreund SternThaler:
hast recht: Es ist Formel (2.7) und den Fehler im alten Posting habe ich korrigiert.

Wohnst Du wirklich in der Nähe von London? (London Interbank Borrowing Rate - Fest???)

Ciao,

mare_crisium

Sternthaler

29.09.2008, 03:07

Na, wer ist denn noch alles wach?

@LustigeIdeen-mare_crisium
Ne, ab übermorgen nicht mehr. Nachdem ich einen Teil der letzten Überweisung einer Deu.Bank (KxW, oder so ähnlich) aus u s a habe umleiten können, werde ich nun auf so eine kleine Insel umziehen. Dort kann man hervorragend Fische und Smilies beobachten ;-)

Nun aber erst einmal ein: Gute Nacht
Sternthaler

oberallgeier

29.09.2008, 10:06

... Wir trinken hier Bier nicht im Moass, sondern in Massen ...Hmmmmmm, grübelgrübel: vermutlich nicht ausm Moass, klar, da ist ja auch kein ganzer Liter drin, laut Aussage eines unbedeutenden Lokalpolitikers - der wohl andauernd zumindest gegen das Eichgesetz verstößt. Ohhh - Lokalpolitiker - das hat ja ein paar hübsche Nebenbedeutungen (Lokal = Wirtschaft/Alk-ausschank) . . . . oder sind das dann die Hauptbedeutungen . . . . und ich hab´s nur bisher nicht gerafft ! ? ! ? ! !

... sondern in Massen: also trinken zu hunderten Leuten, die beieinander sitzen und sich zum Kom.saufen animieren? Oder ihr trinkt das Bier einfach massenhaft?

Dazu diese Anmerkung (ist ja sowieso schon alles OT):
Nordlich zum Bayern: Nu sajen sie mal, Mann, wat trinken sie denn so viel Bier? Bayer: Jo woils mir holt schmeckd! Nordlicht: Also ich trinke nur soviel, wie ich Durst habe. Bayer: Grod wia d`Viechar.

... merkwürdige Hinweise ... selbst wenn ihr nicht danach fragt ...Das erinnert mich total an unbedeutende und auch bedeutende Lokal- und sonstige Politiker. Die reden auch immer ungefragt - das ging ja noch - aber unquali . . . . ok, ich hör auf.

PRobot

03.12.2014, 20:08

Hier für die Nachwelt gesichert, die PDF von mare_crisium. Viel Spaß!!

Wepamat

04.12.2014, 08:55

Vielen Dank! Super, dass du die PDF nach 6 Jahren noch gefunden hast..