ラベル multiWii の投稿を表示しています。 すべての投稿を表示
ラベル multiWii の投稿を表示しています。 すべての投稿を表示

2014年5月14日

MultiWiiでヘリコプター(5)  予測補正でテールホールドばっちり!

PIDをつきつめる前に、予測補正(predictive compensation)に手を出してしまいました。

PIDはどんなに頑張ってもしょせんフィードバックです。BLHeliのマニュアルにも書いてありますが、テールが動いてしまってからそれを感知して元に戻そうとするより、動く前に何が起こるか知っていてテールが動きにくいようにテールローターを制御する方が良いに決まっています。


もちろん量的に完璧な予測をできるわけはありませんが、予測補正の良いところは、フィードバック補正と組み合わせて使ってもまったくお互いに悪影響を及ぼさず、純粋にお互いの苦手分野をカバーできるところです。


ごたくを並べましたが、たいしたことではありません。コレクティブピッチを入れたらその量に応じてテールローターの出力をアップする、というだけです。

式で書くと、multiWiiのoutput.c内にあるYAWサーボの値を決めてる箇所で
servo[5] = (axisPID[YAW] * SERVODIR(5,1)) + conf.servoConf[5].middle + abs(collective)/2;
と、コレクティブの絶対値に適当な係数(うちの場合は0.5にしました)をかけて足します。
absで絶対値を取りましたがまだ背面してないのでマイナスピッチ時は未検証です。

テールローター出力とサーボの関係は機体によっていろいろなので、今回入れた係数0.5の部分は本当はあとから微調整できるようになっているべきです。しかし予測補正は正確な補正量じゃなくても予測無しよりたいていマシなので、ソースコード内にdefineで係数を定義する程度でも大丈夫かもしれません。


たったこれだけで、大幅にテールの挙動が改善されました。昨日のムービーとピッチポンプの様子を比較すると良く分かります。

昔からある技として、プロポ側でピッチを入れたらミキシングで右ラダーを少し打つようにする、というのがありますが、3軸ジャイロから見るとかなり違いがあります。

プロポミキシングの場合、3軸ジャイロさんには右に少しノーズを向けろ、という指令が伝わり、彼はテール推力を少しアップさせますが、ピッチを同時にいれられちゃったせいで不幸にもその命令は十分に実行できず、彼はかろうじて左を向かずには済んだ、と思っています。しつこいヘッドロック機能をもったジャイロなら、その後負担が軽くなったところでぐいっと本来向きたかった右を向くかもしれません。

対して予測補正の場合は、3軸ジャイロには回頭指令は全くはいらず、彼テールに対して特に何もしません。ただ彼の部下のサーボさんが、勝手に上司の指示を無視してテール出力を増量しているのが目に入るだけです。
彼は「あーあ、知らないよ」と内心思いますが、責任感がある性格なので、部下の不始末が原因であっても機首がおかしな方向を向いたらちゃんと修正してやろうと思ってます。結果的にテール出力の増量は同時に起こったピッチ負荷と相殺してテールはあまりぶれず。それでも少しピッチ負荷が勝ってゆらゆらと左を向きそうになったりしたら、3軸ジャイロさんは本来の仕事をして、ホバリング時と同じようにそれを淡々と修正します。

つまりレートジャイロ(Iゲインが0)の場合を除いて、プロポミキシングの補正と機体側での予測補正は違いがあり、機体側での補正の方がずっと有利です。




ついでにnobさんから指摘のあったD補正もいろいろ変えてみました。しかしD補正は機体の「回転速度が急激に変化した時」しか効かないので、これ単体でテール負けを防ぐ効果はほとんどありませんでした。ピッチポンプでのテール負けはmultiWiiの世界ではそう速い変化ではない、ということだと思います。

D補正が効くのは本当に速度が急激に変化し続ける場合で、つまり手でピルエット入れたり機体を傾けたりした後に、操作を止めたところでおつりが出てぶるぶるっと振動するところをダンピングさせる効果があります。
そもそも振動が出なきゃ出番が無いわけですから、かなり強めのPゲインがかかっていることがDゲイン活躍の前提ということになります。


また、Iゲインは少なくともmultiWiiの世界ではテールや機体の傾きを保持する効果はほとんど発揮できませんでした。Iゲインが働く時間周期が0.5sec程度なので、こんな周期でテールがゆらゆら大きくワグられてもうざいだけです。
なので、Iゲインはゆらゆらワグが無くなるところまで減らして、「無くてもいいけどあれば機体の向きがゆーっくりドリフトして動くのを少し軽減できるかな?」程度のものだと思っておく方が良いです。


ただこれは機体の大きさや、ジャイロセンサのローパスフィルタ周波数等によっても変わるかもしれないので、あくまで今回のマイクロヘリの場合、という結果です。

