Dropbox

Rekon4 LR初飛行

久しぶりの完成機ですし、なるべく箱出しの状態で飛ばしてきました。

飛行前に行ったこと、
– 受信機の設置、ExpressLRSとCrossfireで悩みましたが、ロングレンジフライトに対して実績を重んじてCrossfire Nano RXを使うことにしました。
– Mode/Adjustmentは当然、自分流に設定。
– Ratesも自分流です。PID/Filterはファクトリー設定のままにしました。
– BlackboxはGYRO_SCALEDを設定、ログ周期は2KHzにしました。
– GPS設定はSanity CheckをONからFailsafe onlyに変更しました。

手持ちの650mAh, 750mAhのリポで快適に飛びます。わたしが普段飛ばしているような軽いフリースタイルはまったく問題なくこなせます。

[ 飛行時間 ]
やや古いリポということもあるかも知れませんが、ログ取りのためにやや激しく飛ばすと650mAhで4分前後しか飛びませんでした。バッテリー6本飛ばして一番長い時で6分弱だった気がします。

[ Blackboxログ ]
1フライト分しか取れませんでした。しかもデータがやや怪しい。Blackbox Explorerで見るとところどころGyroデータが振り切っていますしPIDtoolboxを走らせるとエラーしてしまいます。Gyroノイズの雰囲気はそれなりに見えます。RPMフィルターは使われていませんが、それなりに良い感じにフィルターは効いているようです。

[ 機体のゆれ ]


ロールとかフリップすると直後にゆらゆらします。最初はバウンスバックかと思いましたが、どうも長いアンテナの影響ではないかと思えてきました。DVRを見るとロールの後でも縦揺れしているような気がします。ロングレンジ機たる長いアンテナですので、致し方ない気がします。硬性を高めるか短くすることも検討はしてみます。

[ GPS ]
最初はGPS位置が取れないまま飛ばしていました。3回目の飛行中に位置がロック出来たので改めてGPS Rescueのテストを実施。問題なく機能しました。せっかくのGPSデータですのでOpenTXでログを取っていました。それをGoogle Earthに取り込んだのが下の動画です。


GPSデータの活用については、また改めて書いてみたいと思います。

次はRPMフィルターを設定し、Betaflight 4.2.0から最新に更新してログの取り直しを行います。もし間に合えばLi-ionバッテリーのテストも行いたい。

HGLRC Rekon4 Micro Long Range

多分、3年振りくらいにFPVドローンの完成機(PNP)を購入しました。HGLRC Rekon 4 LR Caddx Vista/Polar搭載版です。まだ最低限の設定を済ませただけで飛ばしてはいませんが開封レビューをしておこうと思います。

Rekonシリーズはマイクロロングレンジという新しいジャンルを生み出したDave_Cの設計による機体です。それをHGLRCが販売しています。この組み合わせは申し分ありません。手に取った瞬間に一分の隙もない完成度の高さを感じられます。はんだ付けのクオリティーも高い感じがします。

付属品はプロペラが2種類とGoPro Liteマウント、REKON FPVステッカー、説明書等です。

本体からは2つのコネクターが出ています。ひとつはGoPro Liteの電源でVBATから電圧が供給されています。黄色い線は付いていません。もうひとつはPNP機なので受信機用ですがコネクターがそのまま挿せる受信機は存在しない気がします。5V、GND、R1(SBUS用)の3本の線が接続されています。

プロペラは2枚羽のGEMFAN 4024(2セット)と2枚羽で折りたたみ式のGEMFAN F2019(1セット)です。初めての折りたたみペラを入手です。何となく折りたたみは重いのではないかと思っていましたが、実際には4024より軽かったです。どちらも試してみますがF2019がメインになりそうな予感です。 

Betaflight 4.2.0が入っていました。ざっと見たところGPSレスキューも設定済みのようです。RPMフィルターは設定されていません、これはESCがBLHeli_Sなので仕方なし。フィルターはスライダーでジャイロフィルターが弱めにしてありました。PIDはスライダーを使わずに全てやや強めな感じです。良い設定が出ていることを期待します。

デジタル版ですのでCaddx Vista搭載です。カメラは最新のPolarが付いていますのできっとDVRでも綺麗な画像が撮れそうです。

