Témata: Výpočty

Michal_x - 6/7/2005 - 11:29

Ahoj!

Abych se Vám představil. Je mi 16 a studuji SPŠS ve Vsetíně. Jsem přiměřený fanda kosmonatiky a velmi mě zajímá projekt CubeSat.
Nebudu tady dělat ze sebe chytráka, ale zkoušel jsem číst některé Vaše diskuse a abych pravdu řekl rozuměl jsem maximálně 1/3 o čem jste mluvili. A proto se chci zeptat jestli budou za potřeba nějaké výpočty. Strašně rád bych Vám pomohl...


Marian Vana - 6/7/2005 - 20:35

quote:
Ahoj!

Abych se Vám představil. Je mi 16 a studuji SPŠS ve Vsetíně. Jsem přiměřený fanda kosmonatiky a velmi mě zajímá projekt CubeSat.
Nebudu tady dělat ze sebe chytráka, ale zkoušel jsem číst některé Vaše diskuse a abych pravdu řekl rozuměl jsem maximálně 1/3 o čem jste mluvili. A proto se chci zeptat jestli budou za potřeba nějaké výpočty. Strašně rád bych Vám pomohl...


Je zapotřebí vypracovat algoritmus (počítačový program) pro průběžné určování polohy družice na základě měření zemského magnetického pole. To jest určit sklon družice k siločarám zemského magnetického v každé ose (x,y,z) zvlášť a na základě měření časových změn jednotlivých složek pole (Bx, By, Bz) určovat i okamžitou rychlost a směr rotace družice. Taktéž je zapotřebí určovat i absolutní polohu družice vůči Zemi, tj. zeměpisnou šířku a délku a vzdálenost od Země tj. středu nebo povrchu. Snad bude vhodné použít přesný geomagnetický model Země (viz např. http://nssdc.gsfc.nasa.gov/space/model/models/igrf.html
). Vývoj algoritmu lze rozdělit do jednotlivých etap a úkolů. Máš-li zájem a věříš si ozvi se mi na info@emp-centauri.cz.

P.S. e-mail mi teď pár dní nefunguje kvůli technickým problémům a přechodu na ADSL ale to bude za pár dní v pořádku.


leemer - 6/7/2005 - 20:52

quote:
Ahoj!

Abych se Vám představil. Je mi 16 a studuji SPŠS ve Vsetíně. Jsem přiměřený fanda kosmonatiky a velmi mě zajímá projekt CubeSat.
Nebudu tady dělat ze sebe chytráka, ale zkoušel jsem číst některé Vaše diskuse a abych pravdu řekl rozuměl jsem maximálně 1/3 o čem jste mluvili. A proto se chci zeptat jestli budou za potřeba nějaké výpočty. Strašně rád bych Vám pomohl...


Pokud se chces i jinak zapojit do deni kolem kosmonautiky, tak se stav ve ctvrtek dopoledne (10:00 - 12:00) nebo odpoledne (13:30 - 16:00) ci v patek vecer (19:00 - 24:00) na Hvezdarnu Vsetin :-)

Na setkani se tesi Vaclavik Michal


Michal_x - 7/7/2005 - 18:05

quote:
quote:
Ahoj!

Abych se Vám představil. Je mi 16 a studuji SPŠS ve Vsetíně. Jsem přiměřený fanda kosmonatiky a velmi mě zajímá projekt CubeSat.
Nebudu tady dělat ze sebe chytráka, ale zkoušel jsem číst některé Vaše diskuse a abych pravdu řekl rozuměl jsem maximálně 1/3 o čem jste mluvili. A proto se chci zeptat jestli budou za potřeba nějaké výpočty. Strašně rád bych Vám pomohl...


