名前なし
2023/08/05 (土) 13:58:02
27c81@57bbf
テスフラでの測定用で、加速測定用のlevel flight BOTと、旋回率測定用のsustained turning BOTをpythonで作った。滅茶苦茶簡単に自作できるのな。マッチで使うのはリスキーすぎてやらんが。
通報 ...
複雑な処理となると別だけど規則的に動くだけなら簡単なのだろうね。実際中華BOTの激安のとかは敵の認識とかせずゲーム内BOTに移動を組み合わせるだけとからしいし。それはそうとマッチで使わずとEACがBOTの使用を検知したら問答無用でBANだろうから自己責任でね
↑↑github参考に8111のpythonライブラリ展開。
先人の叡智。情報は多分揃ってるので後は使い方だね(オートエイムBOTは作る必要もないので考えたことないけど)。画像認識も別ライブラリ使えば多分簡単。pythonと先人サマサマよ。作例にないけど、テレメトリ内の各値を参照したければtelem.full_telemetry.get('IAS, km/h')←telemetryの任意のキー名称、で取り出せる。
ライブラリを使わない方法はseleniumで直接url叩く。
マウス入力を再現するライブラリはsendInput。マウス実座標が固定されていたりで他ライブラリは正常動作しない。ただ外部マウス入力でないのはeacにバレるのでeac駆除対象かと(おそらく)。kernelとか深い場所から外部マウス入力を装うとか、botではなくrobotでマウスを直接操作するしかeac回避はないので素人では限界(認識違いあるかも)。
たまに見かける旋回率とかをグラフに落とし込んでるやつ、あれはどうやってつくってるんだろう
すごいのができたなー。わしも作ってみよ。これつまりジョン・ボイドのEMダイアグラムが自動計測できちゃうってことだよね。たしかエレベータ作動角とか流れてたはずだから、エレベータが95%以下になったらブラックアウトしたと見なして、直線飛行してブラックアウト時点の速度を8111に送って再測定みたいなとこまで自動でできちゃう。
全力旋回のみならず、これまでマウス手操作では不安定で計測不可だったSEP=20,10,0,-10,-20等の緩旋回をbot活用し計測可能になった。ただ全自動かというと課題があるかな。①外れ値 (RBマウス操作由来の不安定さで必ず混じる外れ値を取り除く必要がある)②BOTの不安定さ (PIDなので初期値を整えないと発散する)③ ①②を組み込んだプログラム作成が普通に難しい。なのでこれまで通り手動でexcelデータをまとめるのが続くかも。
【↓ご指摘のE-M線図。おっしゃる通りこれが作りたい】
↑↑WTRTI計測後のデータをexcel分析だよ…。計算式のtemplateを張り付ければ結果が出るようにしてるから、基本転記だけすれば良いんだけど、上記①外れ値確認があるから手作業が無くせない…。
外れ値は例えばSEPが20±1を外れると表示させないようにするか、2~3試行回分を重ね書きすればいいかな(自分は業務ではチャンピオンデータに惑わされないように細線で数回分重ね書きしたデータで見る)。PIDについては自分ならZNステップ応答法とかでフィードフォワードで一発走らせて速度ごとのPIDパラメータ取得してから計測する感じかなぁ。あとわりと教科書で書いてないつまづきポイントで"飽和"って現象があるから、Anti-windup補償器を仕込んでおくかPD制御にしちゃうと安定するかもね。
外れ値の発生要因で一番の問題はG-Lockなんだよね。検出自体は搭乗員スタミナをプログラム上でシミュレートすれば解決しそう(搭乗員スタミナは8111範囲外、マウス制御でのエレベータ作動角上限はIAS,機種によって決まってて100%にならない(余談:マウスでも100%を開放するのがトリム旋回)。よって"直接"G-Lockを検出するすべはない)。だけどG-Lock復帰後(またはG-Lock防止後)に再度計測条件復帰する際に初期値次第で制御発散リスク(上記②)と、一瞬でも条件満たす瞬間はデータ記録されてしまうリスク(上記①)とがある。まぁ①はあまり心配してないけど②が設計負荷たけぇわ。
・重ね書きデータ→自分も現状手動でやってる。外れ値確認の基本だよね。研究所の人もやってたし間違いないかと。現状のグラフ外観から外れ値を探す手作業を自動化するのは大分難儀(条件付けが厳しい)だけどそも外れ値がかすむくらい重ね書きすれば影響は小だね(上記「①はあまり心配してない」の意図はコレ)。
・ZNステップ応答→参考になるわ。PID調整こそ現場感覚だもんねw、理屈だった調整方法知れるのはありがたい。臨界感度というように外乱に弱いからマウス制御のピッチヨーロールが複雑に絡む制御に適用すると発散しそうだけど高速応答の術として参考になる。
・FF制御→モデル化しないと発散する(それで会社残件抱え中)
・1発走らせてPIDパラメータ取得→知見を持ってないに尽きる…。想像は出来るが実装にあたって勉強からだわ。でも身につけば絶対役立つ。ただ負荷特性が状態によって変動するので(エレベータ作動時のダンピングとか[マウス特有])網羅しきれねぇんじゃないかな。
・Anti-Windup補償器→入力飽和だね。今回例でいうと、マウスが機体を置き去りに暴れると滅茶苦茶な旋回になるから制限掛けろと。役立ちそうだしつける必要はあるとは思ってたが名前があるのね。
Gロック後の復帰時に発散するのであれば、復帰時初期条件を水平直線飛行にすればよいのではと思ったけど、マウスの狙ってる方向が水平かどうかわからないのか。高度25500m以上に飛ばせば"戦場に戻れ"警告が出て高度25000m水平飛行に戻してくれるっぽいので、高度50000くらいに飛ばす→自動で25000mくらいに戻されるタイミングを高度監視して検知→元々計測したかった高度速度に戻して一定速で飛ばして……って感じになるのかな。
ZNステップ応答法は限界感度法と違って微小入力入れて応答の定常値を見る方法なので、自動で緩い水平旋回しながらマウス入力を100pxだけ上にズラして……というのをイメージしてた。でもたしかにキレイな旋回しててもGと速度で全部特性変わるから、網羅するだけでしんどくて、実際には片翼失速とかラダーだけ旋回ときちんとロールしてから旋回するパターンでグチャグチャになるのか。自分用計測ではマウスジョイスティックでやるかなぁ。どうせマウスジョイスティックでしか飛ばないし。
なるほど…?Excel使ったことないからよくわからんが、とりあえずデータの出し方と入力方法ググってみる。ありがとう
WT技術部のページのWTRTIの項目に一応簡単な説明足しておいたよ。
excelテンプレ
01template***の右側にまとまった列が計算列で、ロギングしたcsvに張り付ければ結果が出るようになってる。ただし列指定が柔軟でないので個人個人で設定要(つまり他の人は使えない)。計算を参考にするか、または結果がACC, TURNとあるので参考にして貰えれば。ただしデータとして不足があるので過去雑談、技術板で相談した通り追加測定を考えてるんだけどね。(そのためのこの木話題のBOT作成)
相談に乗ってもらったDRAGは"setting"の"fm mode/ON"で出現、luaスクリプトの理解等、こちらも進展はあるのだけどまとまってから話すね。
ごちゃごちゃと問題ばかり並べ立てて申し訳ないわ。素人で測定データがどうなるか想像が付かない故なのである程度は半自動(手動あり)でデータ確認してから自動化可否判断となるかな。そのときは(理解間違ってた)ZN応答とか織り込めたらいいな。