2014年6月30日

multiwiiで130Xクラスを飛ばす

前回作成した130Xフレームのmultiwii機で、セッティングをいろいろつめてみました。
一番大きかったのは振動の抑制で、フェザリングシャフトの曲がり、メインモーター固定ガタを丁寧に修正したら、大幅に振動が減り、結果としてジャイロのMPU6050にセットするローパスフィルタを46Hzに上げることができました。(miniCPベースの機体では20Hzでもぎりぎりでした)

このローパスフィルタはテールワグの削減に非常に効きます。正直この周波数が死ぬほど高ければYAWゲインなんてめっちゃくちゃ上げておいてON/OFF制御でもいいくらい重要です。


離陸した時点でテールワグはほとんど感じられないし、序盤の鬼ピッチポンプでもテールはびたっと止まっています。ヨーモーター機の苦手な左高速旋回でもワグワグしません。なかなか良いです。
うちのKbar-V120D02Sは上手くセッティングできてないせいもありますが、現状であれよりこっちの方が飛ばしやすいくらいです。

ただスワッシュサーボの固定が両面テープでぷにぷになのがいけないのか(いけないに決まってますけど)スワッシュ方向のぐらぐら感が消せません。スワッシュハンチングが出るぎりぎりまでゲインを上げてもまだぐらぐらした感じがあります。あとピッチセンターが合ってないのを直さずトラベルアジャストで吸収してるので、微妙な上下動がうまくできず、最後背面でべちゃっと落ちてるのもピッチ操作が思ったように効かなかったためです。


それとは別に問題なのがテール負けで、制御としてはちゃんと追いついてるんですが、少しピッチを入れながら左サイドフリップをするとおもいきりテールがブローアウトしてあさっての方を向いちゃいます。

恐らくテールローターの最大推力が足りてないので、モーターを高kVタイプにするか、または回しきれる範囲でローターを大径にするか、最悪の場合テールロッド延長でもなんとかなるでしょう。

いずれにせよ今のホビキン$9モーター(7700kV)はやめようと思います。中が砂鉄だらけだし。


最後のぺちゃ落ちで少しダメージを受けまして、ブレードグリップのボールが折れました。いや正確には折れたのを瞬着で付けてたのが取れました(おぃ)
全体的に泥だらけで掃除がめんどくさいなー。

ブローアウトが問題となると対策しようにも部屋ホバじゃテストできないので、また次の週末までお預けかもしれません。

2014年6月28日

Blade 130X やっぱり奇跡のヘリは良い

先週テールギアを破損して、V120D02Sギアに入れ替えた130Xを飛ばしてきました。
人間が退化しててあまり良いテストができませんが、最近飛ばしているmultiWii機の一番良い状態と比べても、大差をつけて130Xの方が良いです。

なんというか、うまく言えませんが正確でシミュレータというか… スティック入力以外のぐらぐらっとした動きの成分が全く無いので、補正舵を打つ場面がそもそもありません。

もう一つは、気のせいかもしれませんが、傾けてひっくり返す時に少しくらい水平からずれていても勝手に遠くに離れていかない気がします。でも意図的に斜めで強ピッチを入れれば水平ワープもできるので、気のせいだとは思いますが・・・。正確でぐらぐらしないから斜め具合を常に正確に制御できるので、勝手に離れていかないように感じるのかもしれません。


まるで腕がついていかないのでフライト動画を見せても意味無いかもしれませんが、クマー隊さんが5機も買うくらいのヘリは、庶民が飛ばしてもホントに楽しいですよー。

最後にピルエット2回転くらいでかなり斜めに傾いたのを見て、少しほっとしている自分がいました(笑)

こいつにもしピルエット補正がついていたら、multiwiiコントローラをいじろうという意欲はわかなかったかもしれません。それくらいパーフェクトに近いヘリです。


追記:
youtubeの右側のリンクから、強烈にすごい130Xムービーを発見したので貼っておきます。電源を3Sに変更しているようですが3in1と機体、モーターは全てストックです。ほんとにすごいです。


もういっぽん追加:こっちは異常に正確です。ピル補正なんてまったく不要ですね。

2014年6月26日

MINI MWC with DSM2で130Xもどきを浮かす

nanoWii機が遊べるレベルに達したので、以前ちらっと紹介したMINI MWC board with DMS2コントローラを使ってヘリを飛ばすプロジェクトをはじめます。

このコントローラはnanoWiiと以下の違いがあります
 

有利なところは安くて単体で送信機バインドもできるところと、ピンヘッダを外せば5gを切りmultiwii系の最軽量を狙えるところです。あ、一応バロメータとコンパスがついてるのも売りだと思います。

