普通的生活

四国のタイニーレースで使用する勝ち上がり戦のレース形式でのFPVTrackSideの運用方式は集計まで含めてFPVTrackSideで完結しているので、FPVTrackSideだけでレース運用は可能です。ただしFPVTRackSideが提供する画面だけだと柔軟性に欠けるため配信や会場でのレース状況の表示にうまく適用できません。

FPVTrackSideにはローカルwebでレース結果を表示する機能はありますが、今回作り込んだ勝ち上がり戦の状況を確認するのには適していません。

そこで従来TVP+Google Sheetで行っていたような順位表示とレース中に周回数をグラフ表示させる外部の連携プログラムを構築しました(AIが)。以下のリンクで公開しています。

https://github.com/nkozawa/fpvt2google/

プログラムはPython3で書かれていて特別な外部モジュールは必要としていません。Python3が動けばどんな環境でもすぐに使えると思います。

[ FPVTrackSideからのデータ供給 ]

アプリケーション設定のGate / LED POST notificationをExtension Modeで供給されるデータを利用します。

[ 使い方 ]
Python3.8以上が動けば追加のパッケージは必要ありません。
– 導入は適当なディレクトリーにfpvt2google.pyを置くだけです。
– 初期設定は python3 fpvt2google.py --initを実行するとfpvt2google.jsonファイルが作られます。Google Sheetを使用する場合、このファイルの最初の方にデプロイしたURLを入力しておきます。Google Sheetを使用しない場合はそのままで大丈夫です。
– python3 fpvt2google.pyで起動すれば稼働します。画面に表示されるログで稼働状況を知ることができます。またhttp://localhost:5705にアクセスしてローカルweb機能が動いていることを確認します。

Googleへのデータ送信を行わずローカルだけで使用する場合はpython3 fpvt2google.py --local-onlyで起動することをお勧めします。

[ fpvt2google.pyで出来ること ]

FPVTrackSideから得たデータを加工しGoogle SheetにPOSTします。ここでは受け取る側のGoogle Sheetの詳細については書きません。実際に使用しているGoogle側のスクリプトはgithubに入れてあります。
Google SheetへのPOST先は二つあり、一つはレース中に周回数をグラフ表示するものともう一つは順位表です。どちらも随時更新されていきます。順位についてはレース毎に、その時点での順位が表示されます。また、勝ち上がり戦に入ってしまうと予選順位はFPVTrackSideでは見ることが出来なくなるので、Google Sheet上に保管して後から振り返って見ることが出来るようになっています。

fpvt2google.pyはwebサーバーとしての機能も持っておりGoogle Sheetに表示するものと同じデータを表示することが出来ます。http://localhost:5705で閲覧できます。IP Addressかホスト名を指定すれば他のPCからのアクセスも可能です。

下のスクリーンショットはローカルweb機能のものです。

なんかローカルweb機能があれば会場での表示や配信には使えるのでGoogle Sheetの機能は必要が無いようにも思えますが、会場外でレースの状態を見ることが出来るので残しておきます。

長ったらしいタイトルになってしまいました。
MacBookにUSBサウンドデバイスを接続してFPVTrackSideの音を外部に出そうとしました。ところが、TTSの音声はUSBオーディオで再生されるのにレース開始トーンなどWAVファイルの音は本体のスピーカーで鳴ってしまうという現象に出くわしました。再起動するとうまく行ったりするのでとても悩みます。

根本原因は”設定/サウンド/サウンドエフェクトの再生装置”にあります。

このように出力デバイスはUSBサウンドになっていても、サウンドエフェクトの再生装置が本体スピーカーになっていると再生先の分離が発生します。

このサウンドエフェクトの再生装置を明示的にUSBオーディオにするか”選択したサウンド出力装置”にします。

そしてもう一点、もしすでにFPVTrackSideが起動しているのならば再度起動し直してください。そうしないと設定が反映されません。

「FPVTrackSideの四国レース設定 MacOS」を完了しておきます。

[ ladder_finals.luaの設定 ]
~/Documents/FPVTrackside/scripts/ladder_final.luaを必要に応じて編集します。