Je zapotřebí vypracovat algoritmus (počítačový program) pro průběžné určování polohy družice na základě měření zemského magnetického pole. To jest určit sklon družice k siločarám zemského magnetického v každé ose (x,y,z) zvlášť a na základě měření časových změn jednotlivých složek pole (Bx, By, Bz) určovat i okamžitou rychlost a směr rotace družice. Taktéž je zapotřebí určovat i absolutní polohu družice vůči Zemi, tj. zeměpisnou šířku a délku a vzdálenost od Země tj. středu nebo povrchu. Snad bude vhodné použít přesný geomagnetický model Země (viz např. http://nssdc.gsfc.nasa.gov/space/model/models/igrf.html
). Vývoj algoritmu lze rozdělit do jednotlivých etap a úkolů. Máš-li zájem a věříš si ozvi se mi na info@emp-centauri.cz.

P.S. e-mail mi teď pár dní nefunguje kvůli technickým problémům a přechodu na ADSL ale to bude za pár dní v pořádku.




Ok, existuje na to nějaký program nebo se bude muset udělat?


Marian Vana - 7/7/2005 - 20:03

Program zatím neexistuje a je jej samozřejmě zapotřebí vypiplat a odladit. Něco málo je už připraveno, hlavně Hardwarové zapojení je v podstatě dané.
E-mail mi už funguje, pošlu Vám v nejbližších dnech bližší informace když budu vědět kontakt (e-mail). Taktéž o nosné konstrukci (rámu).


Michal Pavelka - 8/7/2005 - 17:26

quote:
Program zatím neexistuje a je jej samozřejmě zapotřebí vypiplat a odladit. Něco málo je už připraveno, hlavně Hardwarové zapojení je v podstatě dané.
E-mail mi už funguje, pošlu Vám v nejbližších dnech bližší informace když budu vědět kontakt (e-mail). Taktéž o nosné konstrukci (rámu).


Můj e-mail je misa.vs@centrum.cz


spook - 10/7/2005 - 22:50

jj, ja bych se taky rad podilel na stavbe CubeSatu ale jako stavař se zajmem o PC a vseho co se tyka vesmiru, nemam potrebne znalosti

takze mi nezbejva nic jineho nez sledovat tuhle diskuzi a tise zavidet chytrost ostatnim

no ale napada me, teda jestli mate vyresenej HW, ze by to slo resit treba ceckem? teda jestli to neni nejaka blbost

jinak kdysi jsem narazil na tuhle stranku treba by se dalo neco pouzit: http://nebmech.astronomy.cz/VYPOCTY/vypocty.htm


Marian Vana - 12/7/2005 - 18:28




Můj e-mail je misa.vs@centrum.cz


Prosím ještě o pár dní strpení než s kolegy dovyjasníme některé problémy, viz diskuse na téma "konstrukce satelitu".


Marian Vana - 12/7/2005 - 18:30

quote:
jj, ja bych se taky rad podilel na stavbe CubeSatu ale jako stavař se zajmem o PC a vseho co se tyka vesmiru, nemam potrebne znalosti



Třeba právě jako stavař se znalostmi zeměměřičství by jste nám mohl pomoci s určováním polohy družice? My také nemáme mnohé potřebné znalosti, tak si je prostě musíme doplnit nebo to jinak dohnat.


spook - 12/7/2005 - 19:28

tak to me nenapadlo ze bych moch vyuzit geodezii. a jestli by to stacilo v C-cku tak bych moh nejakou tu funkci na to napsat(teda aspon doufam)


Wartex - 13/7/2005 - 11:28

quote:
tak to me nenapadlo ze bych moch vyuzit geodezii. a jestli by to stacilo v C-cku tak bych moh nejakou tu funkci na to napsat(teda aspon doufam)


S programovanim se nezatezujte, od toho tu jsou jini :-)
Prozatim staci, kdyz vymyslite vzorce na vypocet zemepisnych souradnic kolmeho prumetu kruzice na povrch v case.


spook - 14/7/2005 - 11:51

quote:
Prozatim staci, kdyz vymyslite vzorce na vypocet zemepisnych souradnic kolmeho prumetu kruzice na povrch v case.


?

