地球平面モデルでは，

• 本来は曲面である地球表面を平面と近似
• 地球の公転及び自転を無視（公転及び自転による地表面の運動を等速直線運動と近似）

⇒ 地表面に固定された平面座標系（例えば𝑥𝑥軸を経線，𝑦𝑦軸を緯線に対応）は慣性座標系

運動計算はシンプルであり，近距離かつ短時間の飛行を対象とした飛行シミュレーションには有効．

図２-１に，地球平面モデルのイメージを示す．（曲面を平面に貼り付けたイメージ）

図2-1 地球平面モデルのイメージ

原点：地表面上の任意の点，$x-y$平面：地表面内，$z$軸：地表面に鉛直下向き

• 地球の公転・自転を無視⇒地表面は慣性空間に対して固定⇒地表面固定座標系は慣性座標系
• 機体の位置の基準

【例1】 地表面局所水平座標系 $[x_{HG}, y_{HG}, z_{HG}]$（図 ２-１）

【例2】 滑走路NED 座標系 $[x_{HR}, y_{HR}, z_{HR}]$ （地表面局所水平座標系の 1 種） （図2-2）

【例3】 滑走路軸 （Runway Axes）$[x_R, y_R, z_R]$ （図2-2）

図2-2: 滑走路NED座標系と滑走路軸

原点：機体重心，$x-z$平面：機体対称面，$x$軸：前方向き， $y$軸：右翼方向

• 機体とともに加速並進・回転 ⇒ 非慣性座標系
• 機体の速度，角速度ベクトルの成分表示に使用

図2-3: 機体固定座標系

【例１】 機体軸 （Body Axes）$[x_B, y_B, z_B]$（図2-3）

【例２】 安定軸 （Stability Axes）

原点：機体重心，$x$軸：北向き（$N$），$y$軸：東向き（E） （$z$軸：鉛直下向き（$D$））（図2-4）

• 機体とともに加速並進 ⇒ 非慣性座標系， 回転はせず，常に$N/E/D$方向
• 機体の姿勢の基準

図2-4: 局所水平座標系

6自由度シミュレーションでは，飛行制御を行う際に誘導系と制御系の両方の設計が必要である．

設計した誘導制御系の性能が不十分な場合，誘導系と制御系の両方の設計変更が必要なため，作業量は膨大となる．

そこで誘導系のみの設計・評価用として，誘導系からの姿勢コマンドは制御系により完全に達成されるものと仮定し， 制御系部と機体回転運動を解く運動計算部はスキップした3自由度シミュレーションプログラムを別途作成し， 誘導系のみの設計・評価に活用する．

この場合の運動計算は回転運動を含まないため，質点の運動方程式となる．

3自由度シミュレーションを用いて誘導系のみの設計が完了すれば，続いて制御系の設計を行い，６自由度シミュレーションにより誘導・制御系の総合評価を行う手順となる．

このように手順を２段階とすることにより，誘導制御系設計の効率化が実現する.

図2-5に6自由度シミュレーションと3自由度シミュレーションのイメージを示す．

図2-5: 6自由度シミュレーションと3自由度シミュレーションのイメージ

そもそもクォータニオンを使って何がやりたいのでしょうか？大きく分けて以下の 2 つがあるように思います。

• 3D 空間における「回転」を表す
• 3D 物体の「姿勢」を表す

2 つと言ったのですが、メインは「回転」の方でしょう。

「姿勢」は単純に「どういう回転でその向きになったか」として捉えることができます。

注意点として、「姿勢」は「方向」よりも多くの情報を含んでいます。

クォータニオンを用いた回転を扱うときに、回転させたい対象が「姿勢」なのか「方向」なのかを混乱しないようにすることが肝要です。

方向は「進行方向」や「視線」といったものを表していますが、姿勢はそれに加えて、その方向周りの角度の情報も含みます。

航空機でいえば、機首の向いている方向だけでなく、機首に対して機体がどれだけ傾いているのかも指定してはじめて機体の姿勢が完全に決まります。

数理的には以下のようになっています。

	自由度	備考
方向	2	進行方向は三次元ベクトル (3 個のパラメータ) で表せますが、そのベクトルの大きさは意味を持たないので 1 減らして 2 です
姿勢	3	方向 + 1 です

つまり、姿勢は最小 3 個のパラメータで表せるということです。

回転も姿勢と本質的に同じものなので、同様に 3 個のパラメータで表せます。

実際にオイラー角は 3 個のパラメータで姿勢や回転を表します (回転を表す方法はクォータニオンだけではなく、オイラー角による方法もメジャーな方法の 1 つです)。

オイラー角は Unity ではインスペクターの Rotation 項目で表示されているやつです。

(しかし transform.rotation は Quaternion 型なので少し紛らわしいですね...この記事でも注意喚起がなされています)

クォータニオンは任意軸回転がキーワードとして言及される場面も多いです。

いかなる回転 (三次元空間内) も表現できることが強みです。具体的には以下のように定義します。

三次元空間において

• 方向ベクトル $(\lambda_x, \lambda_y, \lambda_z)$ を回転軸として
• 角度 $\theta$ だけ回転する