-- ===== 設定 =====
-- 公式練習のラウンド数（0〜3）。0 = 公式練習なし。
-- 予選の前に「予選と同じ組み合わせ」の練習ラウンドを作る。手作業で組み合わせを
-- 変えれば予選に引き継がれる。練習の結果はどの順位にも反映しない（予選の集計は
-- 練習より後のラウンドだけを読む）
local PRACTICE_ROUNDS = 0
-- 予選ラウンド数（1〜4）。0 = 手動モード: 回数を固定せず、生成するラウンドの
-- 「名前」で次を決める。空ラウンドを作って "Ladder"（または "Final"）と名付けてから
-- 生成するとラダー＋決勝、それ以外の名前（空を含む）なら続きの予選を生成する。
-- 手動モードで公式練習をやる場合は "Practice"（または「公式練習」）と名付ける。
local QUALI_ROUNDS = 2
local QUALI_MODE = "best"
local MAX_PER_HEAT = 4
local FINALS_COUNT = 15
local FINAL_HEATS = 3
local LADDER_HEATS = 1     -- 勝ち上がり戦の各段を何ヒートで競うか（1〜3）

-- 予選のヒート構成を名前で固定する（空 {} なら自動）。書いたヒートはそのまま使い、
-- 書かれていない選手は残りの人数で均等に新しいヒートを作る。
--   local QUALIFYING_HEATS = {
--     { "Alice", "Bob", "Carol", "Dave" },
--     { "Eve", "", "Frank" },      -- "" は空席のまま（このヒートは2人で飛ぶ）
--   }
-- 名前は空白と大文字小文字を無視して照合する（"Smallyuki" でも "SmallYuki" にマッチ）。
-- "" は意図的な空席。一覧に無い名前は警告して無視し、余りが1名だけのときは
-- 孤立した1人ヒートを作らずに警告する。
-- 未指定の場合は直前予選ラウンドの構成を自動的に引き継ぐ（generate 内を参照）
local QUALIFYING_HEATS = {}

最初の方に設定項目があります。
PRACTICE_ROUNDS : 公式練習の回数です。組み合わせは基本的に予選と同じです。順位には影響しません。中断して予選に進んでも構いません。
QUALI_ROUNDS : 予選を何ラウンド行うかを指定します。0だと予選回数を決めずにレースを開始できますが、使わない方向で考えています。
QUALI_MODE : 予選ラウンドの集計方法です。四国ではそれぞれのラウンドの一番良い成績のレースを選んで順位を決めるので”best”にします。
MAX_PER_HEAT : これは4で良いでしょう。
FINALS_COUNT : 決勝ラウンドに進む人数です。15と指定すると予選順位16位以下は足切りとなります。0にすると全員が決勝ラウンドに進みます。
FINAL_HEATS : 決勝戦のラウンド数です。
LADDER_HEATS : 勝ち上がり戦のラウンド数です。
QUALIFYING_HEATS : 予選の組み合わせを予め決めておくためのものです。

順位の決め方は周回数の多い方が勝ち、同一周回ならば総飛行時間が短い方、それも同じならベストラップで順位を決めます。
勝ち上がり戦と決勝ラウンドではポイント制で順位を決めます。ポイントの配分はFPVTrackSideのポイント設定にあります。四国では一位から順に5, 3, 2, 1, 0に設定します。もし同一ポイントの場合は、順位の合計が小さい方が勝ちです。それも同一の場合は予選順位が上位の方が勝ちとなります。

[ パイロット画像の登録 ]
「FPVパイロット一覧」あるいは独自に集めたパイロットのアイコン、写真、短い動画などがあれば ~/Documents/FPVTrackside/pilotsにコピーしておきます。

[ レースの進行 ]

先に作成したイベントを開くと下の画面になるので何らかの方法でパイロットを登録します。おそらくはエントリーリストからクリップボード経由で「パイロットを貼り付け」が一般的です。私は「プロフィール画像ファイル名からのインポート」もよく使います。

バイロット名の入力が終わったら「ラウンド」を開きます。

ラウンド上で右クリックもしくは三本線メニューから”Set Format/From Scripts/Ladder Finals 勝ち上がり戦”を選びます。

自動的に予選1戦目の組み合わせが出てきます。この組み合わせはパイロット名の文字アルファベット順になっています。予め組み合わせが決まっている場合は、ここでドラッグ&ドロップで選手名を入れ替えるか、予めladder_finals.luaのQUALIFYING_HEATSで指定しておきます。

