課程手冊

立方衛星設計與實作 — STK 課程手冊

課程:清華大學太空科學與工程研究所 · 立方衛星設計與實作
貫穿主線:單一 FIREYE 火山觀測 CubeSat 任務,逐週疊加分析,期末成完整任務報告

一、課程設計理念

1.1 單一任務主線

全學期圍繞一個 CubeSat 任務:對美國境內活火山成像、提供噴發早期預警。每週往同一個
STK 場景疊一層分析,期末自然長成一份完整的任務分析報告(對應 AGI 官方 SmallSat Series 的教學邏輯)。

任務逐週演進:
- Week 4 選軌道 → Week 7 配電力 → Week 8 定姿態 → Week 10 規劃機動 →
Week 11 開通訊鏈路 → Week 12 做資料預算 → Week 14 排通聯 → Week 15 規劃發射

1.2 工具分工三層

原則:凡 STK 能做的用 STK 主導;STK 先天不做的(結構/熱/系統工程管理)用開源補位;
兩者都能算的,讓學生用兩種方法互相驗證,培養工程判斷。

本課程用到的 STK 付費模組為 Astrogator、Aviator、Communications;
SOLIS(閉迴路電力/姿態模擬)是獨立附加產品,不一定包含在一般組合內 ——
影響 Week 8 能否用 STK 做完整 ADCS 模擬;若無,Week 8 用 Python detumbling
+ STK 3D 視覺化替代(見該週實驗單)。

各校可用的模組組合不同,請依實際環境調整;本手冊刻意不記錄特定機構的授權狀態。

二、逐週實驗總覽

三、各週實驗單

Week 1–2 導論與系統架構 ○

載入現成 FIREYE 情境,認識物件瀏覽器、3D/2D、時間軸;用 access 結果當「coverage 換 volume」的量化輸入。
交付:場景導覽 + 系統架構初步權衡。

Week 3 系統工程:任務預算表

工具:Python/pandas | 檔案:week3_mission_budgets.py → week3_budgets.png
內容:質量/功率/鏈路/資料四大預算 + margin 管理。物理量由各週 STK 結果填入。
步驟:改各表數字看 pass/fail 翻轉;把 Week 7/11/12 的 STK 結果串接進來。
評分:四表正確 40% / margin 管理 30% / 與 STK 串接 30%

Week 4 任務規劃與軌道選擇 ◎

工具:STK Analyzer | 檔案:Lab1OrbitDesign_Connect.m、FIREYE_Volcano_FullScenario_Connect.txt
內容:掃描 (a, i) 找最大火山 access,對照 Lab1 最佳解;比較發射載具軌道。
評分:掃描完整 30% / 最佳解 30% / 載具比較 20% / CONOPS 20%

Week 5 結構與機構:FEA + 發射振動

工具:CalculiX + Python | 檔案:week5_fea_launch_vibe.py、cubesat_panel_modal.inp
內容:面板模態分析(自然頻率 vs 發射要求)+ GEVS 隨機振動響應(GRMS、傳遞率)。
基準案例 FAIL(71 Hz < 100 Hz),Part B 設計迭代到 PASS,Part C 用 CalculiX 3D 驗證。
評分:基準判讀 25% / 設計迭代 30% / CalculiX 對比 30% / 討論 15%

Week 6 熱管理:節點熱網路

工具:Python + STK 日照時間線 | 檔案:week6_thermal_network.py → week6_thermal.png
內容:6面+內部節點熱網路 ODE,吃 STK 日照/地影當熱輸入開關。基準電池 FAIL(低於0°C),
Part B 熱控迭代,Part C 接 STK 真實日照。
評分:基準判讀 25% / 熱控迭代 30% / STK 日照接入 30% / 討論 15%

Week 7 功率系統 ◎

工具:STK Solar Panel Tool | 檔案:FIREYE_SolarPanel_Connect.txt
內容:軌道發電曲線 + 功率收支;三種太陽能板/電池選型;FIREYE vs FIREYEPosX 構型。
評分:發電計算 30% / 收支分析 30% / 選型 25% / 構型比較 15%

Week 8 姿態確定與控制

工具:Python + STK(SOLIS 若有) | 檔案:week8_detumble_stk_integrated.py → .png + .a
內容:B-dot detumbling 閉迴路,姿態輸出成 .a 檔餵回 STK 看 3D 動畫。
磁場模型用 USE_IGRF 切換,結論差很多:IGRF-13 八圈消旋 80.3%(末 0.87 °/s)、傾斜偶極 99.1%(末 0.04 °/s)——偶極模型高估 B-dot 效能。兩個都跑,討論差異來源。
評分:基準判讀 25% / 參數研究 30% / STK 3D 串接 25% / 討論 20%

Week 10 推進系統 ◎(STK 主軌)

