Problem med teckenbaserade linjer (Matematisk utmaning)

[Icecap]

Jag har tidigare löst ett sådan problem, det var ganska enkelt. Jag hade en start-XY koordinat och en slut-koordinat. Sedan valde jag vilken av X och Y-skillnaden som var störst och gjorde en for-to-next på den.

Resten var bara att stega ett steg och räkna ut var den andra koordinat skulle vara för den X eller Y jag stegade.

Och att dela upp det i vilken delruta samt delruta-koordinater är ju hur enkelt som helst.

[ToPNoTCH]

OK.

Så i varje "tecken-box" så är det enbart *1* punkt som ska aktiveras ?
Inte en hel rad (så som det lät från början).

Jo det gjorde det

så har jag skapat 18 tecken med en(1) vit bilpunkt

Observera att när jag skriver streck så menar jag egentligen en rad med punkter, dom är ju inte sammanhängande givet hur jag tidigare beskrev att de definerats.

Och punkten sitter alltid i mitten i tecken-boxen, sett ur ett vänster/höger perspektiv ?
Men på olika höjd i mitten ?

Helt rätt uppfattat.

Om nu boxen är 11 punkter hög, så blir det väl bara 11 olika "tecken" ?

Nej "boxen" är 18 pixel hög,12 pixel bred och utgör ett tecken.
Den totala ytan består av 11 tecken (eller boxar om du så vill) på höjden.

> Så här representeras alltså 0 grader.

Just *0* grader var väl kanske det sämsta du kunde välja för ett exempel...
Hur ska t.ex 30 grader se ut ?? Ska vinkeln ta hänsyn till att det är olika
proportioner på boxen ? D.v.s att 45 grader ska inte bara vara en rak trappa
snett uppåt ? Det ger ju mindre än 45 grader efter de är bredare än höga (även
om det inte ser ut så på din bild !?).

0 grader var det enda jag på rak arm kunde med säkerhet rita i MS paint
Jo jag vill att den tar hänsyn till proportionerna. Den virtuella horizonten är ett "flyghjälpmedel" för att avgöra roll och
då vill man ju gärna att den är linjär.

Jag har kommit så långt nu att jag kan beräkna höjden i pixlar på respektive tecken kolumn.

Då SIN funktionen tydligen vill ha radianer så blir formeln.
y-pixel=SIN((vinkel*PI)/180) * (kolumn*12)

Sedan bode det bara vara att dela y-pixel med 18 och använda modulus för vilket tecken.

Det här tar ju bara hand om delen till höger om centrum punkten, men det till vänster är ju spegelvänt och borde ju inte vara så svårt att lösa.

Är jag på rätt spår ?

[labmaster]

Är det inte så enkelt som att jag har en liksidig triangel där vinkel och ena kateten(x) är känd...

ToPNoTCH, utan att fördjupa mig i detaljerna så känns det nog enklast att du använder räta linjens ekvation. Y = kX + M. Ty den tar mindre tid än att använda cosinus och sinus.

By the way, Det framgår inte någonstans i tråden hur din horisont finns representerad innan den skall visas i displayen med hjälp av teckenpunkterna.

[ToPNoTCH]

Du kan nog ha rätt.
Har rätt mycket CPU tid över förvisso men kan man göra något snabbare så bör man nog.

Jag tyckte det vart krångligt nog att beskriva utan att blanda in värdet som representeras

Jag tar OUT_X från en LIS302DL Accelerometer.
Om jag minns rätt så är det 8-bitars värde och två komplement.
Tror det är så att 0-50 representerar 0-90 grader medsols och 254-200 representerar 0-90 grader motsols.

Egentligen så låg upplösning så man kan lösa det med en uppslagstabell nästan, om man nu vill att det skall gå ännu fortare.
Skulle nog ta 200 bytes bara om man använder dom klokt.

[bearing]

Håller med labmaster. Det ToPNoTCH ska göra är ju att helt enkelt skala om värdet som kommer från accelerometern till skärmen.

Accelerometern ger ju två koordinater i en cirkel. Kvoten av koordinaterna är lutningskoefficienten k (eller 1/k, beroende på vilken koordinat som läggs i täljaren).

Sedan är det ju bara att räkna ut y genom att multiplicera x-koordinaten för varje prick med k, sedan dividera med 12 för att få koordinaten för tecknet, sedan ta resten av 12 för att få vilket tecken som ska användas.

[labmaster]

De två inläggen precis innan detta ger två budskap om vad som kommer ur accelerometern. Eftersom jag inte orkar kolla i databladet ställer jag motfrågor i syfte att förhoppningsvis kunna hjälpa till att få fram en möjlig lösning.

Först och främst om:
a) accelerometern som bearing säger levererar två koordinater; (x0,y0) (x1,y1) blir k = (y1 - y0) / (x1 - x0)

b) accelerometern levererar lutningsvinkel (v) som ToPnoTCH säger så blir k = tan(v).

Om det är b som gäller blir motfrågan: Kan lutningsvinkeln (v) anta vilket värde som helst mellan 0 och 50, det vill säga är det flyttal eller är det heltal mellan 0 och 50 det handlar om som motsvarar 0 - 90 grader?

[ToPNoTCH]

Det låter nog lite konstigt kanske, men databladet är inte så tydligt vad det gäller utdata.
"X-axis outdata" = lsb 0-7 msb=not used