レースの開始はレース番号、「エンデューロ 1-1」などと書かれているところをクリックします。

レース画面になり選手の紹介が始まります。スペースバーでレース開始です。レースの終了もスペースバーを押します。自動的に終了はしませんので必ずスペースバーあるいは右下のアイコンで終了させます。

レースが全て終了すると、次の予選が自動的に生成されます。QUALI_ROUNDSで指定した予選回数が終了すると勝ち上がり戦(Ladderラウンド)が生成されます。

FINAL_HEATS = 3, LADDER_HEATS = 1の例です。勝ち上がり戦は1ヒート、決勝は3ヒートです。
予選順位1位と2位の人は自動的に決勝戦に入ります。勝ち上がり戦は1位抜けですが、勝ち上がり戦の最後は1位と2位が決勝前に進みます。

VTXチャネルの変更を最小限にするように組み合わせが組まれています。そのため、勝ち上がった人の為の空席はヒートによって違います。またチャネル変更が必要な人のチャネルの色アイコンには三角マークが表示されます。

勝ち上がった人を次のヒートに入れるのは手作業になります。上のスクリーンショットはレース4-1で1位だったKPro-FPVさんをレース4-2の空席であるF3にドラック&ドロップしているところです。

決勝まで終了すると右側に最終順位が表示されます。省略しましたが予選中には予選順位の表示もあります。

順位表については外部のシステムで表示する仕組みも作り込んであります。これらついては改めて紹介します。

https://fpvtrackside.com/download から記事を執筆時点での最新版 FPVTrackside 2.77.3.889.dmg を導入し以下の作業を行いました。

四国のメンバーには設定済みファイルを共有する予定です。

基本的な設定につていは「FPVTrackside Mac版を使ってみよう」を見てください。チャネル、ArUco、映像入力、日本語設定などを行います。

[ zubon2003さんのFPVTrackside_localization_jpの導入します ]
チャネルの色やら諸々をいい感じに設定してくれます。

お好きな方法でダウンロードすれば良いですが、zipにするのがお手軽です。
FPVTrackSideを起動するとmacOSの場合は、ユーザーの書類フォルダー下にFPVTracksideというフォルダーが作られます(~/Documents/FPVTrackside)。ここに各種データが保持されます。ダウンロードしたzipの中にはdata, sounds, themeというフォルダーが入っています。それぞれFPVTracksideフォルダー下の同名のフォルダーにマージします。

[ ladder_finals.lua ]
https://github.com/nkozawa/LadderFinals
四国で行っている勝ち上がり戦形式のレース運営を行うためのluaスクリプト”ladder_finals.lua”を上のリンクからダウンロードしFPVTrackside/scriptsにコピーします。このスクリプトの詳細については別の記事に書きます。

[ イベントの設定 ]

– タイムゾーンは東京にしています。
– ラップ数、レース時間は耐久レース形式でレース時間は60秒の時の指定です。
– 最小スタート遅延、最大スタート遅延、両方に6秒を指定したのでレーススタート操作から6秒後にレース開始です。最小と最大に違う数値を指定すると、指定の数値間でランダムな時間を経過してからのスタートになります。
– 主要タイミングシステム位置を”End Of Lap”にするとヨーイドン・スタートになります。”Holeshot”にするとStggeredスタートになります。
– レース開始時の検出無視、最小ラップ時間、トップレーサーのラップタイムより十分に小さい数値にします。

[ サウンドエディター ]

レース開始時にカウントダウンさせたいので”Start Race in 5″にsoundsフォルダーの5.wavを設定、同様に4, 3, 2, 1を設定する。また、スタートの音を少し大きめにしたいので”Race Start”をtone.wavからlouder_tone.wavに変更した。

[ レーススタートのGO ]
レーススタート時に”GO”と画面に表示するためにはthemes下の適当なテーマに入っている”racestart.png”をFPVTrackside/themes/FPVTrackside-JPにコピーします。

[ キーボードショートカット ]

四国ではチャネル毎に審判をおき、ゲート通過をモニターで確認したら外部接続のボタンを押してTinyViewPlusのラップ追加を行っていました。同じハードウェアでラップを追加するためにショートカットを上のように変更しました。

SWR測定シリーズ、最後に残ったのは一番単純なモノポールアンテナです。

