普通的生活

以前の記事「Rasbberry Pi AI Kit用に画像認識モデルを作る」に従い、Hailoソフトウェア群をUbuntu環境で再構築し、モデル変換の準備をしようと試みましたが、いくつかの問題に直面し、構築を断念しました。主な問題は、hailo_model_zooの適切なバージョン（dataflow compiler 3.29.0に対応するもの）をインストールできないことでした。当時、GitHubから最新版をクローンしていましたが、タグ指定で過去のバージョンをダウンロードしてもうまくいかず、クローン後に適切なコミットに巻き戻す必要があるようでした。

そこで、手動での構築を試みるよりも、配布されているDockerイメージを利用することにしました。

https://hailo.ai/developer-zone/software-downloads/

Hailo AI Software Suite – Docker のVersion 2024-10を使用しました。最新版は、既に構築済みのRaspberry Pi+AI Kit環境との互換性がありません。

導入に使用したPCは、古いIntel NUCで、メモリは16GBです。OSはUbuntu 22.04.4 LTSにDockerをインストールしています。

ダウンロードしたzipファイルには、Dockerイメージと起動スクリプトが含まれています。このスクリプトを実行することでDockerが起動します（二度目の起動には–resumeオプションが必要です）。

./hailo_ai_sw_suite_docker_run.sh
推奨メモリが32GBであることやGPUがないといった注意書きはありますが、問題なく起動しました。

hailo -h と hailomz -h でプログラムが動作することを確認できました。

その後は、以前の記事とほぼ同じ手順で進めます。

まず、COCOデータベースを導入します。

cd hailo_model_zoo
python hailo_model_zoo/datasets/create_coco_tfrrecord.py val2017
python hailo_model_zoo/datasets/create_coco_tfrrecord.py calib2017

次に、フォルダーの修正が必要です。

cd /local/shared_with_docker/.hailomz/models_files/coco/
ln -s 2023-08-03 2021-06-18

実環境とのデータ連携は、shared_with_dockerフォルダーで行います。

最後に、以下のコマンドを実行するだけで、モデル変換が完了します。

hailomz parse --hw-arch hailo8l --ckpst ./best.onnx yolov10s
hailomz optimize --hw-arch hailo8l --har ./yoolov10s.har yolov10s
hailomz compile yolov10s --hw-arch hailo8l --har ./yoolov10s.har

日本でのロングレンジ飛行は一般的ではありませんが、より遠距離での飛行や電波環境が不安定な状況での飛行を安全に行うための設定例を紹介します。実際に屋外でやや距離を出しても、通常の設定(500Hz, 100mW)でも信号強度は常に安定しており、通信品質に問題はありませんでした。よってELRS設定は過度に気にする必要はありませんが、より安全な飛行のために参考にしていただければと思います。

内容的にはOscar Liang氏のブログを参考にしたものになります。
https://oscarliang.com/lq-rssi/

[ ELRSの設定 ]
– パケットレート: 250Hz

通常は500Hzを使用していますが、屋外での安定性を高めるため、パケットレートを下げて感度限界を下げる設定に変更しました。出力は最大に設定します。

[ OSDの表示設定 ]

– リンク品質

– RSSI値(dBm)

ExpressLRSの通信状態を監視するには、この2つの指標を同時に表示することが重要です。

RSSI値は信号強度を示します。ExpressLRSの公式ページでは、パケットレートごとの許容信号強度が公開されています。
https://www.expresslrs.org/info/signal-health/#rf-mode-indexes-rfmd
ExpressLRS Luaスクリプトでパケットレートを選択する画面にもこれは表示されます。

250Hzを選択した場合、感度限界は-108dBmです。飛行中はこの値を下回らないように注意が必要です。

リンク品質の表示について：
– 左側の数値：現在のパケットレート
– 右側の数値：有効パケットレート（通常100%）

有効パケットレートが80%を下回る場合は、通信状態の悪化が考えられるため注意が必要です。

