|
Pro vysunutí tetheru je zapotřebí zorientovat nejdelší osu družice souhlasně s osou střed Země-družice (s osou Z). Nejdelší osou družice myslím tu procházející středem družice, středem stěny s anténou a středem stěny s otvorem pro vysunutí tetheru. Přitom stěna družice s připojenou anténou musí směřovat k Zemi, protilehlá stěna ze které se vysouvá tether od Země. Optimální by byla odchylka obou os menší než 30° v okamžiku začátku vysouvání tetheru.
Dále je vhodné (nevím jestli nutné) v okamžiku vysunutí tetheru "štěrbinu" tedy otvor pro vysunutí tetheru zorientovat jeho delší stranou kolmo na osu X a souhlasně s osou Y. To znamená že např. pokud by byl tether vysunut na Zemském magnetickém rovníku, tak při orientaci delší strany štěrbiny přesně souhlasně se Zemským magnetickým rovníkem by byla odchylka delší strany štěrbiny od roviny magn. rovníku do asi 10°-20°. Asi by bohatě vyhověla odchylka do 30°. Po rozvinutí tetheru do tvaru písmene T (kde spodek "nohy" písmene odpovídá poloze "kostky" tedy mateřského tělesa) budou obě "ramena" (tj. vrchní vodorovná "noha" písmene T) přibližně rovnoběžná s delší stranou štěrbiny. Za předpokladu že "ramena" tetheru nebudou rotovat nebo silně kývat okolo osy Z, umožní toto uspořádání při průletu nad zemsk. magnetickými póly využít téměř plně maximálních hodnot indukce v této oblasti pro silové působení na ramena tetheru protékaná el. proudem (ramena budou na koncích zakončena plazmovými kontaktory).
Po vysunutí tetheru by tento měl být stabilizován gradientem gravitačního pole tak že "svislá noha" písmene T je přibližně ve směru osy Z, ale bude se určitě kývat o jistý úhel. 3 cívky v mateřském tělese družice by mohly pomoci tyto kyvy postupně tlumit, stejně jako tlumit kyvy "ramen" písmene T okolo osy Z.
Před vysunutím tetheru jsem uvažoval 2 varianty "stabilizace" družice (tj. "kostky") pomocí 3 elmag. cívek:
1. stabilizace tak jak jsi ji popsal Ty, tj. jedna stěna družice je stále přivrácena k Zemi, tj. jedna otočka okolo osy Y za cca 90min. Dále jedna osa družice je stále souhlasná se směrem osy X (směrem letu) a druhá osa se směrem Y (kolmo). Vzhledem k tomu že směr letu družice je přibližně rovnoběžný se směrem siločar zemského mag. pole v oblastech nad rovníkem, a směr osy Z je v oblastech nad zemskými póly přibližně rovnoběžný se směrem zemských mag. siločar, je možné družici stabilizovat pomocí 3 cívek s přesností 15°až 25° když budeme zjednodušeně předpokládat že družice létá po přesně polární dráze a že zemské magn. póly a rovník souhlasí přesně s těmi skutečnými. Takováto přesnost stabilizace by měla bohatě vyhovět pro tether i pro anténu. V oblastech mezi póly a rovníkem musí družice udržovat určitý proměnný sklon vůči siločarám zemského mag. pole.
2. stabilizace kdy jedna osa družice je stále přibližně rovnoběžná se směrem siločar zemského magnetického pole. Družice vykoná při 1 oběhu okolo Země 2 plné otočky okolo osy Y. Dále je družice orientována tak aby stěna s anténou směřovala k Zemi nad severním pólem a nad jižním naopak. Tato varianta sice umožní kvalitní radiové spojení s družicí jen v určitých oblastech, konkrétně v pásmu 2.4GHz jen nad severní polokoulí, ale pro vysunutí tetheru by to mohlo postačovat pokud se toto uskuteční nad severní polokoulí. Konkrétně nad územím ČR by byl sklon nejdelší osy družice asi 50° k zemskému povrchu s možnou odchylkou plus minus až 25°, přitom optimální pro vysunutí tetheru je sklon 90° kdy stěna se štěrbinou směřuje přesně od Zemského povrchu. Snad by tato orientace družice byla postačující pro úspěšné vysunutí tetheru, popř. by snad šlo dát povel pro vysunutí tetheru aby proběhl v oblasti nad Zemským severním pólem kdy magnetometr změří maximální intenzitu zemského mag. pole. Tato 2. varianta by měla výhodu asi výrazně jednoduššího algoritmu pro stabilizaci družice.
Omlouvám se ale neumím to takhle příliš vysvětlovat pomocí psaného textu. Také si myslím že to co trvá napsat hodiny se dá vysvětlit možná za několik minut.
Jinak si myslím a vychází mi početně rovněž že počítat s maximální dobou rotace 1x za 3 sec. je odpovídající, ale když to půjde ještě trochu zpřísnit nebude to na závadu. |
|
Mel bych prosbu.
Pro SW pro simulaci pohybu a stabilizace satelitu a alespon nejakou vizualizaci bych potreboval data o zemskem povrchu.
Textury povrchu bych mel, i kdyz netusim, kdo je vlastnikem jejich copyrightu.
Souradnice mest a mist take, ty jsou snad zdarma.
Pomohlo by mi, pokud byste nekdo mel databazi souradnic bodu ohranicujicich kontinenty, pripadne dalsi zajimava geo-data, ktera by bylo dobre vizualizovat. |
| 11.9.2005 - 12:11 - spook | |
|
Včera mě napadlo(nejspíš je to ale blbost), jak by možná šlo nasměrovat družici na Zemi(přibližně).
Měřila by se napětí ze solárních článků. Jednotlivé hodnoty by byly v procentech a vybraly by se tři největší hodnoty(mx. osvětlených stran) a podle nich by se určila zhruba poloha Slunce. ( tím způsobem že: 100% u jedné strany by znamenalo, že Slunce je tim směrem, kde je natočená strana družice ; u dvou sousedních stran po 50% by znamenalo, že je Slunce zhruba tam, kam ukazuje společná hrana těchto stran atd….)
Tento postup by se prováděl nepřetržitě, v intervalu třeba 3s. Porovnáním několika výsledků za sebou by se dokázala odhadnout rotace družice a vypočítalo by se tak, jak bude rotovat dál(třeba na minutu dopředu)
Potom by se zjistila poloha družice(snad by šla odvodit od aktuálního času – myslím, že už to tady někdo psal) a podle průmětu by se odhadlo osvětlování(napětí) na daných stranách(taky cca na minutu dopředu).
Potom by se porovnaly výsledky z družice(odhad rotace podle změřeného napětí) a z průmětu na Zemský povrh. Odchylky které by se takto vypočítaly by byly potřebné změny v rotaci(ve všech třech osách), aby byla družice natočená aspoň tak zhruba k Zemi.
mno, doufám že pochopíte jak jsem to myslel a že to neni moc velká kravina(kdyžtak tenhle příspěvek smažte)
|
|
To je samozrejme dobra myslenka. Predpoklada to merit napeti clanku na jednotlivych plochach krychle s nejakou rozumnou presnosti, rekneme 8 bitu a 2-3 vzorky za sekundu.
Jestlize jsme se shodli, ze druzici bude tvorit sada relativne samostatnych inteligentnich bloku propojenych komunikacni sbernici, pak je toto ukolem napajeciho modulu. Pro algoritmy stabilizace by bylo dobre, kdyby poskytl data relativni osvetleni jednotlivych svych ploch, merena v presnych casovych odstupech.
Zname-li relativni osvetleni strany krychle, vyplyva z toho uhel, ktery svira vektor ke Slunci (napr. v souradne soustave satelitu), takze Slunce lezi na povrchu kuzele, jehoz osa prochazi prislusnou stranou a vrcholovy uhel je dvojnasobkem doplnku uhlu osvetleni do praveho uhlu.
Z dat osvetleni dvou stran jsou dve mozna reseni, z dat osvetleni 3 stran by melo vyjit reseni jedno ;-)
Dalsim zdrojem informace je sber dat z magnetometru, pokud na druzici bude (jako ze to vypada, ze ano). Primo hodnota z magnetometru (aktualni vektor vnejsiho pole v soustave druzice) je malo platna, ale zajimava je sekvence zmen tohoto vektoru, ze ktere lze oddelit zmenovou slozku zpusobenou pohybem v menicim se poli a slozku zpusobenou zmenou polohy satelitu.
Osobne by se mi libilo, kdyby byla na druzici obe mereni, magnetometry i mereni napeti solarnich clanku, a modul stabilizace by tyto informace kombinoval ... |
|
spook: Kdysi jsme se snažili vymyslet systém orientace, který by nepotřeboval primární informaci o dráze, což tebou navržený systém potřebuje. Ale pokud bychom nechali systém letět autonomně cca. alespoň jeden oběh, mohl by se ze střídání osvětlené a zemí stíněné části "naučit", kterým směrem je Země i bez znalosti svých kepleriánů. (jinými slovy by věděl, jestli je pod či nad ... (snad  ). A z pozorování své 3d rotace by tak přesně mohl určit svou 3D polohu nad povrchem ... |
|
k orientaci a stabilizaci našeho CubeSatu:
- s odvozením polohy (a snad i rotace) vůči Slunci z měření napětí na solárních článcích počítáme
- spookův návrh na porovnávání odhadů rotace je mi bohužel nějak nesrozumitelný
- v prvním přiblížení pro naši potřebu postačuje zastavení rotace vůči Slunci (alespoň ve dvou osách)
- ideálním stavem je asi "vázaná" rotace kolem Země (jedna plocha družice stále míří k Zemi)
- taky bych byl rád, kdyby na družici bylo i měření magnetometry, už jen pro možnost zjišťování polohy v zemském stínu
- výpočet polohy a rotace i návrh a řízení aktivních stabilizačních prvků (mg. cívek) rozhodně není nic jednoduchého a na poslední sobotní schůzce (10.9.2005) jsme proto aktivní systém orientace a stabilizace zařadili mezi experimenty
- řešení tohoto systému pro CubeSat budeme dále upřesňovat, takže nové nápady, algoritmy i výpočty jsou vítány
|
| 15.9.2005 - 19:40 - spook | |
|
no to byl jen takovej vyplod fantazie jak jen tak nahrubo natocit druzici.
k tomu:
>>spookův návrh na porovnávání odhadů rotace je mi bohužel nějak nesrozumitelný
no v podstate, by se podle drahy druzice(vypocitane z aktualniho casu) odhadlo jak ma byt druzice osvetlena a podle toho by se potom natocila. |
| 25.9.2005 - 20:30 - spook | |
|
citace:
Mel bych prosbu.
Pro SW pro simulaci pohybu a stabilizace satelitu a alespon nejakou vizualizaci bych potreboval data o zemskem povrchu.
Textury povrchu bych mel, i kdyz netusim, kdo je vlastnikem jejich copyrightu.
Souradnice mest a mist take, ty jsou snad zdarma.
Pomohlo by mi, pokud byste nekdo mel databazi souradnic bodu ohranicujicich kontinenty, pripadne dalsi zajimava geo-data, ktera by bylo dobre vizualizovat.
Narazil jsem na netu na prográmek Globus 1.0 od od Tomáše Hanzáka. Tento prográmek obsahuje víc jak 4000 zeměpisných souřadnic měst po celé Zemi. Prográmek je volně ke stažení na stránce: http://www.sweb.cz/thanzak/Download.htm kde zároveň autor píše:
Každý nechť s nimi nakládá ke své nejvyšší spokojenosti. ..... Pokud budete chtít některý můj program umístit na své CD či ho jinak hromadně šířit či propagovat, můžete tak klidně učinit. Pokud mi o tom dáte vědět, nebudu se zlobit.
snad se to bude hodit. Po dalších geodatech budu ještě pátrat, ale pomohlo by mi kdybych vědel jaký budou potřeba |
|
citace:
Měřila by se napětí ze solárních článků. Jednotlivé hodnoty by byly v procentech a vybraly by se tři největší hodnoty(mx. osvětlených stran) a podle nich by se určila zhruba poloha Slunce. ( tím způsobem že: 100% u jedné strany by znamenalo, že Slunce je tim směrem, kde je natočená strana družice ; u dvou sousedních stran po 50% by znamenalo, že je Slunce zhruba tam, kam ukazuje společná hrana těchto stran atd….)
Tohle nenapadlo jenom tebe :-)
Já bych rád napsal program pro palubní počítač (ať už bude ten počítač na bázi čehkoliv... nějaký tam snad bude, alespoň atmel), který by na základě srovnání osvětlení panelů a údajů určitého časovače (např. vždy na 10 oběhů dopředu) prováděl vhodné manévry se solání plachtou: pokud zhruba vím kde jsem, a zhruba vím odkud svítí slunce, tak z toho jednoznačně pomocí nějaké transformační funkce (nejspíš prostě nějkaé větší tabulky předem spočítaných hodnot.. :-) lze určit vhodné natočení plachet.
Zatím jsem ale ještě nezačal ani se simulátorem, který by simuloval osvětlení plachet během jednoho oběhu, a na kterém by moji transformační (navigační) tabulku poloh plachty vzhledem k čase a osvitu článků šlo testovat :-(
Představuu si to tak, že během např. 10-20 oběhů Země (jeden den) bude změna dráhy a oběžné doby minimální - takže stačí předvypočítat matrici navigačních hodnot na den dopředu, a další den (při dalším přeletu nad řídícím střediskem :-) se podle změřené/spočítané změny dráhy přenese rádiem zase nový program na dalších 24h. V případě, že se spojení nenaváže, se stejný program použije ještě po nějaký n-násobek původní předprogramované periody, a poté se přejde automaticky do režimu stabilizac ("svěšení" plachet) a bude se čekat na nejbližší rádiovou session.
Podle toho co zatím vím, by se mnou požadavaná transformační matice měla vejít i do jednočipového počítače Atmel, který má zároveň vestavěné A/D převodníky (takže to měření naětí článků by zvládal bez potřeby spolupráce s čímkoliv dalším...). Ale samozřejmě - pokud na palubě bude nějaké větší dělo,tak není důvod se omezovat na Atmel... :-) nevím v jakém stavu jsou práce na řídících obvodech, ale doufám, že se inspirují tou univerzitou, co nahoru prostě poslal PC s linuxem... kompletníé linux bych nahoře viděl samozřejmě nejradši... :-)
|
| 03.12.2005 - 09:49 - spook | |
|
citace:
Tohle nenapadlo jenom tebe :-)
?mozna ze jo, nebo jsem to kdysi davno nekde cet a proste sem si na to jenom vzpomel(nevim)
-taky by slo podle natoceni plachet odhadnout kam se druzice bude pohybovat(jenze by neexistovala zadna kontrola)
-nebo intenzitou osvetleni kontrolavat vzdalenostod od slunce
nejlepsi by imho bylo, kombinovat nekolik takovyhle(odhadnich) metod a pak je zprumerovat |
|
Ano - s tím, že víme, kam se při daném postavení plachet družice natočí, s tím se tiše počítá :-)
Ta vzdálenost od Slunce je podle mě neměřiteln... zatímco natočení vzhledem ke Slunci naopak snadno (odrazy slunečního světla od Země i Měsíce vygenerují na solárních panelech podle mě jen dost malé napětí...).
Žádnou velkou vzdálenost odnikud není moc potřeba měřit. Je poměrně jasné, kde CubeSaty jsou: na sun-synchronní polární dráze ve výšce 600km
nad Zemí. Tuto dráhu chceme zatím zvyšovat - jakékoliv další manévry (např. změna jejího sklonu, apod.) jsou hudba budoucnosti. Když měřitelně zvýšíme oběžnou dráhu o jakkoliv malý měřitelný kousek, řádově třeba jen o kilometry, tak jsme prozatím mistry světa v solárním plachtění.. a teprve pak má cenu vymýšlet nějaké "extended mission".
Ten realtimový výpočet nastavení plachet si představuju spíš o to, že během průletu nad osvětlenou částí Země musíme plachty neustále průběžně natáčet - abychom v libovolný okamžik zrychlovali, a ne brzdili. Zároveň ale musíme korigovat rotaci družice, která se bude neustále znovu objevovat, vlivem nepřesností jednotlivých plachet a lehce odlišných sil, které na ně budou působit. Zároveň ale trvalé spojení družice s řídícím střediskem nebudu možné zajistit - takže mě to vychází, že na palubě bude muset být přítomen nějaký velice jednoduchý deterministický algoritmus, který na základě vstupních dat ze šesti solárních panelů a časoväče bude vydávat jednoznačné pokyny servomotorkům.
Vychází mi to tak, že většina navigačního a simulačního softwaru bude (minimálně u tohohle testovacího modelu) na Zemi v řídícím středisku - prostě program na PC - a na družici se bude ze Země vysílat jenom jakýsi předvypočítaný a předzpracovaný "mikrokód", který počítá s tím, že my dole na Zemi víme, na jaké je družice dráze, a že my nejlíp víme, co je pro ni dobré. Rozhodování kam chceme letět se dělá tady na Zemi - tak není důvod dělat na Zemi i výpočty - zvlášť když odezva plachty bude daleko delší, než rádiové zpoždění při komunikaci se Zemí.
Mít na palubě kompletní navigační software, kterému se zadají souřadnice v prostoru a on spočítá jak tam nejlépe doletět - to by samozřejmě bylo krásné :-) ale pro nanosatelit mě to přijde nereálné a zbytečné.
No jinak ten simulační software bych asi fakt měl dodat - protože jak se tak nad tím zamýšlím, tak je to asi můj jediný možný přínos pro tenhle projekt... v podstatě nic jiné užitečného neumím.. jenom tlachat a trochu programovat :-/
|
|
Zdravim, xChaosi.
Ocenuji tvuj konstruktivni pristup. Jakakoliv pomoc v projektu bude vitana. Nasmeruj se pres Alese na koordinatora :-), ocekavame te tez na schuzce 14.1.
K technickym vecem:
Rizeni "na dalku" je sice realne, ale:
1) draha jednotlivych CubeSatu je skutecne priblizne sun-synchronni, ale lisi se pro jednotlive ejdnotky vypoustene v ramci jednoho startu, napriklad vyska drahy kolisa od 600 do rekneme 700 km.
2) satelit dostava pocatecni rotaci od vypousteciho mechanismu, kterou odhadujeme na cca 2-5 otacek za minutu, osa rotace je nahodna, ale zpocatku pevna (v ECI souradnicich)
3) vlivem vsech moznych vlivu a podobne dojde ke kyvum, precesi
4) pasivni stabilizace je nepresna a zdlouhava, pro efektivni manevrovani je treba trirozmerna stabilizace v ECIF, zatimco pro tether trirozmerna stabilizovana rotace v ECIF, tj. fizace v OF. To je s plachtou, domnivam se, castecne v rozporu.
5) aktivni stabilizace, ktera je k tomuto potreba, musi byt palubni, protoze efektivni radiove spojeni je mozne az po stabilizovani, do te doby je to zalezitost viry a stesti.
6) algoritmy a vlastni aktivni stabilizace (napr. pro magneticke korekcni zasahy) jsou experimentem samy o sobe :-) nevim zatim o CubeSatu, ktery by ji vyzkousel (nCube bohuzel selhal). Uvidime.
7) Pro palubni stabilizaci je (podle me, ale mohu se mylit) nutne mit na palube vsechnu tu souradnicovou vektorovou geometrii a vypocty. Pozemni stanice v tom nepomuze. Soucasti stabilizace je znalost pozice na draze, vektor ke Slunci ...
Suma sumarum
- ulohy stabilizace a rizeni plachty ve velmi prekryvaji
- na palube bude muset neco samostatne pocitajicicho byt
- pozemni stanice nam v tomto nepomuze
a abych byl uprimny, pripada mi tezsi ty algoritmy vymyslet (opsat) a matematicky podlozit, nez je posleze implementovat, treba i do palubnich mikrokontroleru (nebo Linuxu ) |
| 12.12.2005 - 19:43 - Maša | |
|
>- ulohy stabilizace a rizeni plachty ve velmi prekryvaji <
>- na palube bude muset neco samostatne pocitajicicho byt<
>- pozemni stanice nam v tomto nepomuze<
Přesně tak, řízení plachty je jen stabilizací družice jinými prostředky. Ovládací prvky jsou sice jiné, ale ta základní matematika volného setrvačníku zůstává společná.
Jinak opět a znovu opakuji, že na dráze kolem země nemá nic, kromě plně tříose řízené plachetnice cenu, zvláště ne na tak nízké dráze, která se stáčí každých patnáct vteřin o stupeň. (Je samozřejmě trochu sporné, jaký smysl má na takové dráze sama plachetnice.)
|
|
Vážení přátelé,
měl bych otázku, na kterou jsem zatím nenašel přesnou odpověď:
Při výpočtu dráhy satelitu se tato počítá v inerciální soustavě, jejíž základní osa je směr k jarnímu bodu, tj. do místa oblohy, kde je Slunce, když při své každoroční zdánlivé pouti přechází rovník z jihu na sever.
Poté se souřadnice satelitu převádějí do soustavy pevně spojené se Zemí, která vůči inerciální soustavě rotuje víceméně konstantní rychlostí, a to jedna otáčka za jeden hvězdný den.
Aby se dala transformace provést, je potřeba znát přesný úhel, o který jsou soustavy pootočeny. K tomu je třeba znát přesné místo na rovníku, kde došlo k okamžiku "jarní rovnodennosti", tj. Slunce bylo přesně v nadhlavníku.
Jak nebo z čeho toto místo zjistit ? Stačí pro jeden konkrétní rok, pro další rok je čas jasný, interval mezi rovnodennostmi je jeden tropický rok.
Možná se špatně ptám, může mi někdo z přítomných astronomů odpovědět nebo problém osvětlit ?
|
|
ze dvou nezavislych zdroju
jarní rovnodennost
20.3.2005 v 13:33:01 SEČ
20.3.2006 v 19:25:34 SEČ
Ten cas plati diky casovy pasmum presne pro 15°v.d. takze tim je dany jeden uhel natoceni tech dvou souradnych soustav. Jestli plati v realu uplne presne to, ze v te chvili Slunce je v zenitu na rovniku, nevim. |
|
Diky, ten cas 13.33.01 SEC jsem nasel tez, ale nevedel jsem, pro jakou zemepisnou delku PRESNE plati.
Cele casove pasmo ma jeden cas ... tj. jak ja to chapu, je tam neurcitost 360 / 24 = 15 stupnu v zemepisne delce, tj. plus minus 7.5 stupne.
Jinymi slovy, otazka zni: PRESNE v jaky cas byly kolem poledne 20.brezna 2005 srovnany (jako identicke) soustavy ECI a ECEF ?
Zatim tedy budu vychazet z teto casove znacky. |
|
Tento údaj: 20.3.2006 19h25m SEČ je uveden ve Hvězdářské ročence 2006. Ta je počítána pro 15°, v tu dobu by se sluce mělo nacházet nad rovníkem. Bod jarní rovnodennosti je bod křížení rovníku Země a ekliptiky (zdánlivé dráhy slunce po obloze).
V ročence je hromada dalších údajů o Slunci, Měsíci, planetách i meteoritech atp. a i něco málo teorie. |
|
citace:
Tento údaj: 20.3.2006 19h25m SEČ je uveden ve Hvězdářské ročence 2006. Ta je počítána pro 15°, v tu dobu by se sluce mělo nacházet nad
Dekuji, klicova je informace, ze tento presny cas plati presne pro polednik 15 stupnu vychodni delky. |
|
