てな、馬鹿げた表題をつけたものの、本当にできるんでしょうか？
何に使うのかって？。外に持ち出すには最低7インチのディスプレイが必要です。配線や電源も考えなければいけません。これがケータイで代用できたらとっても便利。がさばるディスプレイの代わりにケータイを使うのが最終目的。
TX1で物体を認識した動画を、iPhoneで受信！？。考えただけでザワーっとします。つまり、その作成過程を考えるだけで吐き気がっ。
今回の記事はJetPack-2.3環境すなわち全部64bit環境な場合です。また、homeにプレインストールしてあるjetson_clocks.shを実行し、GPUクロックを最大にしてます。
今回の最終形。１度に複数の物体を認識している（テレビの中の人物も）。これがTX1から送られたmjpeg動画の一部画像です。動いている様子は以下のMoveファイル参照。
ザワーの１回目
まず肝心のPy-Faster-RCNNインストール。このダウンロードしたフォルダの中で、専用に修正されたCaffeのビルドが必要です。経験上すんなりとインストールできない予感があったのですが、やっぱり的中。少し探すとForumに書いてありました。要するにCuda8.0に対応してないとのこと、
これを参考（中程にNvidia担当者の回答がある）にすると、インストール自体は何て事ありません。説明が悪いだけ（私の英語力の問題か？）です。BLC Caffeは修正済みなので、この中からいくつかのライブラリをコピーして上書きしなさいですと。
すなわち py-faster-rcnnをダウンロードして解凍すると、py-faster-rcnn->cafe-fast-rcnn の中身が改造されたcaffeのインストーラがあります。すでにBLVC Caffeの方はCuda8.0に対応しているので、ダミーでどこかにBLVC caffeをダウンロードして、この中身のライブラリを入れ替えればOK。
入れ替えるファイルは、以下の11個のファイル（青の部分）だそうです。該当フォルダは黒の部分です。
include/caffe/util/:
cudnn.hpp
src/caffe/layers/:
cudnn_conv_layer.cu
cudnn_relu_layer.cpp
cudnn_relu_layer.cu
cudnn_sigmoid_layer.cpp
cudnn_sigmoid_layer.cu
cudnn_tanh_layer.cpp
cudnn_tanh_layer.cu
include/caffe/layers/:
cudnn_relu_layer.hpp
cudnn_sigmoid_layer.hpp
cudnn_tanh_layer.hpp
すでにTX1にCaffeをインストールしていれば、依存ライブラリがインストールしてあるはずなので、あとはいつものMakefile.configの書き換え。内容は以前の記事を参考にしてください。いつものようにビルドして、以下の記事の
２番目あたりからpy-faster-rcnnをインストールすればOK。私の場合、
sudo pip install pyyaml
で、新たなPythonライブラリが必要でした。新たにビルドされたCaffeは、すでにインストールされているCaffe、Pycaffeと区別されるので、pathなどの追加は不要。
TX1ではメモリーオーバーになるのでデモソースは、簡易型のデータでしか実行できません。この後のライブラリの容量を考えると、まーTestなので、それなりに認識すればいいのかと。
一応 py-faster-rcnn-->tools に入って、
python demo.py --net zf
（その後の確認：TX1の同じフォーラムに書いてありましたが、GPUメモリをなるべく使わない方法＝logout して他のコンピューターからSSH接続後同じプログラムを動かすと--net zf 無しでも動きました。画像の認識は上がりますが、スピードが極端に落ちます。動画として確認するなら--net zfをつけたほうが良いみたいです。）
5つのテスト画像を読み込んで、認識結果を画像で表示します。GPUフル稼働でも1画面平均0.47秒くらいの認識スピードなので、動画にすると遅いこと確実 。遅いと言ってもCPUモードで実行すると平均28秒！！、なんと60倍くらい遅くなります。それよりははるかにマシ。Pi3だとどんだけ遅くなるんでしょうか？
めげずにmJpeg配信のためにSimpleCVをインストール。py-faster-runのビルドに成功していれば、以下の2つを追加インストールでOK。
sudo apt-get install python-pygame
sudo pip install https://github.com/ingenuitas/SimpleCV/zipball/master
ざわーの２回目
mJpeg配信とくればSimpleCV!!。同じPythonなので簡単に...。Camera画像の変換が重要な問題だとはわかっていたのですが、少し風邪気味でタダでもボケボケの頭が、さらにボーケボケ。構想２日、実務が半日で、やっとdemo.pyを書き直した物が次のソースです。一応動くだけですが。
py-faster-rcnn-->toolsへ保存したら、40行目付近の
js = JpegStreamer("tegra-ubuntu.local:8090")
の赤字部分を自分のip環境に変更して下さい。
cv2-->SimpleCVのイメージデータ変換（たった１行）だけがキモでした。ソースを全部コピー（最後の１行が見にくい）して mjpeg.py とかで名前を付けて保存。そしてUSBにカメラをつないだら、
python bokeboke.py --net zf <-----直したつもりなのにボケボケでした
python mjpeg.py --net zf
を実行。MacやiPhone のサファリからtegra-ubuntu.local:8090と打ち込めば、期待のpy-faster-rcnn動画が確認できます。TX1をバッテリー駆動させてiPhonのテザリング機能を使うことで、どこでも結果が確認できることになります。前にEdisonのFlask環境でGPIOとmjpeg画像を制御したことがあるので、応用すればTX1でもディープラーニング環境でGPIOの遠隔操作が可能のはずです。
カメラ画像は1080X720で読み取ってますが、これより解像度が低いと、物体の認識率が下がるようです。認識に時間を取られるので解像度を下げても、あまり表示スピードが変わりません。色々試してみると面白い。mjpeg配信なので、本体直結のディスプレイでなくとも画像表示可能です。だから本体をログアウトさせても、他のコンピューターからSSH接続で動作可能。--net zf 無しで実行したい場合は、この方法で！！
結局の動画
動画とは程遠いものですけど、少しバカな（反応の鈍い）ロボットの認識用として使えば、現実味を帯びてきます。ファインチューニングで個別画像をDIGITで追加学習させれば、「こんにちはTAKEsan」とか、こんにちは「Juneちゃん」（愛犬の名前）を言ってくれる！！（っと思う）。次の目標はこれで決まり。こう考えるとなんとなく顔がにんまりしてきます。さらに認識する種類を限定することで、大幅に早くなるような気がします。
TX1で発信したmjpeg動画をiMacで表示させているところ。かなりスローで、3秒くらいの遅延がありますが、なんとなくいい感じ。 ちゃんとfaster-rcnnしてるでしょ。
試しに、母艦GTX1080環境で実行すると（GTX1080もCoda8.0対応のため、TX1と同じようにCudaのライブラリを変更したらすんなり動いた）、やっぱり速い。図体がでかいので、背負って移動させるわけにもいかず、早くてもあんまり意味がありません。
母艦Ubuntu環境（i7 6700K とGTX1080）で同じソース画像をiMacで受信、Pythonなのに遅延がほとんどない。
幸せになったということで、py-faster-rcnnの実験については、これで終わり。
TX1環境のデープラーニング応用環境が現実味を帯びてきた
この頃はもっぱらTX1やIntel Jouleの個人的な性能評価やらインストール作業やらに熱中してしまって、まともにプログラム作成に向き合っていません。あっちこっちに首を突っ込んで当初の予定だったニューラルネットワークに関するお勉強がそっちのけになっています。
まーその流れで。Jetson TX1の最先端はどちらに向かってるか探りを入れてみました。この方が鍵を握っているようです。
Nividiaでは、Jetpack2.3になってから、TenserRCがどうのコウノト言ってますが、果たしてこれは何？。発売当初からFloat 16演算を行うと、スピードが1Tが出るとかなんですが、実質的な実現例が提示されていないばかりか、Float16のcaffeもイマイチ中途半端でした。ましてTensorRCはこのFloat16に特化したと言いながら、何も具体的な情報が無い。やっと重い腰をあげたみたいなので、以下実行結果を私なりの理解度でご報告。でも未だにTenserRCが何者なのか、わかっていない。
まずTorchはどうなったのか。
この方が「できるできる」と言っていたものが、少し前にやっとgithubで公開されています。自分で試して見て初めてわかったんでしょうね。ちなみにTorchはTenserRCとは無関係。TX1のCuda8.0対応版です。
記載されている手順通りで無事インストールできました。開始はいつものthではなく./deepRL-consoleでした。仕組みが理解できていませんがOpenblas、torch、torch7,cutorchが同時インストールされます。標準Luaライブラリは nn,cutorch、cunn、などがプレインストール。他のLuaライブラリは、Luaにパスを通せば簡単にインストールできます。例題はこんなのです。ピンポンゲームの学習。
以前入れた早稲田大学の白黒カラー化ソフトを実行させてみると。
（ソース中のargではコマンドラインで指定したファイルを認識しないので、直接ソースに画像指定してやります。この記事に書いてあるように追加のLuaライブラリが必要）
OpenBlas関連の実行時エラーが出ますが、ちゃんとカラー化できました。気になるテスト用に入っている風景写真の変換スピードは、以前のjetpack2.2と比較すると、60秒の実行時間に対して、今回は20秒。40秒も実行スピード早いのです（i7 6700k+1080環境では4秒程度ですが）。データの読み込みや演算共格段の進歩が見られます。いよいよTorch+TX1がモバイル環境で現実味を帯びてきました。
TenserRT
これはなかなかでした。DIGITSで作成した学習データの応用例です。
カメラを使ってリアルタイムで学習結果を表示します。
まず30fpsくらいで、とにかく手当たり次第、物体認証結果を表示するプログラム。Caffeのexampleの中にあるWeb-Testを使えば私にもできそうな感じ（スピードはここまでは確実に上げられない）です。
どこを認識しているのかがわからない点が残念ですが、とにかく速い！！。せめて点くらい表示させたらいいのに....ブツブツ。
物体の認識が組み合わさっているのに、目にも止まらぬ実行スピードです。出力単語をよく見ると、それらしい物体として認識されてます。
次にリアルタイムObject-Detect認識をTX1で実現させたプログラム。人物群と物を同時に判断できるようです。（スピードを度外視すれば性能は今回取り上げたpy-faster-runが上！！）こちらはさすがにだいぶゆっくりですが、ホビーでは実用レベルです。すごい。
動画では判断しにくいですが、人物を見つけると青の四角が表示されます。今回実験したmjpeg画像に比較すると格段に速いことが確認できると思います。
そもそも例題を実行すると、画像が上下逆！！。プログラムの中身を見て変更しようにも、複雑で何が何だかわからない。もっと単純にできなかったものなんでしょうか。評価用としては、プログラム中のコメントが少ないので解析に時間がかかりそうです。表示部分がおかしいような感じ。当分は、カメラをひっくり返せばいいことなんで、気にしない気にしない。
この方は同じgithubページ上に16bitCaffeのインストールスクリプトも自信を持って書いてますけど、OSが１つ前のものなので、run testがうまくいきません。どうも他の記事を読んでも、TX1に関しては、神の存在だと思ってるみたいな気がしないでもない。内容の割に、質問や閲覧数が少ないのは、この辺りでアメリカのみなさんも引いてしまうんでしょうね。
記事を発表している人物が、メーカー側ですから消費者として率直な感想を書きました。がっ、やってることは納得です。こういうものを見せられると、寒気が。つまり「機械が自分を守るための単純な何かについて、人間がヒントを与えた時。ニューラルは空恐ろしいほどの進化があるのかも」です。
DIGITSで学習させたObject-Detectデータが使えるようなので、次の機会に試してみることにします。TX1のフォーラムでは、「こんなに遅いのに」的に言ってる人がいますが、要はどう応用して使うかの問題なので、基本的なスピードがこれならば、十分実用的だと思うのですが、いかがなものでしょうか。
※2017/1/19:この後TX1へのOpenFrameworksインストールに成功して、OF上で上の動画より早く実行できるようになりました。おまけに入出力の「とっつきにくさ」が解消されます。
jetpack2.3でOpenCVやZEDカメラSDKのコンパイルができた
OpenCVの例題や、ZEDカメラSDKのコンパイル時にcudnn関連のエラーが出て困っていたのですが、対策がわかりました。
Oencvライブラリを使ったソースの場合、aarch64に限ってコンパイルエラーになってしまうようです。この問題は近い将来修正されると思いますが、どちらもsampleに入っているCmakeLists.txtファイルの最初の方に、以下を記述するとOKでした。ZEDの場合は以下を記述し、なぜか2回cmakeを実行するとうまくいきます。
set(CUDA_USE_STATIC_CUDA_RUNTIME OFF)
TX１でもJouleでも内部eMMCはTRIMが実行できる。
これはlinuxでSSDを使ってるみなさんならご承知の通り、SSDの延命と実行スピードを維持するための必需品
sudo fstrim -v /
です。これが実行できた＝TRIMが実行できたです。本体内部のeMMC寿命＝超お高い本体CPUの寿命につながりますので、思い出したらやってみましょう。
では、また。
