普通的生活

「BlackBox Logを利用した動画スタビライズ」の続きです。前回は、一眼レフで撮影した動画をBlackboxログでスタビライズする試みでmacOSを使用していました。今回はいよいよドローンで撮影した動画のスタビライズに挑戦です。使用する環境はWindows10で、ビルド済みの実行ファイルを利用するのでセットアップがかなり簡単になっています。細かなオプションの解説とかではなく、わたしの実例にそってそれなりに実用的な出力を得られるまでの一連の手順を紹介します。

前回も書いていますがBlacboxログを利用した動画スタビライズ関連のおさらいから始めます。現在、２つの方法があります。一つはBlackboxToGPMFというプログラムを使用してBlackboxログから抽出したジャイロデータを動画ファイルに組み込んでGoProと互換性を持たせてしまうものです。それをReelSteadyGoという定評のあるプログラムでスタビライズするものです。詳しい手順については井上さんのブログをご覧ください。

もう一つがこれから紹介するGyroflowというプログラムで、これひとつでBlackboxログの解析とスタビライズを一度に行います。

Blackboxログの取得から書いていきますので、かなり長いエントリーになることを予めお断りしておきます。

事例として紹介するのはDJI Digital FPV SystemのゴーグルのDVRのスタピライズです。解像度は960×720,60FPSの動画です。Blackboxログは既定値のままで取得したものを使用します。

[ Blackboxログ関連の設定 ]
まずはBlackboxログが取得出来るFCを使わないことには始まりません。Whoopタイプだと取得できないものの方が多いです。まずはBetaflight Configuratorに接続してBlackboxタブを見てください。下のような画面なら大丈夫です。もし、もっと簡単な画面でBlackbox logging deviceがNo LoggingとSerial Portだけの場合は、そのままではログの取得が出来ないのであきらめます。ログ取得には(シリアルポートに外付けのログデバイスを付けるか)FCを交換する必要があります。

ログの取得にSDカードを使用するものだと、そこそこ多くのログが取れます。Onboard Flashの場合はせいぜい3フライト分しか取得できないので、こまめにログの保管とErase flashでの消去が必要です。ログのエリアが一杯なると書き込みを停止します。

必要のないログ項目を削除してなるべく長くジャイロデータを取得する手法などもありますが、とりあえずは既定値のままで大丈夫です。

Blackboxログは既定値でアームからディスアームまで取得するようになっています。Modes画面を見ると分かりますが送信機のスイッチでコントロールすることも可能ですが既定値のままで良いと思います。

飛行前にErase flashで空きを作っておくことだけを忘れ無いようにして、とりあえず飛ばしてみましょう。

[ Blackboxログのコピー ]
上の画面にあるActivate Mass Storage Device Modeボタンを押すとBlackboxログの格納されたストレッジがUSB接続されます。macOSでもWindowsでも、あるいはAndroid端末でも普通のUSBドライブとして見えるようになります。

btfl_001.bbl
btfl_002.bbl
btfl_003.bbl
btfl_all.bbl

みたいな感じでファイルが見えるので、あとから動画と関連付けられるように工夫してどこかにコピーしておきます。保管したらUSBドライブを切断、USBケーブルの抜き差しでBetaflight Configuratorに戻りErase flashしておきます。

[ Blackbox Viewer ]
Bteaflight Blackbox Explorerとも呼ばれます。ログの解析に使うツールですが、ここでは動画とログの時間差の計測とログのcsv形式での出力に使います。 導入はとくに難しくは無く、リンク先の実行ファイルをダウンロードして実行するだけ稼働します。

どのログファイルに欲しいデータが入っているかは開いてみて動画と合わせてみないことには分かりません。またひとつファイルには複数のフライトが入っている可能性もあります。

この例では4つのパートが含まれています。時間の長さを目安に選択します。この場合は4番目が目的のログでした。右上のOpen log file/videoをクリックして動画ファイルを重ねて読み込みます。

再生してみて動画とログが一致しているかどうかと、どれくらいのズレがあるかを調べます。アームしたところとか、最初にスロットルを入れて離陸したところ、あるいは急激なターンなどが目印になります。Gyroflowは5秒までのズレを自動的に補正しますので、あまり細かく追求する必要はありません。わたしの例ですとDJIゴーグルDVRもログと同様にアーム時に自動スタートしますのでその差は確実に5秒以内なのでログと動画が合っているかどうかの確認だけでも大丈夫です。

