Lennuki instrumendid arvutiekraanile

[jakim]

Vs: Lennuki instrumendid arvutiekraanile

Selles on sul õigus, et encoder C reziimi kõrgusejaoks. Felchiga oleme neid asju katsetanud ja laboris radariga veits kiiritanud ka. Aga minimaalseks jaotuseks tolle encoderi puhul oli 50 ft. Kui abi vaja siis projekti arendamisel saab Lennukolledži laboris ka mõõtmisi teha. Millisele lennukile seadet paigaldada mõtled?

[felch]

Vs: Lennuki instrumendid arvutiekraanile

Mina olen seni ainult PICutanud Enne seda ka 51 tuumaga prosed. PIC18F4550 tahtsin just oma töö jaoks osta ja katsetama hakata. ARMiga pole kogemusi aga ta on kindlasti hea valik. Kui kasutada Texase MSP430-t, saaks neilt ehk hea disaini eest auhinna Mul on vastav arenduskeskkond olemas aga seni pole kogemusi. Samas...progeda võib ju keegi asjalikum kuju. Tulekski selline foorumirahva ühine projekt. Ja siis koos kukume...
Jakimiga kasutasime PIC18F452-e. Tunduvalt mugavam kui madalamad seeriad, sarnaneb omadustelt AVRi ja Intel 8051-ga. RAMi ca. 1,5k, flashi 8k (oli vist nii). Asmi jaoks piisavalt. Sellega on isegi videot genereeritud (aga asmis!).
Kas sa kokkutulekule laekud? Äkki saaks seal asja ühiselt arutada ja projekti spec'i kokku panna?

[lendurhenry]

Vs: Lennuki instrumendid arvutiekraanile

LCD-dest selline tähelepanek, et vanad head ilma taustvalgustuseta displayd on selgemad ja päikesevalguse käes nähtavad. Vaadake kasvõi näiteks päikesepatareidel töötavaid kalkulaatoreid. See halb vaadeldavus on tulnud seoses taustvalgustusega ja halltoonide või värvide kasutamisega. Seal on ilmselt tehnoloogia pisut teine. Mobiili display on lennukis üsna kehva kontrastiga ja päikese käes pole ka taustvalgustusest tolku. Seega tunne ütleb, et pealtvalgustusega, kahetoonilised (must ja valge) LCD-d peaks olema paremad.
Inffi koguneb sõltuvalt logi tihedusest. Reeglina mahuga ei priisata ja see on megabaitides.

Kas ma saan õieti aru, et te ehitasite põlve otsas transponderi valmis? Ise-enesest midagi keerulist seal ju ei ole. Kas see 50jalga per jaotis on kogu skaala ulatuses? Sellisel juhul on anduri näit kuidagi ebalineaarseks aetud? Vastasel korral peaks 10km kõrgusel jaotise suuruseks olema 144 jalga. Muidu 51200 jalga (üle 15km) peaks täiesti piisav kõrgus olema jah.

Pole veel otsustanud, kas prototüüp panna Blaniku või Jantari peale. Projektist on huvitatud paar purilendurit Ridali lennuklubist veel, eks me koos otsustame. Võimalik, et kui paberil asi valmis ja kalkulatsioonid tunduvad vett pidavad, siis teeb kohe mitu eksemplari valmis.

Vaatasin siis Texase prosesid ja ära sa ütle. MSP430x44x on üsna arvestatav tegija:
60kB Flash, 2kB RAM, 8x12bit ADC ja mingi LCD draiver

Muidu ASM-ga on mul kogemusi Juku ajastust. Siis sai isegi masinkoodi kirjutatud. Aga olen seda projekti juba küllaldaselt analüüsinud, et mõista kõrgema keele vajadust selle ülesande lahendamiseks. Liiga palju on seal vektorarvutusi. Kardan, et jõudluse tagamiseks on lausa vajalik süsteem erinevateks mooduliteks jaotada. Üks tsentraalne moodul, mis paneb kõik parameetrid kokku, teostab logimist ja bluetooth-le edastust. Võimalik, et inimliidestus (LCD ja keyboard) on kah selle kanda, kuid vajadusel võib selle ülesande eraldi lahendada. Just selleks eraldi, et edaspidi oleks võimalik erinevaid inimliidestus variante välja töötada. GPS on niikuinii omaette tükk, mida ise pole mõtet ehitada. Põhiline et sealt võimalikult tihedalt lugemit saaks. Siis eraldi nihkemoodul, mis tegeleb kiirenduste ja nurk-kiiruste jälgimisega, ning nende abil viimase mingi kindla aja sees toimunud nihke kalkuleerimisega. Seda kasutatakse siis GPS viivituse kompenseerimiseks. Eraldi kompassi moodul, mida saab suuna kalibreerimiseks kasutada. Siis pneumaatika moodul, kus on andurid kiiruse, libisemise ja kohtumisnurga määramiseks ning üldine rõhuandur nende näitude kalibreerimiseks ja GPS kõrguse vigade silumiseks. Ma arvan, et igal moodulil on pisiavalt keerukas ülesanne, et ühele mikroprotsessorile tööd pakkuda. Süsteem võiks ka tööle jääda siis, kui üks moodulitest ära langeb. Siis on võimalik mingi aja teiste mõõtmistulemustega selle näite asendada.

