Dropbox

DJI Digital FPVゴーグル用アンテナLumenier AXII HDアンテナのテストは一度行っていますが、急いでテストしたため自分でも結果に自信が持てなかったので再テストを行いました。

前回のテストと同じ場所で少しコースを変えてテストしました。今回は各アンテナ構成で二度飛ばして同じような結果になることを確認しました。またゴーグルが記録している数値データの評価も行いました。取れているデータを見てみると信号の強さは4段階しかありませんので評価からは除外しました。遅延が使えそうな気がしていましたが、実際に限界状態で飛ばしている時と数値の悪さ加減が今ひとつ一致していませんでした。ということで、一番状態をよく表しているのがビットレートでした。それぞれのアンテナ構成で2回飛んだうちで良い方のデータをグラフにして比較しました。

X軸は時間あるいは場所に相当しますが各フライトの速度は違うので完全には一致しません。そこで信号が悪くなり始めた特定の場所をビデオから判断して各グラフの位置をそこで合わせました。

結果をみるとDJIのオリジナルアンテナは速くから脱落し始めています。そして画面をロストしてしまい機体を元の位置に戻すことが出来ませんでした。二度のフライトとも同じでした。あとは微妙な違いです。しかしながらパッチアンテナを下にした方が落ち込みが大きいです。実際に飛ばした時の感じからも危うさを感じました。パッチアンテナを上にした場合と混合構成はほぼ同じ結果でした。飛ばしていた時の気持ち的には前回の結果も有ってパッチアンテナを上にした時の方が安定していたように感じました。データをみたりビデオを見る限りほぼ差はなかったのかもしれません。

わたしの結論としてはパッチアンテナは上に付けて使っていこうと思っています。

一部SNSで紹介済みですがInsta360 Goを見事な操縦技術でまっすぐに公園のベンチの金属部分にぶち当ててレンズを割ってしまいました。SNSでは言っていませんが同時にCaddx Nubulaのレンズも割っています。

先にInsta360 Goのレンズを破壊済みの同志から公式サイトで修理を受け付けていることは聞いていましたので修理に出しました。その経過を書いておきます。

9月15日(火) Insta360の公式サイトの修理サービスというページから修理依頼を行いました。直ぐにメールで故障した製品の送付手順が送られてきた。公式サイトは日本語で操作していましたが、在住国が中国なのでメールは中国語です。
9月17日(木) 宅配便にてレンズの割れたInsta360 Goを送付。修理サービスサイトに宅配便のトラッキングコードを入力。
9月19日(土) 目的地に到着しているものの休日のため配達出来ず。
9月21日(月) 配達完了。Insta360から受け取った旨のメールを受信。
9月22日(火) Insta360から検査完了のメールを受信、けっこう夜遅くでした。
9月23日(水) 修理の見積もり価格の提示があった。午前中に価格の提示があったが、実際に支払ったのは夕方遅くでした。にもかかわらず、すぐに発送のお知らせが来ました。
9月25日(金) 荷物到着。シリアル番号も違う新品が返ってきました。ちょうど10日目に戻ってきましたが、わたしの方からの発送が2日ほど遅れたので実質8日間でした。まずまず悪くない対応だと思います。

修理費用は新品購入価格の約7割ほどでした。付属品を除いた本体だけの値段と考えれば納得です。

FPVドローンの世界で小型精密電動ドライバーと言えばWowstickですが、小米からも同様というかそっくりな製品が出ているので入手してみました。

もともと定評のある小米の精密ドライバーセットを使用していました。これは日本語での記事も多数見つかるようにとても出来の良いものです。代表的な記事としてEngadegt Japanに我らがガジェットキングShimoKenさんが書かれているものをご覧いただくと良いかと思います。この製品はほんとうに良く出来ているので、その流れを組むのならば電動版もきっと良いものであろうと思い買ってみることにしました。