受信機とバインドの面では有利なんですが、PC接続がUARTなので、USB-UARTコンバータみたいなものが必要です。うちでは秋月のFT232ケーブルを使っています。

これに繋ぐために、1.25mmの4ピンコネクタを買ってきて、以下のような2.54mmピッチピンヘッダに変換するものを作ります。

こんな感じに使います。これをPCに繋ぐとPCから5Vも給電されて一時的に電源が入ります。
後で機体に前から押し込むために、固定用のネジ耳を1セットきり飛ばしました
シリアルコネクタにリセットピンが出てないので、arduinoIDEから書き込みをするときは、手動でいいタイミングでリセットをかけてやらないといけません。

MINI MWCボードの電源ON/OFFでやってもいいんですが、リセットピンがCPUそばの三角マークのところに出ているので、これをGNDに繋いでおいて、絶妙なタイミングで離すことでスタートさせるのが一般的なやりかたです。

うちの場合機体に積んだ後はこのパッドがさわれなくなっちゃうので、線をハンダ付けして機体の外に引き出しました。

で、書き込み手順は以下の通りです
  1. arduinoIDEで、シリアルポート番号を選んでおく。ボードタイプはATmega328を使ってるduemilanoveを選びます
  2. MINI MWCボードの電源とシリアルを例の4ピンコネクタでPCにつなぎ、リセットピンをGNDに落としてCPUを止めておく。(サーボを繋ぐピンヘッダの、基板面から一番遠い上端の列が全てGNDです)
  3. arduinoIDEで書き込みボタンを押し、コンパイル後、シリアルポートの通信速度が表示された瞬間にリセットを離す
  4. その後[0]か何かが数回表示された後、ハンドシェイクが始まれば書き込みが行われます。
今回は130Xのフレームを使うことにして、スキッドとメインギアの間の純正基板スペースに前からなんとか押し込めました。黄色いテープは緩衝材です。適度にテープを貼って厚みを調整して、押し込むだけでぎちっと固定されるようにします。


arduinoのソース内設定は、まずボードタイプとしてHK_MultiWii_SE_V2を選びます。他の328系でもいいと思いますが、これで使っている人が多いので実績があります。

