Wii速度計第弐話「誤差の源」
2015/10/25
３夜連続更新（予定）でお届けする、Wiiリモコン速度計開発の記 第弐話
前夜エントリで速度計をとりあえず作ってみたが、速度があっているのか分からず、簡易記録機能は誤差らしきものが大きく使えないというありさまだった。
少しは改善できないかとの検証エントリ。
問題を把握確認するために、記録モードでデータを書き出す。書き出すデータは、
Timercount1 … いわゆる、時刻
velocity … いわゆる、その時刻の速度（と思われれる値）
Timercount1 … 時刻。再度。
Timercount2 … 前回の時刻。
l1 … 現在の位置座標
l2 … 前回の位置座標
Timercount1,2は関数Timegettimeで取得します。
これで言うと、速さv = (l1-l2)/(Timercount1 – Timercount2)となる、はず。さて、問題はどこに。
・以下、検証・
書き出されたdata.csvファイル（一部加工）
とりあえず、ほぼ50ms間隔でデータは来ているらしい。前回エントリでは問題を感じつつ、Timegettimeを使わずに、経過時間として単純にTimer.Intervalを使っていた。しかし、少なくとも間隔50msではその影響はほとんどない、ということか。
そして一応、速さv = (l1-l2)/(Timercount1 – Timercount2)は成り立っているようで、計算間違い的誤作動ではない。、と。
data.csvのグラフ化。１．v-tグラフ。
一定の力を物体に加えて運動させた場合、直線になるはず。しかし、1000ms以降荒れ、2000ms以降大荒れ。少なくとも、何らかの要因で速さ0.3m/s = 15mm/50msを越えるところ、あるいは2000msを超えるところで値が安定しないことは確からしい。
２．x-tグラフ。
2000ms以降荒れるということは、距離の観点から言ってセンサーバーからの距離900mm前後から不安定化していたということが分かります。
３．2000ms以降拡大！
縦で見ると、赤と青の差が大きかったり小さかったりで結構ばらつきが出ている。これでは、v-t図が荒れるのも無理はない。ただし、引きで見ると、グラフ②なんかはちゃんと２次関数のグラフになっているだから、位置座標が根本的に間違っているわけではない。しかし、「位置座標l1,l2の不安定さがl1≒l2でのl1-l2という処理で顕在化している」といったあたりが、ばらつきの原因であると思われます。
ではそもそも、l1やl2といった値が、なぜ > 2000ms, > 0.3m/s, > 900mの状況で不安定なのかについては未だ検証できず。ただ、このグラフ（ネタ元は2011.1.11のエントリ）
で言うところの、900mm以遠は変化が少ない平坦な領域に差し掛かるから…というのが、今のところの理解。
センサーバーのLED間隔を離せば改善が期待できる…のか？
しかし、いずれにしても分解能0.4m/s2の加速度計同様、速度計もまた、一癖二癖ありそうである。
せめて簡易表示はまともにしたい。そこで考えるべきは、
I 位置座標の精度は悪くない
II 高校物理の場合、１次元運動でv-tグラフを描く場合の大半が等加速度運動
ということ。50ms間隔で計算した値をそのまま表示せずに、数100ms間隔での平均の速さを表示した方がいいのでは？との示唆を得た試みだった。