tak tohle jsem asi nepochopil. jetli myslite dve pomyslne (soustredne) koule z nichz jedna je Zeme a druha je urcena polohou sondy a zaroven znate souradnice na kouli urcene sondou, pak prumet na Zemi bude jednoduchy. => uhly zustanou stejne a potrebne vzdalenosti budou primo umerne pomeru polomeru_Zeme/polomeru_myslene_koule

ale takhle jste to asi nemyslel.
Potreboval bych spiz znat (obcne)hodnoty pri zacatku vypoctu. (ty konecne hodnoty, teda jestli to chapu dobre, budou zemepisna vyska a sirka)


Archimedes - 15/7/2005 - 12:43

Vratil jsem se ze staze v Nemecku, takze se zas pustim do pokracovani na (zatim) jednoduchem programu pro simulaci stabilizace. Zkusim do toho zapracovat model geomagnetickeho pole z toho odkazu z NASA.


ales - 15/7/2005 - 18:28

Vrátím se ještě k výpočtům polohy družice. To, co opravdu potřebujeme, je vědět, kde je Země (pro směrování komunikace), kde je Slunce (pro napájení a případně pro sluneční plachtu) a také, kde jsme na dráze (pro časování komunikace).

Doufám, že to, kde jsme na dráze, můžeme zjistit z reálného času a předpokládané dráhy prostou tabulkou poloh (časů komunikačních oken) v závislosti na čase.

To, kde je Slunce, snad zjistíme měřením napětí solárních článků na různých stranách družice.

Zjistit, kterým směrem je Země, je pro mne v tuto chvíli nejobtížnější. Snad by to mohlo jít odvodit z měření mg. pole ve třech osách. Vidím to tedy tak, že potřebujeme algoritmus, který z polohy na dráze (odvozené z reálného času) a z hodnot mg. pole ve třech kolmých osách vypočítá, kterým směrem je Země (kde je směr "dolů"). Možná by to dokonce šlo zjistit i bez znalosti polohy na dráze? Ten, kdo pro toto navrhne (popíše) co nejjednodušší (nejsnáze naprogramovatelný) algoritmus, by stavbě družice opravdu pomohl :)

Ještě jednou to shrnu:
- máme hodnoty mg. pole Země ve třech osách (určené osy družice)
- máme souřadnice polohy na dráze (třeba sklon, argument perigea a čas od perigea)
- vypočítejte z těchto hodnot, kterým směrem je Země? (vzhledem k určeným osám družice)

Alternativní možností je navrhnout, jak jinak (co nejsnáze) zjistit výše uvedené hodnoty (kde je Země? kde je Slunce? kde jsme na dráze?)

P.S.: Jiné potřebné výpočty jsou např. ty pro stabilizaci družice, kterým se věnuje Archimedes. Pokud ale někdo další chce a může pomoci, tak ať se ozve.


Wartex - 15/7/2005 - 23:55

Predpokladejme nasledujici postup:
- civky prepneme procesor hardwarove do rezimu snimani indukovanych napeti
- procesor provede mereni hodnot napeti ve vsech civkach, a to po dobu nekolika sekund (rekneme pro zacatek 3s) s frekvenci alespon par desitek vzorku za sekundu

- ziskame tri casove rady po cca 100-200 vzorcich

- na techto casovych radach aplikujeme harmonickou analyzu (FFT)

- ziskame typickou vyraznou hodnotu frekvence, to bude frekvence rotace v prislusne ose

- podobny algoritmus lze aplikovat na hodnoty proudu z fotoclanku na stenach, frekvence by mely byt shodne, smery ke Slunci a smer mag. pole muzeme v nejakem kratkem intervalu (par sekund) povazovat za konstantni.

- zahajime aktivni stabilizaci, a to tak, ze do civky nutime silny proud souhlasny s proudem samocinne indukovanym (indukovany proud se sam snazi civku stabilizovat).

- stridame fazi mereni a aktivni stabilizace, a to tak, abychom mohli vzdy naplanovat aktivni zasah dopredu. Toto by melo podle meho nazoru fungovat nezavisle na okamzitem smeru vnejsiho pole.

- v prubehu jednotlivych vyhodnocovacich fazi by se mela snizovat frekvence rotace v jednotlivych osach.