AIO FCのボード上のUFLコネクターが壊れた時に、芯線部分にワイヤーを接続してアンテナにすることは良くあります。少し古いAIOだと最初からワイヤーアンテナだったりもします。

中央付近の赤いワイヤーです。ちょっと短い気もします。

答えを先に言って仕舞えば13mmのワイヤーを付けておけば良いです。これは5.8Ghzの波長の1/4から得られる数値です。

アマチュア無線の勉強を少し思い出すと1/2λでも良いかもと思えますが、単純なモノポールアンテナではインピーダンスが極端に大きくなるので良くありません。実際に測定すると何時も使っているSWRのレンジでは測定できないくらい大きなSWRになりました。

測定するのはSWRなので電波の飛びを調べている訳ではありません。反射波でVTXに無駄な負荷を与えないことを確認するものです。

実際の測定は15mmくらいから始めました。15mmでもそんなに悪くなかったです。大体0.5mmくらいを目処に短くしつつSWRを測定していきました。だんだん少しづつ数値が良くなり、大体13mmの時のグラフが次のものです。

そこからもう少しだけ短くしたら、ちょっとだけ数値が悪くなりました。

普通の定規で測って13mmくらいに切ったワイヤーを取り付ければ問題ないと言うのが結論です。ただし電波の到達距離は何とも言えないので屋内飛行用と考えておいて下さい。

zubon2003さんの多大なる貢献により以下の問題が解決された”FPVTrackside 2.77.3.889.dmg”が公開されました。おそらくMac版もこれで完璧です。ダウンロードは以下のページから。
https://fpvtrackside.com/download

FPVTrackside Mac版(v2.77.1.877)で確認している問題点は二つあります。使用方法によっては致命的とも言えます。併せて回避策も示しておきます。問題が整理でき、あるいはコードフィックスの目処がつけば開発者にフィードバックする予定です。将来のバージョンでは問題が解決するものと思います。

(2026/08/08) zubon2003さんにより2点とも修正が提出されています。将来のバージョンに取り入れられるものと思います。

[ ディレクトリ問題 ]
https://github.com/uewepuep/FPVTracksideCore/pull/72 ブルリクエストはすでに本体にマージ済みです。

FPVTracksideの様々なデータはWindowsにおいてはユーザーの”AppData\Local\FPVTrackside\”下に集約されています。
macOS版でも”~/Documents/FPVTrackside”(ユーザーの書類フォルダー)と言うフォルダーが作成され、そこにデータを置くような設計になっているようです。ところがいくつかのデータはアプリケーションバンドル内のMacOS下を参照しています。


アプリレーションバンドルの中身はアプリケーションファイルを右クリックして「パッケージ内容の表示」で開くことが出来ます。

どのデータがアプリケーションバンドル内を参照しているのかは、追いきれていませんが、以下の二つは確実です。

< events >

レースイベントの全てに関わるデータがアプリケーション内のMacOS/eventsに保管されます。レースの実施にはおそらく大きな問題はありません。問題となるのはFPVTracksideを更新、あるいは同じバージョンであっても再インストールを行うとデータが失われてしまうことです。
もしデータを失いたくない場合は自力でeventsディレクトリーをどこかに保存しておく必要があります。

< pilots >
pilotsフォルダーはパイロットの写真や動画を保存する場所です。FPVTracksideは最初の起動時にpilotsフォルダーを作成します。実際に”~/Documents/FPVTrackside/pilots”を作成しています。ところがFPVTracksideがpilotsフォルダーの操作を行う時にはアプリケーションバンドル内のMacOS/pilotsを参照します。しかしこのフォルダーは作成されていません。そのため様々な問題が発生します。

とりあえずMacOS下に自分でpilotsフォルダーを作成すればパイロットの写真機能を使用することは出来ます。

[ macOSの濁点問題 ]
https://github.com/uewepuep/FPVTracksideCore/pull/75
プルリクエストが提出されました。-> あっという間にマージされました。

ファィル名に濁点と半濁点が含まれていると発生する問題です。NFC/NFD問題とも言います。簡単に説明します。NFDとNFCと言う異なる文字表現があります。NFDでは濁点などを独立した文字としてあつかいます。NFCは濁点付きの一つの文字として表します。例えば「が」はNFDでは2文字、NFCでは1文字になります。日本語だけではなく西欧の文字列にもわずかですが同様の文字が存在するそうです。

