SOARISTO工房 Logo

ペガソス計画(20) - 週刊「ファランクスを作る」

 前回の続きです。

 nVIDIAの「Jetson TX2 Development Kit」に、最新の「JetPack」をインストールし、起動できるようにしてみました。

Tiny Phalanx, CIWS

 こちらは、目下建造中の「タイニー・ファランクス」です。

 まだ基台上部の旋回台座の部分が組み込めていませんが、その前にやることが発見されたため、工程を改めます。

 これまで、Trossen Roboticsの「ArbotiX-M Robocontroller」に、4D Systemsの「gen4-uLCD-70D-SB」を接続したり、SHARPの「CYBER STICK」を接続したりしましたが、いざArduino IDEでスケッチを書いて動かしてみると・・・。

 画像は、CYBER STICKから値を読み出して、TFTディスプレイに表示させているだけなのですが、画面のリフレッシュレートが、10fpsを下回ってしまっています。

 gen4-uLCD-70D-SBは、4D Systems提供の「Diablo16-Serial-Arduino-Library」(1.0.3)を使い、Arduino側で対応できる最大のボーレート(115,200bps)でシリアル通信させています。
(gen4-uLCD-70D-SB側は、600,000bpsまで対応可能)

 また、Arduino内部では、Timer1割り込みを使って、100msおきに、CYBER STICKの状態監視をはじめ、内部の温度センサの状態、PCファンの回転数・照明用LEDの照度(PWM制御)などの処理をさせています。

 にしても、わずかいくつかのテキストを表示させるだけで、10fpsを切ってしまうとは・・・。0xF999

 将来的には、TFTディスプレイに、タイニー・ファランクスの各種状態を、グラフィカルに表示させることを構想していたのですが、その実現は、難しくなってきました。

 さすがに、16MHz動作の「ATmega644P」には、荷が重すぎたのかも知れません。

 タイニー・ファランクスの制御にあたっては、それぞれの機器に「分散処理」をさせることを想定していたのですが、こと、TFTディスプレイについては、単体の処理速度に加え、シリアル通信の速度がボトルネックになるようです。

#単に、言われたことをやるヤツより、自ら考え行動するヒトが好きなので、TFTディスプレイも、パッシブではなく、アクティブな制御(表示)ができる機器を選んだはずだったのですが・・・。0xF9D1

Tiny Phalanx, nVIDIA Jetson TX2 Development Kit

 仕方がないので、真打ちを登場させます。

 「Jetson TX2 Development Kit」には、ステレオカメラからの画像解析など、“分析系”に専念してもらいたかったのですが、“表示系”や“制御系”でも、活躍してもらうことにします。

#イコール、これまで「Python」の構文が気に入らなかったので、避けていたのですが、いよいよPythonで書かれた各種ライブラリを扱うことになります。

Jetson TX2 Development Kit, Install SDK Manager

 と、いうことで、3年半前に購入して以来、永らく放置してあった「Jetson TX2 Development Kit」を、最新の状態にすることにします。

 画面は、ホストPCとなる自作水冷マシンで、「Ubuntu」(18.04.6 LTS)を立ち上げたところです。

 Jetsonのクリーンインストールと言えば、約8年前に「Jetson TK1」を購入し、当時はほとんど情報がなかったため、かなり苦労して最新化した記憶があるため、これまで避けていました。

#面倒くさいことは、避けてばっかり。0xF9C7

 Jetson TX2を、リカバリモードで立ち上げ、ケーブルを接続すると、ホストPCからは、USBデバイスとして認識させることができます。

Jetson TX2 Development Kit, Install SDK Manager

 ホストPCに、「nVIDIA SDK Manager」(1.8.1.10392)をインストールし、起動すると、「Jetson TX2」が認識されました。

 ここから、Jetson TX2に、最新のJetPack(現時点では4.6.2)をインストールします。

Jetson TX2, Ubuntu 18.04 LTS

 無事に、Jetson TX2上で、Ubuntu(18.04 LTS)が起動できました。

 と、簡単に書いてますが、ここまで来るのに、盆休みの2日間を要しました。0xF9C8

 まず、ホストPCに、仮想環境を作り、そこでUbuntuを起動し、SDK Managerを動作させようとしました。

 具体的には、ホストPCに「VMware Workstation Player」(16)をインストールし、その上で、Ubuntu (18.04 LTS)を起動させました。

 しかし、何度やっても、インストールの途中で前に進まなくなってしまいます。

 いろいろ調べてみると、どうやら、仮想環境上のUbuntuでは、SDK Managerが上手く動かない“らしい”。

 仕方がないので、“仮想”ではなく、“物理”でUbuntuを起動させるべく、ホストPCにインストールすることにしたのですが・・・。

 同一ディスク上に、Windows10とUbuntuをインストールする「デュアルブート構成」では、Windows10側に不具合が出る可能性が高いとのことで、ディスクを分けることにしました。

 使い古しの(容量の少ない)HDDやSSDなら、たくさん転がっているので、一時的に接続すればことは済むのですが、またも別の問題が。

 Ubuntuのインストーラーの不具合で、インストール対象となるディスク以外のディスクが繋がっていると、間違ってそちらに書き込んでしまう可能性があるとのこと。

 最新鋭の自作水冷マシンでは、マザーボード上にM.2 SSDが取り付けられ、さらに、その上に、水冷ブロックを組み込んだグラフィックボードが組み込まれていることから、容易にM.2 SSDを取り外すことができません。

 仕方がないので、前世代の自作水冷マシンに、SSDを取り付け、Ubuntuをインストールしようと起動してみたところ・・・。

 1ヶ月近く放置プレイされていたことに気を悪くしたのか、はたまた、新しいカノジョに付きっきりなことに気を悪くしたのか、ちゃんと起動してくれません。

