ドリフト

　おはよー！(外が！！暗い！！！)

***



　姿勢変化の時系列。各軸毎じゃないのであんまり意味ないけど。
　開始直後に一旦ドリフトが大きくなってるけど、その後安定し、少し経って急激にドリフトが大きくなってる。
　起きたのが16時前で、そこでストーブをつけているが、そのタイミングでドリフトが急減してるので、温度変化によるオフセットが大きいんだろう。
　恒温槽とかに突っ込んで温度計と一緒にデータ取って補正値出してやれば温度変化に対するオフセットはある程度減らせそうな気もするけど、どうだかなぁ。ミッション期間短くてある程度の電力と空間を確保できるなら、センサだけ断熱して+40℃くらいに加熱したほうが良さそうな気もする。
　そもそも国内の缶サットだとミッション時間短いし温度環境も割と良いので、起動時に動かさない状態で平均取ってオフセットすれば十分な気もする。ロケットに結合してから打ち上げまでの待ち時間が長かったりするので、その間のドリフトが怖いけど。ランチャ上で1分くらい機体動かないように固定してくれる運用とかあるといいんだけどねぇ。総員退避して機体に触る人がいなくなってから平均値とるとか? 風に揺られないことを願って。

***

　STM32F4のバックアップメモリにいくつかの設定を入れるようにしてみた。ジャイロのオフセットとか、データ出力の頻度とか。20ワード(80バイト)しか無いのであんまりたくさんの情報は入れられない。ジャイロのオフセットとかは生データが16bitなので6バイトあれば足りると思いきや、数百サンプルの平均値だからfloat表現で12バイト必要、とか。boolで1バイト使うのもったいないのでビットフィールドとか使い始める始末。
　大容量が必要ならDIP8のSPI接続なSRAMとか使うと良さそう。64KiBくらいの容量があるので相当デカイ。もっとも、通信速度は20MHzに通信プロトコル乗せるのでだいぶ遅そう。マイコン内のRAMにキャッシュ作る構成だろうなぁ。

　JSF++を見てみると、「ビットフィールドをスペース節約の目的に使ってはいけない」がwillで指定されてる。まぁ、willならつかっちゃえ。
　JSF++的にはビットフィールドは低レベル(ハードウェアとか通信プロトコル)に合わせるためにのみ使う、ということらしい。が、ビットフィールドのビット位置って指定できないはずなので、クッソ面倒なバグを量産しそうな予感。

　とりあえず、ジャイロのドリフトは短期的には無視できる見込みがついたので、吊り下げ試験の運用性が向上できた。はず。
　予め机の上とかに固定して平均値をとって、その後で吊り下げる。30分毎くらいでキャリブレーションし直さなきゃいけないけど。

　私、実験前には平均取れって言ったよね！