macOSではファイル名をNFDで作成します。ところが一般的にプログラム内部ではNFCを期待しています。macOSでプログラムが濁点の含まれるファイル名を単純に読み込むと濁点が独立した文字(NFD)になってしまいます。それをそのまま画面に表示すると濁点、半濁点がやや離れたところに表示される奇妙な状態になります。また、プログラム内部でNFCで管理されている文字列とファイルシステムから得られたNFD文字列は一致しないため、意味としては同じだったはずのものが別のものになってしまいます。macOSの仕様が何故このようになっているのか理解に苦しむところでもあります。

FPVTracsideにおいてはパイロット名と上記のpilotsフォルダーに保管したパイロットの写真の間でこの問題が発生します。

シナリオは幾つかありますが、ここではmars.fpv@YAMAGATAさんのFPVパイロット一覧のデータを使ってテストしてみます。
– FPVTrackside用ZIPをダウンロードします。
– ZIPを展開した中にあるアイコンファイル(拡張子png)を上の方で作成したアプリケーション内のMacOS/pilotsフォルダーにコピーします。
– FPVTracksideを起動しイベント画面でパイロットのインポートを行います。

「プロフィール画像ファイルからインポート」を行います。
– これで先にコピーした画像ファイル名をパイロットの名前として使用できるようになります。

パイロットの写真があればパイロット名リストが簡単にインポート出来るとても便利な機能です。が、コザックとドローン部長だけちょっと名前が見づらいです。これはWTW四国のメンバーであることが原因ではありません。これこそがNFD問題です。ちなみにmacOSのファインダー上では普通に見えます。
– 名前が見づらくても良いのであればこのままでも動きます。

やはりカッコよくないです。それにパイロット名を別の方法でインポートしてあった場合にはパイロット名が一致しなくなります。

本来の解決策はFPVTrascksideの中でNFDからNFCに変換する”nfc normalization”と言う処理を行うことです。それが実現されるまでの間はファイルシステム上でnfc化することも可能です。ただし古いHFS+ファイルシステムだとうまく行かないようです。

nfc化を行うnfd2nfcと言うPythonスクリプトを作りました。

これを使うとファイルシステム上でnfc化することが出来ます。

インポートをやり直しました。やはり、こちらの方が良いでしょう。

FPVTrackSide Mac版でやっとArUcoが動くようになりました。

ArUcoとはTinyViewPlusでお馴染みのARマーカーのことです。zubon2003さんがFPTracksideのレースタイミングとして組み込みを行い、Windows版ではv2.75.0から使えます。しかしMac版はなかなか動きませんでした。私の手元でMacでも何とか動くようにし、それをzubon2003に手伝ってもらい開発者にフィードバックしたものが、かなりの時間を経てやっと(ちゃんと動くものが)リリースされました。

https://fpvtrackside.com/download
私がテストしたのは”FPVTrackside 2.77.1.877.dmg”です。

ただし、Mac版にはまだ別の問題があります。これについては次の記事「FPVTracside Mac版の問題点(2026/07/30現在)」に書きました。とりあえず、FPVTrackside初心者の私がARマーカーでタイムが測れると確認した道のりを書いておきます。

[ インストール ]
導入は一般的なmacOSのアプリケーションと同じです。dmgファイルを開き、FPVTracksideのアイコンをApplicationsにコピーします。
ひとつ前のバージョンくらいからは正しく署名がなされていますのでxattrのおまじないは必要ありません。最初の起動時には下のポップアップが出ますので「開く」をクリックします。

最初の画面です。

[ チャネルの設定 ]

Channel Settingsを開くと何かしらチャネルが設定されているので不要なものをRemoveして必要なものをAddします。

[ ビデオ入力 ]

Video Settingsを開き、映像入力をAddします。私の場合はUSB3 Videoと言うHDMI/USB-C変換器を追加しました。

Video Modeはそれなりに適切なものを選択します。私の使ったビデオ入力は4チャネルを一つのHDMIに集約したものなのでChannel Splitsを”2 x 2″にしました。あらかじめチャネルを設定していたので自動的に各画像とチャネルは自動的に一致しました。もし違う場合は画像の上で右クリックすると変更出来ます。