Men efter lite vickande har jag kommit fram till vad jag skrev tidigare.

v kan anta 1-50 heltal vilket motsvarar 1-90 grader medurs lutning.
eller
255-205 heltal vilket motsvarar 1-90 grader moturs lutning.

0 motsvarar plant läge.

Det är alltså ett 8-bitars värde vi talar om.

Det låter lite orimligt att man nyttjar 100 värden för att representera 180 grader.
Det hade varit mer logiskt att nyttja halva utdata-området (127 värden) för halva rotationen.

Det är inte omöjligt att det är så, för jag kan inte vända skrotet ända upp till 90 grader då det sitter på fyra olika breakout kort där två sitter på breadboardet och de två andra hänger i massa sladdar på sidan.

Kort sagt en koppling som till och med Tekko skulle bli impad av

I så fall är det 0-63 medurs och 255-192 moturs.

Jag har sent om sider lyckats lösa det nu med en uppslagstabell som jag bygger upp vid boot.
Det gick 712 bytes men det är till ett gott syfte trots allt.

Jag använde 3 msb för att lagra position på tecknet i y-led och 5 lsb för vilket tecken som skall ritas.

Genom genom att addera position och tecken på högersidan och subtrahera på vänstersidan så fick jag det att lira.

Jag vet inte om lösningen är optimal, men det tar under en sek att skapa uppslagstabellen vid boot och huvudloopen blev väldigt snabb utan avancerade beräkningar.

Horizonten blev lite skakig då accelerometern inte har några trixiga filter ombord.
Brukar vilja läsa ett par värden och ta snittvärdet, men har jag inte fixat ännu då det blev lite jobbigt med den knepiga utdatan.

Ett kalmanfilter vore mums kanske

[labmaster]

Många vägar bär till Rom. Det du har gjort är att nyttja räta linjens ekvation och lagrat alla värden i en tabell som ekvationen ger för en given vinkel (va) som kommer från accelerometern, det vill säga för ett givet värde på k i Y = kX+M.

Om du får ont om plats i minnet och behöver banta ned tabellen kan du kanske skapa en tabell för k till varje heltal (va) som kommer från accelerometern. Värdena i varje tabellcell räknar du fram med excel som k = tan(90/va) för 0 < va < 51 och för 204 < va < 256 använder du ekvationen Y = -kX + M. Du behöver naturligtvis också klura ut hur du lagrar k som ett 16-bitars heltal om du behöver banta tabellen till 100 byte.

[bearing]

Med två koordinater menade jag egentligen en koordinat, alltså ett x- och ett y-värde.

Förra inlägget skrev jag utan att läsa något om sensorn, men efter att ha läst så är jag övertygad om att jag har rätt, d.v.s. att den här 3-axliga accelerometern ger en x,y,z-vector precis som alla andra.

Utdata läses från de tre registrerna OUT_X, OUT_Y, OUT_Z, och är formaterade som en vanlig signed byte.

Ur http://www.st.com/internet/com/TECHNICA ... 098549.pdf

9.3 Understanding acceleration data
The measured acceleration data are sent into OUTX, OUTY and OUTZ registers. The
acceleration values are expressed as a 2’s complement number. When the full-scale is set
to 2g, each LSB corresponds to 18mg.
The table below provides few basic examples of the data that will be read in the data
registers when the device is subject to a given acceleration. The values listed in the table
are given under the hypothesis of perfect device calibration (i.e no offset, no gain error, ....)
and rounded to the closest integer.
Table 5. Output Data Registers content vs. Acceleration

Kod: Markera allt

Acceleration Values
         FS bit = 0    FS bit = 1
0g           00h        00h
350mg        14h        05h
1g           38h        0Eh
2g           6Fh        1Ch
-350mg       ECh        FBh
-1g          C8h        F2h
-2g          91h        E4h

("FS" väljer mellan +-2g och +-8g mätområde. Egentligen är mätområdet lite högre, eftersom att 0x6F = 111, d.v.s 127 motsvarar ca 2,3g)


Om accelerometern hålls helt horisontellt kommer OUT_Y = 0x38, och OUT_X = 0. I det läget ska horisonten vara helt horisontell, dvs k = 0, vilket betyder att k beräknas k = OUT_X / OUT_Y.

Antar att du kommer använda heltalsberäkningar, d.v.s det går inte att beräkna k separat, utan kvoten får slås ihop med de andra beräkningarna på ett sätt så att inga signifikanta siffror trunkeras bort.

k är ju detsamma som tan(fi) eftersom OUT-värden är sin resp. cos för vinkeln. (tan(fi) = sin(fi)/cos(fi).)
Så du fick ju en stor del av lösningen redan i ett av de tidiga inläggen

Om k är kolumn, r är rad, t tecken, och fi vinkeln från horisonten (dvs 0 horisontellt, pi/2 vertikalt) borde det bli något i stil med:

r = floor(tan(fi)*(k-9))+9
t = floor(tan(fi)*(k-9)-floor(tan(fi)*(k-9)))*9 + 9

[Swech]

Alla är förvirrade över den mystiska punktskärmen.
Bortser man från det så är det ju en simpel bresenham linjealgoritm som du skall köra

Räkna ut din linje precis som på vilken skärm som helst och därefter dela fram med 12
vilket tecken som skall användas

Swech