右が以前から持っている精密ドライバーセットです。ケース上にドイツのWiha Toolsのロゴがあります。実際にはビットの一つ一つにもwihaと刻印されています。左が今回購入した電動精密ドライバーセットです。当然ですが、非電動品より一回り大きい筐体です。残念ながらWihaロゴはありませんが、大変良く似たデザインになっています。ビットはそれぞれ微妙に違うので、両方持っていることの意味が出てきて私的には嬉しいです。電動の方に付いている長いサイズのビットも地味に嬉しい。

初日に充電してから、数日使用していますが、まだ電池切れまで使っていませんので電池の持ちとかは分かりません。この間にBeta95X V2のフレーム交換を一回とあとは日常的な作業をこなしているので、おそらくは電池の持ちで不満を持つことは無いと思います。

トルクは二段階に調整出来ます。そこそこの強さはありますが、固めに閉まっているネジは最初に手で回して緩める必要があります。それも本体が普通のドライバーのような太さですので、片手で回して緩んだところで電動をスタートするというのが握り直すこともなく一連の動作で行なえますので効率が良いです。逆にネジを締める時に自分の手の力で締めたい時も同様に一連の動作で電動駆動から手回しに移れますのでとてもスムースです。

小さなドローンではネジの数もしれていますし、手回しでも疲れるということはありませんが、一度電動ドライバーを経験してしまうと手放せなくなります。日本で入手出来るかどうかはわかりませんが中国での販売価格はかなり手頃なものですしオススメのツールです。

最初にも書きましたがWowstickにそっくりです。何かしら関係があるのかと軽く調べてみましたが、まったく繋がりは見えてきません。パクリ商品なのでしょうかね?

BlackBoxログは奥深くなかなか完全に使いこなすことは難しいですが、なんとなく少しずつ使うようにしています。今までは標準のBetaflight Blackbox Explorerを使用していました。これは時系列での事象を確認するのに適したツールです。この動作のときにはpropwashが起きているとかスティックの動きに追従出来ていないとか、受信機からの信号が失われてfailsafeになる様子、あるいはクラッシュ後にdis-armする代わりに飛行モード切り替えスイッチ動かしているみたいな事も分かります。

もう一つのBlockboxを解析するツールであるPIDtoolboxについて簡単な使い方を調べたので、それについて書いてみたいと思います。私自身が使いこなすというレベルではないので走らせ方と初歩的な解説にとどまります。それすら間違ったことを書いている可能性を踏まえて読んでみてください。PIDtoolboxはログ全体を見渡して統計的な処理を施し、視覚に訴えるデータを表示するツールです。PIDの調整やジャイロのノイズに対して絶対値で語るだけの知識がなくても調整前後あるいは良い機体と悪い機体のデータをグラフで比較することにより問題点が見えてきます。

[ 導入 ]
PIDtoolboxはGithubにて開発管理が行われています。ダウンロードはreleaseページで行います。2020/09/10時点の最新バージョンはv0.392です。以下の話は、このバージョンでの話です。

Windows版もMac版もほとんど同じです。ダウンロードしたzipファイルを展開しruntime_installation_file/MyAppinstaller_webというプログラムを実行し導入作業を行います。このインストーラーの主な目的はMATLABという外部プログラムの導入です。ところが、ついでにPIDtoolboxをプログラムメニューにも登録します。これが曲者でWindowsスタートメニューあるいはmacOSのアプリケーションからPIDtoolboxを起動しても動きません。もうひとつの外部プログラムであるblackbox_decodeがうまく動かないからです。
結局のところ、zipを展開したところにあるmain/PIDtoolboxを直接起動するのが良いようです。MATLABは必要なので先のインストーラーの実行はスキップ出来ません。

[ ファイルの選択と読み込み ]

Select File [A]とSelect File [B]と2つのblackbocログが選択出来ます。PIDやフィルターの設定前後のログを同時に表示して比較する事が出来ます。Windowsでは任意の場所のログファイルを開くことが出来るようですが、macOSではログファイルをプログラムのあるフォルダー(zip展開後のmain下)にコピーしておく必要があるようです。

ファイルを選択後”Load+Run”を押します。ログによってはSELECT LOG NUMBERというダイアログが出ます。たいていの場合はdurationの一番長いものを選べば良いと思います。