重心もほぼ完璧です。

 上海も雨続きで、テスト飛行が待ち遠しいです。まずは出荷時の設定で飛ばしてログを取る予定です。

Chris RosserさんのBetaflight filter tuningについて

Betaflight filter tuning

PIDチューンは、謎が多くFPVドローンを始めてからずっと良い解説を求めて来ました。多くのことをYouTubeのUAV Techチャネルで学びました。最近では同じくYouTubeでChris Rosserさんのチャネルに注目しています。とても詳細な技術的な事柄をわかり易く解説し実践的なチューニングにつながる動画を公開されています。

この6月からPIDチューニングについての解説をいくつかの動画で公開されています。それらについて自分の理解を深める意味で日本語で要点について書き起こしてみることにしました。今回は最初の回でフィルター設定についてです。結果としてほぼ全てのシーンについて日本語訳をつけることになりました。加えて私自身の解釈なども少しだけ書いてあります。

最初にあるのがYouTube上のタイムスタンプです。グラフや画面コピーが沢山出てきますので動画を見ながら日本語を見てもらうと理解がしやすいかと思います。文中、カタカナになったり英字表記だったりして読みづらいかもしれませんがご容赦ください。

解説の前提は、
– RPMフィルターの設定が出来ていること
– 5インチ機を想定している、whoopにも通じることがほとんど
– Blackboxログが取得出来るFCであること、また説明ではOnboardフラッシュを念頭においています
– Blackboxログを見るためのBetaflight Blackbox Log Explorerが導入されていること

Timestamps:
0:00 – Intro

0:57 – Check the Mechanicals
機械的物理的チェック
– ネジの緩みが無いこと(強く締めすぎるのもまたよくありません)
– FCの上に配線を通していないこと、とくにジャイロ付近に注意 -> もしジャイロチップに配線が当たると大きなノイズの原因になります [これは盲点でした、まったく気にしたことがないです、小型機では完全にFC上をフリーにするのは難しいですがジャイロノイズを念頭においた配線を心がけたいと思います]
– ESC(電源線)にキャパシター(コンデンサー)が付いていること(6Sでは必須、4Sでも強く勧めます)
– Bidirectional D-shot(RPMフィルター)が設定されていてエラー0%であること
– プロペラは通常の飛行を想定したものであること -> もし少し曲がったプロペラで飛ばす事が多いのならばその状態に
– VTXアンテナはしっかりと固定されていること、前後にぐらつくことがないように -> 写真のように長いアンテナをTPUで出来たマウントに取り付けるのは理想的ではありません、短いアンテナが良いですが、長いアンテナを使う場合はPLAなどの素材でマウントを作った方が良い -> アンテナの振動が機体の振動につながります

3:35 – Fly a tuning flight on defaults
フィルターとPIDsを既定値のまま飛ばしてログを取ります
–  チューニング飛行には以下の動作を何度か行います
> フルスティック360度スナップロール
> フルスティック360度スナップフリップ
> フルスティック360度スナップヨースピン
> 3秒以上かけてゆっくりとスロットルを0からフルスロットルまで動かす
– 既定値でモーターはスムースに回転すべきです
– もしラフな感じならば最初の物理チェックに戻ります -> 特別に大きな機体などでは強いフィルターを設定しないとスムースにならないかも知れませんが皆さんが飛ばしている7インチ以下のサイズならばBF既定値で問題ないはず
– フライトの前にログを設定します

5:31 – Set up logging in BF
Betaflight Logの設定
– Blackbox logging rateは2KHzにセット
– Blackbox debug modeにはGYRO_SCALEDをセット [フィルター前のジャイロデータが取れます]
– Onboard chipの場合、Free spaceが十分にあることを確認、Erase FlashボタンでFeee spaceが得られます
– (変更した場合)Save and rebootを押します

7:13 – Filters 101
フィルターの設定にあたりセオリーから解説します
– 2つの種類のフィルターがあります
> Low pass
> Notch
– Low passは高い周波数を減衰します
– Notchは特定の周波数近辺を減衰します

8:01 – Low pass filter
– Low passは高い周波数を減衰します
– cut-off周波数付近から減衰し始め高い周波数のノイズをより強力に減衰する
PT1(single pole):
– 位相遅延(位相シフト)が小さいがフィルター効果も小さい
Bi-quad(double pole):
– Cut-offが鋭く、よりフィルター効果があります、また位相遅延も大きい