今日の時点で最も良い感触だったパラメータを載せておきます。上のムービーの時よりDゲインを増やしておつり振動がなくなったので、ムービーよりも気持ちよくすぱっすぱっと傾けられます。


2014年5月13日

MultiWiiでヘリコプター(4) テールホールド少し改善

昨日、テールモーターの出力センターが調整できないと書きましたがただの勉強不足でした。ちゃんとMultiWiiConfのsettingsタブで、センターと両端の出力値を明示的に調整可能です。


なので、ヘリ部長に習ったとおり

  1. まずYAWのゲインを全て0にする
  2. テールサーボのセンターをいろいろ調整して、ラダー操作が左右に偏らずにホバれる位置を探す
  3. 今度はテールワグが出る寸前までどんどんYAWのPゲインを上げていく
  4. 最後に長周期ワグが出ない範囲でYAWのIゲインも上げる

という調整手順で設定をやり直すと、テールホールドがだいぶ改善されました。


軽いピッチポンプを入れてもテールが90度ぐるっと取られることはなくなりました。まだテールがぐらぐら不安定な感じはしますが、無風の屋外ならフリップもできるかもしれません。


この結果でわかったことは、基本的に急激なピッチ操作時のテールホールドはPゲインが担っているようだ、ということです。

2014年5月11日

MultiWiiでヘリコプター(3) とりあえず浮いてます。テールモーター制御が課題

HobbykingのnanoWiiコントローラでマイクロヘリを飛ばそう計画。

PWM出力をBLHeliに合わせるのはまだできておらず、現状サーボ信号相当の1000us~2000usPWMとしてESCに認識された状態でPID係数の効果と現状の課題洗い出しをしています。

ハードウェア加工はごく少量で、まずnanoWiiにwalkeraサーボ用のmolex 1.25mmコネクタ3つを直付け。信号線ピンを折り曲げて基板に直接ハンダ付けできる位置にコネクタを接着してから作業しました。GNDとVCCのピンは横に橋渡ししてハンダ付けします。


メインモーターとテールサーボの信号は基板裏側に信号線をハンダ付けして取り出しています。
メインモーターは490HzのPWMで50%~95%くらいが出てくるんですが、それってつまりサーボPWMだと思って解釈すると0~100%の信号に見えるようにうまく選ばれています。これによってブラシモーター等のデューティ比PWM信号としてもそれなりに動くし、サーボ信号を要求するESCに食べさせてもちゃんと機能するようになっているわけです。


次に、miniCPフレームを使うことにして、なんとかコントローラを水平マウントできるようにプラ板を切ってステーを作ります。

Geniusフレームやsolomaxxフレームの方が無理なくマウントできそうですけど、まあ手持ちの中古パーツを活用する方向で。。

サーボはwalkera純正でかまわないんですが、手元にHK5320サーボがいっぱい余ってるのでこれを使いました。機能の記事でV120のテールに使ったHK5330とは別物です。このサーボは激安だしminiCPに少しかさ上げすれば簡単に装着できるんですが、回転方向が逆なので流用するには(逆転させるには内部の配線を4箇所もハンダ付けする必要があって)面倒だし、パワーもwalkeraサーボに劣るのでこんな時しか使い道がありません。

multiWiiはもちろん汎用のコントローラなので、サーボ方向の逆転設定がありますから回転方向に関しては何の問題もありません。あ、例によって信号線とGNDがwalkeraと逆なのでコネクタのオレンジと茶色は入れ替え必要ですよ。


テール指令がサーボ信号で出てくるので、いちどブラシレスESCを通す必要があることもあり、たいしたパワーも出さないのにダブルブラシレスになりました。メインモーターはパワー不足で最近余っていたHP03Sです。ESCは高価なOrigin10Aを2つ、基板ステーの下側に貼り付けてあります。1Sと2S両対応ってところがテスト機に向いてるんですよね。


とりあえず現状でのフライト映像


サイクリック方向はP=1.5~2、I=0.030~0.050あたりでまあまあの感触を得ています。最低限のホバ安定度は出ていますし、機体を傾けるとその状態を維持したまま横に走ります。

が、動画の後半でもわかりますが、ピッチポンプした時にテールがぎゅんぎゅん負けて使い物になりません。

これはyaw方向のゲインがP=2.0と非常に小さい値になっているせいです。これを5とか6まで上げるとテールを保持するようにはなるのですが、今度はワグワグ左右に尻尾を振って見苦しいことこの上ありません。



このサイクリックとヨーの違いは、補正無しのセンター位置でヘリが準安定になっているかどうかに起因していると思われます。

テールサーボ機の場合だと、テールの調整はまずジャイロの補正が無い状態(サーボがセンター位置で)だいたいホバれるようにメカニカル調整して、そこからPIゲインを入れていくようにするようです。

しかしテールモーター機だと、メカニカルに調整しやすい箇所が無いので(テールモーター選択、ブーム長やローター種別で不連続には変更できますが)ホバるためにはどうしてもジャイロが一定の補正を安定して出し続けるようなPIパラメータにせざるを得ません。

