Google AIY Voice Kitが来た

Google AIY Voice Kit

Rasyberry Pi 3に繋いで音声認識で遊べるGoogle AIY Voice KitPimoroniで受注していたので注文し、初期入荷分4,000台のうちの一つを無事に入手しました。まだ箱を空けて中身の眺めただけで、組み立てていません。同梱されていた小冊子がマニュアルになっており、これに従って組み立てればよさそうです。

parcel from PimoroniPimoroniから届いた小包には「海賊ロボ忍者さる」の文字列が。どうも海外で流行ってる新種のジャンケンの手のようで、これらの頭文字からPimoroniは名付けられたとか何とか。

ちなみにPimoroniにはPi Zero Wの在庫もあったので、ついでに一つ購入しておきました。

なお、国内では今月末にKSYから発売になるようです。

Movidius NCSをTinker Boardから使う

Movidius NCSはRaspberry Pi (以下、RasPi)にも対応しています。RasPiのアーキテクチャはarmhf、OSはDebianベースのRaspbianです。どこかに似たような環境がありませんでしたか? そう、ASUS Tinker Boardです。Tinker Boardもarmhfアーキテクチャ、DebianベースのTinker OSで動作します。これはTinker Boardで動かしてみる価値がありそうです。

ということで試行錯誤してみた結果、動作させることができましたので情報を整理しておきます。キーポイントは

  • TinkerOSのPython3.5.3は互換性がなくNG
  • python3-setuptools, python3-wheelを事前に手動インストール
  • armhf向けの再配布用debパッケージを手動インストール

あたりです。

※注) 以下の方法はTinker Board上でMovidius NCSが安定して動作することを保証するものではありませんのでご注意下さい。

Tinker Boardはセットアップ済みとします。まずはapt lineを編集してベースをStretch (stable)からBuster (testing)へ変更し、システムを更新します。

$ sudo vi /etc/apt/sources.list
deb http://http.debian.net/debian/ testing main contrib non-free
#deb-src http://http.debian.net/debian/ stretch main contrib non-free
deb http://security.debian.org/ testing/updates main contrib non-free
#deb-src http://security.debian.org/ stretch/updates main contrib non-free
deb http://http.debian.net/debian/ buster-updates main contrib non-free
#deb-src http://http.debian.net/debian/ stretch-updates main contrib non-free

$ sudo apt update
$ sudo apt upgrade
$ sudo apt clean

src行もコメントアウトしてあります。おそらくaptコマンドで -t オプション指定してpython3だけtestingにすれば問題はないと思いますが、私は普段使いの環境もtestingなのでここではシステム全体をtestingにしています。この後に、

$ sudo apt install python3-setuptools python3-wheel

しておきます。この二つがインストールされていないと、SDKのインストール時にエラーになったりします (wheelの方はインストールしなくても大丈夫なようですが念の為)。

システムの更新が済んだら、SDKをインストールしていきます。まずはToolkitから。こちらはUbuntu環境と同様に展開してbin/setup.shを実行すればOKですが、だいぶ時間が掛かります。CPUをぶん回すためか、Tinker Boardもだいぶ熱くなりますのでご注意を。

次にAPIのインストールですが、その前にarmhf向けの再配布用debパッケージをインストールします。APIのtar.gzを展開したncapi/redist直下にもdebパッケージファイルがありますが、ここではさらにその下のpi_jessieディレクトリ以下にあるdebパッケージをインストールします。

