Pilot Induced Oscillation(part1) ~modelicaで制御工学~

[追記:2020.07.29]

ステップ入力とパルス入力に対する応答に関して、フライトシミュレータ、X-plane10で動きを再現した動画(へのリンク)を追加。



先日、ふとしたことから表題のpilot induced oscillation(以下、「PIO」)が話題になった。そこでこれをmodelicaで簡易にシミュレートしてみた。
(*筆者、飛行力学・飛行制御について大学レベルのことを過去に一通り学んだ程度で、実業務で日々当該分野に携わっている訳ではないので間違い・不足をご容赦願いたい。寧ろ指摘・修正頂ければ幸いだ。)

記事が複数に跨るが、例によって、今回のモデリング&シミュレーションを通じて伝えたいこと(結論)を先に述べておく。
  • 既に安定(自然な特性か制御システムを用いた人為的なものかは問わない)なシステムにフィードバック制御機構を重ねると、急激に不安定になり得る。
  • 安定性が悪化するかは制御ゲイン次第。なので追加するフィードバック制御機構がモデル化困難な「人間」の場合、広い範囲のゲインに対してシステム全体が不安定にならないよう元のシステムの動特性を頑健に作っておく必要がある。
結論が飛行力学やPIOと直接関係の無い抽象的なものなのだが、関係無いことなどなく、PIOは上記2つのとても目で観て判り易い具体例の1つだ。以下、PIOを中心に話を進めてゆく。

まずPIOとは何か。詳しくはこちら等に任せるが、簡単に言うと”飛行機の動的応答とパイロット操作の重なり合いの結果生じる、安定性低下・振動挙動”のこと。飛行機/機の制御システムは安定かつ良好な応答性に設計されているのに、パイロットの反応が制御ループに介入してくることで意図しない不安定挙動・振動が起きる。実例動画を幾つか示しておく。




どれも操作のオーバーシュート→回復させようと逆方向動作、を繰り返して手が付けられない振動に発展し墜落に至っている。
誤解しないで欲しいのはpilot inducedと称されているが、必ずしもpilotに非があるのではなく、機体の動特性/制御システムがpilotの介入を含めて適切に設計されていないという事。もちろん、訓練段階のpilotなど、過剰な回復操作を行おうとして起きるような、pilotに非が有る場合も有るが。

さて、それでは機体モデル。機体の種々のパラメータと飛行条件から機体に働く力・モーメントをシミュレートするモデル、は残念ながら無い。今回は、縦方向(前後・上下・pitching)に限定、線形化されたモデルの伝達関数を使う。伝達関数は、飛行力学の書物中の例を引用する。
pitch角速度がelevator(昇降舵)入力に対して2次遅れの系で、pitch角はそれを時間積分したものである。制御工学やsystem dynamicsに触れた方なら式を見て判るかと思う。
そして、機体の縦dynamicsの手前にelevator actuator のdynamicsとelevator角度制限を置く。actuatorは単純な1次遅れ系で時定数を文献引用で0.1に設定し、elevator制限は上下両方向に30 [deg]までの動作とする。


引用元: Flight Stability and Automatic Control, Robert C. Nelson, Ch. 8.4.1

次は、ちょっとしたこだわりでelevator actuatorのレートリミッタを設ける。今回のシミュレーションには影響しないものだが、後々、pitch rate 制御器とか、高度維持オートパイロットとか作って遊ぼうというときに必要になってくる筈。制御器を作ると現実に行うと機器を壊すような急激な入力の信号を出すことが有り、そのような入力に制限をかける。


それでは、elevator入力信号をランプ(ほぼステップ)状に変化させた応答を観よう。
まずピッチ角。想定通り、上げ舵(定義上、下げ舵が正の値)を与え続けている間、ピッチ角度が一定の割合で増え続けている。ランプ操作直後が少し波打っているが、これはpitch角速度が2次遅れ系であるめだ。
*本当はトリムだとか、頭上げ動作がどこかしらで止まるとか、pitch角が90 [deg]超えると重力の向きが逆転するだとかが起きる筈だが、線形化・伝達関数表現の簡易モデルではそれらは考慮していない。