- zaroven by se mela snizovat frekvence kmitu hodnot proudu z fotoclanku na stenach.

- Kdyz poklesne dostatecne malo, abychom mohli povazovat druzici za triose stabilizovanou pro ucely mereni, provedeme mereni hodnot slozek pole, bud nezavislym magnetometrem, nebo vyuzit dopredneho pohybu a merit napeti indukovane na nejakem primem dlouhem vodici.

- Z toho bychom vypocitali hodnoty slozek vnejsiho pole a tim i celkovy vektor vnejsiho pole.

- Tento vektor vnejsiho pole bychom pocitali periodicky, kazdych 30 sekund, po dobu cca 25 minut, to je zhruba ctvrtina obehu. Z teto sekvence hodnot by mela jit, podle zabudovaneho modelu pole Zeme, urcit zhruba trajektorie, tedy sklon drahy (ktera by mela byt predem znama) a vystrednost (ktera by mela byt co nejmensi).

- Jakmile zna druzice svou trajektorii, muze synchronizovat svuj vnitrni cas ... atd.


Marian Vana - 16/7/2005 - 08:58

Rozumím-li tomu dobře, předpokládá se že nejkratší perioda rotace družice bude výrazně delší než několik sekund. V případě nějaké rychlejší rotace by uvedený postup nefungoval (?).

Tento navržený postup můžeme vzít jako první základ pro další rozpracování. Tento navržený postup funguje tak že družice se stále snaží nerotovat popř. nekývat vůči siločarám zemského mag.pole (opravte mne jestli se mýlím). Určitý pohyb družice vůči siločarám je ale žádoucí. Nad zemskými póly by měla být družice orientována vůči siločarám o 90° jinak nežli na rovníku, tedy za zhruba 25 minut se musí pootočit o 90°. Pro aktivní stabilizaci je podle mne třeba měřit nejen indukované napětí v cívkách (rychlost kyvů nebo rotace družice vůči zemskému mag. poli) ale i hodnoty jednotlivých složek pole (Bx, By, Bz) a výsledné korekční akce provádět v závislosti na obou změřených veličinách. Neboli :
Tc = -K1 W - K2 dW/dt
Tc je korekční akce úměrná součinu velikosti korekční síly a času po kterou bude korekční akce prováděna
K1, K2 jsou korekční konstanty které budeme muset stanovit (spočítat)
W je chybový (nežádoucí) úhel o který je družice natočena vůči siločarám oproti (správnému) požadovanému úhlu (požadovaný úhel je např. 90° nad rovníkem, 0°nad póly, 40°nad územím ČR, atd.)
dW/dt je časová derivace chybového úhlu (pozor, nejedná se tedy o časovou derivaci sklonu družice k siločarám ale možná ji bude moci při zjednodušení použít)
Myslím že tenhle postup se odborně nazývá PD kontroler (position plus derivative).
Dále, nebylo by vhodnější nežli měřit napětí indukované na cívkách a odtud odvozovat rychlost rotace nebo kyvů, měřit změny zemského magnetického pole v jednotlivých osách x,y,z přímo pomocí magnetických čidel a rozdílu časů? Mám totiž obavy že by se do přesnosti měření pomocí induk. napětí na cívkách mohli míchat další nežádoucí jevy jako např. již dříve zmiňované indukované napětí vlivem rychlosti družice (cca 7km/sec) a nehomogennity zemského mag. pole.


Wartex - 16/7/2005 - 10:06

Absolutni casy jsem uvadel pro predstavu, samozrejme pri rychle rotaci by bylo nutno prizpusobit frekvenci vzorkovani, pri pomale rotaci zase je podstatnejsi doba vzorkovani. Tohle vsechno si ale procesor muze volit, takze zrejme udelame nejakou heuristiku, kdy nejprve nahrubo zkusime "jak na tom jsme" a pak zvolime spravne frekvence a casy.

