AWS Greengrass を Raspberry Pi で動かしてみる

 AWS re:Invent 2017 では今年も多数の新サービスが発表されましたね。その中には IoT や AI 関連のものも多く、 エッジデバイス上で Machine Learning の推論が実行できる AWS Greengrass ML Inference などはとても興味深いです。が、そもそも Greengrass に今まで触ったことがなかったので、今更ではありますが Raspberry Pi で Greengrass を動かしてみました。基本的に下記の公式ドキュメントのチュートリアルの実行です。

docs.aws.amazon.com

Raspberry Pi での環境設定

 Raspberry Pi の基本的な環境構築は終わっているものとして、 Greengrass を動かすための設定を行います。まずは Greengrass Core 用の Linux ユーザとグループを作成し、 sqlite3 をインストールします。

pi@raspberrypi:~ $ sudo adduser --system ggc_user
Adding system user `ggc_user' (UID 117) ...
Adding new user `ggc_user' (UID 117) with group `nogroup' ...
Creating home directory `/home/ggc_user' ...
pi@raspberrypi:~ $ 
pi@raspberrypi:~ $ sudo addgroup --system ggc_group
Adding group `ggc_group' (GID 122) ...
Done.
pi@raspberrypi:~ $ 
pi@raspberrypi:~ $ sudo apt-get install sqlite3
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Suggested packages:
  sqlite3-doc
The following NEW packages will be installed:
  sqlite3
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 99.6 kB of archives.
After this operation, 139 kB of additional disk space will be used.
Get:1 http://mirrordirector.raspbian.org/raspbian/ jessie/main sqlite3 armhf 3.8.7.1-1+deb8u2 [99.6 kB]
Fetched 99.6 kB in 1s (91.6 kB/s)
Selecting previously unselected package sqlite3.
(Reading database ... 104790 files and directories currently installed.)
Preparing to unpack .../sqlite3_3.8.7.1-1+deb8u2_armhf.deb ...
Unpacking sqlite3 (3.8.7.1-1+deb8u2) ...
Processing triggers for man-db (2.7.5-1~bpo8+1) ...
Setting up sqlite3 (3.8.7.1-1+deb8u2) ...
pi@raspberrypi:~ $ 

 Greengrass Core では起動時にOSでハードリンク/ソフトリンクの保護が有効か確認しているため、この保護を有効にしておきます。 /etc/sysctl.d/98-rpi.conf に設定を追加します。追加前後の差分は下記の通りです。

pi@raspberrypi:~ $ diff /etc/sysctl.d/98-rpi.conf.20171220 /etc/sysctl.d/98-rpi.conf
2a3,4
> fs.protected_hardlinks = 1
> fs.protected_symlinks = 1
pi@raspberrypi:~ $ 

 設定を追加したら一度再起動します。

pi@raspberrypi:~ $ sudo reboot

 再起動したら下記のように確認するとハードリンク/ソフトリンクの保護が有効になっていることがわかります。

pi@raspberrypi:~ $ sudo sysctl -a | grep 'fs.protected'
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
sysctl: reading key "net.ipv6.conf.all.stable_secret"
sysctl: reading key "net.ipv6.conf.default.stable_secret"
sysctl: reading key "net.ipv6.conf.eth0.stable_secret"
sysctl: reading key "net.ipv6.conf.lo.stable_secret"
sysctl: reading key "net.ipv6.conf.wlan0.stable_secret"

Greengrass Group と Greengrass Core の作成

 Greengrass のデバイスには Core デバイスと、 Core デバイスに接続するそれ以外のデバイスがあり、Core デバイスが AWS IoT や Greengrass のクラウドサービスと通信します。また、それらのデバイスと設定情報をひとまとまりにしたものが Greengrass Group になります。まずはコンソールから Greengrass Group を作成しますが、その前にコンソールから Greengrass を操作するための権限を追加しておきます。今回はお試しということでとりあえず Greengrass へのフルアクセス権限を追加してしまいます。

f:id:akanuma-hiroaki:20171221081929p:plain

 それでは Greengrass Group を作成します。AWS IoT のコンソールのメニューから Greengrass を選択します。

f:id:akanuma-hiroaki:20171221082356p:plain

 ようこそ画面が表示されるので、「Greengrass グループの定義」の 今すぐ始める をクリックします。

f:id:akanuma-hiroaki:20171221082445p:plain

 グループの作成方法の選択画面が表示されますので、 簡単な作成の使用 を選択します。この方法だと Core デバイスがクラウドサービスにアクセスするために必要な証明書やキーペアの作成なども自動で行ってくれます。

f:id:akanuma-hiroaki:20171221082740p:plain

 グループ名の入力画面で任意のグループ名を設定します。

f:id:akanuma-hiroaki:20171221083155p:plain

 続けて Core デバイスの名前も決めます。デフォルトだとグループ名に _Core がついたものになっているので今回はそのまま使用します。

f:id:akanuma-hiroaki:20171221083252p:plain

 実行する内容が表示されるので、 グループとコアの作成 をクリックします。

f:id:akanuma-hiroaki:20171221083411p:plain

 Group と Core が作成され、証明書のダウンロード画面が表示されますので、ダウンロードしておきます。

f:id:akanuma-hiroaki:20171221083632p:plain

 また、同じ画面で Greengrass ソフトウェアパッケージもダウンロードできますので、CPUアーキテクチャとして ARMv7l を選択し、ダウンロードして、 完了 をクリックします。

f:id:akanuma-hiroaki:20171221083804p:plain

 これで Greengrass Group と Greengrass Core の作成は完了です。

Greengrass Core のインストール

 Raspberry Pi に先ほどダウンロードした Greengrass ソフトウェアパッケージをインストールします。ソフトウェアパッケージを Raspberry Pi 上に配置したら展開します。

pi@raspberrypi:~ $ sudo tar zxf greengrass-linux-armv7l-1.3.0.tar.gz -C /
pi@raspberrypi:~ $ 
pi@raspberrypi:~ $ ls -l /greengrass/
total 16
drwxr-xr-x 2 nobody 99 4096 Nov 21 08:09 certs
drwxr-xr-x 2 nobody 99 4096 Nov 21 08:09 config
drwxr-xr-x 5 nobody 99 4096 Nov 21 08:09 ggc
drwxr-xr-x 3 nobody 99 4096 Nov 21 08:09 ota

 Lambda の cgroup を自動的に設定するために、 /etc/fstab に下記設定を追加します。

cgroup /sys/fs/cgroup cgroup defaults 0 0

 追加後の fstab は下記のようになります。設定を追加したら一度再起動しておきます。

pi@raspberrypi:~ $ tail /etc/fstab 
proc            /proc           proc    defaults          0       0
/dev/mmcblk0p1  /boot           vfat    defaults          0       2
/dev/mmcblk0p2  /               ext4    defaults,noatime  0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that
cgroup /sys/fs/cgroup cgroup defaults 0 0

 続いて証明書を配置します。先ほど展開したディレクトリ内の certs ディレクトリに、Versign からルートCA証明書をダウンロードして配置します。

pi@raspberrypi:/greengrass/certs $ pwd
/greengrass/certs
pi@raspberrypi:/greengrass/certs $ 
pi@raspberrypi:/greengrass/certs $ sudo wget http://www.symantec.com/content/en/us/enterprise/verisign/roots/VeriSign-Class%203-Public-Primary-Certification-Authority-G5.pem -O root-ca-cert.pem                                             
--2017-12-20 15:30:39--  http://www.symantec.com/content/en/us/enterprise/verisign/roots/VeriSign-Class%203-Public-Primary-Certification-Authority-G5.pem
Resolving www.symantec.com (www.symantec.com)... 72.247.61.29
Connecting to www.symantec.com (www.symantec.com)|72.247.61.29|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1758 (1.7K) [text/plain]
Saving to: ‘root-ca-cert.pem’

root-ca-cert.pem                                            100%[===========================================================================================================================================>]   1.72K  --.-KB/s   in 0s     

2017-12-20 15:30:39 (37.7 MB/s) - ‘root-ca-cert.pem’ saved [1758/1758]

 続けて、 Group と Core 作成時にダウンロードした証明書の圧縮ファイルに含まれる証明書とプライベートキーを同じディレクトリに配置します。

pi@raspberrypi:~ $ tar zxf dbb10e0817-setup.tar.gz 
pi@raspberrypi:~ $ ls certs/
dbb10e0817.cert.pem  dbb10e0817.private.key  dbb10e0817.public.key
pi@raspberrypi:~ $ 
pi@raspberrypi:~ $ sudo cp certs/dbb10e0817.private.key /greengrass/certs/.                                                                                                                                                                   
pi@raspberrypi:~ $ sudo cp certs/dbb10e0817.cert.pem /greengrass/certs/.

 次に、コンソールから Greengrass 用のサービスロールを作成します。 IAM のコンソールから ロールの作成 をクリックします。

f:id:akanuma-hiroaki:20171221085246p:plain

 サービスのリストから Greengrass を選択して 次のステップ をクリックします。

f:id:akanuma-hiroaki:20171221085325p:plain

 ポリシーの選択画面で AWSGreengrassResourceAccessRolePolicy を選択して 次のステップ をクリックします。

f:id:akanuma-hiroaki:20171221085446p:plain

 任意のロール名を入力して ロールの作成 をクリックします。

f:id:akanuma-hiroaki:20171221085631p:plain

 ロールが作成されたら ARN を記録しておきます。

f:id:akanuma-hiroaki:20171221085839p:plain

 続いて今作成したサービスロールをアカウントに紐づけます。 Mac 上から AWS CLI で下記のようにコマンドを実行します。

Greengrass  $ aws greengrass associate-service-role-to-account --role-arn arn:aws:iam::365361468908:role/Greengrass
2017-12-20T15:53:26Z

 最後に Raspberry Pi 上の Greengrass 設定ファイルを下記のように編集します。各証明書などへのパスはフルパスではなくファイル名だけでOKです。

pi@raspberrypi:/greengrass/ggc/packages/1.3.0 $ cat /greengrass/config/config.json 
{
    "coreThing": {
        "caPath": "root-ca-cert.pem",
        "certPath": "dbb10e0817.cert.pem",
        "keyPath": "dbb10e0817.private.key",
        "thingArn": "arn:aws:iot:ap-northeast-1:365361468908:thing/MyGroup_Core",
        "iotHost": "xxxxxxxxxxxxxx.iot.ap-northeast-1.amazonaws.com",
        "ggHost": "greengrass.iot.ap-northeast-1.amazonaws.com"
    },
    "runtime": {
        "cgroup": {
            "useSystemd": "yes"
        }
    },
    "managedRespawn": false
}

Greengrass Core の起動

 それでは Raspberry Pi 上の Greengrass Core を起動します。 Greengrass のソフトウェアパッケージのディレクトリ(今回は /greengrass/ggc/packages/1.3.0 )で下記のようにコマンドを実行します。

pi@raspberrypi:/greengrass/ggc/packages/1.3.0 $ sudo ./greengrassd start
Setting up greengrass daemon
Validating hardlink/softlink protection
Validating execution environment
Found cgroup subsystem: cpu
Found cgroup subsystem: cpuacct
Found cgroup subsystem: blkio
Found cgroup subsystem: memory
Found cgroup subsystem: devices
Found cgroup subsystem: freezer
Found cgroup subsystem: net_cls

Starting greengrass daemon
Greengrass successfully started with PID: 1917

 成功するとデーモンが起動します。