10:09 – Notch filter
– Notchは特定の周波数の周りを減衰します
– 目標周波数を大きく減衰し、その両側は減衰が少なくなります
– 目標周波数を低く、また幅広くするとフィルターを実行するにあたり遅延が大きくなります

11:44 – Filter Delay (Phase Delay)
– すべてのフィルターは位相遅延を引き起こします
– これはジャイロが動作を検知してから信号がPIDループに到達するまでの時間差になります
– これはフィルターの数学的な必要性から引き起こされるものでありFCの処理速度とは関係ありません [ちょっと考えてみると分かりますか、信号の変化から周波数を見極めるためにはしばらく変化を見続ける必要があります、どこかで見かけたのですがsingle poleで1/4周期必要らしいです]
– cut off周波数が低いほど遅延も大きくなる [位相で遅延するわけですので実時間を考えると周波数が低いほど遅延時間が長くなります、極端な例を言うと限りなく0Hzに近い周波数を見極めるためには無限の時間が必要になります]
– フィルター遅延はクワッドコプターの性能、とくにpropwashの扱いに影響を与えます
– 位相遅延は小さいほど良い、すなわち機体の振動、モーターの異音や加熱が出ない状態で
最低限のフィルター設定が望ましい

14:31 – Dynamic filtering
– Betaflightにはdynamic low pass filtersとdynamic notch filtersがあります
– フィルターの機能としては先に話したものと同じです、ただcut-off周波数が飛行中に変化するのです
– dynamic low pass filtersはスロットルポジションに連動して変化します
– dynamic notch filterはノイズのピーク周波数を追いかけて変化します
– RPM notch filtersはESCから得られるモーター回転数に合わせて変化します

15:36 – Betaflight filter settings
– Gyro Lowpass Filters
 > Gyro Lowpass 1 Dynamic Filter: 高い周波数を減衰するフィルターです、周波数はスロットルポジションに連動して変化します、Min Cutoff Frequency=200はスロットルを最小にしたときのcut off周波数です、Max Cutoff Frequency=500はスロットルを最大にした時のcut off周波数です、その中間ではスロットルに応じて直線的に変化します、Dynamic filter type=PT1ということであまり過激ではないフィルタータイプです
> Gyro Lowpass 1 Filter: その下はstatis(静的)なフィルターです、cut off周波数は変化しません、もしスロットルポジションによる周波数の変化を望まない場合は上のdynamicフィルターをオフにして、このstaticフィルターをオンにします
> Gyro Lowpass 2 Filter: これは上と同様のstatisフィルターです
– Gyro Notch Filters: これはstatisなnotchフィルターです、通常は必要ないと思います、center frequencyはターゲット周波数です、cutoff frequencyは50%の減衰が得られる周波数です [centerを中心に幅を持たせて減衰するわけですが、その下側を指定するのがcutoffです、centerから同じ幅で上側にも50%減衰するポイントがあります]
– Gyro RPM Filter: Hurmonics Numberは回転数の何倍の周波数までフィルターするかを指定します、3が適切な番号と思います、これでnotchフィルターのターゲット周波数としてモーターの回転数、モーターの回転数の倍、モーターの回転数の3倍が適用されます、2つ目の数値はMin Frequencyです、RPM notch filterの下限周波数を示します、低すぎるターゲット周波数は遅延が大きくなるので良くないです
– Dynamic Notch Filter
> Dynamic Notch Width Percent: [動画ではただ幅と言っています、2つのDynamic Notch Filterの間隔のような感じみたいです、0を指定するとDynamic Notchは一つだけになります、これがRPMフィルター使用時のおすすめです]
> Dynamic Notch Q: Notchフィルターの幅あるいはシャープさを表す係数です
> Dynamic Notch Min: ノイズをスキャンする下限周波数
> Dynamic Notch Max: ノイズをスキャンする上限周波数
[Min/Maxの間で強いノイズピークを見つけ出してフィルターしてくれる便利なものです]
– D Term: 右側はGyroデータではなくD Termを対象としたフィルターでそれぞれの定義はGyroのものと同じです
– Yaw Lowpass Cutoff Frequency: PT1フィルターでcut off frequency 70になっています [軽く流されています、存在意義など他の資料を見ても良くわからなかったです]

