Tag Archives: ドローン

Jumper T8SG V2 Plus ~その2~

前回紹介したJumper T8SG v2Plus、正常動作が確認できたので予定通りMODE2→MODE1に改造します。

その前にこのMODE1や2ってなんなのさ?という事を簡単に説明しておきます(このブログはラジコンやドローンよりもどちらかというと工作寄りなので)。
ラジコンの送信機で空モノを操縦するとき、基本の4つの軸(スロットル、ラダー、エルロン、エレベーター)を 2本のスティックで 操作します。2本のスティックそれぞれを縦と横に操作するので4つの軸を操作できるわけです。この時どのスティックにどの軸を割り当てるかで色々なMODEがあります。MODEには1から4までありますが大抵はMODE1かMODE2が使われています。日本では歴史的にMODE1が使われてきましたが海外ではMODE2が多いそうです(なぜなんでしょうね?)。

私も昔からMODE1を使ってきました。 どっちのモードが操縦し易いのかというと色々意見があるでしょうが、何にせよ最初に使い始めたモードに慣れると簡単に変更する事はできません(といいつつも息子は飛行機を飛ばしていた頃はMODE1でしたがマルチコプターを飛ばす様になってからMODE2に変更してしまいました)。

話は戻りますが今回購入したT8SGは前回書いた様にショップの在庫の関係でMODE2なので改造が必要なのです。大抵の送信機はジンバルの構造が似通っているので問題なく改造できると思います。

なおMODE1とMODE2の違いは2本のスティックの縦方向への割り当てが、MODE1だと右手がスロットル、左手がエレベーターですがMODE2だと逆になります。通常エレベーターはスティックから手を離すとバネで中立に戻りますがスロットルは手を放してもそのままの位置を保持します(そのため適度な摩擦感を持たせてある)。なので改造の主な内容は左右のバネ感と摩擦感を出すパーツの入れ替え作業となります。

では蓋を開けてみます。
本体裏側のネジを6本外して本体の肩の部分にあるスイッチを止めているプラスチックをこじ開けると裏蓋が外れます。
裏側から見ているので写真右側のスティックが左スティックで、このスティックの縦方向の操作がスロットルに割り当てられています。

中身

スロットルは摩擦感が必要なので金具で押さえつけてあります。

金具を取り外しました。

そして右ジンバルには中立に戻す為のバネがあります。バネ上側を取り付けてあるプラスチックパーツはバネの力だけで保持されているので引っ張り上げれば本体から外せます。

バネを保持していたプラパーツ
そしてカムを押さえつける為のレバーとバネ。
このレバーがスティック側のカムを押さえつける事で中立に戻るのです。

右スティックから外したバネとプラスチックパーツを左スティックに取付けます。

そして左スティックから外した押さえ金具を右スティックに取付けます。

ネジの締め具合で抑え圧を調整できる様です。

あとは元通りに裏蓋を取付けて電源を入れ、メニューからMODE1設定に変更すれば完了です。

これで暫く快適にシミュレーター(VelociDrone)をしていたのですが、突然右スティックを左右に動かしたときにキコキコという軋み音が出る様になったので、もう一度裏蓋をあけて右ジンバルを外してみました。


隙間が狭く当たりそうな箇所に細く切った紙を挟んで見ましたが接触している箇所はなく、やはりカムとレバーが擦れる部分で摩擦音が出ている様です。そこで 細いエナメル線にグリスを少しつけ、薄く塗ってみたら軋み音は消えました。

先日モーターのコイルを巻き直したエナメル線の切れっ端でグリスを塗った。


外したついでにジンバルを眺めまわします。この機種はホールジンバル採用というのがウリとなっていて、可変抵抗ではなく非接触のセンサーなのですり減る心配がないそうです。
恐らくこのコンデンサーマイクかと思う小さな部品と横の基板がホール素子を利用した角度センサーの様です。

これどういう仕組みなのでしょう?
ロボットなどではレゾルバという角度センサーがあります。こちらは直交コイルで回転磁界を作っておき、その中に可動するコイルを入れておくとコイルの角度によって誘導電圧の位相が変るので、位相のずれ角からコイルの角度を検出します。
実物のホールジンバルを見るまではレゾルバに似た仕組みかと想像していましたが、このサイズで実現できそうな気がしません(いや最近の中国の技術なら実現できるのか?)。
コンデンサーマイクっぽいのが磁石なのかな?

なにはともあれ軋み音は消えたのでフタを閉めました。
何となく3台並べて撮影。

左から息子のT10J、私のT6EX、そして今回のT8SGv2Plus

どどーんはじめました。~その9~ 初レース

鹿児島県出水市で開催されたU199ドローンレースに参加してきました。
息子に触発され、今回は私も初参加です。