Druzice musi vedet svou polohu na draze a take to, kde nad povrchem prave proleta. Z toho teprve muze odvodit zadany uhel natoceni vuci silocaram, z magnetometru nebo civek aktualni mereny uhel natoceni
a tim ziskat podklady pro aktivni regulaci uhlu.

Jaky to bude presne typ regulatoru a jake by mel mit ridici konstanty, by bylo nejlepsi zjistit simulaci. Na tom pracuji. K tomu je treba mit dost dobry model satelitu a pohybovych rovnic. Intenzivne studuju mechaniku tuheho telesa, ale potreboval bych v tomto trochu pomoci


Marian Vana - 17/7/2005 - 15:14

Mohu zapůjčit nějakou literaturu ohledně dynamiky a řízení polohy satelitů, něco z toho by mohlo být užitečné. Ale tak na pár týdnů, pak bych to potřeboval vrátit.


Honza Mocek - 18/7/2005 - 07:49

Pokud bude frekvence vzorkování (v režimu zjišťování polohy) menší než perioda rotace družice, nebo i srovnatelná, dojde k tzv. aliasingu a FFT bude dávat ujeté výsledky. Např. pokud bude perioda rotace 5 sekund a snímání "shodou okolností" taky, tak se střední hodnoty budou jevit stejné, jako kdyby družice byla v klidu, ale pokud bude snímač "samplovat" vzorku po 5,5 sekundě tak bude zdánlivá perioda 50 sekund a při frekvenci snímání 4,5 taky ale v opačném směru.

Analogie pro humanitně=netechnicky zaměřené: každých 23 hodin juknu z okna na oblohu a co nevidím: slunce vychází na západě a zapadá ne východě, oblohou jde zprava do leva /sev. polokoule/ a trvá mu to 24 dní...!


Wartex - 18/7/2005 - 08:41

Samozrejme mate pravdu, Honzo, to je trivialni uvaha.

Proto uvazuji o tom, ze nejprve probehne heuristicka "zkouska", jak na tom jsme zhruba, ve kterych radech se rotace prave pohybuje.

K tomu se udela nekolik pokusnych mericich sad, pokazde s diametralne odlisnou vzorkovaci periodou.


Wartex - 18/7/2005 - 10:08

quote:
Mohu zapůjčit nějakou literaturu ohledně dynamiky a řízení polohy satelitů, něco z toho by mohlo být užitečné. Ale tak na pár týdnů, pak bych to potřeboval vrátit.



to je velkorysa nabidka ... kterou okamzite prijimam :-) pisu vam mail.

neni nejaka cesta, jak to sdilet elektronicky ? pokud to neni prilis mnoho stran ?


Archimedes - 18/7/2005 - 13:38

quote:
Mohu zapůjčit nějakou literaturu ohledně dynamiky a řízení polohy satelitů, něco z toho by mohlo být užitečné. Ale tak na pár týdnů, pak bych to potřeboval vrátit.
Taky bych se na to rad podival. Kolik toho cca je? Idealni by bylo naskenovat alespon ty podstatne pasaze do PDF. V praci skener mame, takze bych tomu i nejaky cas obetoval.


Marian Vana - 18/7/2005 - 17:32

Raději bych to poslal poštou. Nerad bych to kopíroval a porušoval autorský zákon. Zákony této země se mi sice vůbec nelíbí, ale zákon je zákon. Mohu to poslat Wartexovi a on pak Tobě jestli souhlasíš.


Marian Vana - 18/7/2005 - 17:38

Mohu poslat tyto knihy:
Marcel J.Sidi: Spacecraft Dynamics and Control
Charles D. Brown: Elements of Spacecraft Design.


Wartex - 22/7/2005 - 10:40

Dekuji, Mariane, za knizky. Je to skutecne poklad, informace a postupy, ktere jsem se pokousel dat postupne dohromady z mechaniky tuheho telesa, jsou tu proste skoro hotove.

Nas satelit je totiz v podstate setrvacnik s volnou osou, na ktery pusobi soustava casove promennych vnejsich sil. To je patrne z hlediska analyzy a simulace jeden z nejslozitejsich pripadu. Vysledkem je totiz casove promenny precesni pohyb, nic jednoducheho. Na obecne analyticke reseni muzeme zapomenout rovnou (to jsem popravde ani nepredpokladal).

