Take’s diary

Macとマイコンに関すること--ワクワクの製作日記

Intel Joule はEdisonやPi3 との価格差を超えられるか?

Intel Jouleを色々試してみて

 先月の段階で、Ubuntu developer potalよりUbuntuインストール方法が紹介されています。本体eMMCに自動的にインストールされるのですが、前回私の書いた記事より格段に簡単で、画面が安定している感じなので、今回紹介します。そしてmraaの実装と少し高度な動作確認。さらにはOpenCLの動作確認まで触れて見たいと思います。

f:id:TAKEsan:20161206144546j:plain

                                                                私の最終構成です。

f:id:TAKEsan:20161206144543j:plain

             OpenCLまで動いちゃいました

本体内部eMMCに、Ubuntu16.04をインストールする

 今月の初め(2016/12)にJouleにUbuntu14.04をインストールして、インストール煩雑さの挙句GPIO群が使えないなんて記事を書きました。その後Intel Edison ユーザー会https://www.facebook.com/groups/625317624253131/の Hirokazu Egashiraさんにヒントをいただいて、いろいろ試したらとても簡単にインストールできたのでご報告。

 まず、Intel Joule | Ubuntu developer portalに、JouleのUbuntuが発表されていました。最初はUbuntu Coreだけだと思っていたのが大間違いで、最後の方に自信なさげにUbuntu desktopインストール方法が書いてあります(Developer setup Install Ubuntu Classic (desktop) on the Intel Joule)。ただ、リンクされたファイル「tuchuck-xenial-desktop-iso-20161006-0.iso」ではインストール用のUSBが作れませんでした。で、諦めかけて以前Ubuntuのインストールで大変参考になった記事Installing Ubuntu on Intel Joule 570x |Intel Communitiesを見ていたら、最後の方にjosephwinstoniiさんがこの件を書いていました(この方は一体誰?)。よく見るとリンク先が違っているようです。本当は、 http://people.canonical.com/~platform/snappy/tuchuck/tuchuck-xenial-desktop-iso-20161006-0.isoだそうです。ダウンロードに、ものすごく時間がかかるのですが、これを使うと簡単にUbuntuインストール用のUSBメモリーが作れます(現在はリンクが治っている可能性がありますが)。あとはUbuntu developer portalの手順に従ってインストールするだけ。注意点はその記事にも書いてありますが、JouleのBIOSBIOS V#131に更新する必要があることです。

 Intelサイトに

software.intel.com

書いてあるんですが、JouleのBIOSをインストールできるのはWindows環境だけです。書き換えにはJouleと付属USB Cをつなぎます(電源は必要なし)が、接続したディバイスは時間が経つと自動的にキレてしまうようなので、最後のスクリプトを実行する前に、Windowsディバイスマネージャーで、接続されていることを確認してから、コマンドプロンプトスクリプトを実行することで上手くいきました。認識していない場合は、USBを刺し直します。これが失敗すると、今回の方法でUbuntuが上手くインストールできないので。確実にクリアすることが必要となります。

 次に自分の母艦環境(WindowsMacLinux)でUbuntuインストール用のUSBメモリを作ってください。あとは、JouleのUSB3.0へキーボード、ディスプレイ、UbuntuインストールUSBメモリを取り付けてBOOTマネージャーからUSBを指定するだけ。

f:id:TAKEsan:20161206151121j:plain

          Jouleを起動させてF2キーを押すと、こんな画面になります。

f:id:TAKEsan:20161206151122j:plain

         Boot Manegierを選択して、EFI USB Deviceを選択します。

 あっという間に本体eMMCにUbuntu16.04がインストールできちゃいます。(あっとといっても20分程度は必要)Reboot後、派手な初期画面が現れた後(2分程度)、途中で言語やキーボード、Wifiの設定を聞かれるので、基本的な環境を入力します。簡単簡単。「前回のは何だったんだろう」みたいな感じでした。ちなみにカーネルは 「4.4.0-1000-joule」で、Joule専用のようです。

 思い切ってOstroとはさよならすることにしました。WindowsLinuxの母艦とクロスコンパイルするならOstoroでも良いとは思いますが、Edison等とは違い、以下の様にSSDUbuntuをインストールすると、ビルドが相当早いので、母艦の必要性を感じなくなります。内部eMMCにインストールしたUbuntuが母艦の代わりとでも言いましょうか。蛇足ですが、容量の少ないJoule内蔵eMMCにインストールしたUbuntuには、apt updateとapt upgradeを実行した後、最小限のアプリのインストールに留めた方がよろしいかと思います。

Usb3.0に接続したSSDUSBメモリUbuntuをインストールする

 このままでも良いのですが、eMMCはもったいない(IntelはeMMCのを信用していない節があちこちに見受けられる)ことと、絶対容量が不足なので、どうしても外部から起動したくなりますが、USB外部記憶装置にインストールが可能です。

 まず本体eMMCで起動したjouleに外部SDやSSDを接続。さらにインストールUSBを接続します。

f:id:TAKEsan:20161206145100j:plain

今回接続しているSSDSanDisk(128Gで12,000円くらい)、キーボード・マウス兼用の無線アダプタ、インストールSDカードはSONY製を使いました。左上は、OpenCLテスト用に作ったSDカード。BuffaloのSDカードリードライターを使ってます。USBハブは当然3.0用ですよ。お間違えなく。

 次にUbuntuの世界で有名なGpartedをインストール。このソフトでインストールするディスク名称を調べ、一応全領域をext4でフォーマットします。

f:id:TAKEsan:20161206135923j:plain

GpatedでSSD内容を表示させています。すでにUbuntuをインストールしてあるので複数のパーテーションに分かれていますが、最初は全領域ext4でフォーマットします。右上にデイスク名称「sda」が表示されています。

インストールCDの install/predeed.cfg の中身を修正。2箇所(50,90行目付近)修正箇所があります。

f:id:TAKEsan:20161206142708j:plain

  50行目付近の赤線部分を変更。念のため以前の行はコメントをつけています。(元々はmmcblk0)

f:id:TAKEsan:20161206142707j:plain

               90行目付近も同じように修正します。

 この部分をmmcblk0からsda またはその他(環境によってディスク名が変わるのでgpartedで確認したディスク名)に変更して保存。

 修正が完了したらインストールUSBメモリ、外部記憶装置は外さないで、reboot後、F2でブートマネージャーを立ち上げ、Boot Option Menuを選択。今度は下の写真の様にEFI USB DIiviceが2つ出てきます。大雑把な方法ですが、空の方は選択してもブートマネージャに戻ってきますので、もし戻ってきた場合はEFI USB DIivice 1の方を選択すれば、本体eMMCと同じ様に、自動でpredeed.cfgに指定した空のディスクにインストールされます。なんか挙動がおかしかったら、(途中でインストール作業が止まってしまったら)再度リセットスイッチを押して本体eMMCでUbuntuを起動した後、predeed.cfgの中のディスク名称を再度確認してください。インストールできない原因は多分これだけです。正常であれば簡単にインストールできちゃいます。

f:id:TAKEsan:20161206135921j:plain

            Boot Option で EFI eMMC Deviceを選択するだけ。

 現在私はコンパクトSSDを使ってますが、安定して動いてます。早いこと早いこと。もう立派なUbuntuマシンです。Ubuntuディスクトップマシンを持ってるのですが、全く必要無くなってます。

 標準で使うUbuntuを決めたら最初にMraaインストールと動作確認

 JouleでPythonc++からGPIOを制御するには、mraaが最適です。何はともあれ、最初にmraaをインストールします。これが使えなければわざわざJoulを選択する意味がありません。色々な方法で試して見ましたが、最新のソースをダウンロードしてビルドしたものが一番安定している様です。

 ソースはhttps://github.com/intel-iot-devkit/mraaからダウンロード。解凍したフォルダに入ったら、以下を実行。

sudo apt-get install git build-essential swig3.0 python-dev nodejs-dev cmake libjson-c-dev

mkdir build

cd build

cmake ..

make

sudo make install

sudo ldconfig

sudo ldconfig -p | grep mraa

一応nano .bashrc で 最後に

export PYTHONPATH=$PYTHONPATH:$(dirname $(find /usr/local -name mraa.py))

を追加

 インストールしたら、ダウンロードしたファイルにPython のサンプル(mraa-master/examples/python)が入っているので、blink-io8.py---->内部の x=mraa.Gpio(8)をx=mraa.Gpio(101)に変更。sudo python blink-io8.py でボード上のLEDが点灯するはずです。sudoを付けないとGPIO制御ができないので注意。

f:id:TAKEsan:20161206142706j:plain

                       実行前

f:id:TAKEsan:20161206142705j:plain

どうせならってことでボード上のLEDを全部点滅して見ました(GPIO番号 100〜105)CPUモジュール上のLED 2個も点灯できました。

 ところが、オンボードLEDの点灯確認ができますが、手持ちのLEDをピンコネクタに取り付けたてみたのですが、どんなことをしても点灯できない!!。回路図を見ても全てのピンヘッダは3.3Vに昇圧されているのに.....。試しに予備で取っておいたOstroのSDカードで、Intelご自慢のOstroを起動して試してもダメ。なんてことでしょう。Ostroでも動かないなんて。だから取説のサンプルも基板上のLEDだけなんだと、妙に納得したりして.......。

 あ、そうそう。本体のSDカードフォルダに取り付けたSDカードにもインストールできると思いますが、16G以下に限られることと、転送速度が遅いためUbuntuでは体感スピードはかなり遅く感じます(前回検証)。CPUスピードは変わらないので、外部で使うならアリかもしれません。またOSをインストールしたSDカードを入れっぱなしにしておくとうまく起動できない場合があるので注意。

Joule EXpanson ボードのGPIOがmraaで動かない!!-->動いたぁ。

 肝心のGPIOピンに関して、i2cもPWMもGPIOも全く動く気配がありません。回路図を見るとちゃんと3.3Vレベルシフターが入っているし、宣伝でもピン出力は3.3Vと明記している。でもできない.....。ボード上のLEDは100~105番までちゃんとチカルのに。やっぱりカーネルがおかしいのかななどど考えたのですが、blink-io8.pyを利用してテスターでGPIOを確認すると、一瞬3.3Vになって1.8Vに戻る。OFFだと0V。どうやら内部レベルシフターが正常に働いていない。mraaは真面目に動いてるらしい...。80本のピンを3.3Vに昇圧するために実装している9つのレベルシフターが同時におかしくなるわけがないと思っていた矢先、またしてもHirokazu Egashiraさんからのヒントがありました。何でも非売品を買ったとか。それもJoule Ubuntuにインストールしたmraaで動くとか。ネットで探すと該当商品の説明がありました。

Gravity Expansion Shield for Intel Joule SKU: DFR0465 - Robot Wiki