ズレの計測方法はまず動画で特徴的な動きを探します。右下にあるタイムスタンプを記録します。次にジャイロもしくはスティックの動きを見て対応する所のタイムスタンプを記録し、その差を求めます。オフセットは動画-ログになります。+/-は実際に確認してみれば分かるので深く考えなくても良いです。

計算したズレをSyncに入れて再生してだいたい一致していることを確認します。

次にExport CSVボタンを押してログをCSV形式で保管しておきます。

[ Gyroflow ]
上のリンク先のDownloadページから実行ファイルをもらってきて適当な場所にコピーして実行します。Windowsの場合はgyroflow-presets-*.zipもダウンロードして適当な場所に展開しておきます。macOS版もWindows版もプログラムが動き出すのに少々時間がかかりますので辛抱強く待ってください。もし自力でPythonを動かすことが出来ると立ち上げの時間は節約できます。ただし立ち上がったあとの処理時間は同じです。

Video Stabilizerを起動します。

まずInput画面でビデオファイル、カメラプリセット、CSV形式のログファイルを選択します。カメラプリセットはgyroflow-presersの中に格納されているものから適当に選びます。私の例ではCaddx_Vista_4by3というそのものズバリのプリセットがありました。自分でプリセットを作る方法も作者自身がYouTubeで解説されていますが、わたしは今の所必要としていないので、まだ試したことが無いです。
-> 日本語でのカメラキャリブレーションの方法を井上さんが書かれました。そのうち試してみたい。

Blackboxログは拡張子bblの物も読み込めるようになってはいますが、うまく動かないことがあるので先にCSVに変換したものを使用します。
加えてCamera to gyro angleを設定します。わたしの場合Caddx Vistaのカメラアングルがおおよそ30度にしていますので30と入力します。

次にSync/StabilizationにてInitial rough gyro offset/Auto sync timestamp 1/Auto sync timestamp 2を入力します。自動的に+/-5秒の間で同期ポイントを調べてくれるのでInitial rough offsetは本当にラフな数値で大丈夫です(画面では-2と入力していますが、5秒以内なので実際には0のままでも問題ないです)。動画とジャイロは最初と最後で随分とズレます。そのためgyroflowは２つのポイントで画像データとgyroデータを解析してオフセットを計算してくれます。そのために動画のどのあたりで解析すべきかを指示するためにAuto sync timestampを指定します。動画を再生してみてクラッシュ以外で大きな動きをしている場所を動画の最初の方と終わりの方で調べておき、その時間を秒数でAuto sync timestmap 1とAuto sync timestamp 2に指定します。

Smoothnessは好みで変更しますが、とりあえずは20%で良いでしょう。Apply settings and compute syncを押すと同期のための処理が始まります。

後ろにあるコマンドラインのメッセージで処理の進行状況が分かります。また何かしら問題が発生したときにはヒントとなるエラーメッセージも確認できます。しばらくすると上のようなグラフが出るので、そのウインドウを閉じると続きの処理が始まります。

２つ目のグラフです。これは閉じるとすぐに次のグラフが表示されます。

このグラフを閉じるとまたしばらく処理が続きます。

しばらくすると下の方のDelay for sync 1とDelay for sync 2に数値が入ります。これでsync作業が終わりました。次はExportです。

Export画面で最低限入力が必要なのはExport bitrateです。これが足りないと元の動画より画質が劣ってしまいます。ビットレートはコーデックにより変わりますが、とりあえずは元の動画と同じくらいにしておけば良いでしょう。この例では40Mbsにしています。
もうひとつ必ず必要かどうかは分かりませんが、FFmpeg color space selectionにyuvj420pを指定しました。わたしの場合、これを入れておかないとyuv444pというカラープロファイルの動画になってしまいました。これだとDaVinvi Resolveなどで読み込めないので使えない動画ということになってしまいます。最初からyuv420pもしくはyuvj420pを指定すれば良いと思います。

