Zur Abwechslung mal ein Mathematisch/Geometrisches Rätsel

[robodriver]

Hi Leute,

beim Bau meines Roboters saß ich letztens vor einem sehr interessanten Rätsel.
Mittlerweile habe ich eine Lösung dafür gefunden.

Nun dachte ich mir, das wäre doch mal eine tolle Rätselaufgabe fürs Forum :)
Vielleicht findet ja sogar jemand noch eine bessere Lösung als ich sie habe.

Folgende Aufgabe soll realisiert werden:
Mein Roboter soll erfassen können wo in meiner Wohnung er sich befindet.
Dafür greife ich zum üblichen Koordinatensystem. (Auflösung in Millimeter!)
Ein Fester Punkt in meiner Wohnung (eine Äußere Ecke) hat die Koordinaten (0, 0)
Somit kann sich der Bot immer nur im positiven Bereich bewegen.
Negative Koordinaten gibt es nicht.
Zum fahren gibte es folgende vier Szenarien, für die es jeweils eine Formel zu

entwerfen gilt:
1.: in Vorwährtsrichtung fahren
2.: nur das rechte Rad dreht einzeln (nach vorne)
3.: nur das linke Rad dreht einzeln (nach vorne)
4.: in rückwärtiger Richtung fahren

(Der Controller weiß zu jeder Zeit in welchem Szenario er sich befindet, da er die Fahrbefehle selbst an einen anderen Controler gibt)

Es soll möglichst genau ermittelt werden an welcher Position im Koordinatensystem sich der Roboter befindet (best mögliche Genauigkeit ist gefordert, 100% genau geht es [glaub ich] nicht)
Wie oft bzw. bei welchem Ereigniss eine Berechnung erfolgt und wie mit Variablen verfahren wird, das müsst ihr selbst bestimmen bzw. herausfinden was das beste/sinnvollste ist

Daten:
- Der Roboter besitzt 2 separat getriebene Räder mit Radencodern.
- Die Encoder geben 255 Incremente pro Radumdrehung.
- Die Encoder gehen auf 2 Timer im Controller, welche als 8-Bit Counter arbeiten. So dass die Counter im Controller immer einen Wert zwischen 0 und 255 aufweisen
- Der Radumfang beträgt 22cm.
- Der Abstand der beiden Räder beträgt 25cm.
- Der logische Punkt des Roboters im Koordinatensystem liegt genau mittig zwischen den beiden Antrieben (auf der verlängerten Achse der Antriebs)
- Es wird davon ausgegangen das es keinen Schlupf gibt.


Hinweis:
Es ist wichtig, das beim fahren in vorwärtsrichtung NICHT einfach nur die Radumdrehung auf die Koordinaten aufaddiert werden. Hierbei sollen äußere Einflüsse beachtet werden.
So das sich die Berechnung auch nicht aus der Bahn werfen lässt, wenn ein Rad mal kurzzeitig etwas langsamer dreht (wegen Hinderniss oder unterschiedlichem Untergrund).
Danach fährt der Roboter nämlich in eine andere Richtung ;)

Zusatz:
Für die ganz schlauen: Ihr solltet versuchen für das Szenario 1-3 eine Formel zu entwerfen. (Mach bar ist es, ich habe das jetzt auch so gelöst)


Beispiel:
Hier noch 2 kleine Beispiele zum (hoffentlich) besseren Verständniss:
1. Fall:
Der Roboter befindet sich bei x: 150 und y: 200 (150, 200)
nun drehen beide Räder jeweils 255 Incremente nach vorne (Szenario 1)
somit wären die neuen Koordinaten bei (150, 420)
(Weil er sich ja um 220mm Richtung y bewegt hat)
2. Fall:
Der Roboter befindet sich bei x: 150 und y: 200 (150, 200)
Nun dreht nur das linke Rad, so lange das sich der Roboter um 90° gedreht hat.
Danach würde er sich dann bei x: 162,5 und y: 212,5 befinden.

Wer diese beiden Fälle nicht versteht oder nicht nachvollziehen kann, braucht gar nicht erst an zu fangen das Rätsel zu lösen.

Noch ein kleiner Tipp von meiner Seite:
Nacht euch Zeichnungen auf einem Blatt, das hilft ungemein beim erstellen der Formeln und beim Nachvollziehen.

PS: Die beiden Fälle ziegen nur die Ergebnisse, aber nicht den Lösungsweg, da ich nicht zu viel der Lösung verraten möchte. Ihr müsst natürlich immer von den Grunddaten, den Incrementen des rechten und linken Rades ausgehen und mit diesen beiden Werten und eventuell von vorherigen Rechnungen verwendete Variablen/Zwischenergebnisse alles andere Berechnen. Denn so viel kann ich schon einmal sagen: Die Räder werden niemals gleich drehen.

[jeffrey]

hi,
das ist eigentlich nicht so schwer, und mare_crisium hat das hier https://www.roboternetz.de/phpBB2/viewtopic.php?t=33739&start=110 doch eigentlich toll erklärt.
gibt natürlich noch 1000 andere quellen, wo das erklärt wird.
mfg jeffrey

[robodriver]

Okay, der Lösungsansatz ist in der Tat etwas anders als meiner.

Dann sollte man einen Zusatz hinzu nehmen:

Der Controller der das ganze ausrechnet, hat keinen Timer mehr frei der Zeiten stoppen kann.
Somit ist keine Berechnung der Geschwindigkeit möglich (und nach meinem Lösungsweg auch nicht erforderlich)