ATmega32U4専用のオプション(A32U4_4_HW_PWM_SERVOS)とかは全てコメントアウトして、素直にソフトPWM出力のリフレッシュレート指定(#define SERVO_RFR_160HZとか)をコメントアウトして設定します。


ヘリで使う場合には1つ問題があり、ATmega328で4サーボ指定の時に通常使われる12番ピンがこのボードはありません。その代わり受信機がPPM接続でピンを消費しないので、通常は受信機からの入力に予約されてる5,6,A2なんかのピンが完全に空いていますし、ボード設計もそのつもりでフロントのピンヘッダに5,6,A2が出ています。

というわけで、def.hの以下のところを書き換えてA2ピンをnickサーボに割り当てます。


これで後はnanowiiと同様にヘリが飛ぶようになります。

ソフトPWMなので少し処理速度が心配でしたが、nanowiiがサイクルタイム2.8msのところ、MINI MWCは3.3ms、という程度の違いです。はっきり違いはありますがまあ問題ない速さは保っています。

(ちなみにうちで追加したピルエット補正を入れるとさらに+0.2ms遅くなります)


とりあえず130Xの廃品フレームにくっつけて、hobbykingの安物アナログサーボを両面テープで貼り付けたものでテストしてみます。

機体スペック
  • コントローラ: MINI MWC board DSM2
  • フレーム: blade 130X純正
  • テールモーター: hobbyking 7700kV ($9)
  • メインモーター: HP08S 8000kV
  • ESC: Plush12AとOrigin 10A
  • BEC: Plush12A内蔵の2Aレギュレータ
  • サーボ: Hobbyking TS541A*3  ←お勧めしません。$6くらいの安物デジタルを買いましょう
  • リポ: Deeforce 2S 350mAh


まだ全然安定しません。このサーボと両面テープじゃ永遠に安定しないかもしれませんが…

とりあえず部屋フライトとお外メイデンフライトです。





まだまだこれからですねー。

2014年6月24日

Blade 130X テールDギア交換 V120ギアへ

multiwii機の比較テスト用に、130Xを気を抜いて飛ばしていたらうっかりハードクラッシュさせてしまいました。

フェザリングシャフトのプチ曲がりはすぐ修正できたんですが、テールのDギアがなめてしまいました。
写真の白いDギアの軸をなめました
もう既にA,B,Cギアをなめ尽くして全てHKRCのメタルギアに代えているため、さすがにここだけはメタルにする自信はありません(絶対に落とさないならいいんですけど…)

プラギアはフルセットだとヘリモンは純正ABCDセットで1400円Hobbykingの互換ABCDセットで$4、てとこでしょうか。

ここのギアはよくなめるC,Dだけ2セットにしたお得パッケージもありまして、RCデポで420円(在庫切れ率高し)、なんとか今ならAMainHobbiesの$4がin stockです。



仕入れはいずれするとして、入手までの間飛ばないのも困るので、以前検討したとおり入手性の高いV120D02Sギアを使ってみることにしました。

以前はクリアランスがきついかな?と思ったんですが、ちゃんとテールを丁寧に組んであればただ装着するだけでギア自体はバックラッシュも適量ある状態ではまりました。

ただDギアの厚みがかなり違うので、元々あったアルミパイプのスペーサーが長すぎてはまりません。

せっかくのアルミを削って短くするのも嫌だったので、どうせこのスペーサーはベアリング脱落避けの役目だけだろってことで、熱収縮チューブを短く切ったものをはめておきました。もしかしたらすぐにトルクチューブのシャフト先っちょで削られてちぎれ飛ぶかもしれません。V120D02Sみたいなビニールの硬いチューブを見つけたら交換してみたいと思います。

これでテール周りは、ホルダー、テールシャフトの2つを除き全てV120D02Sパーツになりました。


とりあえず部屋で軽く浮かす程度なら違和感ありません。たぶんちゃんと飛ぶと思います・・・が。

2014年6月21日

一月ぶりくらいに貝塚フライト multiwii-CP

すっごく久々に貝塚飛行場で飛ばしました。30分くらいですけどね。

1機目は、すっかりメイン機になったmultiwii-CP 2Sの、ブレードをmCPx純正からxtremeのmCPx-BL用に変更したものです。

特に深い考えがあって変えたわけではなくて、単にもう少し重いブレードだと目に見えて飛びが変わるかな?と思っただけです。結果は・・・あまり違いはわかりませんでした。

以前純正miniCPボードを使ってたときには、このブレードだとロールレートが低すぎて小回りフリップができなかったんですが、multiwiiは元々私がぎりぎりまでPゲインを上げて、DRの方で絞って飛ばしているのでDRを増やすだけでくいくい操作できました。

まあ、気分でてきとーに使い分けてみます。

肝心のお外フライトの感想は・・・キャノピー無しで曇天だと見えない。これが一番ですね(笑)

二番目には、そもそも腕があまりにも鈍りまくっていて、これ撮りながら指が緊張でびくびく痙攣して落ちるかと思いました。

FFFと右旋回はこのサイズのヘリとしては非常に良いです。ぜんぜんガクガク上下に首を振られることがありません。
左旋回も首の安定度はいいんですが、左ラダーを入れるとテールがワグワグする癖があるのでちょっと気分的にいまいちです。気にしなきゃそれほど操作の邪魔にはなってないんですけどね。


フリップも良いんですが、テールの保持はまだ不十分です。サイドフリップして戻した時に(要は横チクの要素)かなりテールが動きます。スロットル操作の指ミスかもしれませんけど…

といってもV922やFBL80は完全に超えて、純正miniCPやnanoCPxと比べるレベルになってるので、飛ばしててなかなか楽しめるヘリになっています。

そして追加機能の背面ピルエット。まだピルフリもピルサーもできないんで使い道がないんですが、できる人なら活用していただけると思います。ああ、誰か上手な人にこれを飛ばしてみて欲しい…



最後の課題と言えるテールワグは、6軸ジャイロMPU6050のローパスフィルタをもっと高周波にセットすれば消える所まではわかっています。今は20Hzですが46Hzにするとほとんどテールはワグらなくなります。
ただ3方向のジャイロのフィルタを別々にはセットできないので、46Hzにすると今はスワッシュ側に振動の悪影響が出てヘリ全体としてのビタっとした安定度が落ちるため、テールワグの方を我慢しています。

もっと振動の少ないフレームかマウント方法があればここを改善できる可能性はありますね。
また、補正の処理サイクルは3ms程度なので、333サンプル/secでジャイロは読めているはずから、ちょっと苦しいながらもソフトを工夫すればスワッシュ方向だけソフトLPFをかけて安定させることができるかもしれません。

2014年6月18日

multiwiiヘリ作成記 nanoWiiコントローラ

最近マイブームのmultiwiiヘリ作成レシピを書いておきます。

必要なもの
  • ヘリ機体と、3ピンの普通のスワッシュサーボ×3
  • Hobbyking nanoWiiコントローラ
  • Hobbyking orangeサテライトRX
  • メインモーターとESC(サーボ信号を食べられるもの) BLHeliなら確実
  • テールモーターとESC(サーボ信号を食べられるもの)  またはトルクチューブ機の場合テールサーボ
  • multiwii-helimodソースコードと、arduinoの純正IDE
その他必要に応じて
  • (サテライトRXをバインドする環境が無い人は) なんでもいいからサテライトコネクタ付きRX  なんならKbarでもOK。
  • (メインESCに5VBEC出力が無い人は)5Vが出力できるBEC


今回うちの作例では、miniCP機体とサーボ、バッテリーは2S-240mAhでメインモーターはHP06v2とESCがXP-12A。テールモーターはHP03Tの8000kVとESCがPlush6Aを使います。


まず、サテライトRXを何か適当な受信機につなぎ、送信機とバインドしておきます。このバインド機能をmultiwiiにやらせるオプションもあるんですが、私自身はRX620でバインドしてしまったので未確認です。

そして、バインドしたサテライトRXをnanoWiiにつないで動作確認します。
このときソースコードのconfig.h内でサテライトRXを使うオプションを指定する必要がありますが、うちと同じボード、受信機で行く場合はmultiwii-helimod置き場からソースを拾ってきてarduino IDEからnanoWiiコントローラに書き込めば即動作します。

サーボ配線とモーター信号の取り出しですが、nanowii基板でハードウェアPWMを使う設定 (#define A32U4_4_HW_PWM_SERVOS を有効) にした場合、ピン番号は以下のパターンになります。

     * motor[0] = motor       = pin  6
     * servo[3] = nick  servo = pin 11
     * servo[4] = left  servo = pin 10
     * servo[5] = yaw   servo = pin  5
     * servo[6]  = right servo= pin  9
 うちの場合サーボコネクタのピンヘッダを全て除去して、以下のようにwalkeraコネクタ(molex  picoblade 1.25mm 3ピンハウジング)を瞬着固定してハンダ付けしました。
3ピンのうち、シグナルピンが一番基板に近い側に来るように着けるのがポイントです。

うちの場合は2Sで飛ばすので、XP-12AのBECからの5Vをサーボ電源入力に入れて、そこからMWCの制御部の電源入力までワイヤーで分配しました。

MWC基板は5Vを食べることになっています。実際はもうすこし低い電圧でも動きますが、1S機の場合はリポ直結だとモーターが回って降圧したときにリセットがかかります。1Sで飛ばす場合は昇圧コンバータを通すか、またはMWCboard5Vの入力にモーターとは場別系統の1Sリポを繋ぐのが現実的です。モーターと共用さえしなければ、サーボとコントローラの電源を共用するくらいなら1Sで問題ありません。


基板の置き方はいろいろ選べて、ソースコード内の #define FORCE_GYRO_ORIENTATION  という行が存在しなければ、デフォルトの向き、すなわちnanoWii基板に書いてあるでっかい矢印が機体前方向を向くように水平マウントします。

しかしminiCPをはじめとして最近の小型機フレームは基板を垂直マウントする設計のものが多いです。その場合、
#define FORCE_GYRO_ORIENTATION(X, Y, Z) {imu.gyroADC[ROLL] = Z; imu.gyroADC[PITCH] =  Y; imu.gyroADC[YAW] = X;}
と書いてやれば以下の写真のように垂直マウントできます。

miniCPの場合機体への固定は、まずプラ板を純正RXの位置にネジ止めして、その上にnanowii基板を強力両面テープで固定します。
これで振動的には苦しいんですがまあ飛びます。



ESCは普通のブラシレス機と同じように配線しますが、nanowiiから出てくる信号についてコメントしておきます。

メインモーターは、nanowii内でもモーターと扱われていまして、その場合
  • nanowiiがアーミングしてない場合、出力は常に0V
  • nanowiiがアーミング(スロットル最低で右フルラダー)すると、490hzでduty50%~99%くらい(幅にして1000~1950usくらい)のPWMが出てきます。この490hzは固定です。
これをESCに食べさせると、BLHeliファームなんかは超高速リフレッシュレートのサーボ信号だと認識して、ちゃんと0~100%のモーター出力に翻訳して動作します。サーボ信号だと思ってるわけなので、スロットルを0まで下げた場合でも50%幅のパルスを出し続けていないとESCのシグナル監視がロストしてしまって再始動できません。

multiwiiにはMOTOR_STOPというオプションがあるのですが、これをONにするとスロットルを最低に下げた時にディスアーム時のようにモーター出力が0V固定になるようになります。これは上のPWM出力をESCではなく、FET経由で無理やりブラシモーターに繋いだ場合を想定しているようです。

ブラシモーターに繋いでMOTOR_STOPをONにすれば、スロットルに応じて、0または50~100%の出力でモーターが回るので、まあ実用上は遊べるようになります。ただブラシモーターを使う場合はさらにEXT_MOTOR_RANGEというオプションもあり、PWMパルス幅の下限が50%じゃなくて0%まで連続的に繋がり、完全に0~100%幅出力のPWM信号が出てきます。

注意点は、モーター信号のPWM周波数はとにかく490Hz固定なので、BLHeliはこれを絶対にデューティPWMと解釈してくれず、うまく動作しないことです。EXT_MOTOR_RANGEとMOTOR_STOPはブラシモーター専用だよ!と覚えておいてください。



テール信号もまた悩ましくて、miniCPのように2モーター機なので、テール出力もmultiwii内でモーターと扱って欲しい・・・と思います。そのためのオプションYAWMOTORというのがあるんですが、ピン配置の関係で今回のようにハードウェアPWMをONにしている環境では、こいつはうまく機能しません。とにかくテール信号はサーボ信号として出すしかないです。

ただまあ、メインモーターの信号で説明したように、multiwiiの場合実はモーター信号だろうがサーボ信号だろうが、リフレッシュレートを変えて間をつめてるかどうかの違いだけで、どちらも1000~1950usのパルス信号が出てくるというのは同じです。

だからテールサーボのリフレッシュレートを #define SERVO_PIN5_RFR_RATE オプションで高めに設定(150Hzとか)しておけばメインモーターの信号と大差ありません。どうせBLHeliはサーボ信号として解釈しますし。

ただ、サーボ出力にはメインのところで出てきたようなブラシモーター用オプションは効果ありませんので、テールPWMをブラシモーター用のデューティ0~100%出力にすることは用意されたオプションだけではできません。



話が長くなりましたが、multiwii-helimodを拾ってくればそれだけでメイン、テールモーターともBLHeli-ESCでちゃんと動きます。

あとはセッティングだけですが、まずヘリコプターにはオートレベリング(自動的に加速度センサの値を使って水平に戻る機能)は相性が悪いです。
加速度センサのキャリブレーションは地面に置いた水平時しかできませんし、それが完全にできたとしても、フライト時にはヘリコプターが安定するのは水平ではなく微妙に右に傾いた状態です。
そのための専用パラメータレベルトリムをちまちま設定して空中で微妙に傾いた状態をデフォルトにすることも可能ではありますが、お手軽に安定するんじゃないのならオートレベリングの機能自体が要らないと思います。

というわけで、加速度センサの情報を全く使わないようにレベリング関連のパラメータは全て0にしておきます。マルチローター用語ではアクロモードと呼んだりします。

以下がうちのminiCP-nanowiiの設定です。



あ、サーボリバースの設定だけ説明しておきます。
上記の真ん中のサーボ画面で、謎の四角いタイルが9個並んでいます。これがリバース設定です。

これの列(COLL NICK ROLL)はスティック入力のコレクティブ、エレベータ、エルロンに対応していて、行(NICK LEFT RIGHT)はそれぞれのサーボがスティック入力に対してどちらに動くか、という方向を表しています。単にサーボの回転を逆転するだけではなくて、傾き方向の反応は同じでコレクティブ入力の場合だけ逆にサーボが動く、みたいな設定も自在にできます。V120D02みたいにコレクティブでスワッシュが下がる機種もOKですね。


あとは飛ばしてパラメータを追い込むだけです。

2014年6月16日

multiWii-miniCP-2S とりあえず完成?

前回の記事でだいたい完成かな、と思いきやピルエット補正に気を取られている間にテールホールドが悪化して泥沼にはまっていたmultiWii-miniCP-2Sですが、なんとか原因がわかりました。

というか、部屋ホバばかりしてないで外で飛ばせてればすぐわかったんですが… オチはピッチセンターが機械的に思い切りずれていたためでした。



もちろんずれてるのは認識してて、まあいいやとサブトリムでずらして飛ばしていたんですが、よく考えたらコレクティブ指令をテールの予測補正に使っているので、コレクティブのセンターがずれてるとテール補正量もずれまくり、さらに酷いことにコレクティブのプラスとマイナスでテール補正量が違うと言う結果になります。

これに気づかず、ピッチポンプでマイナスピッチに入れたときにテールが過回転してどうにも安定しないと悩んでいたんですが、ピッチセンターをロッドで合わせたらさっくり純正miniCPくらいのホールド感に戻りました。



そこを直して、今朝アパートの駐車場で撮ってみた動画です。フリップ時にテールがぐらっと振られることがなくなりました。これならもっとDRやピッチ範囲を増やしても平気そうです。

そして何より、初挑戦の背面時ピルエットでもサイクリック修正無しで傾きません。これは130Xにも無理なことだったのでちょと感動です。

昨日撮ったまったり部屋ホバの方も貼っておきます。こちらはピッチセンターの修正前なのでピッチポンプ時のテール安定が悪いです。

これでやっと完成記事が書けそうですー。

2014年6月13日

multiWii-2S 基板マウントをやりなおし

実に個性的な基板マウントだったmultiWii-2Sですが、無理なくサーボ線を取り回したいので、元のminiCPと同じ縦マウントに変更しました。元々のマウントビス穴も使えるので剛性面でも有利でしょう。

元々前を向いていたUSBコネクタが上向きに来るように固定しました。ジャイロ方向の指定はちょっと試行錯誤しましたが、config.h内の記述を
      #define FORCE_GYRO_ORIENTATION(X, Y, Z) {imu.gyroADC[ROLL] = Z; imu.gyroADC[PITCH] =  Y; imu.gyroADC[YAW] = X;}

としてうまく行きました。ROLLがZは納得いきますが、PITCHがY? X軸とY軸の定義が機体後方から見た定義ではないのか、または元々MPU6050のマウントでXY軸が入れ替わってたんでしょうかねぇ…


あちこちぶつけて歪んだ後遺症か基板マウントの変更のおかげか、左右ピルエットともラダーだけでぴしっと水平が出るようになりました。6畳間で両方向くるくるピルエット可能です。

もう少しテールを追い込んだらこれはいったん完成として製作手順とソースをシェアしようと思います。

純正キャノピーは着きませんが、大き目の紙キャノピーなら被せられるかもしれませんね。

2014年6月11日

しつこくmultiWii 2Sモーターに移行してテール安定度UP

multiWii機を室内で調整してて落っことして、機体やらサーボやらいろいろ壊してしまい、おまけにEEPROMの設定がふっとんでコントローラもまともに動かなくなってしまったので、問題きりわけのために修理したばかりのminiCP 2Sの機体にコントローラを移植しました。


miniCP純正のサーボケーブルが今まで使ってたhobbyking5220サーボより短いので、せっかくwalkera互換コネクタをコントローラに装備したにもかかわらず取り付けに苦労し、最終的に基板を45度傾けて搭載することでなんとか載せました。でもさすが汎用コントローラだけあって、こんな変態装着を考慮したオプションも最初から設定項目にあります。

重量は重いですけど2Sだからぜんぜん問題ありません。軽いESCとケーブルを使えばあと5gは下げられるでしょう。


といっても最初はホバリングすらできずに基板が壊れたかと思いましたが、レベリング関連のパラメータを全て0に戻して(使ってない)加速度センサのキャリブレーションをやり直したら、最終的にいい感じに安定しました。

元の2S機が非常に良いバランスだっただけあって、ピルエット時の安定度は1S実験機よりずっと上です。そんな室内ピルエット映像をどうぞ。

ピルエット時はラダーのみで、サイクリックでの修正は全く使用していません。(ただ、反時計回りは修正無しだと少し傾いて大回りになってしまうので映像には映しませんでした)

あ、そんなことより部屋が汚いですね。そうですね…

2014年6月8日

multiWii そこそこピルエット補正効いてる感じ

multiWii機のピルエット補正の精度を少し向上させて(1回転の検出割り算精度を向上)、ヘリ自体のメカセッティングも見直しました。(重心を中央に近づけて、ローターを少し重いものに変更)



PIゲインはいろいろ悩みましたが、可能な限りPゲインを上げる方向で再調整。
テールはジャイロの検出フィルタを20Hzまで戻して高速検出可能にし、その代わりPゲインを2倍以上増やし、小刻みにワグらせてでも保持力を上げる方向にしました。

Pゲインを増やすと室内テストでは素晴らしい挙動に見えるんですが、外で風が吹くとぐらぐらオーバーゲインで揺れたりしてなかなか難しいです。


梅雨入りしちゃってまともにテストもできないので、アパートの駐車場で少しだけフライト。大家さんの家がすぐ横なのでおっかなびっくりです。

ちっこくて分かりにくいですが、ホバ状態でなら何周回ってもそんなにぐらぐらしません。売り物のピルエット補正にはかなわないですが、まあまあに見えます。

ただこれは、重い機体がローターに吊り下げられて自動的に水平に戻る効果が加味されてるので、機体を傾けた状態でピルエットできなければ本当に成功とは言えません。
途中で少し傾けた状態で1回転ピルエットしていますが、少し水平側に戻っちゃう傾向はあるものの少なくとも別の方向に傾いたりはしませんでした。

だがしかし! 残念ながらテールの保持力自体がまだいまいちで、動画終盤のフリップ時にくるっとナチュラルピルエットして落ちるかと思いました。次はこっちのテーマと戦うことになりそうです。

2014年6月7日

miniCP BL-2S 修理完了

かなり長いことお蔵入りになっていたminiCPの2S機を修理しました。


故障箇所はサーボのギア欠け2箇所と、ESCを前後個とも交換です。


元々この機体がお蔵入りになっていた理由は、調子よく飛んでいても突然モーターストップでストンと落ちたり、突然テールが止まってお殿様墜落したり、といった原因不明トラブルが絶えないためでした。

当時は電波が途絶えてるのかとかRX基板にクラックが入っているのかとか制御系を疑いましたが、その後いろいろヘリを壊して、この手のトラブルは大半がESCのFET故障だということがわかってきました。


モーターの始動性が少しでも新品時より悪かったり、フライト時に稀に止まる、といった現象が出たらそのESCは3チャンネルのうちどれかのチャンネルがパワーダウンしていることがあります。
始動時に逆転することがある場合は完全に1系統死んでるのでESC故障か断線です。



2S機でペイロードには余裕があるので、以前使っていた高価なOrigin10Aを使うのをやめて、メインモーターにはXP12A、テールモーターにはPlush6Aを使うことにしました。どちらもケミコンを積んでいるので重いですが、その分BECレギュレータ付きでRX基板とサーボの電源を供給してくれるので以前とそれほど重さは変わりませんでした。

機首部分に無理やりESCを詰め込むと押されて断線トラブルが増えるのを学習したので、XP12Aはサイドマウントにしました。ちょっと太すぎてキャノピーの加工が必要になりそうです。

テール用のPlush6Aは機首に輪ゴム止め。重さは我慢できますが縦に長いですねえ…

メインモーターはHP06(2S用)で、テールモーターは8000kVのHP03Tです。この構成はT-Rex150とほとんど同じで、フライト性能も非常に似通っていると思います。

フレームやメインシャフトのヤワさはこのレベルのパワーをまったく想定していないので、REX150ほどの正確なフライトはできないとも思いますが、私程度では違いが分からないでしょう。



梅雨入りしちゃったので会社の食堂で少し調整フライとしただけですが、安定度と機動性のバランスは非常に高く、最近セッティングをかなり煮詰めて良くなってきたnanoWii-CPと比べてもこちらの制御の方が圧倒的に良いです。ピルエット補正機能だけはありませんが、2回転くらいくるくる回ってもさほど姿勢を崩さないので、そもそも補正など必要無さそうです。

2014年6月5日

VBar Android 1.2.1動作しました

Bluetoothで接続してKBarのテレメトリーは取れるのにどうもエラーが多発しているようで設定の読み書きができない。具体的にはandroid画面右上のステータスランプがERRORとENABLEの繰り返しで点滅している状態でCONNECTの緑には最初の接続時に一瞬しかならない、という症状で困っていましたが・・・

いろいろぐぐっていると、

http://www.helifreak.com/showthread.php?t=405871

同じ症状の人がいて、コメントには「androidを再起動してみるといいよ」と投げやりなアドバイスがあったりました。
この投稿者さんはその程度では解決しなかったようですが、そういえばうちも再起動はしてないな、と思ってダメもとでやってみたら・・・

あっさり解決! そんなんでいいのか!


というわけで、もう少し気長にKBarセッティングと付き合えそうです。

2014年6月4日

Kbar bluetoothで現場セッティング

V120D02に積んでいる$26の激安Kbarですが、今までは自宅のパソコンでUSBセットアップして、現場で1フライトしてダメなら持ち帰り、としてました。非常に効率が悪いです。

もちろん本家Vbarには各種セッティング手段がありまして、パソコン、Bluetoothによるandroidアプリ、プログラミングボックスが選べます。

プログラミングボックスのパチ物ももちろん存在していて、nobさんが箱目当てに買ったGY280RXにも付いてます。nobさんの記事によれば他のvbar互換ジャイロにも使えたそうです。もう少し安いminiSBARにも付いているようですが、中華文字なのと、こちらがKbarに使えるかどうか情報はありません。



専用ボックスが一番便利だとは思うんですが、$26のジャイロをセットアップするのにそれ以上払うのもなんか釈然としないので、手持ちのBluetoothアダプタでandroidセットアップを試してみました。

適当にぐぐると、Kbar側のUSBコネクタの左にある4ピンがシリアル端子で、上からVCC、GND、TX、RXだそうです。ケースにはVCCピンのところに小さな△マークがモールドされてますね。


ここにBluetoothシリアルのスレーブモジュールを繋げばいいのですが、通信条件が9600bps パリティ無し、ストップビット1bitだそうです。

昔は適当にモジュールを買ってくるとデフォルト設定がそうなってるものが多かったので劇楽でしたが、最近arduinoとかmultiWii用にセットアップされてることが増えてきて、デフォルトは115200bpsになってるものが多く、自分で設定変更が必要です。



Hobbykingだと MWC FC Bluetooth Module Programmer がありますが、デフォルト速度が115200に設定されてます。
お得意様のBanggoodだと、マスタースレーブ両用可のHC05か、スレーブ専用のHC06があります。どちらもデフォルト速度は不明ですが、もしも通信速度変更が必要な場合、HC06の方がセットアップが簡単です。
あと、詳細不明ですが納期待ちたくない方のためにヘリモンにも数種あります。


うちでは今回、昔Hobbykingで買ったMWC用のモジュールを使いました。スレーブ用のHC06相当です。BLHeliテレメトリーで遊んだ時に1200bpsに自分で変えてしまっていたので9600に戻して、HTC desire HDでモジュールのみのバインド確認。

そして公式androidアプリを580円で購入して(ダメなら払い戻しできますしね)

モジュールをKbarに繋いでandroidアプリから接続を選んでみたら、あっさり繋がりました。
これでなんとか現場セッティングができそうです。
この写真では白と灰色が(モジュール側で)TX,RXです
Kbar側のピン配は上からVCC、GND、TX、RXと言いましたが、モジュール側にベースプレートと4品が出ているタイプは、モジュール側も同じ配列です。
ってことは、お互いのTXとRX同士を繋いでやらないと通信できませんから、4ピン全て順に繋ぐのではなく、TXとRXはねじって入れ替えて繋いでやります。まあ失敗してもすぐには壊れないですからダメなら両方試しましょう。

若干気持ち悪いのは、ちゃんと通信できていてリアルタイムでセンサ値や積分値もノイズなく読めるのに、画面右上のステータスアイコンにはERRORと出ています。実戦投入でちゃんと機能するまでちょっと不安です。

→実機で試してみました。テレメトリーだけは取れますが、かんじんの設定内容は通信できていないようです。android側でゲイン等を変更してもジャイロ側には反映されていませんでした。KbarがダメなのかBluetoothアダプタの問題かまだわかっていません。
→その後androidを再起動したらちゃんとステータスCONNECTになり無事に設定も取れました。


シリアル通信慣れしてる人ならセットアップは試行錯誤でなんとかなりますが、普通の人が同じことをするとき、ネックになるのはBluetoothモジュールの通信速度セットアップだと思います。特にHC05を買ってしまうとかなり難しいと思います。

今Banggoodに頼んでるモジュールが届いたらまた少し記事にまとめてみたいと思います。

2014年6月2日

mutiWiiにピルエット補正を・・・(失敗)

コメント欄での激論の末、一応ピルエット補正を理解した・・・ような気がするのでmultiWiiに実装してみました。

Iゲイン(正確には積分エラー項)を毎回ヨージャイロの値に応じて三角関数を使って回転させてやります。
プログラムコードは超絶手抜きですが(sinやらdoubleやら使ってなんの工夫も無し)、高速化の前にまず実用になるか確認したいので試しにやってみました。



動作確認はフタバのローテーショナルコレクションと似た感じに、
  1. モーターコネクタ外す
  2. バインドして、スロットルを中間くらいまで上げる
  3. エレベータダウン。スワッシュが傾いたらスティック戻す
  4. スワッシュが傾いた状態のまま、手で機体を右にずりずり回す
  5. スワッシュの向きが変わらなければIゲインがピルエット補正対応
という方法で確認します。うちのmultiWiiは減衰しないIゲイン補正なので確認しやすいですが、減衰タイプの場合は3から5の間をささっと急いでやる必要があります。




一応動いているようです。
これは床に置いて試してますが、手でローターヘッドを持って、スワッシュを傾けてから機体の方をくるくるっと手で回してやるとサーボがすごい勢いで上下にしゃかしゃか動いてスワッシュ状態を維持しようとするので、ある程度高速ピルエットでも補正は効きそうです。


が、外でテストフライトしてみたところ、どうにもうまくありません。
1回転させるとぐらっと傾いた機体がある程度元に戻るので、補正無しよりは連続回転させた時のぐらつきが少ないですが、大型機みたいに定点でくるくる回る感は無く、おおいにぐらぐら傾きながらなんとか横転はしないように戻している、という感じです。


その場でくるくる綺麗に回る機体を作るにはまず、補正無しでも1回転くらいできるように機体そのものの素性をある程度よくしておかないと補正だけでは苦しそうです。

もう少しこのコントローラを煮詰めたらV120クラスに積んでみると面白そうですね。