Kokkutulekule ilmselt ei laeku. Ei tunne ennast veel elektroonikuna. Rohkem kui 15a tagasi sai raadio-ringis käidud, kuid vahepeal pole kolbi eriti käes hoidnud. Nädalavahetused kuluvad praeguste ilusate ilmadega reeglina lendamisele.
Henry

[lendurhenry]

Vs: Lennuki instrumendid arvutiekraanile

Tegin algatuseks siis mingi skeemi moodulite arhitektuurist. Iga moodul võiks siis olla omaette tükk, mida saab ühendada ja vahetada. Lisaks siis inimliidesed, mida peaks saama järjestikku ühendada niipalju, kui mahub. Kesksüsteem saadab siis igale poole ühte ja samat joru. Kirjutab logisse, saadab arvutisse või siis inimliidesele. Pakett peab sisaldama inffi asukoha, orientatsiooni, kiiruste, pöörlemiskiiruste, ülekoormuste, kohtumisnurkade, tuulesuuna jms. kohta. Kesksüsteemil peaks olema varulahendused, kuidas kalkuleerida sisendparameeteid, kui mõni moodul rivist välja langeb. Näiteks saab kompassi mõnda aega GPS ja IMU abil asendada jne. Mida rohkem mooduleid taga, seda täpsem on tulemus. HIU rida oleks siis kuvada tulemusi vastavalt klaviatuurilt valitud ja tüübi poolt võimaldatavaid näitusid. Kas variomeetrit, altimeetrit, avio-horisonti, navigatsiooniinfot jne. See moodul tegeleb siis graafika joonistamisega. Kui neid on mitu, siis saab mitu LCD-d erinevasse kohta armatuuri paigutada ja neile erinevad instrumendid valida. Eks hakkame lihtsamatest LCD-dest ja ülesannetest pihta.

Anduritest moodulites:
IMU - 6x14bit 5V + (3x10bit 5V) + 3x10bit 3V (güro anduritele pisut täpsemad näidud koos null asenditega, temperatuuri mõõt võib olla ebatäpsem või üldse ära jääda, kiirendusandurite jaoks piisab 10bit-st)
ASU - 4x10bit 5V (üks absoluutrõhu andur ja kolm diferentsiaalrõhu andurit)
CMU - 3x10bit 5V (pisut segane asi, väljundeid on kividel palju)
APS - esialgu ainult mõned lülitid neutraalasendi tuvastamiseks.

Et siis ootaks ettepanekuid. Kuidas need moodulid omavahel suhtlema peaks ja milliseid mikrokontrollereid rakendada.
Henry

[peepk]

Vs: Lennuki instrumendid arvutiekraanile

olen asjast huvitatud natuke teise kandi pealt. nimelt lennutan rc helikoptereid ja huvitavad kopteri stabilisaatorid ja autopiloodid. on olemas kommertsasju, nt http://www.helicommand.com või http://http://mikado.e-vendo.de/imgm..._news_2006.pdf ja ka open source http://autopilot.sourceforge.net. mudeleid ja suuri lennuvahendeid ühendavad samad sensorid (gps, imu jne) ja ka töötlusalgoritmid. kui sensorid saab piisavalt väikeseks, siis leiab projektile kindlasti huvilisi ka mudelite maailmast.

olen küll it haridusega ja olen kunagi mikrokontrolleriga isegi led-e vilgutanud aga skeemide jootmine ja koodi kirjutamine on jäänud valgusaastate taha.

PeepK

[lendurhenry]

Vs: Lennuki instrumendid arvutiekraanile