Export (hopefully) stabilized videoを押して出力ファイル名を指定すると動画の書き出しが始まります。進捗が100%に達してpreview画面が消えれば終了です。

出力された動画はフレーム付きでフレームが揺れ動くものになります。これを動画編集で中央部分だけ切り取れば完成です。

もし出力されたファイルが再生できない場合は何かしら問題があります。進捗が出力されているコマンドウインドウに何かエラーが出ているかもしれないので調べて下さい。わたしが経験した事例をひとつ紹介しておきます。

[ トラブル事例 ]
Exportは出来るが普通では再生出来ない動画になった。VLCプレーヤーなら再生できる。あるいは再生は出来るが画質が悪い。
別の観点で調べてみると元の動画にかかわらず25FPS固定、ビットレートも指定通りになっていない。
以下のエラーメッセージがExport時に出力されていた。

11:47:26 :: Helper :: DEBUG :: No Custom FFmpeg path provided. Auto-Installing FFmpeg static binaries now. Please wait…
11:47:28 :: Helper :: ERROR :: HTTPSConnectionPool(host=’ffmpeg.zeranoe.com’, port=443): Max retries exceeded with url: /builds/win64/static/ffmpeg-latest-win64-static.zip (Caused by ProxyError(‘Cannot connect to proxy.’, OSError(0, ‘Error’)))

これは最初にExportする時に内部で使用するためのffmpegというプログラムを自動的に取りに行っているのですが、我が家のネットワーク事情により失敗していました。これが無いと高度な動画ファイルの作成が出来ません。そのため限られた範囲でExportされていました。ネットワーク環境を正しくして実行するとffmpegが取得され正しい動画がExportされました。

以下サンプル動画です。

FPVドローンに搭載するFCに記録されるログの中からジャイロデータを抽出し、それを利用して動画の安定化を図る方法があります。色々と解説が出ていますがWindows 10によるものがほとんどな気がします。ここではmacOS Big Surでの事例を紹介します。

本来の目的はドローンの飛行中の動画に適用するものですが、一眼レフの上にFCを単独で載せて手持ち撮影の動画の安定化を試してみようという試みでもあります。

大きな流れはBlackbox Log Viewerでログをcsv形式で保管、それをgyroflowで処理し動画をスタビライズするというものです。これとは別にBlackboxToGPMFというソフトウェアでGoProコンパチの動画ファイルを作り、既存のReelSteadyGoで処理する方法もあります。

2021/02/24追記)
以下Pythonのセットアップから書いていますが、直接実行可能なパッケージが提供されるようになりました。
Gyroflowの公式ページのDownloadにある実行可能ファイルをダウンロードします。macOSの場合は拡張子dmgになっています。これを実行するとgyroflowという実行ファイルとcamera_presetsフォルダーが見えます。これを適当な場所にコピーしてgyroflowをダブルクリックもしくはターミナルから実行するだけです。ただし起動にかなり時間がかかります。わたしのMacBook proでは一分近く待つとgyroflowのウインドウが開きます。

[ Pythonのセットアップ ]
わたしのmacOS Big SurにはPython2.7とPython3.7が最初から入っていました。必要なのはPython3系なので3.7で試してみましたがうまく行きませんでした。最新の3.9なら大丈夫そうということで、常套手段であるpyenvを導入して色々とやってみましたが問題続出でひとつひとつ片付けていってもダメでした。思い直してbrewもpyenvも忘れることにしてパッケージで導入しました。以下手順です。

– https://www.python.org/のDownloadページから現時点での最新版3.9.1のmacOS版インストーラーをダウンロードして導入。
– ターミナルを開き直すとpython3.9が使用可能になっています(python3で起動できます)。
– “pip3.9 install numpy” でNumPyモジュールを導入します。
同様に以下のモジュールを順次導入します。
– opencv-python, PySide2, scipy, orangebox, construct, python-dateutil, hachoir, matplotlib, VidGear

[ Gyroflowのインストール ]
GuroflowのダウンロードページにmacOSの実行ファイルがありますが、今ひとつ動かし方が分かりません。GithubからソースコードをダウンロードしてPython3で起動することにします。
https://github.com/ElvinC/gyroflowのCodeボタンを押してzipで全てのコードをダウンロードし任意の場所に解凍します。
ターミナルを開き解凍したフォルダーにcdしてpython3 gyroflow.pyで起動できます。