次にpitch角速度。ランプ操作直後に大きくオーバーシュートし、短時間で定常(ランプ前とは異なる値)に至る。pitch角の波打ちと合致している。オーバーシュートにより振動はしているが、減衰が強く、安定性は高い。

以下、フライトシミュレータ、X-plane10で同じ動きを再現して録画したもの。フライトデータのplotも載せてある。手動と目視で舵を動かす操作を行っているので同一な動きが再現出来ているとは言えないが、上記のplotと類似した挙動を示している。


X-PLANE 10


Amazon APIのアクセスキーもしくはシークレットキーもしくはトラッキングIDが設定されていません。「Cocoon設定」の「API」タブから入力してください。

X-PLANE 11


Amazon APIのアクセスキーもしくはシークレットキーもしくはトラッキングIDが設定されていません。「Cocoon設定」の「API」タブから入力してください。

Microsoft Flight Simulator


Amazon APIのアクセスキーもしくはシークレットキーもしくはトラッキングIDが設定されていません。「Cocoon設定」の「API」タブから入力してください。

FlightGear


Amazon APIのアクセスキーもしくはシークレットキーもしくはトラッキングIDが設定されていません。「Cocoon設定」の「API」タブから入力してください。

X-PLANE 9


Amazon APIのアクセスキーもしくはシークレットキーもしくはトラッキングIDが設定されていません。「Cocoon設定」の「API」タブから入力してください。




次は、pitch角を意図した値まで変化させる操作を考えよう。例として、pitch角を0 [deg] から10 [deg]に頭上げをさせたいとする。フィードバック制御を入れなくとも、単純な操作だけで達成可能だ。ランプ(ステップ)状にelevatorを上げ舵にし、一定時間保った後にelevatorを0に戻す操作(台形入力)をすれば、上げ舵保持の時間の調整で意図したpitch角に姿勢変更できる筈。
下図が台形入力でpitch角を0 [deg] から10 [deg]に変化させた例だ。厳密に10 [deg]にするparameter調整は行っていないが、台形入力の幅調整で、目標とするpitch角を得られることが判る。
先に見た通り、pitch角速度が2次遅れ系なので、ストレートに目標picth角に向かうのではなく、序盤に波打ちながらのpitch角増加と、最後にオーバーシュートを伴った挙動になる。



下図がpitch角速度の挙動。上げ舵開始時と解除時にオーバーシュートが起きている。

また、フライトシミュレータでの再現動画。こちらも上記のplotと似た挙動となっている。



対象の機は、オーバーシュートを伴いながらも、フィードバック無しの操作で臨む状態に持っていくことが出来て、短時間で定常状態に落ち着く、安定性が高く制御が容易なシステムであることが確認できた。
しかし、機のオーバーシュート挙動まで考慮に入れて、必要な上げ舵保持時間を計算して操作するなどという事が人間に出来るだろうか?しかも、上げ舵を解除するタイミングは、オーバーシュートを起こしている最中であり(起こした直後でない)、明らかに直観に反した操作だ。オーバーシュートに達する前か、達した直後に舵を下げる動作をとるのが自然だろう。
人間が操作に介入すると、必ず、意図した状態と現状値の際や、その差異の変化の仕方を見て、常時操作量を変更する。人間はフィードバック制御器として働く。
次回以降、今回の機体縦dynamicsモデルにフィードバック機構を付け足して、pitch角挙動がどう変化するかを見ていく。

今回のシミュレーションに使用したモデル:SystemModels.VirtualExperiments.simPIO_longi_01_v01
収録ライブラリ:SystemModels
今回はここまで。

コメント

タイトルとURLをコピーしました