この制限があると、Iゲインが使い物にならず、どうしても弱めのPゲインのみでテールを保持するような設定になってしまうのですが、それだと今度はピッチポンプのような急制動に弱いという問題が出ます。

何か別のパラメータでテール出力のセンターを設定できるようにする必要があります。
また、そうやって求めたテール出力のセンターは、メインモーターの回転速度に応じて変化するので、センター出力の設定自体をメインモーターやピッチによって変化させるというフィードフォワード(予測)補正も必要になるでしょう。

かなり安物の3in1コントローラでも、最低限そのような処理を行っているものと思います。まだまだこれからです。



そういえば、受信機としてOrangeサテライトRXを電池ケースの下に貼り付けているんですが、LEDがいい感じにオレンジ点滅してとても実機ぽくてかっこいいです(笑)

2014年4月25日

MultiWiiでヘリコプター(1)

MultiWiiはチープなフライトコントローラの中で小さくない勢力を占めていますし、なによりHobbyKingに支持されておりハード入手が容易です。


ただ、ヘリコプターを飛ばすとなると情報が少なく敷居はけっして低くありません。

2012年にPatricさんがコードをモディファイして初めてヘリを浮かせて以降、公式ページへの記載はほとんど変化が無い、というほどマイナー扱いです。


が公式docからもリンクされていますが、ボードタイプも汎用の古いものですし、今となってはあまり参考にできる部分がありません。(ヘリコプターフォーラムはそれなりに活発なので読むだけでもためになります)



まず、MultiWiiのつらいところは、サーボとモーターの番号が謎のマジックナンバーで管理されてるところです。各コプタータイプごとにどの番号がどんな役割かがハードコードで決められており、ヘリコプターは
  • HELI: 4,6,7 - swashplate servos, 5-rear servo or rear motor (MOTOR2 output can be used too for rear motor)
だそうです。サーボ1,2,3はマルチコプターでジンバル用に使われる習慣があるので遠慮したようです。

rear motorという記載があるように、一応YAWMOTORというオプションがあり、テールモーターのヘリに対応した形跡が見られます。しかしこのオプションはnanoWii等の小型コントローラでは機能しないように見える上に、どんなハードウェアでサポートされているか情報がありません。

では、サーボ4,5,6,7を使うことはわかった。そのサーボ1~8とやらはどのピンに割り当てられているのか? というとこれもまたボードによってばらばらでろくにルールがありません。しかも同じボードでもハードウェアPWMのオプションの選び方しだいで変化するという有様です。

ハードウェアPWMは本当にCPUのレベルでピン番号に制限が付いちゃうので仕方ないんですが、それならちゃんと各ボードごとにプロジェクトを管理しないと、一部のボードでしか使えない機能がいろいろできてしまって共通ソースにしている価値が薄くなってきています。

(実際にforkしてしまったプロジェクトもたくさんあります。まあ最初からそれを許容してるので文句を言われる筋合いは無いんですけどね。)


ピン番号に関して公式docでは
For promini:
  • Motors : 9,10,11,3,6,5,A2,12
  • Servos : A0,A1,A2,12,11,3,10,9
For Mega:
  • Motors: 3,5,6,2,7,8,9,10
  • Servos SW_PWM : 34+44 , 35+45 , 33+46 , 37,6,2,5,3
  • Servos HW_PWM : 44,45,46,11,12,6,7,8
For promicro m32u4:
  • ...
と書かれていて、nanoWii基板に乗っているm32u4の情報はありません! (9,10,11がスワッシュサーボで5,6がメインモーター、テールサーボのようです)

なお、もう一つ紹介したMINI MWC with DSM2ボードのほうはATMega328Pなのでpromini系だと思うんですが、サーボ4,5,6,7はピン12,11,3,10と上記に書かれており、MINI MWC基板では12番ピンがサーボヘッダに出ていないのでそのままではヘリに使えません。

まあ、そんなげっそり状態から始めるわけですが、少なくともnanoWiiの方はソースコードを見る限りこれでヘリを飛ばしてる人がコントリビュータの中に実際にいるようなのでまだマシです。今後はまずnanoWiiを動かしていこうと思います。




なお、RC入力や各センサーの現在状態を見たりPID設定を変更したりするには何かしらGUIが必要ですが、最初はやっぱりパソコンが便利だと思います。

オフィシャルにmultiwii2.3のソースコードを拾ってくると同梱されているMultiWiiConfでもいいですし、



windowsの.NETで作られたWinGUIでもいいと思います。


ただMultiWiiConfはJavaでできていて、JavaのVMバージョンによってはウィンドウが出るにもかかわらずちゃんと情報が更新されなかったり一部画面が崩れたりしますので、一発でうまく動かなかったら問題きりわけのためにWinGUIを試すことをお勧めします。