Kazdopadne pro ucely verohodne simulace bude nutne znat rozlozeni hmoty v telese satelitu, aby se dal vypocist moment setrvacnosti vzhledem k libovolne ose.

Tohle rozlozeni by se nemelo s casem menit, takze musime uvnitr vsechno dobre upevnit, aby se to pri startu nehnulo, ruzne cancoury a kabely a podobne :-) Kdyz se bude trochu menit, nevadi, s tim by se mel vyporadat regulator, ale nesmi se zmenit podstatne, to by totiz ovlivnilo parametry regulatoru a ty, prepokladam, by mely byt predem nastaveny uz ze Zeme.

Volny setrvacnik ma prirozenou osu rotace kolem osy s nejvetsim nebo nejmensim momentem setrvacnosti. Je nejaky predpoklad o tom, jak vypada vlastni vypusteni satelitu CubeSat ? Jakou zhruba pocatecni rotaci bude mit ? Zhruba rozsah uhlovych rychlosti ?

Chceme vlastne stabilizaci ve 2 nebo 3 osach ? Tri osy jsou dokonalost sama, ale pak se to z jedne strany porad opeka Sluncem. Dve osy (tj. rotujici kostka s osou rotace smerujici do stredu Zeme) umozni dobrou komunikaci a zajisti dobry teplotni rezim. Jaky na to mate nazor ? Samozrejme pro dosazeni obou techto stavu ELMAG stabilizaci je treba mit vsechny tri civky.

Myslim, ze jsme se shodli na tom, ze cilem tohoto prvniho satelitu je udelat stabilizovanou komunikujici druzici s experimentem, v tomto pripade tetherem. Pro tether by snad stacila stabilizace ve 2 osach, nebo se mylim ?


Marian Vana - 23/7/2005 - 13:41

"Je nejaky predpoklad o tom, jak vypada vlastni vypusteni satelitu CubeSat ? Jakou zhruba pocatecni rotaci bude mit ? Zhruba rozsah uhlovych rychlosti ? "

Nedokáži přesně odpověď. Snad by někdo šlo sehnat o tomto informace. Vzájemné odpoutání jednotlivých Cubesatů od sebe a od P-Podu, tj. přepravního obalu, je zajištěno pomocí pružin jež jsou součástí nosné konstrukce. Na standartním Cubesatu včetně našeho jsou 2 tyto pružiny vzdálené od sebe úhlopříčně asi 140mm. Síla každé pružiny je typicky 0.5 až 1libra, tj. přibližně 2-4N. Při nepřesném seřízení (nastavení) obou pružin ,můžeme předpokládat rozdíl v silách maximálně tak 1N, tato síla působí při vypuštění družice po dráze asi 1mm, odtud mi vychází maximální rychlost rotace asi 1 otáčka za 10sec. Když tak mne překontrolujte. Jak je to ale v případě odpoutání P-PODu od mateřského tělesa nevím.

Dal bych přednost stabilizaci družice ve 3 osách. Pro vlastní vysunutí tetheru by to bylo jistější. U samotného tetheru po vysunutí předpokládám stabilizaci jednak gradientem gravitačního pole a jednak silovým působením zemského mag. pole na vodič protékaný proudem (tedy v podstatě tříosá stabilizace), pak by měl tether dostatečně stabilizovat i samotnou kostku. Pokud bude po vysunutí tetheru ještě fungovat i stabilizace samotné kostky pomocí 3 cívek, nebude to na závadu i když se budou tether s kostkou trochu "přetahovat".
Před vysunutím tetheru, při stabilizaci kostky ve 3 osách, je sice část kostky dlouhodobě na Slunci ale vzhledem k velmi malým rozměrům kostky a dobré tepelné vodivosti hliníku jakožto nosné konstrukce by to nemělo vyvolat drastické rozdíly teplot mezi jednotlivými částmi kostky v daném okamžiku, vychází mi to , byť přibližně, do asi 10-20s stupňů, viz také analýza v souboru druzice.doc.