pi@raspberrypi:/greengrass/ggc/packages/1.3.0 $ ps aux | grep greengrass | grep -v grep
root      1304  0.7  1.4 940632 13900 pts/0    Sl   Dec20   0:38 /greengrass/ggc/packages/1.3.0/bin/daemon -core-dir=/greengrass/ggc/packages/1.3.0 -port=8000 -connectionManager=true -router=true -shadow=true -shadowSync=true -tes=true -deviceCertificateManager=true
ggc_user  1472  0.8  1.1  31308 10796 ?        Ssl  Dec20   0:45 python2.7 /runtime/python2.7/lambda_runtime.py --handler=greengrassHelloWorld.function_handler

Lambda Function の作成

 Greengrass Core デバイスで動作させるための Lambda Function を作成します。 Lambda のコンソールから 関数の作成 をクリックします。

f:id:akanuma-hiroaki:20171221090835p:plain

 今回はあらかじめ用意されているサンプルを使用しますので、「設計図」から「greengrass-hello-world」を選択して 設定 をクリックします。

f:id:akanuma-hiroaki:20171221090927p:plain

 任意の Function 名とロールを選択します。今回は以前作成していたロールを使用していますが、作成していなかった場合は新たに作成します。

f:id:akanuma-hiroaki:20171221091049p:plain

 Core デバイスで Lambda Function を実行するには新しいバージョンを発行しておく必要があるので、「アクション」メニューから 新しいバージョンを発行 をクリックします。

f:id:akanuma-hiroaki:20171221091156p:plain

 バージョンの説明を入力して 発行 をクリックします。

f:id:akanuma-hiroaki:20171221091339p:plain

Greengrass Group に Lambda Function を追加

 作成した Lambda Function を Greengrass Group に追加します。 Greengrass Group のコンソールの Lambda メニューから、 最初の Lambda を追加する をクリックします。

f:id:akanuma-hiroaki:20171221091712p:plain

 Lambda の追加方法の選択画面が表示されますので、 既存の Lambda の使用 を選択します。

f:id:akanuma-hiroaki:20171221092014p:plain

 Lambda Function の選択画面が表示されますので、先ほど作成した Lambda Function を選択して 次へ をクリックします。

f:id:akanuma-hiroaki:20171221092126p:plain

 先ほど発行したバージョンを選択して 完了 をクリックします。

f:id:akanuma-hiroaki:20171221092229p:plain

 Lambda Function が追加されたら、設定を変更するために 設定の編集 をクリックします。

f:id:akanuma-hiroaki:20171221092414p:plain

 設定項目の中の「Lambda のライフサイクル」の項目で「存続期間が長く無制限に稼働する関数にする」を選択して 更新 をクリックします。

f:id:akanuma-hiroaki:20171221092505p:plain

Greengrass Group にサブスクリプションを追加

 Greengrass Core が MQTT プロトコルでメッセージをやりとりするためのサブスクリプションを追加します。サブスクリプションは、メッセージの送信元であるソース、メッセージの送信先であるターゲット、それとトピックから構成されます。 Greengrass のサブスクリプションメニューから、 最初のサブスクリプションを追加 をクリックします。

f:id:akanuma-hiroaki:20171221232433p:plain

 ソースの選択で先ほど作成した Lambda Function を選択し、ターゲットの選択では IoT Cloud を選択して 次へ をクリックします。

f:id:akanuma-hiroaki:20171221232652p:plain

 今回は対象のトピックを hello/world に限定するため、「オプションのトピックフィルター」に hello/world を入力して 次へ をクリックします。

f:id:akanuma-hiroaki:20171221232849p:plain

 最後に 完了 をクリックしてサブスクリプションの追加は完了です。

f:id:akanuma-hiroaki:20171221233139p:plain

Greengrass Group のデプロイ

 ここまででクラウド上での Greengrass Group の設定は完了したので、これを Greengrass Core デバイスにコピーします。 Greengrass Group のデプロイのコンソールのアクションから デプロイ を選択します。

f:id:akanuma-hiroaki:20171221233546p:plain

 検出方法の設定画面になりますので、 自動検出 を選択します。

f:id:akanuma-hiroaki:20171221233654p:plain

 これまでの設定が正しく行われ、 Core デバイス上でデーモンが正しく稼働していれば、少し経つとデプロイが完了します。

f:id:akanuma-hiroaki:20171221233809p:plain

動作確認

 それでは Greengrass Core デバイス上で Lambda Function が正しく実行されているか確認します。AWS IoT コンソールから「テスト」を選択し、 hello/world トピックにサブスクライブします。

f:id:akanuma-hiroaki:20171221234017p:plain

 Lambda Function が正しく実行されていれば、下記のようにトピックにメッセージが発行されていきます。

f:id:akanuma-hiroaki:20171221234034p:plain

まとめ

 今回はチュートリアルの内容をそのまま追っただけになってしまいましたが、 Greengrass Core デバイス(今回は Raspberry Pi)上で Lambda Function を動かせることが確認できました。今回はここまでで長くなってしまいましたが、まだ Core デバイスに接続している他のデバイスとの連携は試せていないので、次回以降で試してみたいと思います。

Arm Mbed Cloud によるデバイス管理&リモートアップデート

 12/8(金)に Arm Mbed Connect 2017 のワークショップに参加してきました。

armkk-event.com

 このワークショップでは Mbed 対応の開発ボードで実際にコーディングしたり、 Mbed Cloud でのデバイス管理などを体験できるハンズオン型のワークショップで、下記のような内容でした。

  1. Mbed ビルドツールのインストール
  2. Mbed OS - 自分のアプリケーションをビルドする
  3. Mbed Cloud Client - Mbed Cloud アプリケーションをビルドする
  4. Mbed Cloud Client - 新しい LWM2M オブジェクトを追加する
  5. Mbed Cloud Client - 書き込み可能な LWM2M オブジェクトを追加する
  6. Mbed Cloud Client - Wi-Fi アップデート
  7. Cloud SDK – 値を取得するシンプルなwebアプリ
  8. デバッガの使用

 Mbed OS アプリのビルドは Mbed CLI を使ったものでしたが、それについては以前も書いていますので、今回は Mbed Cloud でのデバイス管理の部分について、どのような感じで管理・アップデートが行えるのかを紹介してみたいと思います。

使用デバイス

 今回使用したデバイスはワークショップ用に用意された開発ボードで、ワークショップ後はそのままいただくことができました。無料ワークショップなのになんとも太っ腹です。

f:id:akanuma-hiroaki:20171212081717j:plain:w450 f:id:akanuma-hiroaki:20171212081735j:plain:w450

 機能としては下記のようなものが載っています。

  • Wi-Fi

  • センサー(温度、湿度、照度、加速度、大気クオリティ、距離)

  • RGB LED とステータス表示用の LED

  • LCD ディスプレイ

  • スイッチ

 ワークショップ中に使ったセンサーは温度センサーだけでしたが、それ以外にも色々なセンサーが載っているので遊べそうです。OS は Mbed OS 5 です。

Mbed Cloud とは

 Mbed Cloud は IoT デバイスを管理するためのクラウドプラットフォームで、Mbed OS 5 と連携することで個別の IoT デバイスを管理することができます。

cloud.mbed.com

 現在 Mbed Cloud はパートナーしか利用することができませんが、今回のワークショップでは参加者に期間限定のアカウントが提供され、それを使ってアクセスしました。

f:id:akanuma-hiroaki:20171212084353p:plain:w450

 ログインするとダッシュボードが表示されます。

f:id:akanuma-hiroaki:20171212085241p:plain:w450

Mbed Cloud へのデバイス登録

 Mbed Cloud にデバイスを接続するには Mbed Cloud で生成した証明書を使用する必要があります。Mbed Cloud の Device identity メニューの Actions から Create a developer certificate を選択し、ダイアログに従って情報を登録して行くと証明書が作成されます。

f:id:akanuma-hiroaki:20171212090007p:plain:w450

 作成された証明書を一覧から選択してローカルにダウンロードし、アプリケーションのルートディレクトリに配置します。

 Mbed Cloud では LWM2M を使ってデバイスの管理が行われますので、デバイスの登録も LWM2M のクライアントを使います。今回のワークショップでは登録用のサンプルコードが提供されていたので、自分で書く必要はありませんでしたが、アプリ側の登録用コードの抜粋は下記のようになります。

client = new SimpleM2MClient(network, &sd, &fs);
int init_rt = client->init();
client->call_register();

 そして下記のようにビルドして、生成されたバイナリ combined.bin をボードにコピーして書き込みます。

$ mbed compile -t GCC_ARM -m UBLOX_EVK_ODIN_W2
〜〜〜中略〜〜〜
Combined binary: /Users/akanuma/Documents/mbed_connect_ws/mac-workshop-content/mbed-connect-cloud-application/BUILD/UBLOX_EVK_ODIN_W2/GCC_ARM/combined.bin
〜〜〜中略〜〜〜
Image: ./BUILD/UBLOX_EVK_ODIN_W2/GCC_ARM/mbed-connect-cloud-application.bin

 正しく登録されると、 Mbed Cloud の Device directory に対象のデバイスが表示されます。

f:id:akanuma-hiroaki:20171214233425p:plain:w450

デバイス情報の確認

 登録されたデバイスの情報を確認するには、デバイスの一覧から対象のデバイスの Device ID をクリックします。表示された詳細画面から Live resources タブをクリックすると、 LWM2M の各リソースの情報が確認できます。表示されるリソースの項目や内容は各デバイスでの実装に依存します。

f:id:akanuma-hiroaki:20171214233141p:plain:w450

 また、更新が可能なリソースはこの画面から値を更新することも可能です。各リソースが更新可能かどうかはデバイス側での実装に依存します。

f:id:akanuma-hiroaki:20171214233654p:plain:w450

Wi-Fi アップデートの準備

 IoT デバイスでは Web アプリケーションやスマートフォンアプリケーションと違って、デバイス自体を遠隔地において来てしまうので簡単にファームウェアのアップデートのフラッシュを行うことができません。そこで IoT プラットフォームによる、デバイスのファームウェアのリモートアップデート機能が重要になってきます。 Mbed Cloud でもこの機能を持っており、 Wi-Fi に接続した上でソフトウェアをリモートでアップデートできます。

 Mbed Cloud のリモートアップデートでは manifest-tool を使いますが、そのために API キーが必要になりますので、Mbed Cloud のコンソールから API キーを生成します。 Access management メニューの API keys の画面から Create new API key をクリックして表示されるダイアログに従うと API キーが生成されて表示されます。API キーの内容は生成時しか見ることはできないため、ここでコピーして保存しておきます。

f:id:akanuma-hiroaki:20171214082141p:plain:w450

 次に manifest-tool がインストールされていない場合はインストールします。ワークショップ時はインストール用のファイルが配布されたので pip でローカルファイルを使ってインストールしましたが、通常はこちらのチュートリアルの手順に従ってインストールすることになるかと思います。

https://cloud.mbed.com/docs/v1.2/updating-firmware/tutorial-installing-the-manifest-tool.html

 ただ、このチュートリアルの手順だと manifest-tool のリポジトリが見つからないということでエラーになってしまうため、実際に使う場合は確認が必要です。

$ pip install -U "git+https://github.com/ARMmbed/manifest-tool-restricted.git"
Collecting git+https://github.com/ARMmbed/manifest-tool-restricted.git
  Cloning https://github.com/ARMmbed/manifest-tool-restricted.git to /private/var/folders/l1/5gdn8snd6gj_nfyh5j4nc1sw0000gn/T/pip-rx_uWM-build