[ FCの準備 ]
一眼レフの上に適当なマウントを作ってFPVドローン用のFlight Controllerを単独で載せました。なるべく多くのログが取得出来るようにMicroSDカードが使えるFC(MATEX F722-STD)にしました。給電はモバイルバッテリーからUSBで行います。一般的には飛行開始時に行うARM動作でログの取得を開始するようになっていますが、FC単体ではログを開始するきっかけがありません。そこで下のCLIコマンドにて電源投入と同時にログを開始するようにしました。
blackbox_mode = ALWAYS
問題はログを停止する手段がないことです。仕方がないので録画終了からしばらく時間をおいてUSBケーブルを抜いて電源を切るようにします。

[ 録画 ]
後からジャイロデータと動画の同期を行う必要があるので、動画の最初と最後にわかりやすい動きを記録しておきます。カメラを大きく横と縦に振っておくと良いです。

[ 実際の手順 ]
動画にまとめましたので、それを見ていただくのがわかりやすいと思います。

いくつか動画の補足を書いておきます。
– YouTubeに作者らしき人からコメントをいただきました。Initial rough gyro offsetを計算してセットしていますがgyroflowは+/-5秒で同期ポイントを探すので5秒以下のズレならば何も入力しなくても良いそうです。

– もとの動画は59.94FPSでした。これをgyroflowで処理する方法もあるのかも知れませんが、よく分からないので予めDaVinci Resolveで30FPSに変換してから使用することにしました。
– Blacbox Log Explorerでオフセットを調べていますが、これはあまり正確な数値を追求しなくても大丈夫です。gyroflowが自動的に同期タイミングの調整を行ってくれます。
– gyroflowはBlackboxログの生ログを読み込めますが、今の所うまく動かない気がします。blackbox log explorerでCSV形式で書き出したものはうまく処理出来ます。
– Gyroflowのcamera presetsが何者かは良く知りませんが、色々とためして一眼レフで取得した動画で歪の無い出力が得られるものを探し当てたものがlgg6_normal_16by9というだけです。論理的な理由があるわけでは無いです。
– Syncを計算した後にDelay for sync 1とDelay for sync2が表示されます。これを見ると動画の最初と最後では随分とオフセットが変わるのがよく分かります。
– Exportした動画は何か不具合があるようでmacOSのプレビューも出来ないですしDaVinci Resolveに読み込むことも出来ません。こんな時の定番がVLCです。VLCは他で読めない動画ファイルの再生が出来ます。VLCに読み込んで改めて書き出すことによりDaVinci Resolveに取り込むことが出来るようになりました。これはいずれgyroflowで修正されるものと思います。
=> 環境依存のようですが、Color profileがyuv444の動画になっているのが原因でした。gyroflowの画面に書かれているとおりにExportする時にyuv420pという指定を”FFmpeg color spae selection”という所に書き込めばOKです。
– Exportした動画はフレームが踊っている変わった動画です。中央を上手に切り取ることによりスタビライズした動画となります。

EmuFlight+Mockingbird設定で飛ばしている1S 65mmブラシレス機をEmuFlight 0.3.3に更新してDAS機能を設定してみました。DASとはYawとRollをミックスさせる機能です。

以下のCLIコマンドでRollスティックにYawをミックスさせました。

set das_yaw_with_roll_input = 90

この設定はrateprofileに入りますので、スイッチでオフオン出来るようにしています。反対にYawスティクにRollをミックスさせることも出来ます。

私はモード2なので、左のスティックはスロットルだけに集中し右スティックだけでコーディネートターンを行おうという狙いです。まだまだ練習中ですが、慣れてくると動きが省略されるので楽な気がします。速くなったかどうかは不明です。

以下、わかりにくいですがスティックカムを含めた動画です。

以前、自作テスターを使用したFCの電流値校正について書きました。手順はまったく同じですが、市販の電源装置を利用した校正のやり方を改めて書いておきます。

使用したのはWanptek NPS3010Wという電源ですが、そこそこ正確な電流計が付いていればどんな物でも大丈夫です。

