Építsünk rakétát! [1 – a koncepció]

2024. december 01. vasárnap

Nyáron elkeveredtem az űreszköz-építő táborba, ahol miután Örs elejtett egy fél mondatot, hogy LoRa és Radiometrix modulokkal kommunikálnak a szuborbitális rakétákon fellőtt műholdak, elkezdtek dolgozni a kis manók: mégis, ez időben hogy jön ki?!

A dolog csak nem hagyott nyugodni, a kérdések pedig egyre gyűltek: egyáltalán, mi az a minimális hardver, amivel biztonsággal, gyakorlatilag realtime lehet telemetriát szolgáltatni egy alig néhány másodperces fellövés alkalmával? Mire jobban utánanéztem a CanSat versenynek is, és kiderült, hogy valójában csak az ereszkedés a lényeg, már késő volt, és visszafordíthatatlanul dolgozott a vezérhangya a fejemben egy telemetriaadó- és logger ötletén. (Ha az cansat, akor ez eggsat (HI).)

Azzal, hogy túl komolyan ráfeküdni nem fogok tudni, a projekt kapóra jött, hogy egy Eagle-s élményszobrászat keretein belül az évek alatt összegyűlt néhány fontosnak, vagy legalább hasznosnak tűnő ötletet kipróbáljak. Ha jobban belegondolok, a legcsábítóbb nem is a kivitelezés volt, hanem a küldetés biztonságának számos pontot tetten érhető (túl)méretezése.

A dolog hamar egymásra talált egy tengerentúlra költözött ismerős korábbi beszámolójával, akik tojásokat lőnek fel kisebb-nagyobb rakétákon. Nyilván adódott a kapcsolat, hogy a hasznos tehernek miért is kellene nagyobbnak lennie egy 50-60 grammos tojásnál…?

Szóval adott egy rakéta, amit kilövünk, fent felrobbantunk majd visszaejtünk, valamint egy tojásnyi méretű berendezés, ami nem csak kibírja mindezt, hanem relatíve valós időben közvetíti is az adatokat. Egy monitoron szeretném látni, hogy épp mi történik; vezetett grafikonon a gyorsulást, és egy óriási számon a G-erőt, sebességet és az aktuális magasságot. Egyszerűnek tűnik, de ez csak a provokáció benne.

Dokumentálni túlságosan nem szeretném az egyébként triviális hardveroldalt, néhány telefirkált A4-es lap és a panelterv – mégiscsak szabadidő, nem kell túltolni. Egyedül a koncepciókat célszerű lefektetni. A neten rengeteg ballonról, vagy a népszerű CanSat-ről található leírás, de én inkább fényképet sem néztem, izgalmasabbnak tartom szembesülni a problémákkal, mint kész megoldásokban kapni még fel sem tett kérdésekre választ.

Fontos, hogy a koncepcióterv – noha néhány apróságot kipróbálni tökéletes -, tanulásra nem alkalmas, otthoni körülmények között nem megépíthető. Akit érdekel a téma és belefér az életkorba, látogasson el a CanSat verseny oldalára.

A kis készüléknek képesnek kell lennie másodpercenként tíz mérést végeznie hőmérséklet, légnyomás, három tengelyen gyorsulás, GPS magasság- és sebesség tekintetében, ezeket, vagy legalább ennyi átlagértéket egy kártyán rögzíteni, illetve másodpercenként kétszer rádión letolni.

Az ehhez rendelt hardver kérdése már kicsit összetettebb. Eleve kell egy mikrovezérlő, amin van annyi port, hogy minden szenzor külön kapjon egyet, plusz egy dedikált SDIO. A modulok SPI és/vagy I2C buszon kommunikálnak a központi egységgel. A gyorsulás és sebesség értéke kicsit számolásigényesebb, mivel több tengely értékéből kell kiszámolni a beláthatóan kevés idő alatt, ezért az sem árt, ha lebegőpontos számításokat végző magot is rejt a CPU. Beláthatóan az STM32 család 4-es szériája kerül a panelre, lehetőleg olyan, ami kényelmesen forrasztható. Sajnos kétlem, hogy 48 lábú változatból lenne minden kritériumnak megfelelő.

Rádiómodul esetében az alapsávi átvitelt elengedem, és a lora felé kacsingatnék. Látatlanban – merészen – azt mondom, hogy inkább a teljesítményre helyezem a hangsúlyt a több száz kbps sebességgel szemben, így a 2,4 GHz-es modul helyett inkább egy felsőbb-ISM sávú berendezést vennék elő. Ennek azért utána kell számolni, elég sok adatot kell átvinni túl rossz körülmények között túl nagy biztonsággal. Inkább legyen kicsit lassabb, de biztosabb az átvitel és egyszerűbb az infrastruktúra.