[ OSD Warningの設定 ]
以下の警告を設定することをお勧めします：
– RSSIが-98dBm以下 (250Hzの感度限界-108dBmに対し-10dBmのマージンを持たせた設定)
– リンク品質: 60%

OSD画面で警告にチェックを付けます。

以下のCLIを投入します。

set osd_link_quality_alarm = 60
set osd_rssi_dbm_alarm = -98
save

[ EdgeTXのテレメトリアラーム設定 ]

この設定はオプションです。

これらの設定により、安全なセミロングレンジ飛行が可能になります。特にRSSIの監視は重要で、通信状態の悪化を早期に検知できます。

FPVドローンのVTXチャネルを変更する際、通常はOSDメニューやLUAスクリプトを使用しますが、その手順は少し複雑です。
この記事では、プロポのスイッチを使って、VTXチャネルの切り替えを簡単にする方法を説明します。

S1を回してVTXチャネル変更できるようにした。LEDの色はE1で赤、F1で緑、F4で青に設定しています。S1を左端でE1、中央でF1、右端でF4になります。モニターはF4で映ります。 pic.twitter.com/mu7gsyZj71

— コザック KozakFPV 空の自由人 (@nkozawa) May 5, 2025

[ プロポスイッチを使う利点 ]

1. OSD/LUAスクリプトの問題点
   OSDメニューやLUAスクリプトでの変更は手間がかかります。
2. プロポスイッチの長所
   スイッチの位置で直接チャネルが切り替わるため、直感的で素早い操作が可能です。
3. スイッチの選び方
   日本では現在E1、F1、F4の3チャネルが使用可能です。そのため、3ポジションスイッチが適していますが、誤操作を防ぐためにS1のポットを使用することにしました。(一度アームした後は変更出来なくなるようなので誤動作の心配はあまり必要ないかもです)

[ 設定手順（プロポ側）]

1. スイッチの受信機割り当ての確認
   a. Betaflight ConfiguratorのReceiverタブでS1が受信機のAUXチャネルに割り当てられているか確認します。
   b. 未設定の場合、MIXESを使ってスイッチをAUXチャネルに割り当てます。
   手順例（プロポによって異なる場合があります）:
   – MIXESメニューを開きます。
   – 空いているCHを選び、Source をS1、Weight を100%に設定します。



2. LUA Script（ExpressLRSなど）からVTXの変更機能を無効にします。

[ 設定手順（Betaflight側）]

1. S1の動作確認
   Receiverタブで、S1の動作範囲、方向、AUX番号を確認します。
   例：AUX7、動作範囲は左端1000、中央1500、右端2000
2. VTX設定の確認
   Betaflightの Configuration > VTXタブで現在の設定を確認します。



3. CLIタブで以下のようなコマンドを入力します：

   vtx 0 6 3 1 1 900 1200
   vtx 1 6 4 1 1 1300 1700
   vtx 2 6 4 4 1 1800 2100
   

   コマンドの形式：
   vtx [設定番号] [AUX] [バンド] [チャネル] [パワー] [AUX値下限] [AUX値上限]
   – 設定番号：0から始まる連番
   – AUX：AUX番号から1を引いた値（例：AUX7なら6）
   – バンド：3=BOSCOM_E, 4=FATSHARK
   – チャネル：VTXテーブルのチャネル番号
   – パワー：1=25mW
   – AUX値：プロポのスイッチ位置に対応する値の範囲

   この設定により、S1の位置に応じてVTXチャネルが以下のように切り替わります：
   – 左端：E1チャネル
   – 中央：F1チャネル
   – 右端：F4チャネル

これで、プロポのS1スイッチを操作するだけで、簡単にVTXチャネルを切り替えることができます。

昨年のNaka Drone Racing 2024以来育ててきたGoogle Sheetによるレース集計システムを紹介します。まだまだ未完成ですが、いくつかのレースを経て役に立つものになりつつあります。またTinyViewPlus v0.9.33 beta6の通知機能を利用しリアルタイムな更新も可能となりました。

その概要とプログラム全てを公開いたします。使い方や細かい動作までは説明しきれないので、勝手に参考にしてもらったり、使える部分は再利用をしてください。という放任主義です、悪しからず。