Põhimõtteliselt saaks ka purilennukit panna autopiloodiga lendama. Sellisel juhul peab sellel olema kaks reziimi - ülelend ja spiraal. Olen tihti lennukis ette kujutanud, mis tunne oleks tõusta termikas, kui autopiloot tsentreerimise töö ära teeks. Sina ainult sekkud pilvepiirini jõudes või teiste lennukite olemasolul ja juhid lennuki lahkumiskursile ning lased autopiloodil ülelennuks juhtimise üle võtta. Autopiloot hoiab siis vastavalt vajumisele kiirust ja alustab õigel hetkel spiraali. Päris huvitav oleks võistelda, kumb lendaks marsruudi lendu paremini, kas kogenud purilendur klassikalisel purilennukil või autopiloot sellise lennukompuutriga.

Põhimõtteliselt saaks autopiloodi sellele seadmele väljundisse pookida jadamiisi HIU moodulitega või mudelite puhul üldse nende asemele.

Veel mõtlesin sellise asja peale, et kuidas ehitada raadiosaatjat, mis mingi aja tagant selle paketi ka kuhugi keskusesse saadaks. Andme edastuskiirus ei ole eriti oluline, põhiline et see süsteem võimaldaks mitmel lennukil keskusega suhelda. Peab siis ilmselt teadma kaugust keskusest (mida saab GPS põhjal lihtsalt arvutada) ja siis saatma paketi kindlatel hetkedel, et ta teiste lennukite omadega ühel ajal kohale ei jõuaks. Lennujuhil oleks ilma transponderitagi hea ülevaade, kus keegi asub ja kuidas edeneb. Ka see süsteem kuluks mudellistidele marjaks ära. Kui infot pisut tihedamini saata, siis võid istuda arvuti taha ja juhtida lennumasinat, mis silmapiirilt väljas.

Järgmine samm oleks juba info tagasi saatmine lennukisse, et piloodid oleksid teadlikud, kui teine purilennuk ohtlikult lähedal. See on üks suuremaid ohte, mistõttu hõigatakse oma asukoht ja kõrgus võimalikult sagedasti raadiosaatjasse. Eriti kui lähenetakse pilvele. Raudne reegel on ka see, et kui lähened tõusule, kus keegi juba on, siis pead sellest teatama. Ta võib küll olla kõrgemal, kuid väga piiripealset spiraali tehes võib pöörisesse kukkuda ja sajab sulle kaela. Kui ta on aga teadlik, et keegi tema all, siis ta lendab väikese varuga. Lisaks on prilennunduses teiste edenemine oluline teada veel selleks, et tõuse leida. Tihti jälgitakse eemal olevat purjekat visuaalselt ja see annab kõige parema pildi, mis õhk seal teeb. Saad ise tema vigadest hoiduda või tema poolt leitut ära kasutada.

Täiendasin skeemi pisut. Uus versioon siin. Et siis kesksüsteem täpsustab GPS andmeid ja lisab sellele lennuki asendi parameetrid. Edasi edastatakse inff saatja moodulisse. See oskab siis inffi edastada kindlale objektile, mille koordinaate ta teab ja oskab selle kaugust arvutada. Kui vastuvõtja saab inffi teiste lennukite kohta, siis edastatakse see järgnevatele moodulitele. Viimaseks mooduliks on andmete eksportija, mis oskab mälukaartile logida või läbi mingi liidese arvutile väljastada. Neid mooduleid võib siis mistahes järjekorras kokku panna või vahelt ära jätta. Näiteks peaks asi töötama ka mingilmääral otse GPS pealt. See on see jadamiisi ühenduse võlu, et iga moodul saab inffi juurde lisada.
Henry

[felch]

Vs: Lennuki instrumendid arvutiekraanile

Seoke huvitav asi: http://www.global.yamaha.com/news/2006/20060726.html
TEa's kas ta ka midagi väärt on?

[lendurhenry]

Vs: Lennuki instrumendid arvutiekraanile

