Lihtsalt mõned mõtted
Väga suur stabiilsus on saavutatav ilma igasuguse spetselektroonikata.
On olemas klass F1 - vabalend. Seal lendavad kõik lennukid ISE ja stabiilsus pole miski eriline probleem. Ükskõik mis asendist lähevad lennukid , kui ainult kõrgust jätkub, peagi normaallennule tagasi.
Helikopteritel on samuti olemas näiteks Heli-Max Axe EZ (simulaatoris RF3.5) või LAMA tüüpi helikopterid, mida on küllalt võimatu tagurpidi pöörata. Juhtimisesks piisab gaasist ja "pöördetüürist".
Seepärast ei näe küll mingit mõistlikku põhjust vigurlennuriistade elektroonika abil "reisilennukiks" tegemiseks.
Usun, et esimesed põhiprobleemid on mingi etteantud lennumarsruudi lendamine ja siis kõrgusehoidmine.
Näiteks "kollase" kohal autonoomne ringislend võimaldaks kestvusrekordit teha, mis juba oleks miski rakendus.
Mõistlik on ka side kadumise korral stardikohta tagasitulek, mis võimaldaks julgeid fotoretki jne.
UAV juhtelektroonika - isetegemise rõõm - MIDA ?
Esimene asi, mida ette võtaks, kui kunagi sinnamaani välja jõuan on kopteri saba hoidmise täiendamine magnetilise kompassiga. Mistahes kallis güro ei hoia saba õiges asendis kuithase kaua. Kopteri raam, mootor ega akud digitaalse magnetilise kompassi tööd ei sega. Olen testinud. Sellise mooduli istutaks vastuvõtja ja güro vahele. Kui kangi asend on keskel siis hakkab tööle kompassi aga muidu kuulatakse juhtsignaali puldilt.
Minule tundub kah nende "tavapäraste" kopterite UAV-ideks muutmine üpris küsitav tegevus. Olles veidi uurinud ja näinud mida mujal maailmas tehakse, siis... seda eriti ei tehta! UAV seisukohast juba eos stabiilne lennuriist on kõige A ja O vast ikkagi, kui just eesmärk pole helikiirusel lennata või midagi taolist.
"Tavapärase" kopteri stabiliseerimine ise-enesest on muidugi ka jälle eraldi teema.
Ehk siis on võimalik võtta stabiilne lendav mudel ja tegeleda selle autonoomse juhtimise arendamisega. Või võtta ebastabiilne lendav mudel ja tegeleda selle lennu automaatse stabiliseerimisega. Mõlemat korraga vast teha ei tasu ja polegi mõtet ehk?
Minu mõningad mõtted sel teemal lihtsalt
"Tavapärase" kopteri stabiliseerimine ise-enesest on muidugi ka jälle eraldi teema.
Ehk siis on võimalik võtta stabiilne lendav mudel ja tegeleda selle autonoomse juhtimise arendamisega. Või võtta ebastabiilne lendav mudel ja tegeleda selle lennu automaatse stabiliseerimisega. Mõlemat korraga vast teha ei tasu ja polegi mõtet ehk?
Minu mõningad mõtted sel teemal lihtsalt
Lauri Laidna - www.pistik.com
Et vigurlennukopter pole eriti töökindel (pudinarohke mehaanika) ja stabiilne "värk", otsitakse pidevalt mõistlikumaid lahendusi. Paistab, et on ka edusamme:
http://www.youtube.com/watch?v=rJ9r2orc ... st%3A40877
http://www.youtube.com/watch?v=rJ9r2orc ... st%3A40877
http://en.wikipedia.org/wiki/V-22_Osprey on kah üks kaval idee.[J] wrote:Et vigurlennukopter pole eriti töökindel (pudinarohke mehaanika) ja stabiilne "värk", otsitakse pidevalt mõistlikumaid lahendusi. Paistab, et on ka edusamme:
http://www.youtube.com/watch?v=rJ9r2orc ... st%3A40877
Sattusin hiljuti juhuslikult artiklile, kus võrreldi Harrieri ja Ospreyd. Põhiline erinevus on juhtimises - Harrieril teeb seda inimene, Ospreyl erakordselt keerukate algoritmidega elektroonika. 21. sajandi matemaatika.
Kõige värskemad andmed lennumasinate automaatjuhtimisest, mida mina olen näinud, on 60-datest. Andmete all mõtlen ma reaalselt töötanud seadmete juhtimisalgoritme ja programmilõike. Näiteks on avaldatud Apollo kuumooduli juhtimiskood. Unikaalse protsessori masinkood puudulike selgitustega. Tehnkaajaloo huviliste ringkondades liiguvad mõned 50-60-ndate aastate nõukogude teatmikud. Põhiliselt analoogtehnika. On ka algoritme, aga nende kasutamiseks tavaharidusest ei piisa.
Arvan, et töötava UAV süsteemi loomiseks on möödapääsmatu matemaatiku ja juhtimisteoreetiku abi. Kardan. et automaatjuhtimise teooriat Eestis vastaval tesemel ei õpetatagi. Kindlasti on vaja ka programmisti(reaalset, matemaatikuharidusega).
Näituseks. automaatjuhtimise A ja O on PID regulaator. Neid olen ma teatmike abil ise kokku pannud ja häälestanud. Signaale töödeldakse kõiksugu filtritega. Neid olen samuti kirjanduse abiga arvestanud ja kokku pannud. Digitaalsete filtrite programme pole koostanud, aga olen neid parameetrite abil häälestanud. Nüüd UAV-de juurde. GPSi signaali peab UAV jaoks müra vähendamiseks töötlema nn. Kalman'i filtriga. Tegu on puhta matemaatikaga tõenäosusterooria ja statistika kandist. Vot selle filtri häälestamisega, rääkimata koostamisest, ei saa ma iseseisvalt kuidagi hakkama. Ehk ilma teoreetikute abita on vähe lootust midagi korralikku teha.
See oli ainult üks näide, kitsaskohti on rohkem.
Kõige värskemad andmed lennumasinate automaatjuhtimisest, mida mina olen näinud, on 60-datest. Andmete all mõtlen ma reaalselt töötanud seadmete juhtimisalgoritme ja programmilõike. Näiteks on avaldatud Apollo kuumooduli juhtimiskood. Unikaalse protsessori masinkood puudulike selgitustega. Tehnkaajaloo huviliste ringkondades liiguvad mõned 50-60-ndate aastate nõukogude teatmikud. Põhiliselt analoogtehnika. On ka algoritme, aga nende kasutamiseks tavaharidusest ei piisa.
Arvan, et töötava UAV süsteemi loomiseks on möödapääsmatu matemaatiku ja juhtimisteoreetiku abi. Kardan. et automaatjuhtimise teooriat Eestis vastaval tesemel ei õpetatagi. Kindlasti on vaja ka programmisti(reaalset, matemaatikuharidusega).
Näituseks. automaatjuhtimise A ja O on PID regulaator. Neid olen ma teatmike abil ise kokku pannud ja häälestanud. Signaale töödeldakse kõiksugu filtritega. Neid olen samuti kirjanduse abiga arvestanud ja kokku pannud. Digitaalsete filtrite programme pole koostanud, aga olen neid parameetrite abil häälestanud. Nüüd UAV-de juurde. GPSi signaali peab UAV jaoks müra vähendamiseks töötlema nn. Kalman'i filtriga. Tegu on puhta matemaatikaga tõenäosusterooria ja statistika kandist. Vot selle filtri häälestamisega, rääkimata koostamisest, ei saa ma iseseisvalt kuidagi hakkama. Ehk ilma teoreetikute abita on vähe lootust midagi korralikku teha.
See oli ainult üks näide, kitsaskohti on rohkem.
Usun, et see tõde hakkab kehtima kiirustel üle 200 km/h. Väikestel lennukiirustel, stabiilsete lennuriistadega saab lendu suunata ka ilma kõrgemat järku regulaatoriteta ja kontrollida lihtsate anduritega.töötava UAV süsteemi loomiseks on möödapääsmatu matemaatiku ja juhtimisteoreetiku abi
"Uimastel süsteemidel" ikka naljalt juhtsignaal valepidiseks ei osutu.
Lihtsaid autopiloote ehitatakse hoolega ja seejuures edukalt.
http://diydrones.com/profiles/blog/show ... st%3A37739
UAV-teemast juba läbi käinud ka, aga tuletan siiski meelde ka siin, et vabalennu mudelid lendavad ju täiesti ise. Kui "teeme-ise" UAV ülesandeid väga keerukaks ei aja, siis ise lendavat vabalennu mudelit veidi suunama panna pole ju probleem. Viljandis selline gps-asjapulk juba kuid olemas 
Sealt on võimalik siis asja edasi arendada nii palju, kui oskused ja haridus võimaldavad. Aga reaalselt "meil" ju mingit abosluutselt ebastabiilset lendajat ise lendavaks teha polegi vaja a la B2 pommitaja.
Sealt on võimalik siis asja edasi arendada nii palju, kui oskused ja haridus võimaldavad. Aga reaalselt "meil" ju mingit abosluutselt ebastabiilset lendajat ise lendavaks teha polegi vaja a la B2 pommitaja.Lauri Laidna - www.pistik.com
Hei,
Mul on jäänud mulje, et vabalennu mudelid lendavad ja on häälestatud stabiilseks ühel kindlal kiirusel. UAV võiks suuta osata lennata erinevate kiirustega ja ainult kõrgustüüri staatilisest sättimisest nagu ei piisa.
Ma olen tegelenud üha iseenesest üsna stabiilse lennuki (Elektru-UHU) juhtimisega autopiloodi abil ja see ei ole nii lihtne kui võiks arvata. Kaldega pole probleemi (kuigi ma lisasin talle kaldtüürid:-), aga kiiruse ja suuna hoidmisega küll. Tegeleda tuleb just võnkumiste mahasurumisega ning pakun, et teatavat häälestamist tuleb teha ka siis, kui vabalennu lennukile ainult pöördetüüri juhtimine peale panna.
Mul on jäänud mulje, et kõige edukamad lahendused sisaldavad endas lennuki ja (muutuva) keskkonna matemaatilist mudelit ja enam-vähem teavad ette, kui palju on vaja tüüri liigutada, et mudel muudaks oma asendi soovituks. Regulaator, mis oma tegevuse tulemust ette ei tea, ainult jälgib olukorda ja adapteerub kiirelt, nii edukas ei ole, aga tihtipeale piisab ka sellest.
Ehk siis, ma ütleks nii: garanteeritud ja täpse tulemuse jaoks on vaja matemaatikut/füüsikut/automaatikut, aga toimiva tulemuse on võimalik saada ka hobikorras. Ka GPS mõõtmise häiretest sõltub täpsus - kui selles suhtes piisavalt järele anda, siis probleemi ei tohiks olla...
AndrusK
Mul on jäänud mulje, et vabalennu mudelid lendavad ja on häälestatud stabiilseks ühel kindlal kiirusel. UAV võiks suuta osata lennata erinevate kiirustega ja ainult kõrgustüüri staatilisest sättimisest nagu ei piisa.
Ma olen tegelenud üha iseenesest üsna stabiilse lennuki (Elektru-UHU) juhtimisega autopiloodi abil ja see ei ole nii lihtne kui võiks arvata. Kaldega pole probleemi (kuigi ma lisasin talle kaldtüürid:-), aga kiiruse ja suuna hoidmisega küll. Tegeleda tuleb just võnkumiste mahasurumisega ning pakun, et teatavat häälestamist tuleb teha ka siis, kui vabalennu lennukile ainult pöördetüüri juhtimine peale panna.
Mul on jäänud mulje, et kõige edukamad lahendused sisaldavad endas lennuki ja (muutuva) keskkonna matemaatilist mudelit ja enam-vähem teavad ette, kui palju on vaja tüüri liigutada, et mudel muudaks oma asendi soovituks. Regulaator, mis oma tegevuse tulemust ette ei tea, ainult jälgib olukorda ja adapteerub kiirelt, nii edukas ei ole, aga tihtipeale piisab ka sellest.
Ehk siis, ma ütleks nii: garanteeritud ja täpse tulemuse jaoks on vaja matemaatikut/füüsikut/automaatikut, aga toimiva tulemuse on võimalik saada ka hobikorras. Ka GPS mõõtmise häiretest sõltub täpsus - kui selles suhtes piisavalt järele anda, siis probleemi ei tohiks olla...
AndrusK
Mis siin ikka arvata? Saab ju võistlustel vaatamas käia.Mul on jäänud mulje, et vabalennu mudelid lendavad ja on häälestatud stabiilseks ühel kindlal kiirusel.
http://gallery.pistik.com/view_album.ph ... me=album69
Näiteks see lennuk pakib oma tiivad lahti alles peale lubatud 5 sekundilist mootorlennu lõppu (umbes 300 meetrit kõrgust):
Tegu maailma paremiku hulka kuuluva Ukraina võistlejaga.
On jäänud mulje, et UAV-de iseehitajad võtavad liiga palju korraga ette. Hakatakse kohe koordinaatide, marsruutide ja muu sellisega tegelema. Esimeseks sammuks peale lennuvahendi stabiliseerimist (elektroonilist või valitud konstruktsiooni kaudu) peaks olema, püsiva kõrguse ja õhu suhtes suuna hoidmine. Järgmine ja otsustav samm oleks maa suhtes kursi hoidmine(suund ja kõrgus). Väja võiks näha umbes nii: mudel starditakse puldiga juhtimisel nagu mudel ikka ja lennutatakse ohutule kõrgusele, ütleme 50m. Edasi lülitatakse sisse kapten-roolimadrus rezhiim. Kapten maa peal annab käsu - "320deg, 55m" ja roolimadrus üleval läheb antud kursile ja hoiab teda kuni tuleb muutev käsk. Just see, maapinna suhtes enamvähem sirge lend etteantud suunas ja kõrgusel on kõige alus. Kuidas asi tehniliselt lahendatakse - variante on mitmeid. Alles nüüd saab tegelda UAV tähtsaima funktsiooniga - etteantud koordinaatidega punkti läbimine kindlal kursil. On ka lihtsustatud võimalus - läbida punkte ainult 0 ja 180deg tuule suhtes.
Teine asi, mis hobiUAV-de puhul silma hakkab - püüd liikuda mingeid "optimaalseid " trajektoore mööda. Umbes nii, et leida lühim tee punktide A, B, C vahel (või joon, mis läbib). Tegelikult lennatakse nagu lahingülesande täitmisel. UAV-d ongi ju piloodita lahinglennukid. Ei hakka pikalt seletama, toon näiteks variandi kolme ette ja vasakule jääva punkti läbimisest. Kõigepealt minnakse kahte esimest punkti läbivale sirgele(kolmas punkt jääb sellest sirgest vasakule) ja lennatakse see läbi. Peale teise punkti läbimist ei keerata vasakule kolmanda punkti suunas, vaid tehakse silmus paremale teist ja kolmandat punkti ühendavale sirgele, lennatakse veelkord läbi teise punkti ja seejärel otse läbi kolmanda jne. Kordan veelkord, see on ainult üks variantidest.
Kolmas asi, et püütakse kõik funktsioonid ühe kontrolleri peal ära teha. Kaasaegsete protsessorite arvutusvõimsus muidugi võimaldaks. Sisendeid ja väljundeid jätkub ka. Aga praktikas muutub sellise süsteemi väljatöötamine väga tülikaks. Loetaks paremaks, kui keskprotsessorisse lähevad juba töödeldud andmed: näiteks GPS-lt suunavektor ja koordinaadid, altimeeteetrilt tõusukiirus ja absoluutväärtus jne. Töötlemise all mõtlen ma mõõtmise teooria järgi, kes on tehnikat õppinud, see peaks mäletama
. Väikesed protsessorid on kerged, ümberprogrammeeritavad ja odavad. Moodulkonstruktsioon oleks kordades lihtsamini häälestatav.
Teine asi, mis hobiUAV-de puhul silma hakkab - püüd liikuda mingeid "optimaalseid " trajektoore mööda. Umbes nii, et leida lühim tee punktide A, B, C vahel (või joon, mis läbib). Tegelikult lennatakse nagu lahingülesande täitmisel. UAV-d ongi ju piloodita lahinglennukid. Ei hakka pikalt seletama, toon näiteks variandi kolme ette ja vasakule jääva punkti läbimisest. Kõigepealt minnakse kahte esimest punkti läbivale sirgele(kolmas punkt jääb sellest sirgest vasakule) ja lennatakse see läbi. Peale teise punkti läbimist ei keerata vasakule kolmanda punkti suunas, vaid tehakse silmus paremale teist ja kolmandat punkti ühendavale sirgele, lennatakse veelkord läbi teise punkti ja seejärel otse läbi kolmanda jne. Kordan veelkord, see on ainult üks variantidest.
Kolmas asi, et püütakse kõik funktsioonid ühe kontrolleri peal ära teha. Kaasaegsete protsessorite arvutusvõimsus muidugi võimaldaks. Sisendeid ja väljundeid jätkub ka. Aga praktikas muutub sellise süsteemi väljatöötamine väga tülikaks. Loetaks paremaks, kui keskprotsessorisse lähevad juba töödeldud andmed: näiteks GPS-lt suunavektor ja koordinaadid, altimeeteetrilt tõusukiirus ja absoluutväärtus jne. Töötlemise all mõtlen ma mõõtmise teooria järgi, kes on tehnikat õppinud, see peaks mäletama
. Väikesed protsessorid on kerged, ümberprogrammeeritavad ja odavad. Moodulkonstruktsioon oleks kordades lihtsamini häälestatav.Hei,
moodulkonstruktsioon on kahtlemata way to go, aga minu arust see ei pea olema realiseeritud raua tasemel, tarkvaras on lihtsam.
Minu arust jaguneb lennuki juhtelektroonika üldjoontes kaheks - seljaaju (stabiliseerib lennukit ja hoiab etteantud kiirust/suunda/kõrgust) ja peaaju (otsustab, et kuhu minna ja mida teha). Need kaks komponenti võivad olla eraldi kivides, aga ei pea, kuna suuremasse kivisse mahub tavaliselt probleemitult ka väiksema kivi funktsionaalsus ära ja interruptidega saab ajakriitilised asjad ära teha mõttetegevust ja pikki arvutusi segamata. Ise näen kahe kivi mõtet (suhtlemas üle järjestikpordi arvatavasti) siis, kui nende op systeemid on erinevad (peaaju on näiteks linuxi peal, mille alla mina näiteks hetkel ei oska draivereid teha servode otsejuhtimiseks). Sellistesse moodulitesse, mis lihtsalt kontrollivad mingit funktsiooni (servot v mootorit) ja omavahel ei suhtle, ma ei usu.
Siin foorumis on kuulda olnud 3 inimest/seltskonda, kes uav'ga suhteliselt aktiivselt tegelevad - AndrusT (+AndresO) on integraator, kes kasutab valmis juppe teatava eesmärgi saavutamiseks, Ilmar paistab tegelevat esmajoones peaajuga ja mina alustasin seljaajust. Ei usu, et midagi valesti on, sest kui endal tulemus käes ja hakatakse tegelema poolega millega teine on tegelenud, siis saab ju kogemusi vahetada.
AndrusK
moodulkonstruktsioon on kahtlemata way to go, aga minu arust see ei pea olema realiseeritud raua tasemel, tarkvaras on lihtsam.
Minu arust jaguneb lennuki juhtelektroonika üldjoontes kaheks - seljaaju (stabiliseerib lennukit ja hoiab etteantud kiirust/suunda/kõrgust) ja peaaju (otsustab, et kuhu minna ja mida teha). Need kaks komponenti võivad olla eraldi kivides, aga ei pea, kuna suuremasse kivisse mahub tavaliselt probleemitult ka väiksema kivi funktsionaalsus ära ja interruptidega saab ajakriitilised asjad ära teha mõttetegevust ja pikki arvutusi segamata. Ise näen kahe kivi mõtet (suhtlemas üle järjestikpordi arvatavasti) siis, kui nende op systeemid on erinevad (peaaju on näiteks linuxi peal, mille alla mina näiteks hetkel ei oska draivereid teha servode otsejuhtimiseks). Sellistesse moodulitesse, mis lihtsalt kontrollivad mingit funktsiooni (servot v mootorit) ja omavahel ei suhtle, ma ei usu.
Siin foorumis on kuulda olnud 3 inimest/seltskonda, kes uav'ga suhteliselt aktiivselt tegelevad - AndrusT (+AndresO) on integraator, kes kasutab valmis juppe teatava eesmärgi saavutamiseks, Ilmar paistab tegelevat esmajoones peaajuga ja mina alustasin seljaajust. Ei usu, et midagi valesti on, sest kui endal tulemus käes ja hakatakse tegelema poolega millega teine on tegelenud, siis saab ju kogemusi vahetada.
AndrusK
Hei,
kui on olemas tulemus, millega rahule jään, siis arvatavasti teen oma threadi, aga kirjutaks siia üldised põhimõtted, kuidas mu autopiloodi hakatis on üles ehitatud:
1. 16f870 kivi hetkel 4MHz kvartsiga, sisemine takt 1MHz. Täidab ühe käsu mikrosekundis, timeri tick on üks mikrosekund jne. Et servo signaal on 1ms-2ms, siis on servo juhtsignaali hoidmiseks vaja kahte baiti ning enamus muutujaid ja arvutusi on tegelikult 16-bitised.
2. 16-bitine timer käib pidevalt ringiratast. Vastuvõtja signaale ja kaldeandurit sisestatakse port change interruptidega. Interrupt kirjutab timeri väärtuse ja portb väärtuse ringpuhvrisse, seda töödeldakse interruptist väljas. Üldises programmis kontrollitakse ka timer overflow biti väärtust ning tehakse overflow puhul perioodilisi tegevusi.
Hetkel mul tuleb vastuvõtjast 3 juhet - kanalid 1,3 ja 5 - aga kuna 1 ja 3 kanali vahe on 2. kanal ja 3 lõpu ning 5alguse vahe on 4. kanali signaal, siis ma saan kätte 5 kanalit. R608FS kasutamisel on karta, et servo signaalid tulevad korraga, siis saab kätte 3 kanalit ainult või tuleb kasutada kivi rohkemate interrupt-on-change sisenditega.
3. kiiruse mõõtmiseks on rõhuandur mpxv5004dp, 4kPa max rõhk, see on ühendatud a/d sisendisse 0. Kuna rõhk on kiiruse ruut, siis võtab PIC anduri väärtusest tabeli abil ruutjuure ja edasi tegeletakse kiirusega m/s. Üks saatja pöördnupu signaal teisendatakse kah m/s skaalasse, sealt tuleb speed target. See teema on hetkel arengufaasis.
4. ad kanalisse 1 läheb mpx4115as absoluutse rõhu andur - see on olemas, aga pole külge jootnud, kuna tegelen kiirusega hetkel.
5. servo väljunditeks on hetkel 6 bitti, signaali väljutamine toimub biti nihutamisega interruptide abil (timer1 compare interrupt, igas interruptis nihutatakse bitti ja võetakse puhvrist uus väärtus komparaatori jaoks).
6. 3 bitti ühes pordis on võetud elektroonilise kompassi jaoks - see väljastab x ja y telje suunalise magnetvälja väärtusi. PIC teisendab signaali binary radian (brad) kujule (1 bait, väärtused 0...255 tähistavad siis suundi), jagades x ja y väärtusi (400 mikrosekundit läheb selle peale) ja kasutades tulemusel arctangents funktsiooni tabeli abil. Hetkel nurka arvutatakse ja edukalt, aga suunda ei korrigeerita, see ootab kiiruse juhtimise paikasaamist.
7. On ka 2x16 display - see väljastab hetkel 8 16-bitise muutuja väärtusi.
Programmi südameks on tsükkel, mis vastavalt flag'idele kutsub välja alamprogramme. Alamprogrammid on portB sisendi haldamiseks, kompassi haldamiseks, A/D muunduri haldamiseks, juhtimistehete tegemiseks, perioodiliste tegevuste jaoks ja väljundi seadmiseks. Alamprogrammid seavad üldise state bitte, mis lubavad järgmise alamprogrammi aktiveerimise, neil võib olla ka oma sisemine state. Alamprogramme võib vaadelda moodulitena, ühe modimine ei pruugi nõuda teiste alamprogrammide muutmist.
Üldine loogika on nii, et oodatakse vastuvõtja signaalide saabumist - kui nad on käes, siis tehakse tehted ja seatakse väljundväärtused puhvrisse. Kiirus, kompass, kalle tulevad asünkroonselt ja tehetes kasutatakse viimaseid teadaolevaid väärtusi. Kui vastuvõtjast signaali ei tule, siis iga umbes 25ms ootamise järel seatakse vastuvõtja sisenditele fail-safe ning arvutatakse väljund ikkagi. Väljundite arvutamise ning sisendite saabumise vahel on n.ö. "vaba aeg", kus tegevusi tehakse interruptidega (servo väljundi saatmine ja vastuvõtja/kaldeanduri sisendi lugemine). Sinna ma üritan suunata rõhuandurite ja kompassi signaalidega tegelemist. Arvatavasti mahuks sinna ajaliselt GPS manipulatsioon kah.
Reguleerimiseks olen seni kasutanud PI-tüüpi regulaatorit, kusjuures integraalne komponent on seatud saavutama max väärtust 30 sek jooksul (plaanin seda kasutada trim'ina). See töötab kalde puhul, ei ole aga võimaldanud mul vabaneda lennuki "pumpamisest", seetõttu on hetkel proovimisfaasis I2D tüüpi regulaator - 2 integraalset komponenti, üks neist trim (30 sek max väärtuseni), teine integraalne komponent sõltub diferentsi suurusest ja võiks saavutada maksimumi umbes 0.5 sek jooksul. Samas kontrollitakse ka, mis suunas differents liigub ja kui ta väheneb, siis nullitakse teine integraalne komponent ära, trim tiksub edasi. See võiks toimida nii, et kui lennuk liigub liiga aeglaselt, siis hakatakse tema nina alla suunama kuni hetkeni, millal lennuki kiirus hakkab tõusma. Siis nullitakse korrigeeriv signaal ja vaadatakse, mis saab edasi. Kui kiirus nüüd tõuseb, siis tuksub ainult trim kuniks saavutatakse soovitud kiirus, aga kui kiirus hakkab vähenema või läheb üle soovitud kiiruse, siis hakatakse jälle teise integraalse komponendi abil korrigeerima. See on ilmselt see koht, kus võiks rohkem tutvuda olemasolevate lahendustega. Ise pusimine on samas huvitav ning tekitab arusaama, et milleks midagi vaja on.
Kui kiirusega ok, siis panen külge staatilise rõhuanduri ja siis saab proovida mootoriga kõrgust hoida. Mind huvitab pigem purilennuki tüüpi mootori juhtimine, ehk mootoriga kõrgele ja siis mootor välja, toimiva kiirusregulatsiooniga ei tohiks selle funktsiooni lisamine nõuda erilist pingutust. Ühtlasi on siis võimalik hakata tõusvaid õhuvoole otsima - kaldeanduriga saab aru nõksust tiiva pihta, rõhuanduriga saab aru, kas lennuk tõuseb või vajub. Ja siis peaks mõtlema GPS ühendamise peale, aga see vajab suuremale (arvatavasti 16-bitisele) kivile üleminekut.
Update: programmeerimine assembleris, usart on planeeritud gps sisendiks, hetkel kasutuses tabloo väljundina. Kivi käib pessa ja liigub perioodiliselt autopiloodi ja programmaatori vahet. Keskkond on MPLAB IDE.
AndrusK
kui on olemas tulemus, millega rahule jään, siis arvatavasti teen oma threadi, aga kirjutaks siia üldised põhimõtted, kuidas mu autopiloodi hakatis on üles ehitatud:
1. 16f870 kivi hetkel 4MHz kvartsiga, sisemine takt 1MHz. Täidab ühe käsu mikrosekundis, timeri tick on üks mikrosekund jne. Et servo signaal on 1ms-2ms, siis on servo juhtsignaali hoidmiseks vaja kahte baiti ning enamus muutujaid ja arvutusi on tegelikult 16-bitised.
2. 16-bitine timer käib pidevalt ringiratast. Vastuvõtja signaale ja kaldeandurit sisestatakse port change interruptidega. Interrupt kirjutab timeri väärtuse ja portb väärtuse ringpuhvrisse, seda töödeldakse interruptist väljas. Üldises programmis kontrollitakse ka timer overflow biti väärtust ning tehakse overflow puhul perioodilisi tegevusi.
Hetkel mul tuleb vastuvõtjast 3 juhet - kanalid 1,3 ja 5 - aga kuna 1 ja 3 kanali vahe on 2. kanal ja 3 lõpu ning 5alguse vahe on 4. kanali signaal, siis ma saan kätte 5 kanalit. R608FS kasutamisel on karta, et servo signaalid tulevad korraga, siis saab kätte 3 kanalit ainult või tuleb kasutada kivi rohkemate interrupt-on-change sisenditega.
3. kiiruse mõõtmiseks on rõhuandur mpxv5004dp, 4kPa max rõhk, see on ühendatud a/d sisendisse 0. Kuna rõhk on kiiruse ruut, siis võtab PIC anduri väärtusest tabeli abil ruutjuure ja edasi tegeletakse kiirusega m/s. Üks saatja pöördnupu signaal teisendatakse kah m/s skaalasse, sealt tuleb speed target. See teema on hetkel arengufaasis.
4. ad kanalisse 1 läheb mpx4115as absoluutse rõhu andur - see on olemas, aga pole külge jootnud, kuna tegelen kiirusega hetkel.
5. servo väljunditeks on hetkel 6 bitti, signaali väljutamine toimub biti nihutamisega interruptide abil (timer1 compare interrupt, igas interruptis nihutatakse bitti ja võetakse puhvrist uus väärtus komparaatori jaoks).
6. 3 bitti ühes pordis on võetud elektroonilise kompassi jaoks - see väljastab x ja y telje suunalise magnetvälja väärtusi. PIC teisendab signaali binary radian (brad) kujule (1 bait, väärtused 0...255 tähistavad siis suundi), jagades x ja y väärtusi (400 mikrosekundit läheb selle peale) ja kasutades tulemusel arctangents funktsiooni tabeli abil. Hetkel nurka arvutatakse ja edukalt, aga suunda ei korrigeerita, see ootab kiiruse juhtimise paikasaamist.
7. On ka 2x16 display - see väljastab hetkel 8 16-bitise muutuja väärtusi.
Programmi südameks on tsükkel, mis vastavalt flag'idele kutsub välja alamprogramme. Alamprogrammid on portB sisendi haldamiseks, kompassi haldamiseks, A/D muunduri haldamiseks, juhtimistehete tegemiseks, perioodiliste tegevuste jaoks ja väljundi seadmiseks. Alamprogrammid seavad üldise state bitte, mis lubavad järgmise alamprogrammi aktiveerimise, neil võib olla ka oma sisemine state. Alamprogramme võib vaadelda moodulitena, ühe modimine ei pruugi nõuda teiste alamprogrammide muutmist.
Üldine loogika on nii, et oodatakse vastuvõtja signaalide saabumist - kui nad on käes, siis tehakse tehted ja seatakse väljundväärtused puhvrisse. Kiirus, kompass, kalle tulevad asünkroonselt ja tehetes kasutatakse viimaseid teadaolevaid väärtusi. Kui vastuvõtjast signaali ei tule, siis iga umbes 25ms ootamise järel seatakse vastuvõtja sisenditele fail-safe ning arvutatakse väljund ikkagi. Väljundite arvutamise ning sisendite saabumise vahel on n.ö. "vaba aeg", kus tegevusi tehakse interruptidega (servo väljundi saatmine ja vastuvõtja/kaldeanduri sisendi lugemine). Sinna ma üritan suunata rõhuandurite ja kompassi signaalidega tegelemist. Arvatavasti mahuks sinna ajaliselt GPS manipulatsioon kah.
Reguleerimiseks olen seni kasutanud PI-tüüpi regulaatorit, kusjuures integraalne komponent on seatud saavutama max väärtust 30 sek jooksul (plaanin seda kasutada trim'ina). See töötab kalde puhul, ei ole aga võimaldanud mul vabaneda lennuki "pumpamisest", seetõttu on hetkel proovimisfaasis I2D tüüpi regulaator - 2 integraalset komponenti, üks neist trim (30 sek max väärtuseni), teine integraalne komponent sõltub diferentsi suurusest ja võiks saavutada maksimumi umbes 0.5 sek jooksul. Samas kontrollitakse ka, mis suunas differents liigub ja kui ta väheneb, siis nullitakse teine integraalne komponent ära, trim tiksub edasi. See võiks toimida nii, et kui lennuk liigub liiga aeglaselt, siis hakatakse tema nina alla suunama kuni hetkeni, millal lennuki kiirus hakkab tõusma. Siis nullitakse korrigeeriv signaal ja vaadatakse, mis saab edasi. Kui kiirus nüüd tõuseb, siis tuksub ainult trim kuniks saavutatakse soovitud kiirus, aga kui kiirus hakkab vähenema või läheb üle soovitud kiiruse, siis hakatakse jälle teise integraalse komponendi abil korrigeerima. See on ilmselt see koht, kus võiks rohkem tutvuda olemasolevate lahendustega. Ise pusimine on samas huvitav ning tekitab arusaama, et milleks midagi vaja on.
Kui kiirusega ok, siis panen külge staatilise rõhuanduri ja siis saab proovida mootoriga kõrgust hoida. Mind huvitab pigem purilennuki tüüpi mootori juhtimine, ehk mootoriga kõrgele ja siis mootor välja, toimiva kiirusregulatsiooniga ei tohiks selle funktsiooni lisamine nõuda erilist pingutust. Ühtlasi on siis võimalik hakata tõusvaid õhuvoole otsima - kaldeanduriga saab aru nõksust tiiva pihta, rõhuanduriga saab aru, kas lennuk tõuseb või vajub. Ja siis peaks mõtlema GPS ühendamise peale, aga see vajab suuremale (arvatavasti 16-bitisele) kivile üleminekut.
Update: programmeerimine assembleris, usart on planeeritud gps sisendiks, hetkel kasutuses tabloo väljundina. Kivi käib pessa ja liigub perioodiliselt autopiloodi ja programmaatori vahet. Keskkond on MPLAB IDE.
AndrusK
Last edited by ak on Fri Jul 11, 2008 20:17, edited 2 times in total.
Mõned arvavad ka nii ja on tegudes isegi ette jõudnud:tola555 wrote:http://en.wikipedia.org/wiki/V-22_Osprey on kah üks kaval idee
http://api.ning.com/files/wT3mI933bQfWg ... /image.jpg
Hei,
update tegemistest autopiloodi kallal.
Eelmises postituses pakutud algoritm ei toiminud, võnkumised olid ikkagi. Tundub, et on mõttekas ajada asju standartse PID regulaatoriga, lihtsalt ta tuleb õigesti häälestada. PID regulaatoreid PIC baasil teha ei ole probleem, näiteks niimoodi:
http://www.microchip.com/stellent/idcpl ... e=en021807
PID häälestamiseks tundub sobivaim olevat kas Ziegler–Nichols method või siis meetod mille nime ma ei tea, aga põhimõte on selles, et muudetakse astmeliselt sisendit ja väljundi graafikult vaadatakse dead time, maksimum tõus ja lõppväärtus ning arvutatakse koefitsendid vastavalt (näide http://www.omega.com/temperature/z/pdf/z115-117.pdf ).
Kogu see asi võiks olla lihtne, kui oleks aega minna ja eksperimenteerida erinevate seadistustega kuni optimaalne käes, aga mul on keskmiselt aega teha nädalas üks max pool tundi lend. Ühtlasi oleks vajalik, et lennuki sensorite väärtused ja sisemised muutujad saaks kas maapealse arvuti serial porti üle eetri või siis vähemalt salvestatud lennukis logerisse kuniks ta maandub. Oleks veel hea, kui saaks PID regulaatori muutujaid maa pealt lennuki lendamise ajal timmida. Ühesõnaga, loomulik areng kipub liikuma Paparazzi süsteemi suunas, kus ground station'il on oluline osa...
Enda lühiajalised plaanid on üritada eksperimenteerides paika saada PID regulaatori väärtused, millega lennuk lendab rahuldavalt, siis liikuda edasi suuna hoidmise peale ja lõpuks kõrguse piiride hoidmise/tõusvate õhuvoolude jahtimise peale. Lennu ajal regulaatori tuunimise võimalusi piirab kasutatav PIC, kus muutujate mälu on praktiliselt otsas. Ma üritan seal teha loogika, mis suurte võnkumiste korral keerab maha PID ülekandeid, aga see on vast suht kõik. Ma integreerisin autopiloodi ka nüüd R608FS vastuvõtjaga, aga ma ei ole päriselt aru saanud, kuidas ja mis ajalises järjekorras kanalid sealt tulevad - hetkel on PIC logika see, et vastuvõtja kanalid tulevad samuti asünkroonselt nagu ka andurite signaalid, kasutatakse viimast väärtust ning perioodiliselt arvutatakse ja saadetakse väljundit. Ühtlasi kaotas ka mõtte signaali puudumise loogika - vastuvõtja saadab alati midagi.
Kanaleid saan kätte 3, üsna lihtsalt saaks lisada veel ühe, aga siis on ka hetke raua piir. Kasutan hetkel CH2 (throttle) kanalit autopiloodi sisse-väljalülitamiseks - piirasendites on autopiloot väljas ja saba juhtimine tuleb otse puldilt. Keskasendist natuke allpool on piloot aktiivne ja mootor seisab, keskasendist natuke üles on piloot aktiivne ja mootoril täispöörded. Kui piloot on aktiivne, siis elevatori signaali abil määratakse speed target, saba ta otseselt ei juhi. Pöördetüür on endiselt saatja küljes, kompassiga ei arvestata.
Natuke pikemaajalisem perspektiiv on hankida suurem kivi, endiselt PIC praeguste plaanide kohaselt. Ühest küljest oleks kena, kui kivis oleks natuke mälu, mille abil saaks PID lennu ajal tuunida, teisest küljest oleks hea omada piisavalt interrupt-on-change sisendeid, et saaks kõik saatja kanalid PIC'i sisse ja omada suuremat kontrolli toimuva üle. Kolmandast küljest oleks hea omada 2 serial porti, üks tabloo/juhtimise jaoks ja teine gps'ile, neljandast küljest võiks kivi olla piisavalt kiire, et interrupti sisenemine ja selle teenindamine võiks toimuda 1 mikrosekundi jooksul, nii et sisendsignaali mõõtmisel häireid poleks. Olen mõelnud sellise kivi nagu dsPIC30F614A - see töötab veel 5V peal, pakutavate võimaluste poolest on väga tasemel, aga hind on ikkagi ainult 500EEk kandis Eestist ostes - ei midagi erilist võrreldes muu kraamiga. Ainus raskus on tema pakendi tüüp ja väikeste mõõtmete juures suur jalgade arv, tuleb talle ilmselt custom trükkplaat teha. See on ideefaasis hetkel. Kaalun ka DSPIC30F4013 - see on kahjuks vähema mälu ja jalgade arvuga ja on kahtlemata kompromiss, aga saadaval amatöörile paremini manageeritava 40PDIP korpusega ja hind ka ainult 150EEK.
AndrusK
update tegemistest autopiloodi kallal.
Eelmises postituses pakutud algoritm ei toiminud, võnkumised olid ikkagi. Tundub, et on mõttekas ajada asju standartse PID regulaatoriga, lihtsalt ta tuleb õigesti häälestada. PID regulaatoreid PIC baasil teha ei ole probleem, näiteks niimoodi:
http://www.microchip.com/stellent/idcpl ... e=en021807
PID häälestamiseks tundub sobivaim olevat kas Ziegler–Nichols method või siis meetod mille nime ma ei tea, aga põhimõte on selles, et muudetakse astmeliselt sisendit ja väljundi graafikult vaadatakse dead time, maksimum tõus ja lõppväärtus ning arvutatakse koefitsendid vastavalt (näide http://www.omega.com/temperature/z/pdf/z115-117.pdf ).
Kogu see asi võiks olla lihtne, kui oleks aega minna ja eksperimenteerida erinevate seadistustega kuni optimaalne käes, aga mul on keskmiselt aega teha nädalas üks max pool tundi lend. Ühtlasi oleks vajalik, et lennuki sensorite väärtused ja sisemised muutujad saaks kas maapealse arvuti serial porti üle eetri või siis vähemalt salvestatud lennukis logerisse kuniks ta maandub. Oleks veel hea, kui saaks PID regulaatori muutujaid maa pealt lennuki lendamise ajal timmida. Ühesõnaga, loomulik areng kipub liikuma Paparazzi süsteemi suunas, kus ground station'il on oluline osa...
Enda lühiajalised plaanid on üritada eksperimenteerides paika saada PID regulaatori väärtused, millega lennuk lendab rahuldavalt, siis liikuda edasi suuna hoidmise peale ja lõpuks kõrguse piiride hoidmise/tõusvate õhuvoolude jahtimise peale. Lennu ajal regulaatori tuunimise võimalusi piirab kasutatav PIC, kus muutujate mälu on praktiliselt otsas. Ma üritan seal teha loogika, mis suurte võnkumiste korral keerab maha PID ülekandeid, aga see on vast suht kõik. Ma integreerisin autopiloodi ka nüüd R608FS vastuvõtjaga, aga ma ei ole päriselt aru saanud, kuidas ja mis ajalises järjekorras kanalid sealt tulevad - hetkel on PIC logika see, et vastuvõtja kanalid tulevad samuti asünkroonselt nagu ka andurite signaalid, kasutatakse viimast väärtust ning perioodiliselt arvutatakse ja saadetakse väljundit. Ühtlasi kaotas ka mõtte signaali puudumise loogika - vastuvõtja saadab alati midagi.
Kanaleid saan kätte 3, üsna lihtsalt saaks lisada veel ühe, aga siis on ka hetke raua piir. Kasutan hetkel CH2 (throttle) kanalit autopiloodi sisse-väljalülitamiseks - piirasendites on autopiloot väljas ja saba juhtimine tuleb otse puldilt. Keskasendist natuke allpool on piloot aktiivne ja mootor seisab, keskasendist natuke üles on piloot aktiivne ja mootoril täispöörded. Kui piloot on aktiivne, siis elevatori signaali abil määratakse speed target, saba ta otseselt ei juhi. Pöördetüür on endiselt saatja küljes, kompassiga ei arvestata.
Natuke pikemaajalisem perspektiiv on hankida suurem kivi, endiselt PIC praeguste plaanide kohaselt. Ühest küljest oleks kena, kui kivis oleks natuke mälu, mille abil saaks PID lennu ajal tuunida, teisest küljest oleks hea omada piisavalt interrupt-on-change sisendeid, et saaks kõik saatja kanalid PIC'i sisse ja omada suuremat kontrolli toimuva üle. Kolmandast küljest oleks hea omada 2 serial porti, üks tabloo/juhtimise jaoks ja teine gps'ile, neljandast küljest võiks kivi olla piisavalt kiire, et interrupti sisenemine ja selle teenindamine võiks toimuda 1 mikrosekundi jooksul, nii et sisendsignaali mõõtmisel häireid poleks. Olen mõelnud sellise kivi nagu dsPIC30F614A - see töötab veel 5V peal, pakutavate võimaluste poolest on väga tasemel, aga hind on ikkagi ainult 500EEk kandis Eestist ostes - ei midagi erilist võrreldes muu kraamiga. Ainus raskus on tema pakendi tüüp ja väikeste mõõtmete juures suur jalgade arv, tuleb talle ilmselt custom trükkplaat teha. See on ideefaasis hetkel. Kaalun ka DSPIC30F4013 - see on kahjuks vähema mälu ja jalgade arvuga ja on kahtlemata kompromiss, aga saadaval amatöörile paremini manageeritava 40PDIP korpusega ja hind ka ainult 150EEK.
AndrusK
>> teisest küljest oleks hea omada piisavalt interrupt-on-change sisendeid, et saaks kõik saatja kanalid PIC'i sisse
vastuv6tja kaku lahti ja otsi see koht yles, kus kogu PPM signaal yhes tykis saadaval on .. siis piisab yhest sisendist ..
vt n2iteks siia: http://diydrones.com/profiles/blog/show ... st%3A38393
2.4GHz asjade juures ei pruugi niikergesti k2ia asjad, tuleb tunnistada ... multiplexi vastuv6tjast sain 6ige signaali ca 5 minutiga ..
vastuv6tja kaku lahti ja otsi see koht yles, kus kogu PPM signaal yhes tykis saadaval on .. siis piisab yhest sisendist ..
vt n2iteks siia: http://diydrones.com/profiles/blog/show ... st%3A38393
2.4GHz asjade juures ei pruugi niikergesti k2ia asjad, tuleb tunnistada ... multiplexi vastuv6tjast sain 6ige signaali ca 5 minutiga ..
skype:kaido
Kunagi sai kasutatud 18LF2550 planaarset varianti, mis oli müüja poolt DIP jalaaukudega plaadile pandud. Üks dsPIC30F4012 vedeleb siiamaani lauasahtlis, sai lihtsamatega hakkama.
PID regulaatoritest. Reaalsete masinate omad on keerulisemad, kui nendes näidetes. On veel anduri lõtku, hüstereesi või tühikäigu kompensatsioon, anduri viivituse kompensatsioon, kiiruse, venituse, libisemise, vea kompensatsioon, termokompensatsioon või veel midagi. Väljund pole ka sageli lihtsalt lineaarne. Näiteks ventilaatoreid kiirendatakse püsiva momendiga, midagi ruutfunktsiooni sarnast. Seisutakistuse ületamiseks, paigaltsaamiseks antakse lühikesi võimsaid impulsse. Samuti on võimsuse, voolu, kiirenduse piirajad. Veel näiteks: alisvoolu mootoreid juhitakse 2 astmeliselt 2 väljundkanali ja vähemalt 2 tagasiside sisendi kaudu.
On ju ilmne, et tüür 3 ja 30deg nurga all toimib täiesti erinevalt. Sellepärast ma eelmistes postides rääkisingi spetsiifiliste lennukijuhtimise algoritmide vajalikkusest. Lennukil on kõik kiiruste ja nurkadega seotud funktsioonid mittelineaarsed ja mittepidevad. Lineaarseteks võib lugeda ainult väga väikeseid vahemikke.
Tegelikult on vajalikud algoritmid lisaks PID regulaatoritele gürodesse ja lennustabilisaatoritesse sisse ehitatud. Ise neid aretama hakata on mittevajalik ja lootusetu ettevõtmine.
Lihtsustatult võiks välja näha nii :
1."peaajust" väljuvad külgsuuna- ja kõrgusesuuna muutmise signaalid
2. lendu stabiliseerib B.T.A AS-07
3. suunasignaal läheb läbi integreeriva lennukigüro(head-held) rudderile
4. kõrgusesignaal läheb autopiloodile
B.T.A AS-07 -l on ka külgsuuna sisend, aga selle andmeid pole avaldatud.
PID regulaatoritest. Reaalsete masinate omad on keerulisemad, kui nendes näidetes. On veel anduri lõtku, hüstereesi või tühikäigu kompensatsioon, anduri viivituse kompensatsioon, kiiruse, venituse, libisemise, vea kompensatsioon, termokompensatsioon või veel midagi. Väljund pole ka sageli lihtsalt lineaarne. Näiteks ventilaatoreid kiirendatakse püsiva momendiga, midagi ruutfunktsiooni sarnast. Seisutakistuse ületamiseks, paigaltsaamiseks antakse lühikesi võimsaid impulsse. Samuti on võimsuse, voolu, kiirenduse piirajad. Veel näiteks: alisvoolu mootoreid juhitakse 2 astmeliselt 2 väljundkanali ja vähemalt 2 tagasiside sisendi kaudu.
On ju ilmne, et tüür 3 ja 30deg nurga all toimib täiesti erinevalt. Sellepärast ma eelmistes postides rääkisingi spetsiifiliste lennukijuhtimise algoritmide vajalikkusest. Lennukil on kõik kiiruste ja nurkadega seotud funktsioonid mittelineaarsed ja mittepidevad. Lineaarseteks võib lugeda ainult väga väikeseid vahemikke.
Tegelikult on vajalikud algoritmid lisaks PID regulaatoritele gürodesse ja lennustabilisaatoritesse sisse ehitatud. Ise neid aretama hakata on mittevajalik ja lootusetu ettevõtmine.
Lihtsustatult võiks välja näha nii :
1."peaajust" väljuvad külgsuuna- ja kõrgusesuuna muutmise signaalid
2. lendu stabiliseerib B.T.A AS-07
3. suunasignaal läheb läbi integreeriva lennukigüro(head-held) rudderile
4. kõrgusesignaal läheb autopiloodile
B.T.A AS-07 -l on ka külgsuuna sisend, aga selle andmeid pole avaldatud.
>> vastuv6tja kaku lahti ja otsi see koht yles, kus kogu PPM signaal yhes tykis saadaval on .. siis piisab yhest sisendist ..
tänan, asjalik link. Ma võtsin ühe PPM vastuvõtja lahti ja tõepoolest, sama nihkeregister on seal.
Ma vaatasin R608FS sisse ja natuke uurisin teda ossiga - seal on ka pisikesed kivid, mis võivad olla nihkeregistrid, aga ma sain ühest neist 3 impulssi ainult ja teistele ei pääsenud ligi - vastuvõtja trükkplaat on 2-korruseline. Kui ma võrdlesin omavahel kanaleid ossiga, siis tundub, et kanalid 1-6 väljastatakse korraga, 7 ja 8 järgmises grupis. Saatja manual väidab, et PCM G3 korral saadetakse kanalid 3'ste gruppidena, võib-olla 2.4G puhul saadetakse kuueste gruppidena siis. Võimalik ka, et mingi vahe on, et kas saatja on 14-kanali (multichannel) rezhiimis (R8014FS ja ka R608FS töötavad sellega) või 7-kanali rezhiimis (6 ja 7 kanaliliste vastuvõtjate jaoks), äkki R617FS puhul saaks sarnaselt PPM'iga impulsid kätte. Esialgu pole küll endal plaanis 7-kanaliga vastuvõtjat muretseda, nii et proovida ei saa...
piperclub, kas oled proovinud ise lennukit juhtida regulaatoriga?
AndrusK
tänan, asjalik link. Ma võtsin ühe PPM vastuvõtja lahti ja tõepoolest, sama nihkeregister on seal.
Ma vaatasin R608FS sisse ja natuke uurisin teda ossiga - seal on ka pisikesed kivid, mis võivad olla nihkeregistrid, aga ma sain ühest neist 3 impulssi ainult ja teistele ei pääsenud ligi - vastuvõtja trükkplaat on 2-korruseline. Kui ma võrdlesin omavahel kanaleid ossiga, siis tundub, et kanalid 1-6 väljastatakse korraga, 7 ja 8 järgmises grupis. Saatja manual väidab, et PCM G3 korral saadetakse kanalid 3'ste gruppidena, võib-olla 2.4G puhul saadetakse kuueste gruppidena siis. Võimalik ka, et mingi vahe on, et kas saatja on 14-kanali (multichannel) rezhiimis (R8014FS ja ka R608FS töötavad sellega) või 7-kanali rezhiimis (6 ja 7 kanaliliste vastuvõtjate jaoks), äkki R617FS puhul saaks sarnaselt PPM'iga impulsid kätte. Esialgu pole küll endal plaanis 7-kanaliga vastuvõtjat muretseda, nii et proovida ei saa...
piperclub, kas oled proovinud ise lennukit juhtida regulaatoriga?
AndrusK
>> tänan, asjalik link. Ma võtsin ühe PPM vastuvõtja lahti ja tõepoolest, sama nihkeregister on seal.
mul l2ks kergemini, ei olnd vaja isegi nihkeregistrit otsida - multiplexi 7-chan IPD vastuv6tja on v2ga ilusasti lahendatud kahel trykkplaadil - yhel raadioosa ja teisel siis digitaalosa .. kahe osa vahel on ainult loetud arv yhendusi - nende hulgas siis ka vajalik
mul l2ks kergemini, ei olnd vaja isegi nihkeregistrit otsida - multiplexi 7-chan IPD vastuv6tja on v2ga ilusasti lahendatud kahel trykkplaadil - yhel raadioosa ja teisel siis digitaalosa .. kahe osa vahel on ainult loetud arv yhendusi - nende hulgas siis ka vajalik
skype:kaido
Hei,
tundub, et PIC upgrade aeg jõudis kätte oodatust kiiremini - kanali lisamine võttis ära viimase jupi PIC mälust ning kanalite korraga saatmine tekitas olulise sõltuvuse interrupt latency'st. Kui kanalite järjestikuse sisestuse puhul interrupt latency pole tähtis, see taandub välja, siis paraleelse kanalite sisestuse puhul hakkab ta ebameeldivalt mõjutama ja seda ei saa vältida, niimoodi rallit ei sõida. Ringpuhver sisendite hoidmiseks jäi vist samuti väikseks, sest kui väga lähestikku tulevad 4 kanali ja kaldeanduri sisendid, siis 5'st tasmest ei pruugi piisata enam.
Ehk siis, tellisin 16-bit kivi ära - kuniks ta tuleb (üsna varsti), on ilmselt mõttekas pilooti arendada PPM vastuvõtjaga. Ühtlasi saab ka tegeleda koodi portimisega. Proovisin teha interrupt koodi 16-bitisena - ta on umbes 3x lühem, koos suurema kivi taktiga on interrupt latency alla mikrosekundi, ehk siis ei mõjuta mõõdetava tulemuse täpsust üldse. Koos muude omadustega - interruptide prioritiseerimine, hardware multiply & divide ning muud põnevad võimalused, nagu "Euclidean distance" arvutamise käsk - on uue kiviga majandamine lihtsam ja ta oleks kiirem ka siis, kui takt samaks jääks. Hetkel ei saagi enam aru, miks ma enne 16-bitist kivi ei võtnud... Üsna põnev on ka vaadata, mida annavad AD muunduri 2 lisabitti.
See on siis 3. põlvkond juba - esimene piloot oli 16F627 peal ja oskas kallet korrigeerida, teine piloot 16f870 sai endale külge ka display, kompassi ja rõhuandurid. Kolmas põlvkond siis areneb dsPIC30F4013 peal. Küll ta kunagi lendama kah hakkab:-)
AndrusK
tundub, et PIC upgrade aeg jõudis kätte oodatust kiiremini - kanali lisamine võttis ära viimase jupi PIC mälust ning kanalite korraga saatmine tekitas olulise sõltuvuse interrupt latency'st. Kui kanalite järjestikuse sisestuse puhul interrupt latency pole tähtis, see taandub välja, siis paraleelse kanalite sisestuse puhul hakkab ta ebameeldivalt mõjutama ja seda ei saa vältida, niimoodi rallit ei sõida. Ringpuhver sisendite hoidmiseks jäi vist samuti väikseks, sest kui väga lähestikku tulevad 4 kanali ja kaldeanduri sisendid, siis 5'st tasmest ei pruugi piisata enam.
Ehk siis, tellisin 16-bit kivi ära - kuniks ta tuleb (üsna varsti), on ilmselt mõttekas pilooti arendada PPM vastuvõtjaga. Ühtlasi saab ka tegeleda koodi portimisega. Proovisin teha interrupt koodi 16-bitisena - ta on umbes 3x lühem, koos suurema kivi taktiga on interrupt latency alla mikrosekundi, ehk siis ei mõjuta mõõdetava tulemuse täpsust üldse. Koos muude omadustega - interruptide prioritiseerimine, hardware multiply & divide ning muud põnevad võimalused, nagu "Euclidean distance" arvutamise käsk - on uue kiviga majandamine lihtsam ja ta oleks kiirem ka siis, kui takt samaks jääks. Hetkel ei saagi enam aru, miks ma enne 16-bitist kivi ei võtnud... Üsna põnev on ka vaadata, mida annavad AD muunduri 2 lisabitti.
See on siis 3. põlvkond juba - esimene piloot oli 16F627 peal ja oskas kallet korrigeerida, teine piloot 16f870 sai endale külge ka display, kompassi ja rõhuandurid. Kolmas põlvkond siis areneb dsPIC30F4013 peal. Küll ta kunagi lendama kah hakkab:-)
AndrusK
Last edited by ak on Fri Jul 18, 2008 20:50, edited 1 time in total.
Kunagi sai tehtud väike PWM-PCM recoder lennuki juhtimise visualiseerimiseks. Viimane sorts on selles threadis:
http://www.rcgroups.com/forums/showthread.php?t=640740
Minu õnneks genereeris minu vastuvõtja impulsse järjest ja väikse vahega. Ma OR-isin kõik kaheksa kanalit kokku ja siis piisas ühest interrupt on change pinist. Pmst sain samasuguse PPM signaali nagu Kaido, ainult et ei pidanud vastuvõtja sees kaevama. Mõnel PIC-l on ka capture võimalus - see oleks väga abiks.
Ma usun, et sellist vastuvõtjat, mis kõik signaalid korraga väljastaks ei ole olemas. See oleks aku suhtes liiga sadistlik. Ehk siis natuke ossiga mässates peaks olema võimalik grupeerida signaale nii, et piisaks ka kahest-kolmest sisendist.
Mina olen mõelnud, et kui peaks tegema universaalse paljukanalilise PWM signaali hookimise, siis kasutaks kaht proset - üks dekodeeriks sisendeid ja saadaks siis dekodeeritud väärtused mingi digitaalse ja mitte-ajakriitilise protokolli abil teisele. Väljundi genereerimisega on vist lihtsam - seda võiks ehk ka põhiprose teha.
Arne
http://www.rcgroups.com/forums/showthread.php?t=640740
Minu õnneks genereeris minu vastuvõtja impulsse järjest ja väikse vahega. Ma OR-isin kõik kaheksa kanalit kokku ja siis piisas ühest interrupt on change pinist. Pmst sain samasuguse PPM signaali nagu Kaido, ainult et ei pidanud vastuvõtja sees kaevama. Mõnel PIC-l on ka capture võimalus - see oleks väga abiks.
Ma usun, et sellist vastuvõtjat, mis kõik signaalid korraga väljastaks ei ole olemas. See oleks aku suhtes liiga sadistlik. Ehk siis natuke ossiga mässates peaks olema võimalik grupeerida signaale nii, et piisaks ka kahest-kolmest sisendist.
Mina olen mõelnud, et kui peaks tegema universaalse paljukanalilise PWM signaali hookimise, siis kasutaks kaht proset - üks dekodeeriks sisendeid ja saadaks siis dekodeeritud väärtused mingi digitaalse ja mitte-ajakriitilise protokolli abil teisele. Väljundi genereerimisega on vist lihtsam - seda võiks ehk ka põhiprose teha.
Arne
Code: Select all
piperclub, kas oled proovinud ise lennukit juhtida regulaatoriga?Kui lennu stabiliseerimisega olid esimesed tulemused käes, siis muretsesin suurema lennuki, 1,6 m Multiplex Magisteri. Aga see osutus elektrilennukina liiga jõuetuks ja lennuaeg oli ka ainult 4-5 min. Konverteerisin ta sisepõletajale ja sain suurepärase traineri, kahjuks UAV platvormiks sobimatu. Praegu lennutan SPM lennukeid, mitme asjaga ei jõua korraga tegelda. Kui aega rohkem üle jääb, on plaanis ise teha üks ~1.2 m lennuk miniUAV jaoks.
Vabandan otsekohesuse pärast, aga ma ei saa aru, miks te kasutate lennukiks mingeid "märg kana" tüüpi asju. Võtke mingi korralik plaaner (kere võib teha alati vajalikus mahus):
http://www.f5models.com/poly_pulsar2008.php
ja mootorlennu aeg 1 tund pole miski probleem.
http://www.f5models.com/poly_pulsar2008.php
ja mootorlennu aeg 1 tund pole miski probleem.
Hei,
mõtlesin, et kirjutan oma tegemistest viimase kuu jooksul. Eelmine postitus kuu aega tagasi päädis arusaamaga, et tuleb platformi uuendada ja nüüdseks on see tehtud. Nimelt, ehitasin oma uue piloodi 16-bitise signaaliprotsessori dsPIC30F3014 peale (plaanisin kasutada dspic30F4013, aga tellisin vale kivi ja kuigi mul on nüüdseks ka õige kivi olemas, on 3014 ja 4013 õnneks praktiliselt täiesti ühilduvad ja probleemi pole).
Esimene probleem oli kivi programmeerimisega - Vellemani K8048 seda ei tunnistanud, ma ei saanud ka tööle vabavaralist winpic'i. Sai siis ostetud Pickit2 ning sellega sai mure murtud - sain sellega ka lisaks pic riistvaralise debugimise võimaluse. Praegu on PIC küll autopiloodi pesas, aga programmeeritakse teda skeemist välja võtmata ja Pickit2'ga kulub programmeerimiseks paar sekundit ainult. Kui keegi Pic'idega tegeleda plaanid, siis soovitan soojalt muretseda programmaatoriks Pickit2, väga hea hinna ja omaduste suhe.
Teine raskus oli assembleri uue syntaxi tundmaõppimisega - ühest küljest on käske tunduvalt rohkem, teisest küljest on syntax lihtviisiliselt erinev. Ka kivi ise on keerulisem, aga kuna registrid on 16-bitised, siis on vaja vähem mõtiskleda, et mis registris see bitt nüüd oligi.
16-bitisel kivil on tööregistreid päris palju ja ilmselt oskaks C kompilaator neid optimaalsemalt kasutada kui ma assembleris seda suudan, aga nüüdseks on kogu kood ümber visatud ja nii programsest kui muutujate mälust on kasutusel kuskil 10% ringis, hea puhas ja kuiv tunne on teda edasi arendada nii. Korrutamine on 1 tsükkel, jagamine 18, nii et ei ole mingit muret korrutamise, jagamise või kasvõi ruutjuure võtmisega, see käib nii kähku et ei pea muretsema.
Hetkel on lennukil R608FS vastuvõtja, sellest tuleb pic'i 6 kanalit. Kiirendusanduri pöörasin risti ja mõõdan y-suunalist ja Z-suunalist kiirendust. Lisaks on veel küljes rõhuanduriga kiirusmõõtja ning staatilise rõhuanduriga kõrgusmõõtja ning elektrooniline kompass. Saatjas on 3 esimest kanalit konfitud kangide alla, järgmised 3 kanalit pöördnupud, millest ma keeran PID koeffitsente. Gaasikangi konfiguratsioon on nii nagu ennegi: kõige kõrgemas ja kõige madalamas asend on autopiloot väljas ning täielik manuaaljuhtimine, keskosas on autopiloot sees. Mootor töötab on-off rezhiimis - kui gaasikang on üle poole, siis on mootoril max pöörded, muidu seisab.
Esimese lennu tarbeks implementeerisin ainult P-tüüpi regulaatori kaldele ning kiirusele - esimene nupp seadis ülekannet y-kiirenduse ja aileronide juhtimise vahel. Referentskiiruseks seadsin 10 m/s ning teine nupp seadis ülekannet soovitud ja mõõdetava kiiruse vahe ning elevaatori vahel, kolmas nupp seadis ülekannet z-kiirenduse ja elevaatori vahel. Pöördetüüri juhiti igal hetkel kangist ainult. Tulemus oli hea, selles suhtes et lennukiga sai päris pikalt autopiloodi peal lennata ja ta lendas täitsa ok'lt, kuigi mingi hetk tekkisid ka võnkumised. Igal juhul, salvstasin regulaatorite asendid ja võnkumise sagedused sihiga PID regulaatori jaoks täpsed koefitsendid arvutada.
Teine lend ei läinud enam nii hästi, mul oli softis bugi ning lennuk oli liiga tundlik, kolmas lend on veel olemata. Küll aga on mõned probleemid ja mõned mõtted.
1. Lennuki reageerimine tüüride asendile sõltub lennuki kiirusest. Kuna õhutakistus on võrdeline kiiruse ruuduga, siis sama liigutuse tegemiseks tuleb suuremal kiirusel tüüri liigutada vähem. Selle implementeerimiseks ma jagan PID regulaatori koefitsente mõõdetud kiirusega, aga selle tulemuseks on see, et tüür üles praktiliselt ei liigu. Kui kiirus on suur ja selle vähendamiseks tuleks tüüri üles liigutada, siis kiirusega arvestamine võtab ülekanded maha. Alla aga samas liigutatakse tüüri siis, kui kiirus on liiga väike ja väikese kiirusega tuleb soovitud mõju saamiseks tüüri liigutada rohkem. See kõik on ok ja loogiline, aga seab suured nõuded trim'i täpsusele - kui algne trim on paigast ära ja lennuk pikeerib, siis ta ei pruugi pikeeringust välja tulla, kuna tüür ei liigu piisavalt üles. Trim'i tegemine kiiremaks nõuab integraalse komponendi suuremat ülekannet, mis aga põhjustab võnkumisi. Arvatavasti tuleks regulaatoris integraalsest komponendist loobuda, aga mingi valemiga rakendada soovitava kiiruse juhtsignaali otse väljundile. Mingid mõttet on hoida pic'is kas kiirustele vastava trim'i tabelit või siis kasutada mingit funktsiooni, mis tuleks enne kindlaks teha. Variant on panna ka algne trim teadlikult vale niimoodi, et lennuki kiirus oleks väiksem kui soovitud, ming lasta tal seda aeglaselt täpsustada lendamise käigus.
Eks neid mõtteid ole veelgi ja eks neid saab ka proovitud. Nii et - hetkel on autopiloot jälle arenduskorras ning elu läheb edasi.
AndrusK
mõtlesin, et kirjutan oma tegemistest viimase kuu jooksul. Eelmine postitus kuu aega tagasi päädis arusaamaga, et tuleb platformi uuendada ja nüüdseks on see tehtud. Nimelt, ehitasin oma uue piloodi 16-bitise signaaliprotsessori dsPIC30F3014 peale (plaanisin kasutada dspic30F4013, aga tellisin vale kivi ja kuigi mul on nüüdseks ka õige kivi olemas, on 3014 ja 4013 õnneks praktiliselt täiesti ühilduvad ja probleemi pole).
Esimene probleem oli kivi programmeerimisega - Vellemani K8048 seda ei tunnistanud, ma ei saanud ka tööle vabavaralist winpic'i. Sai siis ostetud Pickit2 ning sellega sai mure murtud - sain sellega ka lisaks pic riistvaralise debugimise võimaluse. Praegu on PIC küll autopiloodi pesas, aga programmeeritakse teda skeemist välja võtmata ja Pickit2'ga kulub programmeerimiseks paar sekundit ainult. Kui keegi Pic'idega tegeleda plaanid, siis soovitan soojalt muretseda programmaatoriks Pickit2, väga hea hinna ja omaduste suhe.
Teine raskus oli assembleri uue syntaxi tundmaõppimisega - ühest küljest on käske tunduvalt rohkem, teisest küljest on syntax lihtviisiliselt erinev. Ka kivi ise on keerulisem, aga kuna registrid on 16-bitised, siis on vaja vähem mõtiskleda, et mis registris see bitt nüüd oligi.
16-bitisel kivil on tööregistreid päris palju ja ilmselt oskaks C kompilaator neid optimaalsemalt kasutada kui ma assembleris seda suudan, aga nüüdseks on kogu kood ümber visatud ja nii programsest kui muutujate mälust on kasutusel kuskil 10% ringis, hea puhas ja kuiv tunne on teda edasi arendada nii. Korrutamine on 1 tsükkel, jagamine 18, nii et ei ole mingit muret korrutamise, jagamise või kasvõi ruutjuure võtmisega, see käib nii kähku et ei pea muretsema.
Hetkel on lennukil R608FS vastuvõtja, sellest tuleb pic'i 6 kanalit. Kiirendusanduri pöörasin risti ja mõõdan y-suunalist ja Z-suunalist kiirendust. Lisaks on veel küljes rõhuanduriga kiirusmõõtja ning staatilise rõhuanduriga kõrgusmõõtja ning elektrooniline kompass. Saatjas on 3 esimest kanalit konfitud kangide alla, järgmised 3 kanalit pöördnupud, millest ma keeran PID koeffitsente. Gaasikangi konfiguratsioon on nii nagu ennegi: kõige kõrgemas ja kõige madalamas asend on autopiloot väljas ning täielik manuaaljuhtimine, keskosas on autopiloot sees. Mootor töötab on-off rezhiimis - kui gaasikang on üle poole, siis on mootoril max pöörded, muidu seisab.
Esimese lennu tarbeks implementeerisin ainult P-tüüpi regulaatori kaldele ning kiirusele - esimene nupp seadis ülekannet y-kiirenduse ja aileronide juhtimise vahel. Referentskiiruseks seadsin 10 m/s ning teine nupp seadis ülekannet soovitud ja mõõdetava kiiruse vahe ning elevaatori vahel, kolmas nupp seadis ülekannet z-kiirenduse ja elevaatori vahel. Pöördetüüri juhiti igal hetkel kangist ainult. Tulemus oli hea, selles suhtes et lennukiga sai päris pikalt autopiloodi peal lennata ja ta lendas täitsa ok'lt, kuigi mingi hetk tekkisid ka võnkumised. Igal juhul, salvstasin regulaatorite asendid ja võnkumise sagedused sihiga PID regulaatori jaoks täpsed koefitsendid arvutada.
Teine lend ei läinud enam nii hästi, mul oli softis bugi ning lennuk oli liiga tundlik, kolmas lend on veel olemata. Küll aga on mõned probleemid ja mõned mõtted.
1. Lennuki reageerimine tüüride asendile sõltub lennuki kiirusest. Kuna õhutakistus on võrdeline kiiruse ruuduga, siis sama liigutuse tegemiseks tuleb suuremal kiirusel tüüri liigutada vähem. Selle implementeerimiseks ma jagan PID regulaatori koefitsente mõõdetud kiirusega, aga selle tulemuseks on see, et tüür üles praktiliselt ei liigu. Kui kiirus on suur ja selle vähendamiseks tuleks tüüri üles liigutada, siis kiirusega arvestamine võtab ülekanded maha. Alla aga samas liigutatakse tüüri siis, kui kiirus on liiga väike ja väikese kiirusega tuleb soovitud mõju saamiseks tüüri liigutada rohkem. See kõik on ok ja loogiline, aga seab suured nõuded trim'i täpsusele - kui algne trim on paigast ära ja lennuk pikeerib, siis ta ei pruugi pikeeringust välja tulla, kuna tüür ei liigu piisavalt üles. Trim'i tegemine kiiremaks nõuab integraalse komponendi suuremat ülekannet, mis aga põhjustab võnkumisi. Arvatavasti tuleks regulaatoris integraalsest komponendist loobuda, aga mingi valemiga rakendada soovitava kiiruse juhtsignaali otse väljundile. Mingid mõttet on hoida pic'is kas kiirustele vastava trim'i tabelit või siis kasutada mingit funktsiooni, mis tuleks enne kindlaks teha. Variant on panna ka algne trim teadlikult vale niimoodi, et lennuki kiirus oleks väiksem kui soovitud, ming lasta tal seda aeglaselt täpsustada lendamise käigus.
Eks neid mõtteid ole veelgi ja eks neid saab ka proovitud. Nii et - hetkel on autopiloot jälle arenduskorras ning elu läheb edasi.
AndrusK
Hei,
väike update: autopiloodil kiiruse hoidmine nüüd toimib. Kui lennuk stall'i ajada, siis sealt välja kukkudes ta lihtsalt saavutab vajaliku kiiruse ja lendab siis seda hoides edasi, võnkumisi ei teki. Oluline edasiminek toimus siis, kui sai sämplimisperiood diferentseeriva komponendi jaoks 160ms peale lastud. Enne seda, kui sai PID regulaatori diferentsiaalset komponenti arvutatud iga 20ms tagant, siis arvatavasti servo lihtsalt ei jõudnud reageerida (UHU servod on ka üsna uimased). Proportsionaalne komponent arvutatakse ikka iga 20ms tagant, integraalne kah.
Hetkel tegelen suuna hoimisega kompassi abil. See on keerulisem kui arvasin, kuna kallutamine mõjutab kompassi näitu olulisel määral. Üritan teha midagi sellist, et väikese suunaerinevuse juures seatakse trim'i, suure erinevuse puhul tehakse pöördetüüri väljalöök, oodatakse 0.5s, siis pannakse pöördetüür otseks, oodatakse veel 1s ja siis mõõdetakse kompassi näit ja vajadusel korratakse protseduuri. See veel ei toimi, kuna ma pole aru saanud, kui palju ma peaks kiiruse kasvades servosignaalide ülekannet vähendama, ning kallutamine ei toeta pöördetüüri tööd. Tundub, et mõõdetud rõhu väärtusega jagamine oli liiga karm, aga paistab, et rõhu ruutjuurega jagamine (kiirus) on ikka veel liig. Homme on plaanis proovida nii, et kaldetüüride ülekannet ei vahendatagi kiiruse kasvades.
Kui suunahoidmine toimima saab, siis ongi nagu aeg käes poodi gps järele minna. Tõusvaid öhuvoole saaks piloot otsida ka olemasoleva rauaga, aga oleks siiski kena, kui lennuk ise jälgiks, et ta liiga kaugele ei lähe ja oskaks koju tulla.
AndrusK
väike update: autopiloodil kiiruse hoidmine nüüd toimib. Kui lennuk stall'i ajada, siis sealt välja kukkudes ta lihtsalt saavutab vajaliku kiiruse ja lendab siis seda hoides edasi, võnkumisi ei teki. Oluline edasiminek toimus siis, kui sai sämplimisperiood diferentseeriva komponendi jaoks 160ms peale lastud. Enne seda, kui sai PID regulaatori diferentsiaalset komponenti arvutatud iga 20ms tagant, siis arvatavasti servo lihtsalt ei jõudnud reageerida (UHU servod on ka üsna uimased). Proportsionaalne komponent arvutatakse ikka iga 20ms tagant, integraalne kah.
Hetkel tegelen suuna hoimisega kompassi abil. See on keerulisem kui arvasin, kuna kallutamine mõjutab kompassi näitu olulisel määral. Üritan teha midagi sellist, et väikese suunaerinevuse juures seatakse trim'i, suure erinevuse puhul tehakse pöördetüüri väljalöök, oodatakse 0.5s, siis pannakse pöördetüür otseks, oodatakse veel 1s ja siis mõõdetakse kompassi näit ja vajadusel korratakse protseduuri. See veel ei toimi, kuna ma pole aru saanud, kui palju ma peaks kiiruse kasvades servosignaalide ülekannet vähendama, ning kallutamine ei toeta pöördetüüri tööd. Tundub, et mõõdetud rõhu väärtusega jagamine oli liiga karm, aga paistab, et rõhu ruutjuurega jagamine (kiirus) on ikka veel liig. Homme on plaanis proovida nii, et kaldetüüride ülekannet ei vahendatagi kiiruse kasvades.
Kui suunahoidmine toimima saab, siis ongi nagu aeg käes poodi gps järele minna. Tõusvaid öhuvoole saaks piloot otsida ka olemasoleva rauaga, aga oleks siiski kena, kui lennuk ise jälgiks, et ta liiga kaugele ei lähe ja oskaks koju tulla.
AndrusK
Hei,
update: kompassiga suuna hoidmine on tõesti väga problemaatiline: allpool on link artiklile, kus sel teemal juttu on. Artiklis räägitakse merekasutusest, aga lennukiga on see ilmselt veel hullem.
Key points: kompassi kallutamine ühe kraadi võrra võib põhjustada näidu erinevust kuni 10 kraadi. Seda kompenseeritakse integreerimisega, aga see tähendab, et kompassi näit arvutatakse tema keskmise näiduga, ütleme, viimase minuti jooksul, mis ilmselt ei ole piisavalt operatiivne, et hoida turbulentsides tantsivat lennukit kursil - see jõuab selle ajaga mitu tiiru teha. Tundub, et kahju küll, aga skeemi tuleb võtta lisaks güroskoop.
AndrusK
Artikkel: http://www.autonav.com/html/anav4009.htm
update: kompassiga suuna hoidmine on tõesti väga problemaatiline: allpool on link artiklile, kus sel teemal juttu on. Artiklis räägitakse merekasutusest, aga lennukiga on see ilmselt veel hullem.
Key points: kompassi kallutamine ühe kraadi võrra võib põhjustada näidu erinevust kuni 10 kraadi. Seda kompenseeritakse integreerimisega, aga see tähendab, et kompassi näit arvutatakse tema keskmise näiduga, ütleme, viimase minuti jooksul, mis ilmselt ei ole piisavalt operatiivne, et hoida turbulentsides tantsivat lennukit kursil - see jõuab selle ajaga mitu tiiru teha. Tundub, et kahju küll, aga skeemi tuleb võtta lisaks güroskoop.
AndrusK
Artikkel: http://www.autonav.com/html/anav4009.htm