コース図は一週間前に公表されました。8の字や二連ゲートがあり自分に飛べるか不安です。
そこでVelociDrone(シミュレータです)内にコースを作って練習しましたが・・・コースを作る事に慣れておらず、コースづくりの方に時間が掛かってしまった。。。

午前のコース。午後は若干変更になりました。

まあそんなこんなで会場に到着。昨年息子が参加した時と同じ会場です。

出水市陸上競技場
コース
運営席/操縦席

午前は練習、午後はレースとなっています。
なお参加者は8人の予定でしたが当日都合がつかなくなった方がおられ5人でのレースとなりました。

午前中は風も弱く、遅いながらも周回できていましたが、午後から風が強くなってゲートをくぐるのが難しくなり、墜落しては再離陸の繰り返しです。またコースが広すぎるという事で午後は少しパイロンの間隔が縮められ、初心者には余計に厳しくなりました。

それでも最後の方は何とか落ちずに周回できる様になってきましたが、他の方々のタイムの倍以上の時間で回っています。

で、結果ですが予想通り私は5人中5位です。息子は結構頑張って2位になっていました。→レースリザルトのページ

途中でヘリデウス様ご提供のトイドローンを賭けたゲーム(手裏剣に見立てたプロペラを箱に投げ入れて入った数を競う)がありましたがこれも結構難しくてトイドローンはゲットできず。。。

でも参加賞としてエアクラフト様ご提供の送信機グローブ を頂きました。
寒い時に送信機を入れ、左右から手を突っ込んで操作できます。

これで厳寒期も練習だ・・・。

成績はボロボロでしたが昨年は見ているだけだったレースに今年は参加でき、楽しい一日を過ごさせていただきました。200グラム以下のレースが近くで開催されることは少なく貴重であり、次回も是非実施して頂けると嬉しいです。
だがその前に腕を磨かねば。。。

ARマーカーでドローン制御

ドローンを自動制御してみたくなりました。
いきさつを言うと、とある大学でドローン競技があり、その中に人が操作せず空中に5秒間ホバーリングさせるという種目があるのを知りました。私が競技に出場する訳ではないのですがこれをやってみたくなりました。

まず空中に静止させるには考えられる方法が色々あります。GPSで座標を取得してフィードバックするというのが一番ありそうですが、世の中に既にあるし屋外で実験するのも中々大変です。できればコアレスモーターの軽いやつを使って室内で試したいのです。そこでARToolkitなるものを使ってみようと思います。

前に作った「どどーん」を使いたい。

ARToolkitはARマーカーという図形を印刷しておき、これをカメラで映すと画像に3Dの物体が合成されて現れるアレです。詳細はこちらを参照ください。
ARToolkit本家→ http://www.hitl.washington.edu/artoolkit/
工学ナビさんの説明→ http://kougaku-navi.net/ARToolKit/

そしてマーカーはこんな感じの図形です。

ARToolkitについてきたサンプルマーカーをそのまま使用

ARToolkit自体はCのライブラリなのでVisualC++から呼び出します。
ARToolkitに画像を渡しマーカーを認識しすると、マーカー座標からカメラ座標への変換行列が得られます。 ARtoolkitの一般的な使い方ではこれを元に図形を描画するのですが、この行列にはマーカーの位置が3次元的にどっちにあるか、またどの方向に傾いているかという情報が含まれるので、今回はこれを元にドローンを制御し、常に同じ位置にマーカーが見える様にしてやればホバーリングできるはず・・・という目論みです。

最初はこんな感じでやろうと思っていました。

ARマーカーは壁等に貼っておきます。

そしてコントローラーはこれ。Arduionoでサーボを制御して送信機のスティックを動かすという無理やりな構造。

やはりこのコントローラーは無理がありました。最初は手動でホバーリングさせてから自動に切り替えたいのですが、この切替がうまくできません。また縦軸を動かすと横軸が微妙に動くという問題もあります。 制御パラメーターの微調整が必要になる筈ですが、不安定なコントローラーでは訳が分からなくなりそうなので、まずはPCが考える値を確実にドローン側のフライトコントローラーに伝えるため、以前作ったTWE-Liteを使った送受信機を使う事にします。

またドローンに搭載したVTXから送られてくる画像では画質が今イチな上に振動の影響なのかARマーカーの認識が不安定でした。そこでARマーカーをドローンにぶら下げ、三脚に固定したカメラで検出する方法に変更しました。これでもマーカーが揺れますがカメラが固定なのでこっちの方がマシなのです。

カメラは固定に変更。ドローン側にARマーカーをぶら下げます。
こんな感じで糸でぶら下げました。