remote: Repository not found.
fatal: repository 'https://github.com/ARMmbed/manifest-tool-restricted.git/' not found
Command "git clone -q https://github.com/ARMmbed/manifest-tool-restricted.git /private/var/folders/l1/5gdn8snd6gj_nfyh5j4nc1sw0000gn/T/pip-rx_uWM-build" failed with error code 128 in None

 ここではひとまず manifest-tool がインストールできたことにして、次にアプリケーションのルートディレクトリで manifest-tool を設定します。コマンドのシグネチャは $ manifest-tool init -d "<company domain name>" -m "<product model ID>" -a "<api key>" -q --force という感じなので例えば、

$ manifest-tool init -d "example.com" -m "update_test" -a "ak_1MDE2MDBmYWM0YjBjXXXXXXXXXXXXXXXXXXXX" -q --force

 という感じになります。これで公開鍵/秘密鍵のペアが作成されて公開鍵はデバイスに組み込まれるようになりますので、秘密鍵はプログラムの更新時に署名するために保持しておきます。 manifest-tool init による設定が終わったら再度ビルドして combined.bin をボードに書き込んでおきます。

Wi-Fi アップデートの実施

 ここまででリモートアップデートの準備ができましたので、実際にリモートアップデートを実施してみます。まずアプリケーションのソースに何らかの変更を加えたらこれまで同様にビルドしておきます。ただ今回使用するバイナリは combined.bin ではなく、ブートローダを含まない bin になりますので、今回の例であれば mbed-connect-cloud-application.bin になります。

$ mbed compile -t GCC_ARM -m UBLOX_EVK_ODIN_W2
〜〜〜中略〜〜〜
Image: ./BUILD/UBLOX_EVK_ODIN_W2/GCC_ARM/mbed-connect-cloud-application.bin

 ビルドしたら manifest-tool prepare コマンドを実行して、マニフェストファイルの生成と、バイナリとマニフェストファイルのアップロードを行います。

$ manifest-tool update prepare -p ./BUILD/UBLOX_EVK_ODIN_W2/GCC_ARM/mbed-connect-cloud-application.bin -o myUpdate

 これで Mbed Cloud にマニエストファイルとアップデート用のバイナリファイルがアップロードされましたので、 Mbed Cloud のコンソールからキャンペーンの設定を行いますが、アップデートの配布対象デバイスを指定するためにはデバイスフィルタを作成しておく必要がありますので、下記メニューから作成しておきます。(詳細は割愛)

f:id:akanuma-hiroaki:20171214085533p:plain:w450

 デバイスフィルタを作成したら Firmware update のメニューからキャンペーンを作成します。

f:id:akanuma-hiroaki:20171214085920p:plain:w450

 次に表示されるフォームで、先ほど manifest-tool update でアップロードされたマニフェストと、配布対象デバイスの条件として事前に作成したデバイスフィルタを選択し、任意のキャンペーン名を入力して Save します。

f:id:akanuma-hiroaki:20171214234407p:plain:w450

 するとキャンペーンが作成され、内容が表示されます。

f:id:akanuma-hiroaki:20171214234634p:plain:w450

 この状態ではまだキャンペーンは開始されていませんので、 Start をクリックするとキャンペーンが開始し、アップデートがスタートします。

f:id:akanuma-hiroaki:20171214235922p:plain:w450

 これでデバイス側が正しくネットワークに接続して稼働していれば、アップデートが行われます。例えばワークショップ時のサンプルコードではシリアル出力で様子を確認していると下記のようにアップデートが行われたことがわかりました。

Firmware download requested
Authorization granted
Downloading firmware...
Downloading: [-                                                 ] 0 %Temperature: 23.74C!!!!
Downloading: [+/                                                ] 2 %Temperature: 23.74C!!!!
Downloading: [++-                                               ] 4 %Temperature: 23.77C!!!!
Downloading: [+++-                                              ] 6 %Temperature: 23.77C!!!!
〜〜〜中略〜〜〜
Downloading: [++++++++++++++++++++++++++++++++++++++++++++++-   ] 92 %Temperature: 23.77C!!!!
Downloading: [+++++++++++++++++++++++++++++++++++++++++++++++-  ] 95 %Temperature: 23.77C!!!!
Downloading: [++++++++++++++++++++++++++++++++++++++++++++++++\ ] 97 %Temperature: 23.78C!!!!
Downloading: [++++++++++++++++++++++++++++++++++++++++++++++++++] 100 %
Download completed
Firmware install requested
Authorization granted
Booting up...
             Bootloader starting, formatting? 0
                                               [BOOT] mbed Bootloader
[BOOT] ARM: 0000000000000000000000000000000000000000
[BOOT] OEM: 0000000000000000000000000000000000000000
[BOOT] Layout: 0 801A75C
[BOOT] Active firmware integrity check:
[BOOT] [++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++]
[BOOT] SHA256: 0950D54B7D7CB0957BB3AF342E390D5BEBDF3847E88E291B76F8XXXXXXXXXXXX
[BOOT] Version: 1513261526
[BOOT] Slot 0 firmware integrity check:
[BOOT] [++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++]
[BOOT] SHA256: 0C596036D5DD603389852A9D7BD18C4BE5743FDCCFC30BD465F3XXXXXXXXXXXX
[BOOT] Version: 1513262444
[BOOT] Slot 1 is empty
[BOOT] Update active firmware using slot 0:
[BOOT] [++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++]
[BOOT] Verify new active firmware:
[BOOT] [++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++]
[BOOT] New active firmware is valid
[BOOT] Application's start address: 0x8020400
[BOOT] Application's jump address: 0x805FB05
[BOOT] Application's stack address: 0x20030000
[BOOT] Forwarding to application...

 キャンペーンの進捗状況はキャンペーン一覧の Active タブから確認できます。

f:id:akanuma-hiroaki:20171214235658p:plain:w450

f:id:akanuma-hiroaki:20171214235533p:plain:w450

まとめ

 デバイスを LWM2M で管理するという点では SORACOM Inventory と同じようなイメージを持ちました。Firmware のアップデートについては LWM2M でもできそうな感じではありますが、プラットフォームでサポートしていて複数端末へのアップデートの配布や状況の確認等もコンソールからの設定で行えるのは便利そうに思いました。Mbed Cloud はまだ誰でも利用できるわけではありませんが、どんな感じでデバイス管理を行えるかのイメージが掴めたのは良かったです。

Alexa Skills Kit + AWS IoT + Raspberry Pi + 赤外線LED でテレビリモコンを作る

 Amazon Echo や Google Home では Fire TV や Chromecast 等と組み合わせることで音声でテレビを操作することができるようになりますが、今回は Amazon Echo と Raspberry Pi を連携させ、赤外線LEDなどと組み合わせることでテレビを操作してみたいと思います。

全体構成

 今回の全体の構成は下記の図のようになります。Alexa Skills Kit でカスタムスキルを実装して Amazon Echo から呼び出し、 Fulfillment として Lambda Function を実装してそこから AWS IoT の Shadow の更新リクエストを投げます。Raspberry Pi 上では AWS IoT に MQTT で Subscribe する処理を稼働させておき、Echo からのリクエストで Shadow が更新されたのを検知したら赤外線LEDから赤外線を送信してテレビを操作するという流れです。

f:id:akanuma-hiroaki:20171206084727p:plain

カスタムスキルの実装

 ではまずはカスタムスキルを実装してみます。 Alexa Skills Kit で下記の内容でスキルを作成します。

スキル名:テレビリモコン
呼び出し名:テレビリモコン

 今回はひとまずできるだけシンプルに一通り動くようにしてみたいと思いますので、テレビのON/OFFのみ操作するようにします。 Alexa へのリクエストとしては「テレビリモコンでテレビをつけて」「テレビリモコンでテレビを消して」の2種類のみを受け取ります。カスタムインテントを一つ作ってスロットで ON/OFF のリクエストを切り分けても良いのですが、少し複雑になってしまうので、今回はスロットは使わずにそれぞれのリクエストに対応するカスタムインテントを定義しておきます。

インテントスキーマ

{
  "intents": [
    { "intent": "TVPowerOnIntent" },
    { "intent": "TVPowerOffIntent" },
    { "intent": "AMAZON.HelpIntent" },
    { "intent": "AMAZON.StopIntent" },
    { "intent": "AMAZON.CancelIntent" }
  ]
}

 サンプル発話は前述の通り2つだけ定義しておきます。一通り動くようになったら他のバリエーションにも対応したいと思います。下記のように定義することで、「テレビリモコンでテレビをつけて」と言った時には TVPowerOnIntent が起動し、「テレビリモコンでテレビを消して」と言った時には TVPowerOffIntent が起動することになります。

サンプル発話

TVPowerOnIntent テレビをつけて
TVPowerOffIntent テレビを消して

 Fulfillment としての Lambda Function は下記のように実装します。

# -*- coding: utf-8 -*-
from __future__ import print_function
import boto3
import json

# --------------- Helpers that build all of the responses ----------------------

def build_speechlet_response(output, reprompt_text, should_end_session):
    return {
        'outputSpeech': {
            'type': 'PlainText',
            'text': output
        },
        'reprompt': {
            'outputSpeech': {
                'type': 'PlainText',
                'text': reprompt_text
            }
        },
        'shouldEndSession': should_end_session
    }

def build_response(speechlet_response):
    return {
        'version': '1.0',
        'sessionAttributes': {},
        'response': speechlet_response
    }

# --------------- Functions that control the skill's behavior ------------------

def get_welcome_response():
    speech_output = "テレビを操作するには、「テレビリモコンでテレビをつけて」、" \
                    "または、「テレビリモコンでテレビを消して」、と言ってください。"
    reprompt_text = None
    should_end_session = True
    return build_response(build_speechlet_response(
        speech_output, reprompt_text, should_end_session))

def handle_session_end_request():
    speech_output = None
    reprompt_text = None
    should_end_session = True
    return build_response(build_speechlet_response(
        speech_output, reprompt_text, should_end_session))

def publish(power):
    client = boto3.client('iot-data')
    response = client.update_thing_shadow(
        thingName='home_tv',
        payload=json.dumps({"state":{"desired": {"power": power}}})
    )

def turn_tv_power(power, session):
    should_end_session = True

    publish(power)
    
    speech_output = "テレビの電源を" + power + "にしました。"
    reprompt_text = None
    return build_response(build_speechlet_response(
        speech_output, reprompt_text, should_end_session))

# --------------- Events ------------------

def on_session_started(session_started_request, session):
    print("on_session_started requestId=" + session_started_request['requestId']
          + ", sessionId=" + session['sessionId'])

def on_launch(launch_request, session):
    print("on_launch requestId=" + launch_request['requestId'] +
          ", sessionId=" + session['sessionId'])
    # Dispatch to your skill's launch
    return get_welcome_response()

def on_intent(intent_request, session):
    print("on_intent requestId=" + intent_request['requestId'] +
          ", sessionId=" + session['sessionId'])

    intent = intent_request['intent']
    intent_name = intent_request['intent']['name']

    if intent_name == "TVPowerOnIntent":
        return turn_tv_power('on', session)
    elif intent_name == "TVPowerOffIntent":
        return turn_tv_power('off', session)
    elif intent_name == "AMAZON.HelpIntent":
        return get_welcome_response()
    elif intent_name == "AMAZON.CancelIntent" or intent_name == "AMAZON.StopIntent":
        return handle_session_end_request()
    else:
        raise ValueError("Invalid intent")

def on_session_ended(session_ended_request, session):
    print("on_session_ended requestId=" + session_ended_request['requestId'] +
          ", sessionId=" + session['sessionId'])

# --------------- Main handler ------------------