[ システムの概要 ]
WTW Tokushimaのドローン部長による場内PAおよび配信システムの一部であるTinyViewPlusと集計操作用のMacBook Airを連携して行います。

流行っているのでChatGPTに書いてもらった絵です。何となくな感じであまり正確にシステムを表現しているとは言えません。

[ oscrcv.py ]
oscrcv.pyスクリプトはTinyViewPlusからのOSCプロトコルによる通知で受信したデータをGoogle SheetにPOSTします。データの受信を確実にするためにoscrcv.pyはTinyViewPlusが稼働しているWindows PC上で稼働するようにしています。また予選、決勝などのレース毎(あるいはGoogle Sheetの切り替え)にoscrcv.pyの起動パラメータを指定して立ち上げ直す必要がありますので、MacBook AirからsshでTinyViewPlusのPCにログインして行なっています。

# oscrcv.py
import argparse
import math
from pythonosc import dispatcher
from pythonosc import osc_server
import json
import requests
import time
import datetime

url = ""
url1 = "https://script.google.com/macros/s/AKfycbzDg0hHdgDlE_qYEngvYBBqYDummyssJ_sA_fmstVcXgyyx-KMem32_lbSoC8gdAhgg/exec"
url2 = "https://script.google.com/macros/s/AKfycbw7_T9Z4eWVWbybGm2IhXsazDummyRVwOjrQ_OcuowXC2yV-onDk0ppOxefZdZNQHQh/exec"

sheetname = ""
sh1 = "練習"
sh2 = "予選ヒート1,2"
sh3 = "予選ヒート3,4"
sh4 = "勝ち上がり戦入力"

def timeformat(seconds):
    td = datetime.timedelta(seconds=seconds)
    minutes, seconds = divmod(td.total_seconds(), 60)
    return f"{int(minutes):02d}:{seconds:05.2f}"

def oschandle(addr, *args):
    global url
    global sheetname
    print(addr)
    print(args[0])
    print("")
    timestamp = time.strftime('%Y/%m/%d %H:%M:%S')

    args3 = args4 = ""
    if (len(args) > 3):
        if (isinstance(args[3], float)):
            args3 =  "{:05.2f}".format(args[3])
        else:
            args3 =  args[3]
    if (len(args) > 4):
        if (isinstance(args[4], float)):
            args4 =  timeformat(args[4])
        else:
            args4 =  args[4]

    data = {
        "timestamp" : timestamp,
	    "addr" : addr,
	    "arg0" : args[0],
        "arg1" : args[1] if (len(args) > 1) else "",
        "arg2" : args[2] if (len(args) > 2) else "",
        "arg3" : args3,
        "arg4" : args4,
        "sheetName" : sheetname
    }

    print(json.dumps(data))
    # json.dumpでデータをJSON形式として扱う
    r = requests.post(url, data=json.dumps(data))
    print(r)

if __name__ == "__main__":
    parser = argparse.ArgumentParser()
    parser.add_argument("--ip",
                        default="", help="The ip to listen on")
    parser.add_argument("--port",
                        type=int, default=4001, help="The port to listen on")
    parser.add_argument("--url",
                        default="1", help="1 = Sprint, 2 = Endurance")
    parser.add_argument("--sheet",
                        default="1", help="1 = 練習, 2 = 予選ヒート1,2, 3 = 予選ヒート3,4, 4 = 勝ち上がり戦入力")
    args = parser.parse_args()

    if (args.url == "1"):
        url = url1
    else:
        url = url2

    if (args.sheet == "1"):
        sheetname = sh1
    elif (args.sheet == "2"):
        sheetname = sh2
    elif (args.sheet == "3"):
        sheetname = sh3
    else:
        sheetname = sh4

    print("URL: ", args.url)
    print("Sheetname: ", sheetname)

    dispatcher = dispatcher.Dispatcher()
    dispatcher.map("/*", oschandle)

    server = osc_server.ThreadingOSCUDPServer(
        (args.ip, args.port), dispatcher)
    print("Serving on {}".format(server.server_address))
    server.serve_forever()