Tõesti huvitav. Maksab Jaapanis siis ainult 100EEK kanti. Meil hakkab maksma muidugi 10x rohkem. Selles suhtes hea, et kõik on kivis olemas ja väljund juba digis (I2c). Tavalise anduri puhul pead päris palju juurde ehitama, et sealt tulemust saada. Selle eelmine kaheteljeline versioon on mul mobiilis sees (5140). Seal vihjatakse kah, et GPS-ga mobiilid muutuvad populaarseks. Vihjatakse ka kiirendusanduritega mobiilidele, mis on Nokial ammu olemas - 3220. Sellel on korpuses led-ide rida ja tänu kiirendusandurile on telefoni küljelt-küljele liigutades võimalik õhku kirjutada. Mängud käivad tal kah muidugi telefoni liigutades, mitte nuppu sügades. Ainuke asi, et see kiirendusandur seal on kahe teljeline. Seega on varsti oodata mobiiltelefoni, millel pea kõik sees, millest me siin unistame. Siis võtad kätte ja kirjutad ainult Java rakenduse, ning tulemus pea sama. Tegelikult peab sellega paar aastat ootama, see andur tuleb müüki alles oktoobris, mobiili aretamiseks kulub aga hea paar aastat aega. Umbes niikaua ootasin 5140 GPS toimima saamist peale esimesi teateid Nokialt.

GPS-i mobiilis kasutan üsna tihti kusjures. Abix asi. Kahju, et GPS kompassiga samaaegselt ei toimi.
Henry

[lendurhenry]

Vs: Lennuki instrumendid arvutiekraanile

Muidex, mudelite jaoks on ka sparkfun-l board olemas, kus on juba GPS, PIC mikroprotsessor, 2 teljeline güro, 2 teljeline kiirendusandur ja 2 teljeline kompass. Lisaks sisendid ja väljundid servodele. Nagu ma aru saan, raadio vastuvõtjat tal ei ole, selleks on need sisendid. Asi siis mõeldud autopiloodiks mudel-lennukitele, specci on päris huvitav lugeda.

Nüüd olen asja pisut edasi analüüsinud ja olen probleemi ees. Nimelt NMEA protokoll näeb ette, et tihedamini, kui kord sekundis ei peagi inffi saatma. Standardi järgi ettenähtud kiirus on 4800bitt/s ja sellest jätkub nibib-nabin, et see inff sekundi jooksul ära saata. See tähendab, et desifreerimise ajaks on inff juba umbes 1sec vana. Tegelikult vahet ei ole, kui tihedalt see infovahetus käib, võib ka 5Hz perioodiga, kuid probleem on selles, et pole teada, kui vana see inff täpselt on. Kas see pärineb eelmise tsükkli algusest või lõpust. NMEA-s on küll kella-aeg, kuid see on sekundilise täpsusega. Kiirus antakse eraldi ja pole üldse teada, kas see on eelmise perioodi keskmine kiirus või mingi hetke kiirus...

Minul on igal juhul nende protokollide uurimisest juhtmed koos.
Henry

[andreie]

Vs: Lennuki instrumendid arvutiekraanile

Erinevatel GPS-idel ja erinevatel järjestikportidel ongi erinevad ajastused ja ette välja arvutada neid ei saagi. Pead katse-eksituse meetodile õige välja selgitama. Iseasi, kas leiad sellise kriteeriumi, mille järgi "õiget" ajanihet leida.

NMEA rea kellaajaks tuleb võtta esimese märgi pärast reavahetust sisselugemise aeg. Paned aja kuskile kõrvale ja sel hetkel, kui rida uuesti läbi saab, vaatad, mis hetkel siis rida sisse tuli

[felch]

Vs: Lennuki instrumendid arvutiekraanile

Kas on üldse mõistlik lugeda kiirust GPSi pealt? Kuidas muidu tehakse?

[lendurhenry]

Vs: Lennuki instrumendid arvutiekraanile

Konstantset ajanihet pole võimalik tuletada. Asi selles, et GPS-d töötavad kõik katse-eksitus meetodil. Need võtavad arvesse eelmise koordinaadi, kiiruse ja liikumis-suuna. Paremad kasutavad ka parameetreid kõrverjoonelise liikumise arvessevõtmiseks. Lennunduse puhul saaks ka energiat aevesse võtta (maa suunaline liikumiskiiruse komponent võib tähendada horisontaalse komponendi suurenemist). Kui vahepeal tingimused ei muutu, siis on ainult uue oletatava asukoha kalkuleerimise ja kontrollimise vaev. Kui tead oma asukohta, kella aega ja sattide asukohti, siis saad nendelt tulevat ja segunevat signaali imiteerida ja antennist tulevast maha lahutada. Tekib vaikus, mis kinnitab asukoha õigsust. Sattide mürasignaal on nii ehitatud, et mida rohkem mööda paned, seda tugevam signaal järgi jääb peale lahutamist. Selleks pead 1 mikrosekund (ehk mürapaketi kordumisperioodi jagu) signaali kuulama ja selle perioodi summaarset energiat mõõtma. Nüüd see, mida edasi tehakse, sõltub juba algoritmi kavalusest. Lihtsamal juhul nihutatakse su asukohta paar meetrit sinna-tänna ja vaadatakse, mis signaali tugevusega juhtub. Nii võib sadakond tsükklit kuluda, ennem kui uus asukoht ära täpsustatakse. Seega võib see reaalne koordinaadi leidmise aeg nii 0,1s varieeruda selle sekundi sees, millal eelmise koordinaadi inffi edastatakse.

