2025年10月22日水曜日

ESP32-CAMをWireGuard経由で使ってみた。

 ESP32でWireGuardが使えるライブラリがあるということで、ESP32-CAMもWireGuardを使ってNAT越えできるのではないかということで試してみた。

よくあるスマホのアプリ対応のWiFiカメラとかだとポート解放とか不要でユーザ登録すればカメラの映像を見れたりするけど、ESP32-CAMもモバイル回線とかのポート開放できないような場面で使えたら便利かも?ということで試してみた。前にUPnPでポートを開けてみたこともあったけど、そもそもグローバルIPがない環境だとこの方法も使えないし。

ESP32-CAM

久しぶりにESP32-CAMのスケッチをビルドするのでまずは環境を最新にしてビルドしてみた。ESP32 Arduino Coreは3.3.2でArduino IDEは2.3.5。前にESP32-CAMのESP32 Camera Driverを最新にしたときの手順で、ESP32 Camera Driver v2.1.3に更新してみた。
まずここで躓いたのがSCCB関連で、sccb-ng.cを削除したらうまくビルドできた。

最新の環境で前回のスケッチがビルドできるようになったので早速WireGuardを組み込んでみる。

とりあえずESP32のWireGuardライブラリをダウンロードしてきてサンプルをビルドしてみたんだけどまさかのArduino core for the ESP32 3.xに非対応という…

Pull requestに上がっていた3.x対応のESP32-WireGuardライブラリがあったのでこれをZipでダウンロードしてきて手動で追加した。テストでサンプルがビルドできたのでこのライブラリをESP32-CAMのスケッチに追加していく。

スケッチを全部貼ると長くなってしまうので前回のスケッチに追加した部分だけを紹介。

#define Tunnel

#ifdef Tunnel
#include <WireGuard-ESP32.h>
char private_key[] = "                                            ";  // [Interface] PrivateKey
IPAddress local_ip(10, 4, 0, 2);                                      // [Interface] Address
char public_key[] = "                                            ";   // [Peer] PublicKey
char endpoint_address[] = "     .f5.si";                      // [Peer] Endpoint
int endpoint_port = 51810;                                            // [Peer] Endpoint
static WireGuard wg;
#endif

まずは各種ライブラリをincludeしてるあたりにこんな感じで設定を追加。サーバ側はこの前設定したDD-WRTなんだけど、ESP32-CAM用にPeerを追加した。IPは同じセグメントで別なIPを割り振る感じ。Peerの設定はクライアントに割り振るIP以外ほぼコピーかな。ESP32ではQRコードではなくてQRコードの下にあるExport Peer Configボタンを押してコンフィグファイルをダウンロードする。そんでもってそのファイルの中のPrivateKeyってところとPublicKeyってところをコピーして上に貼り付け。DD-WRTの設定画面からじゃなくて、コンフィグファイルをダウンロードしてその中身ってのがポイント。

#ifdef Tunnel
  Serial.println("Adjusting system time...");
  configTime(9 * 60 * 60, 0, "ntp.jst.mfeed.ad.jp", "ntp.nict.jp", "time.google.com");

  struct tm timeInfo;
  if (getLocalTime(&timeInfo)) {
    Serial.print("Local Time  : ");
    Serial.printf("%04d-%02d-%02d ", timeInfo.tm_year + 1900, timeInfo.tm_mon + 1, timeInfo.tm_mday);
    Serial.printf("%02d:%02d:%02d\n", timeInfo.tm_hour, timeInfo.tm_min, timeInfo.tm_sec);
  }
#endif

WireGuardはNTPから時間を取得する必要があるのでNTPで時計を合わせる部分をsetup()の中のネットに繋がったあたりに追加。mDNSの上ぐらいに追加しておいた。

#ifdef Tunnel
  Serial.println("Initializing WG interface...");
  if (!wg.begin(
        local_ip,
        private_key,
        endpoint_address,
        public_key,
        endpoint_port)) {
    Serial.println("Failed to initialize WG interface.");
  }