おまけに回路図も真面目に掲載されています。Gravity Expansion Shield for Intel Joule Schematic

 このボードはExpansion Boardに差し込む形で、GPIOに特化したもの。Expansion Boardにセンサー類を直結すればいいのにと素人は思ってしまうのですが、理由があったんです。よく回路図を見ると全て4.7Kの抵抗が入っている。つまりPull Upが必要カモ。もしやと思いテスター片手に4.7k抵抗を大量に買ってテストして見ると、動きました!!。引っ張る電圧を5Vに変えると最大5Vになりました。これでバンザーイです。

 i2cはちょっと厄介。i2c-0は使えません。ユーザーに解放されているのはi2c-1以降のようです。さらにi2cdetectで12c-0以外はアドレスを確認できませんでしたが、Pull-Upすると動きます。i2c出力用にj12j13 2箇所ずつ同じポートが存在しますが 微妙です。私の場合、内部eMMCにインストールしたUbuntuでは、J13側。SSDではJ12側でしか反応しません。抵抗値が微妙の様ですが、i2cに関して一応4.7k抵抗をつけて動いた方ということで(測定器が欲しくなってきた)我慢。この辺りはIntelが資料を公開すれば、解消すると思われます。

 各GPIO接続方法は以下のとおり。抵抗1本でOKです。外部レベルシフターなど昇圧回路が必要無い点がGoodです。でもなんでこんなことをしなければならないのでしょうか?基盤が小さすぎたのかもしれません。

f:id:TAKEsan:20161206142709p:plain

こんな感じで、GPIO制御する場合はPull UPが必要みたいです。見た目でも信号を引っ張ってる感じが伝わってきます

f:id:TAKEsan:20161206142702j:plain

GPIO51番に接続したLEDを光らせる準備。Pull UP用に5Vを使用。LEDはLillypad用の抵抗付きLEDを使ってます。

 --->その後テストしてみましたが、SPIとUARTは初期設定時点でエラーになり(カーネル4.4.0-100 joule)ます。まだベータ版なのでしょうがないですね。この辺りForum: Intel® Joule™ |Intel Communitiesを見ると最新情報が確認できますが、やはり現時点では接続できないようです。方法が見つかったら追記します。

JouleのEXpanson ボードのピンヘッダは裏からも刺せる!!

 この頃気づいたのですが、これは初めて見る構造です。裏からも刺せる。L型のピンを使えばいい。ジュールはCPUが熱くなるので、迂闊に上部にCPUを跨ぐ様なボードを刺せません。結構使う側を考えたアイディアだと思います。

f:id:TAKEsan:20161206142701j:plain

ピンコネクタがスルーなのが確認できます。こんな感じで裏からもピンが刺せます!!良くできてますね。

JouleでOpenframeworksが動く!!

 私の実験用にはOpenframeworksは最適なC++フレームワークなので、これがインストールできてなんぼの世界なのですが、あっけなくインストールできました。全てのサンプルがソコソコ快適なスピードで動きます。画像処理中、若干息つきが出ますが、CPUスピードを調整すると格段に良くなることがわかりました。(sudo apt-get install indicator-cpufreq

 とりあえず、といっても2日間みっちり時間が必要でしたが、i2cとGPIOをMacで操作するWeb物を作って見ました。今まで作ってきたものの応用です。前回スイッチサイエンスRapiroボードで、Edison環境+Python flaskで作っていたものの中で、c++環境のスピードが要求されるプログラムをopenframeworksに組み替えました。いつもの非接触式赤外線センサー(OMRON D6T)とLEDとWebCameraを使用してます。

 今までは、ブラウザ上のボタン操作後、若干のタイムラグがあり、ボタンの反応が鈍かったのですが、前々からやりたかったofHTTPを応用した、カメラとセンサーの合成画像とLED点滅操作が、リアルタイムで操作できる様になりました。これが可能となれば、1年以上ブログを書いてきた今までの集大成ということになります。手順は、

  • Openframeworks linux64 Ubuntuインストールをマニュアルに従ってインストール
  • 今回必要Addonをaddonsにコピー(-masterは消すこと)     Openframeworksのディレクトリに入って

       cd addons
       git clone https://github.com/bakercp/ofxIO
       git clone https://github.com/bakercp/ofxMediaType
       git clone https://github.com/bakercp/ofxSSLManager
       git clone https://github.com/bakercp/ofxTaskQueue
       git clone https://github.com/bakercp/ofxNetworkUtils
       git clone https://github.com/bakercp/ofxJSON
       git clone https://github.com/bakercp/ofxHTTP
       git clone https://github.com/bakercp/ofxJSON
                         git clone https://github.com/bakercp/ofxJSONRPC

  • mraaとの連携ですが、新しく作成したプロジェクトディレクトリ内のファイルconfig.make中1箇所を修正。

f:id:TAKEsan:20161206150044j:plain

       config.makeの赤線部分を追加。要するにmraaライブラリを追加します。

 ofxIOのみ最近修正されたようなのですが、これが原因でコンパイルエラーが出ます。以前のofxIOに入れ替えればOKでした。ofxIOと今回作ったソースを一応ダウンロード可能にしときます。ofxIOを作った本人(開発者の一人)が気づくまで.....。今回作成したプログラムは、ofxHTTPとofxJONPRCで利用するサーバーを同一ポートで立ち上げるなどという作者が考えもつかなかった様なことを実験的に実行して見ましたが、ちゃんと動きました。ofxIO旧バージョンと今回作ったプログラムは、ここからダウンロードしてください。

http://d.hatena.ne.jp/TAKEsan/files/Joule-OF.zip

 解凍したファイルは「ofxIO」をaddonsへコピー。joule-jpeg-newはapp/myAppsヘコピー後フォルダに入ってmake -j4でビルド。sudo make runで実行できます。赤外線センサー(D6T)はスイッチサイエンスで手に入れることが可能(専用のケーブルが別売ですが必ず必要)。LEDは各自用意して下さい。D6Tセンサーはi2c-1へ接続、LEDは、+側がピン番号51接続としてます。

f:id:TAKEsan:20161206142703j:plain

     LedとOmton D6Tの接続状況。i2cはJ12側のi2c-1に接続。LEDはGPIO51番

どんなのかは下の動画をどうぞ。

         

左側はJoule直結ディスプレイ。右側はMacのサファリでJouleのip及びポート番号を指定してJouleを操作しているところです。D6T赤外線センサーは、認識画素数が4X4に対してJoule側で最大で200倍以上の補間をしてます。Mac側からLEDのオンオフ、温度分布のオンオフ、カラーマップの切り替え、補間精度の調整をリアルタイムで操作できました(動画ではLEDのオンオフがはっきり確認できませんでした。スンマセン)。カメラ画像は800X600でほぼリアルタイムですが、温度分布の方はD6Tの送信スピードが間に合わずギクシャクしているように感じます。こんなことはEdisonやPi zeroでは感じなかったので結構感激でした。

 何してんのかわかんないって?。センサーに温度を検知させててカメラ画像とシンクロさせてるんです。おまけで最高最低温度と検知した場所を表示させてマス。つまり安上がりのサーモグラフィーもどきってワケ。周囲より温度の高い「手先」に反応して動いてるでしょ。もちろん暗闇でも動きます。もともと16分割の温度しか検知できないなんて信じられます?。スイッチサイエンスさんが、わかりやすく解説していますMEMS温度センサを使おう | スイッチサイエンス マガジンが、これの大幅改良版です。

f:id:TAKEsan:20161206144547j:plain

   Mac側のサファリ画面です。左下にある5つのボタンでJouleをリアルタイムで操作できます。

 Openframeworksの長所でもある簡単に作成できるOSC通信で、WROOM02やらPi zeroやらとのデータ通信が高速にできることを確認しているので、Jouleとの連携が面白そうですが、目下の目標はJouleによるLeptonサーモセンサーの稼働です。先月号のトランジスタ技術にLEPTONの解説が掲載されてましたが、すでにPi zero でもWROOM02でも接続方法が確立している上に、画像配信まで実現しちゃってます(i2cでの温度取得も!!)ので私の方が2歩ぐらい進んじゃってるカモ。詳しくは過去記事をご覧下さい。でも、さすが専門誌だけあって、読み飛ばしていた英文マニュアルの要点を解説しているのでとても役に立ってます。

 Lepton との接続に関してEdisonでは苦い経験があるので、同じIntel系のJouleでうまく繋がるかどうかわかりませんが、トライしてみます。これが可能ならばLeptonを2つ繋げてステレオ・サーモセンサーができちゃったりして.....。階調の幅が相当あるので画素が少なくともなんとかなるような気が........。

 何と言ってもビルドのサクサク感が今後の開発意欲を高めてくれます。

JouleでOpenCLが動く!!

 これが実現できれば、内臓されたGPUIntel HD Graphics)を利用してさらにスピードアップさせたアプリが作れます。まだテスト段階ですが、物によりCPU単独の2倍程度早くなることが確認できました。海外の記事ではインストール失敗例ばかり(と言っても多分1人だけ)なので、今回の記事が最初だと思います。

 今回の記事でインストールしたUbuntuカーネルは、4.4.0-1000 jouleとなっていますが、OpenCLをインストールするには、4.7.0以上にする必要がある様です。危ないので(結果的にGPIO,PMWは使えるが、i2cが使えなくなった)、SDカードにインストールしたUbuntuUSB3.0接続)で試すのがおすすめ。

f:id:TAKEsan:20161206145101j:plain

       OpenCL実行用には、SDカードにインストールしたUbuntuを使いました。

 お試し用のSDカードにインストールしたUbuntuを立ち上げたら、まずカーネルをアップグレードします。

How to Install Linux Kernel 4.7.2 on Ubuntu 16.04 LTS - LinuxBabe.Comを参考に以下を実行。

wget kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.2/linux-headers-4.7.2-040702_4.7.2-040702.201608201334_all.deb

 

wget kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.2/linux-headers-4.7.2-040702-generic_4.7.2-040702.201608201334_amd64.deb

 

wget kernel.ubuntu.com/~kernel-ppa/mainline/v4.7.2/linux-image-4.7.2-040702-generic_4.7.2-040702.201608201334_amd64.deb

 

sudo dpkg -i linux-*4.7.2*.deb

 多少時間が必要ですが簡単にインストール可能。再度reboot。まともに動くかどうか心配でしたが、特に問題無く動きました。uname -a でバージョンを確認して カーネル4.7.2に変わっていればOK。

今度はOpenclをダウンロード。ダウンロード先は、

OpenCL™ Drivers and Runtimes for Intel® Architecture | Intel® Software

最初の方に説明しているSDKパッケージのlinux 64bit版をダウンロードして解凍。

 色々試して見ましたが、最終的にダメ元でトライした結果、ダウンロードしたディレクトリに入っているinstall_GUI.sh を実行するだけでOKでした。

 インストーラーはUbuntu14.04が基本で、途中「必要ライブラリが無い」と叱られますが、インストールを中断してメッセージに出たライブラリをapt-getでインストール。それでもエラーが出ますが気にせずに続けると、なんとなくインストールできます。

 GPUを認識していないんじゃ無いかって? この画面を見てください。ちゃんと認識してます!!

f:id:TAKEsan:20161206144543j:plain

   OpenCLを認識してます。Joule HDグラフィックス(GPU)とCPUの諸元が表示されました!!

 確認用に一番手っ取り早いOpenCV2.4.13をインストール。コンパイル中はかなりの頻度でGPUコンパイラが動いているので、一般コマンドも最適化されている可能性があります。インストール方法は以下の通り。

sudo apt-get install qt5-qmake

sudo apt-get install qt5-default

sudo apt-get purge python-pip

wget https://bootstrap.pypa.io/get-pip.py

sudo python get-pip.py

sudo add-apt-repository universe

sudo apt-get update

sudo apt-get install cmake git aptitude screen g++ libboost-all-dev \