[ ArUcoを設定する ]

Timing Settingsを開きAddメニューから”ArUco (Video Marker)を選択します。

Marker IDsに必要なものを指定します。マーカーのIDが分からない場合、とりあえずのテストならば”0,1,2,3″でだいたい大丈夫でしょう。

[ イベントの作成 ]

最初の画面でContinueを押します。

規定値のEvent設定が開きます。とりあえずテストなので、そのままOpenしました。

[ パイロットの追加 ]

左の方の空いているところで右クリックをしてAdd Pilotで名前を入れます。とりあえずは英字のパイロット名にしてください。

[ ラウンド ]

上の方にあるRoundsをクリックするとラウンドが開きます。ラウンドの内部で右クリックしてAdd Raceを行います。

[ レース ]

レースのチャネル部分に左のパイロットをドロップします。Race 1-1などと表示されている部分をクリックするとレース画面になります。そして右下のStartをクリックしてレースを開始します。

マーカーを見せるとちゃんとゴールゲートとして認識されました。マーカーの写真はいつもYuzuiroさんのブログを無断使用させていただいています　m(_ _)m

[ 日本語 ]
テスト優先で最後になってしまいましたが日本語にすることもできます。

右上にある3本線のアイコンをクリックしてメニューからApplication Settingsを開きます。一番上のLanguageでJapaneseを選択しOKを押します。ポップアップメニューからFPVTrackseideのリスタートを行います。

「VTXアンテナのSWRを測定してみる」の続きです。
UFLコネクターへの変換アダプターが入手出来たの手持ちのタイニーで使用しているアンテナをLite VNA 64で測定してみました。アダプター自体の影響も大きいかも知れないので数値の信憑性はなんとも言えません。

それぞれ一つのアンテナしかテストしていないので、もしかするとハズレの個体を測定している可能性もあります。

BETAFPVのMatrix 1S G4 5IN1 V2に付属していたアンテナです。新品です。5.85GHz以下ではSWR 2.0以下なのでまあまあな感じ。

BETAFPVのちょっと前のAirに付属していたアンテナです。機体から外したもの。先っぽ触るとビリッとする感じのあるやつです。上のものよりちょっと悪いです。

HummingBird V3 AIO(やや古い)付属のアンテナです。新品。今ひとつ。

HummingBird V3.1 RaceSpecから取り外したもの。接触の問題かも知れないけどかなり大きなSWRを示している。ちょっと使いたくないレベル。

タイニーのアンテナだし良い数値を期待するのは無理かも、以上。で、終わりにしようと思っていました。大事なやつを忘れていました。

最後にTBS Unity Pro32 Nanoに付属しているアンテナ。新品。めちゃくちゃ良い数値です。完全にSWR 1.5以下です。TBS流石としか言いようがない。

「タイニー用アンテナのSWR測定」も行っています。

部長のところからやってきたLiteVNA 64を押入れの奥から引っ張り出してきました。コンパクトな機器ですが6GHzまで対応している多機能なネットワークアナライザーです。私がこれを持っている理由はただ一つでSWRの計測です。

SWRは日本語では定在波比と言います。日本語になっても全く意味が想像出来ませんね。ざっくり言うと、電波を発射しようとアンテナに電力を送り出した時に、少しだけ電力が逆流してきます(透明なガラスに光を当てると少しだけ反射するかのようなイメージ)。それを数値化したものがSWRです。

理想的な数値は1.0でアンテナに送った電力が全てアンテナで消費されることを示します(SWRでは電波になったのかどうかは分からないです。もしかするとアンテナの近くで熱になっているのかもしれない)。一般的に言えば1.5以下なら合格。2.0以下ならまあまあ大丈夫と言う感じです。もし2.0だと11.1%の電力が戻ってきています。戻ってきた電力はVTXの中で熱に変わると思われます。あまりにSWRが大きいと最悪な場合ではVTXを壊すこともあるかもしれません。と言うことでSWRは小さい方が望ましいです。

[ LiteVNAの設定 ]
概ねOscar Liangさんの「How to Measure Antenna SWR with LiteVNA: A Comprehensive Guide」に従いました。キャリブレーションに関しては「Tinyネットアナ入門 LiteVNA 64のキャリブレーション」も参考になります。細かい操作方法は公式のドキュメントを読みました。