固定カメラで見たマーカーの位置を元に制御量を決め、FT232RL→TWE-Liteを経由してドローンのフライトコントローラーに伝えます。
また最初に手動で浮かせてから自動に切り替えるのでRC送信機→受信機→HOI-Link→PCの経路で送信機の操作量をそのままドローンにスルーすることもできます。HOI-Linkはこれまた先日作成したS-BUS→HIDコンバーターで、ラジコン受信機が出すS-BUS信号をPCからジョイスティックに見える信号に変換してPCに入力します。
なお手動と自動は送信機のスイッチで切り替える様にしました。

こんな感じで何枚もペラを折ってしまいながら調整を繰り返しました。
スロットルの制御が一番難しいです。まあ自分が操縦しても高度を維持するのが結構難しいので自動制御でも同じなのでしょう。特にロール、ピッチ、ヨーの制御だったらニュートラル位置がだいたい決まっているのでそこを中心に上下してやればよいのですがスロットルだけはこの値にすれば上下しない位置というのが決まっていないしバッテリーの残量によっても変わってくるので飛びながら調整していく必要があります。

そんな感じで何とかホバーリングが10秒以上は 持続するようになったのが次の動画です。まだ上下動が大きいのでもう少しパラメーターを調節したいところ。またバッテリーが消耗してくると何故かYaw軸が右に回ってきて制御で打ち消せなくなってきます

追記・・・

その後パラメータをイジってかなり安定になりました。
またYaw軸が回ってしまうのは機体の特性っぽいですが、これを制御で抑えられない原因が判りました。ドローンが右に回った時、回転行列から取ってくる角度が本来ならマイナスの値になる筈なのにプラスの値になる場合があります。この時自分の目で見てもマーカーは左に回っている様に見えるのです。この原因はARマーカーを印刷した紙が風で曲がっている為だと思います。ARToolkitはマーカーの四隅の頂点位置から角度を算出しますが、マーカーの角が曲がると正しい角度を割り出せないんですね。そこでマーカーの曲がり易そうな箇所を裏からスチレンペーパーで補強したところ、イイ感じになっています。
これでバッテリーが無くなるまでホバーリングを続ける様になりました。
安定化後の動画 ↓

TWE-Liteプロポ化計画~その2~

前回は受信機を作ったところまで書きました。あれから2カ月も過ぎてしまいましたが、Maker Faireも終わったことだし送信機に取り掛かります。

どんな形にしようかと考えた結果、こういうラジコンカーっぽいコントローラになりました。スロットルは引き金、ヨー(ラダー)がホイール、そしてピッチとロールは加速度センサーでコントローラの傾きを検出します。
正規のプロポではなくTWE-Liteなので自由なコントローラを試せるのです。

TWEpropo2_1

送信機とクワッドコプター

電源は2セルのLi-po。レギュレータで3.3Vに落としてTWE-Liteに入れています。
TWEpropo2_2

・・・実はこの機体とコントローラは先日のMFT2018で息子のブースを間借りして展示しました(自分のブースの展示物とは少し毛色が違ったので)。しかしまだ一度も飛ばしていません。というのも機体は開催1週間前に宅配便で発送し、そのあとで送信機を作ったので一度も飛ばす機会が無かったのです。MFT会場で初飛行する訳にもいかない(まず一発では飛ばないし)ので今回が初めてとなります。

で・・・やっと飛ばしてみましたが、ものすごく難しいです。コントローラの傾きでロール・ピッチを制御するのが敏感すぎてまともに飛び上がれません。フライトコントローラの設定で感度を下げたり色々やってみようと思います。

上手くいったらまた報告します。

どどーんはじめました。~その4~

先日作成したマルチコプターは重量が50グラム程度なので室内でも飛ばせます。
しかし何しろ初心者につき、あちこちにぶつけてしまうのでプロペラガードを取付ける事にしました。

まずデータを作って・・・

PropellerGuard

プロペラガード

4つプリントして取付けました。

PropellerGuard

プロペラガード取付け完了。

壁に軽く当たってもバウンドするのでダメージがありません。
安心して操縦の練習ができます。

どどーんはじめました。~その3~

今回のマルチコプターでS.BUSを初めて使ったので信号をArduinoで読み出してみました。
S.BUSとは何かという詳しい説明はコチラ→https://ja.wikipedia.org/wiki/S.BUS
要はラジコン受信機から昔ながらのサーボ信号を出すのではなくシリアル通信にする事で全チャンネルを1本の信号線で制御するという物です。

飛行機の場合はサーボの位置が分散しているので結局それぞれに配線する必要があり、あまりメリットを感じませんでした。しかしマルチコプターでは受信機の信号は全てフライトコントローラ基板に接続するのでこれが一本で済むのは大きなメリットになります。