Just seetõttu kalkuleeritakse GPS seadmetes su kiirus ja liikumissuund eriti täpselt, kuna sellest sõltub koordinaadi leidmise kiirus. Oleks GPS-s kiirendusandurid ja güro andurid, siis läheks uue koodinaadi täpsustamiseks harva lisatsükkleid vaja. Sellisel juhul võiks GPS seadmest sadu kordi sekundis väga täpselt määratud asukohta lugeda. Asukoha määrangu täpsus suureneks selle arvelt, et saad võtta mitme väiksema täpsusega leitud koordinaadi keskmise, kuna nende vahele on vaja nüüd ära paigutada liikumistrajektoor. Just see on see efekt, mida ma üritan antud projeti raames saavutada. Esiteks paraneb täpsus, mis pole primaarne. Teiseks on võimalik igal ajahetkel teada kiiruseid igas suunas. Ja see oli põhieesmärk, et luua variomeeter, mis näitab lennuki koguenergia muutuse asemel õhu tõusukiirust.

Tean siiski GPS-st väga üldist ja palju peab loogiliste järelduste põhjal välja mõtlema. Oletan ka seda, et see kiirus on viimase täpsustustsükkli järgi arvutatud kiirus. St. sisemiselt leitaksegi see koordinaat kümneid kordi sekundis ja iga kord arvutatakse siis kiirus kahe koordinaadi vahelise kauguse ja aja järgi. Võidakse kasutada ka üle-eelmist koordinaati, et leida kõverust ja selle võrra teekonda pikendada. Seega arvatavasti on see koordinaat viimane, mis leitud, ehk üsna eelmise sekundi lõpus. Kiirus on selle perioodi keskmine.

Seega võiks GPS andmeid usaldada küll. Purilenuki jaoks on aga sekund väga pikk aeg. 5Hz oleks küll enneolematu tulemus, mida pneumaatilised seadmed ei võimaldaks, kuid siiski pikk aeg.
Henry

[lendurhenry]

Vs: Lennuki instrumendid arvutiekraanile

Ilmselt kirjutan liiga pikalt ja keegi ei viici lugeda

Esitaks kohe ette abipalve, et äkki keegi aitaks välja valida protsessorid, millega edasi minna. Üritasin seda lootusetult nädalavahetusel ise teha. Ja üldse ootaks kommentaare plaani kohta kaasata süsteemi mitu protsessorit ja jagada nende vahel suurema jõudluse huvides ülesandeid. Vektorarvutus on üsna keerukas, mulle tundub, et üks protsessor seda kogu ulatuses teha ei jäksa. Praeguses visioonis on kalkulatsioonid jaotatud 6 erineva mooduli vahel - GPS, keskprotsessor, IMU, kompass, pneumaatika ja juhtpinnad. IMU ja kompassi võib ju ka kokku võtta. Sama lennuki seadmestiku ja voolikute külge ühendatavate kontrolleritega. Siis võtaks keskprotsessor kolmelt seadmelt andmeid ja kalkuleeriks tulemuse, mille väljastab järgmisele seadmele. Iga järgnev seade ahelas võib järgnevatele edastada oma lisainffi. Umbes sarnaselt on tegelikult tehtud ka standardsed seadmed - purilennuki pardaarvuti lisab GPS NMEA protokolli pneumaatilise kõrguse ja kiiruse info.