def lambda_handler(event, context):
    print("event.session.application.applicationId=" +
          event['session']['application']['applicationId'])

    if event['session']['new']:
        on_session_started({'requestId': event['request']['requestId']},
                           event['session'])

    if event['request']['type'] == "LaunchRequest":
        return on_launch(event['request'], event['session'])
    elif event['request']['type'] == "IntentRequest":
        return on_intent(event['request'], event['session'])
    elif event['request']['type'] == "SessionEndedRequest":
        return on_session_ended(event['request'], event['session'])

 処理の内容はインテントの種別で切り分けています。

    if intent_name == "TVPowerOnIntent":
        return turn_tv_power('on', session)
    elif intent_name == "TVPowerOffIntent":
        return turn_tv_power('off', session)
    elif intent_name == "AMAZON.HelpIntent":
        return get_welcome_response()
    elif intent_name == "AMAZON.CancelIntent" or intent_name == "AMAZON.StopIntent":
        return handle_session_end_request()
    else:
        raise ValueError("Invalid intent")

 turn_tv_power メソッドの中で publish メソッドを呼び出し、その中で AWS SDK を使って AWS IoT の Shadow の更新リクエストを投げています。今回は Shadow の内容としてはテレビの ON/OFF のステータスのみを持たせています。

def publish(power):
    client = boto3.client('iot-data')
    response = client.update_thing_shadow(
        thingName='home_tv',
        payload=json.dumps({"state":{"desired": {"power": power}}})
    )

 テストをして問題なければ Alexa Skills Kit のエンドポイントの設定で上記の Lambda Function の ARN を指定します。

 カスタムスキルの実装については前回も書いてますので、よろしければご覧ください。

blog.akanumahiroaki.com

Raspberry Pi と電子部品の配線

 今度はテレビを操作する側を実装していきます。まずは Raspberry Pi と赤外線LED等を下記の図のように配線します。

f:id:akanuma-hiroaki:20171206081102p:plain:w300:left

 今回使っているパーツは下記の3つです。

 ・赤外線受信モジュール
 ・赤外線LED
 ・NPN型トランジスタ

 これらを抵抗とジャンパーコードで接続します。

 赤外線受信モジュールはテレビのリモコンの赤外線を受信してパターンを記録するために使います。今回使用したモジュールのピンは左から Output, GND, VCC となっているので、 Output を GPIO17 に接続し、 GND と VCC をそれぞれ GND と 3V 出力に接続します。

 そして記録したパターンで赤外線を送信するために赤外線LEDを使うのですが、通常のGPIOで出力される電圧では小さいため、トランジスタを使用して Raspberry Pi の 5V の電源を増幅して使います。今回使用したトランジスタはNPN型で、ピンは左から Emitter, Collector, Base です。 赤外線LEDのアノードを 5V 出力に接続し、 4.7Ωの抵抗を介して Collector に接続します。Emitter は GND に接続します。 Base は 1kΩの抵抗を介して GPIO18 に接続します。

www.aitendo.com

www.aitendo.com

www.aitendo.com

LIRC で赤外線パターンを記録する

 今回はちょっと手抜きな感じもありますが、 赤外線の送信に LIRC を使って動かしてみます。

www.lirc.org

 まず下記コマンドで LIRC をインストールします。

$ sudo apt-get install lirc

 起動時に LIRC モジュールを起動するように、 /boot/config.txt に下記を追記します。

dtoverlay=lirc-rpi,gpio_in_pin=17,gpio_out_pin=18

 追記後に再起動すると下記のようにデバイスファイルが現れます。

pi@raspberrypi:~ $ ls -l /dev/lirc0 
crw-rw---- 1 root video 243, 0 Dec  5 20:52 /dev/lirc0

 そしてテレビのリモコンの赤外線のパターンを記録させます。 irrecord コマンドを使うのですが、そのためには一度 LIRC を停止します。

pi@raspberrypi:~ $ sudo /etc/init.d/lirc stop
Stopping lirc (via systemctl): lirc.service.

 停止させたら irrecord コマンドで赤外線パターンを記録し、 lircd.conf というファイルに出力します。

pi@raspberrypi:~ $ irrecord -n -d /dev/lirc0 lircd.conf
〜〜〜中略〜〜〜
Please send the finished config files to <lirc@bartelmus.de> so that I
can make them available to others. Don't forget to put all information
that you can get about the remote control in the header of the file.

Press RETURN to continue. ← Enter押下

Now start pressing buttons on your remote control.

It is very important that you press many different buttons and hold them
down for approximately one second. Each button should generate at least one
dot but in no case more than ten dots of output.
Don't stop pressing buttons until two lines of dots (2x80) have been
generated.

Press RETURN now to start recording. ← Enter押下
↓テレビのリモコンの色々なボタンを1秒以上押し続ける。受信できている間はドットが表示されていく
................................................................................
Found gap: 74690
Please keep on pressing buttons like described above.
................................................................................
Suspicious data length: 99.
Found possible header: 3461 1746
Header is not being repeated.
Found trail pulse: 422
No repeat code found.
Signals are space encoded.
Signal length is 48
Now enter the names for the buttons.

Please enter the name for the next button (press <ENTER> to finish recording)
power ← これから押すボタン(power)の名前を入力してEnter

Now hold down button "power". ← 電源ボタンを押す

Please enter the name for the next button (press <ENTER> to finish recording)
ch1 ← 1チャンネルボタンの名前を入力してEnter

Now hold down button "ch1". ← 1チャンネルボタンを押す

Please enter the name for the next button (press <ENTER> to finish recording)
ch2 ← 2チャンネルボタンの名前を入力してEnter

Now hold down button "ch2". ← 2チャンネルボタンを押す

Please enter the name for the next button (press <ENTER> to finish recording) ← 入力を終了するために空Enter

Checking for toggle bit mask.
Please press an arbitrary button repeatedly as fast as possible.
Make sure you keep pressing the SAME button and that you DON'T HOLD
the button down!.
If you can't see any dots appear, then wait a bit between button presses.

Press RETURN to continue. ← Enter押下
........................ ← 任意の一つのボタンを連打する
No toggle bit mask found.
Successfully written config file.

 出力された lircd.conf ファイルの中身は下記のようになっています。

pi@raspberrypi:~ $ cat lircd.conf

# Please make this file available to others
# by sending it to <lirc@bartelmus.de>
#
# this config file was automatically generated
# using lirc-0.9.0-pre1(default) on Thu Dec  7 14:49:17 2017
#
# contributed by 
#
# brand:                       lircd.conf
# model no. of remote control: 
# devices being controlled by this remote:
#

begin remote

  name  lircd.conf
  bits           24
  flags SPACE_ENC|NO_HEAD_REP
  eps            30
  aeps          100

  header       3461  1746
  one           424  1309
  zero          424   442
  ptrail        422
  pre_data_bits   24
  pre_data       0x400401
  gap          74690
  min_repeat      5
#  suppress_repeat 5
#  uncomment to suppress unwanted repeats
  toggle_bit_mask 0x0

      begin codes
          power                    0x00BCBD
          ch1                      0x900293
          ch2                      0x908213
      end codes

end remote

 これを /etc/lirc ディレクトリにコピーします。

$ sudo cp lircd.conf /etc/lirc/.

 続いて設定ファイル /etc/lirc/hardware.conf を編集します。編集前のファイルとの差分は下記の通りです。

pi@raspberrypi:~ $ diff /etc/lirc/hardware.conf.bak /etc/lirc/hardware.conf
4c4
< LIRCD_ARGS=""
---
> LIRCD_ARGS="--uinput"
16c16
< DRIVER="UNCONFIGURED"
---
> DRIVER="default"
18,19c18,19
< DEVICE=""
< MODULES=""
---
> DEVICE="/dev/lirc0"
> MODULES="lirc_rpi"

 ここまでで設定は完了なので、 LIRC を再起動します。

pi@raspberrypi:~ $ sudo /etc/init.d/lirc restart
Restarting lirc (via systemctl): lirc.service.

AWS IoT Shadow の更新情報を受け取ってテレビを操作する

 それでは赤外線LEDからテレビに赤外線を送信する部分の処理を実装します。 Ruby のコード中から Open3 を使って LIRC の irsend コマンドを呼んでいます。

require 'bundler/setup'
require 'pi_piper'
require 'open3'
require 'logger'

class IR_Transmitter
  LOG_FILE = 'logs/ir_transmitter.log'

  def initialize
    @led_pin = PiPiper::Pin.new(pin: 18, direction: :out)
    @log = Logger.new(LOG_FILE)
  end

  def transmit
    send_signal
  end

  def send_signal
    begin
      result = Open3.capture3('irsend SEND_START TV power')
      @log.debug("SEND_START #{result.inspect}")

      sleep 2

      result = Open3.capture3('irsend SEND_STOP TV power')
      @log.debug("SEND_STOP #{result.inspect}")
    rescue => e
      @log.error(e.backtrace.join("\n"))
    ensure
      Open3.capture3('irsend SEND_STOP TV power')
    end
  end
end

 今回使っているテレビのリモコンは ON と OFF のボタンは分かれていないので、 いずれの場合も同じように赤外線を2秒送信してストップしています。

 次に、 AWS IoT に Subscribe して Shadow の更新を受け取る処理の実装です。下記内容を subscriber.rb として保存します。AWS IoT に MQTT で接続し、 Shadow 更新時の差分情報が配信される delta トピックに Subscribe して待ち受け、差分情報を受け取った時にその内容から ON/OFF の state を抜き出して前述の赤外線送信処理を実行します。

require 'bundler/setup'
require 'mqtt'
require 'json'
require 'open3'
require './ir_transmitter.rb'

AWS_IOT_URL = 'xxxxxxxxxxxxxx.iot.ap-northeast-1.amazonaws.com'
AWS_IOT_PORT = 8883
TOPIC = '$aws/things/home_tv/shadow/update'
DELTA_TOPIC = "#{TOPIC}/delta"

class Subscriber
  LOG_FILE = 'logs/subscriber.log'

  def initialize
    @ir_transmitter = IR_Transmitter.new
    @log = Logger.new(LOG_FILE)
  end

  def statement(power:)
    {
      state: {
        reported: {
          power: power,
        }
      }
    }
  end

  def subscribe
    MQTT::Client.connect(host: AWS_IOT_URL, port: AWS_IOT_PORT, ssl: true, cert_file: 'home_tv-certificate.pem.crt', key_file: 'home_tv-private.pem.key', ca_file: 'root-CA.crt') do |client|
      initial_state = statement(power: 'off').to_json
      client.publish(TOPIC, initial_state)
      @log.info("Published initial statement: #{initial_state}")

      client.subscribe(DELTA_TOPIC)
      @log.info("Subscribed to the topic: #{DELTA_TOPIC}")

      client.get do |topic, json|
        state = JSON.parse(json)['state']
        power = state['power']

        @ir_transmitter.transmit

        reported_state = statement(power: power).to_json

        client.publish(TOPIC, reported_state)
        @log.info("Reported state: #{reported_state}")
      end
    end
  end
end

if $PROGRAM_NAME == __FILE__
  subscriber = Subscriber.new
  subscriber.subscribe
end

 AWS IoT については以前の記事でも書いてますので、詳細はそちらをご覧ください。

blog.akanumahiroaki.com

動作確認

 ここまでで一通りの実装ができたので、 Raspberry Pi 上で Subscriber を起動しておきます。

$ sudo bundle exec ruby subscriber.rb

 また、カスタムスキルが Alexa の Your Skills のリストに表示されていることを確認します。

f:id:akanuma-hiroaki:20171207092043p:plain:w450

 この状態で Alexa に「テレビリモコンでテレビをつけて」と言うと、赤外線LEDから赤外線が送信され、Alexa が「テレビの電源をONにしました」と返答してくれます。また、「テレビリモコンでテレビを消して」と言うと、同様に赤外線LEDから赤外線が送信され、Alexa が「テレビの電源をOFFにしました」と返答してくれます。