S.BUS信号はシリアル通信ですが、UARTでよく使う仕様とは微妙に違うところがあり面倒になっています。例えば次のところ・・・

  • ボーレートが100Kbps。
    なぜか115.2Kbpsではなく100Kbpsです。妙なボーレートですがArduinoではSerialBegin()のとき100000と指定する事で対応できます。
  • 信号極性が逆転。
    Arduinoに入れる信号はインバータで反転してやる必要があります(もしかするとArduino側に反転機能があるのかもしれませんが見つけられませんでした)。

あと受信後のデータが11bit区切りなので並べ替えがややこしいです。

S.BUSプロトコルに詳細はこちらを参考にしました。→https://os.mbed.com/users/Digixx/notebook/futaba-s-bus-controlled-by-mbed/http://anarchy.hatenablog.com/entry/2014/12/07/181853

そして最低限の部分をスケッチに書きます。

int count;
long interval;
void setup() {
 Serial.begin(115200); // Terminal
 Serial1.begin(100000,SERIAL_8E2); // S-BUS
 count=0;
}

void loop() {
 int data[26];
 int val[19];
 int i;
 if (Serial1.available() > 0) {
 data[count]=Serial1.read();
 interval=millis();
 count++;
 }
 if ((interval+4 < millis()) && (0 < count) ) {
 count=0;

 val[0] =((data[1] & 0xff)<<0) + ((data[2] & 0x07)<<8);
 val[1] =((data[2] & 0xf8)>>3) + ((data[3] & 0x3f)<<5);
 val[2] =((data[3] & 0xc0)>>6) + ((data[4] & 0xff)<<2) + ((data[5] & 0x01)<<10);
 val[3] =((data[5] & 0xfe)>>1) + ((data[6] & 0x0f)<<7);
 val[4] =((data[6] & 0x0f)>>4) + ((data[7] & 0x7f)<<4);
 val[5] =((data[7] & 0x80)>>7) + ((data[8] & 0xff)<<1) + ((data[9] & 0x03) <<9);
 val[6] =((data[9] & 0x7c)>>2) + ((data[10] & 0x1f)<<6);
 val[7] =((data[10] & 0xe0)>>5) + ((data[11] & 0xff)<<3);

 val[8] =((data[12] & 0xff)<<0) + ((data[13] & 0x07)<<8);
 val[9] =((data[13] & 0xf8)>>3) + ((data[14] & 0x3f)<<5);
 val[10]=((data[14] & 0xc0)>>6) + ((data[15] & 0xff)<<2) + ((data[16] & 0x01)<<10);
 val[11]=((data[16] & 0xfe)>>1) + ((data[17] & 0x0f)<<7);
 val[12]=((data[17] & 0x0f)>>4) + ((data[18] & 0x7f)<<4);
 val[13]=((data[18] & 0x80)>>7) + ((data[19] & 0xff)<<1) + ((data[20] & 0x03) <<9);
 val[14]=((data[20] & 0x7c)>>2) + ((data[21] & 0x1f)<<6);
 val[15]=((data[21] & 0xe0)>>5) + ((data[22] & 0xff)<<3);
 val[16] = (data[23] & 0x1) ? 0x7ff : 0 ;
 val[17] = (data[23] & 0x2) ? 0x7ff : 0 ;
 val[18] = (data[23] & 0x8) ? 0x7ff : 0 ; // Failsafe

 for (i=0 ; i<19; i++ ) {
 Serial.print(val[i],DEC);
 Serial.print(F(" "));
 }
 Serial.print(F("\n"));
 }
}

S.BUSから取り込んだデータをUSB経由でシリアルモニタに表示したいので、シリアルポートが複数あるArduino MEGA2560で動かしてみます。

S.BUSモニタ

Arduino MEGA2560でS.BUSをモニター。
ブレッドボード上のICは信号極性反転のための74HC00。

 

こんな感じでデータが出てきました。
送信機が6CHなので7CH以降が正しいかどうかは確かめられていません。また19番目のデータはFailsafeが働いたときに1になるはずですが、これも確かめていません。

S.BUS monitor

モニター中。

各データが11bitt幅なので0~2047が表せるはずで、どうやらニュートラルが1024の様です。
ところでCleanflightにも受信データを表示する機能があります。しかし今回のモニターとCleanflightの値が一致しません。そこで何ポイントか対応を取ってみました。

 SBUSモニタ Cleanflight
       102         943
       697        1315
      1024        1520 ←ニュートラル
      1435        1776
      1681        1930

グラフにすると・・・

SBUS-CleanFlight

SBUSとCleanFlightの読値対応

恐らくCleanflightの表示値は昔ながらのPWMサーボ信号のパルス幅に換算した値をμS単位で表示しているのだと思います。例えばニュートラルはS.BUSの生データは1024ですがPWMだと1520μSといった感じ。
ということでS.BUSの生の値にざっと0.625掛けて879.5を足すとほぼCleanFlightの値になる様です。