解説:テレメトリ ― BLE で飛行データを送り切る設計

執筆者:

カテゴリ:

,

SLEIPNIR-ZERO の機体は、飛行中のセンサ計測値を BLE で地上へ送り続けます。この記事では、テレメトリ送信機のハードウェア構成と、限られた無線帯域で「送り切る」ための設計を解説します。

ハードウェア構成

部品役割
Raspberry Pi Pico 2 W(RP2350)デュアルコア Cortex-M33 マイコン。無線チップ CYW43 で BLE を担う
BME280気圧・気温・湿度センサ。気圧から高度を推定する
BNO0559軸 IMU(加速度・角速度・地磁気)。姿勢と加速度を計測する
WS2812フルカラー LED。機体の状態を色で表示し、離れた場所から目視確認できる

2つのコアは役割分担しています。core1 がセンサの I2C 読み出し専任、core0 がセンサ融合と BLE 送信の担当で、コア間はロックフリーのリングバッファでつながっています。読み出しの取りこぼしを融合や通信の負荷から切り離すための構成です。

センサからcore1(読み出し専任)、SPSCリング、core0(融合・送信)を経てBLEで地上局へ届くデータの流れ
Pico 2 W 内部のデータの流れ

何を送るか

現在飛んでいるのは 50 Hz のテレメトリです。気圧高度・融合高度・上下速度・姿勢(ロール/ピッチ/方位)・線形加速度・制御指令(エレベータ/ラダー/スロットル)などを 1 サンプル 1 行の形式で送り、地上局が CSV として記録します。

さらに、センサの生値をフルレートで降ろすバイナリストリームプロトコルを設計しています。チャンネル構成は次のとおりです。

チャンネルレート内容
加速度1000 Hz3軸 raw 値(int16 × 3)
角速度500 Hz3軸 raw 値(int16 × 3)
地磁気・気圧20 Hz3軸 raw 値/気圧+気温
STATUS1 Hz取りこぼし数・キャリブレーション状態・死活
CONFIG変更時スケール係数・レート設定の通知

生値を raw のまま送るのがポイントです。物理量への換算は PC 側で行い、換算に必要なスケール係数は CONFIG チャンネルで別途通知します。機体側の計算を減らせるだけでなく、換算で情報を落とさずに PC 側の大規模なフィルタ(EKF)へそのまま食わせられます。

帯域の収支

BLE の実効帯域は実測で上限 125 kbps 程度です。上の全チャンネルを合計するとフレーミング込みで約 85 kbps、上限の 68% に収まり、32% のヘッドルームが残ります。また 1 回の notification は 244 バイト以下に厳守しています(これを超えると無線チップが不安定になる実測既知の問題があるため)。

BLE帯域収支の積み上げバー:加速度48kbps、角速度24kbps、低レート系2kbps、フレーミング10kbpsの合計85kbpsが実測上限125kbpsの68%に収まる
帯域収支。実測上限に対して 32% のヘッドルームを残す

電波状況が悪化して帯域が細った場合は、チャンネルごとに間引き率を上げて縮退します(例:加速度を 1/4 の 250 Hz に)。機内の融合処理は常にフルレートで動き続けるので、最悪「ダウンリンクほぼ停止」までプロトコルを変えずに落とせます。

墜落してもデータは残る

機体内に記録するフライトレコーダ方式と違い、テレメトリは送信した時点でデータが機体を離れます。実験機にとって墜落は起こり得ることですが、直前までの計測値が地上に残っていれば原因分析ができます。0 号機の任務は教訓を集めることなので、これは設計上の重要な性質です。

リポジトリ

ファームウェアと地上局ツール(Python 製の受信 GUI・記録クライアント)は danfunc/flight_robocon_telemetory_sender で公開しています。ファームウェアの土台になっている自作カーネルについては「自作マイクロカーネル Shizuku」で解説しています。

コメント

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

WordPress Appliance - Powered by TurnKey Linux