#endif

そしてWireGuardに接続する部分をsetup()の中のserver.onの直前ぐらいに追加。これでWireGuardに接続されるとESP32の通信自体が全部WireGuardに流れる形。起動後10.4.0.2に接続すると普通にカメラの映像を確認できた。スタックも前回増やした状態でいい感じに安定して動いている。

ライブラリを使うことによって意外と簡単にESP32からWireGuard VPNに接続できちゃった。これならグローバルIPがなかったり、ポートが開けられない環境に設置して、サーバ側からポート変換で公開できちゃうので便利。お互いにNAT越えできない場合はTailscaleとか使えると便利そうだなぁ。

mDNSライブラリもそのまま動いてるみたいだけどWireGuardで接続している同セグメントからじゃないとmDNSでは解釈できないみたい。他のWireGuardのPeerからはうまく発見できた。IPだとWireGuard経由でも、ESP32-CAMがつながってるWiFiネットワークからでもどっちからもアクセスできた。

フレームレートの比較はどうやってやればよいのかな…

2025年10月19日日曜日

DD-WRTでWireGuardを使ってみた。

 DD-WRTでSoftEther VPNの設定がうまく行かなくなっていてからOpenVPNを設定して使っていたんだけども、WireGuardのほうが速いという噂を聞いたので試しにDD-WRTでWireGuardの設定をしてみて速度を比較してみた。

WireGuardの設定はOpenVPNとかSoftEtherVPNの設定画面とは別で、SetupのTunnelsから設定できる。DD-WRTのバージョンは62170以上が推奨みたい。

ここのAdd Tunnelを押すと各種Tunnelを追加できるようになっている。色々調べて設定してみたんだけど、どうしてもネットに繋がらなくなってしまうので最終的に公式フォーラムに登録してドキュメントを見ながら設定してみた。

Add Tunnelを押したら新規でTunnelが追加されるのでWireGuardを選択して設定していく。

Generate Keyボタンを押してLocal Public Keyを生成して、Advanced SettingsはEnableにして上のように設定する。MTUはインターネットのMTUからWireGuardのヘッダー分の60を引いた値にしておいた。サーバIPはドキュメント通りに10.4.0.1にしておいた。

とりあえず設定できたらSave & Applyで保存する。

次にクライアントの追加。

Add Peerボタンを押すと設定項目が追加されるのでPeerの設定をしていく。

Client Config FileをEnableにして、とりあえずクライアントのIPはドキュメント通りの10.4.0.6で設定。Peer Tunnel Endpointはサーバのアドレス設定ということで、外部からアクセスできるようにDDNSを設定した。DNSはとりあえずGoogle DNSを設定しておいた。
今回は1デバイス毎にPeerを設定しているのでAllowed IPsのサブネットマスクは/32にしておいた。/24とかにすると同一セグメントのPeer設定を増やすとうまく繋がらなかったり。

あとはMake Peer Configを押すとQRコードが生成される。
とりあえずこれでサーバ側の設定は完了。今回はiPhoneを接続したいのでiPhoneにWireGuardアプリをインストールしてQRコードをスキャンするだけでつながった。

OpenVPNの設定よりも簡単かも…

というわけで次に速度の測定をしてみた。

DD-WRT自体はOpenVPNもWireGuardもどっちもオンの状態で、同じ回線でiPhone側のVPNの切り替えだけでテスト。

まずはVPN不使用で回線のスピードをテスト

これがVPNでどこまで遅くなるのか…
OpenVPNはこんな感じ。何故かいつもダウンロードだけ遅いのよね。ルータの暗号化性能?
WireGuardはこんな感じ。結構速い。上りも下りも同じ速度が出ている
ちなみにルータの性能としてはBCM4708の800MHzデュアルコア、RAM512MBといったところ。
どっちも共存できてるので色んなところでつながるかテストしてみようかな。MTUも調整しないといけないかも。