最初に現れるのはBlackbox Explorerと似たような画面です。横軸が時間で上のチェックボックスで選択したデータが表示されます。ここで重要なのは統計的解析に先立ってデータの範囲を選択しておくことです。st(s)とend(s)というフィールドを使用します。st(s)には予め2と入力されています。これで離陸後の安定飛行部分が指定されてます。end(s)はログの最後になっているため、着陸時の乱れたジャイロデータも含まれてしまいますので、適当に値を調整します。

除外された範囲はグラフ上でグレーアウトされるので視覚的に確認できます。

[ Spectral Analyzer ]
Spectral Analyzerボタンを押すと新しいウインドウが開きます。そこで表示したいデータを選択してRunボタンを押します。

この機能はノイズの分布とフィルターの効き具合を確認するのに適しています。そこで上の例ではGyro, Gypro prefilt, Dterm, Dterm prefiltを選択しています。prefiltはフィルターする前のデータです。残念ながらGyro prefiltは既定値のままでは取れませんので、ここでは意味のあるデータは表示されていません。

グラフの横軸はスロットルで縦軸は周波数です。Gyroの値の0から80Hzくらいは実際の機体の挙動から発生するものです、それより高い周波数はノイズあるいは異常振動と考えられます。スロットルを上げるとややノイズが多くなっていますが、Gyroを見る限り問題のない機体と言えます。実際に飛び方もモーターの熱も問題ありません。Dtermにノイズが多いようなので何かしら問題があるようですが、まだ良く分かっていません。

2-Dというチェックボックスを入れると周波数分布が表示されます。これを見るとDtermもまずまずフィルターされているので、問題ないのかも知れません。別の機体のデータではもっと綺麗なDtermグラフが得られるので、やはりちょっと気になります。

[ Step Resp Tool ]
データの比較例を紹介するためにまず2つのデータを読み込んでみます。

データBは既定値のPID, データAはD値を少し強くしたものです。

Step Resp Toolボタンを押すと下のようなウインドウが開くのでRunボタンを押します。

PID制御の状態を表したグラフです。操縦者はスティックを動かしてドローンをコントロールします。スティックの動きはFCで処理されてsetpointという値を作り出します。これはドローンが操縦者の意図にそって動いた時に出力されるべきGyroの値を示します。別の言い方をするとPIDコントローラーはGyroの値がsetpointを追従するようにモーターの回転を制御します。理想的にはBlackbox Explorerでsetpointとgyroデーターを表示した時にぴったりと重なることです。実際にはGyroが幾分遅れますし、オーバーシュートしたりなかなか安定しなかったりします。

Blackbox Explorerでは個々の動作について追従具合を見ますがStep Resp Toolではログ全体を見渡して総合的な追従具合を表現しています。立ち上がりの速さがレスポンスの良さを表現し、そのあと1に収束している様子を見ます。この例では立ち上がりでいくらかのオーパーシュートがあり、徐々に1に収束しています。

この例では、最初PIDを既定値で飛ばしたて得たデータが右側の状態です。試しにDを少し増やして飛ばしたのが左側です。左はサンプル数が少なくてギクシャクしたグラフですが、ヴァイブレーションとまでは言わないですが、どうも右より収束が良くない気がします。ということでDを増やしたのはあまり良いことではなかったように思えます。もともとの状態は悪くはない気がします。実験的にもうちょっとPIDを変化させて、このグラフが変わるかどうかを見てみたいと思っています。

[ PID Error Tool ]

これについては語られるほどの知識がありません。おそらくは左のグラフで幅が小さいほうが望ましいのでしょう。この場合、2つのログに大きな差はないものと思います。

[ PIDtoolboxを使うに至った事例 ]
ちゃんと飛ぶのだけれどモーターが加熱してしまう機体のログをBlackbox Explorer調べてみました。

モーターのトレースが小刻みに振動しています。他の機体ではもっとなめらかに変化しています。Gyroに注目するとPitchの様子が明らかにおかしいです。この時点ではPIDtoolboxを使う前でした。山の間隔を調べてみるとどうも80Hz付近のように見えたのでStatic Notch Filterで70-90Hzあたりを減衰させてみました。