課題

 今回使用しているテレビのリモコンは ON/OFF のボタンが同一で、実際にテレビの ON/OFF の状態がどうなっているかは検知できていないので、テレビが ON/OFF どちらの状態から始めるかで逆の状態になってしまう可能性があります。また、赤外線が正しく受信されて ON/OFF が切り替わったかも検知できていないので、何らかの方法で実際のテレビのステータスを検知することが必要です。また、赤外線は指向性が強いのと、今回の装置ぐらいだと結構近受信部に近づかないと届かないので、設置場所には工夫が必要そうです。

まとめ

 赤外線はリモコンの各処理のパターンを記憶させる手間はかかりますが、色々な処理を自動化したりリモートで実行させたりすることができそうなので、今回の内容をベースに外出先からエアコンを操作できるようにしたりしてみたいと思います。もちろんもともと対応している家電があればそれがお手軽ですが、自前の装置で操作できるというのはやっぱり面白いですね。

Alexa Skills Kit でスロットを使ったスキルを実装する

 前回は Alexa Skills Kit で、起動のリクエストを受け付けると決まった処理をしてレスポンスを返すだけのシンプルなスキルを実装してみましたが、今回はユーザからの入力値を使って処理をするスキルを実装してみたいと思います。具体的には、前回は順番決めスキルの中で固定で持っていた対象者リストを、ユーザから入力された名前を使用するように変更してみます。

対話モデルの変更

 まずは対話モデルを変更します。 Alexa Skills Kit では、ユーザからの入力値はスロットという引数で扱うことができますので、インテントスキーマでスロットの利用を定義します。

{
  "intents": [
    {
      "intent": "DecideOrderIntent",
      "slots": [
        { "name": "NameA", "type": "AMAZON.FirstName" },
        { "name": "NameB", "type": "AMAZON.FirstName" },
        { "name": "NameC", "type": "AMAZON.FirstName" },
        { "name": "NameD", "type": "AMAZON.FirstName" }
      ]
    },
    { "intent": "AMAZON.HelpIntent" },
    { "intent": "AMAZON.StopIntent" },
    { "intent": "AMAZON.CancelIntent" }
  ]
}

 今回の実装では、対象者を4人まで指定できるようにしたいと思いますので、カスタムインテントの DecideOrderIntent にスロットを4つ定義しています。スロットを定義する際にはスロットタイプも指定する必要があり、独自のタイプを定義することもできますが、あらかじめ用意されている標準スロットタイプで該当するものがあればそちらを使った方が何かと便利です。今回は名前を扱うためのスロットなので、標準ライブラリの AMAZON.FirstName を使用しています。

developer.amazon.com

 次に、インテントスキーマで定義したスロットを使えるように、サンプル発話を変更します。

DecideOrderIntent 順番決め
DecideOrderIntent 順番決めて
DecideOrderIntent 順番を決めて
DecideOrderIntent 順番決めを開いて
DecideOrderIntent 誰の順番
DecideOrderIntent 誰の番
DecideOrderIntent 誰が先
DecideOrderIntent {NameA} と {NameB} の順番を決めて
DecideOrderIntent {NameA} と {NameB} と {NameC} の順番を決めて
DecideOrderIntent {NameA} と {NameB} と {NameC} と {NameD} の順番を決めて
DecideOrderIntent {NameA} と {NameB} の順番
DecideOrderIntent {NameA} と {NameB} と {NameC} の順番
DecideOrderIntent {NameA} と {NameB} と {NameC} と {NameD} の順番
DecideOrderIntent {NameA} と {NameB}
DecideOrderIntent {NameA} と {NameB} と {NameC}
DecideOrderIntent {NameA} と {NameB} と {NameC} と {NameD}

 8行目以降が今回追加した内容です。スロットはサンプル発話の中にプレースホルダーのような形で配置します。今回の4つのスロットは全て人の名前で、2人〜4人で可変なので、リスト形式で受け取れると良いのですが、それはできないようだったので、2人、3人、4人のそれぞれのパターンを定義しています。ちなみにスロット名とその前後のテキストの間に半角スペースを入れないと対話モデルの保存時にパースエラーになってしまいました。

 基本的には対話モデルの変更はここまででOKですが、今回使用している標準スロットタイプの AMAZON.FirstName は日本語を話すユーザが一般的に使用する数千個の名前を集めたものなので、マイナーな名前やニックネームを使いたい場合には候補を追加して拡張することができます。そのためには対話モデルの設定画面のカスタムスロットタイプの項目で下記のように入力します。(下記の例で使っている名前はあらかじめ含まれているとは思いますが。。)

f:id:akanuma-hiroaki:20171123162106p:plain

 更新 ボタンをクリックすると値が登録され、下記のような表示に変わります。

f:id:akanuma-hiroaki:20171123162137p:plain

 複数の標準スロットタイプを使っていて他のスロットタイプも拡張したい場合には スロットタイプの追加 をクリックするとさらにフォームが表示されるので、追加で登録することができます。

 ここまでの内容を 保存 して対話モデルの変更は終了です。

Lambda ファンクションの変更

 スロットの内容を使えるように、 Lambda ファンクションを変更します。変更後の実装内容は下記のようになります。

# -*- coding: utf-8 -*-
from __future__ import print_function
from random import shuffle

# --------------- Helpers that build all of the responses ----------------------

def build_speechlet_response_with_card(title, output, reprompt_text, should_end_session):
    return {
        'outputSpeech': {
            'type': 'PlainText',
            'text': output
        },
        'card': {
            'type': 'Simple',
            'title': title,
            'content': output
        },
        'reprompt': {
            'outputSpeech': {
                'type': 'PlainText',
                'text': reprompt_text
            }
        },
        'shouldEndSession': should_end_session
    }

def build_speechlet_response_without_card(output, reprompt_text, should_end_session):
    return {
        'outputSpeech': {
            'type': 'PlainText',
            'text': output
        },
        'reprompt': {
            'outputSpeech': {
                'type': 'PlainText',
                'text': reprompt_text
            }
        },
        'shouldEndSession': should_end_session
    }

def build_response(session_attributes, speechlet_response):
    return {
        'version': '1.0',
        'sessionAttributes': session_attributes,
        'response': speechlet_response
    }

# --------------- Functions that control the skill's behavior ------------------

def decide_order(names):
    shuffle(names)
    return "今回は、" + '、'.join(names) + "の順番です。"

def get_welcome_response():
    session_attributes = {}
    speech_output = '対象の名前を四人まで言ってください'
    reprompt_text = '聞き取れませんでした。' + speech_output

    should_end_session = False
    return build_response(session_attributes, build_speechlet_response_without_card(
        speech_output, reprompt_text, should_end_session))

def get_help_response():
    session_attributes = {}
    speech_output = 'このスキルでは、四人までの対象者の順番をシャッフルして決定します。' + \
                    '「誰と誰と誰」、という形で、対象の名前を四人まで言ってください'
    reprompt_text = '聞き取れませんでした。対象の名前を四人まで言ってください'

    should_end_session = False
    return build_response(session_attributes, build_speechlet_response_without_card(
        speech_output, reprompt_text, should_end_session))

def handle_session_end_request():
    speech_output = None
    reprompt_text = None
    should_end_session = True
    return build_response({}, build_speechlet_response_without_card(
        speech_output, reprompt_text, should_end_session))

def get_order(intent, session):
    session_attributes = {}

    slots = intent['slots']
    
    if 'NameA' not in slots or 'NameB' not in slots or 'NameC' not in slots or 'NameD' not in slots:
        speech_output = '名前がわかりませんでした。もう一度言ってください。'
        reprompt_text = speech_output
        should_end_session = False

        return build_response(session_attributes, build_speechlet_response_without_card(
            speech_output, reprompt_text, should_end_session))

    else:
        reprompt_text = None
        should_end_session = True
        card_title = "順番を決めました"
        names = []

        if 'value' in intent['slots']['NameA']:
            names.append(intent['slots']['NameA']['value'])
        if 'value' in intent['slots']['NameB']:
            names.append(intent['slots']['NameB']['value'])
        if 'value' in intent['slots']['NameC']:
            names.append(intent['slots']['NameC']['value'])
        if 'value' in intent['slots']['NameD']:
            names.append(intent['slots']['NameD']['value'])

        speech_output = decide_order(names)

        return build_response(session_attributes, build_speechlet_response_with_card(
            card_title, speech_output, reprompt_text, should_end_session))

# --------------- Events ------------------

def on_session_started(session_started_request, session):
    print("on_session_started requestId=" + session_started_request['requestId']
          + ", sessionId=" + session['sessionId'])

def on_launch(launch_request, session):
    print("on_launch requestId=" + launch_request['requestId'] +
          ", sessionId=" + session['sessionId'])

    return get_welcome_response()

def on_intent(intent_request, session):
    print("on_intent requestId=" + intent_request['requestId'] +
          ", sessionId=" + session['sessionId'])

    intent = intent_request['intent']
    intent_name = intent_request['intent']['name']

    if intent_name == "DecideOrderIntent":
        return get_order(intent, session)
    elif intent_name == "AMAZON.HelpIntent":
        return get_help_response()
    elif intent_name == "AMAZON.CancelIntent" or intent_name == "AMAZON.StopIntent":
        return handle_session_end_request()
    else:
        raise ValueError("Invalid intent")

def on_session_ended(session_ended_request, session):
    print("on_session_ended requestId=" + session_ended_request['requestId'] +
          ", sessionId=" + session['sessionId'])

# --------------- Main handler ------------------

def lambda_handler(event, context):
    print("event.session.application.applicationId=" +
          event['session']['application']['applicationId'])

    if event['session']['new']:
        on_session_started({'requestId': event['request']['requestId']},
                           event['session'])

    if event['request']['type'] == "LaunchRequest":
        return on_launch(event['request'], event['session'])
    elif event['request']['type'] == "IntentRequest":
        return on_intent(event['request'], event['session'])
    elif event['request']['type'] == "SessionEndedRequest":
        return on_session_ended(event['request'], event['session'])

 主に変更したのは get_order() メソッドです。

def get_order(intent, session):
    session_attributes = {}

    slots = intent['slots']
    
    if 'NameA' not in slots or 'NameB' not in slots or 'NameC' not in slots or 'NameD' not in slots:
        speech_output = '名前がわかりませんでした。もう一度言ってください。'
        reprompt_text = speech_output
        should_end_session = False

        return build_response(session_attributes, build_speechlet_response_without_card(
            speech_output, reprompt_text, should_end_session))

    else:
        reprompt_text = None
        should_end_session = True
        card_title = "順番を決めました"
        names = []

        if 'value' in intent['slots']['NameA']:
            names.append(intent['slots']['NameA']['value'])
        if 'value' in intent['slots']['NameB']:
            names.append(intent['slots']['NameB']['value'])
        if 'value' in intent['slots']['NameC']:
            names.append(intent['slots']['NameC']['value'])
        if 'value' in intent['slots']['NameD']:
            names.append(intent['slots']['NameD']['value'])

        speech_output = decide_order(names)

        return build_response(session_attributes, build_speechlet_response_with_card(
            card_title, speech_output, reprompt_text, should_end_session))

 Lambda ファンクションに送信される JSON の内容で、スロットに関する部分を抜粋すると下記のような形になります。