機体をBetaflight Configuratorと電源装置に接続します。大雑把に飛行中の電圧になるよう電源を設定します。

Betaflight ConfiguratorのMotorタブで(ペラを外してから)モーターを回します。電源装置の電流計を見ながら安定した電流値になるように回転を調整します。どれくらいの電流値が適当なのかは不明ですが、わたしは1Aから2Aの間にしています。

Betaflight ConfiguratorのPowerタブを確認します。

電圧は概ね正しいと思います。わずかな差はもともと電圧を確認している場所の違いもあるので気にしなくて大丈夫です。電流値も正しければ何もしなくて良いです。多くの場合は正しくは表示されていないと思います。

Calibrationボタンを押します。

電圧のところは0のままで、電流のところに電流計の読みを入力しCalibrateを押します。

設定値が表示されるのでApply Calibrationを押すと自動的にScaleがセットされる。

Power画面のSaveを押すと実際にScaleが反映される。電流値がそれなりの値になれば完成です。

以前から実験用の電源を欲しいと思っていましたが、リポバッテリーを利用した実験用電源セットで間に合っていました。いまでもそれで問題は無いのですが、良さげな電源がTBS COUCHで紹介されていたので購入してみました。中国での価格は5インチドローンのリポ、2本分くらいなので実験のためにリポを充電したりして消耗させるより良いかもです(物欲理論でやや難あり)。

リポ電池を電源とした自家製テストキット

TBS COUCH中でTrappyは電流制限機能があるのでスモークストッパーの代わりになると言っていますが、そこはやや疑問ありです。これについては後ほど詳しく書きます。

購入した電源はWanptek NPS3010Wというものです。TBSで販売しているのはDPS305Uという型番なので少しスペックが違います。TBSで販売しているのは5A仕様ですが私のは10A、またTBSの物は18WのUSB充電機能が付いていますが私のはUSB出力はありません。

電源にはミノムシの付いたケーブルが付属していますが、ドローン用にXT60の付いたケーブルを作りました。XT60からの各種変換ケーブルは以前のテストキット用に作って有るので、これで何でも接続できます。

電圧は0-30Vの間で自由に設定できます。 4桁のLED(小数点以下2桁)で電圧を確認出来ます。そこそこの精度があるのでテスター等で確認する必要はありません。

簡易スコープで見る限り変なリップルもありません(高い周波数のノイズは分かりません)。

電圧が簡単に設定出来るので3.3Vの受信機の単体テストにも使えますし1Sから6Sまでリポの代わりにもなります。

この電源には定電流モードがあります。電流値を設定しておくと、それ以上の電流は流れません。設定方法がややトリッキーです。表示板の電流計はリアルな電流しか表示出来ません。そのため無負荷だと0.000Aのままです。そこで電流調整ツマミを回しても何も出来ません。電流値を設定するためには出力をショートさせないといけません(目標電流より十分に沢山の電流が流れる負荷でも良いかも)。流石に最初に試すときはビビリながらやりました。

これがあるのでどこかショートしていても安全かも知れません。ただし、これは過電流の時に電源をシャットダウンするものではありません。一定の電流を供給し続けるように設計された電源です。つまり、電流が流れすぎたら電圧を下げていって設定された電流を流し続けるように動作します。もし何かしらの不具合で電流が流れすぎた場合も、設定値までの電流は流れ続けます。燃え上がることは無いかもしれませんが、じわじわと壊すことはあるかも知れないので、この機能ををSmoke stopperとして使うことはお勧め出来ません。

12V、電流制限値1Aに設定して自作のテスターを通した先でショートさせた様子。テスター上ではショートしているので電圧は0ながら電流は1A流れているのが分かる。また電源に付いている赤いLEDの点灯が電流制限モードに入っていることを示している。

ということで私としてはVIFLYを併用することにします。

10Aも流せるのでモーターの回転方向の確認、RPMテレメトリーのテストなども余裕でこなせます。

電流表示も信用できるのでFCの電流計の校正も手軽に出来ます。なんかこれが一番のメリットかもです。

流石に中国で購入するより少し高いけどアマゾンにもありました。

95X V3フレームのテスト飛行を行いました。そこで気がついたことをいくつか書いておきます。

[ HDカメラマウントの脱落防止 ]