工具:STK Astrogator(主)+ Python(驗證)
檔案:week10_propulsion_astrogator.txt(MCS)、week10_propulsion_deltav.py
內容:Astrogator MCS + 差分修正器求三次 burn 的 delta-V —— 抬遠地點、圓化、
deorbit(降近地點至 RE+50 km);精確含攝動。Python 解析先估量級驗證。
實測對照:41.8 / 41.6 / 143.3 m/s(Python,總 233.0)vs 38.97 / 38.99 / 140.56 m/s
(STK,總 218.5),差 6.2%,來自兩體 vs HPOP 攝動。軌道維持的 6.2 m/s 是年度預算,
沒有對應的 MCS 段。
驗證段:week10_verify.py —— 42 項(36 PASS / 6 SKIP),補上 23 條結構指令的
回讀死角:MCS 段序、停止條件、修正器是否 Converged、三次 delta-V 對照解析值。
評分:MCS 建構 30% / 差分修正 25% / Python 驗證對比 25% / 推進選型 20%

Week 11 通訊系統 ◎

工具:STK Comm | 檔案:STKSat_Comm_Connect.txt
內容:UHF 下行/VHF 上行雙向鏈路;Link Budget Detailed 報告;餘裕 ≥ 3 dB;RF 環境(雨衰/大氣)。
驗證段(試點週):week11_verify.py —— 把腳本設過的每個值回讀比對,並用最差 Eb/No
確認餘裕 ≥ 3 dB。37 項全 PASS(最差 Eb/No 47.12 dB,餘裕 37.52 dB)。
這一段在導入時抓出三個既有錯誤:Model.DesignFrequency 屬性不存在、設定天線型別會沖掉
先前寫的 DesignFrequency、以及 STKSat 沿用 Lab1 掃描起點(250 km / i=0)導致鏈路
完全沒有 access —— 三者都是 0 個 NACK 的靜默失敗。共用工具在 tools/stk_verify.py。
評分:鏈路預算 30% / 餘裕驗證 25% / 環境模型 25% / 都卜勒 20%

Week 12 酬載與資料處理 ◎

工具:STK + Python | 檔案:FIREYE_Volcano_FullScenario_Connect.txt、week12_data_budget.py
內容:直接讀 Week 4 產生的 C:\STK_Reports\imaging_access.txt / downlink_access.txt
(樣式名為 "Complete Chain Access"),四段輸出對應四項評分:access 統計、每日資料預算、
記錄器填充曲線、成像速率掃描找不溢出上限。基準(FullScenario 獨立執行、7 天窗):
成像 58 窗 / 下傳 42 窗,產生 0.950 vs 可下傳 1.517 GB/day,峰值 1.249 GB(25%),
不溢出上限約 10 Mbit/s。注意報告內容取決於場景時間窗 —— 若沿用 Lab1 的 14 天窗
會變成 112/79 窗。沒有 STK 時退回本資料夾的
sample_access.csv(由真實報告匯出),並在主控台明講用了哪個來源。
評分:access 25% / 資料預算 30% / 儲存曲線 25% / 速率優化 20%

Week 13 軟體與自動化

工具:STK Python 物件模型 | 檔案:fireye_volcano_python.py
內容:用 agi.stk12 / ansys.stk.core 物件模型自動化建場景、排 access、產報表。
教 Connect 字串 vs 物件模型的分工;單位陷阱(Connect 公尺 vs 物件模型公里)。
評分:物件模型 30% / 自動化流程 30% / 資料提供者取數 25% / 討論 15%

Week 14 整合測試與運作

工具:Python(sgp4)+ STK 交叉驗證 | 檔案:week14_pass_scheduler.py → week14_passes.png
內容:從 TLE 算地面站通聯窗(AOS/LOS/最大仰角);與 STK access 互相驗證;排下傳時刻表。
評分:pass 計算 30% / 時刻表 25% / STK 交叉驗證 30% / 與資料預算串接 15%

Week 15 發射與部署 ◎(STK 主軌)

工具:STK Aviator + Astrogator(主)+ Python(驗證)
檔案:week15_launch_aviator.py、LaunchVehicleTradeStudiesAviator.py、week15_launch_deploy.py
內容:Aviator 兩節火箭 trade study(掃燃料×方位×FPA rate),讀入軌 apogee/perigee/inclination,
perigee > 100 km 判有效入軌;或 TASA 彈道發射軌跡。Python 火箭方程先估酬載量級驗證。
部署後接 Week 14 算首次通聯。
評分:Aviator trade 30% / 入軌判定 25% / Python 驗證 20% / 首次通聯串接 25%

Week 16 整合展示:從一顆到一個星座 ◎

