スマートプラグ + ESP32 で超シンプルに Wake On Wan
スマートスピーカーの普及に伴いスマートホーム系製品の低価格化が少しずつ進んでいます。 最近プライベートで次の製品を買いました。今のところ安定動作しており自宅で使っている Google Home Mini との相性もよく気に入っています。
1) 公式アプリ 2) Google Home Mini 3) マイコンボード により照明を操作
（注：この動画には "OK Google" の発声が含まれます。
近くに Goole Home デバイスのある場合にはご注意下さい）
※スマートプラグを使えば家庭用電源から所定の機器への給電を手軽に操作できるため便利ですが、個人的には何らかの原因で自分の意図しない動作が起こった場合に深刻な事態につながりかねない機器との併用は避けています。たとえば少なくとも現時点で電気ストーブなどをつなぐ勇気はありません ^^;
スマートプラグを PC の起動に利用する
スマートスピーカーへの音声指示で PC を起動するアイディアには実用性があり、ネットを検索すると参考になる多くの興味深い例に触れることができます。一方で、Meross Smart Plug Mini を触っているうちにこれを使えばとてもシンプルな道具立てで同様のことを実現できるのではないかと考えました。以下の発想によるものです。
電源投入からのスタートなのでボード側の初期処理に多少の時間がかかることは予想されるものの全体として筋は通っています。特に難しい要素もないため国内外のどこかにすでに同一の事例があるのではないかと想像しましたが、手元でざっと見渡した範囲では見当たらないようです。そんなわけで、まあもし先例があってもいいか、と思いながらざっくり形にしてみることにしました。
実装と動作の様子
スマートプラグからの給電先は何かと融通のきく ESP32 ボードとしました。AC アダプタと USB ケーブルごしにボード単体をプラグへ接続して使います。 プログラムは以下の内容としました。対象 PC が起動すれば当該ボードはお役御免につきプログラムから給電元のプラグをオフにすることで自らをシャットダウンします。
あわせてネットワーク接続時と電源切断前にメールでその旨を通知します。この通知はリモートで操作を行う場合には状況把握のために有用ですが、スマートスピーカーへ声をかけている在宅時にはいささか冗長なのでいずれ手を加えるかもしれません。
ソースコード
Arduino IDE + Arduino core for the ESP32 環境向けに用意したプログラムです。
前項に挙げたメール通知処理には SendGrid を、プラグのシャットダウンには IFTTT アプレットを利用しています。
これらは ESP32_WakeOnLan.h 冒頭の「#define USE_MAIL_NOTIFICATION」「#define USE_AUTO_SHUTDOWN」の定義を無効化すれば省略されます。
デモ
一式の動作の様子を収めた動画です。 （1分10秒）
（注：この動画には "OK Google" の発声が含まれます。
近くに Goole Home デバイスのある場合にはご注意下さい）
余談ながら、手元では過去に何度か Wake On Wan の試みを行いそれぞれ当ブログの記事として公開しています。見返してみると道具立てに微妙に当時の状況が反映されておりちょっと面白く感じました。
時代が加速を続けています。数年後の未来が楽しみです。
(tanabe)
MySQLの新認証方式について
MySQL 5.6 で新たな認証方式 sha256_password が追加され、 MySQL 8 ではその改良版となる caching_sha2_password が追加されました。詳しくは MySQL 8.0.4 : New Default Authentication Plugin : caching_sha2_password を参照してください。
これらは従来の native_password 方式よりも安全とされています。 3つの認証方式について特徴をまとめてみます。
攻撃経路
認証方式を考えるとき、ざっくりと2つの攻撃経路があります。
1つ目は mysql.user テーブルの authentication_string カラム (旧 password カラム) です。このカラムをSELECTできるユーザーが、他のユーザーの authentication_string を閲覧し、その情報を元になりすましができる可能性があります。
2つ目は通信経路です。具体的には盗聴したりサーバーになりすますことで、認証に必要な情報を取得する可能性があります。
3つの認証方式の詳細
caching_sha2_password は sha256_password の改良版です。特に初回の認証は sha256_password と同じです。なのでまずは native_password と sha256_password を比較してみましょう。
| 認証方式 | native_password | sha256_password |
|---|---|---|
| ハッシュ関数 | SHA-1 | SHA-256 |
| SALT | なし | あり |
| 認証プロトコル | 非可逆なチャレンジ＆レスポンス | パスワードを可逆な形で送信 |
native_password
authentication_string カラムの内容は、 native_password が salt なしの純粋な SHA1(SHA1(password)) の先頭に、 MySQL 4.1 以前の形式と区別するための目印として "*" をつけたものです。
mysql> create user t3 identified with 'mysql_native_password' by 'password';
Query OK, 0 rows affected (0.20 sec)
mysql> select Host,User,plugin,authentication_string from mysql.user WHERE User='t3';
+------+------+-----------------------+-------------------------------------------+
| Host | User | plugin | authentication_string |
+------+------+-----------------------+-------------------------------------------+
| % | t3 | mysql_native_password | *2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19 |
+------+------+-----------------------+-------------------------------------------+
1 row in set (0.00 sec)
mysql> select SHA1(unhex(SHA1('password')));
+------------------------------------------+
| SHA1(unhex(SHA1('password'))) |
+------------------------------------------+
| 2470c0c06dee42fd1618bb99005adca2ec9d1e19 |
+------------------------------------------+
1 row in set (0.00 sec)
このため、複数のユーザーが同じパスワードを利用していると authentication_string も同じになります。また、 NIST により認証に SHA-1 を使うのをやめるように推奨されています。これが前述の記事で説明された、新認証方式が必要になった理由 (native_password の弱点) です。
Client-Serverプロトコル (以降プロトコルと呼ぶ) では、まずサーバーからクライアントに nonce が送られ、クライアントは次の計算結果をサーバーに返します。 (https://dev.mysql.com/doc/internals/en/secure-password-authentication.html#packet-Authentication::Native41 より引用)
SHA1( password ) XOR SHA1( "20-bytes random data from server" <concat> SHA1( SHA1( password ) ) )
サーバーは最初に送信した nonce と SHA1(SHA1(password)) を知っているので、再度 XOR を取ることで SHA1(password) を知ることができます。それにもう一度 SHA1() をかけて authentication_string と一致するかで認証することができます。
攻撃者がこの通信を盗聴した場合、 password や SHA1(password) を知ることができません。
また、 攻撃者がサーバーになりすました場合も、password や SHA1(password) を知ることができません。ただしリレー攻撃で本物のサーバーに接続することは可能です。
もちろん、攻撃者が authentication_string を知っている場合は、サーバーと同じ手順で SHA1(password) を得ることができます。生のパスワードがなくても SHA1(password) があれば本物のサーバーに対して認証を通ることができます。
sha256_password
authentication_string はSALT付きで SHA256 を複数ラウンドしたものらしいです。実際、同じパスワードのユーザーを複数作成してみても、全員が異なる authentication_string が異なります。攻撃者が同じMySQLサーバーにログインして mysql.user テーブルを閲覧可能な場合は、 native_password よりも格段に安全です。
一方で、認証プロトコルは次のようになっています。
- 安全な経路 (SSL あるいは unix domain socket) では password + nonce を送る。
- それ以外の経路では password を RSA で暗号化して送る。
どちらも適切に設定されている場合は native_password と同等以上に安全だと思います。
ただしサーバーになりすまされた場合に攻撃者に生の password を与えてしまう点は気になります。なりすましを許した時点でリレー攻撃により本物のサーバーに接続して SET PASSWORD を含む任意のクエリを実行されてしまう可能性があるのであくまでも気持ちの問題ですが。
caching_sha2_password
1度目の認証は sha256_password と同じですが、サーバーはそのときに SHA256(password) をキャッシュします。
2度めからの認証は native_password に似た（ただし SHA-256 を利用した）チャレンジ＆レスポンス認証になるので、生パスワードがプロトコル上に乗ることもありませんし、SSLを使っていない環境でRSA暗号化するオーバーヘッドが要らなくなります。
RSA公開鍵に関する設定
SSL を利用しない場合にクライアントがパスワードをRSAで暗号化するための公開鍵は、ローカルにあるファイルを指定する (--server-public-key-path オプション)か、認証時にサーバーから自動取得する (--get-server-public-key オプション) 事ができます。
自動取得を有効にすると、サーバーになりすました攻撃者が自分の RSA 公開鍵を送りつけることで生パスワードを得ることができるようになります。パフォーマンスを考えてもラウンドトリップが1回ふえることになります。なので個人的には --server-public-key-path オプションをお勧めします。
なりすましサーバーにSSL接続してしまった場合にも生パスワード送信してしまうので、SSLを使わない場合は --ssl-mode=DISABLED も設定しておくと良いでしょう。
ただし、繰り返しになりますが、なりすまされてる時点でリレー攻撃可能なので、生パスワードがもれなかったらOKというわけではありません。
@methane
Go のライトバリアに関するバグを修正した話
Goのランタイムのバグを踏んで解決しました。解決までの過程を記事にします。
同じようなランタイムのバグを踏んで、小さい再現コードを作れない場合の参考にしてください。
自分のプログラムを疑う
あるSlackチャンネルで Go で書かれたサーバーのクラッシュが話題になっているのを見つけました。その時に共有してもらったトレースバックです。
runtime: pointer 0xc007b8af97 to unused region of span span.base()=0xc004000000 span.limit=0xc004002000 span.state=1
fatal error: found bad pointer in Go heap (incorrect use of unsafe or cgo?)
runtime stack:
runtime.throw(0xc046ca, 0x3e)
/usr/local/Cellar/go/1.11.2/libexec/src/runtime/panic.go:608 +0x72 fp=0xc0001dff00 sp=0xc0001dfed0 pc=0x42bf02
runtime.findObject(0xc007b8af97, 0x0, 0x0, 0xc005eb4780, 0x7f3d1915b7b8, 0x5)
/usr/local/Cellar/go/1.11.2/libexec/src/runtime/mbitmap.go:399 +0x3b6 fp=0xc0001dff50 sp=0xc0001dff00 pc=0x413bf6
runtime.wbBufFlush1(0xc000047900)
(長いバージョン)
エラーメッセージに "incorrect use of unsafe or cgo?" って言われてるので、まずはそれを疑います。
cgoは使っていませんでした。 unsafe は使わないようにビルドするのは大変なので、コードをチェックアウトして怪しいところを探します。 プロジェクトのコードには見当たりません。vendoringしているコードにはたくさんありますが、このプログラムで実際に利用されてそうな部分で怪しいものはありませんでした。
また、 race はすでに疑っていて、 -race オプション付きで見つけたレースコンディションを全て潰したあとだったようです。
これでランタイムバグの可能性が高くなってきました。
修正済みバグの可能性と、最近のリグレッションの可能性を調べるため、Go 1.11.4 と Go 1.10.5 で試してもらいました。 1.11.4 ですぐに再現し、 1.10.5 では再現しなかったそうです。 もちろん再現確率が違うだけの可能性も残ってるので、リグレッションだと確定したわけではありません。
Goのデバッグ機能を利用して原因特定を試みる
時系列的には上と同時になりますが、Goが標準で持っているデバッグ機能をつかって原因特定できないか試行錯誤をします。
まず大事なのは、スタックトレースとコードを読みクラッシュした状況を理解することです。
今回のケースは、ライトバリアの実装の中で（性能のために）一旦バッファリングしていたポインタを処理する前に有効な（ヒープ内を指している）ポインタかどうかチェックしている箇所で、無効なポインタを見つけたというものです。
悪いポインタがバッファの中から見つかっているために、そのポインタがどの変数に書かれていたのかとか、どのコードによって書かれたのかがわかりません。そこで試してもらったのが、 GODEBUG 環境変数のうち invalidptr=0 と GODEBUG=gcstoptheworld=1 です。
invalidptr=0 を使うと、このポインタのチェックがなくなります。それでクラッシュしなくなれば、問題解決に時間がかかったときのワークアラウンドになります。クラッシュすれば、今度はその悪いポインタが入っている変数を特定するヒントが得られる可能性が高いです。
gcstoptheworld=1 はコンカレントGC自体を無効にするもので、ライトバリアが使われなくなるので同じく悪いポインタを利用している箇所の近くでクラッシュすることが期待できます。
結果として、どちらのオプションを使ってもクラッシュしなくなりました。ここまでの状況を整理した上で、一旦バグ報告しておきました。
https://github.com/golang/go/issues/29362
ローカルでの再現できるようにする
そろそろ手詰まり感が出てきました。腰を落ち着けて、自分で自由に使える再現環境を作ります。
docker-compose を使った開発環境構築手順を教えてもらい、現象を再現できるようになるまで試験環境との差異を調べて減らしていきます。ログの量を同じにしたところで、１日に数回クラッシュをさせられるようになりました。
反省点として、これは手詰まりになる前にさっさとやっておくべきでした。
print & throw デバッグ
runtime.wbBufFlush1 はライトバリア・バッファの中のポインタを処理する関数なので、ライトバリア・バッファにポインタを書き込む場所を探します。 runtime/mwbbuf.go はたった311行の小さいコードなので、すぐに (*wbBuf).putFast() という関数が見つかりました。ここに、 fatal error の原因になっているチェックと throw を仕込んでみます。
runtime: bad pinter: 0xc007435e93
fatal error: XXXXXX
runtime stack:
runtime.throw(0xbeaeb3, 0x6)
/home/ubuntu/local/go/src/runtime/panic.go:608 +0x72
runtime.(*wbBuf).putFast(0xc00003b290, 0xc007435e93, 0xc007435e93, 0x7f4b766b6d88)
/home/ubuntu/local/go/src/runtime/mwbbuf.go:143 +0x1f8
runtime.bulkBarrierBitmap(0xc0038a6fd8, 0xc0038a6fd8, 0x8, 0x0, 0xc19258)
/home/ubuntu/local/go/src/runtime/mbitmap.go:682 +0x12d
runtime.newproc1(0xc194f0, 0xc0002c8708, 0x8, 0xc00222e780, 0x7f1edd)
/home/ubuntu/local/go/src/runtime/proc.go:3373 +0x441
runtime.newproc.func1()
/home/ubuntu/local/go/src/runtime/proc.go:3309 +0x4f
runtime.systemstack(0x0)
/home/ubuntu/local/go/src/runtime/asm_amd64.s:351 +0x66
runtime.mstart()
/home/ubuntu/local/go/src/runtime/proc.go:1229
goroutine 66219 [running]:
runtime.systemstack_switch()
/home/ubuntu/local/go/src/runtime/asm_amd64.s:311 fp=0xc0002c86b0 sp=0xc0002c86a8 pc=0x45bb70
runtime.newproc(0xc000000008, 0xc194f0)
/home/ubuntu/local/go/src/runtime/proc.go:3308 +0x6e fp=0xc0002c86f8 sp=0xc0002c86b0 pc=0x43750e
XXX/game/connection.Keep(0x7435e93)
これで、プロジェクトの connection.Keep 関数から runtime.newproc が呼び出され、そこから bad pointer がライトバリア・バッファに書き込まれていることがわかります。
また、よくみてみると、 bad pointer の壊れている下位バイトが、 Keep 関数の引数と完全に一致していますね。
throw を仕込む前の完全なスタックダンプ（クラッシュしたgoroutine以外の全部のgoroutineが、引数付きで書き出される）を見直してみると、さらに面白い事がわかりました。
runtime: pointer 0xc00659e432 to unused region of span span.base()=0xc004000000 span.limit=0xc004001f80 span.state=1
fatal error: found bad pointer in Go heap (incorrect use of unsafe or cgo?)
runtime stack:
runtime.throw(0xc0f417, 0x3e)
/home/ubuntu/local/go/src/runtime/panic.go:608 +0x72 fp=0x7ff10e99fd98 sp=0x7ff10e99fd68 pc=0x42dec2
runtime.findObject(0xc00659e432, 0x0, 0x0, 0xc004ab0180, 0x7ff10d5f3e70, 0x1)
...
goroutine 29115 [runnable]:
XXX/game/connection.Keep.func1(0xc00659e432)
XXX/game/connection/connection.go:22 fp=0xc0044a97d8 sp=0xc0044a97d0 pc=0x7f1ff0
runtime.goexit()
/home/ubuntu/local/go/src/runtime/asm_amd64.s:1333 +0x1 fp=0xc0044a97e0 sp=0xc0044a97d8 pc=0x45dc51
created by XXX/game/connection.Keep
XXX/game/connection/connection.go:22 +0x3d
bad pointer のアドレスと Keep.func1 の引数が完全に一致しています。 Keep 関数のコードを見てみましょう。
func Keep(playerID int32) {
go func() { // この無名関数が Keep.func1
err := updateAliveTime(playerID)
if err != nil {
logger.Errorf("Failed to keep connection. err=[%v]", err)
}
}()
}
なんとなく、スタックに残っていたポインタ (64bit) の下位 32bit を int32 の変数で上書きして bad pointer が生成されてそうなのがわかります。とはいえ、 int32 の変数がある場所をポインタとして扱っているのはコンパイラかランタイムのどちらかのバグのはずです。
ここまで追い詰めたら、この部分に詳しい人ならすぐに解析できるでしょう。一旦ここまでをまとめて報告しておきます。
コードリーディング＆バグ修正
ここまでくれば待っていても誰かが直してくれると思いますが、クリスマスを過ぎてしまって欧米の開発者は holiday に入ってしまっている時期だし、何より楽しいので、 newproc ... putFast までのコードを読んでいきます。
newproc1 が新しい goroutine のための G オブジェクトを用意し、親 goroutine のスタックから新しい goroutine のスタックに最初の関数の引数をコピーした上で、ライトバリアが有効なら bulkBarrierBitmap を呼び出しています。 bulkBarrierBitmap は渡されたビットマップを使ってメモリ中のポインタをライトバリア・バッファに putFast していきます。
本来なら、 Keep.func1 の引数は（クロージャ変数の） playerID int32 一つだけなので、 putFast が呼び出されるはずがありません。 bulkBarrierBitmap の呼び出しの前に print を仕込んでビットマップの内容を表示してみます。すると、 Keep.func1 は引数の長さが１ワードなのに、引数のビットマップは長さが 0 になっていました。
このスタック用のビットマップに関連するコードを読んでみると、該当するスタックの中にポインタが１つもない時は空のビットマップが使われるようでした。なので、 bulkBarrierBitmap はオーバーランして別のデータ（多分実行バイナリ上で隣に配置された別のビットマップ）を参照してしまい、int32 の変数が入っている箇所を間違えて処理しているようです。
bulkBarrierBitmap を呼び出す前にビットマップの長さが 0 でないかテストする事で問題が解消することを確認し、報告しました。
https://github.com/golang/go/issues/29362#issuecomment-449964832
パッチ送信＆再現コード作成
runtime の他の場所で似たことをしている場所を探し、自分の書いた if 文が他の場所と(> 0 か != 0 かのスタイルまで)同一であることを確認した上で、 Gerrit にパッチを送信します。
https://go-review.googlesource.com/c/go/+/155779
また、レビューアーが確認できるように、クラッシュの小さい再現コードも作ってみます。ライトバリアが常に有効になるように、ヒープ上にポインタ変数をたくさん作った上で runtime.GC() をループで呼び出します。また、スタック上に残っていたゴミポインタと int32 の値の合体で偶然 bad pointer を作るのでなく、意図的に bad pointer を作った上で、それを整数型の引数として関数を呼び出します。
残る再現条件は、長さ0のビットマップをオーバーランしたときにたまたまその場所のビットが1になっていることなのですが、この条件は Go プログラムで意図的に作り出すことが難しい。確率を上げるためにとりあえず引数を１つではなく４つにしてみたら、あっさり再現できました。
https://gist.github.com/methane/b61dcfb504d54de5bced1c6e3209a91d
理想的にはこの再現コードをリグレッション・テストに落とし込むなり、 newproc1 に対するユニットテストが書ければ完璧なのですが、この辺は Go のプログラムから直接呼び出されるのではなく Go コンパイラが呼び出しコードを生成する部分でテストが難しいので今後レビューアーと相談します。
@methane
Google Assistant Service プログラミング事始め
前回の記事では Google Assistant Library ベースのプログラミングを通じて Google アシスタントの各機能を取り回す試みを行いました。今回はもうひとつの Google Assistant SDK である Google Assistant Service に目を向けてみます。
Google LLC は Google Assistant SDK for devices として「Google Assistant Library」「Google Assistant Service」の二種類のセットを提供しています。前者は高水準で稼働環境は狭め、後者は低水準で広範な稼働環境に対応しており、この周到な構成に Google の本気度が窺えます。現時点では一日あたりのリクエスト数に制限はあるものの個人でも無償で利用できることが大きな魅力です。
Google Assistant Service と稼働環境
前回も引用した Google Assistant Library と Google Assistant Service の比較表を再掲します。（2018年12月時点の公式記事より）
Google Assistant Service の最大の特長は、このように gRPC 対応のプラットフォーム＋対応言語環境全般で利用可能であることです。現時点では Google Assistant Library ほどには多機能ではないものの、稼働環境が広く Windows PC や Mac はもとより小振りで消費電力が小さく IoT フロントエンドとして有用な Raspberry Pi Zero / Zero W 系ボードも Google アシスタントクライアントとして利用できることに関心を誘われます。
Google Assistant Service と Google Assistant Library の機能面での違いは SDK 全体のリリースノートを追うことで手早く俯瞰できます。
両者の機能差は今後変化する可能性がありますが、個人的には 2018年12月時点で Google Assistant Service 側にはない要素のうち実用面とのかねあいにおいて以下の三点に留意しています。
- Google Assistant Library とは異なりウェイクワードの待機・検知に対応していない
- ニュースの読み上げや Google Podcasts に未対応
- アラームに未対応 （リマインダは設定可能）
なお、上記 1. は外部の Hotword Detector との連携（後述）によりある程度補うことが可能です。
※余談ながら、Google Home デバイス実機とは異なり今のところ Google Assistant SDK ベースのプログラムの所作に google-home-notifier を絡ませることはできません。たしかに 8009 番ポートを使ったキャスト機構にはハードウェア側要件としての印象が強いものの、google-home-notifier を あち こち で利用しているファンとしてはちょっと残念です。
pushtotalk.py プログラムのこと
Google Assistant Service をセットアップ後の googlesamples/assistant/grpc/ フォルダには「pushtotalk.py」プログラムが配置されます。
このプログラムは名前の示すように Google Assistant Library に含まれる「hotword.py」とは異なり、ウェイクワード（ホットワード）の音声ではなく 'Press Enter to send a new request...' の CUI メッセージを添えた click.pause() API で物理的なトリガーを待って Google アシスタントとの対話を開始する内容で実装されています。
セットアップずみの SDK ディレクトリ下での pushtotalk.py の実行方法は以下の要領です。引数で指定したプロジェクト ID とモデル ID はホスト側へ記憶され、変更の必要がなければ次回以降は省略可能です。
$ pwd
/home/t/wk/GoogleAssistant
$ ls
env
$ source env/bin/activate
(env) $ googlesamples-assistant-pushtotalk --project-id [設定ずみのプロジェクトID] --device-model-id [設定すみのモデルID]
pushtotalk.py を手元の複数の環境で実行した様子の動画を以下に示します。
|
Windows |
Mac |
|
Linux （32bit） |
Raspberry Pi 3 Model B+ |
|
Raspberry Pi Zero W |
|
|
上の動画のRaspberry Pi 3 Model B+ / Zero W には手持ちの以下の以下のマイクとスピーカーを写真の要領で接続しています。
|
今回は、前回の hotword.py と対照的なこの pushtotalk.py を試作の下敷きとします。
Hotword Detector について
前掲の Google Assistant Service 側未対応の機能のうち、実用上の影響がもっとも大きいのはウェイクワードの待機・検知ができないことでしょう。Google Assistant Library プログラムにおいては Google Home デバイスと同様にハンズフリーでアシスタントとの応酬が可能であることを考えあわせると淋しく感じられますが、この点は外部の Hotword Detection ソフトウェアを併用することで補うことができます。
ただし、外部の Hotword Detector との連携は Google アシスタントネイティブでのウェイクワードサポートではなく、あくまでも Assistant API を呼び出すためのトリガーを外側に用意する手立てに他ならないため以下の注意が必要です。
- ウェイクワード設定の柔軟性や認識精度はすべて Detector 側の要件である
- Google アシスタントの発話中にウェイクワードで介入することはできない
こういった事情を理解した上で Hotword Detector を併用すれば、間口の広い Google Assistant Service を様々な環境でより便利に利用することができるでしょう。
Porcupine と Snowboy
現時点でのスマートスピーカー向きの代表的な Hotword Detector として、Picovoice （カナダ系）による Porcupine と、 KITT.AI （中国系） による Snowboy が挙げられます。後者はすでに随所で取り上げられていますね。どちらも機械学習に基づく精度の高さ・低負荷・マルチプラットフォーム対応・カスタマイズの柔軟性をアピールポイントとしており、後発の Picovoice は両者の比較記事を公開しています。
手元ではどちらも使い始めてまだ日が浅いのですが、今のところウェイクワードを認識する能力そのものに際立った性能差は感じておらず負荷の度合いについては未検証です。今の時点で把握している両者の一長一短を挙げてみます。
対応プラットフォームの広さ： Porcupine ◎
カスタムウェイクワードへの対応： Snowboy ◎
（クリックで大きく表示）
$ pwd
/home/t/wk/Porcupine
$ tools/optimizer/linux/i386/pv_porcupine_optimizer -r resources/ -p linux -o . -w "OK google"
手元では今のところ PC では Porcupine、Raspberry Pi では Snowboy の要領で使い分けています。下の動画はそれぞれの動作の様子です。
※ ふたつの動画でのウェイクワード検知時・対話終了時の応答音はいずれも Snowboy の resource/ ディレクトリ下の wave ファイルによるものです。これらが耳に馴染んだため Porcupine との連携においても同じ要領で使用しています
試作
前回記事での hotword.py （Google Assistant Library） ベースの試作に続き、今回は Google Assistant Service の pushtotalk.py を下敷きにプログラムを作成します。作業上の便宜から開発は PC で行いましたが、Google Assistant Service ベースなので指先に乗るサイズの Raspberry Pi Zero W ボードをはじめ広範な環境で実行可能であることに夢が広がります。オールインワンのダンボールキットも製品化されていますね。
今回はシンプルな切り口として前回の Google Assistant Library 版の各プログラムと同じ動きをするものを作ってみることにしました。Google Assistant Serivice プログラミングは奥が深くまだまだ習作の段階ではありますが、事始めとして取り組んだ内容を以下に掲載します。
1. 指定テキストに基づく音声合成と読み上げ
テーマ： Google アシスタントの音声合成機能を単体で利用する。いわゆる Text to Speech。
［前回 Google Assistant Libray 版試作へのリンク］
内容
デモ： 動画 27秒
（前回分）
考えたことなど
(env)t@PC-533:~/wk/GoogleAssistant$ ./textinput.sh
INFO:root:Connecting to embeddedassistant.googleapis.com
: こんにちは
<you> こんにちは
<@assistant> こんにちは、TAnabeさん
どうしましたか？
: 今何時？
<you> 今何時？
<@assistant> 時刻は、17:25です。
: 今晩、雨降る？
<you> 今晩、雨降る？
<@assistant> 夜は、雨の心配はないでしょう
今夜の山口は雨ではないでしょう。 気温10度、晴れるでしょう。
---
（weather.com でもっと見る）
:
083| def iter_assist_requests():
084| config = embedded_assistant_pb2.AssistConfig(
085| audio_out_config=embedded_assistant_pb2.AudioOutConfig(
086| encoding='LINEAR16',
087| sample_rate_hertz=16000,
088| volume_percentage=0,
089| ),
090| dialog_state_in=embedded_assistant_pb2.DialogStateIn(
091| language_code=self.language_code,
092| conversation_state=self.conversation_state,
093| is_new_conversation=self.is_new_conversation,
094| ),
095| device_config=embedded_assistant_pb2.DeviceConfig(
096| device_id=self.device_id,
097| device_model_id=self.device_model_id,
098| ),
099| text_query=text_query,
100| )
109| text_response = None
110| html_response = None
111| for resp in self.assistant.Assist(iter_assist_requests(),
112| self.deadline):
113| assistant_helpers.log_assist_response_without_audio(resp)
114| if resp.screen_out.data:
115| html_response = resp.screen_out.data
116| if resp.dialog_state_out.conversation_state:
117| conversation_state = resp.dialog_state_out.conversation_state
118| self.conversation_state = conversation_state
119| if resp.dialog_state_out.supplemental_display_text:
120| text_response = resp.dialog_state_out.supplemental_display_text
121| return text_response, html_response
149| if len(resp.audio_out.audio_data) > 0:
150| if not self.conversation_stream.playing:
151| self.conversation_stream.stop_recording()
152| self.conversation_stream.start_playback()
153| logging.info('Playing assistant response.')
: 今何時？
<you> 今何時？
0
1600
1600
（引用中略）
1600
1600
244
<@assistant> 時刻は、18:43です。
（mp3 形式へ変換したもの）
import sounddevice as sd
:
text_response = None
html_response = None
s = sd.RawStream(
samplerate=audio_helpers.DEFAULT_AUDIO_SAMPLE_RATE,
dtype='int16',
channels=1,
blocksize=audio_helpers.DEFAULT_AUDIO_DEVICE_BLOCK_SIZE)
for resp in self.assistant.Assist(iter_assist_requests(),
self.deadline):
assistant_helpers.log_assist_response_without_audio(resp)
s.write(resp.audio_out.audio_data)
s.start()
if resp.screen_out.data:
html_response = resp.screen_out.data
if resp.dialog_state_out.conversation_state:
conversation_state = resp.dialog_state_out.conversation_state
self.conversation_state = conversation_state
if resp.dialog_state_out.supplemental_display_text:
text_response = resp.dialog_state_out.supplemental_display_text
return text_response, html_response
:
ソースコード
- pushtotalk_tts.py - github.com/mkttanabe
2. 利用者の発話内容をテキストへ変換
テーマ： Google アシスタントの音声認識機能を単体で利用する。いわゆる Speech to Text。
［前回 Google Assistant Libray 版試作へのリンク］
内容
デモ： 動画 41秒
（前回分）
考えたことなど
138| for resp in self.assistant.Assist(iter_log_assist_requests(),
139| self.deadline):
140| assistant_helpers.log_assist_response_without_audio(resp)
141| if resp.event_type == END_OF_UTTERANCE:
142| logging.info('End of audio request detected.')
143| logging.info('Stopping recording.')
144| self.conversation_stream.stop_recording()
145| if resp.speech_results:
146| logging.info('Transcript of user request: "%s".',
147| ' '.join(r.transcript
148| for r in resp.speech_results))
ソースコード
- PicovoiceWithGoogleAssitantService_input.py - github.com/mkttanabe
- Porcupine をインストールしたディレクトリ下へ配置して実行のこと
- Porcupine/resource ディレクトリ下に前掲の ding.wav, dong.wav が必要
- デモ動画ではパラメータに "--keyword_file_paths resources/keyword_files/picovoice_linux.ppn" を指定
3. 利用者の発話内容を他言語へ連続翻訳
テーマ： Google アシスタントの 音声認識 / 文意解釈 / 言語翻訳 / 応答文生成 / 音声合成 の各機能を利用する
［前回 Google Assistant Libray 版試作へのリンク］
内容
デモ： 動画 2分30秒
（前回分）
ソースコード
- PicovoiceWithGoogleAssitantService_translate.py - github.com/mkttanabe
- Porcupine をインストールしたディレクトリ下へ配置して実行のこと
- Porcupine/resource ディレクトリ下に前掲の ding.wav, dong.wav が必要
- デモ動画ではパラメータに "--keyword_file_paths resources/keyword_files/picovoice_linux.ppn" を指定
4. 利用者の発話内容を復唱
テーマ： Google アシスタントの音声認識 / 音声合成機能を利用する
［前回 Google Assistant Libray 版試作へのリンク］
内容
デモ： 動画 39秒
（前回分）
ソースコード
- PicovoiceWithGoogleAssitantService_echo.py - github.com/mkttanabe
- Porcupine をインストールしたディレクトリ下へ配置して実行のこと
- Porcupine/resource ディレクトリ下に前掲の ding.wav, dong.wav が必要
- デモ動画ではパラメータに "--keyword_file_paths resources/keyword_files/picovoice_linux.ppn" を指定
しりとり
テーマ： Google アシスタントの音声認識 / 音声合成機能を利用する
［前回 Google Assistant Libray 版試作へのリンク］
内容
デモ： 動画 60秒
（前回分）
現時点ではプログラミングを行うための実践的な情報をあまり目にすることのない Google Assistant Library と Google Assistant Service を題材に手元で行った試みを二度に分けて紹介しました。幼児の年齢を迎えたばかりの Google アシスタントはこれからこれらの SDK とともに成長を重ねて行くことでしょう。未来へ向かう道すがらの愉しみがまたひとつ増えた思いです。
(tanabe)
Google Assistant Library プログラミングを楽しむ
Google LLC は Google Assistant SDK for devices として 「Google Assistant Library」「Google Assistant Service」 の二種類のセットを提供しています。前者は高水準で稼働環境は狭め、後者は低水準で広範な稼働環境に対応しており、この周到な構成に Google の本気度が窺えます。現時点では一日あたりのリクエスト数に制限はあるものの個人でも無償で利用できることが大きな魅力です。
Compatibility and feature support
The following table summarizes the platform compatibility requirements and the
supported features for the Google Assistant Library and the Google
Assistant Service:
Library Service
Supported architectures linux-armv7l and linux-x86_64 All gRPC platforms
Supported languages Python All gRPC languages
Hands-free activation
(Ok Google)Yes No
Audio capture and playback Built in Reference code is provided
Conversation state management Built in Reference code is provided
Timers and alarms Yes No
Playback of podcasts and news Yes No
Broadcast voice messages Yes No
Visual output (HTML5) of Assistant responses No Yes
Google Home デバイスやスマートフォンアプリを通じて Google アシスタントの存在感はどんどん大きくなっています。その一方で現時点では Google Assistant SDK プログラミングのための実践的な情報を国内外を通じてあまり見かけないことが残念に思われました。ネットの奥深くに息づいている Google アシスタント陣営の一連の機能を本 SDK ごしに柔軟に呼び出すことができればこの強力で魅力的なサービスをさらに活用できるのではないでしょうか。
- 音声認識
- 文意の解釈
- 応答文の生成
- 音声合成
- 言語翻訳
そんなわけで手元ではここしばらく Google Assistant SDK に向き合っています。今回はまず Google Assistant Library ベースでこれまでに行った調査と実験の内容を紹介します。
Google Assistant Library と稼働環境
前掲の表にも記載のあるように、今のところ Google Assistant Library の稼働環境は Python を利用可能な linux-armv7l または linux-x86_64 なプラットフォームに絞られます。周辺機器としてマイクとスピーカが必須。セットアップは下記ページからの説明にそって行えば問題ないでしょう。導入手順の詳細は随所で紹介されているためここでは省略します。
（※ スペックの上では Raspberry Pi 2 Model B/B+ も適合するかもしれません）
手元では作業用に 64bit lubuntu 環境の PC と Raspberry Pi 3 Model B+ を使っています。
hotword.py プログラムのこと
Google Assistant Library をセットアップ後の googlesamples/assistant/library/ フォルダには「hotword.py」プログラムが配置されます。実質 100行ほどの短い内容ですが、`sample` と言いながらこのプログラムを利用すればウェイクワードの検知を含め Google アシスタントとのいつものやりとりをそのまま実現することができます。抽象度が高くフロントエンドをこのようにシンプルに実装できることが Google Assistant Library の大きな特長です。
セットアップずみの SDK ディレクトリ下での hotword.py の実行方法は以下の要領です。引数で指定したプロジェクト ID とモデル ID はホスト側に記憶され、変更の必要がなければ次回以降は省略できます。
$ pwd
/home/t/wk/GoogleAssistant
$ ls
env
$ source env/bin/activate
(env) $ googlesamples-assistant-hotword --project-id [設定ずみのプロジェクトID] --device-model-id [設定すみのモデルID]
hotword.py を PC / Raspberry Pi 3 で実行した様子の動画です。ここでは個人的な好みからウェイクワードへの反応音「ポコッ」の再生をコードに加えています。
|
|
上の動画のラズパイには手持ちの以下のマイク （USB 接続） とスピーカー （3.5mm オーディオジャック接続） を写真の要領でつないでいます。
|
一連の試作においてはこの hotword.py を下敷きにすることにしました。コンパクトで見通しのよい内容でありながらアシスタントとの応酬に必要な要素の一式が収められているためカスタマイズを試みるための土台としてはまさに好適でしょう。この記事の最後の項目に Google Assistant Library プログラミングを行う上での基本的な作法をまとめています。あわせて参照して下さい。
試作
今回手がけた試作をデモ動画と素のままのソースコードを添えて以下に掲載します。
1. 指定テキストに基づく音声合成と読み上げ
テーマ： Google アシスタントの音声合成機能を単体で利用する。いわゆる Text to Speech。
内容
デモ： 動画 48秒
考えたことなど
send_text_query(query)
Sends |query| to the Assistant as if it were spoken by the user.
This will behave the same as a user speaking the hotword and making a query OR speaking the answer to a follow-on query.
Parameters: query (str) - The text query to send to the Assistant.
ソースコード
- hotword_tts.py - github.com/mkttanabe
2. 利用者の発話内容をテキストへ変換
テーマ： Google アシスタントの音声認識機能を単体で利用する。いわゆる Speech to Text。
内容
デモ： 動画 41秒
考えたことなど
ON_CONVERSATION_TURN_STARTED
ON_END_OF_UTTERANCE
ON_RECOGNIZING_SPEECH_FINISHED:
{'text': '今何時'}
ON_RESPONDING_STARTED:
{'is_error_response': False}
ON_RESPONDING_FINISHED
ON_CONVERSATION_TURN_FINISHED:
{'with_follow_on_turn': False}
61 | if (event.type == EventType.ON_CONVERSATION_TURN_FINISHED and
62 | event.args and not event.args['with_follow_on_turn']):
63 | print()
ソースコード
- hotword_input.py - github.com/mkttanabe
3. 利用者の発話内容を他言語へ連続翻訳
テーマ： Google アシスタントの 音声認識 / 文意解釈 / 言語翻訳 / 応答文生成 / 音声合成 の各機能を利用する
内容
デモ： 動画 52秒
考えたことなど
ソースコード
- hotword_translate.py - github.com/mkttanabe
4. 利用者の発話内容を復唱
テーマ： Google アシスタントの音声認識 / 音声合成機能を利用する
内容
デモ： 動画 42秒
考えたことなど
ソースコード
- hotword_echo.py - github.com/mkttanabe
しりとり
テーマ： Google アシスタントの音声認識 / 音声合成機能を利用する
内容
デモ： 動画 58秒
考えたことなど
ソースコード
- 別途
メモ： Google Assistant Library プログラミングの基本
hotword.py を通じて
前述のように Google Assistant Library のインターフェイスは抽象度が高くシンプルに扱うことができる。実ロジック 100 行程度の hotoword.py が Google Home デバイスとほぼ同等に Google Assistant と連携可能であることは興味深い。hotoword.py の内容にあらためて目を向けると、デバイス ID 等の管理情報の取り回し以外の実質的な処理は以下のごく短い内容のみであることが見てとれる。
- hotword.py#L122-L145 より
122 | with Assistant(credentials, device_model_id) as assistant: 123 | events = assistant.start() : 144 | for event in events: 145 | process_event(event)
（リファレンスより）- class google.assistant.library.Assistant(credentials, device_model_id) - developers.google.com
Client for the Google Assistant Library.
Provides basic control functionality and lifecycle handling for the Google Assistant. It is best practice to use the Assistant as a ContextManager:
with Assistant(credentials, device_model_id) as assistant:
This allows the underlying native implementation to properly handle memory management.
Once start() is called, the Assistant generates a stream of Events relaying the various states the Assistant is currently in, for example:
ON_CONVERSATION_TURN_STARTED ON_END_OF_UTTERANCE ON_RECOGNIZING_SPEECH_FINISHED: {'text': 'what time is it'} ON_RESPONDING_STARTED: {'is_error_response': False} ON_RESPONDING_FINISHED ON_CONVERSATION_TURN_FINISHED: {'with_follow_on_turn': False}See EventType for details on all events and their arguments.
- class google.assistant.library.Assistant(credentials, device_model_id) - developers.google.com
- hotword.py#L47-L66 より
47 | def process_event(event): : 56 | if event.type == EventType.ON_CONVERSATION_TURN_STARTED: 57 | print() 58 | 59 | print(event) 60 | 61 | if (event.type == EventType.ON_CONVERSATION_TURN_FINISHED and 62 | event.args and not event.args['with_follow_on_turn']): 63 | print() 64 | if event.type == EventType.ON_DEVICE_ACTION: 65 | for command, params in event.actions: 66 | print('Do command', command, 'with params', str(params))（リファレンスより）- ON_CONVERSATION_TURN_STARTED - developers.google.com
Indicates a new turn has started.
The Assistant is currently listening, waiting for a user query. This could be the result of hearing the hotword or start_conversation() being called on the Assistant.- start_conversation() - developers.google.com
Manually starts a new conversation with the Assistant.
Starts both recording the user’s speech and sending it to Google, similar to what happens when the Assistant hears the hotword.
This method is a no-op if the Assistant is not started or has been muted.- send_text_query(query)
Sends query to the Assistant as if it were spoken by the user.
- send_text_query(query)
- stop_conversation() - developers.google.com
Stops any active conversation with the Assistant.
The Assistant could be listening to the user’s query OR responding. If there is no active conversation, this is a no-op.
- start_conversation() - developers.google.com
- ON_CONVERSATION_TURN_FINISHED - developers.google.com
The Assistant finished the current turn.
This includes both processing a user’s query and speaking the full response, if any.
- ON_CONVERSATION_TURN_STARTED - developers.google.com
ポイント
- Google Assistant との一連の応酬を開始するには google.assistant.library.Assistant クラスのインスタンスを生成し start() をコールする
- 応酬中の状況はイベントベースで捕捉可能
- 対話開始： ON_CONVERSATION_TURN_STARTED
- 対話終了： ON_CONVERSATION_TURN_FINISHED
- 後は EventType ごとに必要な処理を記述
- start_conversation() によりウェイクワードなしで Assistant との対話を開始
- send_text_query() により発話に代え任意のテキストを Assistant へ送出可能
- stop_conversation() により Assistant との対話を任意に終了
(tanabe)
