entweder mathematisch indem du ne Funktion bildest
oder per lookup table
Moin.
Mal ein kleines mathematisches bzw. geometrisches Problem.
Von einem Touch-LCD werden die X/Y-Positionen über 2 ADC-Kanäle eingelesen.
Bisher hab ich es bei Tasten immer so gemacht, dass ich auf den Mittelpunkt des Tastenrands gedrückt hab und die jeweilige Position mit dem ADC-Wert bestimmt hab. Also der linke Rand einer Taste liegt z.B. auf 100, der rechte auf 200; oben auf 400, unten auf 500.
Damit weiss ich, dass die Taste gedrückt ist, wenn die Bedingung
((x >= 100) && (x <= 200)) || ((y >= 400) && (y <= 500)) zutrifft.
Ich möchte das Ganze jetzt so umbauen, dass ich nicht mehr bei jeder Taste die ADC-Werte "ausprobieren" muss, sondern dass ich die Position von der jeweiligen GetPos-Funktion gleich als Pixelwert bekomme.
Und da kommt schon das Problem: Fahr ich z.B. auf einer waagrechten Linie von links nach rechts, sollte der y-Wert ja gleich bleiben... tut er aber nicht.
Ich hab hier mal die ADC-Werte der 4 Eckpunkte (X / Y):
Position: X_ADC / Y_ADC (= X_Pixel / Y_Pixel)
Oben links: 101 / 145 (= 0, 0)
Oben rechts: 867 / 150 (= 127, 0)
Unten links: 102 / 759 (= 0, 63)
Unten rechts: 848 / 802 (= 127, 63)
Die Y-Werte ganz oben unterscheiden sich nur um 5 "Punkte", die ganz unten dafür schon um 43.
Wär die Abweichung immer die gleiche oder nur bei einer Achse, wäre es eigentlich kein Problem. Nur dass eben die Abweichung mit der Position selber "abweicht" macht mir irgendwie nen Knoten ins Rechenhirn...
Wie kann ich das ganze so begradigen, dass ich die erwarteten Pixelwerte krieg?
mfG
#ifndef MfG
#define MfG
entweder mathematisch indem du ne Funktion bildest
oder per lookup table
Vor den Erfolg haben die Götter den Schweiß gesetzt
Im Prinzip hat Vitis Recht.
Aber wie wäre es, wenn Du von Deinem Touch auch die 2.Leitung abfragst?
Es funktioniert ja so, dass Du auf eine Ebene eine Spannung anlegst, und dann auf der 2.Ebene eine Seite/Leitung abfragst. Da liegt aber noch ne 2. rum. Probiers mal aus, dann hast Du nur ein "halbschiefes" Koordinatensystem.
Jaecko,
leider ist die Aufgabe nur mit einer Iteration zu lösen (siehe angehängte pdf-Datei). Ich hab's mal mit Deinen Werten durchgespielt: Für den Punkt in der Mitte des schiefen Vierecks brauche ich 4 Iterationen um die Koordinaten im Zielrechteck mit einer Genauigkeit besser als 10^-4 zu berechnen.
Die schlechte Nachricht ist also, dass Du iterieren musst, die gute, dass es schnell geht. Erinnert mich irgendwie an meinen jüngsten Zahnarztbesuch... .
Ciao,
mare_crisium
Edit: Anhang gelöscht wg. Upload-Quota.
@mare_crisium: Deine mathem. Herleitung finde ich schlüssig. Wobei ich mich frage, ob Dir das aus dem FF kam oder Du ne ganze Weile überlegen musstest.
Hattest Du ein solches Problem im Studium?
Thxle schon mal.
Sieht ja soweit nicht schlecht aus. Werd mir das ganze aber erst am Wochenende so richtig anschauen + verstehen können... und dann überlegen, wie ich das ganze AVR-gerecht verpack...
Vektorrechnung ist bei mir doch schon etwas länger her.
#ifndef MfG
#define MfG
@thewulf00,
nee, das hat mich auch einen Abend und einen Morgen gekostet, bis ich raus hatte, wie's geht. Eine besonders wichtige Quelle der mathematischen Eingebung war die morgentliche Dusche .
@Jaecko,
wenn ich mein Modell in der Tabellenkalkulation angucke, dann kann ich Dir für die Umsetzung auf den AVR raten, die Kalibrierung folgendermassen durchzuführen:
1. Die Vektoren der vier Eckpunkte messen.
2. Den Vektor zum Mittelpunkt des schiefen Vierecks berechnen (ist einfach nur der Mittelwert aus den vier Eckpunkt-Vektoren)
3. Den Mittelpunkt-Vektor von den vier Eckpunkt-Vektoren abziehen und die Auswertung mit diesen "verkürzten" Vektoren durchführen. Dazu musst Du dann auch von allen gemessenen "Touch-Vektoren" den Mittelpunkt-Vektor abziehen.
Das hat den Vorteil, dass die maximal auftretenden Zahlenwerte so klein wie möglich gehalten werden. Spart Bytes und Rechenzeit - bzw. wie es früher bei "Dr. Dobb's Journal of Computer Calisthenics and Orthodontia" hiess: "Running Light, without Overbyte" .
Sag' mal, ob's klappt.
mare_crisium
Also ich habs mir jetzt jeden Tag angeschaut.
Nur irgendwie... Mathe war noch nie meine Stärke. Wärs ein Blechviereck, könnt ichs mit entsprechenden Hammerschlägen schon so hinbiegen... nur hinrechnen *g*...
Das Grundproblem ist schon mal: Wie bring ich dem AVR Vektoren bei? Ich weiss, dass die Antwort darauf wohl trivial sein wird; also das typische Problem: Die Frage ist so leicht, dass man nicht draufkommt, weil man einfach zu kompliziert denkt.
(Und Matlab auf nem AVR zum laufen zu kriegen... naaaja...)
#ifndef MfG
#define MfG
Jaecko,
ich nehme gerade meine Grippe... Sobald ich ohne zu Husten ein vollständiges Posting schreiben kann, melde ich mich wieder. Wir kriegen das schon noch hin.
Ciao,
mare_crisium
P.S.:
Vorab im Anhang die Tabellenkalkulation mit dem Algorithmus.
Edit: Anhang gelöscht wg. Upload-Quota
Gute Besserung. Nimm dir die Zeit, eilt nicht.
Liegen ja genügend Projekte rum, wo noch was zu tun ist *g*
(u.a. mal nen vernünftigen FAT-Treiber zum Laufen kriegen...)
Aber die Excel hilft schon mal ein Stück weiter. Thx.
#ifndef MfG
#define MfG
Lesezeichen