[ Google Sheetでの処理 ]
oscrcv.pyからのPOSTはGASで受信します。送られてくるデータは2種類あります、一つはLapデータでリアルタイムなレース状況の更新に使います。

TinyViewPlus v0.9.33 beta5でラップの削除も通知されるようになったのでテスト。 pic.twitter.com/DRfXIqs2Lr

— コザック KozakFPV 空の自由人 (@nkozawa) February 20, 2025

もう一つはレース結果で、レースの集計に使います。

TinyViewPlus がレース結果を送信してくれるようになりました。UDPなので取りこぼしも考慮して、従来通り結果ファイルを見るかクリップボードを見る準備も必要。 pic.twitter.com/PxdglMhXl3

— コザック KozakFPV 空の自由人 (@nkozawa) March 2, 2025

集計作業は結果入力シートにデータを集積し集計プログラムシートにあるボタンからGASを起動して順位を別のシートに記入します。詳細は書きませんが、勝ち上がり戦の組み合わせまでは自動で行います。勝ち上がり戦の集計以降は手作業で行なっています。
予選の順位は周回数が多い方を上位とします。同一周回数の場合は合計時間が短い方が上位となります。全く同じ成績であった場合の処理は入っていませんのでデータの目視確認が必要となります。

WTWShikokuDroneRaceWorksheet
このワークシートはRead Onlyで共用しています。ご自身のGoogl DriveにコピーするとGASの内容も読めるようになります。

TinyViewPlus->Python Script->Google Sheetへの連携の詳細は別記事「Tiny View Plusの外部通知機能を試す」に書いていますので参照願います。

[ ディスク共用 ]
OSCのデータによる集計に問題があった時のためにTinyViewPlusのResultフォルダーをMacBook Airからアクセスできるように共用しています。Google SheetのGASは集計データのファイルからの読み込みにも対応しています。この部分はninjaMoonLightさんが書かれたものです。

[ TinyView Plusのバイロット名 ]
集計作業とは別ですがWindows上のTinyView Plusのカメララベル(パイロット名)のセットもMacBook Airから行なっています。使用しているプログラムはGithubにて公開しています。
https://github.com/nkozawa/tvpilotnames

以上です。まだ完全自動とは言えませんが、そこそこ役に立つものになりました。また進歩があれば何かの形で公開したいと思います。

メモリーたっぷりのMac Miniと普通のAirの比較です。M2とM4で処理速度はいくらかは違いますが、それよりもメモリーサイズが重要であることを実際に確認してみた記録です。テストに使用したのはMacBook Air M2 16GBモデルとMac Mini M4 32GBモデルです。Python関連のバージョンは少し異なりますが、スクリプトは同じで画像認識モデルの作成はUltralytics YOLOv10を使いました。

画像認識モデルの生成で重要なのはVRAMサイズです。より重いモデルの生成には、より大きなVRAMが必要となります。Apple Siliconは単一のメモリーの一部をGPUが使用するVRAMとして必要に応じて割り当てるので、柔軟な対応が可能です。

テスト用に用意したのはイメージファイルを57個でラベル数は2です。これに対しYOLOv10の異なるモデルで作成を行いました。epochは20です。

– M2よりM4は少し速い。
– 16GBのMacBook Airでは軽量モデルであるYOLOv10nとYOLOV10sしか生成できなかった。
– 最重量モデルYOLOv10xでは32GBのほとんどがVRAMとして使われていた。
– 実際のモデル生成ではepochs=200以上を指定するので重いモデルのYOLOv10lとYOLOv10xの生成は実用的とは言えない。

YOLOv10bまではMac Miniでモデル生成が出来るのは大きな収穫です。それより重いモデルの生成はやはりGoogle Colabを使用するしかありません。それも無料で使えるGPUではVRAMサイズが足りずYOLOv10lとYOLOv10xの生成には有料(安いです)のGPU A100などを使用します。その重いモデルもテスト的にMac Miniで生成できるのはとてもありがたいことです。