Pisut siis veel sellest keerukusest. Vaadake veel skeemi, on arusaadavam. Kõige otsas on alati GPS. See on ka kalkulatsioonide aluseks. Sellele järgnevad moodulid on kõik jadamiisi RS232 liidese abil.
1. Keskprotsessor - Kaks RS232 ühendust + 4 või 2 mingit madalama taseme serjal ühendust. Need ühendused võivad olla ka läbi RF. IMu-st saab ta teada, palju on lennuk pööranud ja nihkunud võrreldes eelmise küsimise korraga. Milline ja millises suunas on hetkel kiirus ning nurkkiirus. Kompassilt, mis sihis on praegu põhja-lõuna suund. Viimane tuleb teisendada horisontaalseks, kuna seda ise-enesest on ta ainult ekvaatoril. Nendest kolemst sisendist täpne, keskmistatud tulemus kokku panna on üsna keerukas ülesanne. Tuleb hoida logi näiteks viimase poole minuti kohta ja palju vektorarvutusi teha. Edasi tuleb paremalt poolt arvesse võtta lennuki polaari mõjutavad tegurid. Tuleb arvutada lennuki takistustegur, mis sõltub kohtumisnurgast, libisemisnurgast, juhtpindade asendist, kaalust ja ülekoormusest ning pneumaatilisest kiirusest. Selle järgi tuleb polaari tabelist võtta kiiruse järgi vajumiskiirus ja need andmed panna edastatavatele parameetritele juurde. Ühesõnaga tegemist on siin ühe prose kohta küllaldaselt.
2. IMU ja CMU. IMU saab analoogsisenditesse kiirendusandurite tulemused ja gürodelt nurk-kiirused. Vastik on siinjuures see, et peab teadma vertikaalsuunda, et maa külgetõmbe jõu komponent kiirendustest maha lahutada. Seega keerukamal juhul peaks need parameetrid keksprotsessori käest saama. Oma töötsükkli alguses kehtinud lennusuund võetakse kõigele aluseks ja sinna lisatakse siis pidevalt vektorarvutustega üliväikeste ajavahemike tagant juurde suuna muutust ja nihet. Kompassi puhul on keerukas see, et neid kivisid on vaja pidevalt ergutada ja kalibreerida, et saada täpset tulemust. Sisendeid on küll oluliselt vähem ja anduri väljundpinge on vastavuses anduri nurgaga magnetvälja suhtes, seda erinevalt güro anduritest, mis näitavad pöörlemiskiirust. Kompass ja IMU tuleks eraldi teha ainult sellepärast, et andureid ei pruugi saada lähestikku paigaldada. IMU tuleks paigaldada võimalikult massikeskme lähedale, mis aga võib paikneda üsnagi rauda sisaldavate metallkonstruktsioonide lähedal. Magnetandurid tuleks võimalikult kaugele viia tavalistest kompassidest ja muudest magnethäiretest.
3. Lennuki tagasiside. Siin on kalkulatsioonid suhteliselt lihtsad, kui mitte polaari arvutusi sisse tuua. Kõrguse järgi tuleb kiirust täpsustada, kuna kõrgemal olev hõre õhurõhk tekitab ka kiiruseanduris samal kiirusel väiksema rõhu. Mehhaanilistes seadmetes pole seda viga kompenseeritud, kuna lennuomadused on sõltuvuses just sellest ebatäpsest näidust. Navigeerimisel peab seda lihtsalt arvestama, et spidomeeter valetab. Edasi on vaja kiirusest ja libisemisandurite näidust arvutada libisemis ja kohtumis- nurgad. Selleks vajalikke parameetreid on väga keerukas kalkulatsioonidega tuletada, seega peaks see GPS abil kalibreeritav olema. Ilmselt isegi mitte valemitena, vaid suhtegraafikutena. Nii peaks ka polaare mõõtma erinevatel tingimustel. Seega kogu keerukus seisneb siin adaptiivsuses. Vabalt võib juhtpindu mõõta pneumaatika kontrolleriga, kuid juhtpindade käändteljed on reeglina seljataga ja pneumaatika torud armatuuri all. Kogu see värk peaks olema projekteeritud iga lennuki jaoks eraldi, seetõttu peaks ta olema ka kesksüsteemist eraldi. Tegelikult oleks üsna hea, kui kogu polaari jälgimine oleks siin, et siis saab muid seadmeid suvalisel hetkel ühelt lennukilt teisele tõsta jättes ainult selle koos oma flash mäluga alles.
4. DTU. Esimene moodul, kuhu keskprotsessor infi edastab on andmete edastusmoodul. See peaks siis olema ühenduses kas keskusega või lähedal asuva teise lennukiga. Sisse tulevad täpselt samasugused paketid teiste kohta, mis enda keskprotsessor edasi saadab. Seega, aeg-ajalt saadab see ka oma info-paketi laiali. Urisin sobivaid ja kättesaadavaid lahendusi ja leidsin ühe kiibi, mida võiks kasutada. Andmeedastus kiirus on täiesti rahuldav, kuid võimsus mitte. Kas õnnestuks väljundit võimendada? Mind paeluks hoopis suundantenni lahendus. Sellest moodulist jookseb läbi ju kogu inff enda asukoha ja suuna kohta. Kui saaks pöördantenni juhtida nii, et see oleks koguaeg keskuse suunas, siis peaks vähemlt saadetav inff kohale jõudma. See antenni juhtimine samm-mootoritega ei tohiks eriti keeruline olla, kuna viimasel ajal maksavad inimest jälgivad USB kaameradki alla tuhande krooni. Samas, see moodul ei ole prioriteetne ja selle torkab vahele alles kaugemas perspektiivis.
5. HIU. Järgnev ahel peaks olema siis mingi inimliidestus ahel, mis suudab näidata siis näiteks lihtsat navigeerimisinffi - suunda ja kaugusi teistest objektidest (teised lennukid, pöördepunktid, lennuväli jne.). See on kalkuleeritav kõik sisendisse tulevast infist. Lisaks peaks see olema klaviatuuri abil lihtsasti häälestatav variomeetriks või mõneks muuks instrumendiks. Edasi liikuvat inffi võib ta täiendada hoiatuspakettide näol. Seda peaks vastu võtma näiteks mõni järgmine liides, mis oskab häält teha või tulukesi vilgutada vms. Eks igaüks ise valib, kui radikaalselt ta asja lahendab. Et kas hoiatus öeldakse maha inimkeeli või teatud toonilise piuksuga. Ka häälvariomeetri signaalid peaks HIU kalkuleerima, kuna seda saab ainukesena juhtida. Neid HIU-sid võib olla erinevaid ja neid võib üldse mitte olla, kui jätad kõik näiteks pihuarvuti teha.
6. DEU. Kui GPS oli kõige alguseks, siis andmete ekspordi moodul peaks olema nn. terminaator. Põhimõtteliselt saab ka ilma selleta RS232 abil viimase seadmega arvutit ühendada, kuid DEU peaks pakkuma laiendatud võimalusi ja ilusat portide pesa armatuuril. Esiteks peaks see konvertima infoedastuse NMEA-ks, kui sisemiselt kasutatakse muud (kiiremat). Teiseks peaks lisaks RS232-le olema ka USB ja miks mitte ka BlueTooth. Kolmandaks peaks seal olema SD kaarti pesa, et saaks lennuinfot logida. Seega siia oleks sellist protsessorit tarvis, millel tugi kõige jaoks olemas. Arvutusjõudlus pole siin oluline.