libgflags-dev libgoogle-glog-dev protobuf-compiler libprotobuf-dev \

bc libblas-dev libatlas-dev libhdf5-dev libleveldb-dev liblmdb-dev \

libsnappy-dev libatlas-base-dev python-numpy libgflags-dev \

libgoogle-glog-dev python-skimage python-protobuf python-pandas

お好きなOpenCVをダウンロード解凍後(今回は2.4.13)ダウンロードしたフォルダに入って

make build

cd build

cmake  -D WITH_OPENCL=ON -D WITH_QT=ON -D WITH_OPENGL=ON -DBUILD_TESTS=OFF -DBUILD_PERF_TESTS=OFF -DBUILD_EXAMPLES=ON -D BUILD_opencv_python2=ON -D PYTHON_EXECUTABLE=$(which python) ..

make

sudo make install

 これで簡単にOpenCVもインストールできます。コンパイルオプションにOPENCLを入れています。

 ダウンロードしたOpenCVの中に入っているOpenCL用のexample(oclディレクトリ内に存在)を実行して見ます。コンパイル方法は、

  g++ 該当ソース.cpp `pkg-config --cflags opencv` `pkg-config --libs opencv`

コンパイラが働いている証拠にOpenCLの中間ファイル(拡張子.clb)ができてます。

f:id:TAKEsan:20161206181431p:plain

oclサンプルのcppファイルをコンパイルした後、中間ファイル拡張子clbができていた。OpenCLがまともに動いてる!!

 実行できないのもありますが、次の2つのプログラムで実行内容を確認して見ました。

 まずfacedetect。これは遅い!!。GPUの恩恵は感じられません。認識用のデータは opencv-2.4.13/data/haarcascades_GPU/haarcascade_frontalface_alt2.xml を指定します。このデータ以外は実行できない様です。なんとなくGPUメモリが原因みたいな感じでした。もともとOpenCVの顔認識サンプルは、遅いことがわかっていたのですが、これはダメ。(Openframeworksの顔認識の方がはるかに早い!!)

 次にhog。これは人物を認識するプログラム。ちゃんとCPUの2倍早くなってることが判明。効率を追求すればこの倍は行く様に思われます。ちなみにTX1ではGPU ONで今回の5.3倍程度(CPUのみで1.9fpsなのでCPUスピードはJouleが若干上で、GPU ONだとTX1が遥かに上)のスピードでした。i7 6700K CPUオンリー環境でもJoule のGPU ONの2倍くらいのスピードなので、このサンプル自体OpenCVGPUのテストとしては、相当効率が悪い様です。

f:id:TAKEsan:20161206144544j:plain

Mac上で人物を表示させて、Jouleに接続したカメラで人物を認識させているところ。実際の人間ならもっと認識率が上がるカモ。GPUが4.4fps前後であることが確認できます。

         

GPUとCPUの切り替えをしている動画です。画面に映っているテレビ画面の動きでスピードの感覚が掴めると思います

 てな訳で一応ちゃんと動きました。外付けGPUにはとても叶いませんが、少しでも早いソフトを作りたい方は最適かと思いますが、いかんせんカーネル4.7.2では、i2cが使えません。(/dev にi2cポートが現れない)対処方法はインテルの資料待ちといったところでしょうか。また、内部エラーが時たま出るので、システムが不安定になります。付け加えると、GPUプログラム実行時Jouleモジュール自体、かなり発熱しますので冷却体制は万全に。

 やっと本題

Intel Joule はEdisonやPi3 との価格差を超えられるか?ですが、

  •  CPUスピードは、Edisonの10倍、Pi3の3倍くらいの差が確実に体感できる。
  • GPIO制御に特別の外付け回路が必要ない(抵抗が必要だが)。
  • 本体のみでプログラム開発がサクサク。
  • はるかに拡張性のあるUbuntu環境が簡単に実現できる。
  • Wifiが実用レベルで動く(Pi3やTX1と比較して非常に安定している)。
  • GPGPU(OpenCL)を使ったプログラムが組めるので、さらにスピードアップが期待できる。

 Ubuntuがノートパソコン並みにサクサク実行できて、GPIOが使えれば、価格差なんか糞食らえになっちゃいます。使用感の次元が違うので、この種の趣味を持つ者とすれば天国ですよね。でもEdison(WROOM02やPi zeroも!!)についてはIOT制御面での優位性は確実にありますので、これらを適所で組み合わせることで素晴らしいモノが作れると思います。

 Pi3を色々試してみると、どうしてもSDカードのスピードの壁に突き当たって来ます。Pi3ユーザーの一人として、こうしてJouleを色々実験してみると、私のPi3へのプログラム処理能力の期待度は、結局Jouleだったんだと分かって来ました。過去、私を含めた批判者の多いモジュールでしたが、Jouleについて初期の頃感じていた不満を1つ1つクリヤしていくと、計り知れない底力を秘めていることを感じてしまいます。

 Joule唯一の欠点は、外部へ持ち出した時、電源への配慮が必要なことでしょうか。 Ubuntu環境では、USB C へ3A程度の電源供給ではシステムが初期ダウンしてしまいます。基板上に電源用のパターンが存在しているので、この辺も追求したら楽しそう.....。

 結論になってませんが、そもそも比較する対象が違うっ。という曖昧な答えを出して今回は終了。

 少し長くなりましたが、今年はこれで終わりにします。これから少し家の修理とか、正月の準備とか、庭の手入れとかに精を出したいと思ってます。そのあたりで何か発見があればまた書きたいと思います。

 

                        では、また。あー疲れた。

 

 

 

Juneちゃん その後。

 やれIntel jouleやら、Nvidia TX1やら、ゲームパソコンやらちょしてる(仙台弁触ってるの意)事に限界を感じてきたので、今回は私のストーカー犬「ジュン」ちゃんの近況です。

 ところでトイプーって毛が抜けないの知ってました?ほっておくと着古した毛糸のセーターみたいに毛玉だらけになっちゃいます。初めの頃は知りませんでした。

 今年は3歳。夏バテ防止のためサマーカット(丸刈り!!)を2回ほど経験してやっとこうなりました。

f:id:TAKEsan:20161127194546j:plain

f:id:TAKEsan:20161127194547j:plain

 お腹のタプタプがチュッチュッチュッ〜なんですけとワンちゃんを飼ってない人はわからないでしょーね。

 モッップ状態。これがカワイくなるんでしょーか?。今までだとある程度長くなると形が整ってくるんですが、今回は全くダメ。基本のカットバランスがものすごく悪い。今までのトリマーさんが変わったみたいなのが大きな理由。変わったトリマーさんはどうやら初心者のようです。自分の娘みたいなもんなんで、「カワイ」くしたいのは飼い主のサガ。

 思い切って、違うところに頼んでみました。

f:id:TAKEsan:20161127201714j:plain

惚れ惚れするようないい女!!

f:id:TAKEsan:20161127201715j:plain

尻尾のくびれが......ソソル。

f:id:TAKEsan:20161127201716j:plain

セクシー!!

3日後

f:id:TAKEsan:20161127202629j:plain

今度のトリマーさんはまつ毛を残してくれたのに気づきましたました。

f:id:TAKEsan:20161127202632j:plain

まつげの先がキュンと跳ね上がってました。

f:id:TAKEsan:20161127202630j:plain

 思い切ってマスカラで黒くしようと思いましたが。気持ち悪くなるのでやめました。もう少し頭の先が伸びると最高。こんな感じで365日見つめられているのもなんか後ろめたさがあったりして.......。

                             ではまた。

   

 

 

 

 

Jetson TX1 で py-faster-rcnn を使ってmjpeg 配信できたら幸せ!! そのほかモロモロ。

てな、馬鹿げた表題をつけたものの、本当にできるんでしょうか?

 何に使うのかって?。外に持ち出すには最低7インチのディスプレイが必要です。配線や電源も考えなければいけません。これがケータイで代用できたらとっても便利。がさばるディスプレイの代わりにケータイを使うのが最終目的。

 TX1で物体を認識した動画を、iPhoneで受信!?。考えただけでザワーっとします。つまり、その作成過程を考えるだけで吐き気がっ。

 今回の記事はJetPack-2.3環境すなわち全部64bit環境な場合です。また、homeにプレインストールしてあるjetson_clocks.shを実行し、GPUクロックを最大にしてます。

f:id:TAKEsan:20161111105719p:plain

今回の最終形。1度に複数の物体を認識している(テレビの中の人物も)。これがTX1から送られたmjpeg動画の一部画像です。動いている様子は以下のMoveファイル参照。

ザワーの1回目

 まず肝心のPy-Faster-RCNNインストール。このダウンロードしたフォルダの中で、専用に修正されたCaffeのビルドが必要です。経験上すんなりとインストールできない予感があったのですが、やっぱり的中。少し探すとForumに書いてありました。要するにCuda8.0に対応してないとのこと、