Co se týče přesnosti stabilizace kostky, je otázka zda je nutné stabilizovat družici s přesností nějakých cca 10-20°nebo lepší, nebo postačí stabilizace pouze souhlasně se siločarami magnetického pole. Ta druhá stabilizace by určitě vyžadovala jednodušší algoritmus a v podstatě by asi stačilo sledovat napětí indukované v cívkách vlivem kývání nebo rotace kostky a snažit se jej minimalizovat, jak jsi myslím navrhoval Ty Wartexi (nabízím tykání pokud možno). Pro anténu by to asi stačilo a pro tether snad (?) také. Každopádně si myslím že nějaká rychlejší rotace družice okolo osy družice-střed Země, dejme tomu 1 otáčka za 10sec. a rychlejší, by mohl být pro vysunutí tetheru problém.


Marian Vana - 23/7/2005 - 14:17

Co se týče momentů setrvačnosti kostky v jednotlivých osách, je předpoklad že bude největší okolo os X a Y, je-li ve směru osy Z družice nejdelší (113mm).Podél směru osy Z také předpokládám rozmístění složeného tetheru uvnitř v kostce a jeho vysunutí by se mělo uskutečnit směrem od kostky také v ose Z. Vysunutí mechanismu bude do vzdálenosti nějakých 5-10 metrů od kostky, možná ještě o něco více, poté by se měla vysunout obě ramena tetheru do stran každé o délce nějakých 3 až 5 metrů. po rozvinutí tetheru by tento měl mít v podstatě tvar písmene T:

plazmový kontaktor I-----------střed----------plazmový kontaktor II
!
!
!
!
!
!
!
!
!
!
!
!
!
kostka
(mateřské těleso)

!
!
\!/
směr k Zemi

Vzhledem k hmotnosti tetheru (200-400gramů) dojde tedy po jeho vysunutí k podstatným změnám momentů okolo os X,Y, moment okolo osy Z se změní také postatně ale o něco méně.
Jinak si myslím že pro stabiliazci pomocí cívek ve 2ou nebo 3osách bychom nemuseli znát jednotlivé momenty setrvačnosti kostky až tak přesně, tedy že by měla stačit přesnost např. 50% až 200% skutečné hodnoty momentů. Budeme-li korekční akce provádět dostatečně často (řekněme alespoň 5 korekčních akcí pro každou osu a 5 následných měření po dobu jednoho kyvu kostky nebo periody rotace kostky) tak se kostka musí dříve či později ustabilizovat tak jako tak. Ale možná že mi něco uniká.
Zatím má kostka asi 400gramů. Největší rozložení hmotnosti je po obvodu (povrchu) kostky. Pochopitelně, neboť vnitřek je zatím téměř prázdný.


Marian Vana - 23/7/2005 - 14:20

No, tak ten obrázek v předešlém příspěvku se mi příliš nepovedl. Svislá osa s vykřičníky má mířit do "středu" aby to celkově tvořilo písmeno T.


Wartex - 23/7/2005 - 23:00

quote:
vychází maximální rychlost rotace asi 1 otáčka za 10sec. Když tak mne překontrolujte. Jak je to ale v případě odpoutání P-PODu od mateřského tělesa nevím.


Je-li usporadani tak, jak popisujes, pak by mela osa pocatecni rotace priblizne prochazet spojnici dvou uhlopricne protilehlych stran a stredem krychle. To neni urcite osa s nejvetsim momentem, takze deviacni momenty budou nejake a kostka se postupne rozkyve.

Nicmene, pokud jde o frekvenci, prepocitaval jsem to, prace pruziny je 10-3 J, moment setrvacnosti homogenne huste kostky vuci teto ose mi vysel nejakych 1.67.10-3 kg.m2 (numericky), takze omega=cca 1rad/s takze frekvence rotace cca 0.17 Hz, to je otacka za 6 sekund, takze jako nejhorsi pripad bych bral otacku za zhruba 3 sekundy, coz mi pripada slusne. Vychazelo ti to, Mariane, nejak podobne ?