$ sudo dpkg -i ncapi/redist/pi_jessie/*_armhf.deb

なお、ncapi/redist直下のpython3-mvncパッケージはpython3.5用、pi_jessie以下にある同名のパッケージはpython3.4用のようです。TinkerOSはpython3.5なので、pi_jessie以下のパッケージはインストールする必要はありません (all = 全アーキテクチャ向けなので前者で問題ありません)。

一旦ターミナルを開き直してToolkitが設定した環境変数を反映させてからAPIをインストールします。debパッケージをインストールしたら、ncapi/setup.shでAPIをインストールします。caffeモデルのDLにはしばらく時間が掛かりますが、その後のコンパイルはすぐ済みます。

最後にbin/data/dlnets.shを実行してcaffeのネットワークモデルをDLしたら、さっそくMovidius NCSをTinker Boardに挿してみましょう。OSの再起動は不要でした。

$ sudo dmesg | grep MA2X5X
[...] usb 1-1.4: Product: Movidius MA2X5X

OSから認識されているようですので、example00〜03を実行してみましょう。

$ cd ~/workspace/mvncsdk/bin/
$ make example00
$ make example01
$ make example02
$ make example03

エラー等も発生せず、問題なく実行できるかと思います。

Movidius NCSをセットアップする

Movidius NCS
Movidius Neural Compute Stick

intelに買収されたMovidius社から、USB接続型の機械学習(ディープラーニング)用アクセラレータ、Movidius Neural Compute Stick (以下、Movidius NCS)が発売されました。RSコンポーネンツMouserから入手できますが、現時点では在庫切れのようです。初期の入荷数が少なかったようですが無事に入手できましたので、環境をセットアップしてみました。

推奨環境はネイティブなUbuntu 16.04 amd64ですが、そんなに都合よく環境は用意できませんので、WIndows 7上のVMWare 12にUbuntuをインストールしました。

※注) 以下の方法はVMWare上のUbuntuでMovidius NCSが安定して動作することを保証するものではありませんのでご注意下さい。

Ubuntuのインストールが完了したらログインし、Movidius NCS SDKをセットアップします。手順はGetting Startedに書かれている通りに進めれば何の問題もありません。マシンパワーやネットワークの速度によっては、pythonモジュールのインストールやcaffeモデルのDL等に時間が掛かることがあります。

引っ掛かる可能性のあるポイントは、SDKのToolkitインストール後に環境変数を反映させるためにログアウト(あるいはターミナル等の立ち上げ直し)が必要なことです。これをせずにAPIをセットアップしようとすると失敗します。

SDK (ToolkitとAPI)のセットアップが完了したら、PCにMovidius NCSをUSBポートに差し込んでみましょう。認識されたかどうか確認してみます。

$ sudo dmesg | grep MA2
[...] usb 3-2: Product: Movidius MA2X5X

こんな感じの文字列が出力されれば認識されてるのでOK、と言いたいところなのですが、udevを使ってデバイスファイルのパーミッションを設定したりしているようなので、Ubuntuを一度再起動した方が確実かも知れません。

認識されない場合、VMWareのリムーバブルデバイスの設定でMovidius NCSが仮想マシンに接続されているか確認して下さい。接続されていない場合は接続して上記の手順で再度確認してみて下さい。

Movidius NCSが認識されていることを確認できたら、動作確認してみましょう。Getting Startedにもあるように、

$ cd ~/workspace/mvncsdk/bin
$ make example00
$ make example01
$ make example02
$ make example03

のexample00から03までを動かしてみて下さい。うまくいけばMovidiusを動作させることができます。私のVMWare環境では動作したりしなかったりで、記事執筆時点では安定して動作させることができていません。

追記: ネイティブなDebian testing (buster) amd64はサポート外ですが安定して動作することを確認しました。VMWareやVirtualBox上で動作させるのは必要以上に労力が必要となりますので、ネイティブ環境を用意されることをお奨めします。

ASUS Tinker Boardをセットアップする

Raspberry Pi 3より高性能であることがウリのシングルボードコンピュータ、ASUS Tinker Boardが販売されています。発売直後は入荷数が少なくて入手が難しい状況でしたが、米Amazon.comからも技適マーク有りの購入できることもあり、今は国内代理店にも常時在庫があるような状況です。

具体的なスペックはTinker Boardのサイトにお任せするとして、個人的にはGbEに対応していることが嬉しいです。

セットアップ方法ですが、基本的にはサイトにあるGetting Startedの通りに作業すればOKですが、Linux上でセットアップする際に実行するよう指定されているFlashUSB.shというスクリプトがどこにあるのか分かりませんので、いつものようにコマンドラインから

$ sudo dd if=output.img of=/dev/sdb seek=0 bs=16M conv=notrunc

(microSDが/dev/sdbの場合) のように直接実行すればOKです。私は慣れているDebianベースのTinkerOSをインストールしました。中身はほとんどDebianそのものです。デフォルトではXの解像度が低めに設定されているようです。

インストール後はlinaro/linaroでログインして、

$ sudo apt update
$ sudo apt upgrade

で環境を最新にします。必要に応じてlvやtmux等をインストールして下さい。ifconfigでIPアドレスを確認すれば、以降はSSHでリモートログインして作業できるようになります。時刻がズレている時は

$ sudo dpkg-reconfigure tzdata

でAsia/Tokyoを選択しましょう。その他、必要に応じてLANGやEDITOR, PAGER等の環境変数を設定しておきましょう。

Jetson TX2が来た

Jetson TX2 in Box
Jetson TX2 in Box

米国での発売と同時に手配したJetson TX2 Developer Kitが届きました。が、技適未取得のようで、開封はしたものの電源はまだ入れていません。動きがありましたら追ってお伝えします。

まだ詳しくは見ていませんが、開発ボードはTX1と共通で、モジュールのみがTX1からTX2に差し替えられただけのように見えます。ケーブルや電源等の付属品もTX1とまったく同じっぽいです。

JetPack 3.0導入済みのようですので、TX1のように更新作業は必要ありません。eMMCの容量が16GBから32GBに倍増したようですが、容量やら寿命やらでやきもきするのは嫌なので、SSDからの起動も検討しています。

Jetson TX1 (JetPack 3.0)にTensorFlow 1.0をインストールする

JetPack 3.0にTensorFlow 1.0をインストールしようとしましたが、ビルドに失敗してしまいました。調査する時間も惜しいので、今回も有志が公開しているバイナリをインストールしちゃいましょう。

githubのissueからGoogle Drive上のwhlファイルへリンクが張られています。これをDLして pip3 install すれば完了です。必要に応じてvirtualenvも使いましょう。

ただし、Python2用のバイナリは提供されていないようですのでご注意を。

Jetson TX1をJetPack 3.0に更新する

Jetson TX2の発売と合わせてJetPack 3.0が公開されました。公開から数日が経ってしまいましたが、この最新版に更新したいと思います。

今回は諸事情によりMacBook Pro上のVirtualBoxではなく、Windows PC上のVMWareに入れていたUbuntu 14.04 LTSから作業します。

以前にJetPack 2.xで試した際には失敗しましたが、今回は事前にTX1をリカバリモードにしてVMWareのUbuntuからTX1を認識できることを確認した上で作業を行いました。

手順はマニュアル通りです。インストーラをDLし、chmod +x して実行し、画面の指示に従って操作するだけです。この辺りは以前の記事と同じ内容なので再掲はしません。今回はVMWareからでもリカバリモードでのイメージファイル転送が成功し、無事にJetPack 3.0に更新することができました。

あとはeMMCからではなくSSDから起動するよう設定しましょう。先の記事と同じ手順で問題なくSSDから起動させることが可能です。

Raspberry Pi Zero Wirelessを入手する

Raspberry Pi Zero Wireless
Raspberry Pi Zero Wireless

国内でようやくRaspberry Pi Zeroが入手できるようになった途端、WiFiとBluetoothに対応したRaspberry Pi Zero Wireless (以下、PiZeroW)が発表され、海外では既に発売されています。

在庫が戻ってもすぐに売れてしまうため、個人輸入での入手はなかなか難しい状況ですが、国内でも今月中には販売になる予定のようですので、我慢強く待ちましょう。

それでも待ち切れないという方は、個人輸入するしかありません。ModMyPi, Pimoroni, Adafruitは日本へも発送してくれますが、The Pi Hutはなぜか日本は発送対象外です。いずれのサイトもユーザ登録してカートに商品を入れてクレジットカード(あるいはPayPal)で支払えば簡単に購入できます。

貨物の混雑状況にもよりますが、発送されてからおよそ1〜2週間で届きます。関税や通関手数料は掛かりません。今回私は発売初日の02/28にModMyPiに注文し、03/07に届きました。

Raspberry Pi Zero Wireless [back]
Raspberry Pi Zero Wireless [back]
なお、PiZeroWの背面に技適マークはありますが、総務省の技適機器検索にヒットしません。電波暗室等の外で電源を入れるのは触法の可能性がありますのでご注意下さい。

CIサーバのセキュリティを向上する

前回の記事ではnginxによるSSLプロキシを有効にして通信路を暗号化しました。が、今のままでは平文のHTTPでもアクセスできる状態になっていますので、これを閉じます。

例によってdocker-copose.ymlです。

version: '2'

services:
  # リポジトリ
  gitbucket:
    image: takezoe/gitbucket
    container_name: gitbucket
    volumes:
      - ./gitbucket/data:/gitbucket
    environment:
      - TZ=JST-9
    ports:
      - 8080
      - 29418:29418

  # CIサーバ
  jenkins:
    image: jenkins:alpine
    container_name: jenkins
    volumes:
      - ./jenkins/home:/var/jenkins_home
      - ./jenkins/executors.groovy:/usr/share/jenkins/ref/init.groovy.d/executors.groovy
    environment:
      - JAVA_OPTS=-Duser.timezone=Asia/Tokyo
    ports:
      - 8080
      - 50000:50000

  # Rocket.Chatデータ
  db:
    image: mongo:3.0
    container_name: db
    volumes:
      - ./db/data:/data/db
    command: --smallfiles

  # Rocket.Chat本体
  rocket.chat:
    image: rocket.chat:latest
    container_name: rocket.chat
    environment:
      - ROOT_URL=http://localhost:8082
    links:
      - db
    ports:
      - 3000

  # リバースプロキシ
  nginx:
    image: nginx:alpine
    container_name: nginx
    volumes:
      - /etc/letsencrypt:/etc/letsencrypt:ro
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf
      - ./nginx/conf.d:/etc/nginx/conf.d
    depends_on:
      - gitbucket
      - jenkins
      - rocket.chat
    ports:
      # HTTPS
      - 8280:8280
      - 8281:8281
      - 8282:8282

フォントを赤くした3箇所のexposeを解除して、コンテナ間でのみ通信するように変更しました。Jenkinsの50000番ポートについてはJNLPによる接続なので、使わないようであればこれもexposeする必要はないと思います。

GitBucketの29418番ポートは外部とのSSH通信のためのポートですので、このままにしておきます。

nginxでリバースプロキシを立てる

さて、先の記事Let’s Encryptから取得したSSL証明書ですが、使わないと意味がありません。今回はnginxをHTTPSリバースプロキシとしてセットアップしてみます。

まず今回は既存のポートは生かしたまま、8280番ポートにGitBucket, 8281番ポートにJenkins, 8282番ポートにRocket.Chatを、それぞれ割り当てたいと思います。

例によってdocker-compose.ymlです。

version: '2'

services:
  # リポジトリ
  gitbucket:
    image: takezoe/gitbucket
    container_name: gitbucket
    volumes:
      - ./gitbucket/data:/gitbucket
    environment:
      - TZ=JST-9
    ports:
      - 8080:8080
      - 29418:29418

  # CIサーバ
  jenkins:
    image: jenkins:alpine
    container_name: jenkins
    volumes:
      - ./jenkins/home:/var/jenkins_home
      - ./jenkins/executors.groovy:/usr/share/jenkins/ref/init.groovy.d/executors.groovy
    environment:
      - JAVA_OPTS=-Duser.timezone=Asia/Tokyo
    ports:
      - 8081:8080
      - 50000:50000

  # Rocket.Chatデータ
  db:
    image: mongo:3.0
    container_name: db
    volumes:
      - ./db/data:/data/db
    command: --smallfiles

  # Rocket.Chat本体
  rocket.chat:
    image: rocket.chat:latest
    container_name: rocket.chat
    environment:
      - ROOT_URL=http://localhost:8082
    links:
      - db
    ports:
      - 8082:3000

  # リバースプロキシ
  nginx:
    image: nginx:alpine
    container_name: nginx
    volumes:
      - /etc/letsencrypt:/etc/letsencrypt:ro
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf
      - ./nginx/conf.d:/etc/nginx/conf.d
    depends_on:
      - gitbucket
      - jenkins
      - rocket.chat
    ports:
      # HTTPS
      - 8280:8280
      - 8281:8281
      - 8282:8282

既存の設定には手を入れず、末尾のnginxの設定のみを追加してあります。/etc/letsencryptに前回取得したSSL証明書がありますので、これをそのままボリュームとしてマウントします。その他、設定ファイルをいくつか上書きします。

まずはnginxの設定 nginx.conf です。通常、worker_processにはサーバのCPU数を指定します。

# nginx.conf
user  nginx;
worker_processes  2;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;
    keepalive_timeout  65;
    #gzip  on;
    include /etc/nginx/conf.d/*.conf;
}

次の各サービスに対するプロキシの設定を、conf.dディレクトリ以下に gitbucket.conf, jenkins.conf, rocketchat.conf として作成します。内容はほぼ同一で、listenするポート番号とproxy_passぐらいしか違いがないので、ここではgitbucket.confのみを例として挙げておきます。

# gitbucket.conf
server {
    # HTTPS
    listen 8280 ssl;
    listen [::]:8280 ssl;
    server_name ドメイン;

    ssl on;
    ssl_certificate /etc/letsencrypt/live/ドメイン/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ドメイン/privkey.pem;

    ssl_session_timeout 5m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDH !aNULL !eNULL !SSLv2 !SSLv3';
    ssl_prefer_server_ciphers on;
    add_header Strict-Transport-Security "max-age=15768000; includeSubdomains";

    location / {
        proxy_pass http://gitbucket:8080;
        proxy_redirect off;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $http_host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

proxy_passの値として、jenkins.confでは http://jenkins:8080, rocketchat.confでは http://rocket.chat:3000 をそれぞれ指定します。

また、共通的な部分は reverse_proxy.conf としてくくり出しておきます。

# reverse_proxy.conf
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

ここまで設定が済んだらdocker-compose upでコンテナを起動します。

それではまずGitBucketから見て行きましょう。ブラウザで https://ドメイン:8280/にアクセスし、ログイン前の画面が表示されればOKです。いつも通りログインし、右上のプルダウンから “System administration” を開き、”System settings” のBase URLを https://ドメイン名:8280 に変更して “Apply Changes” で保存します。

次にJenkinsです。ブラウザでhttps://ドメイン:8281/にアクセスします。こちらも同様にログイン画面が開きますのでログインします。「Jenkinsの管理」から「システムの設定」を開き、Jenkins URLを https://ドメイン:8281/ に、末尾のBuild Server URLも https://ドメイン:8281/ にそれぞれ変更して保存します。

続いてジョブの一覧から作成済みのジョブを選択し、「設定」を開いてGitBucketのURL欄を https://ドメイン:8280/〜 に変更します。

最後にRocket.Chatです。https://ドメイン:8282/にアクセスしてログインします。そうするとWarningダイアログが表示されてURLを変更するか確認してきますので「はい」を選択します。

これで、HTTPSで各サービスにアクセスできるようになりました。

2017/02/24追記: 変更を保存し忘れたりすると、サイトにアクセスできなくなります。というかなりました。私の場合、./gitbucket/data/gitbucket.confの base_url の値を直接編集して事無きを得ました。危ない危ない。