https://devtalk.nvidia.com/default/topic/974063/jetson-tx1/caffe-failed-with-py-faster-rcnn-demo-py-on-tx1/

 これを参考(中程に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の書き換え。内容は以前の記事を参考にしてください。いつものようにビルドして、以下の記事の

GitHub - rbgirshick/py-faster-rcnn: Faster R-CNN (Python implementation) -- see https://github.com/ShaoqingRen/faster_rcnn for the official MATLAB version

2番目あたりから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

ざわーの2回目

 mJpeg配信とくればSimpleCV!!。同じPythonなので簡単に...。Camera画像の変換が重要な問題だとはわかっていたのですが、少し風邪気味でタダでもボケボケの頭が、さらにボーケボケ。構想2日、実務が半日で、やっとdemo.pyを書き直した物が次のソースです。一応動くだけですが。

id:TAKEsan の mjpeg.py

py-faster-rcnn-->toolsへ保存したら、40行目付近の

     js = JpegStreamer("tegra-ubuntu.local:8090")

の赤字部分を自分のip環境に変更して下さい。

cv2-->SimpleCVのイメージデータ変換(たった1行)だけがキモでした。ソースを全部コピー(最後の1行が見にくい)して mjpeg.py とかで名前を付けて保存。そしてUSBにカメラをつないだら、

                   python bokeboke.py --net zf   <-----直したつもりなのにボケボケでした

                   python mjpeg.py --net zf

を実行。MaciPhone のサファリから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環境のデープラーニング応用環境が現実味を帯びてきた

 この頃はもっぱらTX1Intel Jouleの個人的な性能評価やらインストール作業やらに熱中してしまって、まともにプログラム作成に向き合っていません。あっちこっちに首を突っ込んで当初の予定だったニューラルネットワークに関するお勉強がそっちのけになっています。

 まーその流れで。Jetson TX1の最先端はどちらに向かってるか探りを入れてみました。この方が鍵を握っているようです。

github.com

 Nividiaでは、Jetpack2.3になってから、TenserRCがどうのコウノト言ってますが、果たしてこれは何?。発売当初からFloat 16演算を行うと、スピードが1Tが出るとかなんですが、実質的な実現例が提示されていないばかりか、Float16のcaffeもイマイチ中途半端でした。ましてTensorRCはこのFloat16に特化したと言いながら、何も具体的な情報が無い。やっと重い腰をあげたみたいなので、以下実行結果を私なりの理解度でご報告。でも未だにTenserRCが何者なのか、わかっていない。

まずTorchはどうなったのか。

 この方が「できるできる」と言っていたものが、少し前にやっとgithubで公開されています。自分で試して見て初めてわかったんでしょうね。ちなみにTorchはTenserRCとは無関係。TX1のCuda8.0対応版です。

GitHub - dusty-nv/jetson-reinforcement: Deep reinforcement learning libraries for Jetson and online training

 記載されている手順通りで無事インストールできました。開始はいつものthではなく./deepRL-consoleでした。仕組みが理解できていませんがOpenblas、torch、torch7,cutorchが同時インストールされます。標準Luaライブラリは nn,cutorch、cunn、などがプレインストール。他のLuaライブラリは、Luaにパスを通せば簡単にインストールできます。例題はこんなのです。ピンポンゲームの学習。

                                


 以前入れた早稲田大学の白黒カラー化ソフトを実行させてみると。

takesan.hatenablog.com

(ソース中のargではコマンドラインで指定したファイルを認識しないので、直接ソースに画像指定してやります。この記事に書いてあるように追加のLuaライブラリが必要)
OpenBlas関連の実行時エラーが出ますが、ちゃんとカラー化できました。気になるテスト用に入っている風景写真の変換スピードは、以前のjetpack2.2と比較すると、60秒の実行時間に対して、今回は20秒40秒も実行スピード早いのです(i7 6700k+1080環境では4秒程度ですが)。データの読み込みや演算共格段の進歩が見られます。いよいよTorch+TX1がモバイル環境で現実味を帯びてきました。

TenserRT

 これはなかなかでした。DIGITSで作成した学習データの応用例です。

GitHub - dusty-nv/jetson-inference: Guide to deploying deep-learning inference networks and realtime object detection with TensorRT and Jetson TX1.

カメラを使ってリアルタイムで学習結果を表示します。

 まず30fpsくらいで、とにかく手当たり次第、物体認証結果を表示するプログラム。Caffeのexampleの中にあるWeb-Testを使えば私にもできそうな感じ(スピードはここまでは確実に上げられない)です。

       

どこを認識しているのかがわからない点が残念ですが、とにかく速い!!。せめて点くらい表示させたらいいのに....ブツブツ。

 物体の認識が組み合わさっているのに、目にも止まらぬ実行スピードです。出力単語をよく見ると、それらしい物体として認識されてます。

 次にリアルタイムObject-Detect認識をTX1で実現させたプログラム。人物群と物を同時に判断できるようです。(スピードを度外視すれば性能は今回取り上げたpy-faster-runが上!!)こちらはさすがにだいぶゆっくりですが、ホビーでは実用レベルです。すごい。

        

動画では判断しにくいですが、人物を見つけると青の四角が表示されます。今回実験したmjpeg画像に比較すると格段に速いことが確認できると思います。
 そもそも例題を実行すると、画像が上下逆!!。プログラムの中身を見て変更しようにも、複雑で何が何だかわからない。もっと単純にできなかったものなんでしょうか。評価用としては、プログラム中のコメントが少ないので解析に時間がかかりそうです。表示部分がおかしいような感じ。当分は、カメラをひっくり返せばいいことなんで、気にしない気にしない。
 この方は同じgithubページ上に16bitCaffeのインストールスクリプトも自信を持って書いてますけど、OSが1つ前のものなので、run testがうまくいきません。どうも他の記事を読んでも、TX1に関しては、神の存在だと思ってるみたいな気がしないでもない。内容の割に、質問や閲覧数が少ないのは、この辺りでアメリカのみなさんも引いてしまうんでしょうね。

 記事を発表している人物が、メーカー側ですから消費者として率直な感想を書きました。がっ、やってることは納得です。こういうものを見せられると、寒気が。つまり「機械が自分を守るための単純な何かについて、人間がヒントを与えた時。ニューラルは空恐ろしいほどの進化があるのかも」です。

 DIGITSで学習させたObject-Detectデータが使えるようなので、次の機会に試してみることにします。TX1のフォーラムでは、「こんなに遅いのに」的に言ってる人がいますが、要はどう応用して使うかの問題なので、基本的なスピードがこれならば、十分実用的だと思うのですが、いかがなものでしょうか。 

※2017/1/19:この後TX1へのOpenFrameworksインストールに成功して、OF上で上の動画より早く実行できるようになりました。おまけに入出力の「とっつきにくさ」が解消されます。

takesan.hatenablog.com

 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)

TX1でもJouleでも内部eMMCはTRIMが実行できる。

 これはlinuxSSDを使ってるみなさんならご承知の通り、SSDの延命と実行スピードを維持するための必需品

      sudo fstrim -v /

です。これが実行できた=TRIMが実行できたです。本体内部のeMMC寿命=超お高い本体CPUの寿命につながりますので、思い出したらやってみましょう。

 

                              では、また。

Intel Joule にUbuntu14.04をインストールしてみた。

 Intel JouleにUbuntuをインストールして普通に動かせたら。かなりワクワクしますよね。

※11/24  かなり簡単にインンストールできるようになってます。現在執筆中!!

----->12/6  完了。下の記事参照。Ubuntu16.04、外付けSSDにも簡単にインストールできて、mraaでGPIOも制御できた上に、OpenCL(GPGPU)の動作確認までできちゃいました。

takesan.hatenablog.com

以下の記事はUbuntu14.04をインストールしたい場合参考にして下さい。 

f:id:TAKEsan:20161103220858j:plain

 画面のもたつきとGPIOの制御ができない(執筆時点では気付かなかったのですが、sudoをつければボード上のLED制御可能。多分Pull UPすれば、大部分のGPIO制御が可能です)ことを我慢すれば、ちゃんとしたものになったので、どんな状態なのかも画像でついでにご報告。今回は、この記事の

communities.intel.com

成功例を使わせていただきました。結局、記事を最初に書いたKhaosさんが説明している通りでした。後の方でMcCoolさんが補足していますが参考になりません。混乱するのでやめた方が良いと思われます。KhaosさんはかなりLinuxに精通しているらしく、私のような初心者では中間が抜け過ぎています。でも。最終的にインストールができてみると、こんな短い英文に、よくぞこんなに盛り込んだと思えるくらいヒントが隠されてます。今回は補足という形で記事を書きました。ただし、IntelからJoule版Ubuntuが正式発表されるまでの命です。

 私は本体eMMCにインストールしてしまったのですが、後で元に戻すのが厄介なのでSDカードにインストールした方がベターです。今回は、SDカードインストール方法を紹介します。インストール先を変更すれば、簡単に内部eMMCにもインストールできますが、あまりオススメできません。例によってlinux初心者+αなので力技で処理しています。なので精通している方はもっとインストール過程がスマートになると思います。

用意するもの

  • SDカード16G以上(Ubuntu実行用。価格が高くなるが、なるべくスピードの速いもの)
  • USB3.0用のSDカードリーダー
  • USBメモリ16G程度(インストールディスクとして使う)
  • USB3.0用のUSBハブ(4口程度がベター。補助電源なしでも今の所快適)
  • 専用のHDMIケーブル

 本体のSDカードフォルダはスピードが遅く(ubutu実行時入力が相当もたつく)16Gまでという壁があるのでUbuntuはインストールしない方が良いと思われます。今回はUSB3.0にSDカードリーダーを介したSDカードにUbuntuをインストールします。まー遅めのSSDと言いましょうか。Ubuntuを使う限りはサクサクです。USB3.0ですから本物の外付け小型SSDを付ければもっとサクサク。

 Ubuntuのインストールは、かなりスピードの速いソニーのUSM-W3というUSB3.0対応のUSBメモリでも試してみましたが、USB2.0並みの操作感でした。つまり遅くてUbuntu実行環境では使えません。今回の検証はUSB3.0対応カードリーダー+SanDisk Ultraです。また、Joule本体がかなり熱くなるので小さなFanが必要。無い方はウチワであおぎながら作業しましょう。

 f:id:TAKEsan:20161104080359j:plainf:id:TAKEsan:20161104080400j:plain

インストール準備

 まずインストール用USBメモリをを用意して、通常通りインストールディスクを作ります。最初から日本語化してある理研などのサイトからダウンロード。作成方法は他のサイトを当たって下さい。(今回はUbuntu14.04)

Joule本体にキーボードとHDMIディスプレーを本体につなぐ

 キーボードは、ファンクションキーである「F2」が直接打ち込める標準キーボード(無線やFnキーを押さないとF2を認識しない小型キーボードではBIOS設定ができなくなる可能性大)BIOS設定ではJIS標準キーボードだと特殊記号が文字化けするので、 = /  \  : + - の位置を入力時確認する必要があります。

インストール用のUSBメモリをUSBハブにつなぐ

  • Jouleの電源ON
  • 本体のランプが4つ点灯した頃F2キーを押す。
  • 画面がBIOS設定に切り替わるの矢印キーで以下を選択
  • Boot -> F2 -> Boot Manager -> EFI Internal Shell

f:id:TAKEsan:20161103220848j:plain

f:id:TAKEsan:20161103220854j:plain

f:id:TAKEsan:20161103220855j:plain

                                      ここで EFI Internal Shellを選択すると、f:id:TAKEsan:20161103220857j:plain

      Shell画面になる。画面ではfs0:を入力後lsコマンドを実行している

なんだか訳のわからない表示が出てきますが、Shellがスタートしています。なので普通のlinuxコマンドが実行できます。この状態になったら、最初に「UbuntuインストールUSBメモリ」を選びます。通常は、fs0: のようです。

  • fs0:  エンター

 必ず : を付けること。ここで装置記号を入力しないとShellコマンドが実行できません。記憶装置名を入力したら、lsなどのコマンドを入力して、ファイル構成を確認して見て、選択した記憶装置が正しいものかどうかチェック。違っている場合は慌てずにexitを入力すると初期状態に戻るのでもう一度やり直しすればOK。直接画面では肝心の FS◯◯ 部分がスクロールされてしまうので、内容がfs0:でない場合は、fs0: から Fs4:くらいまで試して見ます。多分Fs0:でOKですが.....。Ubuntuインストールディスクはrootにcasperというディレクトリができているのですぐに判別できます。(一応他のlinuxマシンでcasperディレクトリが存在するかどうか事前に確認しておくと、安心)

  • cd casper

を入力して、casperに入ったら、めんどくさいですが以下を入力。この時、特殊記号の入力に注意すること。この時点でキーボード配置を確認しておくと後々便利。

  • vmlinuz.efi initrd=/casper/initrd.lz file=/cdrom/preseed/ubuntu.seed boot=casper quiet splash ---

---まで一挙に入力したらエンター。スペルは正確に!!。

 ドキドキしますが、しばらくすると見慣れたUbuntuの画面が現れます。ただしこれはインストール用(CDイメージ)ですから他のアプリはインストールできません。とりあえずここで、ディスクトップ画面から家庭内のwifiに接続しておきます(簡単に接続できるはず)。Ubuntu画面が出てこないでシステムが止まってしまったら慌てずリセットボタン(パーワーボタン長押し)を押して、再挑戦。casperディレクトリの有無やスペルの確認をしてみて下さい。

 標準でGpartedがインストールされているので、USB3.0用カードリーダーに高速SDカードを挿してUSBハブに接続してから、Gpartedを起動させ、SDカードのフォーマットを行います。すでにsdaはインストールUSBメモリに割り当てられているので、新たにつないだSDカードはsdbの筈です。ここで新たに2つのパーテーション(sdbに)を作成しますが、詳しくはGpatedの使い方を確認してください。前方に500MiB程度のfat16、後方の残りをext4にフォーマットします。前方にfat16を作らないとJouleのBIOSがこのSDカードを認識しないのでここが重要なポイントとなります。