これで飛ばしてみました。しかしながらログをみてもほとんど変化がありません。フィルターが思うように効いていないのか周波数を間違ったのか、そのあたりをはっきりさせるためにPIDtoolboxを使ってみることにしました。

Gyroのフィルター前のデータを取得するためにBlackboxにGYRO_SCALEDを指定した。

それで取得したログのSpectra Analyzerのグラフです。

左の2つが既定値のフィルター、右側が80Hzを中心としたstatic notchフィルターを入れたデータです。それぞれのGyroとGyro prefiltを表示しています。

– まずびっくりしたのは周波数的にはまんべんなく分布していることです。波形に特徴があるので特定周波数が特に強いはずですが、このグラフには表れていません。
– Gyro [B]を見ると80Hz付近が切り取られているのでstatic notchフィルターは確かに効いています。
– Gyro prefiltを見ると実は300Hzより上の周波数にデータが出ている、これらは効果的にフィルター群で取り除かれていたということを認識しました。300Hzから500Hzにかけてのスペクトラムが右肩上がりなのはスロットルポジションに追従して変化している、言い換えるとモーターの回転数に影響されたものだと推測出来ます。

それにしても、PitchのGyroの様子がおかしいという確認は出来ましたが原因も対策もよく分かりません。このSpectral Analyzerを見ると飛べているのが不思議に見えますが、Blackbox Explorerを見ると実際は機体の動きは取れていて、その波に小刻みにノイズが乗っている感じに見えます。FCの問題に思えますが、まだ結論は出ていません。

DJI Digital FPV System向けの社外アンテナはいくつか発売されています。割と高いこともあり、またストックアンテナで十分に強力なのでなかなか手が出ませんでした。実際、手持ちのパッチアンテナなども試してはみましたが、わざわざ付け替えるほどでは無い気がしていました。

Lumenier AXII HDコンボを使用するとストックアンテナよりもコンパクトになることが魅力的でした。アンテナを外すことなくバックパックに入れらるのはとても便利です。

性能がストックアンテナとあまり変わらなくてもコンパクトさ故に使ってみることにしました。せっかく入手したので簡単に比較テストを行いました。また、疑問点としてパッチアンテナは上と下のどちらに付けるべきかということへの自分なりの回答探しでもあります。

家の近所のスポットでアナログでもDJI FPVでも比較的近距離なのに200mWでは超えられない場所があります。そこでのテストです。

実験はそれぞれの構成で一度の飛行しか行っていませんので、あまり信頼性は高くはないかも知れません。結果はAXII HDのパッチアンテナを上、スタピを下に付けたら初めてその限界点を超えてまた戻ってくることが出来ました。本来なら同じテストをもう一度行うべきですが暑さと時間の制約で行えませんでした。また別の場所でテストしてみたいと思います。

Umma95が飛行中に燃えました。

火元はモーター3のESCです。反転しているので、オリジナルの場所で言うとESC2です。ここが一番燃えていました。回収時にはフレームが燃えて火が出ていて、なんとかバッテリーを外して消火しました。

実際の被害はFC、フレーム、モーターのケーブル、Caddx Vistaのカメラケーブルくらいです。剥きプロは煤けていはいますが録画可能でした。

ずっとモーター1と3だけが熱くて色々と調整を試みていましたが、飛びそのものは悪くはなかったです。ログをみるとジャイロの細かな振動、特にYawで顕著、があったのでモーターとESCに負荷がかかっていことは間違いありません。モーターが焼ききれるのならまだしも、ただそれだけで燃えてしまうことは考えにくいです。

そうなるとFCの設計的に組み合わせの問題が露見したか個別の故障です。使用していたのは、
– BetaFPV F4 AIO 12A V2
– BetaFPV 1106 5000KV
– 4Sバッテリー
です。Beta95Xの完成機のように16AのFC/ESCを使用する必要があったのかも知れません。このFCにはBlackBoxもあり気に入っているで追加で2枚発注したばかりです。今後は3Sで使う方が良いかも知れません。4S機は16A以上のFC/ESCを使用するのが無難なのかもしれません。

