結線図のラフ

下でもいいのだろうけどこれまでの資産が生かせるうえでまずはやる。電圧が違うのがあるから、問題があってJetson nanoが壊れても困るというのもある。

DC-DC等の箱を作成

DSC_0010

DC-DC等の箱を作成DC-DCを抑えてるクリップ(キャップ)部分が熱で溶けないが少し心配。データをアップロードはそういうのも含めてテストしてからのほうがよさそう。

Jetson Nanoのバッテリーからの起動に成功

へたくぞながらはんだ付け完了。Jetson nanoの起動をバッテリーで確認。

失敗して3Vしかでなくなってしまったコンバータは別の目的で勝ったアップコンバータと合わせてスピーカーの電源にする。スピーカの消費電力には若干足りないがまあスピーカーなら音が少し小さくなるくらいで済むだろう。

あと、これを入れる箱が必要だな。

DSC_0006DSC_0007

複合要因だったようだ

どうやら遅延は複合要因だったようだ。主な原因は以下の二つ。

  1. タイマーのインターバルが遅い
  2. 送信データが大きすぎる。

まず以下の状態の時遅延はほとんどない。

  • タイマーのインターバル 0.016
  • 送信データのサイズを640 X 360
  • カメラからの入力フレームレート30fps

1といえる理由としてうまくいく状態からタイマーのインターバルを0.1にしたとき遅延が発生した。

2といえる理由としてうまくいく状態から、送信データを1280 X 720 としたとき遅延が発生した。また、640X320のままでもデータの受け手をふやす(unityでの表示とpythonでの直接表示を同時に起動)と遅延が発生した。

上手くいく状態からカメラの入力フレームレートを10fpsに落としても遅延派はとんどなかった。

これを踏まえてソースコートを修正する必要がある。

エンドポイントはあまり影響なさそう

endpointは影響なさそう。ただ、ダイレクトにウィンド作成して画像表示するノードとエンドポイントを経由して表示するノードを二つ同時に起動したら露骨にJetson nano側の処理が落ちた。”送信”が処理として重いのかも

ラグの原因調査中

ラグの原因を調査中. endpointをpc側にして、Jetson nanoはパブリッシャーのみにしてみたけどあまり変わらず。今度はpythonでダイレクトに受け取って映像表示してみる。

これでラグが解消されるなら、unity側もendpoint使用しないものを検討しないと。
ただその場合MetaQuestからダイレクトにJetson nanoにつなぐのはあきらめなくてはいけない。

処理能力の問題か?

とにかく通信が主要因ではなかったのでwifi機材を買う必要はなさそう。これで買い物ができる。

処理能力が足りてないのはちょっと深刻かな。VPNサーバー切らないと遅れがひどくなる。まあ今はソフトの技術を確立できればいいから、VPNはもう切っておいていいかな。