f:id:TAKEsan:20161103220856j:plain

この時は内部eMMCにインストールしたのでmmcblk0になっているが、SDカードはsdbになっているはず。パーテーションはこんな感じで2つ作る。(fat16,ext4ext4はsdb2になっていることになる)

あとは、sdb2を/に指定して通常のUbuntuインストールを実施します。インストールが終了したら、再起動しないでそのまま、yoctoがプレインストールされている内部eMMCの第一パーテーションの中身を全部sdb1にコピーします

   認識している外部記憶装置は、/media 以下に全部マウントされているので、端末を立ち上げ、sudo cp -a を使ってフォルダごとコピーします。/media 以下にぶら下がっているディレクトリは、こんがらがってしまうので、中身を確認して間違えないように名称を確認してください。(英数字の羅列になっている)つまり内部eMMCに作られているBOOT部分をそっくり新しく作ったSDカードの第一パーテーション(fat16フォーマット)にコピーしてしまうわけ。コピーするディレクトリ構成は2つだけです。

                            EFI

                                --BOOT

次に端末からSDカードの第一パーテーションに入って、sudo で ubuntuフォルダを作ります。フォルダ構成は(ubuntuフォルダは、EFIの直下にBOOTと同位置に作る)

                            EFI

                                --BOOT

                               --ubuntu