Also: Lautet die Aufgabe nun die Lösung zu finden ohne Geschwindigkeiten aus zu rechnen oder irgendwelche Zeiten zu stoppen ;)

[shakespear]

Aus den Drehzahlen der Räder bzw. aus deren Differenzen kann ich mir den Radius/Mittelpunkt ausrechnen, um den sich der Robo dreht, und dann rechne ich mir den Umfang des Kreises bis zum äußeren Rad aus bzw. dividiere durch den Radumfang und Inkremente/U und erhalte den Winkel pro Signal und rechne dann nur noch mit y=r*sin(alpha) und x = r*cos(alpha) die neue RELATIVE Position aus.

Funktioniert auch, wenn sich das eine Rad vorwärts, das andere rückwärts dreht.

Dann können sich die Räder drehen wie sie wollen. Hab grad keine Zeit, das zu spezifizieren, aber so funzt es. wenn du die relativwinkel zamzählst, dann weißt du auch wie das Ding grad steht, und kannst jeweils die RELATIVkoordinaten in die absoluten umrechnen.

WÄRE meine Lösung.

[robodriver]

Gut okay.

Das ist EINE Lösung. Aber eine recht ungenaue.
Dies war auch mein erster Lösungsansatz.
Aber das ist zu ungenau.

Ihr realisiert die Aufgabe glaub ich nicht so ganz.

Es sind 255 Incremente PRO Radumdrehung.
Das steckt noch ein kleiner Kniff drinn.

Nach deiner Rechnung shakespear, könnte man folgendes phänomän NICHT beachten und würde somit auf dauer enorm große Abweichungen erhalten:

Der Robter fährt los. Aus irgendwelchen Gründen dreht das rechte Rad früher los als das linke. Dadurch macht er anfangs einen kleine kurve nach links. Kurz nachdem sich beide Räder dann drehen, kommt das rechte Rad etwas ins stocken. Daraus ergibt sich dann wiederum eine kleine rechtskurve.
So und nun werden die Incremente gemessen: Beide Encoder sind nahezu gleich. Nach deiner Formel würde der nun herauskommen, das der Bot einfach nur in Richtung y gefahren ist.
In Wirklichkeit hat er aber auch noch einen Schwenk nach x gemacht.

Somit ist er in y noch gar nicht so weit vorne wie berechnet und in x auch woanders als berechnet.

Desshalb fehlt bei deiner Lösung auch noch ein paar Komponenten:
- Bei welchem Ereigniss soll die Rechnung durchgeführt werden?
- Und wie oft, in welchen Abständen, wovon abhängig?
Denn hiervon hängt die Genauigkeit des ganzen ab. Das ist also mit das wichtigste Kriterium ;)

[jeffrey]

hi,
du kannst doch einfach die ganze sache integrieren, dann werden aus der geschwindigkeit weg, bzw. winkel. die zeit ist dann nicht wichtig.
abtsten würde ich immmer, sobald an einem rad eine flanke auftritt,beim anderen rad schreibst du den alten wert rein. jetzt kennst du zu jedem zeitpunkt die strecke, die jedes rad gefahen ist, und kannst dir da draus die position berechnen.
mfg jeffrey

[robodriver]

Hi Jeffrey:

Die Frage war nach einem Lösungsweg und keinen Thoeretischen Ansatz.

Deine Aussage ist mir auch nicht ganz klar.
"die ganze Sache integrieren" Was soll in was intergriert werden?

"beim anderen rad schreibst du den alten wert rein"
Welchen Wert? Und wo rein schreiben? Den Zähler verändern?

Bitte zeige die Lösung doch mal etwas genauer auf.

[robodriver]

Okay, also das ganze hat jetzt hier nicht so ganz geklappt wie ich das gern gehabt hätte.

Naja, aber vielleicht können wir das kleine "quizz" einfach zu einer Diskussion umlenken.

Worauf ich hinaus wollte war folgendes:
Wir haben eine Auflösund von 255 Incrementen auf 22cm.
Also ist ein Ein Icrement = 0,86mm

Da wir beim Messen immer nur ganze Incremente erfassen können, haben wir pro Messung eine Messtoleranz von 0,86mm.

Wenn man also einfach sagt, man rechnet alle 1cm die neuen Koordinaten aus, dann hat man unter umständen auf einem Meter einen Messfehler von 8,6 cm.
Das ist schon ziemlich viel.
Und wird immer mehr, desto öfter man eine Koordinatenberechnung durchführt.

Wenn man eine Koordinatenberechnung hingegen nur alle 50cm durchführt hat man aus einem Meter nur noch einen Messfehler von 1,72mm.

Wenn man allerdings so selten Berechnet, dann hat man ein anderes großes problem:
Wenn der Roboter zwischen Messung A und B eine S-Kurve fährt, dann haben beide Encoder (im Idealfall) Exakt die gleichen Incremente. Also Würde man laut der Formel herausbekommen, das sich der Bot z.B. nur in Richtung X bewegt hat.
In wirklichkeit hat er sich aber weniger in X bewegt und dafür noch etwas in Y, was für den Bot dann eben unbemerkt bleibt und ebenfalls zu großen Abweichungen führen kann.

Das war die ganze Thematik auf die ich hinaus wollte.

So, mal sehen ob zu der Problematik noch jemand einen Einwurf hat wie man das ganze besser / genauer machen kann.