Dropbox

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

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

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

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

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

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の問題に思えますが、まだ結論は出ていません。

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に接続する方法は、次の記事で紹介する予定です。

BetaFPV 95XフレームにはBetaFPV GoPro Liteを搭載していましたが、かなりpropwashがひどくダイブとまでは言わなくとも機種を下に向けるだけでフラフラしていました。Cinewhoopですし、そういう飛び方をしなければ良いのですが3Sで飛ばしていたumma85よりも飛ばしにくい気がしました。

フリースタイル的に飛ばすためにumma搭載toothpickにすることも考えましたが、まずはumma95を試してみることにしました。umma95は基本的にはCaddx Vistaを載せること以外はumma85と変わりません。独自に変更した部分を中心にかいつまんで書いておきます。

機体スペック

BetaFPV 95X Frame
BetaFPV F4 AIO FC 12A V2
BetaFPV 1106 5000KV
HQProp DP T2.5X2.5X3
TBS Crossfire Nano RX
Caddx Vista
BetaFPV BEC Board half
Naked GoPro Hero6 Black

VISTAマウントをオリジナルの垂直から水平に変更した。おそらくTPUなら問題ないのですが、PLAで作ったため、縦置きだとちょっと転んだだけでアンテナマウントが壊れてしまうことへの対応です。既存の造形の合わせ技で作りました。

これはumma95の標準ですが下側はVTXカバーから脚に変わりました。これはハードに着陸しても壊れず安心です。またCrossfireの受信機は、この中に格納しました。

これが一番の変更点ですが、ummaのカーボンプレートを2枚使いGoProボードの保護を図りました。これは以前、操縦不能に陥って墜落した時にGoProボードを物理的に壊したことの対策です。わたしのオリジナルアイデアではなくて、何方かがFacebookで紹介されていた手法です。

GoProメインボードには半分に切断したBetaFPV BECボードのBEC側を搭載しています。電源としてVBATをBECボードに供給しています。

LED_StripによるGoProコントロールも設定しています。加えてボタンのついたリボンケーブルも接続しています。これは主にはマイクを接続するのが目的です。これによりモーター音の録音と音声コマンドの使用が可能になります。

GoPro Liteを搭載した時はPropwashが酷かったのですが、umma95にしてから嘘のようになくなりました。ロープロファイルな形状が良いのかプッシャーが良いのかはわかりませんが見違えるような飛び方です。

チューニングも軽く行っていますがBetaflight 4.2にHD向けプリセット(4.2 Tuning Notes参照)+RPMフィルターだけで良い感じに飛びました。

フィルタースライダーは、何時ものように少しづつ右に動かしながらテストしました。1.4まで行ったところでfly to the moon(意図せず上昇)になりモーターの加熱が認められました。おそらくは1.1か1.2くらいが安全な感じでした。

まったりとした飛びにしたいのでStick Resposeは0.7にしました。ややbounce backが感じられたのでPDバランスを1.1にしてみましたが、戻してみてもbaounce back自体がなかなか確認出来なくなったので良くなかったかどうかは良くわかりません。propwashも少しだけ残っているのでPIDはもう少し追求していく余地があるかも知れません。Cinewhoop的な飛ばし方をする分には、このままでまったく問題はありません。

まだチューニングの途中ですが、まったりとしたフリースタイルがこなせる機体になりました。

GoProを使い始めて約1年になります。設定などは先人たる世界のFPVドローンパイロット達が公開している設定を真似て使用していました。カラーは当然の如く皆さんFlatを使用しています。出来るだけ情報量を多く記録しておき編集で好みの色合いに設定するわけです。完全に素人なので、その編集でカラーコレクト(ノーマライズ)する方法も色々な人が公開している方法をかいつまんで行っていました。概略を言うとパレード図というのを出してColor Wheelsでレンジを広げたり黒いところ、白いところを基準に合わせて行くみたいな感じでした。これが次のYouTubeを見てまったく違うやり方になりました。

全然、用語も知らないし、同じDaVinci Resolveなのに見たことのない画面やテクニックで驚きます。この動画が始まってすぐに、まあとりあえずLUTは当てときましょうって言ってます。LUTって何?状態です。どうもカメラ毎のLog映像に合わせたプリセットらしいです。ところがDaVinci Resolveの画面を見てもGoPro Flatというのが見つかりません。ググってみるとGoPro用のLUTなどもネット上にあるようですが、DJI_Phantom4_DLOG2Rec709というDaVinci Resolveに最初から入っているものを適用しても良い結果が出るという情報を見つけました。

試してみると、驚くほど綺麗に仕上がります。先の動画だと、これをベースにもっといじるまでが基礎の基礎らしいです。見様見真似でやってみてはいますが、撮影条件やGoProのモデルにもよるでしょうけど、わたしの技術的にはLUT適用だけでも大差が無いかもしれません。詳しい手順は先の動画を見ていただくのが良いですがLUT適用のところだけ画面を紹介しておきます。

カラーの調整はColorタブの中のノードに対して行います。ノードを右クリックして目的のLUTを見つけたのが上のスクリーンショットです。

先の動画の説明にあるように他のカラー要素をいじるときには要素毎にノードを追加して行うとノード毎にリセット出来るのでやり直しが簡単になります。ノード上で右クリックしてAdd Node/Add Serialを行うと良いでしょう。

複数クリップに同じ調整をするのにはAdjustment Clipを使うなどという話しもしたいところですが、長くなりますし、探すとすぐにやり方は見つかると思います。

実際にLUTを適用したわたしの動画を紹介しておきます。最後の方は、さらに微調整に挑戦していますが、実のところLUTを適用しただけのものと大差がない気がします。

いろいろ設定中に気がついたのですが、GoPro Remoteや携帯電話のアプリから接続が出来ないことがあります。WiFiの電波が発信されていません。ただし送信機やRECボタン、音声コントロールは正常に作動し録画できますので、現象自体になかなか気づきませんでした。また、色々と操作しているうちにWiFiが発信されるようになることもあります。

原因は簡単なことでした。送信機とBetaflightの設定によりGoProの電源が上がる時にRECボタンが押されている状態になっていたからでした。どなたかがTwitterで似たようなことを書かれていたような気もします。それですぐに思いつきました。物理的なRECボタンを押したままGoProの電源を投入しても同じ現象が再現できます。

BetaflightのサイトにBetaflightの設定ガイドがありますが、実はそこにもわざわざ赤字で注意されていることでした。


これが私の間違った設定です。USER1は送信機のモーメンタリスイッチがオフだと左端、オンすると右端に移動しRECボタンを押下した状態になります。問題なく構成できているように見えます。ところが、機体の電源が投入され送信機と接続される前はUSER1は中央値1500になります(failsafe画面で変更も可能です)。それだとRECボタンを押していることになってしまいます。GoProメインボードには自動電源投入のジャンパーが施されていますので、電源投入時には常にRECボタンが押されていることになります。


対策は簡単でUSER1が1500になっている時にはオフ(左端と同じ)になるように設定するだけです。failsafeで受信機が信号を送ってこない時の値を変更して対処も出来ますがあまり一般的とは言えません。