ちなみにDD-WRTでやってるDNS広告ブロックもWireGuard経由で有効にできないかなといろいろ試してみたんだけど、PeerのDNS設定を10.4.0.1にしてDD-WRTのdnsmasq設定にWireGuardのセグメントを追加するだけ(listen-address=10.4.0.1)で行けた。そういえばOpenVPNの時もこんな設定にしていたな…

2025年10月12日日曜日

MediaMTXでラズパイカメラV1の映像をストリーミングしてみた。

 この前作ったダイレクトドライブなラジコンにカメラを搭載してFPVで操作してみたいと思って、LuckFox上でμStreamerを動かしたやつを載せてみたんだけど、このモータが結構早いのでもっと低遅延にしたい。

ということでもっと低遅延にできる方法が無いかどうか試してみることに。LuckFoxはビルドしてFlashに書き込んでっていうのが何回も往復するのが面倒なので、まずはRaspberry Pi Zero上で試してみることに。

久しぶりにRaspberry Pi Zeroを出してきたのでまずはOSをクリーンインストール。Raspberry Pi Imagerからセットアップして、WiFi設定までできるのは便利になったなぁ。Debian Trixieになった。

カメラ回りも少し仕様が変わっているみたい。raspi-configからの設定はいらなくて自動で認識するとか。

とりあえずセットアップが終わったRaspberry Pi Zeroに昔購入したRaspberry Pi Camera V1の互換品を取り付けて起動してみる。この前uStreamerで不安定だったリベンジ。

起動したら

rpicam-hello --list-cameras

と実行してみる。前のバージョンではlibcameraだった部分がrpicamに変更になっている感じかな?

Available cameras
-----------------
0 : ov5647 [2592x1944 10-bit GBRG] (/base/soc/i2c0mux/i2c@1/ov5647@36)
    Modes: 'SGBRG10_CSI2P' : 640x480 [58.92 fps - (16, 0)/2560x1920 crop]
                             1296x972 [46.34 fps - (0, 0)/2592x1944 crop]
                             1920x1080 [32.81 fps - (348, 434)/1928x1080 crop]
                             2592x1944 [15.63 fps - (0, 0)/2592x1944 crop]

こんな感じで差し込んだだけで認識してるみたい。互換品でもとりあえず問題なく自動で認識できた。確かに電源を入れたときに一瞬カメラのLEDが点灯したのでその時に確認してるのかな?

rpicam-jpeg -n --output test.jpg

次に静止画を撮影するコマンドで写真を撮影して、WinSCPでPCに転送して確認してみた。(SSHで作業しているため)
写真もバッチリ取れてるのでまずはカメラの動作確認はOK。

カメラの動作確認ができたのでMediaMTXをダウンロードして実行可能にする。MediaMTXはWebRTCを使ってカメラの映像をブラウザからストリーミングできる。

wget -P ./mediamtx https://github.com/bluenviron/mediamtx/releases/download/v1.15.1/mediamtx_v1.15.1_linux_armv6.tar.gz
cd mediamtx
tar xzf mediamtx_v1.15.1_linux_armv6.tar.gz
chmod +x mediamtx

ラズパイZeroWにはH264のハードウェアエンコーダが内蔵されてるのでせっかくなので使ってみようということでH264でWebRTCでストリーミングのテストをしてみる。同じフォルダのmediamtx.ymlを開いて一番下の方のpaths:っていうサンプルがあるところをまるっと下記のように置き換える。

paths:
  cam0:
    source: rpiCamera
    sourceProtocol: automatic
    rpiCameraWidth: 1296
    rpiCameraHeight: 972
    rpiCameraFPS: 30
    rpiCameraBitrate: 2000000
    rpiCameraCodec: hardwareH264

保存したらあとは./mediamtxでMediaMTXを起動するだけ。

ブラウザからhttp://raspberrypi.local:8889/cam0/にアクセスしてみるとカメラの映像が見れるようになってるはず。MediaMTX簡単で良いな…

早速遅延を図ってみた。前に使ったように画面にストップウォッチを表示して、その隣にストリーミングの映像を表示させてスクショを撮るという方法。