工具:STK Coverage(主)+ Python 解析模型
檔案:week16_walker_coverage_Connect.txt、week16_constellation_tradeoff.py
內容:用 CoverageDefinition + RevisitTime FOM 量化「一顆 FIREYE 夠不夠」。
實測(2 天窗、美西 90 格點):單顆平均重訪 19.10 hr(最差格點 48 hr),
Walker 3×4 降到 1.75 hr(最差 2.05 hr)—— 12 倍衛星只換到 10.9 倍改善,
且星座真正的價值是把服務品質變均勻。Python 解析模型系統性低估約 6.5 倍,
但兩個案例的比值一致,校準後可便宜地掃描規模:3 hr 目標約需 7 顆。
以此接續討論巨型星座、在軌服務、深空 CubeSat。
評分:Coverage/FOM 30% / Walker 參數研究 25% / 解析對照 25% / 架構決策 20%

三之一、基礎知識導論(primers/)

每一週的實驗之前,都有一份 primers/weekNN_primer.md 當觀念底稿。
它處理的是「會做」與「知道為什麼這樣做」之間的落差 ——
沒有這一層,實驗容易退化成照抄指令。

固定七節:(1) 這一週在解什麼問題、(2) 核心觀念(帶公式與典型數值)、
(3) 名詞與符號表、(4) 觀念與本週腳本的逐項對照、(5) 常見誤解、
(6) 延伸閱讀(外部連結,全部經過連線驗證)、(7) 課前自我檢核 5 題。

教學用法建議:第 7 節的自我檢核題可以當課前小考或討論題;
第 5 節的「常見誤解」多半直接對應本教材實測踩過的坑,適合當開場的反例。

導論已收進各週 notebook(標題之後、實驗之前)與課程 PDF 的每一章開頭;
primers/README.md 另有全課程通用的外部資源彙整(標準、資料庫、工具、教科書)。

三之一之二、七個獨立章節

除了 16 週的立方衛星主線,本教材另有七個獨立章節,不併入課程週次。
它們借用同一套方法論(STK 主導、Python 補位、ACK 不等於生效),題材換成
地面雷達、紅外線預警、發射交會、地形傳播、次軌道飛行、地月轉移與
工具鏈通聯 —— 適合當專題、選修或示範材料。

(標題原本寫「四個」而表格已有六列 —— 那是新增章節時漏改的,一併修正。)

每章各有導論、實驗單、Python 分析與驗證段;多數另有 Connect 腳本、
notebook 與 HTML 展示頁。所有數值均為 STK 12.10.0 實測。

教學用法:七章各自獨立,可單獨指派。它們共同示範的是同一件事的多種面貌 ——
工具會 ACK、會回讀、會產生報告,但那都不等於它算對了、甚至不等於它算了。

驗證段完全不碰 STK(協定常數、API 名稱、診斷邏輯、封包格式、攢批算術、
DOP 的數學恆等式都不在 STK 裡),所以適合當作沒有授權時的備案,
或當作「工具鏈本身也要驗」的示範。需要 STK 的檢查另外收在
grpc_link_stk_verify.py(27 項),驗的是 STK 自己:GPS almanac 給的星座、
Realtime 注入的往返完整性、存取約束有沒有生效,以及閉迴路有沒有真的改變飛行。
它也是唯一一章把自己的一個 bug 連同修正與回歸測試留在教材裡的:
原本用耗時分辨「連線被拒」與「逾時」,實測推翻了那個直覺。

tirem_coastal/ 值得單獨指派給高年級。 這一章的主角是一個
會通過驗證的錯誤結論:「TIREM 算不出結果」是錯的,
而它通過了 41 項全綠的驗證。該章把查證的方法本身變成主題,
整理出四種靜默失敗:

型態 D 最難察覺,因為 A/B/C 至少會讓你在某個環節看到異狀。抓到它的方法是
挑一個「該有明顯差異」的條件去改,然後看輸出動不動 —— 該章用 VHF
當對照,排除了「這是物理」的解釋。

三之二、驗證段:ACK 不等於生效

STK Connect 對絕大多數指令只回「收到」。本教材實測 396 條指令全部 ACK,
但真正能證明生效的只有一部分。因此每一週都附了 weekNN_verify.py
(共用工具 tools/stk_verify.py),把「有沒有生效」變成可執行、可評分的一步。

• 需要 STK 的週次:*_RM ... GetValue 回讀每個設定值 + 結構檢查 + 該週的物理判準。
• 純 Python 的週次:把實驗單寫死的基準數字變成斷言(例如 Week 5 的 71 Hz 基準 FAIL)。

結果分 PASS / FAIL / SKIP,離開碼 0/1,可直接進 CI。建議列入每週評分:
學生不只要跑出結果,還要能證明那個結果是他設定出來的。

