Evropská kosmická agentura má za sebou výrazný pokrok ve vyšetřování anomálie, která postihla 19. října přistávací modul EDM známý též jako Schiaparelli. Slovo anomálie je ve skutečnosti pouze eufemismem pro závadu, která nakonec vedla k havárii. Odborníci se při hledání příčiny museli probírat velkým množstvím údajů. Pozitivní je, že při analýze všech nasbíraných údajů zjistili, že modul pracoval velmi dobře ve fázích vstupu do atmosféry i hlavního brzdícího manévru.
Nyní již bezpečně víme, že k vystřelení padáku došlo přesně podle plánu ve výšce 12 kilometrů při rychlosti sestupu 1730 km/h, tedy ve správnou chvíli, která se očekávala. Již nepotřebný tepelný štít byl odhozen také podle plánu – když byla sestava 7,8 kilometru nad povrchem Marsu. Modul EDM byl stále připojený k horní části ochranného pouzdra, ze kterého se uvolnil padák. Po odhození štítu se aktivoval výškoměr na principu Dopplerovského radaru, který podle všeho pracoval správně. Data z něj byla úspěšně zpracována řídícím, navigačním a kontrolním systémem.
Zdroj: http://www.esa.int/
Problém ale s největší pravděpodobností nastal někde jinde. Jednotka IMU (Inertial Measurement Unit) dosáhla maximální saturace v ose Z krátce po vystřelení padáku. To znamená, že jednotka dosáhla maximálních měřitelných hodnot. IMU zodpovídá za měření úrovní rotace tělesa ve všech třech jeho osách, jedná se v podstatě o gyroskopy. Výstup z této jednotky byl po celou dobu konzistentní vyjma této jedné události, která trvala déle, než se čekalo – zhruba jednu sekundu. Bližší informace o jednotkách IMU na modulu EDM najdeme v tomto díle našeho seriálu Pohled pod kůži.
Jakmile se tyto informace dostaly do navigačního systému došlo k vygenerování chybné informace, která spočívala v negativní výšce, tedy pod úrovni terénu. V tu chvíli zmatený řídící systém předčasně uvolnil modul od ochranného pouzdra a padáku. Systém měl ještě zakódováno, že se po oddělení mají spustit brzdící motory, k čemuž skutečně došlo. Kvůli zmateným údajům o výšce se ale motory po chvilce vypnuly, aby mohlo dojít k finální fázi přistání – volnému pádu z výšky 150 – 200 centimetrů. Problém spočíval v tom, že modul se v té době nacházel ve výšce 3,7 kilometru.
Zdroj: http://planetary.s3.amazonaws.com/
Za havárii většinou může buďto souhra nešťastných okolností (jako v případě ztráty japonského teleskopu Hitomi), nebo jde o drobnou závadu v celém neskutečně komplexním systému. Dopplerovský radar, který byl terčem mnoha internetových spekulací tak podle všeho pracoval správně a kdyby modul spoléhal pouze na něj, nemělo by jej co zmást. Ale takhle to bohužel nefunguje. Radar sice poskytoval informace o výšce, ale modul při sestupu potřeboval i údaje o náklonu, který měla zajistit právě IMU.
Sešly se tak dvě základní chyby – maximální saturace IMU a možná trochu přecitlivělý systém, který si neporadil se sekundovou abnormalitou. Setkaly se tedy dvě na první pohled drobné chyby – jedna rázu elektronicko-mechanického a druhá spíše softwarová. Před techniky nyní bude stát výzva – odhalit proč přesně k této závadě došlo. Proč se IMU maximálně saturovala a proč řídící systém reagoval tak, jak reagoval. Jedině když se ESA z chyb poučí, nebude ztráta modulu EDM zbytečná. Schiaparelli byl od začátku technologický demonstrátor, který měl ověřit technologie pro přistání na Marsu. I když se mu to nepovedlo, může nám prozradit, co přesně bylo špatně a čeho je potřeba se vyvarovat.
Zdroj: http://planetary.s3.amazonaws.com/
Vyšetřovací týmy jsou si proběhem události již téměř jisté. Vše do detailu nasimulovali na počítačích a výše popsaný scénář přesně odpovídá nasbíraným údajům. „Jedná se o předběžné závěry našeho technického vyšetřování,“ zůstává opatrný David Parker, který v ESA zastává funkci ředitele pro pilotované lety a robotický výzkum a dodává: „Kompletní obrázek si uděláme až na začátku roku 2017 po zpracování výsledků z nezávislého externího vyšetřovacího týmu, který byl nyní založen na žádost ředitele ESA. Tento tým spadá pod generální inspektorát ESA.“
„Určitě jsme se od Schiaparelli hodně naučili. To přispěje k vývoji druhé mise ExoMars, kterou vyvíjíme společně s našimi zahraničními partnery, aby mohla startovat v roce 2020,“ popisuje Parker. Jeho kolega Roberto Battiston, ředitel italské kosmické agentury ASI doplňuje: „ExoMars je pro evropskou vědu a výzkum velmi důležitý. Společně s ostatními státy zapojenými do programu, budeme muset pracovat, abychom úspěšně dotáhli druhou misi ExoMars k cíli.“
Zdroj: https://upload.wikimedia.org
Jelikož modul EDM havaroval, všechny zajímá hlavně příčina havárie. Málo se ale ví, že modul před svým zánikem sbíral iinženýrská data, která se ale hodí i vědcům a která se podařilo odeslat. Údaje z palubních přístrojů pořízené během sestupu, stejně jako sledovací data ze sond TGO a Mars Express i s údaji z indického radioteleskopu byly předány vědeckým týmům. Tato vědecká data pomohou lépe pochopit Mars a především jevy v jeho atmosféře.
Na závěr ještě krátká zpráva o druhé části programu Exomars 2016, tedy o sondě TGO, na kterou by se ve světle havárie EDM nemělo zapomínat. Sonda v těchto dnech začíná první sérii vědeckých pozorování a snaží se využít výhody své dočasné parkovací dráhy předtím, než zahájí dlouhou sérii manévrů, kterým se říká aerobraking. Jde o stav, kdy družice sníží nejnižší bod své dráhy až do míst, kde začínají slabé pozůstatky atmosféry. Sonda bude o tyto vrstvy třít, což ji lehce zpomalí a bez použití paliva tak trochu poklesne její nejvyšší bod dráhy. Tento proces se nedá uspěchat a sonda TGO se tak na operační dráhu dostane až na konci roku 2017.
Zdroje informací:
http://www.esa.int/
http://www.planetary.org/
http://www.esa.int/
Zdroje obrázků:
http://planetscitech.com/wp-content/uploads/2016/10/ppp.jpg
http://www.esa.int/…/16069721-1-eng-GB/Schiaparelli_s_heat-scorched_shield.jpg
http://planetary.s3.amazonaws.com/…048120_1780_nomap_backshell_color_processed.jpg
http://planetary.s3.amazonaws.com/…048120_1780_nomap_lander_color_processed.jpg
https://upload.wikimedia.org/wikipedia/commons/8/83/Schiaparelli_Lander_Model_at_ESOC.JPG
„Modul EDM si myslel, že je pod povrchem a vypnul motory“
A teď by se za to modul asi nejraději někam zahrabal. 😀
Zdvojení některých kontrolních funkcí při přistávacím manévru by mělo pojistit úspěšnost. Rovněž použití bezpečnostního senzoru, který může reagovat na předem odhozený aktivátor do místa dopadu.
Redundance systémů je na první pohled snadným a logickým přístupem. A velmi často se také dělá. Při návrhu je ale nutné zvolit, jaký systém nebo jeho část má být vícenásobná. Do toho vstupují další omezení jako hmotnost, cena, čas, rozměry, potřeba el. energie, pohonných hmot, výpočetního výkonu atd. Vždy je to potom o míře rizika jakou jste schopni akceptovat. EDM byl vyvíjen jako technologický demonstrátor, dlouhou dobu se potýkal s tím, aby se návrh vůbec vešel do limitu 600 kg. Technici se rozhodli pro takové řešení jaké zvolili, to už teď nejde vzít zpět. U DM pro misi ExoMars 2020, protože už nejde o technologickou demonstraci, ale dopravu roveru na povrchu Marsu, se od počátku počítá s mnohem vyšší úrovní jištění. Např. dvě jednotky IMU.
V průběhu téhle mise se pořád něčemu omlouváme. Nejprve Brizu a teď výškoměru 🙂
Takže IMU oznámila navigačnímu systému určitou (i když mezní a nečekanou) hodnotu. Což podle mého názoru nemělo ve výšce 3,7 km (jak správně současné ohlásil výškoměr) vyvolat žádnou paniku. Času dost. Navigační systém to však kdo ví proč pochopil, že je pod úrovní terénu. Jak k tomu závěru mohl dospět? A k čemu měl potom výškoměr? To ho mohl klidně nechat doma.
Pokud jsem to pochopil dobře, inerciální systém měl za úkol měřit pouze orientaci v prostoru a ne pozici (výšku). Pokud byl zmatený údaj o orientaci, mohla se ze správného údaje výškoměru odvodit nesmyslná výška. Například, pokud by si myslel, že je vzhůru nohama, vypočtená výška by byla pod povrchem. Tohle je ale poměrně standardní stav, který by měl software odfiltrovat. Navíc je tam víc míst, kde by se na chybu mělo přijít – třeba by počítač neměl připustit změnu výšky výrazně převyšující aktuální rychlost a už vůbec ne teoreticky možnou rychlost.
Navíc určitý údaj o orientaci (i když v této výšce asi ne tak přesný) měl přijít i od samotného výškoměru, který měl více čidel v různých směrech.
Ve funkci výškoměru pracoval pouze RDA.
No ale stejnak, ja, jako programátor mám mít tyhle riskatní stavy ošetřeny když se to dělá už u mobilu, tj když výškoměr ohlásí zápornou hodnotu, tak software má vědět že je to nesmysl (modul tam nešel prci hrabat do povrchu tj zaporna hodnota je nesmysl a ten výsledek zahodit… přijde mi to jako mizerná pprogramátorská prace (neošetření rislatního stavu softwaru)coz by se u takhle drahych a dlouho vyvýjených věcí stávat nemělo
„tj když výškoměr ohlásí zápornou hodnotu, tak software má vědět že je to nesmysl “
To je sice možné, ale v tu chvíli, jakmile software zahodí očividně nesmyslnou hodnotu, jeho míra nejistoty o situaci (tj. množství informace) se nezmění a problém máte tak jako tak. Jinak řečeno, moc jste si nepomohl, je mnohem produktivnější takové situaci zcela předejít, protože třeba ztrátu informace v integrátorech pohybových rovnic IMU už neopravíte (bez nezávislých údajů zvenčí).
Ten problém/příčina nebyla tak jednoduchá a černobílá jak je, z důvodu zjednodušení a snazší pochopitelnosti, popsáno v článku. Šlo o souhru několika událostí, které vedly k tomu, že GNC software zapracoval špatně. A to je dobrá zpráva, protože se podařilo problém identifikovat a je v zásadě softwarový a ne hardwarový, což se (a v kosmonautice obzvlášť) snadněji napravuje.
Hlavní důvod pro navedení na provozní dráhu až koncem roku 2017 je odklad zahájení aerobreakingu na březen 2017. A ještě drobnost, EDM sbíral při přistání data inženýrská, nikoli vědecká. Vědecká data měla být získaná dedikovanou aparaturou až na povrchu jako bonus.
vďaka za upresnenie -> „EDM sbíral při přistání data inženýrská, nikoli vědecká“, to mi zavrtalo v hlave po prečítaní.
IMU hlásila maximální měřitelnou hodnotu. Jakou orientaci modulu v prostoru tato hodnota představuje?
Přece nejjednodušší je do počítače dát priority. Tady to měl být výškový radar a ne nějaký “ náklon“. Dnes jsou počítače zcela jinde než před 50ti lety a přitom již primitivní počítač na LEMu Apolla priority měl, kdyby tomu tak nebylo tak se LM po poplachu na 1202 hbitě vracel k CM.
Je to už druhý nepovedený pokus o přistání o to něco vypovídá. ESA to prostě neumí a o je při dnešní úrovni techniky a dokonalých znalostech o Marsu na pováženou, pro srovnání Američané před padesáti lety přistáli na první pokus a hned 2x a Rusové tehdy též prakticky uspěli. Technika a znalosti o Marsu se s dnešními nedají srovnat.
Jedná se o systémovou, nikoli náhodnou chybu, ptám se proč modul nestavěli Angličané, ti byli s 10x lehčím zařízení blízko úspěchu. V roce 2020 bude situace stejná modul postaví zase někdo jiný a draze placené “ zkušenosti“ půjdou v niveč. Pozitivní je, že Rusové mají vlastní “ zkušenosti“ a s tehdy primitivní technikou před 50 lety prakticky uspěli, dostali sondu na padáku až k povrchu a proto jim dávám 90%.
„Je to už druhý nepovedený pokus o přistání“, koho?
Myslím, že pan Alois míří na ESA, a první nepovedený Beagle 2. A ano, je to šlendrián, přesné součástky pospojovány a výsledek je nefunkčnost. Jistě ta příčina mohla být komplexnější, ale na to vše musí být takový automat softwarově připraven. Jasně, tam seděl člověk, tak to vyhodnotí, co funguje blbě vypne a přistane. Tak jako Apollo.
Omluva, v poslední větě mi vypadlo slovo – Kdyby tam seděl člověk…
Philae se to přistání také moc nepovedlo. Pan Alois má pravdu, ESA má prostě v procesech přípravy někde nějaký problém a komplikované věci, které musí fungovat na první pokus, jí asi moc nejdou …
Ale např. na Titanu přistála ESA excelentně. A jak to bylo daleko …
Přesně tak.
Vždyť dle dostupných informací je to jednoduché.
Gyroskop – tzv. orientace v prostoru určuje všechny tři osy: X,Y,Z
Výškoměr – určuje výšku a je přece k němu vztažena jedna osa
Takže pokud by Gyroskop špatně vyhodnotil směr orientace, tak výškoměr (jak se tady psalo) tuto nejdůležitější osu směrem k přistání musí do CPU řídící jednotky dostat a porovnat. Takže zde by to mělo být sekundárně zajištěno!
Jedině, že by mezi sebou špatně komunikovali, takže asi softwarová chyba jak psal Vojta.
Ono urcit priority nie je zasa tak ciernobiele, ako si to vy bohorovne predstavujete.
Ak mate dva snimace, ktorych domeny sa prekryvaju a udaje z nich sa zacnu rozchadzat, ako zistite, ktory z nich ma pravdu? Iste, ak mate doma 2 meteostanice, alebo meteostanicu a snimac vonkajsej teploty pre ekvitermiku, tak to zistite pomerne jednoducho. Ak bude vadny snimac pre ekvitermiku, budete mat v dome zimu alebo prilis teplo, popripade sa pozrete z okna a ak tam uvidite sneh, +30 v tieni asi fakt naozaj nebude, to je vadna meteostanica.
Roboticky modul sa ale z okna nepozrie, ci je este nad povrchom, alebo nie. Tymto sa zaobera cele odvetvie na pomedzi informatiky a elektroniky, ktoremu sa hovori diagnostika a spolahlivost. Najblizsie sa s nim mozete stretnut, ked startujete pocitac a ten si kontroluje pamat, alebo ked vam na aute vyskoci kontrolka check engine. Tam je to ale stale este jednoduche, pretoze staci zistit, ci komponent je zly, alebo nie. Ani auto ani pocitac velmi nemusia riesit, co s nefunkcnym komponentom. Pocitac nenastartuje a auto v lepsom pripade pobezi v nudzovom rezime ignorujuc ho, v horsom nepobezi.
Tradicne sa tento problem riesil nasobnym zalohovanim. Raketoplany (ako ruske tak americke) a kopec dalsieho vybavenia mal 5-nasobne zalohovany system a ten replikant, ktory si dovolil podat nespravny vysledok, siel z kola von. A ked ostali len dvaja, tak sa pri rozdielnom vysledku vybral ten spravny nahodne.
Apollo bolo v uplne inej situacii, tam mal koncove slovo pri znacnej casti alarmov clovek, pretoze on sa z okna pozriet mohol. Na robotickej misii nic take nie je.
Navyse predpokladam, ze korenom veci tu bolo pretecenie registra a pomerne trivialna chyba v SW vybaveni. Algoritmus na filtrovanie vystupu z IMU (aby sa vyriesil problem so saturaciou) nebol nastaveny tak, aby odfiltroval tak dlhu saturaciu, tak sa vysledky mimo rozsah ocakavanych hodnot dostali niekam, kde sa s tak velkymi hodnotami nepocitalo a nejaky celociselny vypocet pretiekol. Kedze vysledok bol zaporny, predpokladam, ze pretecenie bolo dost velke na to aby nastavilo znamienkovy bit ale nie dost velke na to aby indikovalo HW priznak pretecenia a hodilo chybu. Mozno pri tom, ako sa nastavovali platne hranice, alebo SW saturacia niekto spravil chybu vo vypocte max. hodnot, alebo tam dal operator <= namiesto < ? Chybu som nazval trivialnou, ale vo svete pocitacov moze za 99% chyb to najtrivialnejsie 1% ludskych chyb. Aspon teda takto ja chapem to vysvetlenie z clanku.
V tomhle případě se ovšem další referenční veličiny hledají celkem snadno. Třeba čas od mezi jednotlivými manévry, rychlosti a vzdálenosti, kterých bylo vůbec možné dosáhnout a tak. Ovšem po bitvě je každý generál a určitě se pro příště poučí.
Zrovna v tomto pripade bol ten cas to, co sa testovalo, takze predpokladam, ze sa nanho nespoliehali. Dopplerovsky radar aj IMU bolo mozne vyskusat (a skusane boli) aj na zemskom povrchu a vo vzduchu. Cas bol vysledkom cisto teoretickych vypoctov a overoval sa pristavacim manevrom.
Navyse ako som napisal inde, myslim si, ze toto bola tvrda programatorska softwareova chyba a ten software si zrejme nebol vedomy toho, ze s chybnymi datami vobec pocita. Trocha ma udivuje, ze negativna vyska v navigacnom SW nevyvolala alarm. To je ale zrejme kvoli tomu, ze kvoli zvolenej hodnote „0 m.n.m.“ existuju na Marse aj miesta s negativnou vyskou.
Ono „podivat se z okna“ neni zas tak slozite ani pro robota, pokud se na to myslelo pri vyvoji. Velmi nepresny odhad vysky jde ziskat napriklad barometrem a taky z puvodniho letoveho planu. Nepresny senzor naklonu je dneska v kazdem druhem telefonu. Takze se souvastkami za par korun (doslova) a s hmotnosti v jednotkach gramu mohl mit pocitac informace navic pro rozhodnuti se, kdo keca.
Dalsi vec je, ze maximalni pretizeni (ktere jeste neznici modul) a hmotnost modulu je znama. Takze pokud nejaky senzor hlasi neco, jako pokles ctvrtinou rychlosti svetla, nebo pretizeni 1000g, da se prepokladat, ze keca (a pokud nekeca, tak uz to je stejne jedno).
Podle me je problem v nedostatecnem testovani. Takovyhle software se musi pred letem nakrmit i trochu blbymi daty (simulace toho, kdy se neco podela) a odladit, aby se porad choval nejak zhruba rozumne.
Na druhou stranu po pitve je kazdy patologem, takze to berme tak, ze ESA poucila. Aspon ten Mars trefili spravne narozdil od Rusu nekdy pred asi 40 lety, nebo od Americanu, kteri sikovne smixovali stopy a metry.
„Takze se souvastkami za par korun (doslova)“
A pak to havaruje díky i němu – neboť 1/2 ročního letu (či jak dlouhého) v prostředí s vysoce energetickými částicemi s jeho funkčností jako nic asi neudělá.
To jde možná tak u družice, která je stále chráněna magnetickým polem.
Tu si prave myslim, ze data boli dost blbe na to, aby to system rozhodilo, ale nie dost blbe na to, aby to nejake protiopatrenie spustilo. Tipoval by som, ze niekde bol nejaky limit nastaveny na cislo o 1 vacsie alebo mensie, nez mal byt.
Pane Alois vicemene s Vami souhlasim.
Nicmene napriklad srovnavani s 50 let starym systeme moc nejde, tam byla „vyhoda“ jednoduchosti celkoveho reseni. Kdyz to prezenu tak jako se starym a novym „smart“ mobilem – Muj stary dobry Alcatel nikdy „nezamrzl“ a fungoval velice konsistentne. Pravda umel jen telefonovat a nic jineho. Dnesni telefony dovoluji miliony dalsich veci a nabizeji vetsi komfort, ale holt obcas zamrznou ci maji jine vrtochy. A nebo stary dory VAX/VMS versus Windows/OS-X/Linux. Jenze pomer radku kodu VAX/VMS a treba Windows 10 bude v pomeru minimalne 1:1000 🙂
To se chyba najde snadno.
Nicmene pravdou je ze metodiku maji americani zvladnutou asi mnohem lepe, maji asi i vetsi zakladnu nekolika generaci lidi zvyklych a naucenych pracovat v trosku jinem rezimu nez se bezne pracuje dnes.
ESA by se mela chytit za nos a rychle se z toho poucit.
Pán Alois, zase miešate hrušky s jablkami. Priority v počítači slúžia na to, aby určitá veľmi dôležitá úloha mala prednostne k dispozícii zdroje ako CPU a RAM. Vôbec sa takto nerieši logický obsah danej úlohy. Nasadenie priority v počítači pre LM v programe Apollo umožnilo efektívne využiť existujúcu kapacitu počítača pre životne dôležité úlohy.
Problém v EDM bol úplne inde.
To zní jako chyba, která měla být odhalena při testech na Zemi.
No tak to platí o každé chybě. A jak se říká: „po bitvě je každý generál“.
Nějak nechápu vaši odpověď. Forma vaší odpovědi se používa úplně u jiného typu příspěvku.
To je reakce na to, že jste psal, že se chyba měla odhalit na Zemi.
Jednotka dosáhla maximálních měřitelných hodnot a navigační systém to vyhodnotil jako zápornou výšku. To zní jako přetečení hodnoty, se kterým má ESA už bohaté zkušenosti.
Podle mne je to jasná sw chyba. Pokud jedno čidlo je mimo možnosti měření ( z jakéhokoliv důvodu – třeba i závady) tak to logika systému musí jasně vyhodnotit tak, že jeho údaj nemůže dál použít. Zvláště potom, co tam je druhý systém, který předává hodnoty , které odpovídají nějakému profilu ( akcelerace, rychlost, výška)
Podle mne jde o selhání sw v každém případě. Ať už mám systém vyhodnocení reálných veličin zálohován x-krát, tak přece pro zjištění toho, co je a co není blbost se musí taktéž vyhodnocovat podle určité predikce, kde se v této chvíli sonda má vyskytovat. Proboha, celá dráha sestupu je přeci dopředu spočítána. Ví se v jaké výšce, v jakém čase, jakou rychlostí a pod jakým úhlem vstupuje do přistávací fáze. V současnosti to není jako kdysi, kdy nikdo nevěděl co má očekávat´. Ví se poměrně přesně o rozložení a hustotě atmosféry, gravitačním poli atd. Pokud přijde šílený signál v bodě sestupové dráhy, kdy je poměrně přesně dáno, kde se má sonda právě nacházet a sw provede šílené odstřelení padáku v několika km nad zemí, tak tady něco zjevně není v pořádku s odladěním sw, nota bene zvláště s ohledem na to, že druhý pokus už není.
Přesně tak. Přetečení registru, ani čehokoliv jiného, není stav, s kterým lze dál pracovat. Nelze vyhodnotit, že mám zápornou výšku a podle toho zapínat a vypínat motory. A jen nakonec – my všichni tady jsme amatéři a chceme to hlavou pochopit a vysvětlit – jenže v ESA na tomto projektu pracovalo spousta profesionálů, lidí, kteří se touto problematikou zabývají léta, s vysokou erudicí a ne špatně placeni. Proto mi to hlava nebere. Jo a ten Beagle 2 nakonec přistál správně, ale neotevřel všechny solární panely …
Jako SW inženýr, který má analýzu a opravování chyb jako svoji hlavní pracovní náplň, můžu zodpovědně prohlásit, že na základě výše uvedeného popisu chyby nelze nic usoudit, obvzvláště vzhledem k tomu, že nevíme, jak řídicí systém přesně funguje. Takže všechny úvahy o tom, jak hloupá chyba to byla, jsou jen čiré spekulace.
Pokud používám nefunkční čidlo k nějakým závěrům, je to proti normální logice. ( a zvláště, když se při tom tvrdí , že druhé čidlo fungovalo). Na to snad není potřeba být specialistou – tímhle se přeci řídíme i v normálním životě.
Jasně, v obecné rovině to vypadá, že algoritmus nebyl tak robustní, jak by měl. Já myslel ten údaj o záporné výšce – čert ví, co to znamená.
Nejpravděpodobnější příčina záporné výšky bude přetečení hodnoty při výpočtu. Pokud tomu opravdu tak bylo, pak je to hodně hloupá chyba. Už jednou je chyba tohoto typu stála Ariane 5.
Petr: Žádné přetečení. Dnes se to již opravdu neprogramuje v asembleru a nešetří se každý řádek kódu. Z kladné hodnoty prostě už jen tak nedostanete zápornou hodnotu jen tím, že k ní přičtete další velkou kladnou hodnotu. Dnes se software programuje v jazyce C, nebo něčem podobném a tam se o takové jednoduché kiksy stará už systém vyjímek.
Céčko výjimky nemá a hodnota proměnné může přetéct stejně snadno jako v assembleru. C++ už je trochu jiná (výjimky tam zavést jdou), ale přetečení, pokud se nepletu, také nehlídá. Ohlídat se dá samozřejmě ručně, i když běžně to nikdo nedělá. V čem je to programované ale nevím.
Vojta: Ok. C přetečení fakt neřeší, C++ už výjimku má. Ovšem v tom to asi zase programované nebude. Takže tam nějaká možnost chyby i zde být může. (Ale taky to klidně může být „null pointer“, že jo ;-))
„Petr: Žádné přetečení. Dnes se to již opravdu neprogramuje v asembleru a nešetří se každý řádek kódu. Z kladné hodnoty prostě už jen tak nedostanete zápornou hodnotu jen tím, že k ní přičtete další velkou kladnou hodnotu.“
Saturace analogového signálu je analogovým ekvivalentem přetečení. Pouze to přetečení nemá charakter modulární aritmetiky, takže nepřeskočí do záporných hodnot. (Nicméně i v digitálních ALU existují leckdy saturační aritmetické operace.)
„Dnes se software programuje v jazyce C, nebo něčem podobném a tam se o takové jednoduché kiksy stará už systém vyjímek“
Cčko výjimky nemá, a i kdyby je mělo, generická aritmetika v takovém případě stejně dává větší smysl (protože co jiného byste v té výjimce implementoval ručně?).
A navíc v Cčku přetečení povolených hodnot, pokud mě nešálí paměť, vždycky byla především nedefinovaná operace, takže argumentovat Cčkem jako lepším řešením mi nepřijde na místě – jste povinen zaručit, že se program o takovou operaci nikdy ani nepokusí a nějaké výjimky vám nepomůžou.
Tyhle sondy se neprogramují v C a už vůbec ne v C++. Nejrozšířenější u sond je Lisp.
„Tyhle sondy se neprogramují v C a už vůbec ne v C++. Nejrozšířenější u sond je Lisp.“
Ehm…poslední sonda, o které je známo, že v ní byl použit Lisp, byla Deep Space 1. Netuším, jak jste přišel na to, že současné sondy mají software psaný v Lispu. Právě že dnes na C (s výraznými omezeními) přechází spousta kosmického softwaru (je těžké sehnat nové programátory v Adě nebo Module-2).
Ad přetečení v C/C++:
Pro C je to normální platná operace a zrovna jsem si ověřil, že je to tak i pro C++ (překladač g++ pod Linuxem). Možná to zní divně, ale je to tak a občas je to i využíváno programátory. Žádnou výjimku to nevyhodí. Prostě se to musí hlídat přímo na místě ručně.
Nicméně, jak už bylo zmíněno jinde a vlastně i v článku, nemělo jít o programové přetečení, ale o saturaci analogového čidla, což se v programu většinou projeví tak, že se hodnota přestane hýbat a softwarové regulátory, které na to nejsou připravené, se většinou zblázní a saturují i řídící veličinu. Výsledek může být všelijaký, ale nic dobrého z toho většinou nevzejde.
Zcela běžně je využíváno přetečení nějaké proměnné – já ho osobně používám při výpočtu jednoduchého kontrolního součtu – prostě neustále přičítám vysílané bajty do proměnné typu byte nebo word (2byte) – takže logicky očekávám přetečení této proměnné.
Kontrola přetečení se dá v některých překladačích v C++ zapnout – pro určitý blok – je to SW kontrola navíc – takže množství kódu musí ten překladač proto přidat a to běh programu samozřejmě zpomalí.
Jo jo. Uznávám, že i moderní překladače C++, třeba od Microsoftu, mají přetečení na háku a kvůli generování co nejrychlejšího kódu nechávají ošetření přetečení na programátorovi. Programátoři se ale samozřejmě snaží najít optimální způsob jak tu kontrolu do kompilovaného kódu automaticky dostat a přitom to udělat tak, aby to moc nezpomalovalo. Jednou z cest je „As-If Infinitely Ranged Integer Model“
http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=9299
Řekl bych, že ti co programují pro letadla nebo pro sondy, nebo třeba pro samořiditelná auta by nějakou takovou podporu ve svých moderních překladačích mohli využívat.
„Ad přetečení v C/C++: Pro C je to normální platná operace“
Fakt?! Tak to asi neumím číst nebo potřebuji nové brýle, protože norma jazyka C zcela jasně hovoří:
„3.4.3 UNDEFINED BEHAVIOR: behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements
NOTE: Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving duri g translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).
EXAMPLE: An example of undefined behavior is the behavior on integer overflow.“
Na C-čkovém projektu bych s Vámi tedy rozhodně pracovat nechtěl. :-p
Jen pro pořádek .. tohle je sice pravda, ale týká se to jen znaménkových typů, neznaménkové mají chování specifikované jako aritmetiku modulo velikost typu. Je potřeba normu dočíst i dál. Takže přetékání neznaménkových typů je naprosto validní operace. (Velmi možná by se dala najít nějaká záludnost podivnou kombinací neznaménkových typů menších než int a integer promotion rules, ale spíš ani tak ne.)
Ano, ale v tom případě nelze hovořit o přetečení. Řečeno jinak, přetečení je stále neplatná operace, ale protože operace s typy bez znaménka ho *negenerují nikdy*, jsou pro diskusi přetečení irelevantní.
K tomu možná … násobení dvou velkých hodnot v neznaménkovém typu menším než int, by asi mohlo být považováno za undefined, pokud si dobře přebírám normu, protože operace v int z integer promotion přeteče (něco jako násobení 0xff dvou unsigned char, když integer je 16bitový). Pak je otázkou, jak se k tomuhle staví ne norma, ale reálné překladače. 🙂 A pro sčítání asi nic podobného bez obskurních velikostí datových typů vymyslet nejde.
Ono je v principu irelevantní jedno i druhé, protože tady šlo o rozsah senzoru, ne numerické přetečení. 🙂 Ale jinak mám pocit, že se přetečení běžně říká i u neznaménkových typů (viz pár příspěvků nahoru o kontrolním součtu), i když to není konzistentní s použitím tohohle výrazu v C normě.
No já nevím, jak napsat operaci nad unsigned char 255 + 1, kde výsledkem bude nula, ale obvykle se tomu také říká přetečení a může to způsobit podobné problémy jako přetečení znaménkového typu do záporných hodnot. Dobře si pamatuji, že to neměli ošetřené v jedné hře a pak docházelo k dost bizarním situacím. Úmyslné využívání přetečení jsem myslel spíš v rovině neznaménkových typů, u znaménkových je to prasárna stejně jako na ně používat bitové operace.
Ale aritmetika modulo 2^(2^n) není ani prasárna, ani přetečení. 😀 A že pokud něco nechcete, tak to dělat nemáte, to vám říká už standard jazyka.
Měl modul při sestupu kontrolovatelně rotovat, nebo to bylo nechtěné chování po vystřelení padáku? Ve starším článku se psalo, že byla použita IMU LN-200, předpokládám že verze pro space applications LN-200S. Ta má podle datasheetu dynamický rozsah 1000 °/s, takže pokud byla osa Z sekundu v saturaci, modul alespoň tu dobu rotoval zhruba 3 ot./s.
Je běžné, že moduly při sestupu atmosférou rotují, třeba kvůli stabilitě?
Rotace je přirozená a také se s ní počítá.
Podle mě je to prostě jen špatný odhad změn, které měly být ignorovány. Když se od modulu něco odděluje, nebo se mění konfigurace modulu (vyhozený padák etc.), berou se v úvahu velké výchylky v akceleraci i orientaci, které se buď ustálí samy a pak je nemusím měřit a naopak data z nich ignorovat a nebo je přesně měřím a reaguji i během nich. Tady se rozhodlo o první možnosti, jen ten interval na „uklidnění“ asi nebyl nastaven dost dlouhý. Tedy softwarová chyba v „myšlení“ modulu kvůli jeho asi příliš zjednodušenému modelu rozhodování.
Někdy prostě může být příliš moc rychlé rozhodování podle nějakou chvíli špatně interpretovaných dat na škodu. Ty staré analogové sondy vlastně mohly, díky tomu zpoždění a spojité regulaci jejich velice jednoduchých řídících systémů, představovat robustnější (chybným interpretacím odolnější) řešení.
Nicméně ty pořádné testy na Zemi prostě chyběly. Vyhodit z letadla a nechat se to mlátit v zemské atmosféře, třeba s menším padákem a v menší rychlosti, by mohlo něco napovědět. Jen počítačové simulace prostě nejsou všemocné.
Je ale skvělé, jak obrovské množství údajů z letu mají.
Beagle vážil pouhých 60 kg a vezl přístroje a sluneční baterie. Na přistávací vybavení toho moc nezbývalo. Zřejmě přistál tvrději než byla jeho odolnost proti mechanickému poškození otevíracího mechanismu. Kdyby byla anténa na prvním panelu, tak pravděpodobně v omezeném režimu fungoval.
Italský modul vážil desetkrát tolik. Prakticky nic nevezl a stejně nefungoval. Kdyby na Marsu dosud nikdo nedokázal přistát, pak by byly výmluvy na “ získávání zkušeností“ věrohodné, ale na Marsu se běžně přistává desítky let, po jeho povrchu jezdí rovery jakoby se nechumelilo a proto je někde v ESA chyba, nebo to prostě ESA nedokáže, což je horší.
V každém případě bude druhá etapa projektu v roce 2020 riskantní, zejména se bude jednat o vysoké finanční náklady. Nebylo by od věci v roce 2018 to opět zkusit “ na nečisto „, nejlépe s ruskou obdobou Schiparelliho.
Ten váš příspěvek skoro zní, jako by byl ten balónový Beagle přístup vhodnější. Bohužel nebyl. Pro tak rozměrné a hlavně těžké stroje, jakými budou ty v programu ExoMars, nepřipadá dopad na airbagy v úvahu. Tohle stačilo na Spirit a Opportunity. Těžká Curiosity už potřebovala motorické přistání. A stejně tak ExoMars.
To jsem nechtěl, ale myslel jsem to tak, že Schipatelli měli stavět Britové.
Nebo Rusové.
Jaký by to mělo přínos pro Evropu, kdyby ho stavěli Rusové?
Nepíše se náhodou správně „dopplerovský radar“, tj. s malým „d“ na začátku? To jen na okraj…
🙂 Ale ze se Vam ty titulky vyvedly….
„Modul EDM si myslel, že je pod povrchem a vypnul motory“
a vzapeti pod tim:
(Objeven) „Podpovrchový rezervoár ledu na Marsu“
Američané na Marsu přistáli 7x, ale jednou se jim to nepovedlo a tam také nějaký otřes zmátl počítač a ten vypnul motory předčasně jakoby už modul přistál. Výšku nevím, ale bylo to tuším v desítkách metrů. Mám ten dojem, že sonda nesla tehdy i penetrátory, proč ty neuspěly jsem nikde nenašel.
Penetrátory MPL byly připevněny k přeletovému prstenci (takže se samotným landerem neměly nic společného), od kterého se měly stejně jako lander oddělit ještě před vstupem do atmosféry. Ani to oddělení nebylo potvrzeno, takže nevíme nic. Možná se od prstence oddělily a samostatně dopadly (a třeba se i správně zaryly do povrchu), ale kdo ví… ani jeden se neozval.
U penetrátorů je paradoxní, že v historii dobývání vesmíru byly jen na dvou misích, ale obě shodou okolností skončily fiaskem (MPL + Mars 96). Škoda. A nevím o tom, že by někdo nějaký další penetrátor plánoval.
Mám ten dojem, že jsem někde četl o penetrátorech plánovaných pro Měsíc.
Musím říci, jedna z nejzajímavějších diskusí zde. Článek i většina příspěvků byly opravdu velmi fundované. Hezky jsem si početl.
Za mě — takové chyby prostě bolí, když to člověk čte! I když je to třeba 100 milionů km daleko.
Napadla mě zajímavá otázka. Co sestupová kamera, která měla pořídit 15 snímků? Modul se z výšky 3,7 km řítil již nebržděně, kamera měla začít snímkovat asi od 3 km. Je možné, že se aktivovala, něco vyfotila, ale snímky se již nepodařilo odeslat?
Nepřijde mi to reálné kvůli tomu,že modul si myslel, že je nízko. Přešel tedy na systém přistání s vypnutými motory. V této fázi se již snímkovat nemělo. Proto si myslím, že nemůžeme čekat žádné fotky.
Takže od té výšky 3,7 km (kdy se vypnuly motory) už to počítač asi vnímal, jako že přistál. Tudíž kameru ani neaktivoval. To vypadá logicky. Díky. Jinak fotky jsem ted už neočekával, jen mě zajímalo, zda mohlo dojít k aktivaci kamery.
Považuju to za nepravděpodobné.
Adept do top 5 failů v kosmonautice? 🙂
O víkendu jsem na nějaké TV stanici ( za Boha nevím kde ) viděl dokument z ESA a shodou okolností o ExoMarsu s vrcholem se záběry startu na Bajkonuru z března a viděl jen konečnou část , kde vyklepaný a šťastný inženýr z ESA říkal něco jako : “ při vědomí jak málo jsme mohli testovat a jak dobře vše dopadlo … “
Peníze tedy bylo hlavní omezení . Což při misi 2020 nepřipadá v úvahu , nyní se musí testovat jak o život .
Souhlas. U ExoMars 2020 se musí testovat více, nejde o žádný experiment, ale o plně vědeckou misi. Dokonce bych zašel tak daleko, že doprava roveru na povrch Marsu by se mohla odehrát jakýmkoliv způsobem, včetně amerického sky crane (zvláště po tom, co nepodařilo nabrat zkušenosti s motorickým přistáním EDM). Jádrem mise přece není doprava roveru, ale jeho práce na povrchu Marsu. Vrt do dvoumetrové hloubky je unikátní záležitost.
Teď někdy by se mělo jednat o schválení 400 mil. EUR, které chybí. Takže se pohybujeme na hraně zrušení celé mise, trochu se bojím, aby se díky tomu právě to testování nezanedbalo.
Tak jsem měl čas to dohledat , jednalo se o Dr.Nicolase Thomase , Principal investigator projektu ExoMars a vše se odehrálo ve třetím díle vědecko-dokumentární-sci-fi Mars na National geografic asi 33 minuta , kde celý tým sleduje start sondy TGO na Bajkonuru.
V předchozím hovoří o tom jaké to je ztratit sondu , což se mu stalo dvakrát. Na projektu ExoMars pracuje šestnáct let. A při povedeném startu říká doslova : “ A když jste třeba neměli dost času to otestovat , tak si říkáte , No nazdar snad to nedopadne zase špatně „