遅延は440msぐらい?ラズパイZero WはWiFiでルータに接続してる状態で測定。ハードウェアエンコーダとはいえH264に変換してるからかなぁ?
カメラの方が赤みがかっているのはレンズ改造のところに隙間ができていたからかな。隙間埋め無いと…

UVC対応のWebカメラでuStreamerを同じラズパイZero Wで試してみた。

とりあえず前と同じ感じで最新版をビルドした。

ustreamer -m MJPEG -f 30 -s 0.0.0.0 -p 8080 -r 1280x720

解像度はLogicool C270の解像度に合わせて近いところに合わせてみた。

そんでもって遅延を測定すると140msぐらい。ラズパイ上だと結構低遅延じゃん…
しかしこの解像度でもMJPEGだと帯域は8.5Mbpsぐらいあったので、H264の2Mbpsだと電波状況が悪いときは有利かも。

H264ハードウェアエンコード対応のWebカメラも試してみたいな。UVCのH264も実装が色々あるみたいでLinuxで使う場合はUVC1.5対応じゃないとちょっと大変そう。DJI Osmo Action 4とかもUSBカメラモードでH264に対応してるっぽいけど、UVC1.0なのでV4L2からそのまま取り出せなさそう

2025年10月5日日曜日

Windows 11へのアップグレードが31%で止まってしまった。

 そろそろWindows 10のサポートが終了するということで友人がWindows 11にアップグレードしようとしたところどうしてもアップグレードできないということで調べてみた。Windows Updateとかでも止まるらしいので最終手段のisoからインストールも試したみたいなんだけどどうしても毎回31%で止まってしまうらしい。
Windows 8のライセンスを使ってアップグレードでWindows 10をクリーンインストールしているんだけども、2023年9月27日からWindows 8のライセンスも使えなくなってしまったので再インストールしたらWindows 11のライセンスを購入しないといけない可能性もあるし…(ハードウェア変更無いので行けると思うけど。)
そもそも再インストール自体が面倒。

巷で噂のConexant SmartAudio HDデバイスは存在していないようだけれども…

ということでひとまずログファイルを確認してみることに。

C:\Windows\Panther

の中に「setupact.log」と「setuperr.log」というファイルが生成されていて、これがアップグレード時に残るログファイルらしい。

ログファイルは結構大きいけど、おそらく一番下の方だけを確認すれば良さそうな気がする。「setupact.log」の方を確認すると一番下の方でMIGのInfoがあったあとにMOUPGのErrorが出てログが途絶えていた。

2025-10-05 10:10:20, Info                  MIG        AddDriverFiles: Processing device: 4d36e96c-e325-11ce-bfc1-08002be10318
2025-10-05 10:10:20, Info                  MIG        AddDriverFiles: Processing driver: Sennheiser Communication Audio, Sennheiser, Sennheiser
2025-10-05 10:10:20, Info                  MIG        AddInfAndCatalog: Adding catalog file: C:\WINDOWS\system32\catroot\{f750e6c3-38ee-11d1-85e5-00c04fc295ee}\oem40.cat
2025-10-05 10:13:35, Info                  MOUPG  CInstallUI::ShowMessageBox: Showing MessageBox
2025-10-05 10:13:37, Info                  MOUPG  CInstallUI::ConfirmCanceled: User cancel confirmed
2025-10-05 10:13:37, Info                  MOUPG  CInstallUI::OnProgressChanged: Cancel is requested. Returning ERROR_REQUEST_ABORTED
2025-10-05 10:13:37, Error                 MOUPG  CInstallUI::OnProgressChanged(579): Result = 0x800704D3
2025-10-05 10:13:37, Error                 MOUPG  CSetupUIManager::OnProgressChanged(452): Result = 0x800704D3
2025-10-05 10:13:37, Error                 MOUPG  CSetupHost::OnProgressChanged(2531): Result = 0x800704D3
2025-10-05 10:13:37, Error                 MOUPG  CSetupManager::DlpManagerCallback(2341): Result = 0x800704D3
2025-10-05 10:13:37, Info                  MOUPG  Cancel of current task requested...
2025-10-05 10:13:37, Info                  MOUPG  Attempting to cancel current task...
2025-10-05 10:13:37, Info                  MOUPG  MoSetupPlatform: Calling SetupPlatform::INewSystem::RequestCancelOperations...
2025-10-05 10:13:37, Info                  MOUPG  Task cancel request returned: [0x0]
2025-10-05 10:13:37, Error                 MOUPG  SendCallbackMessage: [0x7] -> user callback returned 0x800704D3
2025-10-05 10:13:37, Error                 MOUPG  CDlpTask::Cancel(993): Result = 0xC1800108
2025-10-05 10:13:37, Info                  MOUPG  SendCallbackMessage: [0x7] -> Cancel request returned 0xC1800108