[ 測定してみた ]

手持ちの5.8GHzアンテナでSMAコネクターの付いたものを測定してみました。優秀なものから順に紹介します。

古いTBS(Team-BalckSheep)のStubです。かなり優秀です。どのアンテナにも言えますが個体によって少し違いますが、平均的なSWR値は変わりません。

黄色の線がSWR値のグラフです。横軸が周波数で5.6GHzから6GHzになっています。縦軸がSWRで右側にSWRの数値が表示されています。緑色の線はインピーダンスを表す何か(^^)です。

TBS Triumph、TBS流石としか言いようがない。

TBS TriumphにL字型のコネクターを追加したもの。少し特性が悪くなりますが問題はないレベル。L字型コネクターも他のものと交換して試すべきだったかもしれないです。

EMAX Pagoda-2のとても古いもの。クラッシュしてボロボロだけど数値は良い。

EMAX Pagoda-3Bもまあまあ悪くない。特に日本で使用される周波数では1.5以下になっている。

ところが同じEMAX Pagoda-3Bでも使い古してコネクターが変色している(それが原因か元々の個体差かは不明だけど)はやや悪い。

ImmersionRCのパッチアンテナ。定評がある人気のパッチ、さすがに良い感じです。硬くて外せなかったのでL字コネクターを付けた状態での測定です。

FOXEER ORERO、優秀です。これも斜めにするコネクターを付けた状態です。確かSAITOさんがWorld Games 2022へ参加するときのクラウドファンディングに協力した時の返礼品で、全くの未使用。

優秀な謎アンテナ。どこから来たものか不明。

ここからは即ゴミ箱行きシリーズ

EMAX Nano、これは小さいのが魅力で購入したもののあまりに電波が悪くてすぐに使わなくなったものです。完全に数値に表れていますね。

RUSH Cherry、期待を裏切られた感大きい。とても綺麗な作りで値段もそこそこ高かった気がする。長さ違いで2本ありますが、どちらも同じくらいの成績。

「無課金おじさんBetaflight-MCPを使う」の続きです。

Betaflight-MCPはAIとBetaflight Configuratorを接続する仕組みでした。そのBetaflight-MCPに同梱されているbb-tune-dekstop.zipはPIDチューニングするためのスキルです。その中身はログファイルを解析するPythonのプログラムとAIに対してチューニング手法を指示するための文章です。

opencodeに対してこのスキルを使えるようにしてと頼んでみました。


一見、ちゃんと出来たように見えましたが、opencodeを再立ち上げするとスキルの定義でエラーが発生しました。

導入ディレクトリー下の”.opencode/opencode.jsonc”というファイルの単純な書き間違いでした。この辺りはローカルLLMの能力の限界によるものです。もう一度頼んだりすれば直るでしょうが、簡単なことなので手で直しました。
正しい内容を下に書いておきます。

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "betaflight": {
      "type": "local",
      "command": ["node", "server/server.js"]
    }
  },
  "skills": {
    "paths": [".opencode/skills/bb-tune"]
  }
}

実際にドローンを接続してBlackBoxログを解析してみるとことにします。そのままでも大丈夫ですが、私はblackbox_decodeというプログラムを持っていましたので、それを使うようにSKILL.mdを少しだけ修正しました。

準備したのはわざとPIDを狂わせた65機を飛行させたものです。step responseを見ると次のような感じです。

このドローンをBetaflight-MCPに接続してopencodeでログの解析をお願いしました。自動的にログがダウンロードされ解析が始まりました。これはなかなか新しいです。

解析結果に基づいて対策が提案されます。このまま進めると提案されたPID値を機体に書き込んで、飛行テストに進むという流れです。

実際は全てのPIDを低くしたのですが、step responseを見ると分かるようにyawがかなり悪い状態です。そこはちゃんと指摘されましたが、推奨されたのはより小さなPI値でした。これは方向性が明らかに違うので、ここまでにしました。もしかするとClaude Desktopで行えば多少違うかもしれませんが、基本的にはSKILL.mdに記述された内容に従っているのだと思います。

自分でチューニングの評価をしながらSKILL.mdを更新していく仕組みが作れれば、基本的な枠組みはこのままで進化していく可能性もあります。