A legtöbb vitás dolgot erőből túl lehet méretezni, a kritikus kérdés inkább a tápegység lesz: azon túl, hogy az akkumulátor relatíve nehéz, a több órás üzemidőt elengedve kellemes kompromisszumokat lehet kötni. Szükség lesz a nagy áramok miatt 5 voltra, míg 3,3 voltot stabilan, inkább állandó árammal kell szolgáltatni. Az elsődleges szempont, hogy egyetlen 3,7-es cellával meg lehessen mindent oldani.

A koncepció szerint tehát a teljes berendezés

– másodpercenként tízszer rögzítse a mérési eredményeket,

– másodpercenként kétszer adjon telemetriát,

– egy feltöltéssel legalább 30 percig üzemeljen,

– ne legyen nagyobb egy tojásnál,

– ne legyen nehezebb 95 grammnál.

A rakétával kapcsolatban egyelőre annyit, hogy az 500 méteres magasság elérhető egy szilárd hajtóművel szerelt, egyfokozatú konfekciótípussal. Elektromos gyújtás, sínes kilövőállás, kezdeti elgondolás szerint CNC-profilból egy rozsdamentes platformon. Visszatérés néhány másodperc múlva nyíló ejtőernyővel, bár a mérési eredmények miatt lehet, hogy érdemesebb leejteni.

 

 UPDATE 

Amikor elkezdtem felvázolni a koncepciókat, nem gondoltam volna, hogy ennyire gyorsan papírra kerülnek az első skiccek és ennyire gyorsan meg lesz tervezve egy-egy panel, így a valamivel több konkrétumot tartalmazó második rész nem is új bejegyzést kap, hanem egy folytatólagosan írt fejezet lesz.

a CPU és PSU modul első verziói

Az alig négy centi átmérőjű berendezés felépítése a jelenlegi állás szerint nem lesz túl bonyolult, az elektronika egy önhordó váz bordáira kerül. A különböző funkciók különböző modulokon kapnak helyet, melyek távtartókkal lesznek egymáshoz rögzítve, a buszok és a tápegység pedig flexi panelekkel csatlakoznak. Az árnyékolás jótékony hatásával bíró földet a gondosan ennek kialakított szalagkábelekre teszem ahelyett, hogy nagy és nehéz fém távtartókat alkalmaznék.

A szerelhetőség érdekében mindent 1206 méretű alkatrészekkel oldok meg, a csatlakozók 1,27-es tüskesorok. A processzor kiválasztásának egyik kritériuma, hogy legfeljebb TQFP-64 tokozású legyen, alsó hűtőplatform nélkül. A 14500-as akkumulátort a modulok rögzítik és tartják a helyén.

Könnyű elbagatellizálni, de a nagysebességű buszokra külön figyelmet kell fordítani. Ökölszabály, hogy az elkerülhetetlenül párhuzamos vezetők között fél-egy milliméter távolságot tartsunk, azonban segítség, hogy a modulok 1,6 milliméter vastag üvegszálas panelre készülnek, így az ellentétes oldalon – ahol nem árnyékolást kell kialakítani -, már elég nagy a távolság.

 

CPU modul

A fő modulon csak az STM32F411 processzor kap helyet. Nem kell kicentizni a kéréseket és beolvasásokat, minden periféria külön buszon csatlakozik, szoftveres szempontból is könnyebb lesz optimalizálni. A szűk keresztmetszetet ezúttal az jelenti, hogy ne nagyfrekvenciás tápvonalat készítsek az buszok kivezetéseiből. Ez a panel már hordoz egy, a buszvezetékek mechanikai rögzítésére szolgáló bevágást.

A modul hordozza az alapvető visszajelzéseket is, így a különböző tápfeszültségek meglétét vagy csatlakoztatását, és egy hearthbeat-et is, amit a mikrovezérlő ciklusokon át számlálva kapcsolgat.

 

PSU modul

A projekt talán legkényesebb kérdése a tápegység. Mivel a 3,7-es cellával a 3,3-as igényt egy stabilizátorral nem valószínű, hogy meg tudom oldani – a néhány tized voltnyi drop ugyanis mindent figyelembe véve elég kevésnek tűnik – a terv az, hogy mindent feltolok egy MT3608 step-up konverterrel 5 voltra, majd abból kapom vissza a 3V3-at egy fix LM2569 után. Így amellett, hogy nagyobb terhelés után is stabilabb marad a processzor tápellátása, az újabb konverzió előtt beláthatóan némileg kevesebb veszteséggel számolhatok. Nyilván észszerűbb a nagyobb teljesítményű holmikat a magasabb feszültségről kiszolgálni.

 

MSR modul