V2フレームの経験から予測していたのですが、HDカメラマウントベースは転倒などで簡単に外れます。タイラップをマウントラバーの中に通しておけば外れることはなくなります。

[ FCを再びiFlightに戻す ]
これはV3フレームには直接関係はありません。V3フレームでToothpic FCが使えるようになったので、JHMCU GHF411AIO 20Aを付けてみましたがテスト飛行が散々な結果でした。いつもフィルターを弱めてpropwashに対処できるようにしているのですが、それがまったく不可能でした。むしろフィルターを強めなければまともに飛ばない状態でした。残念ながらBlackboxが無いので何が起こっているのかは分かりません。ということで、もともと使用していたiFlight SucceX-D 20A Whoop F4 AIOに戻しました。これで中身は完全に95X V2で飛ばしていた時と同じになりました。

[ Propwashが酷い ]

95XV3でのpropwash動画 pic.twitter.com/QBai5Sz4gp

— コザック KozakFPV (@nkozawa) January 15, 2021

V3フレームで重量が10g強重くなったのと少しだけダクト形状が変わりましたが基本的な設定はV2と同じで大丈夫と思います。ところが、少し飛ばしただけで何度も酷いpropwashに入りました。考えてみると大きな違いがありました。

ダクト周りに緩衝材のEVAフォームを貼っていたのでした。これを外したら直りました。室内飛行には必要ですが、わたしの95X V3は屋外でまったりフリースタイルを行うので緩衝材無しで行くことにします。

[ フレームは丈夫かも ]
２回目のテスト飛行では今ひとつ調子が出ず(パイロットの問題)にクラッシュばかりしていました。それでもフレームは問題無しです。たぶん、以前のものより丈夫かも知れません。まだまだ何とも言えませんけど。

[ 調子よく飛んだときの動画 ]

この投稿をInstagramで見る

Nobumichi Kozawa(@kozakfpv)がシェアした投稿

BetaFPV 95X V3 BNFに装着されている5枚羽のプロペラがちょっと気になったので試してみました。

以前からTinyなどでは4枚羽と3枚羽でカーブでの粘りが違うなどと良く言われていましたが、わたしはまったくそのあたり無頓着でただただ評判の良いペラを使っていました。唯一自分で飛ばし比べて違いか分かったのは3インチ機で主にはペラ自体の重量から来るパンチの強さでした。そんな違いの分からない男が5枚羽ペラについてレビューしてみようと思います。

D63とはおそらく直径が63mmということで2.5インチ相当です。形状からしてダクトありきのペラと思います。95X V3のフレームとの組み合わせで何かしら最高のパフォーマンスが得られるのではないかと期待して試すことにしました。

ただし私の95X V3のセットアップはBetaFPVの機体とは違いRCINPOWER 1207 5000KVというやや大きなモーターを使用していますのでBetaFPV 95X V3とは結果が異なる可能性については予めお断りしておきます。

比較する対象はお気に入りのHQProp DP 2.5X2.5X3です。

重量はHQPropと比べるとやや重いです。5枚ペラなので当然でしょう。

まずは飛行音を比較してみました。Gemfan D63の方が音が小さくなるかもという期待を抱いていましたが残念ながらほぼ変わりません。むしろ高い音の成分が多くて耳障りな気もします。

屋外飛行でのフィーリングは、まったりした感じです。わたしのまったりフリースタイルでもちょっとレスポンスが物足りない気がします。スロットルを入れたときのパンチも少なめです。

飛行時間については正確に測定はしていませんが、だいぶ短くなるような気がしました。

わたしの結論的にはHQPropを使い続けることになりました。

BetaFPV 95X V3フレームがなかなか格好良いのでV2で組んでいたInsta360 GO搭載機を移植することにしました。

フレームキットの内容(赤いダンパーとネジの小袋は撮り忘れ)です。5枚羽のペラは同時に購入したもので付属ではありません。

プッシャー専用として設計されているので良く出来ています。見た目も丈夫そうです。

ダクト部分に控え目ですが脚が付いているのでumma95のように裏蓋に脚を作る必要がありません。この方が丈夫だと思います。