こんな感じのエラー。

この感じだと実はゼンハイザーのUSBヘッドホンが引っかかってる?

何度もアップデートが失敗しているのでUSBデバイスは抜いているんだけども、抜いていてもインストールしているドライバを移行する際にエラーで止まってしまってる模様。

ということでもう一度ゼンハイザーのUSBヘッドホンを差し込んでデバイスマネージャーからドライバを丸ごと削除してみる。

デバイスマネージャーのゼンハイザーのデバイスを右クリックしてデバイスのアンインストールを選択。

そんでもって出てきたダイアログで「このデバイスのドライバーソフトウェアを削除します。」にチェックを入れてアンインストール。とりあえずSennheiserのデバイス2つともこんな感じで削除。
削除したあとにUSBデバイスのスキャンが入ってしまうとまたインストールされてしまうので削除が終わったらUSBデバイスを抜く。

そんでもってWindows 11アップデートを掛けたら…

魔の31%を超えることができた。やっぱりWindowsのアップグレードはオーディオデバイスがネックになっているのかもしれないね。

EPOSのサイトにはドライバアンインストールツールでのアンインストール方法も公開されてるのでこれも参考にするとドライバをちゃんとアンインストールできるかもしれない。こっちのほうがデバイスマネージャーに表示されない部分も表示されるかもしれないので便利かも?

とりあえずWindows 11のアップグレードが止まってしまったらログファイルをみればなんとかなるかもしれないことがわかった。SetupDiagという、ログを見やすくする便利なツールもあるらしい。

ちなみに今回引っかかったゼンハイザーのGSP 350はアナログケーブルも市販(4極から3極も変換できるし)されてるようなので、こうやってドライバアップデートに引っかかるようだったら普通にアナログ化してオンボのRealtekとかで動かしても良さそう。7.1chのWindows 11対応のドングルに変更しても良いし。

2025年9月28日日曜日

タミヤのボールキャスターを試してみた。

 この前作った対向2輪型のラジコンなんだけど、高速で直進すると左右にゆらゆらするのでキャスターの制度が悪いからキャスターが振られてるんじゃないか?ということでボールキャスターに変更してみた。

金属製なので床が傷つくんじゃないかということで長らく放置していたタミヤのボールキャスター。
組み立ては超簡単。
キャスター用の高さ調整プレートはネジ穴を貫通にしてあるのでボールキャスターの高さ調整にも使用可能。ボールキャスターも35mmで組み立てたのでピッタリ。

実際に走らせてみるとやっぱりゆらゆらする。ということはSimpleFOCのPIDチューニングかもしれない。速度フィードバックで速度が一定になっていないのかなぁ。これはさらなるチューニングが必要かもしれない。
この前CAN経由でチューニングできるようにしたのでESP32側にちょっと変更できるようなしくみを入れようかな。

それはそうと、ボールキャスターになったことでフロントが軽くなってフロントが浮くようになってしまった。

重さはキャスターが36gでボールキャスターが12gだった。これはフロントが軽くなる。
キャスター変えただけでこんなに機敏に動くようになるなんて…
これジャイロつけたらずっとウィリーとかできそうな?