#クルマでもよくありますよね。最新モデルに浮気しようとすると、途端に調子が悪くなるとか。0xF9C7

 なんだかんだで、前世代の自作水冷マシンにUbuntuをインストールし、起動できるようになるまで、一昼夜。

 いよいよ、“物理”環境上でSDK Managerを動作させ、インストールを始めたのですが・・・。

 やっぱり、同じところで、前に進まなくなってしまいます。

#どないなっとんじゃい!0xF9C9

 SDK Managerでのインストールでは、ホストPCとJetson TX2を、USBケーブルで接続し、必要なファイルをJetson TX2にフラッシュします。

 この時、ホストPCとJetson TX2とは、仮想的にLAN環境で接続されたことになっており、その際のJetson TX2側のIPアドレスは、「192.168.55.1」になっています。

 そこで、この“仮想的なLAN接続”が、上手くいっていないものと想定し、接続方法を変えてみることにしました。

Jetson TX2 Development Kit, Install SDK Manager

 SDK Managerのインストール手順の前半に、「Automatic Setup」と「Manual Setup」とを、選択できるところがあります。

 これを「Manual Setup」とし、LANケーブルを使って“物理的に接続”し、IPアドレスを、以前にJetson TX2で遊んでいた時の「192.168.11.xx」にしてみたところ、インストールが前に進みました。

 ハッと思って、仮想環境上のUbuntuでSDK Managerを起動し、SDK Managerを動作させ、「Manual Setup」を選んだところ・・・。

 同じように、インストールが前に進みました。0xF9CF

 ということは、ホストPC側のUbuntuが、仮想環境か物理環境かは関係なく、単に「Automatic Setup」を使わず、「Manual Setup」を使ってIPアドレスを手動で設定すれば、正しくインストールできることが分かりました。

 ちなみに、以前のJetson TX2側のIPアドレス(192.168.11.xx)は、インストールが途中で中断し、Jetson TX2の内蔵メモリがフラッシュされなかったことから、たまたま残っていたもので、「Manual Setup」を使えば、仮想的なLAN接続(デフォルトの「192.168.55.1」)のままで、正しくインストールされます。

 ここまで来るのに、1日半。0xF9C8

 Jetson TX2に、JetPack 4.6.2がインストールされ、Ubuntu 18.04 LTSが正しく起動したことが確認できたところで、もろもろの設定をすることにしました。

 まず、Jetson TX2内蔵のeMMCが、32GBと少なめのため、外部にSSD(240GB)を接続し、関連のファイルを移動しました。

 さらに、eMMC上に確保されているスワップ領域が、16GBとなっているため、外部のSSDに、新たにスワップ領域を確保しました。

 なお、せっかくなので、外部のSSDからシステムを起動させることを考えましたが、Jetson Nanoではなく、Jetson TX2では、外部SSDからのシステム起動は相当に難しいようなので、現時点では見送りました。

 ちなみに、「hdparm」でディスクのアクセス速度を確認したところ、内蔵eMMC(/dev/mmcblkp1)が「230.08MB/sec」、外部SSD(/dev/sda1)が「267.20MB/sec」と、期待したほどの違いはありませんでした。

 よって、無理して(膨大な時間を掛けて)外部SSDに移し換えずとも、起動時間にそれほど違いはないだろうと判断しました。

 ちなみに^2、Jetson NanoにおけるSDカード(/dev/mmcblk0)のアクセス速度は、「85.49MB/sec」とかだそうで、これだけ遅いなら、外部SSDに移し換えるメリットはありそうです。
(Jetson Nanoなら、起動時間が1/3(単純計算で)になるかも?)

Jetson TX2 Development Kit, Install SDK Manager

 ポイントとしては、SDK Manageが終了してからSSDをmountするのではなく、SDK Manageの途中で、Jetson TX2がいったん起動した際に、手早くSSDをmountし、関連のファイルをSSDに移動することです。

 なぜならば、SDK Manageの後半は、CUDA関連やなんやらの、もろもろのファイルをeMMCに書き込むため、無駄にeMMCの容量を消費してしまうためです。

 何度かクリーンインストールを繰り返して分かったことですが、SDK Manageが終了した段階でSSDに移動すると、eMMCは約12.82GBが使われていましたが、SDK Manageの途中の段階でSSDに移動すると、eMMCは約5.45GBが使われていました。
(差分は、SSDに書き出されているということ)

 と、いうことで・・・、

 盆休みの2日間を消費。

#まぁ、大宗の田舎モンとは違うので、わざわざ大渋滞や大混雑の真っ只中に突っ込んでいって、無駄に時間を消費するよりはマシですわな。0xF9D1

 紆余曲折ありましたが、いちおう、永いこと放ったらかしにしてあったJetson TX2を、ひょんなトリガで、最新の状態にすることができました。

 CUDAのサンプルプログラムをmakeし、動かしてみましたが、smokeParticlesで40.0fpsを、コンスタントにマークしてくれます。

 めでたし、めでたし。0xF9CF

(つづく)

Trackback(0)

Trackback URL: https://www.soaristo.org/mt/mt-tb.cgi/1272

Post Comment