{
  "request": {
    "type": "IntentRequest",
    "requestId": "EdwRequestId.2ea90888-5a5f-4fa1-982d-xxxxxxxxxxxx",
    "intent": {
      "name": "DecideOrderIntent",
      "slots": {
        "NameC": {
          "name": "NameC",
          "value": "じろう"
        },
        "NameD": {
          "name": "NameD"
        },
        "NameA": {
          "name": "NameA",
          "value": "たろう"
        },
        "NameB": {
          "name": "NameB",
          "value": "はなこ"
        }
      }
    },
    "locale": "ja-JP",
    "timestamp": "2017-11-23T07:30:42Z"
  },
}

 get_order() メソッドには intent 以下を渡していますので、そこから slots を取り出し、NameA から NameD までの値を取り出しています。

 今回は対象者数は可変なので、値が設定されていないスロットもありますが、その場合にも上記サンプルの NameD のように、 value の項目がないだけで、 name の項目は入った状態で渡されますので、NameA から NameD のいずれかのキー自体が存在しない場合には、名前を読み取れていないとしてもう一度入力を促すようにしています。

 全てのキーがあった場合は、その中の value のキーがある項目の値を対象者リストに追加して、 decide_order() メソッドに渡しています。

 decide_order() メソッドでは渡された対象者リストをシャッフルしてレスポンスを返しています。

def decide_order(names):
    shuffle(names)
    return "今回は、" + '、'.join(names) + "の順番です。"

 また、ユーザからの対象者名の入力を受け付けるために、スキルの起動リクエストだけを受け取った場合にはユーザに対象者名の入力を促すようにし、セッションを継続するようにしています。

def get_welcome_response():
    session_attributes = {}
    speech_output = '対象の名前を四人まで言ってください'
    reprompt_text = '聞き取れませんでした。' + speech_output

    should_end_session = False
    return build_response(session_attributes, build_speechlet_response_without_card(
        speech_output, reprompt_text, should_end_session))

 そのほかにも AMAZON.HelpIntent を受け取った時の説明内容や、Alexa アプリに表示されるカードの内容などを少し整理しています。

動作確認

 ここまででひとまず実装としては完了なので、動作確認をしてみます。前回の記事でやったようにシミュレータを使ってテストをすることもできますが、Amazon Echo などの実機があれば、実機でテストをすることも可能です。Alexa の管理画面もしくは Alexa アプリでスキルストアにアクセスし、右上の '''Your Skills''' をクリックします。

f:id:akanuma-hiroaki:20171123170025p:plain

 すると追加済みのスキル一覧ページが表示されますので、その中に開発中のスキルが表示されて入れば実機でのテストが可能な状態です。

f:id:akanuma-hiroaki:20171123165944p:plain

 この状態で例えば下記のようなやりとりができれば想定通り実装できています。

ユーザ 「アレクサ、順番決めを開いて」 アレクサ 「対象の名前を四人まで言ってください。」 ユーザ「太郎と花子と二郎」 アレクサ「今回の順番は、花子、二郎、一郎です。」

まとめ

 今回はユーザからの入力内容を扱うようにしたとはいえまだまだシンプルな内容です。それでもやはり固定の処理を行うだけの時と比べると、正常ケースだけでも複数のパターンを考慮する必要がありますし、エラーケースや中断のケースなども含めるとかなり考えることが増えています。また、Webやスマートフォンアプリと違い、入力内容(発話内容)を正しく解釈できるかどうかという点も不安定さはありますので、インタフェース設計は音声入力の特徴をよく考慮した上で設計することが重要と感じました。

Alexa Skills Kit でシンプルなカスタムスキルを実装

 前回 Amazon Echo Dot の初期設定と既存のスキルを使ってみるところだけやりましたが、今回は自作のスキル(カスタムスキル)を実装してみます。Alexa では対話形式で複雑な処理を行うスキルも実装できますが、まず今回はシンプルに、スキルを起動したら結果を返して終了するという最もシンプルなパターンのカスタムスキルを実装してみます。

 うちには小学生の子どもが二人いるのですが、ゲームの順番などでしょっちゅう喧嘩しているので、 Alexa に順番を決めてもらうスキルを作成してみます。(教育的には話し合って解決できるようにするべきという点は一旦置いておきます。)

 ひとまず今回はシミュレータで動作確認ができるところまでをやってみたいと思います。

開発の流れ

 カスタムスキルを作成するには Alexa Skills Kit(ASK)を利用します。Alexa Skills Kit での開発については下記で公式のドキュメントが公開されています。

developer.amazon.com

 スキル開発の流れとしては、上記ドキュメントで下記画像のように紹介されています。

f:id:akanuma-hiroaki:20171118132920p:plain

 また、公式ドキュメントの一部として、クラスメソッドが作成しているトレーニングドキュメントもあるようです。

developer.amazon.com

 開発工程での主な流れとしては下記のようになるかと思います。

  1. 対話モデルの作成

  2. Lambda でバックエンドの処理を作成して対話モデルと紐付け

  3. シミュレータ or 実機でテスト

 Amazon Developer Account や AWS Account の作成方法は割愛させていただきますので、アカウント登録が終わっている前提で、それぞれ進めてみたいと思います。

対話モデルの作成

 まずはスキルを作成して対話モデルを作成していきます。下記リンク先にアクセスして開発者コンソールのダッシュボードを開きます。

Amazon Developer Sign In

 開発者コンソールのダッシュボードは下記のような画面になります。

f:id:akanuma-hiroaki:20171119231851p:plain

 画面上部の ALEXA メニューをクリックして Alexa のダッシュボードを開きます。

f:id:akanuma-hiroaki:20171119232448p:plain

 Alexa の要素としては Alexa Skills Kit(ASK) と Alexa Voice Service(AVS) があり、今回は Alexa Skills Kit を選択します。ちなみに Alexa Voice Service は音声を認識してテキストに変換したり、テキストの内容を音声に変換して発話するために利用するもので、自前でハードウェアに Alexa を組み込んでスマートスピーカーを作る際などに利用します。

f:id:akanuma-hiroaki:20171119232709p:plain

 初めてスキルを作成する場合はスキル一覧には何もありませんが、作成済みのスキルがある場合は上記のように一覧に表示されます。今回は新たにスキルを作るために 新しいスキルを追加する をクリックします。

f:id:akanuma-hiroaki:20171119233414p:plain

 スキルの作成画面に遷移しますので、今回は下記の内容で入力・選択します。

  • スキルの種類:カスタム対話モデル

  • 言語:Japanese

  • スキル名:順番決め

  • 呼び出し名:順番決め

 その他の項目は今回はデフォルトのままにしておきます。入力できたら画面下部の 保存 ボタンをクリックします。

f:id:akanuma-hiroaki:20171122223615j:plain

 するとスキルが作成されますので、 次へ ボタンをクリックして対話モデル作成画面へ進みます。

f:id:akanuma-hiroaki:20171122223840j:plain

 上記は対話モデル作成画面での入力後の状態です。

 まずインテントスキーマは Alexa からバックエンドの Lambda ファンクションへ送られるインテントの種類を定義します。今回は下記のように定義します。

{ "intents": [
    { "intent": "DecideOrderIntent" },
    { "intent": "AMAZON.HelpIntent" },
    { "intent": "AMAZON.StopIntent" },
    { "intent": "AMAZON.CancelIntent" }
]}

 今回実装するカスタムスキル用のインテントとして DecideOrderIntent を定義しています。また、それ以外にビルトインインテントを3種類使用します。

 今回のカスタムスキルでは特にユーザから情報を提供する必要はないので、カスタムスロットタイプはブランクのままにしておきます。将来的にはユーザから順番決めの候補者名を提供するようにしたいので、その際にはカスタムスロットタイプを定義することになるかと思います。

 また、サンプル発話は下記のように定義します。

DecideOrderIntent 順番決め
DecideOrderIntent 順番決めて
DecideOrderIntent 順番を決めて
DecideOrderIntent 順番決めを開いて
DecideOrderIntent 誰の順番
DecideOrderIntent 誰の番
DecideOrderIntent 誰が先

 サンプル発話にはユーザがこのスキルを呼び出したいときに使う可能性のある発話内容をリストアップしておきます。

 ここまで入力したら 次へ ボタンをクリックしてエンドポイント等の設定画面へ進みます。ここでスキルのコンソールは一旦置いておいて、 Lambda ファンクションの実装に移ります。

エンドポイントの Lambda 実装

 Alexa Skills Kit では、入力された音声の内容に応じて処理を行うロジックとして、 AWS Lambda のファンクションを使うか、 Web API を呼び出すかを指定できます。標準は Lambda なので、今回も Lambda のファンクションとして実装します。Alexa Skills Kit のエンドポイントとしての Lambda 実装についてのリファレンスは下記になります。

developer.amazon.com

 Alexa Skills Kit でのエンドポイントとのやりとりは JSON で行われますが、その内容についてのリファレンスは下記になります。

developer.amazon.com

 まずは AWS のコンソールにログインして Lambda のコンソールを表示します。

f:id:akanuma-hiroaki:20171120000635p:plain

 新たにファンクションを作成するため、 関数の作成 をクリックします。

f:id:akanuma-hiroaki:20171120000801p:plain

 ベースとなるサンプルを選択します。もちろんファンクションを一から作成しても良いのですが、 Alexa のエンドポイント用の実装サンプルがいくつか公開されていますので、それを変更する形で実装したいと思います。今回は Python での実装サンプルである、「alexa-skills-kit-color-expert-python」を利用します。

f:id:akanuma-hiroaki:20171120001523p:plain

 基本的な情報としてファンクション名とロールを設定します。私のケースでは既存のロールがあったので 既存のロールを選択 を選択してそれを利用していますが、初めて作成する場合には テンプレートから新しいロールを作成 もしくは カスタムロールの作成 を選択して新しくロールを作成します。

 上記以外はひとまずそのままで、画面下部の 関数の作成 ボタンをクリックするとファンクションが作成されます。

f:id:akanuma-hiroaki:20171122224059j:plain

 私が実行したところ、作成後の画面で上記のようなエラーが表示されました。Alexa Skills Kit のトリガーの作成に失敗したということのようですが、トリガーとしては追加されているようなので、ひとまずこのまま進みます。

 一旦 Lambda コンソールは置いておいて、作成した Lambda ファンクションをスキルに紐づけるために、スキルのコンソールに戻ります。

f:id:akanuma-hiroaki:20171122224320j:plain

 サービスエンドポイントのタイプで「AWS Lambda の ARN」を指定し、Lambda ファンクション作成後の画面の右上に表示されていた ARN をデフォルトに設定します。「エンドポイントの地理的リージョンを設定しますか?」の項目には「いいえ」を指定し、その他はデフォルトのままで 次へ をクリックします。

f:id:akanuma-hiroaki:20171122224612j:plain

 シミュレーターが表示されますので、意図した通りにカスタムスキルを呼び出せるか確認します。エンドポイントにもリクエストが送信されますので、先ほど作成した Lambda ファンクションへも実際にリクエストが送信されることになります。

 サービスシミュレーターのテキストに、カスタムスキルのサンプル発話に登録したものの一つを入力して 順番決めを呼び出す をクリックします。するとリクエストとレスポンスの JSON が下に表示されます。レスポンスの内容は Lambda ファンクションの処理結果になりますが、先ほど作成したファンクションはまだサンプルの内容を変更していませんので、サンプルのレスポンスがそのまま返ってきています。

 それでは Lambda ファンクションを今回のカスタムスキルの意図に沿ったものに変更していきますが、まずはファンクションのテストのためにどんな JSON がリクエストされるのかを確認しておきます。シミュレータの実行結果ではリクエストの JSON は下記のようになっていました。あくまで私が実行した時の例なので、ID等の値は変わってくるかと思いますし一部マスクしていますが、構成は同様になるかと思います。