20:58 – Viewing your Blackbox log
– BlackboxタブでActivate Mass Storage Device ModeをクリックするとFC上のフラッシュチップがPCにドライブとして接続されます
– btfl_001.bblファイルをダブルクリックしてBlackbox Explorerを起動します
– ログが開いたらGyro scaledをクリックしてスペクトログラフを開きます [Graph setup/+Add graph/Debugの追加が必要かも]
– 左上でFreq. vs Throttleを選択します
– 右上のスライダーでゲインを調整し、3軸とも確認します

23:00 – What is each filter best at? – Gyro
– RPMフィルターがモーターノイズに最適です
– dynamic notchはフレーム共振にロックして取り除きます
– 上手に組み上げられていればその他のフィルター(low passなど)は必要ありません
– よって、私達はしばしばそれらをオフにします

25:54 – What is each filter best at? – D Term
– D Termが少しややこしいのはデリバティブ機能 [PIDのD] の性質として高い周波数の動きをより増幅するからです、そのためもし何もフィルターを使用しなかった場合、高い周波数のノイズが増幅されPIDループに過剰に作用し振動やモーターの加熱、フライアウェイなどにつながります
– ですから必ずlow passフィルターが必要です
– もしgyro low passフィルターをオフにしたらD Termのlow passフィルターは少し強くした方が良い
– 一般に、この方法 [Gyro low passオフ、D Term low pass強め] の方が位相遅延を少なくしフィルターの質を改善出来る

27:24 –
– RPMフィルターを使用すると縦線がしばしば現れます
– これは機体の共振による典型的な症状です
– これはスロットルの位置に関係なく一定の周波数を示しているのでstatic(静的ローパス)フィルターを使います
– クリーンな設定であれば、ひとつの100Hz Biquadフィルターから試すのが良い、もし振動やモーターの加熱が見られるならば90とか80Hzを試してみます、もしモーターの加熱などが見られなければ105, 110, 120Hzなどを試します、決して70Hz以下にはしないでください [遅延も問題になりますし、低い周波数には実際の機体の動きが含まれているので安易にフィルター出来ない]

29:42 – My recommendation for clean builds
私のクリーンビルドのフィルター設定
– gyro low passフィルターなし
– gyro notchフィルターもなし
– RPMフィルターを使用(設定値は画面を参照)
– dynamic notchフィルターは使用(設定値は画面を参照)
– d termは画面の通りひとつのlow passフィルターのみ設定(設定値は画面を参照)

31:50 – Dynamic notch and the AOS 5
AOS 5という共振を極力小さくしたフレームの話しなので詳しい日本語解説は割愛、簡単に言うと注意深く共振を抑えたフレームならばgyro dynamci notchフィルターさえも必要ないそうです

33:29 – Outro

[ スライダーによるフィルター設定との対比、スライダーを動かして数値を眺めてみると分かりますが、Gyro/D termそれぞれのLow passフィルターの周波数を変化させています。スライダーを左に持っていくと周波数を低く、右にすると周波数が高くなります。これでモーター加熱やフライアウェイの発生しない範囲で遅延を小さくするポイントを見つけるというのは合理的な手法です。この動画ではスライダーだけでは実現出来ないGyro Low Passフィルターをオフにするといった積極的な手法を実行しています。]

Happymodel ELRS 24G AIO FC

HappymodelのExpressLRSシリーズを試してきてかなり調子が良いので手持ちのFrSkyは一掃してCrossfireとELRSだけにしようと思っています。こうなるとELRSの受信機と200mW VTXが搭載された1S Whoop FCも試してみるしかありません。

[ Betaflight ]
いまだRelease Candidateも出ていない4.3が搭載されています。SPI接続なELRS受信機のためのファームが入った特殊なバージョンですので、他のバージョンのBetaflightを導入するわけには行きません。そのためテスト版のBetaflight Configuratorの導入が必要です。また正式版ではないため、いろいろと不都合もあります。

[ ELRSのバインド ]
最初は他のELRS受信機のようにbinding phrase付きのファームを焼いてと思いましたが、SPI接続の受信機のファームはBetflightと一体のためそういう訳には行きませんでした。バインドモードはBetaflight ConfigurtorのReceiverタブにあるBind Receiverを押すことにより入ります。ELRSも開発中のためバージョンによる互換性が心配でしたが1.0.0-RC9を導入したTXから問題なくバインド出来ました。