Jeste k te stabilizaci, tam jsem nepresne zformuloval tu 2osou. Rotujici druzice se bude az na nezbytnou precesi chovat v zasade jako setrvacnik, takze jeji osa bude, v souradnem systemu spojenem s hvezdami, udrzovat konstantni smer, coz vubec neznamena, ze by smerovala stale do stredu Zeme, bude ukazovat stale na tutez hvezdu.


Wartex - 23/7/2005 - 23:25

Ono to, Mariane, s tou stabilizaci je vubec dost komplikovane. Jestli jsem spravne pochopil obrazek, je treba, aby byla druzice stale orientovana jednou stranou, protilehlou k tetheru, smerem k Zemi. To ovsem neni stabilizovany objekt, ale objekt s vazanou rotaci, neco jako Mesic (ten nam taky ukazuje prakticky stale stejnou tvar). Cili bychom vlastne potrebovali, aby druzice vykonala kolem osy Y (predpokladam, ze si rozumime stran souradnic, X ve smeru letu, Z smerem do stredu Zeme, Y kolme na obe, pravotocivy system) za dobu obehu (1h 30min) jednu celou obratku. Rovnomernou.

To, cemu bych rikal stabilizace, znamena, ze po uvolneni z nosice se bude druzice snazit minimalizovat amplitudy vln indukovanych napeti v civkach. To neznamena, ze se zorientuje do konstantniho uhlu proti silocaram ! To znamena to, ze nebude rotovat kolem zadne osy a vuci hvezdam zaujme konstantni polohu (napr. kazda jeji hrana bude ukazovat do stejneho mista na obloze).

I po tomto zorientovani se samozrejme jeste v civkach bude indukovat napeti, dane zmenou orientace civek vuci externimu poli, castecne diky obehu a konstantni pozici, castecne diky promennemu externimu mag. poli, kterym proleta. Toto napeti ale uz nebude mit z hlediska harm. analyzy vyrazne frekvence nekde mezi 0.05-1 Hz. Jak dlouho tato faze potrva, to je prave otazka, nepochybne to zavisi na regulatoru a hodnotach proudu, ktere bude mozne do civek nutit.

Myslim a tusim, ze rozliseni mereni a rusive vlivy nam neumozni rozlisit nizke hodnoty otacek, tak bych se oprel jeste o mereni proudu ze solarnich clanku. Ty by z hlediska otacek mely generovat podobne periodickou zavislost jako indukovana napeti a harmonicka analyza by v nich mela odhalit tytez frekvence, ale nezavisle na externim mag. poli.

Co vlastne ten tether potrebuje ? Jakou presne pozici a orientaci satelitu ?


Marian Vana - 25/7/2005 - 22:40

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.


Wartex - 18/8/2005 - 11:04

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.


spook - 11/9/2005 - 12:11

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)


Wartex - 12/9/2005 - 07:43

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 ...


Véna - 13/9/2005 - 09:04

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 ...


ales - 13/9/2005 - 16:57

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


spook - 15/9/2005 - 19:40

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.


spook - 25/9/2005 - 20:30

quote:
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


xchaos - 2/12/2005 - 13:56

quote:

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... :-)


spook - 3/12/2005 - 09:49

quote:
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


xchaos - 9/12/2005 - 12:50

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 :-/


Wartex - 9/12/2005 - 14:06

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 )


Maša - 12/12/2005 - 19:43

>- 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.)


Wartex - 16/1/2006 - 08:17

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 ?


Archimedes - 16/1/2006 - 10:53

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.


Wartex - 16/1/2006 - 14:30

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.


Bejcek - 17/1/2006 - 11:10


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.


Wartex - 17/1/2006 - 14:10

quote:

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.


Toto téma přichází z:
http://www.kosmo.cz

Url tohoto webu:
http://www.kosmo.cz/modules.php?op=modload&name=XForum&file=print&fid=5&tid=768