# 衛星フライトソフトウェア設計 (Satellite Architecture)

> [!NOTE]
> **ドキュメントのスコープ**
> 本資料は、Raspberry Pi Pico W（C++ / Pico SDK）上で動作するフライトソフトウェア（FSW）の「メインスレッド実行モデル（制御ループ）」、「姿勢制御状態機械の構造」、および「撮像と送信処理の帯域設計」に関する設計判断と合理的根拠をまとめたものです。センサの電子回路インターフェースやPCB配線設計は対象外とします。

---

## 1. 一般論・基本原理の提示 (解空間の起源)

### ① 組み込みシステムにおけるタスクスケジューリング (RTOS vs Superloop)
リアルタイムシステムにおいて、複数の制御タスク（センサ読取、制御計算、通信、撮像など）を処理するためのスケジューリング方式には大きく分けて2つの一般論が存在します。
*   **プリエンプティブマルチタスク (RTOS)**: リアルタイムOS（FreeRTOS等）を用い、タスクごとにスレッドを立てて優先度に基づきコンテキストスイッチを行います。非同期処理のコードが書きやすい一方、スレッド間のリソース競合（レースコンディション）やデッドロックのリスク、コンテキストスイッチに伴うジッター（周期の揺れ）が発生します。
*   **協調的タイムスライシング (Cooperative Superloop)**: 単一スレッドのタイトな `while(true)` ループの中で、各タスクの処理時間を予測可能な範囲（タイムスライス）に収めて順番に実行します。メモリ消費が極めて少なく、スレッド競合が発生しないため確実な決定論的動作（Deterministic execution）が得られます。

---

## 2. フライトソフトウェア実行モデルの選定 (解空間の探索)

### 【FSWタスクスケジュールモデル】候補の比較
*   **候補A（FreeRTOS などのプリエンプティブマルチタスク方式）**: 通信タスク、制御タスク、センサタスクをそれぞれ別スレッドで実行する。
*   **候補B（決定論的シングルスレッド・スーパーループ方式） [採用]**: 200Hz（5ms）のタイマー割り込みまたは同期フラグに基づき、単一のループ内で順番に処理する。

| 評価項目 | 候補A (RTOSマルチスレッド) | 候補B (シングルスレッド・スーパーループ) [採用] |
| :--- | :--- | :--- |
| **メモリ（RAM）消費量** | 中〜高 (スレッドごとのスタック領域確保で256KBが逼迫) | **極小 (スタックが単一のため予測可能で軽量)** |
| **レースコンディション（バグ）**| **高** (I2C/SPIバスの同時アクセス保護が必要) | **ゼロ (バス競合が原理的に発生しない)** |
| **制御周期の確実性（ジッター）**| 低 (OSのスケジューラオーバーヘッド) | **極めて高い (5msの定周期性を完全維持)** |
| **学生デバッグ容易性** | 低 (マルチスレッドバグは再現性が低くデバッグ困難) | **高 (処理がシーケンシャルでブレークポイントが有効)** |
| **開発の初期コスト** | 中 (OSスタックおよび同期制御の実装が必要) | **極小 (標準的なwhile文とタイマーのみ)** |

---

## 3. 衛星フライトソフトウェアのメインループ構造

本プロジェクトでは、上記の比較に基づき「候補B」を採用しています。

```mermaid
flowchart TD
    A[WiFi コマンド受信・非同期パース] --> B[MCP3008 ADC 8ch 読み取り]
    B --> C[フォトダイオード値から太陽方向推定]
    C --> D[ICM-42688 ジャイロ角速度取得]
    D --> E[フォトリフレクタ RW 回転数推定]
    E --> F[姿勢制御 (PID / 状態機械) 更新]
    F --> G{撮像指示があるか & 画像送信中ではないか & 制御完了したか?}
    G -- Yes --> H[カメラ撮影実行・IMG ヘッダ送信\nimg_frame_sending = true]
    G -- No --> I{画像送信中 (img_frame_sending == true)?}
    H --> I
    I -- Yes --> J[32バイト分割データ送信\n全画像送信完了時に false へ]
    I -- No --> K[サーボモータ・ホイール駆動出力]
    J --> K
    K --> L{1秒経過 且つ 画像送信中ではないか?}
    L -- Yes --> M[地上局へテキスト形式でテレメトリ送信]
    L -- No --> A
    M --> A
```

---

## 4. 意思決定と選定根拠 (Justifications)

### ① バス競合とリソース破綻の「防御的回避」
*   **根拠**: RP2040の制限されたSRAM（256KB）環境下で、I2CやSPIのバス共有排他制御ミスによる「デッドロック（通信ハングアップ）」を防御的に回避するため、シングルスレッドのスーパーループ（候補B）を採用しました。すべてのペリフェラル（ADC, IMU, サーボ）へのアクセス順序が静的に確定しているため、同時アクセスの衝突が原理的に発生せず、極めて堅牢に動作します。

### ② 定周期制御（200Hz）とウォッチドッグのクリアの両立
*   **制御周期設計の根拠**:
    姿勢制御アクチュエータおよびセンサ（ジャイロ）の応答性を評価した結果、制御更新は200Hz（5ms）周期が最適です。
    スーパーループの各タスク処理時間は、Wi-Fi通信を除き 1ms 以下に抑えられています。これにより、ループが5ms以内で確実に1周し、姿勢制御の更新タイミングが乱れず、かつウォッチドッグタイマーの定期クリアが阻害されないため、自律安全性が担保されます。

### ③ 画像送信中のテレメトリ・サスペンド（帯域制限）によるフリーズの「防御的回避」
*   **画像送信設計の根拠**:
    画像（約76.8KB）の送信中、テキストテレメトリの送信処理を明示的に停止します。また、画像データはメインループ1周ごとに32バイトに細分化して送信ソケットに書き込まれます。
    Pico WのCYW43チップの送信バッファは極小であるため、一括書き込みはバッファオーバーランを引き起こし接続を強制切断させます。毎ループ32バイトの制限送信を行うことで、バッファ飽和（マイコンフリーズ）を防ぐ（防御的設計）と同時に、データのパケットを分離する地上側パーサーの複雑化（合理的簡素化）を避けています。

---

## 5. 合理的なブラックボックス化 (Rational Black-Boxing)

### ① Pico SDK（HALレイヤー）およびハードウェア初期化のブラックボックス化
*   RP2040のシステムクロック設定、PLL設定、GPIOピンマッピングの設定レジスタのビットマスク操作などは、Pico SDKの標準関数（`set_sys_clock_khz` 等）を完全なブラックボックスとして信頼し、レジスタの直接操作は行いません。
*   **割り切りの根拠**: チップ固有のクロック発振回路の初期化シーケンスに時間を費やすことは本ゼミのミッション目的から外れており、検証済みの公式SDKを信頼することで、学生は制御アルゴリズム（`control.cpp`）の開発に開発資源を集中できます。

### ② Wi-Fiチップ（CYW43）のファームウェアおよびドライバのブラックボックス化
*   Pico WのWi-Fiチップにロードされるファームウェアのバイナリデータ、SPIを介したCYW43とRP2040間の低レイヤーパケット通信プロトコルは、完全にブラックボックスとして扱い、Pico SDKに付属する `pico_cyw43_arch` ライブラリの関数経由でのみ制御します。