{
  "session": {
    "new": true,
    "sessionId": "SessionId.7caeec82-30ad-4629-9c96-xxxxxxxxxxxx",
    "application": {
      "applicationId": "amzn1.ask.skill.1f313097-0cb4-4be1-a4d8-xxxxxxxxxxxx"
    },
    "attributes": {},
    "user": {
      "userId": "amzn1.ask.account.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
    }
  },
  "request": {
    "type": "LaunchRequest",
    "requestId": "EdwRequestId.252e3464-1623-422f-9bf3-xxxxxxxxxxxx",
    "locale": "ja-JP",
    "timestamp": "2017-11-19T22:25:21Z"
  },
  "context": {
    "AudioPlayer": {
      "playerActivity": "IDLE"
    },
    "System": {
      "application": {
        "applicationId": "amzn1.ask.skill.1f313097-0cb4-4be1-a4d8-xxxxxxxxxxxx"
      },
      "user": {
        "userId": "amzn1.ask.account.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
      },
      "device": {
        "supportedInterfaces": {}
      }
    }
  },
  "version": "1.0"
}

 この JSON をそのまま Lambda コンソールからテストイベントとして設定しておきます。

f:id:akanuma-hiroaki:20171122224939j:plain

 そして今回のファンクションの内容は下記のようにしました。とりあえず今回はユーザからの候補者名の入力は受け付けず、固定の二人の名前を実行時に毎回シャッフルして順番を返す単純なものです。

# -*- coding: utf-8 -*-
from __future__ import print_function
from random import shuffle

# --------------- Helpers that build all of the responses ----------------------

def build_speechlet_response(title, output, reprompt_text, should_end_session):
    return {
        'outputSpeech': {
            'type': 'PlainText',
            'text': output
        },
        'card': {
            'type': 'Simple',
            'title': "SessionSpeechlet - " + title,
            'content': "SessionSpeechlet - " + output
        },
        'reprompt': {
            'outputSpeech': {
                'type': 'PlainText',
                'text': reprompt_text
            }
        },
        'shouldEndSession': should_end_session
    }

def build_response(session_attributes, speechlet_response):
    return {
        'version': '1.0',
        'sessionAttributes': session_attributes,
        'response': speechlet_response
    }

# --------------- Functions that control the skill's behavior ------------------

def decide_order():
    candidates = ['太郎君', '花子さん']
    shuffle(candidates)
    return "今回は、" + '、'.join(candidates) + "の順番です。"

def get_welcome_response():
    session_attributes = {}
    card_title = "順番決め"
    speech_output = decide_order()

    should_end_session = True
    return build_response(session_attributes, build_speechlet_response(
        card_title, speech_output, None, should_end_session))

def handle_session_end_request():
    card_title = "順番決め終了"
    speech_output = "良い一日を!"

    should_end_session = True
    return build_response({}, build_speechlet_response(
        card_title, speech_output, None, should_end_session))

def get_order(intent, session):
    session_attributes = {}
    reprompt_text = None

    speech_output = decide_order()
    should_end_session = True

    return build_response(session_attributes, build_speechlet_response(
        intent['name'], speech_output, reprompt_text, should_end_session))

# --------------- Events ------------------

def on_session_started(session_started_request, session):
    print("on_session_started requestId=" + session_started_request['requestId']
          + ", sessionId=" + session['sessionId'])

def on_launch(launch_request, session):
    print("on_launch requestId=" + launch_request['requestId'] +
          ", sessionId=" + session['sessionId'])

    return get_welcome_response()

def on_intent(intent_request, session):
    """ Called when the user specifies an intent for this skill """

    print("on_intent requestId=" + intent_request['requestId'] +
          ", sessionId=" + session['sessionId'])

    intent = intent_request['intent']
    intent_name = intent_request['intent']['name']

    if intent_name == "DecideOrderIntent":
        return get_order(intent, session)
    elif intent_name == "AMAZON.HelpIntent":
        return get_welcome_response()
    elif intent_name == "AMAZON.CancelIntent" or intent_name == "AMAZON.StopIntent":
        return handle_session_end_request()
    else:
        raise ValueError("Invalid intent")

def on_session_ended(session_ended_request, session):
    print("on_session_ended requestId=" + session_ended_request['requestId'] +
          ", sessionId=" + session['sessionId'])

# --------------- Main handler ------------------

def lambda_handler(event, context):
    print("event.session.application.applicationId=" +
          event['session']['application']['applicationId'])

    if event['session']['new']:
        on_session_started({'requestId': event['request']['requestId']},
                           event['session'])

    if event['request']['type'] == "LaunchRequest":
        return on_launch(event['request'], event['session'])
    elif event['request']['type'] == "IntentRequest":
        return on_intent(event['request'], event['session'])
    elif event['request']['type'] == "SessionEndedRequest":
        return on_session_ended(event['request'], event['session'])

 lambda_handler() メソッドに渡している event には、先ほど確認したリクエストの内容が入ってきます。

 また、リクエストの種別としては下記3種類を想定していて、処理内容を切り分けています

  • LaunchRequest: スキル起動時

  • IntentRequest: セッション継続中 もしくはスキル起動時に追加情報と一緒に起動した場合

  • SessionEndedRequest: スキル終了時

 今回はユーザからの追加情報は受け付けないので、 LaunchRequest と IntentRequest で基本的には同じ処理をしています。 IntentRequest の処理の内容はインテント名でさらに切り分けて AMAZON.HelpIntent 等についての処理もサンプルにあったものをそのまま残していますが、今回の内容ではスキルの起動以外にユーザの入力を待ち受けることがないため、 DecideOrderIntent 以外の処理は実行されないかと思います。

 ファンクションを保存して再度シミュレータからリクエストを実行すると、下記のようにレスポンスが返るようになります。

f:id:akanuma-hiroaki:20171122225220j:plain

まとめ

 今回はシンプルなカスタムスキル実装ということで、ユーザからはスキル起動の発話だけ受け取って結果を返すという単純なものでしたので、入力値のハンドリング等も特に必要なく、簡単に実装できました。 Lambda からはさらに他のAWSサービスや外部サービスへも連携できますので、アイディア次第で色々なことができそうです。一方でユーザからの入力内容によって処理を変えられるようにもしたいので、次回以降で入力値のハンドリングも行うスキルを実装してみたいと思います。

Amazon Echo Dot 開封から初期設定など

 先週招待リクエストを登録しておいた Amazon Echo Dot ですが、今週水曜日(11/15)に招待メールが来たので早速購入。昨日(11/16)に届いたので、開封から初期設定まで行い、軽く使ってみました。

www.amazon.co.jp

パッケージと外観など

f:id:akanuma-hiroaki:20171117061337j:plain:w300:left こんな感じの青いパッケージです。


f:id:akanuma-hiroaki:20171117061413j:plain:w300:left 中には本体と電源ケーブル(USB+アダプタ)と、簡単な使い方の説明のカードが入っています。


f:id:akanuma-hiroaki:20171117061523j:plain:w450

Google Home mini と比べるとこんな感じです。Echo Dot の方が一回りコンパクトで、実際は写真よりもさらにコンパクトな印象です。Google Home mini が丸みを帯びた形なのに対して、 Echo Dot がソリッドなので余計にそう思えるのかもしれません。

電源投入

f:id:akanuma-hiroaki:20171117062340j:plain:w300:left

 電源スイッチはなく、付属のUSBケーブル+電源アダプタを接続すると起動します。音声の案内があってライトリングがオレンジ色に光って回り始め、初期設定待ち状態になります。

アプリから Wi-Fi 接続設定

 Echo の初期設定は Alexa アプリから行います。 iOS ユーザであれば AppStore からアプリをインストールします。

Amazon Alexa

Amazon Alexa

  • AMZN Mobile LLC
  • Music
  • Free

f:id:akanuma-hiroaki:20171117062835p:plain:w300:left

 アプリを起動して Amazon のアカウントでサインインすると、まず利用規約への同意を求める画面が表示されます。


f:id:akanuma-hiroaki:20171117062923p:plain:w300:left

 利用規約に同意すると Alexa のホーム画面が表示されます。まずは端末を登録するため、画面中程に見えている CUSTOMIZE ALEXA リンクをタップします。


f:id:akanuma-hiroaki:20171117063226p:plain:w300:left

 すると設定画面が開きます。自分で追加した覚えはないのですが、 Echo Dot がすでにリストに表示されているのでタップします。


f:id:akanuma-hiroaki:20171117072027p:plain:w300:left

 まずは Wi-Fi に接続するために Update Wi-Fi をタップ


f:id:akanuma-hiroaki:20171117072154p:plain:w300:left

 接続設定の開始画面が表示されるので CONNECT TO WI-FI をタップ


f:id:akanuma-hiroaki:20171117072303p:plain:w300:left

 ライトリングがオレンジになってればOKということなので、 CONTINUE をタップ


f:id:akanuma-hiroaki:20171117072430p:plain:w300:left

 Echo Dot が Amazon-CAV という名前のアクセスポイントとして見つかるということなので iOS の Wi-Fi 設定から Amazon-CAV に接続して再度 Alexa アプリに戻ります。


f:id:akanuma-hiroaki:20171117072643p:plain:w300:left

 すると Echo Dot へ接続できたことの確認画面が表示されるので CONTINUE をタップします。


f:id:akanuma-hiroaki:20171117075339j:plain:w300:left

 Wi-Fi AP のリストが表示されるので、接続するAPを選択します。


f:id:akanuma-hiroaki:20171117073913p:plain:w300:left

 以降は AP のパスワードなどの情報を入力していくと Echo Dot が Wi-Fi AP にアクセスし、接続に成功すると完了画面が表示されます。ここまで終われば 基本的な機能は利用可能になります。


Request Sounds の設定

f:id:akanuma-hiroaki:20171117075548j:plain:w300:left

 ここからは好みですが、 デフォルトでは Echo が Wake Word を検知した場合に、本体のライトではそれがわかるものの、それ以外では検知したかわからないため、本体が見えないところからだと喋ってみたけど Wake Word が検知されていなかったという悲しいことになる場合があるため、 Wake Word を検知した場合に音を鳴らしてくれるように設定します。設定画面から Sounds メニューをタップします。


f:id:akanuma-hiroaki:20171117080012p:plain:w300:left

 Request Sounds の項目の内容は下記の通りです。

 * Start of Request Wake Word を検知した場合に音を鳴らすかどうか

 * End of Request Wake Word を検知して待ち受け状態になった後、待ち受け状態を終了した場合に音を鳴らすかどうか

 デフォルトではいずれも OFF になっているので、トグルをタップして ON にします。


音楽サービスのアカウント

f:id:akanuma-hiroaki:20171117080850j:plain:w300:left

 Echo では音楽をかけることもできますが、設定画面から音楽サービスのアカウントを確認したところ最初から Amazon Music が使える状態になっていました。 Amazon Music Unlimited は30日間は無料だと思いますが、このままにしておくとそのまま課金されていくんでしょうか。。?

www.amazon.co.jp


 その他には Google Calendar などとも連携させることができるので、設定しておけばスケジュールの確認なども行えるようになります。

音声での購入設定

f:id:akanuma-hiroaki:20171117085024p:plain:w300:left

 Echo では音声で Amazon から商品を購入することもできますが、いきなり意図せず購入されてしまっても困るので、一旦無効にしておきます。アカウント設定の Voice Purchasing メニューから、 Purchase by voice を OFF にしておきます。

スキルの設定

 Amazon Echo の売りはやはりスキルの多さですね。日本語でもすでにかなりの数のスキルが公開されているようです。

robotstart.info

f:id:akanuma-hiroaki:20171117083405p:plain:w300:left

 基本的なスキルはいくつかあらかじめ登録されていて、アカウントの設定画面からも設定できるようになっています。例えばニュースであればアカウント設定の Flash Briefing から設定できます。