以前の95Xフレームには少し大きくて使用できなかったToothpic FC, JHMCU GHF411AIO 20Aも載せられます。横に出ているUSBコネクターにアクセスするための穴もあります。ということで、今までのiFlight Succex-D F4 20AからGHF411AIOに載せ替えました。(Blackboxが取れないのがちょっと残念)

Caddx VistaはVistaのケースを取り付けているネジを外してマウントするのが正しいようです。20mmx20mmの穴もありますが、それを使うと下の蓋を取り付けるのに窮屈になります。Vistaケースの穴をしようしてマウントするためにはM1.6 6mmのネジを別途入手する必要があります。

フレーム後部に受信機のアンテナを収納する切れ込みがあります。せっかくなので今までCrossfire(海外在住です、念の為)のImmortal Tアンテナを使用していましたが普通のワイヤーアンテナに変更しました。

カーボンフレームが内側にあって、おそらく最初の95Xと同じものです。初代と違うのはモーターが直にカーボンに載ることです。問題は中央の穴が小さめでRCINPOWER 1207だと軸の大きさがギリギリなことです。マウントしてみると、順調に回るモーターもあればガッツリひかかってしまうモーターもあります。穴を広げることも考えましたが、ワッシャーを一枚入れることにしました。

前回のDJI Mini2の充電実験で気づきました。海外版のスペックを見るとバッテリーの最大充電電力は29Wなのに充電に使うACアダプターは18Wしか供給出来ません。日本版では共に18Wなので改善の余地はありませんが、海外版では十分なパワーを供給すれば充電時間を短く出来る可能性があるということです。

さっそくテストです。バッテリーは例によってLow Batteryが出たところから充電開始です。使用したのはDJIのACアダプターと前回一番大きなパワーを供給出来た小米のモバイルバッテリーです。

結果は予想通りです。30Wを供給出来る小米のモバイルバッテリーは1本のDJI Mini2バッテリーを52分ほどで充電完了しました。DJIのアダプターだと72分ほどです。3本充電する場合だと実に1時間ほど節約出来ることになります。

急速充電の仕組みとして充電当初は沢山のパワーを供給し、終了近くでは徐々に電力を小さくします。タイムラプスで撮影したので、その様子が分かるのも興味のある人には面白いと思います。

おそらくは積極的なリークにより、DJIのFPVドローンの写真が少し前から出回っていましたが、ついにFCC IDのサイトで資料が公開されました。製品としての詳細が分かるわけではありませんが興味深いことが沢山あるので、すこしまとめておきます。

FCCID.IOのサイトによると認証申請されたのは3製品です。

DJI FPV Drone
FCC ID: SS3-FD1W4K2006
技適番号: 211-200733

DJI FPV Googles V2
FCC ID: SS3-FGDB282006
技適番号: 211-200732

DJI FPV Remote Controller 2
FCC ID: SS3-FC7BGC2006
技適番号: 211-200734

それぞれ技適番号がありますが、添付されていたラベルに書かれていたもので、現在(2020/12/09)のところ総務省のサイトでは見つけることは出来ません。

興味深いのは技適番号があることに加えて2.4GHzと5.8GHzのデュアルバンドであることです。まるでDJI Mavicのようです。技適の詳細は分かりませんが、電波法的にはMavicなどと同様に無線の免許無しに扱える可能性が見えてきました。

すでにリーク写真もありますが、一部のドキュメントに製品の形状が垣間見えます。
ゴーグルはリンク先の31ページからです。現行のゴーグルにとても似ています。
送信機はリンク先の29ページです。なんだかTBS Tango2のような感じです。小型で好感がもてます。

さて最大の懸念事項はAirUnitが無いことです。現在のDJI Digital FPV SystemではAirUnitという装置を任意のドローンに搭載してVTX(+受信機)として使用するのですが、それがありません。代わりにドローン自体が登録されています。これは現在のFPVドローンとは別物と言えるでしょう。

おそらくDJIの狙いはFPVでの撮影需要を狙った機体まで含めた完成されたシステムということなのでしょう。それも十分に興味深いです。

ゴーグルの名称はDJI FPV Googles V2となっているので現行DJI Digital FPV Systemへの後方互換性はあるのかもしれません。願わくば対応する2.4GHzでも使えるAirUnitを出して欲しいです。