A műszerek a legfelső modulon kapnak helyet, így az M10 GPS és az antennája, a gyorsulásmérő és a hőmérő is. Sok szó csak a GPS-ből fog származni, ez mindenképp SPI-n keresztül kommunikál, a többi mehet egy-egy I2C-n is, talán megengedhető az a luxus, hogy ez csak férőhely kérdése legyen. Fontos szempont a hőmérő- és barométerszenzorok frissítése, tekintve, hogy másodpercenként 10 adatot akarok rögzíteni. A BMP280/388/390 elvileg meghajtható ennyivel, többre a precízebb MS5611 sem képes. Ha már úgyis sütni kell és stencilezni, gyorsulásmérőnek az MPU9250 típust választottam.

 

COM modul

Egy RA-01SCH-P típusú 915 MHz-es LoRa adóvevőt hordoz, ami egy USB-n csatlakoztatott földi állomás számra továbbít adatot több mint egy kbps sebességgel és várhatóan néhányszáz milliwattal. Ehhez már az 5 voltos tápfeszre is szükség lesz, amit több, mint egy amperrel rángathat lora módban.

Az MCX csatlakozóval induló antennarendszer sugárzójaként egy flexi panelből kialakított j-pole, vagy egy sima koaxiális antenna szolgál majd, teljesítménnyel túl lehet tolni annyira, hogy az az egy-két decibel ne számítson elhanyagolható irányhatás mellett.

 

BUS modul

Ugyan aktív elemet nem hordoz, de azért több egy sima vezetéknél. Itt a vastagsággal nem lehet kalkulálni, így a buszokat összekötő szálak – felxibilis nyák – kialakítása szerint minden adatvezetéket egy földelés, vagy nem releváns szál követ majd. Szintén kialakításból adódó árnyékolást kap a tápfeszültség vezetéke.

A könnyítés érdekében ugyancsak hajlékony panellel csatlakoznak azok a perifériák, amiket nem kell feltétlenül hordoznia a berendezésnek. Ilyen a töltés csatlakozója, a boot üzemmód vagy a reset kapcsolója. Érdemes eljátszani a gondolattal, hogy egy gomb állítsa le a program futását is. Nem árt ugyanis, ha nincs adathiba a lekapcsolás miatt.

A buszvezeték hosszát előzetes számolás után inkább meg is mérném a demonstrációs modellen, ugyanis tartok tőle, hogy a behajtogatás miatt figyelembe kellene venni a rugalmasságát is, mint a pinheadek közti távolság egyik tényezőjét. Mivel mindent egybevéve (adat, táp, szervíz és töltés/kapcsolás) elég sok ilyen kábel lesz, ezek egy gyártási periódusban készülnek el, elég drága lenne kísérletezni.

Ha már töltés: a töltőcsatlakozó egyben a főkapcsoló is: ha egy apró link van rajta, akkor indul a program, de ha a töltővezeték, csak az akksi töltődik. Egy másik kábel pedig a tesztüzemhez ad tápfeszültséget. A próbapadon nyilván úgy fog kinézni az egész, mint egy bypasson lévő beteg, de tesztelni kell, ennyi pedig a látvány kedvéért is belefér.

 

CAM modul

Attól tartok, már bőven meghaladtam a 95 grammos határt, és a modulok második verziói nem is az elektromos javításokról, hanem a könnyítésekről, kivágásokról fognak szólni. Ha marad súly, a vezérléstől teljesen független – vagy legfeljebb az első loopban indított – készre szerelt ESP32 kameramodult fog kapni IIC-n kiegészített SPH0645 digitális mikrofonnal, ami teljesen autonóm irányítás és élőkép közvetítés mellett kártyára rögzít. Az ő 2,4 GHz-es antennája mindenképp ragasztható fólia lesz csak.

 

Földi egység

A telemetriát egy újabb LoRa modul veszi majd. USB-n keresztül csatlakozik a számítógéphez, amin egy monitoring szoftver fut. Tápfeszültség tekintetében könnyebbség, hogy neki adnia – legalábbis alap üzemmódban – nem kell. Mivel szervízmódban egyébként is egy csomó vezeték áll majd ki a szerkezetből, ez várhatóan nem is fog változni. Antennát nem szeretném túlgondolni, egy 4G-s szektorsugárzó tökéletesen megfelel: pont annyi irányhatása van, hogy legalább a hátulról jövő zavarokat csillapítsa, de nem kell követni az elrepülő rakétát.

 

A küldetés és az AI

Próbálkoztam a mesterséges intelligencia alkalmazásával. Eleinte csak a szenzorok kiválasztásához kértem összehasonlító táblázatokat, majd radar chartokkal akartam néhány döntést meghozni, de eddig már nem jutottam el. Ettől függetlenül derült ugyanis ki, hogy fogalma sincs a pókháló lényegéről a döntéshozatalban, előtte azonban azzal kellett szembesülnöm, hogy a kommunikációval kapcsolatos, az adatátvitel sebességére és a visszatérésre vonatkozó számításai is hibásak.

Szembesítettem a tévedésével, elnézést kért, de ezután több olyan eredményt is kiadott, ami egy szóráson belül volt, így teljesen megbízhatatlannak kellett minősíteni.