Ühesõnaga, aidake erinevate lahenduste jaoks optimaalne prose leida. Siin on küll palju ulmelisi ideid ja asi kipub jube keeruliseks arenema, kuid ma katsun siiski ajast pisut ette mõelda, et ei tekiks nüansse, mis arengut pidurdavad. Realiseerima ja testima hakkame niikuinii tükk-tüki haaval.
Henry

[andreie]

Vs: Lennuki instrumendid arvutiekraanile

Kui tohib, siis ma kommin natukene.

Ei ole hea mõte sedavõrd keeruka ülesande juures kohe sihtida optimaalset protsessorit/kontrollerit. Asja teeb keerukaks probleemi kana-muna-kana laadi olemus. Kas tead enne ülesande lahendamist, milliseid valemeid lõplik variant kasutama hakkab? Näiteks võib poole ehitamise pealt selguda, et kõvasti aitab silumine - kõmm! - jälle jupp arvutamist juures. Või siis selgub, et FLASH-i on algoritmide jaoks vähe. Hoidsid 500 krooni kokku, pärast ehitad juba peaaegu valmis aparatuuri ümber mitme tuhhi eest. Esimese eksemplari juures võib ju kahuriga varblast lasta, järgmiste juures vaatad, kui palju protsentuaalselt prose TEGELIKULT hõivatud on ja võtad sellevõrra nõrgemad isendid.

Lisan ennemöeldule, et iga kahe protsessori vaheline ühendusliin lisab väljatöötamise ajale tublisti juurde - ilmselt alahindan, kui ütlen, et 2-3 päeva ühenduse kohta.

Ujukomaarvude asemel kasuta võimalusel fikseeritud komaga arve, kuigi on veidi tülikam programmeerida, kuid protsessor jahvatab neid vähemalt 100 korda kiiremini läbi. Usun, et programmiridadest ei hakka arvutused võtma rohkem kui 10%, nii et kui selle 10% asemel ongi 20%, ei ole hullu.

