更新情報
- 2016.11.23 Ubuntu 16.04.1のインストール法、Slicer4の動作検証、Win10 IoT Coreのインスコ印象などを追記。Joule Ostro XTにmraaをインスコする際、mraaのバージョン確認を。Intelのgithubに問題あり。RealSense camera SR300がJouleでは使えないという情報がある。
- 2016.11.26 XDKからUbuntu Jouleに接続出来ない件について、Ubuntu用のxdk-daemonがまだ開発途中（11月時点）であることが発覚。E1.6に追記。
- 2016.12.7 Ubuntu 16.04.1 LTSでPython+MRAA+UPMの開発環境構築に成功。いばらの道E1.7に追記。加速度センサのデータをIBM Bluemix Quickstartでグラフ表示。
- 2016.12.11 Ubuntu 16.04.1にRealSenseカメラのドライバlibrealsenseをインスコ、テストプログラムの動作を確認した。CPU稼働率も特に問題なく動いていることをセクションD4に追記。UART接続のCO2センサを初期化出来ない件について、JouleではそもそもUARTがそのままでは使えないことが発覚したことをセクションE1.7.3に追記。
- 2016.12.17 gpio export permission errorについて、回避策のまとめをセクションE1.7.1の最後に追加。
- 2016.12.18 OpenCV 3.1のインスコ、顔認識Pythonコード実施例をセクションD4に追記。
- 2016.12.19 【重要】IntelからXDK Update for December 2016がリリースされた。Joule−Ubuntuでxdk-daemonが新たにサポートされ、Joule単体でNode.jsが走る。Ubuntu設定に関するセクションE1.6と、F5にリリースノートの和訳を追記。
- 2016.12.23 XDKのプロジェクトアップロードに関するrootアクセス制限の回避策とxdk-daemon設定スクリプトの間違いについてセクションE1.6.3に追記。
- 2016.12.25 ワイヤレスディスプレイの調査状況についてセクションE2に追記（途中）。また、Ostro OSへの回帰についてセクションF6に追記。
- 2017.1.9 ワイヤレスディスプレイに必要なツールのインスコがほぼ完了した件についてセクションE2に追記。
- 2017.1.14 ワイヤレスディスプレイの実証結果（任務完遂）をセクションE2に追記。
目次
プロローグ
A.準備
A1.必要機材と起動
A2.ネットワークの設定
A3.Bluetoothデバイスの接続
A4.ベンチマーク
B.Jouleの設定
B1.BIOSフラッシュ
B2.ローレベルライブラリの導入
B3.Windows 10 IoT Coreの導入
B4.Ubuntu Coreの導入
B5.リファレンスOstro linuxの再導入
C.ホストPCの環境設定
C1.System Studio IoT Editionのインストール
C2.XDK IoT Editionのインストール
D.実施例
D1.Lチカ
D2.三軸加速度センサ：地震計
D3.センサタグTI CC3200：環境モニタ >>> IBM Bluemix IoT Cloudへの接続
D4.RealSense Developer Kit SR300：物体認識
E. Ubuntu 16.04.1開発環境
E1.Ubuntu 16.04.1LTS (Classic)をインスコ
E2.Miracastドライバをインスコ (under testing)
F.資料
F1.スペックまとめ
F2.Tuchuckピンアウト
F3.UPMレポジトリ
F4.Jouleに於けるRealSenseテクノロジの互換性
F5.Intel XDK Update for December 2016（12月13日）
F6.Ostro OSへの回帰
プロローグ すさまじい基本性能
Jouleが何者であるかを語るには、まずここから始めたい。
何と、sysbench 0.5ベンチマークで、JouleがXeonを超えている。
Joule Ostro XTのXFCEデスクトップでsysbench 0.5を走らせたところ、4スレッドで驚きの2.23秒、シングルスレッドでは8.14秒で駆け抜ける。MacBook AirのSandy Bridge Core i7 1.8 GHzで12.76秒、わずか数年前にワークステーション用Xeonの頂点に立ったやはりSandy Bridge世代のE5-2687W 3.1 GHzですらシングルコアでは9.27秒だった(Edisonベンチ)。Intelの中の人にも再現してもらったから、確か。sysbenchはデフォルトで10000以下の素数を数えるベンチで、Jouleに搭載されたAtom T5700 1.7-2.4 GHzにどんな秘密があるのか分からないが、CPUだけではなくメモリ周りも寄与しているのだろうか。
因みに、Edisonは225.71秒。単純にJouleはEdisonの27.7倍高速ということになる。他のレビューでも6〜10倍高速と言われていたが、実測はそれ以上だ。プラス、多彩な画像処理エンジンを謳うグラフィックコアもある。こいつはほんとにAtomなのか？これはもうEdisonの進化版というレベルじゃなくて、ターゲットが、目指してる所が、全然違う。
これだけの性能があれば軽くノートPCになる。ところが、だ。実際はJouleのリファレンスOSのOstro XTから、なんとパッケージマネージャが意図的に省かれている。apt-getもyumもない。新規ソフトをインスコするにはローカルにビルドするしかないという。そんな、dependency hell（依存性地獄）を乗り越えてJouleに開発環境やブラウザをインスコしてしまう強者にしかJouleの本当の姿を見せないという。これが何を意味するかと言うと、IntelとしてはJouleをデスクトップマシンとして使うなということだ。何だろう、単なるマーケティングだろうか？
※後日談 Ostro XTからパッケージマネージャが省かれている理由は、Ostro OSの設計思想そのもににあった。Ostro OSの特徴として、１）Yocto Projectに由来するOSイメージのビルドを簡略化するシステム、２）Clear Linux Projectに由来するソフトウェア・アップデート・メカニズム、という2つの方法でOSを管理していることが挙げられる。IoT製品に必要でかつ最小限のリソースを含む単一イメージを作り、多くのデバイスに配布（deploy）するという、Jouleが個人ではなく産業界を主な標的としていることを反映する背景があった（セクションF6参照）。
Joule T570XをAtomの系譜から眺めてみると、スマホやタブレット向けに省電力を至上命題として開発されて来たこれまでのAtomの延長線上に、T570Xは確かに位置する。
約3〜5万円台の安価なタブレットやノートPCに搭載されるAtomシリーズ。その中でもT570Xの兄弟に相当するApollo Lakeを搭載するecs LIVA Z（来年1月発売）に近い、或いはそれ以上の性能をT570Xは有していると思われる。特にメモリ周りの強化が、画像データのプロセシングのような大きな負荷に対して効果があるのではないだろうか。価格的には、OS込みのLIVA Zの32,800円に対し、Joule開発ボードは約5万円で売られている。
T570XのコードネームBroxtonは今年の4月にIntelから開発中止がアナウンスされている。Jouleの後継機種は次世代Atomになるのか、それともモバイル向けのCore m3などに集約されて行くのか・・・
※Intelの従業員っていう人が身分を明かしてJouleにUbuntu (Ubuntu Coreではない）をインスコする方法を公開している。Joule-break？ ▶セクションE1参照
Jouleの標的とは
Developer ZoneのJouleトップページ
※https://software.intel.com/en-us/iot/hardware/joule
This powerful system on module (SoM) was designed to help inventors and IoT developers contribute to a new generation of robots, drones, and IoT devices that are equipped with Intel® HD Graphics, 3D modeling, object recognition, and interactive capabilities.
（sorrow訳）この高性能なSoM（システムオンモジュール）は、発明家やIoT開発者が新世代のロボット、ドローン、IoTデバイスにIntel HDグラフィックス、3Dモデリング、物体認識、インタラクティブ機能を装備するための一助となるよう設計されている。
Intel HDグラフィックスはH.264/H.265のハードウェアエンコードによる４K再生支援、3Dモデリングは3Dスキャン・3Dプリント、物体認識は仮想現実や顔認識、インタラクティブ機能はジェスチャー制御。まだArduinoレガシーが～と言っていたEdisonとは明らかに一線を画す。ほとんどRealSenseデバイス開発のための専用プラットフォームと言っていいかもしれない。
IoTプラットフォーム：左からIntel Edison (Atom Z34XX modified), Intel Joule (Atom T5700), TI CC3200 (ARM Cortex M4)。Intelはモバイル向けにAtomを売ることを諦め、奇しくも、縮小するPC市場のため稼働率が落ちた工場をARMのファウンダリとして提供するという、なんか4年くらい前からあったらしい話が現実に。（シビアな世界だなあ。）モバイル、省エネ性能へのこだわりがなくなり、Jouleにありったけの性能を突っ込んだのか、単にEdisonでAtomに掛けていたリミッタを外しただけなのか、いずれにしても180度ターンのような気がする。
目的外使用、と言われそうだが、ベンチマークだけではなくて計算負荷の厳しいアプリではどうか、Ubuntu 16.04.1（後述セクションE1.5）にインスコしたSlicer4という3D画像レンダリングソフトで試してみた。
CT画像の骨軟部組織のコントラストの差から色々な解剖学的構造を再構成してくれる、かなり負荷の高いソフトだ。CPUでレンダリングした時のCPU稼働率が下の図。4コアとも一時的に100%近くまで張り付くが、5秒くらいでレンダリングしてくれる。4GBのメモリがきわどい。
今度はGPUでレンダリングした時のCPUの稼働率。CPUよりやや演算に時間が掛かっているが、その間CPUの負荷は見事に軽減されている。
以前、PalitのGTX960の水冷レビューでSlicer4を動かした時と比べると、GTX960はリアルタイムで描出してくれるのに、Jouleだと流石にリアルタイムでは計算できないという大きな違いはあるが、そもそも5秒くらいの時間でレンダリングしてしまうということ自体すごい。業務用だとQuadroを積んだワークステーションでやるような作業だから、こんなちっちゃな筐体で驚くべき性能だ。
さて、今回のレビューもいばらの道だった。Developer Zoneに出してあるサンプルコードがそのままでは動かない。大体、JouleとRealSenseカメラを使った物体認識に挑戦するというのも、素人にはハードルが高い。だって、JouleにおけるRealSenseはまだ実験段階にすぎず、Intelの正式なサポートはない状況だから。ま、目標に到達するために必要な準備をひとつひとつクリアーし、ほとんど英語しかない情報を探すという作業そのものが少しでも他の人たちの参考になってくれたらうれしい。
A.準備
A1.必要機材と起動
- DC12V 3A電源（5.5 mm/2.1 mmジャック）またはtype C USB端子から5V電源
- 通常のmicro USBケーブル（断面が台形のtype B）シリアルコンソールに使う
- mini HDMI-HDMIケーブル（モニタ接続）
- USBまたはBTのキーボード&マウス
- 16GB USBフラッシュメモリ（OSのインストールに必要）
- Windows 10ホストPC（Win10 IoT Coreのインストールに必要）
- type C micro USBケーブル（断面が上下対称なやつ）はJouleキットに附属
まず、DC12V 3Aという数字。つまり36W。いつも使ってるMacBook Air 11"ですら（LCDディスプレイ含めて）45Wだ。そりゃ放熱板とかファンとか必要になるよね。Jouleの公式サイトでは全く触れられていないが、データシートのページ12には、+VDC_INまたはUSB VBUS（type Cソケット）のどちらか電圧供給されればブートする（両方の場合+VDC_IN優先）とあり、実際どちらでも動く。
ACアダプタは一般的には19Vが多くて、12Vはなかなか見つからない。今回はガラクタ箱の底から昔のIBMノートのが出てきたので、ACアダプタの（オス）ジャックからJouleのオス端子につなげる変換ケーブルを自作して準備完了（i.e.売ってなかったので）。当然のようにACアダプタの方がでかい。
最初のミニマム構成はJoule、電源、USBキーボード、HDMIモニタの４つ。これでJouleのOstro XT (Ostro OS extended)が起動する。このままテキストコンソールでもいいけど、後述A3でBTマウスをつなげたら
# startx
または
# startxfce4
でターミナルまたはデスクトップを立ち上げてもよい。XFCE（xfce.org）は超軽量デスクトップで、グラフィカルにファイルシステムやターミナルウィンドウを操作できるが、Ostro自体がまだapt-getやyumをサポートしてないため、XFCEのアプリケーションプラグインをインスコするのもままならない。セクションBで述べるように、Ubuntu CoreまたはWin10 IoT Coreに乗り換えれば、わざわざホストPC上に開発環境を構築してシリアル転送でやりとりしなくても、Joule上で開発環境が完結し（少なくとも素人には）効率的。
A2.ネットワークの設定
A2.1 WiFi接続
まずP2P, WiFi, Bluetoothの動作確認から。
# connmanctl technologies
WiFiの設定は、scan wifiでルータのMACアドレスを確認。ブロードキャストしてないルータはhidden managedと表示され、接続を試みるとSSIDを聞かれる。
# connmanctl
connmanctl> enable wifi
connmanctrl> scan wifi
connmanctrl> services
connmanctl> agent on
connmanctl> connect *****_hidden_managed_***
Hidden SSID name?
Passphrase?
Connected wifi_****_hidden_managed_***
connmanctl> quit
A2.2 SSH接続
# echo ‘PermitRootLogin yes’ >> /etc/ssh/sshd_config
# passwd
ポート開放。
# iptables -F
# iptables -P INPUT ACCEPT
# iptables -P FORWARD ACCEPT
# iptables -P OUTPUT ACCEPT
# iptables -S
Joule公式サイトには、shellログイン毎にこれをやれと書いてある。
# iptables -A INPUT -p tcp --dport 2345 -j ACCEPT
※１ rootにパスワードを設定しないとSSH接続しない
※２ Ostro XTではこの設定で通るが、Ubuntu 16.04.1ではConnection refusedになる。現在調査中。
A3.Bluetoothデバイスの接続
Jouleにはtype A USBソケットが1つしかないので、キーボード、マウスはBTが便利。まずBluetoothのスイッチをオン。
# connnmanctl
connmanctl> enable bluetooth
connmanctl> exit
次いでbluetoothctrlで接続設定。
# bluetoothctrl
[bluetooth]# agent KeyboardDisplay
Agent registered
[bluetooth]# default-agent
Default agent request successful
[bluetooth]# scan on
Discovery started
...
[bluetooth]# pair xx:xx:xx:xx:xx:xx （MACアドレス：タブ補完OK）
Attempting to pair with xx:xx:xx:xx:xx:xx
...
Request PIN code
[agent] Enter PIN code: ****
Pairing successful
[bluetooth]# trust xx:xx:xx:xx:xx:xx
[bluetooth]# connect xx:xx:xx:xx:xx:xx
[bluetooth]# discoverable on
[bluetooth]# quit
agent登録はJouleの公式サイトでは何も言及がないけど、シリアルコンソールからペアリング許可の入力に必要。trustしておけば次回から自動的に接続するようになる。またdiscoverable onしておくとBluetooth機器からJouleが見えるようになる。
A4.ベンチマーク
sysbenchはakopytovさんからDL、解凍して
./autogen.sh
./configure
make
でビルドして、sysbenchフォルダから実行。
./sysbench --test=cpu --num-threads=1 run
B.Jouleの設定
B1.BIOSフラッシュ
BIOSに入るにはF2起動。Win10 IoT CoreのインスコにBIOS 131が要求されるため、Intel公式サイトに従ってBIOSフラッシュが推奨される。
B1.1 必要事項
- Windows 8, 8.1, 10ホストPC（32bitまたは64bit）
- type C USBケーブル（Joule附属）
B1.2 既存ドライバの削除
Windowsの「プログラムと機能」に
- Intel Android Device USB driver
- Intel DnX USB Driver version 1.0.0
- Intel(R) Platform Flash Tool version 5.6.1.0
のいずれかがリストされていれば全て削除する。
B1.3 BIOSフラッシュツールのDL
をホストPCにDLし、展開。中のPublicフォルダを開き、Joule_C0-X64-Release-131-Public_DXN.binをDNXフォルダに移動する。ホストPCからJouleを外し、DNXフォルダの奥に隠れている
Joule-Firmware-2016-09-23-131_Public > DNX > DNX-didrcli > installer > FlashUsbDriver-1.0.0.exe
を実行して”Intel Flash USB Driver version 1.0.0”をインスコ。
「プログラムと機能」にFlash USBドライバがインスコされたことを確認。
B1.4 Jouleの接続とBIOSフラッシュ
- Jouleから全てのケーブルを外す
- type C USBケーブルをPC側に接続
- DC12V電源をコンセント側に接続
- JouleのDNXブートボタン（端子類を手前に向けて右上）を押し下げたまま電源ジャックとtype C USBケーブルをJoule側に接続
- DNXブートボタンをリリース
これでJouleが起動し、ホストPCのデバイスマネージャでUniversal Serial Bus devices > Intel DnX Deviceが確認できる。
Windowsのコマンドプロンプトを立ち上げ、ファームウェアのDNXフォルダに移動してFlashバッチコマンドを入力。
Flash.bat Joule_C0-X64-Release-131-Public_DNX.bin
USBケーブルと電源を抜いて終了。プロビジョニングに失敗したと出るが問題ない。
JouleをF2起動して確認。
更新前。
更新後。
さらに、BIOSのBootからOSにWindowsを選べるようになる。
B2.ローレベルライブラリの導入
B2.1 インストールスクリプトを実行。
MRAAと一緒にUPMもインスコされる。
# curl https://raw.githubusercontent.com/intel-iot-devkit/joule-code-samples/master/mraa-install.sh | sh
# mraa-gpio version
※ mraaのバージョンを確認すること。1.5.1でなければならないが、Intelのスクリプトの通りやると0.7.5がインスコされることがあり、node-gypが動作せずビルドが通らない問題を起こす。Ubuntuの場合はapt-get installで行けるが、Ostro XTはそれが出来ないのでIntelのgithub頼り。
B2.2 MRAAはC++ライブラリで、JouleなどのデバイスのI/Oポートのデータ構造とインターフェースAPIを提供する。Pythonやjavascriptからも呼び出せる。github.com/intel-iot-devkit/mraaに各種アプリケーションのサンプルコードがある。
B2.3 UPM (Useful Packages & Modules)レポジトリは、Groveなどの各種センサやアクチュエータを動かすために記述されたライブラリで、ver.1.0ですでに94のデバイスが登録されている。（F3.資料）各言語のサンプルコードは同じくgithub.com/intel-iot-devkit/upmサイトにいろいろ。
B3.Windows 10 IoT Coreの導入
インスコしてみると、期待していたものとの落差があまりにも大きくて唖然とする。デスクトップ環境が用意されていないので、Joule上で開発作業を行うという目的には合わない。ホストがWindows 10の場合、何か都合がいいことがあるのかも知れないが、よく分からない。まだ開発途上なのかな？
B3.1 ファイルのダウンロード
- Windows Assessement and Deployment Kit インストーラ（adk.exe)
- JouleInstaller.zip
- Windows 10 IoT Core Insider image （Windows10_InsiderPreview_IoTCore_IntelJoule_ARM32ARM64_en-us_BUILD.iso）
adk.exeを立ち上げ、
- Deployment Tools
- Windows Preinstallation Environment（WinPEのこと）
の2つにチェックを入れてDL開始。かなり大きいので時間がかかる。
B3.2 起動USBドライブの作成
Windowsの新規インスコプログラムリストから「展開およびイメージングツール環境」を管理者で起動し、コンソールに次のコマンドを入力。
copype amd64 C:\WinPE_amd64
MakeWinPEMedia /UFD C:\WinPE_amd64 X: （XはUSBドライブ名）
次にJouleInstaller.zipを解凍し、中のcmdファイルをさっきの起動USBのルートにコピーする。Windows 10 IoT Core InsiderイメージISOファイルをダブルクリックでマウント。中のWindows_10_IoT_Core_for_Broxton.msiをダブルクリックで実行し、C:ドライブのProgram Files (x86) > Microsoft IoT > FFU > Broxtonフォルダ内にflash.ffuが生成されることを確認する。flash.ffuをさきほど作った起動USBのルートにコピーする。
B3.3 Windows 10 IoT Coreインストール
USBハブにキーボード、マウス、起動USBドライブを接続、HDMIモニタ、DC12VでJouleを起動。F2でBIOSに入り、Device Manager > System Setup > Boot > OS Selection > Windowsを選択しF4で確定。Boot Manager > EFI USB Deviceを選択し、再起動。
Win PEが立ち上がったら、USBドライブに移動する。eMMCがフォーマットされてなければUSBがドライブC:となる。eMMCがフォーマットされているとeMMCがドライブC:となり、USBがドライブD:となる。ルートディレクトリにコピーしておいたJouleInstaller.cmdを起動すれば同じくルートディレクトリに置いたFlash.ffuがeMMCドライブにインスコされる。WinPEプロンプトに戻ったらリブートコマンドを実行。
wpeutil reboot
再起動したらF2でBIOSに入り、Boot orderでeMMCをトップに移動。USBドライブを抜いて再起動するとeMMCからWindows IoT Coreが立ち上がる。えっ？何だろこれ？
画面全体がただのターミナル。何をしろと？
これって、Microsoftの中の人、はっきし言って”手抜き”じゃね？
B4. Ubuntu Coreの導入
Ubuntu 16.04.1がインスコ出来ることが分かったので、Ubuntu Coreインスコを敢えて実行する意味はなくなった（セクションE1）。参考情報のみ。
B4.1 必要事項
- Joule BIOS 131
- UbuntuホストPC 14.04以降
- 2x USBフラッシュドライブ
- USBハブ（4口）
- Ubuntu Core 16 betaイメージファイル (tuchuck.img.xz) 465MB
- Ubuntu Desktop 16.04.1 LST（ubuntu-16.04.1-desktop-amd64.iso）1.4GB
B4.2 Ubuntu 16.04.1起動USBドライブの作成
UbuntuホストPCからUnity Dash > Startup Disk Creatorを入力検索して起動する。ubuntu-16.04.1-desktop-amd64.isoイメージを選択、USBドライブを選択、Make Startup Diskをクリック、これで起動USBドライブが作られる。
B4.3 Ubuntu Coreイメージファイルのコピー
２台目のUSBドライブにtuchuck.img.xzをコピーする。
B4.4 Ubuntu Coreの導入
Ubuntu 16.04.1 ドライブからJouleを起動し、Try Ubuntu withount installingを選択。システム起動後、２台目のUSBドライブを挿入、ターミナルを開きxzcat解凍コマンドを入力
xzcat /media/ubuntu/USB/tuchuck.img.xz | sudo dd of=/dev/mmcblk0 bs=32M status=progress; sync
B4.5 SSHログイン
console-confでSSHキーをDLし、保存する
ssh Ubuntu SSOユーザ名@デバイスIPアドレスでログイン
sudo passwdアカウント名でローカルログインユーザを作成する
B5.リファレンスOstro linuxの再導入
Ostro OS XTは最新バージョンが入っているので、11月現在アップデートの必要はない。Win10やUbuntuをインスコした後にOstroに戻したい場合の方法を示す。
Intel Joule Module Configuration Tool（Intel_Joule_Setup_Win_v2016.3.003.exe）をDLして実行。（OSXバージョンはUSBドライブを認識しなかった。やはりWindowsが無難。）
Ostro XTのイメージはxz圧縮ファイルをDLして7Upとかでostro-xt-image-swupd-intel-corei7-64-2016-08-13_13-03-59-build-170.dskというファイルに解凍しておく。
USBドライブとOSイメージファイルを指定してNextボタンを押すだけ。
無事終了。USBへの書き出しは数分もかからない。
出来上がったUSBインストールドライブをJouleにさして、電源コネクタをつないでF2起動し、BIOSからBoot Optionに入る。
Boot orderでUSBドライブを一番上に。
USBから再起動するとスクリプトが走って、システムをeMMCにインスコするかどうか聞いてくれるのでyと入力。
数分でインスコ完了。
C.ホストPCの環境設定
C1.Intel(R) System Studio IoT Editionのインストール
C++開発環境。一応基本、ということで。ただし、Python開発環境が使えるようになったらそっちに移りたい。C++のコードはほんと見にくいよなぁ。
C1.1 Docker Toolboxのインストール
開発ツールをインスコする前に、下準備が２つ。最初のDocker Toolboxは、Windows 10以外の環境では原因不明の地雷がつきまとうため、Windowsなら10をおすすめ。WindowsネイティブなDocker for Windows.msiというインストーラもあるけど、Windowsのバージョンが最新じゃないと怒られる。
Docker Toolboxのインスコがうまく行くとDocker Quickstart Terminal起動でこんな風に。
ここで一旦再起動が安全。
C1.2 JREのインストール
次いで、Java SE Runtime Environmentを、まだ入れてなければOracleからDLしてインスコ。
※JRE8
C1.3 Intel System Studio IoT Editionのインストール
下準備が出来たらやっとIntel System Studio IoT EditionのインストーラをここからDL。
※w_iss_iot_2016.0.004.exe （10.3MB）
System Studioインストーラを起動すると、最初になぜかYocto環境もデフォルトでDLするようになっている。ご覧の通りGBもあるでかいファイルをDLするので、Ostroだけにしておいた方がいいかも・・・2時間も3時間も待ったあとコケると、かなり痛いッス...orz
無事インスコ終了。System Studioが起動するかどうかチェック。
C2.XDK IoT Editionのインストール
Node.js開発環境。ネットワークに強い言語。コードは読みやすいが、Pythonのように使い慣れないので少しだけハードルが高い。
※xdk_web_win_master_3491.exe (322MB)
XDKは特に問題なくインストール完了。
D.実施例
D1.Lチカ
D1.1 Lチカ
Joule開発ボードにはGP100からGP103まで4個のLEDが並んでいる。
D1.1.1 PythonでLチカ
Ostro XTにはPhyton 2.7とPython 3.5がインスコされている。mraaライブラリをインスコするとupmも一緒にインスコされるので、割と簡単に一般的なセンサ類が使えるようになる。
viエディタでプログラムファイルを作成（blink-led.py）。
import mraa
import time
x = mraa.Gpio(101)
x.dir(mraa.DIR_OUT)
while True:
x.write(1)
time.sleep(1)
x.write(0)
time.sleep(1)
・python blink-led.py
１秒毎にGp101をオン・オフする。
D1.1.2 Node.jsでLチカ
JouleにはNode.jsがデフォルトでインスコされているので、そのままスクリプトが走る。
vi blink-led.js
var m = require('mraa');
var myLed = new m.Gpio(103);
myLed.dir(m.DIR_OUT);
var ledState = true;
function periodicActivity() {
myLed.write(ledState?1:0);
ledState = !ledState;
setTimeout(periodicActivity,100);
}
periodicActivity();
・node blink-led.js
0.1秒毎にGp103をオン・オフする。
PythonもNode.jsもインタープリタモードで動くので楽。PythonとJavascriptの構文はとても似てるので、Pythonに慣れてる人にはNode.jsはわかりやすい。swiftもそうだけど、｛｝ではなくてインデンテーションで構文を作るところが、Pythonの方がきれいで洗練されてるとは思う。Python(Gp101)とNode.js(Gp103)を同時に走らせるとこんな感じ。
D1.1.3 C++でLチカ
System Studio IoT Editionを立ち上げ、Intel IoTメニューからCreate a new Intel project for IoTを選択すると、チュートリアルのサンプルコードからソースファイルを立ち上げることができて、とても便利。初心者はサンプルコードを編集してプログラムを書くべし。
初回はコードをDLするかどうか聞かれる。
JouleとSSH接続の確立。
JouleにSSHを設定した時のログインパスワード。
Lチカサンプルコード。
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include "mraa.hpp"
#define DEFAULT_IOPIN 103
static int iopin = DEFAULT_IOPIN;
int running = 0;
void sig_handler(int signo){
if (signo == SIGINT){
printf("closing IO%d nicely\n", iopin);
running = -1;
}
}
int main(int argc, char** argv){
signal(SIGINT, sig_handler);
mraa::Gpio* gpio = new mraa::Gpio(iopin);
if (gpio == NULL) {
return mraa::ERROR_UNSPECIFIED;
}
mraa::Result response = gpio->dir(mraa::DIR_OUT);
if (response != mraa::SUCCESS) {
mraa::printError(response);
return 1;
}
while (running == 0) {
response = gpio->write(1);
sleep(1);
response = gpio->write(0);
sleep(1);
}
delete gpio;
return response;
}
メニューバーからRunを選択してコンパイル、実行すると、Jouleの/tmpディレクトリに転送されて実行される。
D2.MMA7660三軸加速度センサ：地震計
加速度センサを使って地震検知器を作るというデモンストレーション。
D2.1 Python
まず、Pythonで軽くMMA7660の動作確認。いろいろなセンサのAPIがUPMというパッケージに入っているので、ここからDL。
mma7600.py
from __future__ import print_function
import time, sys, signal, atexit
from upm import pyupm_mma7660 as upmMMA7660
def main():
m = upmMMA7660.MMA7660(upmMMA7660.MMA7660_DEFAULT_I2C_BUS, upmMMA7660.MMA7660_DEFAULT_I2C_ADDR);
def SIGINTHandler(signum, frame):
raise SystemExit
def exitHandler():
print("Exiting")
sys.exit(0)
atexit.register(exitHandler)
signal.signal(signal.SIGINT, SIGINTHandler)
m.setModeStandby()
m.setSampleRate(upmMMA7660.MMA7660_AUTOSLEEP_64)
m.setModeActive()
ax = upmMMA7660.new_floatp()
ay = upmMMA7660.new_floatp()
az = upmMMA7660.new_floatp()
while (1):
m.getAcceleration(ax, ay, az)
outputStr = ("Acceleration: x = {0}"
"g y = {1}"
"g z = {2}g").format(upmMMA7660.floatp_value(ax),
upmMMA7660.floatp_value(ay),
upmMMA7660.floatp_value(az))
print(outputStr)
print()
time.sleep(.5)
if __name__ == '__main__':
main()
D2.2 Node.js
Intel Developer Zoneのサンプルコードから、MMA7660を使った地震検知器を作成した。かなり、ハマった。まだ完全に解決したわけじゃないけど、node-gypがインスコされてないためにXDKがビルドエラーを吐きまくってるみたいで、node-gypをインスコしたら少し動くようになった。Jouleでも動作検証してるって言ってるけど、うそだな。
【重要】npm install -g node-gyp
※Intelの中の人によると、mraaをJouleにインスコした際に何故か古いバージョンが入ったことが原因のようだ。Ostro XTはapt-getが使えないから、簡単にremove/installが出来ないのが歯がゆい。
あちこちのサンプルコードからかき集めて、やっと再構築できた。
"use strict" ;
var mraa = require('mraa');
//GroveベースシールドにI2C接続したMMA7660三軸加速度センサの初期設定
var digitalAccelerometer = require('jsupm_mma7660');
var myDigitalAccelerometer = new digitalAccelerometer.MMA7660(0, 76);
myDigitalAccelerometer.setModeStandby();
myDigitalAccelerometer.setSampleRat(digitalAccelerometer.MMA7660.AUTOSLEEP_64);
myDigitalAccelerometer.setModeActive();
//GroveベースシールドにI2C接続したLCDディスプレイ（JHD1313M1）の初期設定
var lcd = require('jsupm_i2clcd');
var display = new lcd.Jhd1313m1(0, 0x3E, 0x62);
function main() {
//加速度の読み取り
var ax, ay, az;
ax = digitalAccelerometer.new_floatp();
ay = digitalAccelerometer.new_floatp();
az = digitalAccelerometer.new_floatp();
var prev = false;
var outputStr = "";
//加速度をコンソールとLCDに表示する
setInterval(function() {
myDigitalAccelerometer.getAcceleration(ax, ay, az);
outputStr = roundNum(digitalAccelerometer.floatp_value(ax), 2) +
" " + roundNum(digitalAccelerometer.floatp_value(ay), 2) +
" " + roundNum(digitalAccelerometer.floatp_value(az), 2);
console.log("Acceleration:" + outputStr);
display.setCursor(0,0);
display.setColor(0,255,0);
display.write(outputStr);
//X軸の加速度が1より大きい場合のみ、USGSにクエリを送信する
var quake = (digitalAccelerometer.floatp_value(ax) > 1);
if (quake && !prev) {
verify();
}
prev = quake;
}, 500);
}
//X軸の加速度が所定値を超えた時USGSサーバに地震情報を問合わせてLCDの2行目に表示
var request = require("superagent");
var fs = require("fs");
var path = require("path");
//現在地座標
var config = JSON.parse(fs.readFileSync(path.join(__dirname, "config.json")));
function verify() {
function callback(err, res) {
if (err) {
return console.error("err:", err);
}
if (res.body.features.length) {
warn();
} else {
noquake();
}
setTimeout(stop,10000); //10秒後にメッセージ消去
}
var time = new Date();
time.setMinutes(time.getMinutes() - 10);
request
.get("http://earthquake.usgs.gov/fdsnws/event/1/query")
.query({ format: "geojson" })
.query({ starttime: time.toISOString() })
.query({ latitude: config.LATITUDE })
.query({ longitude: config.LONGITUDE })
.query({ maxradiuskm: 500 })
.end(callback);
}
function roundNum(num, decimalPlaces)
{
var extraNum = (1 / (Math.pow(10, decimalPlaces) * 1000));
return (Math.round((num + extraNum)
* (Math.pow(10, decimalPlaces))) / Math.pow(10, decimalPlaces));
}
function warn() {
console.log("Earthquake!");
display.setCursor(1, 0);
display.setColor(255, 0, 0);
display.write("USGS Earthquake!");
}
function noquake() {
console.log("No quake.");
display.setCursor(1, 0);
display.setColor(0, 255, 0);
display.write("USGS No quake");
}
function stop() {
display.setCursor(1, 0);
display.setColor(0, 255, 0);
display.write(" ");
}
process.on('SIGINT', function()
{
clearInterval(myInterval);
digitalAccelerometer.delete_intp(x);
digitalAccelerometer.delete_intp(y);
digitalAccelerometer.delete_intp(z);
digitalAccelerometer.delete_floatp(ax);
digitalAccelerometer.delete_floatp(ay);
digitalAccelerometer.delete_floatp(az);
myDigitalAccelerometer.setModeStandby();
console.log("Exiting...");
process.exit(0);
});
main();
D3.センサタグTI CC3200：環境モニタ >>> IBM Bluemix IoT Cloudへの接続
第2段の企画、WiFiを搭載したTIのセンサタグとJouleをインターネットでつないでIoTもどきを構築予定。
CC3200 Launchpadは安価なWiFi内蔵のARM Cortexコアで、ほんとは簡単にhttpサーバになるはずなんだけど、家のイントラネットに問題があるのか、これまでの所LANに接続することすら出来ていないorz.....
そこで、WiFi接続のデバイスは置いておいて、まずBluemixへのデータ送信から始めることにした。ところが、Ubuntu 16.04.1の上でいろいろ試みた結果、なかなか手強いことが判明。素直にOstro XTでやってれば問題にならないのかも知れないが、Ubuntu 16.04.1の開発環境からセットアップするところから躓いた。
サンプルコードは、IBM Bluemix Quickstartから。
var Client = require("ibmiotf");
var config = {
"org" : "quickstart",
"id" : "sorrow01",
"type" : "iotsensor"
};
var deviceClient = new Client.IotfDevice(config);
deviceClient.connect();
deviceClient.on("connect", function(){
periodicActivity(); //call the periodicActivity function
})
var count = 1;
function periodicActivity()
{
deviceClient.publish("status","json",'{"d" : {"pir" : ' + count +'}}');
setTimeout(periodicActivity,1000);
if(count == 1){
count = 0;
}
else {
count = 1;
}
}
ここまでは簡単にデータが飛ばせた。
この続きはUbuntu環境での検証結果、E1.7.2を参照。
D4.RealSense Developer Kit SR300：物体認識
※JouleではSR300が使えないという情報がある。ZR300（SR200の改訂版）が対応するそうだ。購入を考えてる人は注意。
（12/17追記）Githubのlibrealsense APIでSR300が問題なく動作することを確認した（以下）。Intel公式には全ての機能の動作を保証しないということかも知れないが、少なくともサンプルアプリは全て動く。CPUコアが20-30%の稼働率で動くとかなり熱を出すので空冷必須。またlibrealsense APIはあくまでもカメラ機能だけでIntel RealSense SDKに含まれる物体認識クラスライブラリ等は実装されていない。各自、OpenCV等で対応ということになる。
IntelのコミュニティフォーラムではJouleはAtomだからSR300は使えないと言ってるIntelの中の人がいたけど、どうやらgithubのlibrealsenseドライバで問題なく動くようだ。
因みに、click.intel.comで買ったSR-300（送料込¥18,154）はモデルNo. VF0810となってて、どう見てもCREATIVEのSenz3Dと同じ物体。だいたい箱にCREATIVEって書いてあるし。
これは、もし誰かがSenz3Dのためにドライバやアプリを開発してくれたらそのまま使えるかもしれないってこと。GithubのSDKは、最近はZR300だけに開発されてるみたいなので、Senz3Dコミュで開発が進められればSR300オーナーにも恩恵があるかも知れない。例えばSoftKineticなんかがVF0810のDepthSenseSDK作ってくれないかな、とか。
D4.1 Ubuntu 16.04.1へのlibrealsenseドライバインスコ手順
sudo apt-get update && apt-get upgrade
sudo apt-get install libusb01.0-0-dev pkg-config
sudo apt-get install libglfw3-dev
git clone https://github.com/IntelRealSense/librealsense.git
cd librealsense
mkdir build
cd build
cmake .. -DBUILD_EXAMPLES:BOOL=true
make
sudo make install
cd ..
sudo cp ./config/99-realsense-libusb.rules /etc/udev/rules.d/
sudo udevadm control --reload-rules
sudo udevadm trigger
./scripts/patch-arch.sh
・・・ここで1.17GBのファイルをDLするので、かなり時間がかかる
sudo modprobe uvcvideo
sudo dmesg | tail -n 50
・・・エラーが出てないことを確認
これで/usr/local/libにlibrealsense.soがインスコされるので/usr/local/libをPATHに追加。
ユニットのテストプログラムは、buildフォルダの中のunit-testsにコンパイルされたSR300-live-testがあるので、実行すると36のテストプログラムのうち１つだけ失敗する。単なるバグかも知れない。
サンプルアプリは/usr/local/binにインスコされる。こちらは全て問題なく動く。安心のためAtomは力一杯空冷する。ホッほーって思ったのはやっぱり3D認識のデモアプリで、cpp-tutorial-3-pointcloud：マウスをグリグリすると3D構築されてるのが分かる。画像が荒いのは、恐らく深度計測の原理がtime-of-flight（赤外線を照射して反射光が帰ってくる時間を測定する）のため、解像度が低いんだろうと思う。
cpp-config.uiは露光時間とかIRレーザーの強度とかいろいろ設定が変えられて面白い。
D4.2 物体認識
D4.2.1 物体認識APIとは
SR300のドライバは動いたけど、SR300が動くSDKが無いので物体認識アプリの開発は素人には超ハードルが高い。目標はワンコやお魚さんの顔認識なんだけど、SDK 2016 R2のドキュメントによると2D object tracking (planar objects)で参照画像をそれぞれライブラリとして提供してやれば行けるんじゃないかと。しかし、そのためには少なくともIntelのSDKやgithubのZR300 SDKにあるAPIを解読して、SR300ベースにサンプルアプリを書き換えていくとか、完全に研究開発レベルだなこりゃ。SR300のSDK早よ。
RealSense SDKが使えなければ他の方法でやるしかない。OpenCVは、もともとIntelが開発したコンピュータ・ビジョン(computer vision)のライブラリで、画像処理、構造解析（輪郭とか）、物体追跡、パターン認識、機械学習などのアルゴリズムが実装されている。RealSense SDKも詰まるところOpenCVそのものなのかも知れない。OpenCVの最高に良い点は、Pythonからも使えることだ。
D4.2.2 OpenCV 3.1のインスコ
ソースはgithubのmasterからクローンする。OpenCVのHPからDLしたZipファイルだとうまく行かない。
git clone https://github.com/opencv/opencv.git
git clone https://github.com/opencv/opencv_contrib.git
依存ライブラリのインスコ（どのようなイメージプロセシングを行うかによる）
sudo apt-get install build-essential cmake pkg-config
sudo apt-get install libjpeg8-dev libtiff5-dev libjasper-dev libpng12-dev
sudo apt-get install libavcodec-dev libavformat-dev libswscale-dev libv4l-dev
sudo apt-get install libxvidcore-dev libx264-dev
sudo apt-get install libgtk-3-dev
sudo apt-get install libatlas-base-dev gfortran
sudo apt-get install python2.7-dev python3.5-dev
sudo apt-get install python-numpy python3-numpy
QT5.7のインスコ（使わなければ必要ない）
wget http://ftp.jaist.ac.jp/pub/qtproject/archive/online_installers/2.0/qt-unified-linux-x64-2.0.3-1-online.run
sudo chmod +x qt-unified-linux-x64-2.0.3-1-online.run
sudo ./qt-unified-linux-x64-2.0.3-1-online.run
sudo apt-get install qt5-default
ビルド
cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local -D WITH_TBB=ON -D WITH_V4L=ON -D WITH_QT=ON -D WITH_OPENGL=ON -D INSTALL_PYTHON_EXAMPLES=ON -D OPENCV_EXTRA_MODULES_PATH=~/Downloads/opencv_contrib/modules -D BUILD_EXAMPLES=ON ..
make
sudo make install
sudo /bin/bash -c 'echo "/usr/local/lib" > /etc/ld.so.conf.d/opencv.conf'
sudo ldconfig
Jouleでは容量ぎりぎり。opencvとopencv_contri自体がかなりでかく、他のファイルはほぼ全て削除した上で、ストレージ使用率80%くらいから始めて94％まで上がった。make installの後フォルダを削除すると、ストレージ使用率は50％まで落ちる。
テスト
$ python
>>>import cv2
OpenCVのcheckHardwareSupport関数の引数定義から、OpenCVがどんな命令セットを使うことが出来るか垣間見ることが出来る。
- CV_CPU_MMX
- CV_CPU_SSE
- CV_CPU_SSE2
- CV_CPU_SSE3
- CV_CPU_SSSE3
- CV_CPU_SSE4_1
- CV_CPU_SSE4_2
- CV_CPU_POPCNT
- CV_CPU_AVX
- CV_CPU_AVX2
- CV_CPU_NEON
neonはARM CortexのSIMD命令、popcntはSSE4.2の命令のひとつ。JouleのT5700はSSE4.2までは持っている。
D4.2.3 OpenCV 3.1の顔認識サンプルコード
Real Python: Face Recognition With Python, in Under 25 Lines of Code, by Shantnu Tiwariからコピー。
face_recognition_cv3.py
import cv2
import sys
imagePath = sys.argv[1]
cascPath = sys.argv[2]
faceCascade = cv2.CascadeClassifier(cascPath)
image = cv2.imread(imagePath)
gray = cv2.cvtColor(image, cv2.COLOR_BGR2GRAY)
faces = faceCascade.detectMultiScale(
gray,
scaleFactor=1.004,
minNeighbors=5,
minSize=(50, 50)
)
print("Found {0} faces!".format(len(faces)))
for (x, y, w, h) in faces:
cv2.rectangle(image, (x, y), (x+w, y+h), (0, 255, 0), 2)
cv2.imshow("Faces found", image)
cv2.waitKey(0)
使い方：
python face_recognition_cv3.py <イメージファイル> <カスケードファイル>
- イメージファイル： png, jpgなどソースイメージ
- カスケードファイル： haarcascade_frontalface_default.xmlからDL
カスケードファイルとは、予め対象となる物体の特徴を機械学習させた情報を含むXMLファイルで、opencv/data/haarcascadesフォルダに人の顔とか目とかのデータが入っている。
- haarcascade_frontalface_default.xml
- haarcascade_frontalface.xml
- haarcascade_frontalface_alt.xml
- haarcascade_frontalface_alt2.xml
- haarcascade_frontalcatface.xml
ねこのカスケードファイルがあるってことは、ワンコやお魚さんのもどこか探せばあるかな、と思ったら、意外と無いみたい。ま、ある意味proprietaryな情報だからムリもないか。
PythonコードのscaleFactorとは、イメージ・ピラミッドを生成する際の縮小倍率のことで、1.0以上の値で微調整する。値が1に近いほど検出感度は高くなるが、同時に顔ではないパターンを誤認しやすくなる。minSizeは解析ウィンドウのサイズ。
人間用のカスケードファイルで、パファフィッシュ：フグでもやってみた。検出しているようで、していない。恐らく茶色の模様を眼と誤認している。では、ねこさん用のカスケードファイルでねこさんを検出したらどうか。
ということで、どうやら各動物毎の専用カスケードファイルを手に入れる（自作する！）ことが成功の鍵になりそうだ。因みに、Haarカスケードを自分で作るとするとOpenCVのhaartraining関数opencv_traincascadeを使うらしい。材料になる画像データはオックスフォード大のグループが集めてるデータセットとか。
Haar-like feature（要するに矩形パターン）で顔認識を実行してる動画＞Adam Harvey@youtube
D4.2.4 SR300のRGBストリームを使った顔認識
追記予定
E. Ubuntu 16.04.1開発環境
E1.Ubuntu 16.04.1LTS (Classic)をインスコ
※https://communities.intel.com/thread/106120から引用
Ubuntu 16.04.1 LTSの導入自体はあっけない程トラブルフリーなんだけど、何か触ろうとするといきなりアプリ管理ツールが吹っ飛んだり、NetworkManagerサービスがどうやっても立ち上がれなくなったりと、地雷だらけ。
E1.1 Ubuntu 16.04.1 LTSのイメージファイル
Ubuntuサイトのリンクが間違ってるそうなので注意。
※http://people.canonical.com/~platform/snappy/tuchuck/tuchuck-xenial-desktop-iso-20161006-0.iso
E1.2 コマンドラインでUbuntu 16.04.1の起動USBドライブを作る方法
パーティションエラーを回避しなければならなかった時期の参考情報。現在は解決しているので、E1.3の方法を推奨。
Ubuntu 16.04.1ホストPCから
・sudo apt-get install p7zip-full
・sudo fdisk -l （USBドライブの確認）
ここでは、/dev/sdbをUSBと仮定
・udisksctl unmount -b /dev/sdb1
・sudo sgdisk --zap-all /dev/sdb
・sudo sgdisk --new=1:0:0:0 --typecode=1:ef00 /dev/sdb
・sudo mkfs.vfat -F32 /dev/sdb1
・sudo fdisk -l /dev/sdb（USBドライブの確認）
・sudo mount -t vfat /dev/sdb1 /mnt
・sudo 7z x tuchuck-xenial-desktop-iso-20161006-0.iso -o/mnt/
または
・sudo dd if=/tuchuck-xenial-desktop-iso-20161006-0.iso of=/dev/sdb
・sudo unmount /mnt
LiveCDモードでJouleを起動LiveCDモードで起動したら、まずapt-getでgpartedをインスコ。gpartedを起動し、左上のメニューからeMMC（mmcblk0）を選択。マウントされている２つのパーティションをunmountし、３つのパーティションを全部削除、次いでext4シングルパーティションを作成。ここから先は通常のUbuntuインスコプロセスと同じ。 最終的に4.4.0-31と4.4.0-36カーネルがインスコされてしまうので、apt-getで31カーネルを削除。
E1.3 WindowsのRufus-2.11pでUbuntu 16.04.1の起動USBドライブを作る方法
Ubuntu 16.04.1の公式サイトでは起動USBドライブの作成にRufusを推奨しており、Jouleエディションの場合もRufusで問題なく起動ドライブを作ることが出来る。注意するのは、canonical.comのISO置き場に2つのUbuntuイメージがあり、
- tuchuck-20161014085519.img.xz (465MB)
- tuchuck-xenial-desktop-iso-20161006-0.iso (1.8GB)
の中、大きい方のxenial-desktop版を選ぶこと。Ubuntuのサイトにはごちゃごちゃ書いてあるけど、非常に簡単。
Rufusの設定項目
・Partition scheme: MBR partition scheme for BIOS or UEFI
・File system: FAT32
・Cluster size: 4096
HDMI、USBハブにUSB起動ドライブ、KB、マウスをつないで、DC12Vで起動。自動的にOEMインスコが始まって、何事もなくUbuntuが入る。すばらしい。
システム情報でUbuntu Coreではないことを確認。
GPartedをインスコして、eMMCが適切にパーティションを切られていることを確認。ベータになる前はこのパーティションが崩れていて、sgdiskを使った迂回路がとられていたのであった。それも必要なくなった。
ただし若干の不安定さは残っていて、システムアップデートしたらgnome-software、つまり肝心のアプリ管理ツールが壊れた。
解決は簡単で、
# sudo apt-get remove --purge gnome-software
# sudo apt-get install gnome-software
安定版が出るまではライブラリの導入とか少し慎重になった方が良いかもしれない。
E1.4 UbuntuにHandbrakeやffmpegをインスコ
インスコには何の問題も無い。ただ、ハードウェアエンコーディングが出来ない。
かなりパワフルなUbuntuマシンになった。QSVとかH.264/H.265エンコのベンチが楽しみ。
＞UbuntsuでQSVやハードウェアエンコーディングしようとすると、Intel(R) Media Server Studio 2017の、しかもProfessionalが必要らしい。でも、$3999って何よ、それ？
E1.5 Slicer4で3Dレンダリング
以前、GTX960のレビューでも使ったSlicer4というCTやMRI画像の3Dレンダリングソフト。Ubuntuで走らせようとすると、依存性のあるライブラリを入れてあげる必要があるけど、それ以外は問題なく動く。
libcharls1_1.0-5_amd64.deb
libopenjpeg2_1.3+dfsg-4.7ubuntu1_amd64.deb
libopenjpeg-dev_1.3+dfsg-4.7ubuntu1_amd64.deb
libgdcm2.2_2.4-1.1ubuntu4_amd64.deb
libgdcm2-dev_2.2.4-1.1ubuntu4_amd64.deb
libdcmtk2_3.6.0.-15_amd64.deb
libdcmtk2-dev_3.6.0-15_amd64.deb
libinsighttoolkit4.5_4.5.0-3_amd64.deb
libinsighttoolkit4-dev_4.5.0-3_amd64.deb
最後に/usr/lib下にインスコされたlibitkhdf5-4.5.soにlibitkhdf5.soのsymlinkを張ってSlicerを起動。
E1.6 UbuntuにおけるXDK開発環境
E1.6.1 Ubuntu用のxdk-daemonが無い
現在、Ubuntu 16.04.1をインスコしたJouleにSSH接続出来ない問題が発生中。XDKからJouleにアップロードできない。
XDKからJouleに接続するにはJoule上でxdk-daemonが走っていなかればならないが、Ubuntuにはこれが無いのでsshのtcp入力から58888へのポートフォワーディングが出来ていないことが原因と思われる。Intel XDK FAQsに答えが。
Can the xdk-daemon run on other Linux distributions besides Yocto?
The Intel XDK xdk-daemon is currently (November, 2016) only supported on the Yocto and Ostro Linux distributions. Work is ongoing to provide a version of the xdk-daemon that will run on a wider range of IoT Linux platforms.
という訳で、YoctoとOstro以外のLinuxにも現在xdk-daemonを開発中とのことだけど、EdisonやGalileoだけじゃなくてJouleにも作ってくれるのかどうかはまだまだ地雷のようだ。
E1.6.2 Ubuntu用のxdk-daemonリリースされる
12月14日にリリースされたクリスマスバージョンのXDKからJouleにもxdk-daemonが提供されることに。
※xdk_web_linux64_master_3759.tgz
展開し、install.shスクリプトを実行。
Ubuntuの方でもSSH接続を通しておく必要があるので、A2.2を参照しつつ
sudo apt-get install openssh-server
sudo nano /etc/ssh/sshd_config
PermitRootLogin prohibit-password
から
PermitRootLogin yes
へ変更
それからポート開放。
$ iptables -F
$ iptables -P INPUT ACCEPT
$ iptables -P FORWARD ACCEPT
$ iptables -P OUTPUT ACCEPT
$ iptables -S
XDKを立ち上げる。IntelユーザIDがあればログイン。
プロジェクトを開いて、デバイスをマニュアル接続しようとすると、自動的にxdk-daemonを検索してインストールしろと。
ダウンロード始まる。
インストール始まる。
インストール・ログ。
おぉっ、通ったみたいだ (´；ω；｀)
ここまで来るのに、遠い遠い道のりだった。
UbuntuでXDKが動くのは大きい。母艦PCが要らないってことだから。Jouleだけで完結するってことだから。これは大きい。
※現在、rootアクセス制限（/node_app_slot -> /home/root/.node_app_slot）の問題があって回避策を検討中だけど、ここまで来たらな何とかなると思う。
E1.6.3 XDKのプロジェクトアップロードのrootアクセス制限回避策
第1案 ルート権限でXDKを立ち上げる
cd /opt/intel/XDK
gksudo ./xdk.sh
Ostro XTでは同様のrootアクセスエラーが発生しないことから、Ostro XTではXDKはroot権限で走っていると考えられる。
XDKからデバイスに接続しようとすると、xdk-daemonがユーザのルートディレクトリにDLされる。現在のファイル名は、
xdk-daemon-0100-x64-ubuntu-anyboard-node-4.5.0_master
これが展開されたxdk-daemon-0100-x64-node-4.5.0フォルダのsetup.shスクリプトがxdk-daemonをインスコするんだけど、基本的なシンタックスエラーが含まれているので修正する必要がある。まず、走っているxdk-daemonを止めて、不完全にインスコされたxdk-daemonフォルダを削除してから編集する。
systemctl stop xdk-daemon
sudo rm -rf /opt/sdk-daemon
cd ~/xdk-daemon-0100-x64-node-4.5.0
nano setup.sh
次の５つのラインから＄SUDOを削除する。
$SUDO cd $DIR
$SUDO exort CPLUS_INCLUDE_PATH=/usr/include/avahi-compat-libdns_sd
$SUDO cd $DIR/current
$SUDO cd $DIR/current/node-inspector-server
$SUDO cd $DIR
mdnsモジュールをインスコするのに必要なライブラリを入れてから、セットアップ開始。
sudo apt-get install libavahi-compat-libdnssd-dev
./setup.sh
これで、 mdns, bindings, nanという３つのnodeモジュールが /opt/xdk-daemon/currentフォルダにインスコされる。
セットアップの最後にデーモンを開始するかどうか聞かれる。手動でも開始できる。
systemctl start xdk-daemon
第２案 ユーザがアクセスできるフォルダに変更する
.node_app_slotをユーザがアクセスできる所に作る。
mkdir home/$USER/.node_app_slot
sudo rm -rf /node_app_slot
sudo ln -s /home/$USER/.node_app_slot /node_app_slot
cd /opt/intel/XDK
./xdk.sh
E1.6.5 XDKインスコ・オプション
$ ./install.sh --help
This program installs Intel(R) Software Development Products.
Usage: install.sh [options]
-h, --help print this message
-v, --version print version information
-s, --silent [FILE] run setup silently, with settings in the configuration file
-d, --duplicate [FILE] run setup interactively, record the user input into the configuration file
-l, --lang set user interface language
-t, --tmp-dir [DIRECTORY] set custom temporary folder
-D, --download-dir [DIRECTORY] set custom download folder
--user-mode run setup with current user privileges
--ignore-signature skip signature validation
--ignore-cpu skip CPU model check
--nonrpm-db-dir [DIRECTORY] set directory to store product installation database
--SHARED_INSTALL install to a network-mounted drive or shared file system for multiple users
All provided paths must be absolute.
Copyright (C) 2006-2016 Intel Corporation. All rights reserved.
--user-modeを付けると、ユーザディレクトリにXDKをインスコできる。
E1.7 Python + MRAA + UPM開発環境の構築
Node.jsはXDKのGUI環境が使えるのでJoule + Ubuntuを活かせる、と思って数週間挑んだけど、ダメだった。Node.jsが対応出来ていない。
そこで初心に立ち返って、Pythonで攻めることに。これも色々、ほんとに色々あったんだけど、何とかまともに動くようになった、ついさっき。
E1.7.1 一番のポイントは、インスコする順序。これじゃないと動かないという。
<1> Install Node.js
sudo apt-get install nodejs npm
sudo update-alternatives —install /usr/bin/node node /usr/bin/nodejs 10
//update-alternatives: using /usr/bin/nodejs to provide /usr/bin/node (node) in auto mode
sudo npm install npm@latest -g
sudo npm cache clean -f
sudo npm install -g n
sudo n 6.9.1
sudo apt-get purge nodejs npm
sudo node —version
v6.9.1
sudo npm —version
3.10.8
<2> Install MRAA
sudo apt-get update
sudo install build-essential swig3.0 python-dev nodejs-dev cmake libjson-c-dev
git clone https://github.com/intel-iot-devkit/mraa.git
cd mraa
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ..
make
sudo make install
<3> Install Oracle JAVA JDK
sudo apt add-apt-repository ppa:webupd8team/java
sudo apt-get update
sudo apt-get install oracle-java8-installer
sudo apt-get install oracle-java8-set-default
<4> Install UPM
sudo apt-get update
sudo apt-get install libjpeg-dev
git clone https://github.com/intel-iot-devkit/upm.git
cd upm
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ..
make
sudo make install
<5> Install ibmiotf for Python
sudo apt-get update
sudo apt-get install python-pip
sudo pip install paho-mqtt iso8601 pytz requests
sudo pip install ibmiotf
※コメント
Node.jsを使わないのに最初にインスコするのは、これがないとMRAAのビルドが通らないから。しかも、6.9.1じゃないとだめでnightly buildの7.2.0ではMRAAがコンパイル出来ない。ここを通過するのに一番時間が掛かった。Linuxはね、エラーメッセージが意味不明、って言うか思いっきり誤解を招くようなことが多い。だから嫌い。
MRAAのビルドではインスコするフォルダをINSTALL_PREFIXで/usrに指定しておかないと、デフォで/usr/local/libに入ってしまって、後でsudo pythonした時にPATHを通すのが面倒。それから、GitHubのintel-iot-devkit/mraaには、Ubuntuにはapt-add-repository PPA:mraa/mraaでapt-get installせよと書いてあるけど、だめ。MRAAはインスコ出来てもUPMのインスコに失敗する。MRAAをローカルにビルドするしかない。UPMのビルドも同様。
何でsudoにこだわるかと言うと、基本的にsudoで起動しないとペリフェラルのGpioポートとかI2Cとかが全部writeエラーになって、何やってもだめだから。ここも鬼門。Permissionいじってもだめ。
make/install + INSTALL_PREFIX:PATH=/usrでインスコされるフォルダ
/usr/lib/python2.7/dist-packages
pip install upmでインスコされるフォルダ
/usr/local/lib/python2.7/dist-packages/upm
Oracle JAVAはUPMに必要だったかな。忘れた。
Ibmiotfは、出来ればMRAAやUPMのようにローカルビルドして/usr/libに入れたいんだけど、どうしてもだめだった。それでpython pipを使ってインスコすると/usr/local/lib/Python2.7/dist-packages/ibmiotfに行ってしまうので、PYTHONPATHで/usr/lib/Python2.7/dis-packages/upmと一緒にexportする。pip installの環境変数で/usr/libにインスコ出来ればいいと思うけど、出来るかどうかまだ分からない。
sudoでPython起動するとPATHを持って行ってくれないので、PYTHONPATHを設定した上で
sudo PYTHONPATH=$PYTHONPATH python xxxx.py
インタープリタモードなら、スクリプトでsys.path.appendしても良い。
いやぁ、死ぬほどだめ出し食らってどうしようかと思った。まじ。
※gpio export周辺のパーミッションエラーの回避策
RasPiでも”古典的”トラブルシューティングのようで。Intelコミュの記事MRAA and Ubuntu 16.04.1 LTSと、引用元のRasPi板の記事Fixing GPIO user permission errorsから：
１）グループgpioを新規作成し、GPIOにアクセスしたい人を参加させる
sudo groupadd gpio
sudo usermod -a -G gpio $USER ($USERは参加させたい人のユーザ名）
２）次の2行を/etc/rc.localに加える：sudo nano /etc/rc.local
chown -R root:gpio /sys/class/gpio
chmod -R ug+rw /sys/class/gpio
３）新規udevルールを作成；sudo nano /etc/udev/rules.d/80-gpio-noroot.rules
SUBSYSTEM=="gpio", PROGRAM="/bin/sh -c '/bin/chown -R root:gpio /sys/devices/platform/INT34D1:*/gpio'"
SUBSYSTEM=="gpio", PROGRAM="/bin/sh -c '/bin/chmod -R ug+rw /sys/devices/platform/INT34D1:*/gpio'"
4）ここで再起動が確実
これやっておくとPythonからもgpioアクセス出来るようになった。尚、3)のルールで動かなければls /sys/class/gpio -laでgpioのsymlink先がINT34D1で合ってるかどうか確認する必要があるかも。そもそも、gpioデバイスがrootで作成されることの方がlinuxのほんとにナンセンスな所だと思うんだけど。chownやchmodするくらいなら、始めからユーザ権限で作れって。Ostro XTではどうやってこのエラーを回避してるんだろ？まさか同じようなudevルールをこっそり忍ばせたりしてないよな。それとgpio以外のI2Cとかでも類似の回避策が必要なのかどうかは確認が必要。地雷は続くよ。。。
ところで、あんまり夢中になってコンパイルしてると熱でCPUスロットル絞られることに。知らないうちに速度が落ちてるだけならいいけど、コンパイルエラーになってたら目も当てられない。空冷必須。Jouleの電力管理がきちんと作動していると、善意に捉えるべきか。
いろいろいじってるとカーネルが壊れるので何度もUbuntuインスコするはめに。でも慣れた。壊れたら再インスコすればいい。
E1.7.2 加速度センサのデータをIBMクラウドへ
クイックスタートはユーザ登録もなにも必要なくて、quickstartモードでpublishするだけ。簡単だけど、データ送信速度とか制限されるので、少しぎこちない表示にはなる。
※コード
import time, sys
import pyupm_mma7660 as m
import ibmiotf.device
#sys.path.append('/usr/lib/python2.7/dist-packages/upm')
myAccel = m.MMA7660(0, 76)
myAccel.setModeStandby()
myAccel.setSampleRate(64)
myAccel.setModeActive()
x = m.new_intp()
y = m.new_intp()
z = m.new_intp()
ax = m.new_floatp()
ay = m.new_floatp()
az = m.new_floatp()
options = {
"org": "quickstart",
"id": "sorrowXXXXXX",
"type": "sensor",
"auth-method": None,
"auth-token":None
}
try:
client = ibmiotf.device.Client(options)
except Exception as e:
print("Caught exception connecting device: %s" % str(e))
sys.exit()
client.connect()
while(1):
myAccel.getRawValues(x, y, z)
myAccel.getAcceleration(ax, ay, az)
data = {
'Sensor': 'mma7660 I2C 3-axis digital accelerometer',
'raw-x': m.intp_value(x),
'raw-y': m.intp_value(y),
'raw-z': m.intp_value(z),
'accel-x': m.floatp_value(ax),
'accel-y': m.floatp_value(ay),
'accel-z': m.floatp_value(az)
}
client.publishEvent("Intel Joule(R)", "json", data, qos=0, on_publish=None)
time.sleep(0.33333)
client.disconnect()
普通のPC。4Kまで行けるから、もっとすごいはず。
Groveのデバイス。
E1.7.3 Grove CO2センサ
赤外線吸収に基づくCO2センサ、MH-Z16。なんてことは無い、UART接続すればいいだけのはずだった。が、ここにも予想外の地雷が。
なぜか、JouleのUARTソケットに接続しても、何やっても認識しない。だいたい、mraaのUARTクラスの初期化から失敗する。探し回った挙句、なんとmraa 1.5.1のドキュメントにこんなことがこっそり書いてあるじゃないか：
UART UARTと表記してあるピンがありますが、BIOSでUARTとして設定されていないため、UARTとして使えるのはFTDIヘッダだけです。[オッオー！]ttS2のgettyを無効化し、mraaのuart rawモードを使ってttS2を初期化します。[は？]ジャンパJ8でFTDI6ピンヘッダかmicro USB出力か切り換えます。
そりゃ、ないよ。ひどい orz...
むき出しのランドにソケットをはんだ付けしてなんとかしようかと思ったけど、直ぐ横に小さな抵抗器が表面実装されてたりして、危険すぎるため断念。ちょっとムリ。
UART-I2Cアダプタでなんとかならないか検討中。
E2.JouleにMiracastドライバをインスコ
Jouleプロジェクトの残るひとつは、ワイヤレスディスプレイだ。強力なJouleの動作を離れた所からモニタ出来る。Jouleには２バンド・ワイヤレスチップAC 8260が搭載されていて、Intel WiDi（昨年１０月Ⅱサポートが終了してしまった）とMiracastをサポートする。WiDiは恐らくWiFi-Directの略で、WiFi P2P (peer to peer)とも呼ばれる。ネットで探すと、Linuxのワイヤレスディスプレイ・プロジェクトが２つ見つかる。
E2.1 IntelのWDS@01.org
WDS即ちWireless Display Software for Linuxは、メインライブラリのlibwds、GlibとGStreamerを組み込むためのnetwork、ConnmanのWiFi P2P機能を組み込むためのp2pで構成される。GLib, GStreamer, ConnMan, WPA supplicant及びWiFi-DirectプロトコルをサポートするWifiアダプタが必要となる。
E2.1.1 アダプタの互換性について
Intel WDSのサイトにある互換性リストによると、NETGEARのPush2TV (PTV3000)がWiFi P2Pに対応していることになっている。
E2.2.2 依存性ライブラリのインスコ
Intel WDSはWiFiデーモンのwpa_supplicant、ネットワーク接続マネージャのConnManを必要とする。WiFi P2PはConnManのバージョン1.26以降でサポートされるが、Ubuntuレポジトリにあるのは1.21-1.2build2（apt-getでインスコされるやつ）なので、自分でConnManをビルドする必要がある。最新のConnManのバージョンは1.33 (https://01.org/connman)で、p2pの機能が改良されているらしいのでお勧め。今のOstro XTに入ってるConnManのバージョンは確認していないが、もし1.26以降だったらラッキーで、以下の面倒なインスコ手順は無視していい。
まず、ConnManをビルドするのに必要となるライブラリ。
$ sudo apt install autoconf libtool-bin autopoint bison flex gtk-doc-tools
$ sudo apt-get install gnutls-bin libgnutls-dev
これでGnuTLS 3.4.10-4ubuntu1.1がインスコされる。
最新のGnuTLSをインスコすることも不可能ではないけど、かなりの手間を要する。ConnMan 1.33のビルドに必須ではないので、apt-getでいいと思うけど、一応やってみたので。
$ wget https://gmplib.org/download/gmp/gmp-6.1.2.tar.lz
$ ./configure
$ make
$ make check
$ sudo make install
$ wget https://www.gnupg.org/ftp/gcrypt/libgpg-error/libgpg-error-1.26.tar.bz2
$ tar -xzvf libgpg-error-1.26.tar.bz2
$ cd libgpg-error-1.26
$ ./configure
$ make
$ sudo make install
$ wget https://www.gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.5.tar.bz2
$ tar -xzvf libgcrypt-1.7.5.tar.bz2
$ cd libgcrypt-1.7.5
$ ./configure
$ make
$ make check
$ sudo make install
$ git clone https://git.lysator.liu.se/nettle/nettle.git
$ cd nettle
$ ./.bootstrap$ ./configure && make
$ sudo make install
$ git clone https://gitlab.com/gnutls/gnutls.git
$ cd gnutls
$ git submodule update --init
$ make bootstrap$ make
$ make check
$ sudo make install
E2.1.3 ConnMan 1.33をインスコする
$ sudo apt-get install xtables-addons-source
$ sudo apt-get install libreadline-dev
$ wget https://www.kernel.org/pub/linux/network/connman/connman-1.33.tar.xz
$ tar -xzvf connman-1.33.tar.xz
$ cd connman-1.33
$ ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
$ make
$ sudo make install
E2.1.4 wpa_supplicantのビルド環境設定とインスコ
$ wget http://w1.fi/releases/wpa_supplicant-2.6.tar.gz
$ tar -xzvf wpa_suppicant-2.6.tar.gz
$ cd wpa_supplicant-2.6
$ cd wpa_supplicant
ここで、wpa_supplicantのビルド環境を設定するために、作業ディレクトリに.configファイルを作成する。
$ nano .config
CONFIG_DRIVER_NL80211=y
CONFIG_CTRL_IFACE=y
CONFIG_CTRL_IFACE_DBUS_NEW=y
CONFIG_P2P=y
CONFIG_AP=y
CONFIG_WPS=y
CONFIG_WIFI_DISPLAY=y
CONFIG_LIBNL32=y
以下、wpa_supplicantのビルド、インスコ手順。エラーが出るので依存性ライブラリを追加している。この辺もサイトには書いてないので、試行錯誤で。
$ sudo apt-get install libssl-dev libdbus-1-dev
$ sudo apt-get install libnl-genl-3-200 libnl-genl-3-dev libnl-idiag-3-dev
$ make
$ cp wpa_supplicant wpa_cli wpa_passphrase /usr/local/bin
wpa_supplicantのビルドが通ってインスコ出来たら、/etcディレクトリにwpa_supplicantの動作設定ファイルを作っておく。Jouleのデバイス名とかデバイス・タイプの指定とか、p2pのスキャン条件とか。他にもwifiの設定項目が色々あるんだけど、取り敢えずこれで動くので。
$sudo nano /etc/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
update_config=1
ap_scan=1
device_name=Broxton-M
device_type=1-0050F204-1
driver_param=use_p2p_group_interface=1
p2p_go_intent=15
p2p_go_ht40=1
E2.1.5 wpa_supplicantとconnmanのデーモン動作確認
まず、ConnManをインスコすると、UbuntuにデフォルトでインスコされてるNetworkManagerが使えなくなる。これは知らないと焦る。どうもネットワーク設定ファイルが上書きされてしまうから、らしい。もしインスコしたConnManでネット接続が回復出来なかったら・・・、Unbuntu再インスコしかないかもorz ま、とにかくNetworkManagerは使えなくなるので削除していいでしょ。
$ sudo killall -STOP NetworkManger
$ sudo apt-get remove --purge network-manager network-manager-gnome network-manager-pptp network-manager-pptp-gnome
Jouleのネットワークアダプタのデバイス名をチェックするのはifconfigコマンドで。wlp1s0になっていると思う。これをwpa_supplicantの引数に指定する。
$ sudo wpa_supplicant -i wlp1s0 -c /etc/wpa_supplicant.conf -D nl80211 -ddt
-iはintefaceかな、-cはconfiguration file、-Dはドライバ、-ddtは不明。それから別のターミナルウィンドウを開いて、p2pデバイスをスキャンする。
$ sudo wpa_cli -i wlp1s0
>p2p_find 10
10秒間スキャンするという意味。これで周辺にwifiデバイスがあれば表示されるはず。
wpa_supplicantとconnmandをデーモン（バックグラウンド処理）で立ち上げて、connmanctlインターフェースからp2pデバイスをスキャンすることも可能。ワイヤレスディスプレイではこの方法で接続を行う。
$ sudo wpa_supplicant -ddt -u
$ sudo connmand -n -d
$ connmanctl
connmanctl> technologies
connmanctl> enable wifi
connmanctl> enable p2p
connmanctl> scan p2p
connmanctl> peers
technologiesでP2Pが表示されれば大成功。無ければ何かがうまく行っていない。
IYH！これでPush2TVが表示されて、任務完遂までもう一息。
E2.1.6 WDSのビルドと動作確認
WDSはGStreamerとGTKに依存するので、まずこいつらを入れておく。
$ sudo apt-get install libgstreamer1.0
$ sudo apt-get install libgstreamer1.0-plugins-base
$ sudo apt-get install libgstreamer1.0-plugins-good
$ sudo apt-get install libgstreamer1.0-plugins-ugly
$ sudo apt-get install libgstreamer1.0-plugins-bad
$ sudo apt-get install libgtk2.0
GStreamerは0.1バージョンと1.0バージョンがあって、1.0の方が推奨されている。apt-getで入れるとGStreamer1.0-0 version 1.8.2-1-ubuntu1がインスコされる。githubのソースからGStreamerをビルドしようとすると、x264パッケージを別途インスコする必要があって、知らないとコケる。
GStreamer1.0をインスコすると、最初pluginが認識されなくて困ったけど、 .bashrcに
export LD_LIBRARY_PATH=/usr/local/lib
を記述してソースして、さらにGStreamer1.0のキャシュを削除してpluginを再スキャンさせてやる。インスペクトツールでpluginが認識されることを確認。
$ rm -rf ~/.cache/gstreamer-1.0
$ gst-inspect-1.0 ximagesrc
GTK2.0-0は version is 2.24.30-1ubuntu1がインスコされる。ここでやっとWDSのDLとインスコ。
$ git clone https://github.com/01org/wds.git
$ cmake .
$ make
$ sudo make install
ミラーリングの手順は、ターミナルウィンドウを４つ開いて、 (1) wpa_supplicantのデーモン開始、(2) connmandのデーモン開始、(3) connmanctlでエージェント登録、(4)WDSのサンプルコード立ち上げ。
# terminal 1
$ sudo wpa_supplicant -ddt -u
#terminal 2
$ sudo connmand -n -d
#terminal 3
$ connmanctl
connmanctl> agent on
Agent registered
#terminal 4
$ cd wds
$ cd desktop_source
$ ./desktop-source-test
* Regsitering Wi-Fi Display Source with IE xxxxxxxx
* Now scanning for peers...
0: Push2TV PTV3000
connect 0
画面4でconnect 0を入ロすると、画面３に接続確認のプロンプトが出るのでリターンキー。これで上手くいくと、下の写真の右下の画面４のメッセージが表示されて接続完了となる。
同じモニタのDVIにJoule、HDMIにPush2TVを接続して見ているので、少し違うのが分かる。
まず、こちらがオリジナル画面。
こちらがPush2TVのミラー。
デスクトップのミラーリングは、マウスのトラッキングが１秒ほど遅れてしまって実用レベルではなかった。また、原因は良く分からないが接続のニゴシエーションに失敗する頻度も高かった。
とは言え、ロボティックスなど動くJouleの画面出力を離れた所からリアルタイムに観察できるというのは素晴らしい。GalileoでWiFi P2Pを使ってデータ送信している人は居るけど、ワイヤレスディスプレイを実証したのはこれが初めてだと思う。取り敢えず、めでたしめでたし。＼(-o-)／
E2.2 ablfanのMiracleCast
MiracleCast is compatible with Miracast, and depends only on GStreamer, GLib, and Systemd libraries. Building from source and activating it are as simple as;
MiracleCast（ミラクルキャスト）はMiracastと互換性があって、GStreamer, GLib, システムライブラリだけど動くという。ソースからのビルドと使い方は非常にシンプル。（動作検証中）
$ mkdir build
$ cd build
$ cmake ..
$ make
$ sudo make install
$ sudo kill -9 $(ps -ef | grep wpa_supplican[t] | awk '{print $2}')
$ sudo miracle-wifid &
$ sudo miracle-sinkctl
F.資料
F1.スペックまとめ
- Soc: Intel Atom Broxton-M T5700
- CPU: 64-bit, quad-core Goldmont @1.7GHz, 2.4GHzまでターボ
- GPU: Intel Gen9LP (Skylake相当, 18実行ユニット)
- RAM: 4GB LPDDR4
- ストレージ: 16GB eMMC
- 通信: Intel Dual Band Wireless-AC 8260 (802.11ac + MIMO) + BT 4.2
- I/O: USB 3.0/PCIe Gen2（排他的）, UART, GPIO, I2C, MIPI SI, MIPI DSI
- その他： RealSenseカメラサポート, Miracast, Quick Sync Video, H.264/H.265/VP8の４Kビデオエンコード・デコード
T5700の高速演算性能に加え、様々なビデオエンコードツール、コンピュータビジョン、イメージパイプラインのサポートを謳っているのが特徴と言える。IntelはWiDiのサポートを2016年10月で完全に打ち切ってしまったが、Miracastを使えということらしい。
AnandtechのSkylake GPU解説記事によると第9世代GPUのQuick Sync VideoはFF (Fixed Function)-Modeと言ってH.264エンコードを実時間に合わせて実行することで、これまでの実時間よりも高速な処理(PG-Mode)に比べ、レイテンシを落とし（意味不明）、省電力を図っているのだそうだ。ただしH.265エンコードはPG-Modeとある。
F2. Tuchuckピンアウト
Jouleの拡張ボードのことをTuchuckとかGrosse Tette（Big Head）とか呼んでる。
F3. UPMレポジトリ(ver.1.0)
※https://github.com/intel-iot-devkit/upm/blob/master/README.md
F4. Jouleに於けるRealSenseテクノロジの互換性
F4.1 公式vs試験的サポート
JouleのスペックシートにはRealSenseテクノロジとの互換性が謳われており、Jouleの高速演算性能はRealSenseデバイスに於けるイメージ操作を第一の標的として開発されているかのような印象を与える。ところが、これまでRealSenseカメラやSDK, Depth Camera Manager (DCM)が公式にサポートしているのは、あくまでもWindows 10, 第6世代（Skylake）のCoreプロセッサのみで、Jouleは入っていない。一方で、試験的とは言いながらGithubから提供されるlibrealsenseドライバ・APIを使えばUbuntuとAtom T5700でSR300カメラを動かせることも事実だ。SkylakeとAtom T5700の性能の一番大きな違いは、AVX (advanced vector extensions)、AVX2命令セットがあるか無いかという点が挙げられるが、実際にJouleで動いている訳だからこれが必須とは言えない。SR300のシステム要件がSkylakeとなっている理由は、結局のところよく分からない。
F4.2 FAQ for Librealsense (Intel Support) 2016.10.18版
※幾つか注目ポイントがあるけど、ファームウェアアップデートにはWin 8.1/10とDCMが必須であること（新しいSDKのリリースと合わせてファームウェアがアップデートされる）、CPUアーキテクチャ依存性がSSE3に限られる（SSE4, AVX, AVX2は触れられていない）＝T5700でも動かない理由はないこと、Android向けのSDK/DCM開発が進められていることとか。
（sorrow訳）
librealsenseはIntel RealSense F200, SR300, R200カメラ用クロス-プラットフォーム(Linux, OSX, Windows)キャプチャ・ドライバです。ロボティクス、バーチャルリアリティ、IoTなどの分野の開発者、研究者をサポートするために開発が進められています。Intel RealSenseデバイスにしばしば求められる機能が実装されており、これには複数カメラのキャプチャも含まれます。現状、librealsenseは試験的APIに過ぎません。公式Intel RealSense SDKとは別ものです。
librealsenseはどこで手に入れますか？
GithubのURLから入手します：
https://github.com/IntelRealSense/librealsense
Intel RealSense SDKとは何が違いますか？
Intel RealSense SDKとIntel RealSense Depth Camera Managerランタイムは正式にサポートされており、商品開発に適した製品です。Windows 8.1, Windows 10、そして間もなくAndroidプラットフォームで動きます。Intel RealSense SDKはさらに包括的なコンピュータビジョン・アルゴリズムを提供します。librealsenseは、現在Intel RealSense SDKがサポートしていないプラットフォームにおけるカメラ・キャプチャーの実験的APIです。
librealsenseはどのカメラで使えますか？
Intel RealSense R200, F200, SR300カメラでlibrealsenseが使えます。このライブラリでは、特定のカメラのマイナーなハードウェア機能の一部は現在実装されていませんが、必要であることが明らかになれば組み込まれる予定です。Intel RealSense開発キットは互換性のあるUSB3.0ホストコントローラ・チップセットが必要ですが、確認されているのはIntelチップセットだけです。メーカー製品でもlibrealsenseが動くものがあります。例えば、Intel RealSenseカメラR200を内蔵するHP Spectra x2タブレットなど。
librealsenseで複数のカメラを使えますか？
USB3.0バスで送信出来るデータ量には上限があります。従って、librealsenseで扱えるのは8枚の640x480、30fpsのストリーム（depth stream）、または60fpsの4ストリームまで。IR（赤外線）やRGBストリームの組み合わせもUSBバスの負荷になります。ライブラリには実コードされた上限はないため、ユーザがハードウェアの限界を実験するのは自由です。
librealsenseと互換性があるのはどのOSですか？
Linuxについては、唯一サポートされているのはUbuntu 14.04.03 x64で4.4カーネル・アップデートの構成のみです。特にテストはされていませんが、librealsenseは色々なLinuxディストロで動くはずで、これはuvcvideoのパッチやカーネル・アップグレードでどのような変更が必要かによります。アップルOSXでは少なくとも10.8 Mountain Lionが必要です。Windowsで開発し、LinuxやOSXに展開することを考えている開発者のための互換性としては、Windows 8.1になっています。
カメラのファームウェアをアップデートするには？
RealSenseカメラは独占的ファームウェアが搭載されています。ファームウェアはバグフィックスのため定期的にアップデートされますが、librealsenseは現在新しいファームウェアをアップロードする機能を持ちません。サポートされている方法は、Windows 8.1とWindows 10からIntel RealSense Depth Camera Managerを使うものです。サポートされたPCにカメラを接続しIntel RealSense Depth Camera Managerをインストールすると、自動的にファームウェアがフラッシュされます。
ファームウェア・アップデートの通知を受け取るには？
ファームウェア・アップデートは通常Intel RealSense Depth Camera Managerのアップデートに合わせて出され、これはIntel RealSense SDKのリリースと重なります。新しいIntel RealSense SDKのリリースは、パブリック・チャンネル、例えばRealSense Twitterアカウントhttps://twitter.com/intelrealsenseから通知されます。
他のフレームワークでlibrealsenseが使えるのは？
librealsenseが互換性を持つようにデザインされているものには、Robotic Operating System (ROS), OpenCV, The Point Cloud Library (PCL)やその他多くのランタイム、フレームワークがあります。非公開で開発されているROSなどは、一般の方が使えるのは少し先になるでしょう。
Intelアーキテクチャへの最適化はなされていますか？
ライブラリの中心的機能はSSE3インストラクションで高速化されています。
librealsenseは非IA−プラットフォームでも動きますか？
箱から出したlibrealsenseはARMアーキテクチャではコンパイルしません。幾つかキーとなる面で使われるSSE3インストラクションのためです。コミュニティの貢献者が特定の機能を新しいアーキテクチャで使えるように再実装してくれるかも知れません。
F5. Intel XDK Update for December 2016（12月13日）
（sorrow訳）
Intel XDKカスタマの皆さん、ハッピーホリデー、そしてちょと早いけどハッピーニューイヤー！ホリデーシーズンに合わせ、新しいIoT機能をお届けします。
新しいIoTプラットフォームにサポートを拡張しました。このリリースで、Intel Jouleで走るUbuntu Linuxデスクトップが新たにサポートされます。さらに、通信デーモン[xdk-daemonのこと]は、これまでIntel JouleモジュールやIntel Edisonボードに搭載されたOSイメージで配布されていましたが、以後サポートされるプラットフォーム全てでIntel XDKが配布します。この新しい機能によりデーモンを最新に維持することが簡単になり、常に最新バージョンのデーモンが使えるようになります。デーモンがあるか無いか、アップデートの必要があるか無いかを自動的に判定し、ユーザが何もしなくても良いようにします。また、IoTクラウドAPIをNode.JS IoTアプリに組み込み、サードパーティのクラウド・プロバイダ：Amazon Webサービス、IBM Watson IoTHub、Microsoft Azur IoT Hubに接続できるようにしました。この機能はNode.JS IoTプロジェクトのデスクトップ・タブのWebサービスAPIエクスプローラ・パネルにあります。
（以下省略、HTML5モバイルアプリサポートツールが削除されたことになど関する記事）
F6.Ostro OSへの回帰
Ostroにはパッケージマネジャがないけど、こでいいのかもしれない。
F6.1 Ostro OSのアーキテクチャ概要
(sorrow訳)
この資料はOstro OSのアーキテクチャ（構造）と主な構成ブロックについて概観します。さらに、ハッキングからIoT製品の創造まで、さまざまなエンドユーザの使用目的にOstro OSがどのように合うのか簡単にお話しましょう。
Ostro OSの特徴
Ostro OSでは、アーキテクチャ設計を決定する4つの特徴があります。
１．Ostro OSは標準的ライブラリとサービスを使います：Ostro OSで使われる構成ブロックは多くのオープンソースプロジェクトで広く使われており、カスタム実装は可能な限り排除されています。これは大きな利点で、既存のアプリやサービスをOstro OSで走らせるために移植やプラットフォームへの適応の必要がほとんどありません：多くの場合、必要なのはそのアプリのマニフェスト（使われるライブラリ等のリスト）を作成することだけということになります。
２．Ostro OSはセキュリティを念頭に作られています：セキュリティはIoTにとって極めて重要で、Ostro OSはここに焦点を当てています。このセキュリティ設計はOstro OSベースの製品のセキュリティ設定においてスケーラブル（容量可変）な選択肢を提供します。セキュリティ設計についてはOstro OS System and Security Architectureに詳しい説明があります。
３．Ostro OSはカスタマイズが簡単です：Ostro OSは予めコンパイルされた（バイナリやイメージ）で提供される一方で、IoTアプリケーションの様々な製品要件に合うようカスタマイズすることが可能です。Ostro OSで使われているYocto Projectビルドシステムを使い、簡単にビルドをカスタマイズし、あなたの要求に的確に合致するよう細かく調整したイメージを作ることが出来ます。Introduction to the Ostro Projectページとリンク先は、Ostro OSの広範なカスタマイズの可能性について知るための良い出発点です。予めコンパイルされたイメージは開発作業をはかどらせることを意図しており、製品での使用には向いていません。
４．Ostro OSは予めコンパイルと設定が済んでいます：Ostro OSは、Yocto Projectのビルドシステムのツールを活用し、IoTデバイス開発のため特別に調整されたディストロとして予めコンパイルと設定が済ませてあります。あなた自身のOstro OSイメージを作りコンパイルするのはとても簡単で、Ostro OS SSTATEサーバが提供するShared State Cache (SSTATE)を使うよう設計されています。さらに、予めコンパイルされたリファレンス（参照）イメージをOstro Project download server
から入手し、即座に開始することも出来ます。
Ostro OSアーキテクチャのスタック
Ostro OSのアーキテクチャを記述する一つの方法として、ハードウェアプラットフォームからIoTアプリケーションの層までスタックを構築してみます。このスタックを図示すると、
(以下各レイヤーの解説省略)
F6.2 Ostro OSイメージの簡単ビルド法
Ostro OSのイメージを自分でビルドしてフラッシュするという方法。
F6.2.1 Building Ostro OS Images@Ostro Project
F6.2.2 Building Ostro(TM) OS XT@github
F6.3 ソフトウェア・アップデートによるOSの管理
Clear Linuxプロジェクトに由来する、ソフトウェア・アップデートによって機能を後から追加するという方法。基本となるOSイメージにはswupd-がファイル名に含まれる。そう、JouleのOstro XTイメージにも付いてたあれ；ostro-xt-image-swupd-intel-corei7-64-2016-08-13_13-03-59-build-170、何だろうって思ってた人、ピンポン！
F6.3.1 ソフトウェア・アップデート・リポジトリの構築
※Software Update: Building an Ostro™ OS Repository
F6.3.2 ソフトウェア・アップデート・クライアントの実行
追記予定
いぐなっちさん
2016/12/24
sorrowさん
2016/12/24
コメントありがとうございます。Ubuntuは面白いけど大変でした。