[ おまけ ]
動画ファイルに対する画像認識の速度テストも行いました。使用した動画は720×480 60FPSのものです。モデルはYOLOv10sを使用しています。自前のスクリプトで計算したところ、MacBook Airではばらつきがありますが18FPSから20FPSくらいでした。Mac Miniは少しだけ速く22FPSから23FPSでした。どちらも実時間にはだいぶ足りない状態でした。

Tiny View Plus v0.9.33より外部への通知機能が搭載されました。この機能はWTW香川からのリクエストに作者の浅野さんが答えてくださったものです。本来の目的はラップ毎にLEDを点灯させるなどのレースの演出に使うことでした。

通知のされるのはレースの開始、終了、ラップなどです。詳細はドキュメントをご覧ください。
ラップの通知にはラップ数とタイムの情報も含まれているので、これを利用して集計も出来そうなのでテストをしています。

テストの様子です。右側のラップ数をグラフ的に表示するアイデアはninjaMoonLightさんから頂きました。

TinyViewPlus v0.9.33、現在はbetaですが、イベントやラップの情報を外部に通知される様なりました。ラップ毎にLEDを光らせたり、自動集計システムが作れそうです。MacOSで情報を受けてGoogle Sheetに反映させるテストを行なっているところです。(タイムの数値欄は間違ってるので無視してください^_^) pic.twitter.com/xS4KHCaGm3

— コザック KozakFPV (@nkozawa) January 14, 2025

[ 私のテスト環境においての情報の流れ ]
– Windows上のTinyViewPlusからOSCプロトコルで通知を発信。
– macOS上のPythonで受信し、データをGoogle SheetにPOSTする。
– Google ScriptでPOSTを受けてSheetに書き込む。

ここでは、一番基本となる部分だけを紹介します。

[ Google Sheet側の設定 ]
– Googleドライブで新規のスプレッドシートを作ります。
– “拡張機能”から”Apps Script”を開きます。
– スクリプトは以下のようになります。

const spredSheet = SpreadsheetApp.getActiveSpreadsheet();
const sheet = spredSheet.getSheetByName('シート1');

function doPost(e) {
  var data = JSON.parse(e.postData.getDataAsString());
  sheet.appendRow([data.timestamp, data.addr, data.arg0, data.arg1, data.arg2]);
}

– 左側のメニューの”サービス”で”Google Sheets API”を追加します。

– 上の方にある”デプロイ”から”新しいデプロイ”を実行します。種類の選択は”ウェブアプリ”にします。アクセスできるユーザーを全員にしておきます。

– デプロイ時にアクセスの確認が出ます。”アクセスの承認”を押します。
後は、いつもの手順ですが、少々ややこしいです。画面の流れだけ示しておきます。

アカウントを選択

Advanced(詳細)をクリック

Goto [プロジェクト名]をクリック

Allowをクリック

– 完了するとウェブアプリのURLが払い出されますのでコピーしておきます。URLを知る人は誰でもPOST出来るので注意が必要です。

– スクリプトを変更した時は、”デプロイを管理”からバージョンを更新します。URLは変わりません。

[ パソコン側の設定 ]
Python3が動けば、どんなパソコンでも大丈夫なはずです。
OSCのためのライブラリーが必要です。
pip install python-osc
プログラムは以下の通りです。url=のところに先にコピーしたウェブアプリのURLを入れます。

from pythonosc import dispatcher
from pythonosc import osc_server

import json
import requests
import time

url = "https://script.google.com/macros/s/xxxxx/exec"
ip = ""
port = 4001

def oschandle(addr, *args):
  print(addr)
  print(*args)
  timestamp = time.strftime('%Y/%m/%d %H:%M:%S')

  data = {
    "timestamp" : timestamp,
    "addr" : addr,
    "arg0" : args[0],
    "arg1" : args[1] if (len(args) > 1) else "",
    "arg2" : args[2] if (len(args) > 2) else ""
  }
  r = requests.post(url, data=json.dumps(data))
  print(r)