BetaFPVに対して上の組み合わせの是非の問い合わせと火が出るのは異常であるとのクレームを兼ねてチケットをオープンする予定です。

燃えた時の飛行の様子(DJI Goggle DVR)

燃えるひとつ前の快調な飛行の様子(剥きプロ-フィルターがちょっと汚れている)

少し前にYouTubeでISDT PD60のレビューを見たときは4Sまでしか充電出来ないことから今ひとつ興味がわきませんでした(6S機とか持っていないくせに)。5インチ機を持っての飛行会にはHOTA D6 Proを持っていきACに接続するし、一人で飛ばすときは手持ちのバッテリーを使い切ったら終了するしということもありPD60はパスしようと思っていました。

ところが剥きプロのおかげで仲間との飛行会を近所の公園で実施することが多くなりました。公園ではAC電源の確保が難しいし、小型機の充電にはモバイルバッテリーとPD60の組み合わせが良さそうなこともあり使ってみることにしました。

充電対象のバッテリーはLiPo/LiHv/LeFe/NiMHの2Sから4Sです。設定出来る充電電流は1A/2A/3A/6Aです。扱える電力は60Wまでなので4Sで6A出せることはないと思われます。

親電源はQC2.0/QC3.0とPD2.0/PD3.0です。屋外ではモバイルバッテリーを使用するわけですが、少なくとも18Wの出力を得られるものがあれば4Sを1Aで充電できるので小型機ならば十分に使えると思います。

10000mAh 50WのモバイルバッテリーとPD60を持って公園に出かけて2S 520mAhを繰り返し充電し、休み休みですがほぼ一日楽しむことが出来ました。20000mAhのモバイルバッテリーを買い足すつもりです。

FPVドローンを組み立てて最初にリポを接続する時はドキドキします。簡単にテスターでショートしていないかどうかは確認することは当然ですが、それでもまだ心配(VTXの誤配線などなど)はあるので海外のビデオなどではスモークストッパーと称してリポと機体の間に電流を制限するために電球を入れたりしています(と同時に電流が流れすぎると電球が明るく光る)。いずれは同じものを作ろうと思っていましたが、電球を使うのも今ひとつな気がしてのびのびになっていました。

電球を使う代わりに電子回路で過電流を防止する製品を使用するのが楽そうで良いのですが、過去に見てきた製品は、なんか今ひとつで手が出ませんでした。VIFLY ShortSaverはYouTubeでJoshua Bardwellが褒めているくらいで、今までの物とは少し様子が違います。機能としては1Aもしくは2A(スイッチで選択できる)を超える電流が流れると遮断するものです。説明によると回路がショートしている場合は3ms、一般的な過電流の場合は10msで遮断されます。ジャンパーの変更により、もう少し時間を長くすることも可能です。

実際にDJI FPV搭載5インチ機で試してみると1AだとFC/ESCの初期化が終わってモータービープが鳴り始めるところで遮断されました。2A設定だと遮断は発生しません。1A設定でも遮断されるまでに十分に時間があるので機体に問題が無いことは判別可能です。

おそらく、誤配線などからちゃんと機体を守ることが出来そうな気がします。多分、2Aの設定で使っていくと思います。

gopro-remote-stickCはまだ開発が始まったばかりということもあって機能も単純ですし接続できるGoProも一台に限られます。FPVドローンで使用する場合、録画開始、停止だけ出来れば良いのですでに十分に役に立つものになっています。

ところが複数のGoProを使用しているので接続できるのが一台だけでは困ります。M5StickCは安価ですし、GoProの数だけM5StickCを準備しようかと考えているうちにブログラムに手を入れずに解決する方法を思いつきました。思いついただけで実験する前にアイデアをTwitterのスレッドでつぶやいたところpapalagi.orgさん(M5StickCを使っている皆さんウオッチした方が良いですよ)が検証してブログに書いてくださいました。

