Wiiremoteの加速度センサから位置を割り出す
いろいろ似たような質問がきたので、エッセンスだけでも書いておきます。 —English edition—- I created some APIs and testing functions like “Get3D”, “Get2D” and “Get6D” series. The test and scratch loops are not terminated. [Hint1] Have you measured delta T precisely? The delta time is not a stable frequency. [Hint2] Have you measured the gravity? It is very important to define the starting posture and “unit of force”. [Hint3] You shouldn’t standardize/round the values like “G=1”. Wiiremote sensors have 8 bit each, however it is not enough to detect a small movement. Also the acceleration values are not linear (probably, relative values for forces). [Hint4] Have you try to “cancel” the gravity? In your mathematics, you should try to separate the input force as a combine of “gravity(=posture)” and “human movement”. [Hint5] Have you think these 4 conditions of Wiiremote? (1) Gently movement: Gravity > Movement (2) Radical movement: Movement > Gravity (3) Zero gravity: Gravity=-Movement (4) Set on the floor: Gravity=Init Posture If your application always keep in the condition (1), it has a chance to get a better result easily. The condition (4) should be use for calibration (in a short time). The condition (2) and (3) are difficult to detect (without IR sensors), however you should describe this condition in your mathematics. If your equation lack them, your magnitude of force sometime arrive to zero during a human input like a swing. [Important]
I have tried a lot of small codes that can estimate the position from (Ax,Ay,Az) and an initial posture. Shortly, the errors (=small movements less than sensor resolution) might be integrated. If you prefer stable detection, small drift noises should be cut off. “Gravity canceling” will not be a perfect. But if you need a position (X,Y) instead of (X,Y,Z). It will be much easier. Imagine a weight that linked to a string. Tell me if you have any good results. best regards, Akihiko —-日本語版—- “Get3D”, “Get2D”,”Get6D”シリーズと言ったAPIやテスト関数を試しています。 実際にはテストとスクラッチのループは終わってないです。 以下ヒントになるであろう情報。 [Hint1] ⊿ｔ（微小時間）は正確に測りましたか？ 　Wiiremoteから送られてくる測定値は安定なな周波数を持っているわけではありません。 [Hint2] 重力を測りましたか？ 　開始時の姿勢と「力の単位」を取得して定義するのはとても重要です。 [Hint3] 「G=1」というようにセンサーの値を正規化したり、丸めたりするべきではないです。 　Wiiremoteのセンサーは各軸8ビットです。しかし、これは小さな動きを取得するのには十分ではありません。 　また、加速度の値はリニアではありません（たぶん、力に対する相対値）。 [Hint4] 重力を「キャンセル」してみたことはありますか？ 　あなたのアルゴリズムの数式において、入力された力は「重力（＝姿勢）」と「人間の動作」の合力であり、分割されるよう試されるべきです。 [Hint5] 以下のWiiremoteの4つのコンディションについて考えたことがありますか？ (1) そうっと動く：重力＞動作 (2) 激しく動く：動作＞重力 (3) 無重力：重力=動作の逆向き (4) 床置き中：重力＝初期姿勢 　もしアプリケーションが常に（1）でいられるなら、良い結果を楽に得られるかもしれません。 　(4)は（短い瞬間に）キャリブレーションに使われるべきでしょう 　(2),(3)は赤外線なしでは検出が難しいのですが、アルゴリズムの中でこのコンディションを記述するべきです。 　この状態を含まないと、スイング動作のような人間の入力において、マグニチュード(＝ベクトルの大きさのこと、√各要素の二乗和)がゼロになる瞬間があります。 【重要】
　私は加速度（Ax,Ay,Az）と初期位置から位置を推定できる、沢山のサンプルコードを試してみました。 　端的に言えば、エラー（＝センサ解像度よりも低い微小な動き）は積分されます。　 　もし安定した検出をしたいなら、小さなドリフトノイズは切り捨てられるべきです。 　「重力キャンセル」は完璧ではないでしょう。でも、（x,y,z）ではなく（x,y）が必要なら、より簡単になるはず。 　「紐につながった錘」を想像してみてください。 　なんかいい成果が出たら教えてください。 あきひこ