P.S. Ega Sa simulaatori tegemise peale pole mõelnud, a'la ühendad teise arvuti serialpordid oma apastraadi külge andmeid genereerima? Iga väikese pisiasja debugimise pärast lennuki peale ronimine teeb debugimisest projekti suurima ajaröövli.

[lendurhenry]

Vs: Lennuki instrumendid arvutiekraanile

Serial port selleks ongi hea, et siis saad panna kasvõi PC mingit sõlme simuleerima.

Tegin visioonist veel ühe verisooni ja asendasin selle keskprotsessori kahe mooduliga:
OSU - Orientation Sensing Unit, mis hõlmab nii kiirendus, güro, kui ka kompassi andureid.
ASU - Air Sensing Unit, mille juurde kuuluvad ka juhtpinnad. Reostaadid võib ka pika juhtmega ühendada, seega olgu nad kus tahes.
(Asendasin ka HIU HIM-ga, kuna see lühend tekitab assotsiatsiooni venekeelse sõnaga "hui")

Nüüd idee oleks lasta sealt andmed järjestikku läbi. Nii on lihtsam testida. Et siis OSU täiendab ja täpsustab GPS andmeid peale seda lisab ASU andmed lennuki asetsemise kohta õhu suhtes. Selleks, et kalkuleerida tuule kiirust ning õhu tõusmise kiirust, selleks ongi vaja täpseid andmeid liikumise kohta. GPS-st tuleb näiteks inff igas sekundis. Selle aja jooksul käib OSU 10 tsükklit ja leiab igal korral nihke abil täpse asukoha. Kui vahepeal ei ole kiirenduste või pöörangutega limiite ületatud, siis jääb arvutatud tulemus primaarseks ja GPS tulemuse abil leitakse mingid eksimuse tentensi parameetrid. Vastasel juhul võetakse GPS andmed aluseks. Nende järgi kalkuleerib siis ASU ülejäänud orientatsiooniparameetrid, kasutades võrdlemiisi aeglaselt muutuvaid parameetreid (rõhud, juhtpinnad). ASU tegeleb siis ka flash-s olevate polaari graafikute parandamisega ning takistusteguri arvutusega. Ja just selleks vajalikud andmed ta sisse saab. Ainsaks probleemiks siin on see, et OSU saab GPS-lt andmed NMEA-s ja ta peab tegelema ka transleerimisega.

Võibolla oleks paras aeg mõelda ka suhtlusprotokolli peale. Kas ASCII või binaarne? Ma eelistaks sellist, kus oleks kõik orientatsiooni parameetrid juba ühes binaar paketis, mida ei pea ümber teisendama. Iga moodul täiendab seda ja lisab sinna oma parameetrid. Vajadus oleks järgmiste parameetrite edastamise järgi:
1) Paketi saatja (lennuki või objekti tunnus)
2) Aeg (ms täpsusega).
3) Koht (kõrgus, laiuskraad, pikkuskraad)
4) Kiirus (vertikaalne, WE, NS)
5) Pöörlemiskiirus (vertikaalne, rullumine, kallutus)
6) Suund (vertikaalne, WE, NS)
7) Maa suund lennuki suhtes (raskusjõud lennuki telgede suhtes)
8) Tuule suund (vertikaalne, WE, NS)
9) Kohtumisnurgad
10) HIM korraldused
11) HIM (hoiatus)signaalid

Paketi pikkuseks nii 128B, kui see oleks binaarne.
Kui asi teha ASCII-na, siis NMEA-d järgides. Iga mooduli pakett edastatakse muutmata kujul edasi, lisaks saadetakse eraldi oma. Täiega dilemma.

Ilmselt esimene etapp tuleks valmis teha datalogger. Seega GPS+DEU. Lihtne oleks teha siis vahele üks HIM, mis hakkab navigatsiooniandmeid näitama. Heliga võiks see juba hoiatada, kui kurist kõrvale kaldud. Järgmine etapp oleks OSU ja HIM tuleks ümber progeda, et oskaks koguenergia variomeetrit emuleerida. Kui edasi ASU juurde ehitada ja see õieti ära häälestada tehes palju testlende, siis saab juba õhu liikumist variomeetris näidata. Ennem järgmise hooaja lõppu ei usu, et sinna maani jõuab. Järgmine talv võiks siis mõelda selle DTU peale. See omaks niikuinii mõtet ainult siis, kui teised purjekad ja lennuvälja torn kah nende seadmetega varustada. Samas see DTU oleks üks põnevamaid mooduleid üldse, kuid sellest hiljem.
Henry