アイデアはとても簡単です。gopro-remote-stickCは接続するGoProのSSIDとパスワードをソースコードに書き込んで使います。そのプログラムのファイル名を接続するGoPro別に変更して複数持つだけです。具体的な方法については、先のpapalagi.orgさんのブログに書かれていますが、私の別のやり方を簡単に紹介しておきます。

UIFlow DesktopでM5StickCをUSB接続していることを前提としての説明です。M5StickC側でUSBインターフェースを選択する方法はpapalagi.orgさんのブログをご覧ください。

GoProのSSIDとパスワードは上の画面のwifiNameとwifiPassに設定します。それに加えて左上のProjectの名前を接続相手を分かるようにします。Downloadすると、これがM5StickC上のプログラムファイル名になります。もうひとつtitleも同様に接続相手のGoProを識別出来るものにしておきます。プロジェクト名と同じにするのが良いでしょう。これにより実行中のプログラムのタイトルをみれば、どのGoProを対象としたプログラムかがわかります。

この手順でプログラムが増えていきますが、不必要となったプログラムを消す時はpapalagi.orgさんのブログに書かれているVSCodeを利用すると良いようです。

GoProの録画開始停止を行うもうひとつの方法です。

M5StickCという小さなコンピューターをGoProのリモコンにしている人がいるとの情報を見かけたので試してみました。最初はC言語で書かれたM5GoRemoteというのを試しましたがうまく接続できませんでした。開発者はHero4でテストしていて新しいのでも動くんじゃない?というスタンスですので致し方なし。その後papalagi.orgさんが実験的にコードに手を入れて接続は可能になったようですが、今ひとつみたいな感じです。

もうひとつUIFlowというプログラミング環境を使用したgopro-remote-stickCというものをpapalagi.orgさんがブログで紹介されていますので、それを試してみました。必要最低限の機能しかありませんが、問題なく動きます。WiFi接続に必要な時間も短いですし、本物のGoPro Remoteと値段は比べ物にならないくらい安いですし、これはかなり有効なソリューションと言えます。

最初、導入に苦労しましたが、必要なことは全てpapalagi.orgさんのブログに書かれていますので詳細は、そちらに譲ります。ここでは、予め知っておいた方が良いことや私が迷ったことについて書いておきます。

まず最初に把握しておくべきなのはそれぞれのボタンの役割です。UIFlowがロードされた状態での各ボタンによる操作はUSBモードへの切替方法という記事を見ると良くわかります。最新のUIFlowですと画面がかなり変わっていますが、基本操作は同じです。

開発環境にはUIFlow Desktop IDEとブラウザー版のふたつのIDEがあります。Desktop版はUSB経由でM5StackCに接続します。ブラウザー版はWiFiネットワーク経由で接続します。ブラウザー版の場合、M5StickCも自宅などのWiFiに接続しておく必要があります。SSIDとパスワードはM5BurnerなどでUIFlowを書き込む時に同時に設定します。WiFi接続されるとM5StickCにAPI Keyが表示されますので、それに基づいてブラウザー版IDEはM5StickCと接続されます。Desktop版でUSB接続する場合はM5StickCのSetupでUSBを選択する必要があります。またGoProのアプリを起動したあとはWiFi接続がGoProを探しに行ってしまうのでブラウザー版IDEに接続する場合はM5StickCのSetupから正しいSSIDを選択する必要があります。

ブラウザー版の方が新しいデバイスやソフトウェアに対応しているので、こちらを使用したいのですが、ユーザープログラムの読み込みがうまく行きません。papalagi.orgさんのブログにあるようにDesktop版からpythonコードのコピペが必要です。おそらく何かしら解決方法があるのでしょうけど、今の所見当たりません。Desktop版でUSB接続すれば問題はありませんが、これも毎回M5StickCのSetupでUSBを選択する必要があります。

現在のところ、GoProの状況を見ることはできませんし、一台のGoProにしか接続できないアプリケーションですが十分に実用になると思います。複数のGoProに接続する方法は、次の記事で紹介する予定です。