if __name__ == "__main__":

  dispatcher = dispatcher.Dispatcher()
  dispatcher.map("/*", oschandle)

  server = osc_server.ThreadingOSCUDPServer((ip, port), dispatcher)
  print("Serving on {}".format(server.server_address))
  server.serve_forever()

[ Tiny View Plusの設定 ]
最新のTiny View Plusを導入します。記事を作成時の最新版はv0.9.33-beta3です。
ドキュメントに書かれているように一度Tiny View Plusを起動後に作成されるdata/settings.xmlを編集してOSC通知の送信先IP Addressを変更します。

<oscMonitor>
    <enabled>1</enabled>
    <host>192.168.1.255</host>
    <port>4001</port>
</oscMonitor>

IP Addressは私はサブネットに対するブロードキャストにしました。受信するパソコンのIP Addressを指定すべきかも知れませんが、サブネット内の複数の機器で同時に情報を受信できることを狙ってブロードキャストIP Addressを試しています。
IP Addressの設定後にTiny View Plusを起動します。

これで準備完了です。Pythonのプログラムを起動し、Tiny View Plusでレースの開始やラップを記録し、データがGoogleシートに記録されれば成功です。ここまでくれば後は、ゴリゴリとGASを書いていけば集計作業の省力化が可能と思います。ただしOSCはUDPで送られてきますので、データが必ず受信されるとは限りませんのでデータが欠損した場合のことは考慮しておく必要があります。また、OSの実装にもよると思いますがデータの処理される順序が入れ替わることもありますので注意が必要です。

Newbeedrone Hummingbird V3.1 RaceSpecは箱だしで16g台の軽さとその重量の軽さ以上に感じられる軽快な飛びでレーサーの期待を集めています。

[ LED Strip設定 ]
マッドさんが最初の頃にFC上のLED_StripがどこであるかをXで公表されていました。その時はRGB LEDをそこに接続するだけで使えていたそうです。ところが私の購入した機体およびファームウェア(betaflight_4.5.0_HUMMINGBIRD_RS_7498f3807_KAACK_Oct252024.hex)ではLEDとしての動作をさせることとができませんでした。調べてみるとLED_Stripのリソースが割り当てられていませんでした。そこで回答です。

Hummingbird V3.1 RSのFCのこの黄色のパッドでLED_Stripの信号が取れます(たぶん、マッドさんが前に指摘していた)。ただし、それだけではLEDが機能しませんでした。CLIで以下のコマンドの投入が必要でした。

resource LED_STRIP 1 B01
timer B01 AF2
dma pin B01 0 pic.twitter.com/NKGADaJ6Gd

— コザック KozakFPV (@nkozawa) December 29, 2024

左の写真で黄色いリード線を接続しているところがLED_Stripになります。そしてリソース関係の設定は以下のコマンドをCLIに投入します。

resource LED_STRIP 1 B01
timer B01 AF2
dma pin B01 0

LEDの数は32灯までです。
余談ですが、HummingBird V3 FCにはFC上に4灯のLEDが載っていました。

RaceSpecではこのLEDチップが取り付けられていません。そのランドを利用して外付けのRGB LEDを取り付けることにしたのです。またメーカーとしてはLEDチップを外したのでリソースからLED_Stripを削除したのは正しいことだと言えます。

[ USBコネクター ]
USBコネクターがもげてしまったと言う話しを聞きました。

Hummingbird V3.1 RaceSpec のUSBコネクターが外れやすいとのこと。基板を見るとコネクターの足がスルーホールに刺さっているだけでハンダ付けされていない。電源ピッグテールをBT2.0に交換するついてにハンダを流し込んでみた。これで丈夫になるかな。 pic.twitter.com/a7QEDjjNsS

— コザック KozakFPV (@nkozawa) December 27, 2024

上の投稿の通りでUSBコネクターのハウジングの足がFC基板のスルーホールに刺さっているだけで半田付けされていません。半田を流し込んでみました。おそらく、これで丈夫になると思います。