記事の投稿直後にツイッターで教えてもらいました。SPIレシーバーでもパスフレーズが使えるそうです。

[ ESC ]
blheli_s 16.8が入っていました。RPMフィルターは必要ないですが48KHz PWMで稼働するためにファームの更新を試みました。ただJESC、Bluejay, Blheli_Mどれもうまく行きません。どうもESCタイプO-H-5というのが鬼門のようです。仕方がないのでJazzmavericの16.8をダウンロードして焼きました。

これでまあ何とか飛んでいます。しっくり来ないところもあり設定をいじり続けていますが、まあお試し的には満足しています。

Happymodel ELRSのファーム更新をやってみた

Happymodel 2.4GHz ExpressLRSのTXとRXは出荷時のファームウェア(かなり低いレベルと思う)で問題なく稼働していましたが、少し思うこともありRC8版を導入してみました。手順についてはOscar Liangのサイトに詳しく書かれていますので、そちらをご覧いただくのが良いと思います。わたしの場合、いくらか例外的な事が発生しましたのでそれについて書いておきます。

出荷時のレベルで困ってはいなかったのですが、実際に更新してみると手動バインドの必要が無くなるBinding Phraseの便利さを実感しました。それだけのために更新する価値があると思います。

[ ファームウェアのビルド ]
最新のExpressLRS Configuratorを導入します。

自分用のファームウェアをビルドするのですがGUIで必要事項を埋めていくだけでビルド出来るので簡単です。

ステップとしては4項目です。
– まずはRelease、この記事を書いている時点での最新は1.0.0-RC8です。
– Targetは自分のハードウェアとファームウェアの導入方法によって選択します。わたしの受信機にはWiFiで導入するつもりなので”HappyModel_EP_2400_RX_via_WIFI”を選択しました。
– Device optionsはStandard modeではGUIでオプションを選択する画面が出るはずですが、私の場合上のスクリーンショットのように赤文字でエラーになってしまいました。これはネットワークに問題(地域的問題)があると思われます。問題を回避することも考えましたがManual Modeでやってみることにしました。赤い文字で表示されているエラーメッセージの中にURLがあるのでそこにアクセスするとuser_defined.txtというファイルが表示されます。それをコピーしてManual Modeにすると現れるテキストエリアに貼り付けます。そして必要なオプションを変更します。内容についてはOscar LiangのGUIでの設定例を見るとだいたい検討が付きます。

わたしの設定例を以下に貼り付けておきます。

### The Legal Stuff ###

# The use and operation of this type of device may require a license and some countries may forbid its use entirely.
# It is entirely up to the end user to ensure compliance with local regulations. No claim of regulatory compliance is made. In most cases a HAM license is required.
# This is experimental software/hardware and there is no guarantee of stability or reliability. USE AT YOUR OWN RISK

# HOW TO USE THIS FILE: https://github.com/AlessandroAU/ExpressLRS/wiki/User-Defines
# SIMPLY SEARCH WHICH DEFINE YOU NEED HELP WITH AND

### BINDING PHRASE: ###
# Uncomment the line below to use a hardcoded binding phrase
# Leave commented to use traditional binding
-DMY_BINDING_PHRASE=”MyBindingPhrase”

### REGULATORY DOMAIN: ###

#-DRegulatory_Domain_AU_915
#-DRegulatory_Domain_EU_868
#-DRegulatory_Domain_AU_433
#-DRegulatory_Domain_EU_433
#-DRegulatory_Domain_FCC_915
-DRegulatory_Domain_ISM_2400

### SWITCHES: ###

-DHYBRID_SWITCHES_8

### PERFORMANCE OPTIONS: ###

#unlocks >250mw output power for R9M and Happy Model ES915TX (Fan mod suggested: https://github.com/AlessandroAU/ExpressLRS/wiki/R9M-Fan-Mod-Cover)
#-DUNLOCK_HIGHER_POWER

#-DNO_SYNC_ON_ARM

-DFEATURE_OPENTX_SYNC
#-DFEATURE_OPENTX_SYNC_AUTOTUNE

-DLOCK_ON_FIRST_CONNECTION

### COMPATIBILITY OPTIONS: ###

-DUART_INVERTED

#-DUSE_R9MM_R9MINI_SBUS