f:id:akanuma-hiroaki:20171117083706p:plain:w300:left

 すでに登録されているニュースカテゴリのスキルが表示されます。NHKラジオニュースと今日の天気予報はデフォルトで登録されています。左の画像では「ロボスタニュース」と TechCrunch Japan の「最新ニュース」は私が後から追加したものです。また、有効・無効もここで簡単に切り替えることができ、無効にしたものは OFF の項目に表示されるようになります。他のニューススキルを追加するには Get more Flash Briefing content をタップするとスキルリストの画面に遷移します。


f:id:akanuma-hiroaki:20171117084108p:plain:w300:left

 スキルを追加するのは簡単で、目的のスキルの詳細ページに行って ENABLE をタップするだけです。追加されると表示が DISABLE SKILL に変わるので、もし削除する場合には再度タップします。


f:id:akanuma-hiroaki:20171117084320p:plain:w300:left

 設定画面からではなく、左上のハンバーガーメニューから Skills メニューを選択するとスキルストアのトップに遷移しますので、様々なカテゴリの中から好みのスキルを追加することができます。

まとめ

 まだ少ししか使っていないですが、 Google Home mini と比較すると、音声認識や日本語の滑らかさは Google Home mini の方が上の印象です。ですが多くのスキルで簡単に機能を追加できるというのが Amazon Echo の優っている点だと思いますので、公開されているスキルを試すのはもちろん、自作スキルの方も試していきたいと思います。

f:id:akanuma-hiroaki:20171117085420j:plain:w300:left

 「Alexa、猫の鳴き声を教えて」と言うと猫の鳴き声を再生してくれるのですが、うちの猫が動揺し始めるのが面白いです。

Amazon Lex を AWS SDK for Ruby から試す

 日本でも Amazon Echo の発売が発表されました。私もとりあえず招待メールをリクエストしておいたので、購入できたら Alexa のスキルを色々試してみたいと思ってますが、その前に、今更感もありますが Amazon Lex を理解するためにチュートリアルなど試してみたので、ついでに AWS SDK for Ruby から Lex にリクエストを投げる処理を書いてみました。

Lex のチュートリアル

 AWSの公式ドキュメントには Lex で Bot を作成するチュートリアルが用意されています。

docs.aws.amazon.com

 Blueprint から Bot を作成してそのまま動かしてみるケースや、 AWS Lambda を Fulfillment としてゼロから作成するケースなどが用意されています。今回は後者のケースでコンソールから作成した PizzaOrderingBot に対して AWS SDK for Ruby からリクエストを投げてみたいと思います。

PizzaOrderingBot の処理内容

 PizzaOrderingBot はピザの注文を受け付けて処理する想定の Bot です。今回はチュートリアルの内容そのままに作成したので、詳細はドキュメントをご覧いただくこととして割愛しますが、内容としてはピザの種別(ベジタブル or チーズ)、大きさ(大、中、小)、クラスト(皮)の種類(厚い or 薄い)を音声入力もしくはテキスト入力で受け付け、その内容を AWS Lambda に渡して処理します。

docs.aws.amazon.com

 今回はこの PizzaOrderingBot へリクエストを投げる Ruby スクリプトを Raspberry Pi 上で動かしてみます。本当は実際に喋った内容をキャプチャして入力として使いたかったのですが、 Raspberry Pi での音声入力の扱いがうまく行かなかったので、今回は模擬的に Amazon Polly でテキストを音声ファイルにして、それを Lex の入力として使ってみました。

AWS SDK for Ruby のインストール

 AWS SDK for Ruby は Version 3 から gem が各サービスごとの gem に分割されました。

File: README — AWS SDK for Ruby V3

 今まで通り全て一括でインストールすることもできますが、不要なものはインストールしないに越したことはないので、今回は Lex と Polly の gem を指定してインストールします。 Gemfile は下記のような内容にしています。

# frozen_string_literal: true
source "https://rubygems.org"

gem 'aws-sdk-lex', '~> 1'
gem 'aws-sdk-polly', '~> 1'

サンプル実装

 それでは Ruby スクリプトの実装です。まずはスクリプト全体を掲載しておきます。

require 'bundler/setup'
require 'aws-sdk-lex'
require 'aws-sdk-polly'
require 'open3'

class LexSample
  REGION          = 'us-east-1'.freeze
  LEX_INPUT_FILE  = 'lex_input.pcm'.freeze
  LEX_OUTPUT_FILE = 'lex_output.mp3'.freeze

  def initialize
    @lex_client   = Aws::Lex::Client.new(region: REGION)
    @polly_client = Aws::Polly::Client.new(region: REGION)
  end

  def make_lex_input_file(text)
    resp = @polly_client.synthesize_speech({
      output_format: 'pcm', 
      sample_rate:   '8000', 
      text:          text, 
      text_type:     'text', 
      voice_id:      'Joanna', 
    })
    puts resp.to_h

    File.open(LEX_INPUT_FILE, 'wb') do |f|
      f.write(resp[:audio_stream].read)
    end
  end

  def post_request
    input_stream = File.open(LEX_INPUT_FILE, 'rb')
    resp = @lex_client.post_content(
      bot_name:     'PizzaOrderingBot',
      bot_alias:    'BETA',
      user_id:      'hiroaki.akanuma',
      content_type: 'audio/lpcm; sample-rate=8000; sample-size-bits=16; channel-count=1; is-big-endian=false',
      accept:       'audio/mpeg',
      input_stream: input_stream
    )
    puts resp.to_h

    File.open(LEX_OUTPUT_FILE, 'wb') do |f|
      f.write(resp[:audio_stream].read)
    end
  end

  def read_output
    Open3.capture3("mpg321 #{LEX_OUTPUT_FILE}")
  end
end

if $PROGRAM_NAME == __FILE__
  sample = LexSample.new

  sample.make_lex_input_file('I want to order a pizza')
  sample.post_request
  sample.read_output

  # ピザの種類を選択
  sample.make_lex_input_file('cheese')
  sample.post_request
  sample.read_output

  # ピザの大きさを選択
  sample.make_lex_input_file('large')
  sample.post_request
  sample.read_output

  # ピザクラストを選択
  sample.make_lex_input_file('thick')
  sample.post_request
  sample.read_output
end

 まずクラスの初期化時に Lex と Polly のクライアントインスタンスを生成しておきます。

  def initialize
    @lex_client   = Aws::Lex::Client.new(region: REGION)
    @polly_client = Aws::Polly::Client.new(region: REGION)
  end

 以降は下記ステップを複数回繰り返して、 Bot とのやり取りを進めています。

  • Polly にテキストを渡して音声ストリームをファイルに保存

  • 音声ファイルを入力にして Lex にリクエストしてレスポンスの音声ストリームをファイルに保存

  • 保存した Lex からのレスポンスを読み上げる

 Polly で音声合成を行うには synthesize_speech メソッドを使用します。今のところ Lex は日本語には対応していないので、英語での音声出力を作成します。出力フォーマットは pcm です。

    resp = @polly_client.synthesize_speech({
      output_format: 'pcm', 
      sample_rate:   '8000', 
      text:          text, 
      text_type:     'text', 
      voice_id:      'Joanna', 
    })

 レスポンスから音声ストリームを取り出してファイルに保存します。

    File.open(LEX_INPUT_FILE, 'wb') do |f|
      f.write(resp[:audio_stream].read)
    end

 保存した音声ファイルをオープンして Lex への入力にします。 Lex にリクエストを投げるには post_content メソッドを使用します。 post_content メソッドは音声・テキスト両方の入力に使用できます。もしテキストのみ扱うということでしたら、 post_text メソッドを使用することもできます。

 ちなみに post_content のドキュメントはこちらです。 Class: Aws::Lex::Client — AWS SDK for Ruby V3

 Polly では pcm フォーマットで出力したので、それに対応する content_type を指定します。また、 Raspberry Pi 上での再生をしやすいように、 accept に 'audio/mpeg' を指定することで Bot からのレスポンスの音声ストリームを MPEG 形式にしています。

    input_stream = File.open(LEX_INPUT_FILE, 'rb')
    resp = @lex_client.post_content(
      bot_name:     'PizzaOrderingBot',
      bot_alias:    'BETA',
      user_id:      'hiroaki.akanuma',
      content_type: 'audio/lpcm; sample-rate=8000; sample-size-bits=16; channel-count=1; is-big-endian=false',
      accept:       'audio/mpeg',
      input_stream: input_stream
    )

 保存された音声ファイルは mpg321 コマンドで再生します。

    Open3.capture3("mpg321 #{LEX_OUTPUT_FILE}")

 Bot に対して I want to order a pizza と言うことで会話が始まり、ボットからの質問に応じてピザの種類、大きさ、クラストの種類をそれぞれ音声で入力して、レスポンスを再生します。

実行してみる

 それでは実行してみます。デバッグ用にレスポンスを Hash として出力していますので、実行すると下記のような出力があり、Polly で生成した音声と Lex によってやり取りが行われ、最終的にピザのオーダーが完了します。 Bot からの質問に答えるにつれて slots の内容が埋まっていっているのがわかります。

pi@raspberrypi:~/lex_sample $ bundle exec ruby lex_sample.rb 
{:audio_stream=>#<StringIO:0x567a49b8>, :content_type=>"audio/pcm", :request_characters=>23}
{:content_type=>"audio/mpeg", :intent_name=>"OrderPizza", :slots=>{"pizzaKind"=>nil, "size"=>nil, "crust"=>nil}, :message=>"Do you want a veg or cheese pizza?", :dialog_state=>"ElicitSlot", :slot_to_elicit=>"pizzaKind", :input_transcript=>"i want to order a pizza", :audio_stream=>#<StringIO:0x569df3d8>}
{:audio_stream=>#<StringIO:0x56ada838>, :content_type=>"audio/pcm", :request_characters=>6}
{:content_type=>"audio/mpeg", :intent_name=>"OrderPizza", :slots=>{"pizzaKind"=>"cheese", "size"=>nil, "crust"=>nil}, :message=>"What size pizza?", :dialog_state=>"ElicitSlot", :slot_to_elicit=>"size", :input_transcript=>"cheese", :audio_stream=>#<StringIO:0x56e6dfd0>}
{:audio_stream=>#<StringIO:0x56ebf138>, :content_type=>"audio/pcm", :request_characters=>5}
{:content_type=>"audio/mpeg", :intent_name=>"OrderPizza", :slots=>{"pizzaKind"=>"cheese", "size"=>"large", "crust"=>nil}, :message=>"What kind of crust would you like?", :dialog_state=>"ElicitSlot", :slot_to_elicit=>"crust", :input_transcript=>"large", :audio_stream=>#<StringIO:0x56ee4080>}
{:audio_stream=>#<StringIO:0x56abe218>, :content_type=>"audio/pcm", :request_characters=>5}
{:content_type=>"audio/mpeg", :intent_name=>"OrderPizza", :slots=>{"pizzaKind"=>"cheese", "size"=>"large", "crust"=>"thick"}, :message=>"Okay, I have ordered your large cheese pizza on thick crust", :dialog_state=>"Fulfilled", :input_transcript=>"thick", :audio_stream=>#<StringIO:0x56fb4f40>}

まとめ

 Lex は主にチャットボットを作成するために使われることが多そうなので、今回のように SDK から使うケースはあまり多くないのかもしれませんが、 SDK で Lex へリクエストを投げることは簡単だったので、 Raspberry Pi で音声入力と組み合わせることができれば、色々なセンサー類との連携もできそうなので面白そうかなと思いました。

f:id:akanuma-hiroaki:20171113235330j:plain:w450

猫もswitchやる時代らしいです。