[ PID ]
色々な人の意見を総合するとメーカー設定のPIDは正しく出ていない気もします。ただしBlackboxログが取れないので数値での検証は出来ません。またフレームも極端に柔らかいことも考えるとなかなか難しいです。私は別の65機で調整がうまくいったPIDを使用して様子を見るつもりです。

zoomセミナーアーカイブ

Blackbox解析ツール
https://blackbox.betaflight.com/
https://github.com/bw1129/PIDtoolbox

コザックのBFチューン講座の中で紹介するBlackBoxログデータです。リンクを右クリックして保存してください。

フィルター説明用データ:
https://www.nkozawa.com/blackbox/btfl_flt1.bbl – プロペラ破損
https://www.nkozawa.com/blackbox/btfl_flt2.bbl

PDバランス説明用データ:
PIスライダー0.50/0.55　https://www.nkozawa.com/blackbox/btfl_PI050055.bbl
PIスライダー1.30/1.35 https://www.nkozawa.com/blackbox/btfl_pi130135.bbl
PIスライダー1.60/1.65 https://www.nkozawa.com/blackbox/btfl_pi160165.bbl

スライド: https://www.docswell.com/s/6654543372/KJ48JM-2024-11-25-192028/1

PIDチューンを手持ちの機体全てに行うのは面倒です。機体スペックが同じならPID自体はおそらく同じで良いでしょう。と言うのは多くの人が同意すると思います。私自身は65サイズならフレームやモーター違っても同じPIDで済ませようと思っていました。

ところが、私がBetaFPV Air FrameでカリカリにチューンしたPID設定をWTW Shikoku会長のKanrekiさんがMobula6 2024に適用したら振動が出たとの報告をもらいました。その現象はPIスライダーを小さくしたら快適になったとのことです。これは対策として正しいものと思います。

と言うことで、私もBetaFPV Airフレームで調整したPID値をMobula6 2024フレームに適用してテストをしてみることにしました(FCとモーター、ペラはAirフレームと同じ)。結論を先に言ってしまうと、私のテストでは問題なし。むしろBetaFPV Airフレームより良い結果が出ました。フレーム差に加えて個体差が何かしらあるようですが、機体の特性は似ていると思います。やや緩めのPID設定にすれば65フレーム共通で良いのではないかと言うのが現在の結論です。

このテストが面白かったので、経過を書いて行きます。

[ フィルター設定 ]
いつも通りのフィルター設定でノイズを確認してみます。

普通に飛ばせますし、モーターの加熱もありませんが、Rollのジャイロ信号において200Hzより少し上のところに輝線が認められます。これは横軸のスロットルポジションに関係なく一定の周波数で機体が振動しているものをジャイロが捉えていることを示します。また左から二つ目のグラフにも現れていることからフィルターを通過してPIDループにもこの信号が入力されている事が分かります。

このまま放置しても問題は無いかも知れませんが、対策を施してみます。

これはBlackBox ExplorerでRollのフィルター後の信号を見たところです。これで輝線の中心周波数は219Hzだと言うことが分かります。PIDToolBoxのグラフとは違い横軸が周波数であることに注意してください。

対策として追加したのはジャイロノッチフィルター1です。中心周波数は先のデータに従い219Hzにしました。カットオフ周波数は勘で215Hzとしました。これの意味は215Hzから223Hzあたりの信号を取り除くと言う事です。

見事にノイズが除去されました。

他のMobula6 2024フレームでテストは行なっていないので、これがこのフレームに共通したものなのか、この個体の組み上げ方によるものなのかは分かりません。

[ PID設定はどうだろう ]
飛ばしてみると調子は良いので、大きな問題は無いだろうと思いつつログを調べてみました。

赤字の数値を見てもらうと分かるようにFF,I,D Maxの影響を排除して取得したデータで純粋にPDバランスを見ています。Pitchがほんの少しオーバーシュートしてはいますが、かなり綺麗なグラフになりました。

さらに普通に飛ばす時の設定でも、めちゃくちゃ綺麗なグラフになりました。多分、過去設定した中で一番綺麗です。

と言うことで個体差は考慮の必要はありますが、メーカーが違っても似たような65フレームであれば共通したPID設定が使えそうです。

