不等間隔なセンサデータのFFTについて

[NewNotMoon]

調査内容

問題点

• 離散フーリエ変換(DFT)並びにFFTは等間隔にサンプリングされた信号に対して処理するアルゴリズム
  • センサデータは等間隔では取得できない
  • 可能な限り、というのは可能だが、どうしても間隔が空いてしまうことがある
    • 端末の処理能力、通信速度、etc...
  • 流れてきたデータを無理やりぶち込んで解析しては精度が非常に悪い(というか、そもそも正しくない結果になる)

参考文献

不等間隔データのフーリエ変換 / 白川 利昭 先生
https://otsuma.repo.nii.ac.jp/?action=pages_view_main&active_action=repository_view_main_item_detail&item_id=5759&item_no=1&page_id=29&block_id=56

他にもLomb-Scargle ピリオドグラムアルゴリズムなども発見したが、付け焼き刃で実装できるものでも理解できるものでもないので諦め。天文学レベルの精度は不要なので、それっぽく幅を合わせる。

参考文献では、根本的にFFTの処理方法に着目し、積分を近似する手法

• 既存のライブラリが使えない
• アルゴリズムを理解しないといけない、自前で最適化しないといけない
• 台形積分近似なら実用レベルの精度だと言及されている
• 可能なら原理を理解して精度を上げたいが、リリースまで一ヶ月しかないので諦め。

考えうる無難な対策

むりくり幅を合わせる。

サンプリング周波数をT(Hz)として、n/Tにおける値を近い値から推測する。
変化率等考慮するか、単純に線形補間するか。誤差があまりに大きくても困るので、調査、実験が必要。

[NewNotMoon]

線形補間して変換してみた結果

サンプリング周波数がセンサデータの取得周波数より低い場合は、線形補間でもかなりの精度を得られるのがわかった。

• 赤線は送られてきた不等間隔のデータを等間隔に並べたもの
• 青線は赤線をLPF変換したもの
• 黄線は送られてきた不等間隔のデータを等間隔に変換したもの
• 緑線は黃線をLPF変換したもの
• 下のヒストグラムは無視して良い

赤と青は横軸が意味をなしていないものの、だいたいどことどこが対応しているのか理解できるレベルで間隔変換が精度よく行えている。

サンプリング周波数が更に大きくなると誤差が大きくなると想定できるが、現時点ではゲームにおいて問題がないレベルだと思われる。

実際のところ、安定して通信速度をこれ以上上げるのはなかなか厳しい。となるとセンサデータ取得の頻度はそこで頭打ちするし、それによる誤差はどうしようもない。
となればその誤差のあるデータと遜色ないレベルであれば、現時点でできる精度としては十分だと考えて問題無いだろう。

[NewNotMoon]

深刻なバグと、通信速度の実態が判明。

バグ内容

• 受信間隔が遅すぎて、受信nから受信n+1になる間にサンプルポイントを何十個も超えているが、それに対する処理がされていなかった

256Hz、点数256の超過数のログを取ったところ、_約17~40のサンプルポイントをスキップしていた_。毎フレーム明らかに超えてしまっている。

調整の末、まともにサンプルできたのは**_16Hz**_だった。つまり、受信間隔は16Hzだということになる。
サンプリング周波数が16Hz(実際にはこれ未満だが)だとすると、実際にFFTして得られる周波数帯域は約6Hzまでとなる。

はっきりいって精度は最悪に近い。

[NewNotMoon]

Bluetoothの最大実効速度が非対称通信で下り723.2kbps/上り57.6kbps、対称通信の場合は432.6kbps程度。
現時点で、(ヘッダ情報等を除いた)通信のデータサイズは、約600byte(≒0.6kbyte≒4.8kbit)程度ある。サイズは毎フレーム変化する。

16Hzなので、16*4.8=76.8kbps。大雑把だが無難な数値ではある。Bluetooth自体の限界か。
出来るとしたら通信内容の圧縮だろうか。

[prprhyt]

ダメ元ですが、Windows側のボーレートを上げてみてください。
デバイスマネージャー->ポート->Bluetooth リンク経由の標準シリアル(こちらの環境ではCOM3でした)
を右クリック->プロパティ->ポートの設定->ビット/秒
から変更することができます。
調べた範囲だと、Android側は自動で合わせるようです。

[NewNotMoon]

既にマックスです。

[prprhyt]

😭

[NewNotMoon]

送信列が数値とカンマしかないので、圧縮の余地があるはずです。
Bluetoothで、今は文字列で送っていますが、生のバイナリ列で送信することは可能なら圧縮して送りましょう。いや、文字列だとしても圧縮して送りましょう。

とりあえず圧縮で速度に改善が見られるかというところです。

[NewNotMoon]

センサデータの補間そのもの自体は線形補間で進めます。
速度改善は別途Issueを立てますのでこちらは閉じます。