#-DTLM_REPORT_INTERVAL_MS=320LU

### OTHER OPTIONS: ###

-DAUTO_WIFI_ON_INTERVAL=30

#-DJUST_BEEP_ONCE
#-DDISABLE_STARTUP_BEEP
#-DMY_STARTUP_MELODY=”B5 16 P16 B5 16 P16 B5 16 P16 B5 2 G5 2 A5 2 B5 8 P4 A5 8 B5 1|140|-3″

-DUSE_500HZ

# Comment this to disable advanced telemetry.
#-DENABLE_TELEMETRY

#Comment this to disable diversity function
#-DUSE_DIVERSITY

既定値から変更したのは3か所だけです。
#-DMY_BINDING_PHRASE="default ExpressLRS binding phrase"
最初の”#”を取り除き、任意の文字列をBindng Phraseとして書き込みます。自分の全てのTX, RXのファームウェアに同じPhraseを指定します。こうすることにより自動的にバインドされるので手作業によるバインドは必要がなくなります。これはとても便利です。
#-DRegulatory_Domain_ISM_2400
Domainのリストから適切なものをひとつコメントアウト(最初の”#”を取り除く)します。2.4GHzの場合はこの行をコメントを外します。
#-DHYBRID_SWITCHES_8
3ポジョンスイッチを使用するためには、このコメントを外します。
#-DUSE_500HZ
これもコメントを外しました。

– ActionsでBUILDボタンを押すとファームウェアが出来上がり、ファームウェアファイル”firmware.bin”がFinderで表示されます。

[ RXへのWiFi書き込み ]
これは問題なく手順通り出来ました。簡単に手順を書くと、TXをオフにしてRXに電源を投入し30秒ほど待つとLEDが速い点滅になりWiFiが有効になります。PCから”ExplessLRS RX”に接続します。WiFiパスワード”expresslrs”です。ブラウザーから10.0.0.1に接続するとExpressLRSの画面が表示されます。下の方のファイル選択ボタンで先のfirmware.binを選択しUpdateボタンを押します。ボタンを押してもPC画面はすぐには反応しません。暫く待つと成功した旨のメッセージが出てRXが再起動します。RXのLEDはUploadが始まると消えるので、そちらを見ているとUpdateボタンが押されたかどうかはわかります。

[ TXのアップデート ]
TXをWiFiアップデートするためにはLuaスクリプトからWiFi Updateを起動するのですが、わたしのTXでは何故かWiFiが立ち上がりませんでした。TX上のUSBコネクターを使用してアップデートすることにしました。
– TX上のジャンパー変更が必要です。出荷時には6個のジャンパーの中央の二組にジャンパーが入っています。これを下の二組に移動します。

– リモートの電源を上げてTXにUSBケーブルを接続します。ELRS ConfiguratorのSerial Monitorで接続を確認できます。ただし、そこから接続したままだとファームウェアの更新が出来ません。確実にDisconnectするかELRS Configuratorを立ち上げ直します。
– TargetをUART接続のものを選択します。わたしの場合は”HappyModel_ES24TX_2400_TX_via_UART”です。RXと同様にDevice optionsを設定します。ActionsではSerial Deviceを選択してBUILD & FLASHボタンを押して書き込みが終了するのを待ちます。

わたしの場合はLua Scriptも最新版にする必要がありました。

これで完了です。Binding Phraseを使用したので再バインドも必要なくすぐに使用できる状態になりました。

Tango2の外部モジュールでCRSFshotを使用するにはFreedomTX 1.29が必要

日本語で書いてもあまり意味がないかもな情報です。Facebookの関連グループにはシェア済みです。Blackbox Logの活用事例とも言えるのでともかく書いておきます。

TBS Tango2の外部モジュールとしてExpressLRS 2.4GHzを接続しています。PID調整の実験でBlackbox Logを見ていてSetpointが階段状になっているのに気付きました。

SetpointはBetaflightが計算したGyro値の目標値ですが、元々はスティックの動きから来ています。その解像度はいろいろな要因がありますが、TXモジュールに依存していると言っても良いと思います。ExplessLRSの設定では250Hzにしています。上のスクリーンショットでは36Hzくらいの更新頻度しかありません。

どこかがおかしいということで調べていくとFreedom TX 1.29のリリースノートに”added: CRSFshot for external modules”という記述を見つけました。ということでTango2のFreedom TXを更新してSetpointが滑らかになることを確認しました。

Happymodel ES24TXをTango2に取り付けた

Happymodel 2.4GHz ExpressLRS Micro TX Module ES24TXは2.4GHz ExpressLRS用の送信側モジュールです。自作する場合をのぞけば2.4GHz TXとしては唯一の選択肢です、たぶん(追記:ImmersionRC Ghostにファームを焼くことも可能なようです)。この製品はJRベイ用に設計されているためTBS Tango2にはそのままでは接続できません。スリムベイにJRベイを取り付けるアダプターを使用すれば良いのですが、かなり大きくなってしまいます。そこで直接取り付けるためのアダプターを自作しました。

スリムベイとJRベイは形状及びコネクターが違うだけで結線は同じです。形状を合わせるための3Dモデル(一部、GithubでExpressLRS用に公開されているものを流用)とジャンパーケーブルを作るだけで実現できました。詳細はThingiverseで公開しています。

Happymodel ExpressLRSを試す

ExpressLRSはオープンソースプロジェクトでTBS Crossfire以上の性能を目指すラジオコントロールリンクです。900MHz帯と2.4GHz帯があります。ハードウェアも自作することが基本でした。部品点数が少ないので、さほど難しくはないとは言えプリント基板から起こさねばならないので万人向けではありませんでした。書き忘れ: Frsky R9Mハードウェアのファームウェアを書き込む方法もありました。

そこに登場したのがHappymodelの完成品です。900MHz帯はすでにTBS Crossfireを使用しているので2.4GHzの製品を試すことにしました。2.4GHz受信機は3種類あります。チップセットの違いとアンテナの違いです。わたしの入手したのはEP1_RXとEP2_RXです。EP2_RXは基板上にセラミックスのアンテナが搭載されているためWhoopに搭載するとかなりコンパクトに出来そうです。送信機はJRベイです。今どきの小型RCではアダプターが必要です。

完成品ですのでベータ版ながらファームウェアは書き込まれていますので基本的な設定だけで使用することが出来ます。設定など必要な情報はExpressLRS Wikiに書かれています。以下、私が最初にテスト飛行するまでに行った設定の概要です。

[ 送信機 ]
ExLRS Lua ScriptをTango2のScripts/Toolsフォルダーにコピーしました。
モデルはExternal RFでCRSFモードを設定します。ExpressLRSはOpenTXもBetaflightもCRSFとして動作します。

[ 受信機 ]
受信機とFCの結線はCrossfireと同じで任意のTX/RXを使用します。SBUSの様に信号が反転しているかどうかなどは気にしなくても大丈夫です。

まずはLEDの意味を理解しておきます。

バインドモードの入れ方です。

バインドモードになったら送信機のELRS LuaスクリプトからBindを実行し受信機のLEDが点灯しっぱなしになれば完了です。

[ Betaflight ]
ほぼCrossfireと同じです。ReceiverはSerial based receiver/CRSFを選択します。アナログVTXの場合はOSDでLQを選択すると信号が確認できます。信号強度RSSIもありますが、一般的にはLQだけ見ておけばよいです。DJI Digital FPVの場合はOSDがフルサポートではないので従来通りのAUXに割り当てられたLQ/RSSIをOSDで見るようにします。AUX11がLQ, AUX12がRSSIをあらわします。

Telemetryも取得できるようにしておきます。

[ テスト飛行 ]
設定さえ出来れば、当たり前ですが普通に飛びます。レンジテストとかしようとは思わないので普通に飛べばわたしとしては完了です。

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

前回も書いていますがBlacboxログを利用した動画スタビライズ関連のおさらいから始めます。現在、2つの方法があります。一つは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は2つのポイントで画像データとgyroデータを解析してオフセットを計算してくれます。そのために動画のどのあたりで解析すべきかを指示するためにAuto sync timestampを指定します。動画を再生してみてクラッシュ以外で大きな動きをしている場所を動画の最初の方と終わりの方で調べておき、その時間を秒数でAuto sync timestmap 1とAuto sync timestamp 2に指定します。

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

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

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

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

しばらくすると下の方の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した動画はフレームが踊っている変わった動画です。中央を上手に切り取ることによりスタビライズした動画となります。