11月
17
Mr Shutterbugが動画の中で紹介していたWhoopフレームの修理に使えるE6000と書かれた接着剤を試してみました。
確かにフレームの素材によく馴染んで強力に接着されます。普通に飛ばして問題ないレベルです。いずれフレーム交換するにせよ、面倒ですし接着して飛ばせるのは有り難いです。
11月
13
ESCのハードウェアは大きく分けて２つの種類があります。BLHeli_32と BLHeli_Sです。以前は悩むことはありませんでしたが、昨年末からBetaflightのRPMフィルターが出現し、またWhoopではPWMを48KHzにすると飛行時間が伸びるなどと言われだしました。BLHeli_32では標準ファームウェアでどちらもサポートしているので問題ありませんが、BLHeli_S用の標準ファームウェアはRPMフィルターを動かすのに必要なBidirectional DSHOTのサポートがありません、またPWM周波数も24KHzに固定されています。
そこで登場したのが標準以外のBLHeli_S用ファームウェアです。いくつか登場していますので、わたしの理解の範囲でそれらについて書いてみます。
[ JESC ]
最初に登場したのがJESCです。PWM 48KHz/96KHzを使用するだけならば無料で使用できます。Bidirectional DSHOTを使用するためには有料ライセンス(4個なら$4.99,20個で$23.19等)を購入してライセンスの書き込みが必要になります。
安定しています。とくに問題を指摘されている様子もないので安心感があります。わたしも最近20個分のライセンスを購入してまだ未使用が多数あるので、悩まずにこれを使用しておけば良いのですが、どうしても色んなのを試してみたくて次に紹介するBLHeli_Mで実験中です。
[ JazzMaveric/BLHeli_M ]
次に待望の無料版として登場したのがJazzMavericです。これのPWM 48KHz版でRPMフィルターを使用して随分と飛ばしていて特に問題は感じていませんでしたが、Betaflight公式ページによるとバージョン16.73以降でのRPMフィルターの使用は推奨しないということです。16.73を使用すればよいのですが、このバージョンはPWM 24KHz版しかありません。
そして、最近になってJazzMavericがいつの間にかBLHeli_Mというものに進化しているのに気づきました。ファームウェアの書き込みは専用のConfiguratorから行います。2020年11月13日現在、このConfiguratorで書き込めるのはBLHeli_S 16.7 Official, BLHeli_M 16.71 Official beta, BLHeli_M 16.9 Officialの３つのバージョンです。
PWM周波数の変更は従来はファームウェアの書き換えで行っていましたがBLHeli_MではConfiguratorで行うようになっています。
飛行時間の変化で実験してみた結果、BLHeli_M 16.71では、このPWM周波数の変更は有効ではないようです。PWM 48KHz/96KHzを使用する場合はBLHeli_M 16.9を導入する必要があります。
BLHeli_Mは何かしら変更されているとは言えJazzMavericそのものです。そこで問題となるのはRPMフィルターを使用して良いかどうかということです。BLHeli_M 16.71はおそらく問題ないと思います。BLHeli_M 16.9がどうなのかは今ひとつ分かりません。
UAV Techの人が16.9で問題は見当たらないと言っているので大丈夫な気がします。わたしもしばし16.9でRPMフィルターを使用して飛ばしてみたいと思います。
[ bluejay ]
これはまだ始まったばかりのプロジェクトです。Change Logを見ると最初のバージョンが2020-10-18に出てその後積極的な更新が行われています。
PWM周波数の対応、RPMフィルターの対応は当然として、何かしら新規性があるようですが、まだ良く調べていません。そのうち試してみたいと思っています。
11月
12
昨年末くらいだと思いますがESCを48KHzで使用することによりWhoopサイズでは電池の持ちが改善するということを聞きました。当時、BLHeli_Sを使用する機体ではJazzMavericもしくはJESCの48KHzバージョンのファームウェアを導入することでPWM周波数の変更するしかありませんでした。自分でバッテリーの持ちの改善具合をテストしてみたいと思いながらもファームウェアを焼き直してまで試すことはありませんでした。
最近になってBLHeli_Mというファームウェアの存在を知りました。これはJazzMavericの流れを組むものでConfiguratorでPWM周波数が選択できます(導入はこのConfiguratorから行います。無料でRPMフィルターが使用できます)。これにより気軽にPWM周波数を変更出来ますので、やっと自分で電池の持ちの変化を確認する気になりました。
テストに使用した機体:
Beta65 Pro Frame
FC HBSfpv F4
BetaFPV 0802SE 22000KV
GEMFAN 1219-3
BetaFPV Z02 AIO Camera 5.8G VTX
TBS Crossfire Nano RX
BETAFPV 260mAh BT2.0
Emuflight 0.3.2 + MOCKINGBIRD準拠の構成
BLHeli_M 16.9
EmuFlightのPower TabでWarning Cell Voltageを3.3V、Minimum Cell Voltageを3.2Vに設定しました。
BLHeli_Mの構成で既定値から変更しているのは2つで、Startup Powerを1.50、Motor TimingをMediumHighにしています。
テスト方法:
電池6本をナンバーリングし、充電器の決まったチャネルで充電することにより電池と充電ポートの個体差による影響を排除。
PWMを24KHzに設定し、6本の電池で順にアングルモード室内飛行しアームからLow BatteryとLand Nowが表示されるまでの時間を計測した。その後PWMを48KHzと96KHzに設定して同じテストを行った。
結果:
| 24KHz | 48KHz | 96KHz | ||||
| Low Battery | Land Now | Low Battery | Land Now | Low Battery | Land Now | |
| 1 | 133 | 149 | 156 | 173 | 162 | 178 |
| 2 | 125 | 142 | 148 | 166 | 156 | 172 |
| 3 | 122 | 138 | 152 | 163 | 148 | 160 |
| 4 | 124 | 141 | 151 | 166 | 149 | 165 |
| 5 | 129 | 138 | 153 | 166 | 147 | 157 |
| 6 | 119 | 128 | 152 | 158 | 144 | 156 |
| Average Time(s) | 125.33 | 139.33 | 152.00 | 165.33 | 151.00 | 164.67 |
| Improve% to 24KHz | 21% | 19% | 20% | 18% |
結論:
24KHzと48KHzの差は明確です。数値としては96KHzより48KHzの方が少し良いですが誤差の範囲です。面白いのはDVRを並べて見てみるとCurrent Drawはそれぞれあまり変わらなくて電圧の低下が24KHzだけ速いです。もしかすると瞬発力などは24KHzの方が強いのかも知れませんが、それを定量的な観測をする方法を思いつきません。
このバッテリー持ちの改善効果は小さい機体だけとの話しです。機体サイズを変えてテストしてみたいですが大きな機体になると屋外テストが必要ですしなかなか手が出そうにありません。
9月
28
DJI Digital FPVゴーグル用アンテナLumenier AXII HDアンテナのテストは一度行っていますが、急いでテストしたため自分でも結果に自信が持てなかったので再テストを行いました。
前回のテストと同じ場所で少しコースを変えてテストしました。今回は各アンテナ構成で二度飛ばして同じような結果になることを確認しました。またゴーグルが記録している数値データの評価も行いました。取れているデータを見てみると信号の強さは4段階しかありませんので評価からは除外しました。遅延が使えそうな気がしていましたが、実際に限界状態で飛ばしている時と数値の悪さ加減が今ひとつ一致していませんでした。ということで、一番状態をよく表しているのがビットレートでした。それぞれのアンテナ構成で2回飛んだうちで良い方のデータをグラフにして比較しました。
X軸は時間あるいは場所に相当しますが各フライトの速度は違うので完全には一致しません。そこで信号が悪くなり始めた特定の場所をビデオから判断して各グラフの位置をそこで合わせました。
結果をみるとDJIのオリジナルアンテナは早くから脱落し始めています。そして画面をロストしてしまい機体を元の位置に戻すことが出来ませんでした。二度のフライトとも同じでした。あとは微妙な違いです。しかしながらパッチアンテナを下にした方が落ち込みが大きいです。実際に飛ばした時の感じからも危うさを感じました。パッチアンテナを上にした場合と混合構成はほぼ同じ結果でした。飛ばしていた時の気持ち的には前回の結果も有ってパッチアンテナを上にした時の方が安定していたように感じました。データをみたりビデオを見る限りほぼ差はなかったのかもしれません。
わたしの結論としてはパッチアンテナは上に付けて使っていこうと思っています。
9月
11
さらに最新版ではいろいろと変わりました。v0.62での例はhttps://www.nkozawa.com/blog/archives/7178をご覧ください。
最新版導入したら随分と画面が変わっていました。導入などはこの記事を見ていただくとして新しい画面についてはPIDtoolbox v0.44を御覧ください。
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がうまく動かないからです。macOSでは予めblackbox_decodeを単独で一度だけ走らせて置く必要があります(野良プログラムを動かすための儀式を済ませておくためです)。
結局のところ、zipを展開したところにあるmain/PIDtoolboxを直接起動するのが良いようです。MATLABは必要なので先のインストーラーの実行はスキップ出来ません。
< 補足 > 2023/05/23
v0.61ではインストールされた場所からの起動して動くようになっています。導入時にblackbox_decodeを展開したフォルダーを指定するようになったことがミソのようです。
[ ファイルの選択と読み込み ]
Select File [A]とSelect File [B]と2つのblackbocログが選択出来ます。PIDやフィルターの設定前後のログを同時に表示して比較する事が出来ます。Windowsでは任意の場所のログファイルを開くことが出来るようですが、macOSではログファイルをプログラムのあるフォルダー(zip展開後のmain下)にコピーしておく必要があるようです。
< 補足 > 2023/05/23
v0.61で試したところ、ログファイルは任意の場所にあるものを指定するようになりました。逆に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の問題に思えますが、まだ結論は出ていません。
8月
19
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)
燃えるひとつ前の快調な飛行の様子(剥きプロ-フィルターがちょっと汚れている)
8月
18
少し前に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のモバイルバッテリーを買い足すつもりです。
8月
16
FPVドローンを組み立てて最初にリポを接続する時はドキドキします。簡単にテスターでショートしていないかどうかは確認することは当然ですが、それでもまだ心配(VTXの誤配線などなど)はあるので海外のビデオなどではスモークストッパーと称してリポと機体の間に電流を制限するために電球を入れたりしています（と同時に電流が流れすぎると電球が明るく光る）。いずれは同じものを作ろうと思っていましたが、電球を使うのも今ひとつな気がしてのびのびになっていました。
電球を使う代わりに電子回路で過電流を防止する製品を使用するのが楽そうで良いのですが、過去に見てきた製品は、なんか今ひとつで手が出ませんでした。VIFLY ShortSaverはYouTubeでJoshua Bardwellが褒めているくらいで、今までの物とは少し様子が違います。機能としては1Aもしくは2A（スイッチで選択できる）を超える電流が流れると遮断するものです。説明によると回路がショートしている場合は3ms、一般的な過電流の場合は10msで遮断されます。ジャンパーの変更により、もう少し時間を長くすることも可能です。
実際にDJI FPV搭載5インチ機で試してみると1AだとFC/ESCの初期化が終わってモータービープが鳴り始めるところで遮断されました。2A設定だと遮断は発生しません。1A設定でも遮断されるまでに十分に時間があるので機体に問題が無いことは判別可能です。
おそらく、誤配線などからちゃんと機体を守ることが出来そうな気がします。多分、2Aの設定で使っていくと思います。
7月
28
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を利用すると良いようです。
7月
27
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に接続する方法は、次の記事で紹介する予定です。