前回、フィルターの設定が出来ました。いよいよPIDを設定していきます。

まず最初にBetaflight ConfiguratorをExpertモードにしておきます。(上の方に小さく書かれているやつです)

[ 基準値 倍率設定(Master multiplier)の決定 ]
最初に動的ダンピング(Dynamic Damping) D Maxを0にします。この状態で倍率設定(Master Mulitplier)を1より少し小さい値から0.05ずつ上げ、実際に飛ばしてみます。このステップは全くの体感で行います。細かい調整は後から行うので心配は要りません直感を信じて進めます。
倍率設定を上げていくとだんだん反応が良くなります。それがあるところを超えるとまた反応が悪くなったり、モーター音の異常、モーターの加熱が発生します。気持ち良く飛ばせる中で一番高い数値にしておきます。

私の場合は1.25に設定しました。

[ 動的アイドル値(Dynamic Idle) ]

動画中にある表を参考に設定します。65サイズが書いてないですし、プロペラのピッチによる設定値の幅が大きいので、大体のところで100にセットしてみました。

[ PDバランス ]
これからが本番です。最初に技術的な背景を簡単に紹介します。プロポのスティックを操作すると、それがFCで解釈されてYaw/Pitch/Rollのセットポイントという値が作り出させれます。これはその操作を行った時にジャイロが作り出す値の目標となる値です。FCは各モーターを動かしジャイロの出力がセットポイントを追従する様に制御します。その追従の具合を調整することがPIDチューニングです。

「動的ダンピング D Max」, 「スティックレスポンス FF」, 「ドリフト-ふらつき I」を全て0にします。
「トラッキング P&I強度」を0.5から0.05ずつ上げながら20秒ほど飛行しログを取ります。PIDtoolboxでStep Resp Toolで波形を見ます。オーバーシュートしない程度で素早く立ち上がるPの値をRollとPitchでそれぞれ記録します。

これはP&I=1.35にした時の状態です。Rollは良い値が出たところです。Pitchはややオーバーシュートしていますので、もう少し小さな値が良さそうです。
私は、RollはP&I=1.35, P=75、PitchはP&I=1.20, P=70を採用しました。
もし、この調整でスライダーが右端まで行ってしまった場合は最初の「基準値 倍率設定」の数値が足りていないのだと思われます。

「トラッキング P&I強度」スライダーでRollのP値を75にします。これは調べた時の値ですのでP&I=1.35になります。
「ピッチトラッキング」スライダーを調整してPitchのP値を70にします。実際にはスライダー0.9でP=71としました。
これでPDバランスの調整は完了です。

[ ドリフト、ふらつき I 強度 ]
I値は共用範囲が広いのでBetaflightの規定値でも大丈夫かも知れません。大きい方がレスポンスが良くなりますが大きすぎると振動やバウンスバックが出ます。私は今のところ、なんとなくスライダーを1.0にしています。初期値は80/84/80で現在値は135/127/135とだいぶ大きくなっています。もっと小さくすべきかも知れませんが、これでしばらくテストしてみます。

[ Feed forward ]
スライダーではなく右の方にある各値はプリセット/RC_LINKで適切な値を選択することで設定されます。

私の場合はELRS 500Hz, Race, Serial RX, Single cell valueで設定しています。
FFのスライダーはとりあえず1.0にしておきました。

[ 動的ダンピング ]
強度=37，詳細=0に設定します。

[ 動的ダンピング D Max ]
動的ダンピング(D Max)が0の時は上の数値欄にあるD MaxとDerivativeに同じ数値が出ているはずです。これを記録します。「ダンピング D強度」のスライダーを下げ「動的ダンピング D Max」のスライダーを上げてD Maxを記録した値、Derivativeをそれより少し小さい値にします。私の場合は「ダンピング D強度」を0.75, 「動的ダンピング D Max」を1.0にしました。まったり飛行の場合は、もっと差を小さくした方が良いかも知れません。

最終的なPID画面はこんな感じになりました。これでしばらく飛ばしてみようと思います。