!!未レビュー!!

# 撮像・画像取得系設計根拠 (Camera & Image Acquisition Rationale)

> [!NOTE]
> **ドキュメントのスコープ**
> 本資料は、模擬衛星における「カメラモジュールの選定」、「マイコン内部（RP2040のRAM）への画像データの取り込み方式」、および「ウォッチドッグタイマーによるリセットを回避するための画像データ分割送信制御」の設計判断に関する合理的根拠をまとめたものです。画像認識アルゴリズムや光学レンズの焦点調節機構は対象外とします。

---

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

### ① カメラデータ転送とバス帯域の基本原理
デジタル画像データは、VGA（320×240）グレースケールであっても **76.8KB** のデータサイズを持ちます。これを処理するマイコンシステムでは、画素同期信号（PCLK: Pixel Clock）の立ち上がりに同期してデータバス上のビット値を読み出す必要があります。PCLKが高速な場合（数MHz〜数十MHz）、通常のCPU命令によるポート読み取り（ソフトウェアポーリング）では、CPUの命令実行サイクルが追いつかず、ビット落ち（データの欠損）や画像同期崩れが発生します。

### ② ウォッチドッグタイマー (Watchdog Timer: WDT) とシステムフリーズ
宇宙環境で動作する衛星は、放射線等によるCPUハングアップ時にシステムを自動回復するための **WDT** を備えています。WDTは、プログラムが一定時間内に「タイマークリア（キック）」を実行しないと、CPUが暴走またはハングアップしたとみなしてハードウェアリセットをかけます。長時間のブロッキング処理（例：大容量画像の連続送信）を行うと、メインループが停止し、WDTクリアが実行されずに意図しない強制リセットがかかる重大な問題（バグ）となります。

---

## 2. 候補の列挙とトレードオフ分析

### 【カメラモジュールインターフェース】候補の比較
*   **候補A（SPI カメラ）**: モジュール側にSRAMバッファを持ち、低速なSPIシリアルバスで少しずつ画像を読み出す。
*   **候補B（USB カメラ）**: UVC（USB Video Class）規格に対応したカメラを接続する。
*   **候補C（並列バス＋I2C制御カメラ: OV7675） [採用]**: 8ビットパラレルデータバスと同期信号（VSYNC/HREF/PCLK）を使い、I2Cでコマンド制御を行う。

| 評価項目 | 候補A (SPIカメラ) | 候補B (USBカメラ) | 候補C (並列I2C: OV7675) [採用] |
| :--- | :--- | :--- | :--- |
| **データ取得速度** | 低 (シリアルバスによるボトルネック) | 高 (高速USB伝送) | **高 (8bitパラレル同時取得)** |
| **マイコン側の実装難易度**| 低 (SPIコマンドを叩くだけ) | **極めて高** (USBホストスタックの移植が必要) | **中 (同期信号を捉えるロジックが必要)** |
| **部品コスト** | 高 (バッファメモリ搭載のため高価) | 中 | **低 (安価で入手性が極めて高い)** |
| **教育教材としての価値**| 低 (低レイヤー制御がICに隠蔽される) | 低 (WebAPIに近い高レイヤー) | **極めて高 (タイミングチャートの理解が必須)** |

---

### 【マイコン内部データ転送】候補の比較
*   **候補A（CPU ポーリング方式）**: CPUの `while` ループで PCLK ピンの立ち上がりを検出し、その瞬間にポート入力を配列に保存する。
*   **候補B（PIO ＋ DMA 方式） [採用]**: 専用I/Oプロセッサ（PIO）が同期信号を捉えてバッファに詰め、DMAがCPUを介さずに自動でRAMへ転送する。

| 比較項目 | 候補A (CPU ポーリング) | 候補B (PIO + DMA) [採用] |
| :--- | :--- | :--- |
| **CPU 負荷（撮像中）** | **極めて高** (100% 占有し、姿勢制御等が一時停止) | **ゼロ** (バックグラウンドで自動転送) |
| **ビット落ち・同期崩れリスク**| **極めて高** (他割り込みの発生で即データ欠損) | **ゼロ (ハードウェアによりタイミング同期が完全担保)** |
| **動作可能クロック限界** | 低 (PCLK 数MHzが限界) | **高 (PIOの動作クロックまで追従可能)** |

---

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

### ① PIO＋DMA による「フリーズのない確実な画像取得」
*   **根拠**: 衛星姿勢制御ループ（200Hz）を破綻させず、かつクリアな地球画像（320×240）を取得するため、RP2040固有のコプロセッサであるPIOとDMAの連携（候補B）を採用しました。これにより、CPU負荷を完全にゼロに抑え、画像データ取得中であっても姿勢制御や地上コマンド監視などの最優先タスクを全く遅延させることなく（防御的設計）、正確に画像バッファを構築することが可能になります。

### ② 毎ループ32バイト分割非ブロック送信による WDT リセットの「防御的回避」
*   **画像送信制御の設計根拠**:
    76.8KBの画像を一度に Wi-Fi 送信ソケット（`wifi_write`）に書き込むと、送信完了までに約2秒間のブロッキング（プログラムフリーズ）が発生し、WDTの監視リセットが作動して衛星が無限ループリセットに陥ります。
    この致命的バグを防御的に回避するため、画像を「毎ループ32バイト」ずつ細分化して送信する非ブロッキング状態管理（候補B）を採用しました。画像全体の送信完了には約10秒を要しますが、1周あたりのWi-Fiオーバーヘッドをミリ秒以下に抑えることで、WDTのクリアと姿勢制御の定周期実行を両立し、ミッション継続を担保する合理的設計判断です。

---

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

### ① カメラ内部レジスタ設定（OV7675レジスタマップ）のブラックボックス化
*   OV7675カメラには、色ゲイン調整、露光時間、AGC（自動ゲイン制御）、ホワイトバランスなどの調整用に数百個の内部レジスタが存在します。本プロジェクトでは、起動時にメーカーが提供する「推奨値のレジスタ設定テーブル（初期化配列）」をそのままI2C経由で流し込み、個別のピクセルレジスタ調整ロジックは実装しません。
*   **割り切りの根拠**: 画像センサ内部の画質調整アルゴリズムをチューニングすることは本宇宙ミッションの主目的ではないため、推奨値をそのまま信頼可能なブラックボックスとして扱い、ソフトウェア側の「タイミング制御とパケット送信」の開発に注力します。

### ② RP2040 DMA コントローラのハードウェア制御のブラックボックス化
*   DMAコントローラが内部AMBAバスを介してRAMのデュアルポートにアクセスする際の「バスマルチプレクス優先順位」や「メモリ調停ロジック」は、Pico SDKおよびRP2040のハードウェア内部機能に完全に依存し、ソフトウェア側では意識しません。