PCA9685を連結して同じ電圧をかけての動作確認ができた。
一歩一歩進んでる感がある。
PCA9685を連結して同じ電圧をかけての動作確認ができた。
一歩一歩進んでる感がある。
下でもいいのだろうけどこれまでの資産が生かせるうえでまずはやる。電圧が違うのがあるから、問題があってJetson nanoが壊れても困るというのもある。
DC-DC等の箱を作成DC-DCを抑えてるクリップ(キャップ)部分が熱で溶けないが少し心配。データをアップロードはそういうのも含めてテストしてからのほうがよさそう。
へたくぞながらはんだ付け完了。Jetson nanoの起動をバッテリーで確認。
失敗して3Vしかでなくなってしまったコンバータは別の目的で勝ったアップコンバータと合わせてスピーカーの電源にする。スピーカの消費電力には若干足りないがまあスピーカーなら音が少し小さくなるくらいで済むだろう。
あと、これを入れる箱が必要だな。
DSC_0006 | DSC_0007 |
現在、移動機能をつけるために、電源のバッテリー化のための作業を実施中。
CustomMjpeg.py、publisher_member_function.pyを修正
CustomMjpeg.pyはデータサイズを小さくするところのストリームスクリプトが間違っていてエラー出していたのを修正。
publisher_member_function.py はタイマーのインターバルと画像サイズの部分を修正
どうやら遅延は複合要因だったようだ。主な原因は以下の二つ。
まず以下の状態の時遅延はほとんどない。
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はもう切っておいていいかな。