今度は今作ったubuntuフォルダに入って

       sudo cp -a /boot/* 現在のディレクト

を実行して第2パーテーションに作られたboot以下のファイルをめんどくさいので全部コピー。さらに端末から、今コピーしたファイルの中のvmlinuz-4.4.0-31-generic を vmlinuz-4.4.0-31-generic.efi に名称変更。これで下準備完成。

 チョット複雑そうですが、よく考えてみると簡単なことに気づくと思います。コピー方法はこの他にもmountコマンドを使うなり好きな方法で。

いよいよ起動

  • まずインストール用のUSBメモリを抜きます。
  • SDカードを挿したUSBカードはそのまま挿しっぱなし。
  • システムをrebootしてF2キーを押しBIOSを立ち上げます。
  • Reboot -> F2 -> Boot Maintenance Manager -> Boot Options ー> Add Boot Option  を選択

f:id:TAKEsan:20161103220849j:plain

  • 矢印キーでUSBカードらしき部分を選択します。選択した記憶装置が正しければ先ほど作ったubuntuフォルダが選択できるので

f:id:TAKEsan:20161103220850j:plain

              違う場合はEscで変更が可能です。

f:id:TAKEsan:20161103220852j:plain

 ここではBOOT名称はUSB-UBUNTUにしている。カーソルで選択してEnterを押さないと入力できない。スクリプトを入力しているところ。

名称は自分の好きな名前で。スクリプト

root=/dev/sda2 initrd=\\EFI\\ubuntu\\initrd.img-4.4.0-31-generic ro rootfstype=ext4

です。赤文字部分ですが、先ほどフォーマットした時はsdbですがubuntuインストールUSBメモリを抜いているので、自動的にsdaになります。数値は2なのでお間違いなく。F4キーを押して保存した後ESCキーを押してBIOS設定初期画面に戻った後

Boot Manager->今作った設定ファイル名選択で..................Ubuntuが起動!!

f:id:TAKEsan:20161103220855j:plain

          Boot Manager で先ほど作った USB-UBUNTUを選択

起動方法は順序を設定するより、Boot Managerから選択するのが一番確実なようです。

 注意点としては、UbuntuをインストールしたSDカードを抜いてしまうと、設定ファイルが消えてしまうようなので、再度起動スクリプトを書いてやる必要があること。まー暫定ですからガマンガマン。

Openframeworksインストール

 Openframeworksは、標準Linux64版をダウンロードすれば問題なくインストールできました。いつもの3D Exampleをビルドすると、スピードが早いものの「もたつき」があります。ただしコンパイルスピードがPi3とは比較にならないくらい早い。

         

その他

  • apt-getが確実に使えるので、pip、pygame、SimpleCVは簡単にインストールできました。pypyなんかもインストールできて、当然ですが標準Pythonより物によっては10倍以上早くなります。
  • SimpleCVを使ったMJPEG配信では、USBカメラはちゃんと認識するのですが、なぜか配信スピードがEdisonより大幅に遅くなってしまいます。

        

JouleでSimpleCVを使って配信した360X240のWebCamera映像をMacのサファリで表示している。ものすごく遅い。OpenframeworksのOfxHTTPを使えば改善できるかも。後からSimpleCVで顔認識させたら480X270で8〜10fpsくらい出る。不思議不思議。タイミングの問題か?

  • mraaはソースからビルドできますが、全くGPIOを認識しません(実行時GPIOエラー。USBが使えたとしても現段階ではJouleの本領を発揮できません)。
  • GPIOを無視すれば、音声までは試してませんが、動作がぎこちない部分はあるとしてもほとんどのアプリが動くと思われます。
  • Jouleはかなり頻繁にCPUクロックが変化(800〜2400kHz)するので、スピードを固定すると多少画像のギクシャク感が解消できるかもしれません。

https://software.intel.com/sites/default/files/comment/1716807/how-to-change-frequency-on-linux-pub.txt

その後

  sudo apt-get install indicator-cpufreq

でCPUスピードを簡単に変えられました。インストールしたらreboot後右上に表示されたインジケーターで調整。何もしないと直ぐに0.8GHzに変わるみたいです。だから直ぐに反応が鈍るのか...。フーム。

最後に

 今回はSDカードを使ってのUbuntuインストール方法でした。寿命のある内部eMMCを使わないだけ精神的に気が楽になります。失敗を恐れずに何回でも試行できますので、説明不足のところは挫折しないで最後まで頑張ってみてはどうでしょうか?。私ができたのだから必ず成功します。本家がUbuntu稼働を発表した時にはそれよりも良いものになったりして...。マサカねー。

 Jouleの内部eMMCはかなり性能が良いみたいです。LinuxSSD使用者ではおなじみのTrimコマンドを実行可能。延命とスピード維持を確保するため、たまにfstrimを実行した方が良いかもしれません。

  例: sudo fstrim -v /        

       (内部eMMCでブートした場合。SDカードなどの場合は / を変更)

 

                                では、また。

 

 

 

 

 

 

 

 

 

  

 

 

 

 

 

 

 

 

 

Jetson TX1 でUSB3.0につないだSSDからUbuntuをBootしてみる。

 JETSON TX1の電源が壊れてから1.5ヶ月。

 交換品が戻ってきました。

f:id:TAKEsan:20161015142959j:plain

                  Jetson TX1本体はこんな感じ

f:id:TAKEsan:20161015143000j:plain

             分厚いアルミの放熱版でサンドイッチされてます。

 ちょうどJetpackが2.3にアップデートされていたので、最新版をインストールしてみました。最初の感想は、画面のもたつきや、起動時のHDMIディスプレイの認識不良がなくなり、市販ノートパソコン並みにとてもスムース。Bluetoothに接続した入力機器を起動時からストレスなく認識するようになりました。なぜかバージョンアップで、CPUスピードもintel Joule並みに早くなってます。下の方にZEDステレオカメラで画像測定を実行している動画を載せましたので、確認してみてください。

 待った甲斐がありました。やっぱハード発売からソフト安定まで1年以上かかるんですね。また、USBにつないだWebCAMERAをやっとVideo0で認識できるようになりました。ということは、OpenCVのカメラ系Exampleが修正なしで動くようになります。

 逆に弱点は、標準OpenCVやCaffeのインストールに特殊な前処理が必要になったことです。Torchに関して、現状インストールできないといった方が良さそうな感じです(時間の問題でしょうけど)。この辺りは後述します。

ここまで良くなると次はU-BOOTでOS選択。

※OSが3.1以降ではここに記述した方法ではSDカード、USB3.0共うまく起動できないようです。現在検証中なのでしばらくお待ち下さい。2018.3.20

 すなわち、本体内蔵のeMMCを使わずに、SDカードでUbuntuをブートさせることです。これが簡単にできると、応用の幅がグンと広がります。これが思いの外簡単に実現できました。いつものようにその後が地獄でしたけど。

f:id:TAKEsan:20161017200727j:plain

今回取り上げたSSD、Bluetooth入力機器、ZEDカメラを最小のマザーボードにTX1を取り付けてつないで、UbuntuはSSDから実行させてます。今回の操作は、すべてマザーボードにObrbitty Carrir for Jetson TX1を使ってます。

f:id:TAKEsan:20161017200728j:plain

              TX1の大きさはPiとほぼ同じ

SDカードでUBUNTUブートを実現させるには

ヒントは

https://devtalk.nvidia.com/default/topic/923800/boot-from-sd-card/

の中ほどに書いてありました。次のようにします。

まずNvideaのホームページから

Embedded Download Center | NVIDIA Developer

最新版のSample filesystemとDriver PackagesをTX1にダウンロードします。ダウンロードしたファイルは今回バージョンの場合以下の2種類です。

          Tegra210_Linux_R24.2.0_aarch64.tbz2

          Tegra_Linux_Sample-Root-Filesystem_R24.2.0_aarch64.tbz2

 バージョンアップしたTX1にはWebブラウザが全く付いていません。(実はコマンドラインからchromium-browser と打ち込むとchromiumブラウザが立ち上がるんですが)

  sudo apt install midori

で軽量なMidoriブラウザをインストールしました。ダウンロード用だけなら、TX1ではスピード的に全く問題ありません。

 ダウンロードにはNvideaへのログインが必要ありません。(現状の最新版は24.2です)当然最初は、本体のeMMCブートとなりますが、通常のバージョンアップをすると最終でも60%近くのeMMCディスク領域を使ってしまうので、ここからの操作は、ext4にフォーマットしたUSB接続SDカードなどで行うのが最良。本体のSDカードスロットは、OSインストール用に使います。

 まず、gpartedなどで、本体にセットしたSDカード(16G以上)をext4でフォーマットします。フォーマット領域は全領域で構いません。この時フォーマットした領域がemmcblk1p1であることを確認してから、TX1に上記2つのファイルをダウンロードしたディレクトリで次のコマンド群を実行。手っ取り早いのはdfコマンドで、ディスク接続内容を確認すればOK

f:id:TAKEsan:20161015103318p:plain

上の例では.dev/mmcblk0p1が内部eMMCの第1パーテーション、/dev/mmcblk1p1がSDカードスロットにセットしたSDカードの第1パーテーション。ちなみにsda2はUSBに接続したSSDの第2パーテーションです。

 今回の外部メモリへのOSインストール方法の良いところは、TX1上で全ての操作ができてしまうことです。操作は以下のようにコマンド入力します。朱書きで書いたディスク名称はくれぐれも間違えないように!!。この部分でOSの書き込み先を変更できます。

sudo tar xvpf Tegra210_Linux_R23.2.0_armhf.tbz2
sudo mount /dev/mmcblk1p1 Linux_for_Tegra/rootfs
cd Linux_for_Tegra/rootfs
 sudo tar xvpf ../../Tegra_Linux_Sample-Root-Filesystem_R24.2.0_aarch64.tbz2

 cd ..
 sudo ./apply_binaries.sh

これだけです。コマンド間でちょっと時間が必要ですが、あとはブートディスク選択部分を書き換えるだけ。書き換えるファイルは、本体のeMMC入っている extlinux.confです。

cd /boot/extlinux

sudo nano extlinux.conf

次の様に直します、

TIMEOUT 30
DEFAULT sdcard

MENU TITLE p2371-2180 eMMC boot options

LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
INITRD /boot/initrd
FDT /boot/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
APPEND fbcon=map:0 console=tty0 console=ttyS0,115200n8 androidboot.modem=none androidboot.serialno=P2180A00P00940c003fd androidboot.security=non-secure tegraid=21.1.2.0.0 ddr_die=2048M@2048M ddr_die=2048M@4096M section=256M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 debug_uartport=lsport,0 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec=${lp0_vec} nvdumper_reserved=${nvdumper_reserved} core_edp_mv=1125 core_edp_ma=4000 gpt android.kerneltype=normal androidboot.touch_vendor_id=0 androidboot.touch_panel_id=63 androidboot.touch_feature=0 androidboot.bootreason=pmc:software_reset,pmic:0x0 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait

LABEL sdcard
MENU LABEL sdcard kernel
LINUX /boot/Image
INITRD /boot/initrd
FDT /boot/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
APPEND fbcon=map:0 console=tty0 console=ttyS0,115200n8 androidboot.modem=none androidboot.serialno=P2180A00P00940c003fd androidboot.security=non-secure tegraid=21.1.2.0.0 ddr_die=2048M@2048M ddr_die=2048M@4096M section=256M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 debug_uartport=lsport,0 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec=${lp0_vec} nvdumper_reserved=${nvdumper_reserved} core_edp_mv=1125 core_edp_ma=4000 gpt android.kerneltype=normal androidboot.touch_vendor_id=0 androidboot.touch_panel_id=63 androidboot.touch_feature=0 androidboot.bootreason=pmc:software_reset,pmic:0x0 net.ifnames=0 root=/dev/emmcblk1p1 rw rootwait

LABEL usbssd
MENU LABEL usbssd kernel
LINUX /boot/Image
INITRD /boot/initrd
FDT /boot/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
APPEND fbcon=map:0 console=tty0 console=ttyS0,115200n8 androidboot.modem=none androidboot.serialno=P2180A00P00940c003fd androidboot.security=non-secure tegraid=21.1.2.0.0 ddr_die=2048M@2048M ddr_die=2048M@4096M section=256M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 debug_uartport=lsport,0 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec=${lp0_vec} nvdumper_reserved=${nvdumper_reserved} core_edp_mv=1125 core_edp_ma=4000 gpt android.kerneltype=normal androidboot.touch_vendor_id=0 androidboot.touch_panel_id=63 androidboot.touch_feature=0 androidboot.bootreason=pmc:software_reset,pmic:0x0 net.ifnames=0 root=/dev/sda1 rw rootwait

 簡単に言えば元々記述してあるデータ extlinux.conf(黒部分)をコピーして、2回ペースト。各々青の部分を変更するだけです。ブート指定は緑の部分です。sda1とはUSB3.0に接続した外部記憶装置のこと、とりあえず追加しておくと後で便利。ここではsdcardでブートする設定です。内部eMMCブートの場合は緑の部分をsdcardからprimaryに変更するだけです。

 ブートは内部eMMC上の/boot/extlinux/extlinux.confで判断する様なので、SDカードからBOOTしてもファイルマネージャーで内部eMMCを変更できるのでどうにでもなります。

 くれぐれもextlinux.confの書き換えは注意してください。間違えるとTX1に直結したターミナルでないとBOOTできなくなります。完了したら、 

sudo reboot -f

ワクワクの時です。

一応SDカードからBOOTできたものの

 なんか反応が鈍すぎる。まるで一時代前のPiでXwindowを操作してるみたいな....。

考えてみたら当然ですよね。どんなに早いSDカードを入れても、USB2.0並みの読み書きスピードですから。そこで、USB3.0対応のSDカードリーダーにSDカードを差してUSB3.0へ接続。extlinux.confの「DEFAURT sdcard」をDEFAURT usbssd に変えてrebootしてみました。こうすると内部eMMC並みのスピードになります。ここでUSB接続のSSDに変えたらどうなるんでしょ。そこで

USB3.0に接続したSSDにUbuntuを書き込んだら

(SSDにUbuntuをインストールして、上記茶色のemmcblk1p1 を sda1に変更してリブート)

さらにサクサク快適!!。ノートパソコン並みになりました。でもここからが大変。

CUDA、cuDNN、OpenCV2.4.13、Caffeインストールがなかなか...。

 インストールしたUbuntuは、見た目がサクサクでも。サードパーティーのアプリケーションがインストールできない。という最悪の状況。

 ここからは失敗の挙句なんとか使える様にした結果です。Linuxに精通している方は笑っちゃって下さい。

まずCUDAインストール

 標準JetpackインストールでeMMCのhomeにインストールされたCuda-l4tをディレクトリごとBootしたhomeへコピー。

cd cuda-l4t 

./cuda-l4t.sh cuda-repo-l4t-8-0-local_8.0.34-1_arm64.deb 8.0 8-0

でcuda8.0がインストールできます。でもこれだけではcuDNNが使えません。

次にcuDNN5.1インストール。

 一般的なlinuxへのインストール方法では全くダメでした。TX1へのインストールは、Ubuntu母艦環境でTX1のインストール時にダウンロードされたcuDNN-v5.1.zipを母艦からTX1のhomeへコピーすることから始めます。コピー方法はSDカードを使うなりなんなり各自考えて下さい。

 とにかくコピーしたら解凍して、中にあるlibcudnn5-dev_5.1.5.-1+cuda8_arm64.debを使います。同じディレクトリから、

sudo dpkg -i libcudnn5-dev_5.1.5.-1+cuda8_arm64.deb

sudo apt update

を実行。

これを実行するとdevcudnn-xxxxxをインストールしろとかなんとかメッセージが出るのでこの通り sudo apt install XXXXXXXX でcuDNNをインストール。

(すいませんファイル名忘れました)

 Cuda8.0とcuDNN5.1が連携して、TX1最強のGPU環境が構築されます。home にjetson_clocks.shがインストールされてるんで sudo ./jetson_clocks.sh を実行すると最速GPUクロックに変更されてFanが回り出します。卓上でTX1を使うには、これを実行するのが良いと思います。

 ここまで来ると、なぜかapt-getで自由にパッケージがインストールできる様になります。ここで、nanoやmidoriブラウザをインストールして、システムを最新にします

sudo apt update

sudo apt upgrade

かなり時間がかかりますが終了したらreboot。

ここからOpenCVとCaffeインストール

例によって依存アプリをいっぱいインストール

sudo add-apt-repository universe
sudo apt-get update

sudo apt-get -y install build-essential make cmake cmake-curses-gui g++
sudo apt-get -y install libavformat-dev libavutil-dev libswscale-dev
sudo apt-get -y install libv4l-dev
sudo apt-get -y install libeigen3-dev
sudo apt-get -y install libglew1.6-dev
sudo apt-get -y install libgtk2.0-dev
sudo apt-get install cmake git aptitude screen libboost-all-dev \
libgflags-dev libgoogle-glog-dev protobuf-compiler libprotobuf-dev \
bc libblas-dev libatlas-dev libhdf5-dev libleveldb-dev liblmdb-dev \
libsnappy-dev libatlas-base-dev python-numpy libgflags-dev \
libgoogle-glog-dev python-skimage python-protobuf python-pandas

sudo apt-get -y -qq install libgtk2.0-dev ocl-icd-opencl-dev qt5-default

 次にOpenCV2.4.13をインストール。(最初は何かと便利な2.4で状況を確認してから、必要に応じて3.0を再インストールすれば良い)

本家からOpenCV2.4.13をダウンロード。解凍したopencvディレクトリに入って

mkdir buikd 

cd build

今回はOpenGLソースもコンパイルできる環境を作りたかったのですが、OpenCVのmake中、どうしてもGL部分で引っかかるので、これを参考

Jetson TK1 compile from source fails with cuda and opengl interop · Issue #5205 · opencv/opencv · GitHub

にcudaヘッダーファイルを変更。

sudo nano /usr/local/cuda/include/cuda_gl_interop.h

開いたら、前の方に書いてある

#ifndef GL_VERSION

#error Please include the appropriate gl headers before including cuda_gl_interop.h

#endif

#else

を削除。それからいつものようにcmakeしてmake。(11/8 赤部分の数値が文字化けしてました)

cmake .. \

-DWITH_OPENGL:BOOL=ON \

-DWITH_QT:BOOL=ON \

-DWITH_CUDA:BOOL=ON \

-DCUDA_ARCH_BIN=5.3 \

-DCUDA_ARCH_PTX=5.3 \

-DENABLE_FAST_MATH=1 -DCUDA_FAST_MATH=1 -DWITH_CUBLAS=1 -D CUDA_USE_STATIC_CUDA_RUNTIME=OFF\

-DCMAKE_INSTALL_PREFIX=/usr/local \

-DBUILD_TESTS:BOOL=OFF \

-DBUILD_PERF_TESTS:BOOL=OFF \

-DWITH_FFMPEG:BOOL=OFF \

-DENABLE_NEON:BOOL=ON \

-DBUILD_EXAMPLES:BOOL=ON \

-DINSTALL_C_EXAMPLES:BOOL=OFF \

-DINSTALL_PYTHON_EXAMPLES:BOOL=ON \ ..

make -j4

驚くほどワーニングが出ますが、一応OKみたいです。

 すでにpython cv2ライブラリがインストールできています。cuda8.0になってNVCCコンパイル時間が早くなってることが確認できました。

次にcaffe

 Opecvがインストールできたら、Caffeは簡単。問題が多かったのですが、最終的に前の記事通りでOK。Pycaffeはインストール中エラーが出ますが、そのままコンパイルできるので一応対策は考えないことにしました。

Makefile.configの書き換えが必要。次の通り

## Refer to http://caffe.berkeleyvision.org/installation.html

# Contributions simplifying and improving our build system are welcome!

# cuDNN acceleration switch (uncomment to build with cuDNN).

 USE_CUDNN := 1

# CPU-only switch (uncomment to build without GPU support).

# CPU_ONLY := 1

# uncomment to disable IO dependencies and corresponding data layers

# USE_OPENCV := 0

# USE_LEVELDB := 0

# USE_LMDB := 0

# uncomment to allow MDB_NOLOCK when reading LMDB files (only if necessary)

# You should not set this flag if you will be reading LMDBs with any

# possibility of simultaneous read and write

# ALLOW_LMDB_NOLOCK := 1

# Uncomment if you're using OpenCV 3

# OPENCV_VERSION := 3

# To customize your choice of compiler, uncomment and set the following.

# N.B. the default for Linux is g++ and the default for OSX is clang++

# CUSTOM_CXX := g++

# CUDA directory contains bin/ and lib/ directories that we need.

CUDA_DIR := /usr/local/cuda

# On Ubuntu 14.04, if cuda tools are installed via

# "sudo apt-get install nvidia-cuda-toolkit" then use this instead:

# CUDA_DIR := /usr

# CUDA architecture setting: going with all of them.

# For CUDA < 6.0, comment the *_50 lines for compatibility.

CUDA_ARCH := -gencode arch=compute_30,code=sm_30 \

              -gencode arch=compute_35,code=sm_35 \

              -gencode arch=compute_50,code=sm_50 \

               -gencode arch=compute_53,code=sm_53 \

               -gencode arch=compute_53,code=compute_53

 

# BLAS choice:

# atlas for ATLAS (default)

# mkl for MKL

# open for OpenBlas

BLAS := atlas

# Custom (MKL/ATLAS/OpenBLAS) include and lib directories.

# Leave commented to accept the defaults for your choice of BLAS

# (which should work)!

# BLAS_INCLUDE := /path/to/your/blas

# BLAS_LIB := /path/to/your/blas

# Homebrew puts openblas in a directory that is not on the standard search path

# BLAS_INCLUDE := $(shell brew --prefix openblas)/include

# BLAS_LIB := $(shell brew --prefix openblas)/lib

# This is required only if you will compile the matlab interface.

# MATLAB directory should contain the mex binary in /bin.

# MATLAB_DIR := /usr/local

# MATLAB_DIR := /Applications/MATLAB_R2012b.app

# NOTE: this is required only if you will compile the python interface.

# We need to be able to find Python.h and numpy/arrayobject.h.

PYTHON_INCLUDE := /usr/include/python2.7 \

/usr/lib/python2.7/dist-packages/numpy/core/include

# Anaconda Python distribution is quite popular. Include path:

# Verify anaconda location, sometimes it's in root.

# ANACONDA_HOME := $(HOME)/anaconda

# PYTHON_INCLUDE := $(ANACONDA_HOME)/include \

# $(ANACONDA_HOME)/include/python2.7 \

# $(ANACONDA_HOME)/lib/python2.7/site-packages/numpy/core/include \

# Uncomment to use Python 3 (default is Python 2)

# PYTHON_LIBRARIES := boost_python3 python3.5m

# PYTHON_INCLUDE := /usr/include/python3.5m \

#                 /usr/lib/python3.5/dist-packages/numpy/core/include

# We need to be able to find libpythonX.X.so or .dylib.

PYTHON_LIB := /usr/lib

# PYTHON_LIB := $(ANACONDA_HOME)/lib

# Homebrew installs numpy in a non standard path (keg only)

# PYTHON_INCLUDE += $(dir $(shell python -c 'import numpy.core; print(numpy.core.__file__)'))/include

# PYTHON_LIB += $(shell brew --prefix numpy)/lib

# Uncomment to support layers written in Python (will link against Python libs)

 WITH_PYTHON_LAYER := 1

# Whatever else you find you need goes here.

INCLUDE_DIRS := $(PYTHON_INCLUDE) /usr/local/include /usr/include/hdf5/serial 

LIBRARY_DIRS := $(PYTHON_LIB) /usr/local/lib /usr/lib /usr/lib/aarch64-linux-gnu/hdf5/serial

# If Homebrew is installed at a non standard location (for example your home directory) and you use it for general dependencies

# INCLUDE_DIRS += $(shell brew --prefix)/include

# LIBRARY_DIRS += $(shell brew --prefix)/lib

# Uncomment to use `pkg-config` to specify OpenCV library paths.

# (Usually not necessary -- OpenCV libraries are normally installed in one of the above $LIBRARY_DIRS.)

# USE_PKG_CONFIG := 1

# N.B. both build and distribute dirs are cleared on `make clean`

BUILD_DIR := build

DISTRIBUTE_DIR := distribute

# Uncomment for debugging. Does not work on OSX due to https://github.com/BVLC/caffe/issues/171

# DEBUG := 1

# The ID of the GPU that 'make runtest' will use to run unit tests.

TEST_GPUID := 0

# enable pretty build (comment to see full commands)

Q ?= @

 朱書き部が修正したところです。ここまで来るには、cuDNNのインストールやMakefile.configの修正に手間取って無駄な時間を過ごしてしまいました。

今度は、ipython notebookが正常に動かない

 CaffeのExampleに入っているnotebookファイルが全く動きません。使ってみると分かるんですが、これ最高のライブラリなんです。原因はソフトが変更されたからみたいです jupyterに!!。本当にもう。

 sudo pip install jupyter でインストールできます。試しにcaffe/examples から jupyter notebook と打ち込むと、midoriからnotebookが立ち上がります。動作を確認するため00-classification.ipybを選択。初めての人は私のように驚いてしまうでしょう。 

f:id:TAKEsan:20161015115743p:plain

macにインストールしたCaffe examples からnotebookを立ち上げた例。Pythonで書かれた例題が画像を確認しながら実行できる。

全部終わったと思ったら

ubuntu software(前のUbuntuソフトセンター) 設定の中の「ソフトウエア&アップデート」と言語サポートが正常に動かない。これは、どっかのターミナルでsudo aptd実行したままにすれば。とりあえず動作。まーapt-get またはaptでパッケージが普通にインストールできるので良しとしました。

最後に

 caffeのexampleは全て完璧に動きます。しかも確実に前より早く。Mnistのスクリプトを実行してみると、

./data/mnist/get_mnist.sh

./examples/mnist/create_mnist.sh

./examples/mnist/train_lenet.sh

学習スタートから終了まで以前の最速環境で3分21秒に対して、2分36秒で終了。1分近く早くなってました。

 Torchはインストールできませんでした。ここ10日前後でインストールできた方がいるようですが、その通りスクリプトを実行してもビルドが止まってしまいます。解決は時間の問題だと思いますので、もう少し待ったほうが良いようです。

 Nividiaが説明していますが、DIGITSはTX1にインストールできません。TX1が早いと言っても i7 6700クラスでデープラーニングを実行した場合 i7より早いというだけです。(これだけでもすごいことですけど)本格的な学習を簡単に実行できるのがDIGITの売りですから、10倍以上早いGPU環境でないと全く実用的ではありません。最小の大きさで、学習済みデータを最速に実行できるのがTX1の特徴です。しかもGPIO制御もできる。もー夢がいっぱい広がります。DIGITSに執着しないで他のことを目一杯楽しみましょう。

 ZEDも試してみましたが、これもすごかったですよ。先のjetson_clock.shを実行させてからZEDのtoolsを試しに実行させてみるとこんな感じでした。(最近Cuda8.0用にバージョンアップされた)

         

 ステレオカメラで入力したデータを分析して、右側で取り込んだ画像の深度=距離を確認できます。画像の鮮度やスピードに関しては言うことありません。(TX1では1080X720 30fpsが限度みたいです)現状TX1では、OpenCV側のバグでZED SDKがコンパイルできません。これも時間の問題。

 母艦1080GPU環境では、1080x720で60fpsがステレオ2画面で実現できます。今までのWebCamera 30fsと比較するとリアルさがぐっと増します。まるで空気まで表現できる様な感じでした。

 WindowsではZED fuというサンプルが実行できます。これって何かというと、ZEDで写した画像をタイムリーに3D画像に変換できて、ZEDを移動させると3Dデータが自動連結されるサンプルなんです。

         

        基本設定画面。ここからカメラを持って周囲のデータをを記録させる

         

       記録されたデータを3Dデータに変換。メッシュで確認もできてしまう!!

 去年あたり長崎大学が、ドローンを使って軍艦島の3Dデータを作っていたことが話題になりましたが、これを手元で実現できることになります。衝撃以外の表現が見つかりません。

 ちょっと金銭的に無理をすれば、最小の大きさで、画像深度も、ディープラーニングも、それに関連付けた外部センサーなんかも実用レベルで、しかも個人レベルで実現できるんです。なんて幸せな時代なんでしょうか。

f:id:TAKEsan:20161017200729j:plain

 

                                   では、また。

Intel Joule でビックリしたこと。

ビックリしたこと1

金額がEdisonの4倍超になった!! 高〜〜〜〜〜い。

f:id:TAKEsan:20160929203704p:plain

              Mouser 価格!!

ビックリしたこと2

見た目が重厚で所有満足度大。

f:id:TAKEsan:20160929203540j:plain

f:id:TAKEsan:20160929203433j:plain

 Joule本体は安っぽさが微塵もありません。Edisonは本体がアルミ箔で覆われているような感じだったので、価格差分高級感が増しました。おまけにアルミ製の放熱板までついてます。

f:id:TAKEsan:20160929203500j:plain

    ボード全体が何故か重い。価格が高そうな感じ。小さなLEDが多くて楽しそう。

 Kitのボードは、他のインテル製品と同様相変わらず大変クォリティがよろしい。Arduinoや馬鹿高いTX1用のサードパーティボードとは異次元。

ビックリしたこと3

スピードが速かった。

 pythonが標準で付いているので。前々回使ったPython用のテストを実行してみたら12秒でした。これはPi3やTX1(その後おかしいと思ってTX1のOSをバージョンアップしてから再計測したら11.5秒前後でした。つまりJoulと同等)の3倍以上になります。でも、蛇足ですがIntel i5やi7の方がJouleの2〜4倍以上早いのも確か。消費電力の差を考えたら、こんなもんでしょ。iPhone7が発売になりましたが、向こうはARMの発展版なので、早くなったとしてもCPU性能はこちらの方が多分上です。

 消費電力は確認してませんが、Iot制御を主目的にしてるなら既存のボードの中で、CPUスピードでは最速の部類じゃないでしょうか。(TX1はGPUという名のバズーカを抱えているので比べ様がないけど、ものによってはダントツに早い)Pi3が来年あたりバージョンアップしてもこの開きは埋まらないことでしょう。

ビックりしたこと4

OSがイマイチでビックリした。

 やはりハードメーカーってことでもないんでしょうが、ソフトが全然追いついていません。8月のバージョンはバグがいっぱい。なんでこんなわけのわからないOSをつけたんでしょうか?。Yoctoの進化系ということで、Edisonと同じ使い勝手を想像してたのが、そこにも到達していないような、全く期待を裏切られました。今の所Ubuntuで言う所のapt-get すなわちopkgも全く使えません。なので汎用パッケージのインストールは今の所ソースをダウンロードしてコンパイルするしかありません(PIPはソースからインストールすれば大丈夫)。スピードがEdisonやPi3と違うのでコンパイル時間もあまり気になりませんがっ。このあたりが面白いっちゃー面白いんですが。

 そこでopkgのソースをダウロードしてコンパイルしてみましたが、ライブラリのバージョンが違う(GPMG1.0.0以上にしろとか)と怒られました。一筋縄ではいかないようなので、時期バージョンアップ待ち。今回のOSバージョンは、opkg関連の他のコマンド(opkg.pyとか)が使えるのでメーカー側が入れ忘れたか何らかの理由で諦めたかでしょうけど(私の知識不足だったらごめんなさい)。

 Joule発表時に取り上げてたUbuntuもWindows10もまだ公式に対応していません。(成功している人がいるようですがGPIOが使えないようです。今トライ中ですがうまくいきません)メーカーのコミュニケーション情報を見ると今年中とか。ハード発売をなんでこんなに急いだのでしょうかネ?

すごくビックりしたこと5

 詳細なインストール手順IoT - First-time setup | Intel® Softwareが作ってあるのですが、私が期待していた画像に関する詳細説明が全く無し。ディレクトリ内部を見てみると /usr/share にX11OpenCV が鎮座していて、OpenCVに関してはexampleのコンパイル済みバイナリファイルやPythonのexsampleが存在しています。

 もしやと思い、コネクタを買ってHDMIディスプレイを接続、そしてキーボードをUSB3に直結、再起動すると。

f:id:TAKEsan:20160929203341j:plain

f:id:TAKEsan:20160929203534j:plain

 なんとディスプレイにログが表示されて、キーボード入力可能!!。startx コマンドを試しに実行したら、Xwindow画面が現れるではありませんか!!。Pi3用IGZOでも汎用HDMIディスプレイでも。TX1には無いデイスプレイを選り好みしないすんなり感。

 USBカメラをつないで、このXwindow画面から

       /usr/share/OpenCV/examples/python/

に行ってpython video.py を実行してみたら、

         

 簡単に画像をキャプチャーしてしまいました。しかも表示のスムーズさは前回取り上げたゲーミングパソコン並み。CPU部分がPi3やTX1とは格段に違うんですから当然っちゃー当然ですけどっ。これって感覚的にGPIO付きの、ハダカの、超小型比較的高速パソコンです。

 なので今回最大のビックリ!! -------ちょっとXwindowが不安定のようですが..........。

 PiとかTX1とかなら当たり前の事ですが、Edisonをたくさん触ってた者とすりゃ、そりゃ驚きます。  

ビックリしたところ6

 取説の何気ないところに書いてあるんですが、何せ英文。Bootを説明通りSDカードにインストールしてもBios選択できません!!すなわち取説に書いてある選択の鍵となるF2キーをScreen接続では認識しないんです。いろいろ調べたら、キーボードはUSBコネクタに直付けしたらいいような.........。認識しました。最初からこう書けばいいのに。--->ただしF2キーだけ認識。他の操作はScreen接続した端末から。

 あと、SDカードは16Gしか受付ません。32Gも64Gも全然ダメでした。メーカーがScanDiskの最速SDカードでもですよ。

 本体付属の超遅い16G SDカードは正常にBoot可能(当然内蔵eMMCも)。それ以上のメモリが必要な場合は、USBしかダメっす。USBメモリにインストールした各種OSを使い分けるには超便利。でも今の所サポートOSは1種類のみ。

 OSをインストールしたUSBメモリは、Edisonの初期の頃のように作業領域が小さく固定されている(全体で4G以下)ので、容量の大きなUSBメモリを使うには、要拡張。他のUbuntuパソコンのGパーテッドで簡単に拡張できました。

 その他

 非常にわかりにくかったのですが、WifiSSH設定は簡単につながりました。 SSH接続状態は反応が鈍くならないので、Pi3やTX1よりWiFiチップの性能がいいような。

 いろいろ変なことを書きましたが、感覚的に基本性能はさすがです。この機器の本領を発揮するのは、時期OSのバージョンアップと、Ubuntuがリリースされた時の様です。とってもすごくなりそうな予感❤️ ってことで 今日もおしまい。 

その後さらにビックリしてしまうこと。

 この記事を書いた当時は、開発環境に落胆して、Intelに今後を託した感じになりました。海外のWebページを読み漁りながら、ほぼ自力で2ヶ月後には、こうなることになります。 

takesan.hatenablog.com

 基本性能の良さが功を奏し、もうiMacUbuntu母艦はいらない感じ!!。と言ったらビックリしていただけマスでしょうか。

 

 

ROBOX のDual Material Head キットがやっと来た。

思い起こすこと今年の1月半ば。

ROBOXの2色ヘッドをイギリスに注文したのは。それがやっと9月22日に到着しました。あー長かった ちょうど8ヶ月かかりました。

f:id:TAKEsan:20160923215029j:plain

                一見交換が簡単そうだが実は.....。

f:id:TAKEsan:20160923215136j:plain

       ちょっとノズルが汚れているノーマルヘッドとピカピカのDual Material ヘッド

 日本では先月あたりからCGコミュニケーションズさんが取り扱い始めたようです。

 3回ほど催促メールを出したのですが、自分たちもブログで書いているように、小さな会社なのでしょうがないですね。でも結構良心的な返信メールでした。

 Robox本体は、あまりにも売れすぎて(歯科大学が大量に買い占めたとか)イギリス国内では、本体もここ1ヶ月くらいBack Oder状態の様です。 

 届いたものは、ヘッド交換だけかと思いきや、完全なキットで、本体はおろかヘッドのベースまで分解して交換。部品内容を見て恐れおののいてしまいました。(上記写真右側の小袋と、中央のフレキシブルケーブルががクセモノ)

交換方法は動画を見ながらです。

   www.youtube.com

ケースのばらし方がわからなかったのですが、比較的簡単にバラバラになることがわかりました。ただし両側面に関しては力技が必要です。くれぐれもカバーを壊さないように

 バラして組み上げるのに、3時間くらいかかりました。結構重い本体を逆さにしたり、横に倒したりしながら分解していかなければダメなので、腰が....。中身を開けて気付きますが、まー良くできてます。大昔Civicのエンジンルームを改造しているような感覚。

 ROBOXはそもそもセンサーや、ステッピングモーターがてんこ盛り。Dual Material Head キットの組み込みは、規模の大きなロボットを作っているような感覚なので、私の工作欲求が解消されてしまいます。

 一番分かりにくかったのはヘッドのベースで、下の写真のフィラメントを通す2個の金属部品。これは2mmの六角ドライバを差し込んで、ネジ切りしていないヘッドベース部品の穴にかなり力を入れて固定します。見た目が円形なのに奥の方が6角形になってました。(ビデオを見ても何を使ってるのかわかんない)

f:id:TAKEsan:20160923214926j:plain

結局使った工具は

f:id:TAKEsan:20160923221731j:plain

 このほかにラジオペンチとROBOX付属のピンセット。右のドライバセットは上の金属部品を取り付けるためだけに購入(首が細く長くないとダメ)。

とりあえず完成したものの........

 電源を入れても内部照明すら点灯しません。本体の価格を考えると、サーッと血の気が引いていきました。こんな時は即電源OFF。焦げた匂いがしないのでとりあえずは大丈夫そう。

 しょうがないので、フィラメントローダー2個、ヘッドへ供給している信号線と電源を切り離し再度電源、すると 照明が点灯。

f:id:TAKEsan:20160923215427j:plain

         このLED照明が点灯したらひとまずすべての配線がうまくいっている合図

次に、フィラメントローダー再接続-->照明が点灯!!。

ヘッドコネクタ接続-->照明つかない。(ヘッドへの電源は不安なので点検が済むまで接続しない)

ってことでヘッドからみの問題なのが発覚しました。

 ため息をつきながら一番大変なヘッド部品のバラし。また本体の大部分をバラバラにしなければなりません。ヘッドベース(上の写真中ドライバ群の上の黒いプラスチック部品)の中身を付属のアルコールクロスで丹念に清掃。コネクタ類を再点検。特にヘッドに供給している電源は逆だとオシャカになるので再々点検。危なそうなヘッドとベースの接触部分も丹念に清掃。ドライバで少しゴシゴシ。一応全部組み立てないで、コネクタ接続。照明が...............ついた。

 動くこと間違いなし!! と自分に言い聞かせることに。やっぱどっかのコネクタがの接触がうまくいってなかったことになります。ですからこれからの方はこの辺りにご注意を。

 メーカーからの説明がありませんが、今回の経験上、どうやら電源スイッチを入れて本体内部のLEDが点灯するかどうかが成功の鍵のようです。

f:id:TAKEsan:20160923215247j:plain

2個目のフィラメントはもともと本体についているフィラメントホルダを延長しておんぶしている感じ。大概のサードパーティー製フィラメントが取り付けられそう。外部に別ホルダを置くと印刷中の管理(からまってしまわないように)やスペース確保が大変なんですが、これなら納得。

というわけで、この点検作業が+2時間。

  本体がかなり小さい上に、可動部が集中しているので、年寄りには一苦労。結構おもしろーござんした。

f:id:TAKEsan:20160923214851j:plain

       小さな空間にステッピングモーター5個。モーターの下にはCPU基盤

 おかげさまで、以前のヘッド修理と、今回の大改造で、次にトラブっても直せる自信がつきました。

 組み立て中は、けっこうせっかちな性格なので、かなりラフに扱っていましたが、ほとんど印刷物に影響がありませんでした。組み立て精度の正確さが要求される3Dプリンタですので、ここまで内部に変更を加える必要のあるキットをすべてのユーザー対象に販売していることを考えると、各部の自動調整機能にかなり自信を持ってるんでしょうね。

 取り付けたDual Materialヘッドは、ノーマルヘッドよりシビアな調整が必要なようです。特にキャリブレーションは何度も実行して、最良にするのがベターです。

 で、やっとなんとかなったパージマテリアルです。ヘッドに溜まった古いフィラメントを新しいものに変える自動機能ですが、ちゃんと交互に吐き出しています。

f:id:TAKEsan:20160923214816j:plain

ノズルアライメント(ヘッドのXY方向調整)試験も2色出力してました。

f:id:TAKEsan:20160923215353j:plain

 2色分けしたモデルを作るのがめんどくさいので、本体とサポートで、色分けしてみました。

f:id:TAKEsan:20160923215210j:plain

3Dプリンタでよく使われるこのモデルは、かなり意地悪に作られています。出力モードは、NOMAL。もう少し調整が必要。黒いところはサポートです。本来は水に溶けやすいサポート用フィラメントを使えば、普通の3Dプリンタでは不可能な造形もプリント可能となるはず。

 前にTグレースフィラメントを使った時、段差が極端でも美しいと感じるものができる経験をして以来、3Dプリンタに関しては詳細な再現性にあまり意味を感じなくなりました。

 プリンタの基本性能さえよければ、フィラメントを使い分けることと、モデルの作り方でいかようにもなるんですからねー。

 そういった点では、2種類のフィラメントを簡単に使い分けられるので、すごく楽になりました。

f:id:TAKEsan:20160923215102j:plain

一応前に使ったテストモデルをノーマル(右)とファイン(左)で出力。0.4mmヘッドになったので少し雑になるかとは思っていたが、感覚的には0.3mmヘッド比較してと大きな変化はなし。印刷スピードはノーマルヘッドと同じようでした。

前のヘッド簡単に使えるんでしょうか?。

 ヘッドの構造やフィラメントの送り出し方法が全く違うので疑問だったのですが、見事にパス。ヘッドを自動判別して、すぐにプリントを開始しました。ただしキャリブレーションは必要です。そうそう。ノーマルヘッドでは、使えるフィラメントは1種類だけです。でもこれで、当初の狙い通り3種類の太さが違うノズルを簡単に使い分けできることになりました。

f:id:TAKEsan:20160923215350p:plain f:id:TAKEsan:20160923215347p:plain

         左がDual Materialヘッドで右がノーマルヘッドを交換した時

 ROBOXを手に入れてから、他の機種の取り扱い説明などを冷静に眺めていますが、プリント開始方法、フィラメント挿入方法や調整も、改めてすごく簡単であることを感じています。

 唯一不便なのは、安全のためベッドが冷えないと蓋が開かないこと。また分解して鍵を取っちゃえばいいことなんですけど。急いでいるとちょっとムカついてきますが、今回はあーよかったということでおしまい。

 

                               では また。