導入過程中,驗證段在既有教材裡抓出數個 0-NACK 的靜默失敗:
Model.DesignFrequency 屬性不存在(Week 2、11)、設定天線型別會沖掉先前寫的設計頻率、
Week 11 沿用 Lab1 掃描起點導致鏈路完全沒有 access、Week 4 的 SolarPanel DeleteData
會讓 Week 7 的發電計算產出空報告、Week 2 原本 2.5 小時的分析窗使成像 access 為 0。

三之三、Jupyter Notebook

16 週各一本獨立 notebook,放在對應的週次資料夾。內容由該週的 .py / .txt 轉出,
原始腳本保留不動。需要 STK 的週次請用桌面版 —— 無介面的 STK Engine 會拒絕
Animate、Graphics ... SetColor、VO ... SolarPanel 等 18 條指令。

四、Final Project(40%)

用 FIREYE 火山任務貫穿全學期的分析,整合成完整任務報告:
1. 任務需求與 CONOPS(Week 3,4)
2. 軌道設計與覆蓋分析(Week 4,16)
3. 結構與熱可行性(Week 5,6)
4. 電力/姿態/推進/通訊子系統(Week 7,8,10,11)
5. 資料與運作規劃(Week 12,13,14)
6. 發射與部署方案(Week 15)

評分:分析完整性 30% / STK+Python 工具運用 25% / 工程判斷 25% / 報告與簡報 20%

五、檔案清單

STK Connect 腳本:
- eSatellite_STK_Connect.txt(Week 1-2 情境)
- FIREYE_Volcano_FullScenario_Connect.txt(Week 4,12 完整場景)
- FIREYE_SolarPanel_Connect.txt(Week 7 發電)
- STKSat_Comm_Connect.txt(Week 11 通訊)
- week10_propulsion_astrogator.txt(Week 10 機動 MCS,含 deorbit)
- week16_walker_coverage_Connect.txt(Week 16 Walker 星座 + Coverage/FOM)

Python 可跑腳本(附出圖):
- week3_mission_budgets.py / week5_fea_launch_vibe.py / week6_thermal_network.py
- week8_detumble_stk_integrated.py / week10_propulsion_deltav.py
- week14_pass_scheduler.py / week15_launch_deploy.py

STK Python 物件模型:
- fireye_volcano_python.py(Week 13)
- week15_launch_aviator.py(Week 15 Aviator trade)

現成參考範例:
- Lab1OrbitDesign_Connect.m(Week 4,MATLAB)
- LaunchVehicleTradeStudiesAviator.py(Week 15,AGI 官方 Aviator trade study 原版)
- TASA notebook(未收錄於本 repo)

驗證段(每一支都獨立可跑,回讀 STK 的實際狀態而不是看 ACK):
- 全部 15 週各一支 weekNN_verify.py(Week 9 期中考無實驗,故無)
- 連 STK 的七支(01、02、04、07、10、11、13)開頭會 CloseScenario(),
跑之前要先確認當下沒有別的場景在用
- 其餘八支(03、05、06、08、12、14、15、16)不需要 STK,可直接跑

不需要 STK 的三支守門(改完程式或文件後跑一遍,離開碼 0 = 一致):

六支都各自對真實發生過的錯誤驗證過 —— 不是只對假想的錯誤。

notebook 的輸出:python tools/run_notebooks.py 執行不連 STK 的七本
(week03/05/06/08/09/12/14)並把輸出存回去,學生打開就看得到結果。
連 STK 的九本(week01/02/04/07/10/11/13/15/16)預設跳過 ——
它們會 close_scenario() 或 NewScenario,跑下去會關掉當下載入的場景。
要跑得加 --stk,而且要先確認 STK 裡沒有別的場景在用。

輔助工具:
- tools/stk_verify.py(「ACK 不等於生效」的驗證工具,Week 11 為導入試點)
- tools/storage_vs_time.py(記錄器積分的共用工具,由 Week 12 的 Lab 匯入;
原本 Week 7 與 Week 12 各有一份完全相同的複本,已合併為單一份)
- cubesat_panel_modal.inp(Week 5 CalculiX deck)

六、環境需求

• Integration(Python API)。Connect Server 啟用(Edit→Preferences→Connect,port 5001)。

Python 端:numpy, scipy, matplotlib, pandas, sgp4;選配 pyIGRF/ppigrf(Week 8 真實地磁)、
agi.stk12 或 ansys.stk.core(Week 13,15 物件模型)。結構週:CalculiX(ccx)+ cgx/PrePoMax/ParaView。

報告輸出:報告目錄由 tools/stk_paths.py 統一定義(預設 C:\STK_Reports\,可用環境變數 SMALLSAT_STK_REPORTS 覆寫 —— 但 Connect 腳本是靜態文字、不會跟著變)。
這個資料夾要先存在,ReportCreate 寫不進去不會吭聲,拿到的會是空的分析。建起來:

python -c "import sys;sys.path.insert(0,'tools');import stk_paths;print(stk_paths.ensure_reports_dir())"