という「回転」を表すクォータニオンは、四次元ベクトル $(\lambda_x \sin⁡{\frac{\theta}{2}}, \lambda_y \sin⁡{\frac{\theta}{2}}, \lambda_z \sin⁡{\frac{\theta}{2}}, \cos{\frac{\theta}{2}})$ で表します。

これらは Unity では、Quaternion 型変数を qua として、

• qua.x = $\lambda_x \sin⁡{\frac{\theta}{2}}$
• qua.y = $\lambda_y \sin⁡{\frac{\theta}{2}}$
• qua.z = $\lambda_z \sin⁡{\frac{\theta}{2}}$
• qua.w = $\cos{\frac{\theta}{2}}$

という風に対応しています。

(が、Unity の Quaternion を扱うときにこれらの成分を直接触ることはあまりないかもです...スクリプトリファレンスにもクォータニオンに熟知していない限りは x, y, z, w の値を直接変更しないでくださいと書いてあります)

また Unity で上記の定義に則ってクォータニオンを生成するときは Quaternion.AngleAxis を用います (オイラー角など他の方法でクォータニオンを生成する方法は後述します)。

// Y 軸 (上方向) まわりに 30 度回転するのを表すクォータニオン
Quaternion.AngleAxis(30, Vector3.up)

ところで上の定義を見ると

• なんでいきなり三角関数が...
• $\frac{\theta}{2}$ ってなんだよ... $\theta$ でいじゃん...

と思ってしまいそうです。

その答えは「こう定義すれば具体的な回転計算が超楽だから」なのですが、本記事を読み進めて行くことで少しずつ実感していただけたらと思います。

クォータニオンによる「回転」を定義したからには、実際に「三次元ベクトル」や「姿勢」を回転させる計算方法を導出してあげる必要があります。

三次元ベクトル $\vec{v}$ の回転計算は

• キャラクターの視線をある方向へと徐々に向けて行く (3D ゲーム)
• 宇宙機に搭載した望遠鏡を所望の方向へ向ける (航空宇宙)

といった場面で必要になります。

また、姿勢 $p$ の回転計算は、

• クォータニオンとクォータニオンの補間 (3D ゲーム)
• 航空機や宇宙機の三軸姿勢制御 (航空宇宙)

といった場面で必要になります。

結論としては、三次元ベクトル $\vec{v}$ や姿勢クォータニオン $p$ に対し、回転 $q$ を実施した結果は以下のように大変シンプルなものになります！！！！！！！

回転させるもの	回転結果	備考
$\vec{v}$	$q \otimes \vec{v} \otimes \bar{q}$	$\bar{q}$ は $q$ の逆回転
姿勢クォータニオン $p$	$q \otimes p$

逆に

回転操作をシンプルな計算で実現できるように、クォータニオンをあのように定義した

とも言えます。

なお、クォータニオン同士のかけ算 $q \otimes p$ や、クォータニオンとベクトルとのかけ算 $q \otimes \vec{v}$ はまだ定義していないですが、1-4 で導入します。

また、こうした事柄はクォータニオンを自分で実装する場合には必要な知見なのですが、Unity ではいずれも単に

と「*」演算子で実現することができます。

$q \otimes \vec{v} \otimes \bar{q}$ な量を q * v と記述するのは少し紛らわしさがありますが、実用上とても簡便です。

演算子の順番は重要で、左右を入れ替えてはダメです。

三次元空間上での回転や姿勢を表現する方法には代表的なものが 3 つあります。

• クォータニオン
• オイラー角
• 回転行列 or DCM

	パラメータ数	メモリ消費	計算上の扱いやすさ	備考
クォータニオン	4	〇	◎	バランス型で、その他様々なメリットがあります
オイラー角	3	◎	×	具体的な姿勢をイメージしやすく、メモリ的にも優しいですが、計算上の難点を抱えています
回転行列 or DCM	9	×	〇

どの方法にもメリット・デメリットがあるので、状況に応じて使いこなせばいいのですが、総じてクォータニオンはバランスがとれた優秀な方法であることがわかります。

オイラー角はたった 3 個のパラメータで回転や姿勢を表現できるので、メモリ消費は少なくて済むのですが、三角関数を多用することもあって計算時間的には大きくなってしまいます。

それどころかもっと悪いことに、オイラー角の二番目の角度が ±90±90 度になる場合が特異点となって計算上の大きな問題を引き起こすことが知られています (詳しくはジンバルロックを参照)。

端的に言えば、ヨーとロールの区別ができなくなってしまう状態です。

しかしながら特に航空機の世界では

• そもそもジンバルロックが起こるような状態にならない (ピッチが ±90±90 度になる状態...下図のような墜落時などに発生しそうな相当ヤバイ状態です...戦闘機などでは考慮が必要です)
• ヨー、ピッチ、ロールという概念がとてもなじみ深い

といった理由によって盛んに用いられています。

また、3D ゲームの世界などにおいても、オイラー角の直感的なイメージしやすさから、UI や API 部分では用いられるケースも多いです。