ReSpeaker Core v2を試してみる【後編】

前回のエントリからの引き続きになります。

【参考】 uepon.hatenadiary.com

今回は実際にReSpeaker Core v2を使用して見る作業を行います。

音声デバイスのテスト

ReSpeaker Core v2のOSはLinux（Debianベース）なので音声はALSAまたはPulseAudio経由で使用することになります。

ALSAのデバイステスト

まずは、ALSA経由でのオーディオテストです。arecodeコマンドとaplayコマンドで録音・再生を行います。まずは、音声デバイスが認識されているかを 確認します。

まずは録音デバイスの確認は以下のコマンドで確認します。

respeaker@v2:~$ arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: seeed8micvoicec [seeed-8mic-voicecard], device 0: 100b0000.i2s1-ac108-pcm0 ac108-pcm0-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

seeed-8mic-voicecardが見えていれば問題ありません。

続いては再生デバイスの確認は以下のコマンドで確認します。

respeaker@v2:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: seeed8micvoicec [seeed-8mic-voicecard], device 1: 100b0000.i2s1-rk3228-hifi rk3228-hifi-1 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

こちらもseeed-8mic-voicecardが見えていれば問題ありません。 正常に動作しているようです。というかこのように見えていなかったら再度インストールをし直してください。それでもだめな場合には故障も考えられます。

続いては録音と再生のテストにはいります。

まずは録音。以下のコマンドでステレオ（2ch）の録音をしてみます。（録音の停止はCtrl+Cです。いいタイミングで停止してください）

respeaker@v2:~$ arecord -Dhw:0,0 -f S16_LE -r 16000 -c 2 hello.wav
Recording WAVE 'hello.wav' : Signed 16 bit Little Endian, Rate 16000 Hz, Stereo
^CAborted by signal Interrupt...

respeaker@v2:~$ ls
bin  Desktop  hello.wav

無事に録音ができました。（ファイルが生成できただけですが） 次はこの音声ファイルを再生してみます。以下のコマンドで先程作成した録音ファイルを再生します。 音声の出力にはスピーカーが必要なのでHeadphone端子にイヤホンなどを接続して音声を聞きます。

respeaker@v2:~$ aplay -Dhw:0,1 -r 16000 -c 2 hello.wav
Playing WAVE 'hello.wav' : Signed 16 bit Little Endian, Rate 16000 Hz, Stereo

うまく聞こえましたか？ 個人的には意外と音声はっきりと録音できるような印象でした。小さい音も拾っているようです。

続いては8チャンネルの音声ファイルを録音してみます。先程の録音コマンドのオプションを-c 8に変更するだけで対応できます。 （録音の停止はCtrl+Cです。いいタイミングで停止してください）

respeaker@v2:~$ arecord -Dhw:0,0 -f S16_LE -r 16000 -c 8 hello_8ch.wav
Recording WAVE 'hello_8ch.wav' : Signed 16 bit Little Endian, Rate 16000 Hz, Channels 8
^CAborted by signal Interrupt...

とりあえずファイルの作成ができました。再生を考えてみるのですが、ヘッドホン端子では2chまでしか確認ができません。 hello_8ch.wavが生成できていますので大丈夫そうではありますが。

respeaker@v2:~$ ls
bin  Desktop  hello_8ch.wav  hello.wav

そこでX Window上のAudacityの波形表示で確認を行ってみます。 VNC Viewerなどで画面を接続し、Audacityを起動します。画面左下のメニューにもありますし、コマンドライン上からでも起動は可能です。

起動するとHELPっぽいガイドダイアログが表示されますが、それを【OK】ボタンをクリックし、

先程作成した8ch録音したファイル（hello_8ch.wav）をopenします。

チャンネルごとに録音されているのですが、7,8chだけが録音されていませんでした。MICも6ch分しかみえてないので、問題はなさそうですが…後ほど調べることにします。

とりあえず、音声の録音再生に関しては概ね問題はなさそうです。 これでALSA経由での確認は無事できました。

PulseAudioのデバイステスト

続いてはPulseAudioでのテストになります。 まずはプロセスを眺めてPulseAudioが動作しているか確認します。以下のコマンドで表示が行われればOKです。

respeaker@v2:~$ ps aux | grep pulse | grep -v grep
respeak+   965  0.0  0.7 102048  7568 ?        S<sl 02:46   0:00 /usr/bin/pulseaudio --daemonize=no

続いては録音。以下のコマンドでステレオ（2ch）の録音を行います。（録音の停止はCtrl+Cです。いいタイミングで停止してください）

respeaker@v2:~$ parecord --channels=8 --rate=16000 --format=s16le hello2.wav
Warning: failed to write channel map to file.
^C

ALSA経由での録音も可能です。

respeaker@v2:~$ arecord -v -f cd hello3.wav
Recording WAVE 'hello3.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
ALSA <-> PulseAudio PCM I/O Plugin
Its setup is:
  stream       : CAPTURE
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 44100
  exact rate   : 44100 (44100/1)
  msbits       : 16
  buffer_size  : 22050
  period_size  : 5512
  period_time  : 125000
  tstamp_mode  : NONE
  tstamp_type  : GETTIMEOFDAY
  period_step  : 1
  avail_min    : 5512
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 22050
  silence_threshold: 0
  silence_size : 0
  boundary     : 1445068800
^CAborted by signal Interrupt...

両方とも録音でき、ファイルも生成されました。

respeaker@v2:~$ ls
bin  Desktop  hello2.wav  hello3.wav  hello_8ch.wav  hello.wav

再生も行われています。（8chのファイルも2ch分はイヤホンで聞くことはできます。）

respeaker@v2:~$ aplay hello2.wav
Playing WAVE 'hello2.wav' : Signed 16 bit Little Endian, Rate 16000 Hz, Channels 8
respeaker@v2:~$ aplay hello3.wav
Playing WAVE 'hello3.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo

これで音声系のテストは終了です。問題なさそうです。

AVSの導入

基本的には以下を参考にしていきます。

【参考】 github.com

respeaker@v2:~$ pip install avs

インストールされるパッケージは以下のものになります。

Installing collected packages: hpack, hyperframe, enum34, h2, hyper, idna, certifi, urllib3, chardet, requests, six, python-dateutil, backports-abc, futures, singledispatch, tornado, click, avs

実行スクリプトは~/.local/binに格納されます。（alexa-audio-check, alexa-auth, dueros-auth, alexa-tap, alexaなど）

インストール後のavsパッケージ経由での録音デバイスのチェックをします。以下のコマンドを入力して数値が出ていれば問題ない様です。

respeaker@v2:~$ ~/.local/bin/alexa-audio-check

続いてはAVSを使用するために、Amazon.comの認証を行います。ここでGUIが必要になってきます。VNC Viewerとブラウザ（デフォルトではFirefoxがインストールされているので別途インストールをする必要はありません）X上のコンソールから以下のコマンドを実行します。

respeaker@v2:~$ ~/.local/bin/alexa-auth

実行すると…

ブラウザが起動して、【amazon alexa】、【baidu dueros】、【custom】の選択が表示されるので、【amazon alexa】をクリックします。

クリックするとAmazon.comへのログイン画面表示されるのでログインをします。（注）amazon.co.jpではなくamazon.comのユーザでログインをしてください。メールアドレスは同じでも問題ないですが、パスワードは.comのものを使用してください。.co.jpと.comのパスワードを同じものを使っているとトラブルが発生するかも

正常に認証されると以下のような表示になります。

これで認証は完了です。

では、サンプルスクリプトを動作させます。

サンプルスクリプトの実行

サンプルを使って機能の確認を行います。

• Alexa-tap.py : 　キーボードのEnterキーでウェイクアップするAlexaのサンプル
• ns_kws_alexa.py :　ウェイクワードAlexaで起動するサンプル
• ns_kws_alexa_with_light.py :　ボード上のLEDを使用したウェイクワードAlexaで起動するサンプル

Alexa-tap.pyのサンプル

すでにインストールしたパッケージにAlexa-tapは含まれているので以下のコマンドで実行ができます。

respeaker@v2:~$ ~/.local/bin/alexa-tap

実行するのですが、コンソール上に以下のようにINFO:avs.alexa:on_readyと表示されるまで待機します。

表示されるとEnterキーの待機になるのでそこでEnterキーを押します。 Enterキーを押したらトークが可能になるので話かけてください。

念の為に書きますが、英語でよろしくです。ウエイクワードは不要なので、Enterキーを押して質問を話しかけるという感じでOKです。

反応速度も割と早く返答来ます。

ウェイクワードAlexaで起動するサンプル

以下のコマンドを実行してみます。

respeaker@v2:~$ sudo apt install libatlas-base-dev
respeaker@v2:~$ git clone https://github.com/respeaker/respeaker_v2_eval.git
respeaker@v2:~$ cd respeaker_v2_eval
respeaker@v2:~/respeaker_v2_eval$ pip install --no-deps snowboy*.whl
respeaker@v2:~/respeaker_v2_eval$ pip install webrtc_audio_processing*.whl
respeaker@v2:~/respeaker_v2_eval$ pip install voice-engine
respeaker@v2:~/respeaker_v2_eval$ python ns_kws_alexa.py

起動すると…画面が化ける…プログラムを終了させてももとに戻らないという…

動作も一回目はするのですが、その後は動作しなくなるという…

ちょっと飛ばして…次のサンプルを実行してみます。

ボード上のLEDを使用したウェイクワードAlexaで起動するサンプル

以下のコマンドを実行してみます。

respeaker@v2:~/respeaker_v2_eval$ pip install pixel-ring
respeaker@v2:~/respeaker_v2_eval$ python ns_kws_alexa_with_light.py

こちらも前回の起動すると…画面が化ける…プログラムを終了させてももとに戻らないという…

動作も一回目はするのですが、その後は動作しなくなるという…

かなり心が折れてきましたが、もう少し頑張ってみます。

もう少し頑張る

これらのサンプルはうまく行かなかったので違う方法で対応をしようと思います。 先程インストールを行ったパッケージの中にvoice-engineがあったので、これのGithubを検索してみました。

github.com

そのドキュメントでsnow-boyの検出プログラムがあったので、このファイルを作成しテストしてみることにしました。

【snow-boy.py】

import time
from voice_engine.kws import KWS
from voice_engine.source import Source

src = Source()
kws = KWS()
src.link(kws)

def on_detected(keyword):
    print('found {}'.format(keyword))
kws.on_detected = on_detected

kws.start()
src.start()
while True:
    try:
        time.sleep(1)
    except KeyboardInterrupt:
        break
kws.stop()
src.stop()

これを実行してみると…うまく動作していました。とりあえずは、ウェイクワードの検出処理はうまくいっているのかなと思います。

respeaker@v2:~$ python snow_boy.py
['arecord', '-t', 'raw', '-f', 'S16_LE', '-c', '1', '-r', '16000', '-D', 'default', '-q']
found 1
found 1
found 1
found 1
found 1

さらにGithubのソースをcloneして中身をみるとexamplesディレクトリの中にkws_doa_alexa_respeaker_v2.pyというファイルがありました！ もしや！と思い、これを実行してみます。

respeaker@v2:~$ git clone https://github.com/voice-engine/voice-engine.git
respeaker@v2:~$ cd voice-engine/examples/
respeaker@v2:~/voice-engine/examples$ python kws_doa_alexa_respeaker_v2.py

Alexa側の応答の音声が小さいですが、一応動画を…

youtu.be

とりあえず動作しました。ボード上のLEDも連動して点灯して、かつ音声の方向も検出しています。 一応、動きました！

終わりに

最後は少し微妙なところもありましたが、概ねハマることなくできたので品質も上がってきているみたいですね。 他の機能にもチャレンジしてみたいところですが、最近は時間がなかなか取れず…。Groveコネクタの処理はなんとか手をつけたいと思います。

【参考】

www.switch-science.com

github.com

uepon.hatenadiary.com

ReSpeaker Core v2を試してみる【前編】

ReSpeaker Core v2を使わせて頂く機会がありましたので体験記をメモ。SeeedさんのReSpeakerシリーズといえば…

uepon.hatenadiary.com

という辛い思い出もあったので、今回はどうなっているのか。かなり気になるところです。（まあ名前にv2とついているので実は安心していたりします。）

今回使用するデバイスは

ReSpeaker Core V2.0 - Speech Recognition - Seeed Studio

wiki.seeedstudio.com

となります。スイッチサイエンスさんでも販売しているので問題ありません！（何が？）

www.switch-science.com

ドキュメントを見ながら設定をしてみる

このデバイスのスペックに関してはSeeedさんのページを見てもらえればいいかなと思いますが代表的なスペックとしては

• OS DebianとAndroidのサポート
• CPU Quad-Core Cortex-A7,up to 1.5GHz（Rockchip RK3229）
• GPU Mali400MP, Support OpenGL ES1.1/2.0（現状ではすべての機能が使用できるわけでは無いらしい）
• Memory 1GB RAM
• Grove I2C（DigitaL）Socket x 1
• Audio 6 Microphone Array、3.5mm Audio Jack
• Networks WiFi b/g/n;　BLE 4.0;　Ethernet
• Others 12 x RGB LEDs、8 GPIO pins

こんなところかなと。前回使用していたReSpeaker 4-Mic Array for Raspberry PiはRaspberryPiに接続するのが前提のHATなデバイスでしたが、今回のデバイスはデバイス そのものにOSをインストールする形です。オンボード上FlashにOSをインストールすることもできますし、MicroSDカードにOSを入れることもできます。

ピンアサインなどは以下を参照してください。（というかこのページだけでも完結しそうな気もします）

wiki.seeedstudio.com

Githubのドキュメントページへ

基本的には以下のドキュメントページの順におっていけばいい感じでした。

github.com

microSDカードにOSイメージを焼き込む

まずはインストールするOSのイメージをダウンロードし、SDカードに書き込みます。公開されているOSイメージは【iot / lxqt】と【flasher / sd】組み合わせた種類があります。

• iot　…　GUIなし

• lxqt　…　GUIあり

• flasher　…　オンボードFlashへインストールするタイプ

• sd　…　SDカードにOSイメージを配置するタイプ

これらの組み合わせを考えることになりますが、公式ページではlxqtとsdの組み合わせのイメージがおすすめされていました。

以下のサイトから該当するイメージをダウンロードします。

https://ibschoolnz-my.sharepoint.com/personal/baozhu_zuo_vace_co/Documents/Forms/All.aspx?slrid=5ff38e9e-60ad-0000-1073-70d262a67058&RootFolder=%2Fpersonal%2Fbaozhu_zuo_vace_co%2FDocuments%2Frespeaker&FolderCTID=0x0120009E00B7C13B0C174BA0DB998ABD011E0F

URLにアクセスするとOneDriveのファイル共有ページへ移動します。

このなかから新しい日付のフォルダを選択して（このエントリー現在は20180801が最新なのでそれを選択）

今回はこちらのイメージファイルをダウンロードして使用します　→　respeaker-debian-9-test-lxqt-sd-20180801-4gb.img.xz

Etcherでイメージを焼き込みましょう。(Win32DiskImagerでも大丈夫だと思います)

Etcherを起動して…

イメージファイルと書き込み先のSDカードを指定すればOKです！【Flash!】ボタンをクリックします。

すると、書き込みがスタートします。

完了すると以下のような画面になるのでそれそ本体のmicroSDカードのコネクタに挿します。SDカード挿す向きには注意してください。

この向きで挿入します。

ReSpeakerを起動する

micoroSDを挿入したら電源を入れます。microUSBUSBケーブルはOTGと書かれてる方に挿します。隣にPWR_INと書かれたのmicroUSBコネクタに挿しても電源供給は行われますが、WiFiの設定を行うためにはまずはシリアル接続可能なOTG側で接続してください。

microSDとmicroUSBを挿して起動を行い、USER1のLEDが安定して点滅をすると接続可能になります。ターミナルソフト（Teratermなど）でシリアル接続を行います。 Windows10、Mac、Linuxでは特にドライバをインストールする必要はありませんが、Windows7などではドライバが必要になります。以下からドライバをダウンロードしてインストールを行ってください。以下はインストールが終わったところからの作業になります。

github.com

Teratermを起動したら、新規接続のダイアログから【Serial】のラジオボタンを選択し、接続してから現れたシリアルデバイスをプルダウンから選択して【OK】ボタンをクリックします。

【OK】ボタンをクリックするとダイアログは消えますが、ウインドウには何も表示されません。

ここでリターンキーなどを押すとログインできるようになります。

デフォルトのログインのユーザネームとパスワードはともにrespeakerなのでそれでログインを行います。

無事にログインできました。

WiFiの設定

では、WiFiの接続設定を行います。以下のコマンドを入力します。 sudの権限で実行するので、パスワード（respeaker）を入力します。

respeaker@v2:~$ sudo nmtui

【パスワード入力待ちの画面】

すると以下のような画面になります。

このメニュー上で【Activate a connection】を選択して、Enterキーを押します。

すると、WiFiのアクセスポイント名が一覧になってみえるので、接続するアクセスポイントを選択し、パスワードを入力します。

パスワードを入力すると接続が行われます。選択したアクセスポイントの左側に【＊】が付きます。Tabキーでメニューの【Back】までカーソルを持ってきてEnterキーを押します。

メインメニューに戻ったら【Quit】を選択して設定ツールを終了します。

では、IPアドレスが取得できているか確認しましょう。以下のコマンドでIPアドレスを確認します。

respeaker@v2:~$ ip a

すると、成功していれば以下のような表示がされます。インターフェースのwlan0にアドレスが設定されていれば大丈夫です。

これでWiFiの設定は完了です。

IP経由での接続設定

sshでの接続

先程調べたIPアドレスでssh接続をしてみます。先程は【Serial】でしたが今回は【TCP/IP】にラジオボタンを設定し、確認したIPアドレスを入力して【OK】ボタンをクリックします。

ユーザIDとパスワードを入力してログインをします。【OK】ボタンをクリック。

無事にログインができました！

VNCでの接続

使用したOSのイメージがlxqtのものを使用していればXも設定されています。VNCで接続すればそのままで画面接続ができます。 VNCのクライアントがすでにインストールされていれば、そちらを使用してもらえればいいのですが、もし入れていないようであれば Chrome拡張のVNCViewerをしようしても問題はありません。Chrome拡張を以下のリンクからインストールしてアプリを起動してください。

[https://chrome.google.com/webstore/detail/vnc%C2%AE-viewer-for-google-ch/iabmpiboiopbgfabjmgeedhcmjenhbla?hl=en:embed: cite]

起動すると以下のようなダイアログ表示されるのでIPアドレスを設定して【Connect】ボタンをクリックします。

接続中に通信が暗号化されていない旨のメッセージが表示されますが、今回はこのまま進めていきます。【Connect】ボタンを再度クリックします。

パスワードを入力して【OK】ボタンをクリックします。

無事に接続ができました。

特にX Windowをつかわなければならないと言うわけではないのですが、AVS(Alexa Voice Service) などの認証にGUIが必要になることもあるので、GUIはあると便利だと思います。

蛇足

VNCはインストールしたくないなあということもあったので、xrdpをインストールすることでWindowsデフォルトのリモートデスクトップ接続でもGUI接続可能じゃないかと思いました。ということでxrdpをインストールしてみます。以下のコマンドでOKなはずなのですが…

respeaker@v2:~$ sudo apt update
respeaker@v2:~$ sudo apt install xrdp
respeaker@v2:~$ sudo systemctl start xrdp
respeaker@v2:~$ sudo systemctl enable xrdp

実際に接続するとX側から以下のようなエラーメッセージがでて接続ができません。

RaspberryPiではこのままでいけるのですが…デフォルトでインストールされているパッケージが違うようで、 パッケージがもう一つ必要のようでした。そのパッケージはvnc4server以下のコマンドでインストールします。

respeaker@v2:~$ sudo apt install vnc4server

リモートデスクトップ接続を行って、ReSpeakerのIPアドレスを入力し、【接続】ボタンをクリックします。

以下のようなダイアログがでるかもですが、【はい】ボタンをクリックします。

VNC側の接続画面が表示されます。

【Session】のプルダウンをXvncに設定を変更してユーザーIDととパスワードを入力して【OK】ボタンをクリックします。

リモートデスクトップ接続に成功しました！けど？あれ？

壁紙がなくなっちゃいまいしたが、まあブラウザもコンソールも動いているのでこれもありかなと思います。（ちなみにVNCViewerでの接続でも壁紙がなくなってしまいましたｗ）

残りは後半へ

設定に関しては、問題なく終わりましたというかIPの設定ぐらいしかしていません。ただ、OSのイメージとハードウエアが一対一で用意されているので セットアップでそのまま行けるのは結構便利ですよね。今後やAVSやSnowboyなどの実験などを行ってみたいと思います。

LINE対応ビーコンを今更ながら使ってみた

今年の大垣でのハッカソンが開催されたので参加しました。今回のエントリーでは使用したLINE対応ビーコン（以下LINEビーコンと表記）に関してメモしたいと思います。

mashupawards.connpass.com

LINEビーコンとは？

【通販サイトはこちら】 beacon.theshop.jp

LINEビーコンの仕様はこんな感じです。

ハードウエア仕様
サイズ：　約41mm x 79mm x 約27mm
重さ：　約42ｇ（電池取付時：約90ｇ）
BLEモジュール：　hosiden社HRM1017

Buletoothなビーコンといえば、以前に使用したMAMORIOを思い出します。昨年のNagoyaハッカソンで使用したのでビーコンのイメージはなんとなく覚えています。

uepon.hatenadiary.com

MAMORIOは単純なビーコンという形で使用するのに対して（検出したらどう処理するかを直接的に記述する）、今回使用する LineビーコンはLINEの機能を経由して（LINEbotなどを介してバックエンドへの通信）通信を行うことになります。機能的には大きく変化はないのですが、距離や電波強度といった部分関してはラッピングされた形でのセンシングなどが行われます。

ビーコンを使用するボットを準備する

基本的にはLINEMessagingAPIを使用したBotを作成し、その機能を拡張するだけでLINEビーコンへの対応ができます。

LINEBotの作り方に関しては過去の2つのエントリーを参考にしてもらえれば問題ないかなと思います。

【参考】 uepon.hatenadiary.com

uepon.hatenadiary.com

まずはLINE Developersに移動して

ログインを行います。

すると新規のプロバイダー作成画面またはすでに作成されたプロバイダーのリストが表示されます。自分はすでに作成しているので作成したプロバイダーが表示されています。新規に作成する場合には新規プロバイダー作成ボタンをクリックしてプロバイダーの作成をおこなってください。（詳細は過去のエントリーを参照）

今回はすでに存在しているプロバイダーであるMashup名古屋というプロバイダーを使用する想定で作業を進めます。プロバイダー名をクリックします。

するとチャンネルの選択画面に画面が遷移します。ここでは新しくチャンネルを作成するので、【新規チャンネルの作成】ボタンをクリックします。

ボタンにマウスオーバーするとアクティブになりますのでそのままクリックします。

次に使用するAPIを尋ねれれるのでそこで【Messaging API】を選択します。

ここからチャンネル情報の登録を行っていきます。詳細は過去のエントリーを参照してください。

必要となる情報は * アプリアイコン画像 * アプリ名 * アプリ説明 * プラン（Developer Trialを選択してください） * 業種 * メールアドレス

となります。値の確認を行い、規約への同意を行うとBotが作成できます

作成したBotは【チャンネル基本設定】画面で以下の項目を設定してください。（設定方法に関しては過去エントリーを参照）

• メッセージ送受信設定（アクセストークンは再発行してください）
• LINE@機能の利用

こんな感じになります。（WebhookURLに関してはまだ設定していないので未設定で問題ありません。）

Herokuの設定

続いてはBotのバックエンド側の設定になります。ローカルでやってもいいんですが、あえてHerokuを使用します。 以前のエントリーに従ってGitでデプロイしていきます。Git CMDを起動してソースフォルダ（ディレクトリ）まで移動します。

事前に作成するファイルは

• runtime.txt(Pythonのバージョンを記載)
• requirements.txt(依存するライブラリの記載)
• Procfile(プログラムの実行方法を定義)
• main.py(アプリケーションのプログラム)

となります。

今回は単純なオウム返しbotからビーコン対応のBotに変更することを考えていますので、main.pyに関してはオウム返しのものを使用します。 あとの設定ファイルに関しては過去のエントリーそのままで大丈夫です。

【main.py】

from flask import Flask, request, abort
import os

from linebot import (
    LineBotApi, WebhookHandler
)
from linebot.exceptions import (
    InvalidSignatureError
)
from linebot.models import (
    MessageEvent, TextMessage, TextSendMessage,
)

app = Flask(__name__)

#環境変数取得
YOUR_CHANNEL_ACCESS_TOKEN = os.environ["YOUR_CHANNEL_ACCESS_TOKEN"]
YOUR_CHANNEL_SECRET = os.environ["YOUR_CHANNEL_SECRET"]

line_bot_api = LineBotApi(YOUR_CHANNEL_ACCESS_TOKEN)
handler = WebhookHandler(YOUR_CHANNEL_SECRET)

@app.route("/")
def hello_world():
    return "hello world!"

@app.route("/callback", methods=['POST'])
def callback():
    # get X-Line-Signature header value
    signature = request.headers['X-Line-Signature']

    # get request body as text
    body = request.get_data(as_text=True)
    app.logger.info("Request body: " + body)

    # handle webhook body
    try:
        handler.handle(body, signature)
    except InvalidSignatureError:
        abort(400)

    return 'OK'

@handler.add(MessageEvent, message=TextMessage)
def handle_message(event):
    line_bot_api.reply_message(
        event.reply_token,
        TextSendMessage(text=event.message.text))

if __name__ == "__main__":
#    app.run()
    port = int(os.getenv("PORT"))
    app.run(host="0.0.0.0", port=port)

このソースファイルと設定ファイルから、以下のようにGitでpushすればデプロイはできています。

(base) C:\sample> heroku create 【アプリケーション名】
(base) C:\sample> heroku config:set YOUR_CHANNEL_ACCESS_TOKEN="【LineDevelopersのChannelの設定ページで表示されたAccessトークン】" --app 【アプリケーション名】
(base) C:\sample> heroku config:set YOUR_CHANNEL_SECRET="【LineDevelopersのChannelの設定ページで表示されたSECRET】" --app 【アプリケーション名】
(base) C:\sample> git init
(base) C:\sample> git add .
(base) C:\sample> git commit -m 'commit'
(base) C:\sample> git config --global user.email "【メールアドレス】"
(base) C:\sample> git config --global user.name "【名前】"
(base) C:\sample> git remote add heroku https://git.heroku.com/【アプリケーション名】.git
(base) C:\sample> git push heroku master
(base) C:\sample> heroku ps:scale web=1

ブラウザから作成したサービスのURL（https://【アプリケーション名】.herokuapp.com/）にアクセスして

Hello Worldと表示されればOKです！無事にデプロイがされています。

デプロイがうまく行ったらLINEbot側のチャンネル設定で【メッセージ送受信設定】>【Webhook URL】の設定を行います。 https://【アプリケーション名】.herokuapp.com/callbackになるようにします。

あとはこのbotと友達登録をおこなってメッセージを送ればBotの雛形は完成です。

ようやくビーコンのお話

LINE Developerのサイトには以下のURLビーコンを使用するための情報が記載されています。

ビーコンを使う

ボットをビーコンとリンクするには、LINE@マネージャーのビーコン登録ページを開きます。LINE Beacon対応端末とボットをリンクするか、LINE Simple BeaconハードウェアIDを端末に発行できます。

ということなのでLINE@マネージャーにアクセスをします。すると以下のような画面になるので【ビーコン端末とbotの連携】ボタンをクリックします。

次に【アカウント一覧】の画面に遷移します。ここで作成したBotとビーコンの紐づけを行うことができます。

今回作成したBotの右にある【選択】ボタンをクリックします。 続いてアカウント連携と連携するビーコン情報を登録します。 Botとは登録したビーコンのみアクセスされる形になりますので、その他のビーコンに近づいてもなにも反応はしません。 また、注意点になりますが、Botに複数のビーコンを登録することができますが、1つのビーコンで複数のBotに重複した登録することはできません。そのためLINE@Managerではビーコンの登録解除することもできます。

HWIDとCODEを入力して【連携】ボタンをクリックすると連携は完了です。

連携が完了すると以下のようなメッセージが表示されます。

LINE BeaconのEvent Web hook を受信する方法
1. LINEがインストールされているスマートホンのbluetoothをonにしてください。
2.「LINE Beaconを利用」にチェックを入れてください。
a. 設定 → プライバシー管理 → LINE Beaconを利用。
3. Botアカウントと友達になってください。
a. 連携していないBotアカウントには、ビーコンの情報は送られません。
4. ビーコンの電源が入っていることを確認し、スマートホンを近づけて下さい。
a. LINEアプリがビーコンを検知し、その情報をLINEプラットフォームに送信します。

LINEさんのアプリのUIが変わってしまっているので、この説明では設定できません。具体的には以下の部分は読み替えてください。

（以前のUI）a. 設定 → プライバシー管理 → LINE Beaconを利用。

↓

（現在のUI）a. 設定 → プライバシー管理 → 情報の提供 → LINE Beaconをチェック

2018.09.03時点でのUIは以下のようになっています。

【設定画面】を開きます。【プライバシー管理】をタップします。

その中から【情報の提供】をタップします。

【LINE Beacon】のラジオボタンがあるのでタップしてチェックを入れます。

【同意して利用開始】というダイアログが表示されるのでタップして利用を開始します。

端末によってはBluetoothをONにするダイアログがでるかもしれません。【許可】してください。 （画面が表示されなくても別途BluetoothをONにしてください）

これでLINEアプリ上でビーコンが検出されるようになりました。

あとは、LINEBot上でビーコンの検出イベントが通知するようにソースコードを変更することになります。

【main.py】

from flask import Flask, request, abort, send_file
import os

from linebot import (
    LineBotApi, WebhookHandler
)
from linebot.exceptions import (
    InvalidSignatureError
)

from linebot.models import (
    MessageEvent, TextMessage, TextSendMessage, BeaconEvent,
)

app = Flask(__name__)
statusDict  = {}
status = 0

#環境変数取得
YOUR_CHANNEL_ACCESS_TOKEN = os.environ["YOUR_CHANNEL_ACCESS_TOKEN"]
YOUR_CHANNEL_SECRET = os.environ["YOUR_CHANNEL_SECRET"]

line_bot_api = LineBotApi(YOUR_CHANNEL_ACCESS_TOKEN)
handler = WebhookHandler(YOUR_CHANNEL_SECRET)

@app.route("/")
def hello_world():
    return "hello world!"

@app.route("/callback", methods=['POST'])
def callback():
    # get X-Line-Signature header value
    signature = request.headers['X-Line-Signature']

    # get request body as text
    body = request.get_data(as_text=True)
    app.logger.info("Request body: " + body)
 
    # handle webhook body
    try:
        handler.handle(body, signature)
    except InvalidSignatureError:
        abort(400)

    return 'OK'

@handler.add(MessageEvent, message=TextMessage)
def handle_message(event):
    line_bot_api.reply_message(
    event.reply_token,[
        TextSendMessage(text=event.message.text),
    ])

@handler.add(BeaconEvent)
def handle_beacon(event):
    print(event)
    line_bot_api.reply_message(
        event.reply_token,[
            TextSendMessage(text='beaconを検出しました. event.type={}, hwid={}, device_message(hex string)={}'.format(event.beacon.type, event.beacon.hwid, event.beacon.dm)),
        ])

if __name__ == "__main__":
    port = int(os.getenv("PORT"))
    app.run(host="0.0.0.0", port=port)

ソース変更部分の説明

LINEBotはビーコンの変化検出するとenter/leaveといったtriggerをもとにイベントバックエンドに送信します。そのため以下のようにBeaconEventをlinebot.modelsからimportする必要があります。

from linebot.models import (
    MessageEvent, TextMessage, TextSendMessage, BeaconEvent,
)

その後にイベントハンドラーをflask側に登録します。

@handler.add(BeaconEvent)
def handle_beacon(event):
    print(event)
    line_bot_api.reply_message(
        event.reply_token,[
            TextSendMessage(text='beaconを検出しました. event.type={}, hwid={}, device_message(hex string)={}'.format(event.beacon.type, event.beacon.hwid, event.beacon.dm)),
        ])

これでBot側でイベントはを受信できるようになります。

Herokuのログでは以下のようにメッセージが送信されてきます。

(base) C:\sample> heroku logs --tail
2018-09-13T07:42:18.680976+00:00 heroku[router]: at=info method=POST path="/callback" host=【アプリ名】.herokuapp.com request_id=4466883f-6570-4da2-b4ec-c9dcd591cf14 fwd="203.104.146.154" dyno=web.1 connect=0ms service=445ms status=200 bytes=155 protocol=https
2018-09-13T07:42:18.679620+00:00 app[web.1]: 10.95.189.103 - - [13/Sep/2018 07:42:18] "POST /callback HTTP/1.1" 200 -
2018-09-13T07:42:18.238877+00:00 app[web.1]: {"beacon": {"dm": "", "hwid": "00000*****", "type": "enter"}, "replyToken": "248b7d10a5bc4977aab930004cacd320", "source": {"type": "user", "userId": "*********************************"}, "timestamp": 1536824537481, "type": "beacon"}

（注意）
LINEさんのビーコンではビーコンの状態をbotが管理しています。そのため、エリアにはいったり出たりという変化がHerokuで作成したバックエンドのデプロイとは関係ない状態になります。（考えてみれば当然なのですが）つまり、一度Bot側でEnterの状態になると、バックエンドのデプロイをしたからといってEnter状態トリガーが繰り返し発生されることはありません。一般のBeaconでは常に位置情報が取り出されるのでこの部分が大きく異なります。
あとLeaveに関する通知に関しては、ビーコンから離れて、思った以上に遅く送信されます。基本的にはEnterのみを使用する方向で実装したほうがいいでしょう。

イベントで取得するeventオブジェクトに関しては以下のドキュメントを参照してください。

Messaging APIリファレンス

（注意） ドキュメントをみるとJsonのサンプルは以下の様になっていますが

{
  "replyToken": "nHuyWiB7yP5Zw52FIkcQobQuGDXCTA",
  "type": "beacon",
  "timestamp": 1462629479859,
  "source": {
    "type": "user",
    "userId": "U4af4980629..."
  },
  "beacon": {
    "hwid": "d41d8cd98f",
    "type": "enter"
  }
}

このなかでsource.userIdという属性があるように見えますが、これ間違いですsource.user_idが正しいようです。 Githubのソースをみると正解だと確信しました。

終わりに

LINEBotの作成をちょっと変更することでビーコンの機能を追加できるのはなかなか便利だなと思いました。（アプリの外装を作らなくてもいいのも便利） ただ、デバックが結構大変だなというのも実感しました。これはBluetoothのビーコン全体の話かなと思いますが、それに加えて状態管理をLINEアプリ側にゆだねているのが LINEビーコン側のデバックを難しくしているような気はします。あと、LINEビーコンを使用可能にする手順ももう少し簡単にしたらいいなあと。

とはいうものの、ここまでLINEが普及しているのであれば何らかの形で使っていくアイデアがあるのであれば積極的に使ったほうがいいですかね。

LINEさんはサンプルが充実しているので興味ある方はこちらのGithubを参考にしてください。

【参考】 github.com

ドキュメントトップ

【参考】 uepon.hatenadiary.com

uepon.hatenadiary.com

アイデア供養会名古屋の陣を開催しました！

今年のMashupAwards（MA作品応募期間：2018/9/6（木）~11/5（月））も開催が決定していますが、その直前の【2018/9/3（月）】に名古屋ではアイデア供養会を開催しました。

アイデア供養会　名古屋の陣 【Supported by MA＠名古屋ギークバー 】

イベントの名前もアイデア供養会　名古屋の陣 【Supported by MA＠名古屋ギークバー 】です。今年の春に東京では「着手したけどいろいろな理由で放置しているプロジェクトを紹介する(成仏させる)LT大会」という形のアイデア供養会が行われました。

mashupaward.jp

それをきいて名古屋有志でも「開催したいなあ～」という話をしていたのですが、ようやくそれが実現しました！実のところを言うとお盆の時期にできればという話ではあったのですが、 開催場所が時期的に難しいということもあり、お盆の終わった9月3日に行うことになりました。時期としてはお盆は外してしまいましたが、今年のMashupAwardsの開催前にできたのは ギリギリセーフだったなという感じです。

アイデア供養会はMA常連さんの@塚谷さんが東京の発起人ということだったのですが、できれば名古屋の供養会にも来たいという話をしていたのですが、残念ながら「今回は来れない」ということでしたが…なんと、当日の会場の準備をしていると急遽東京から名古屋まで駆けつけていただけました！このためだけに東京-名古屋間を移動されたということなので凄すぎ！

今回は名古屋近辺でも有名なGeekbarを会場にさせていただきました。会場のご協力ありがとうございました。

geekbar.doorkeeper.jp

アイデア供養会とは？

このアイデア供養会の趣旨は、ハッカソンなどで出たアイデアで着手したけどいろいろな理由

• 情熱が続かない
• 技術的に難しそう
• 物が売ってない

などなどの理由で放置しているプロジェクトを紹介する(成仏させる)LT大会になります。

いつものLT大会とはちょっと異なり、木魚やおりんが響く…いつもとは違う雰囲気の中でのLT大会です。今回の会場であるGeekbarもちょっと雰囲気のある会場（いつもはピアノバーとして運営しています）だったので 思った以上に、それらしく行えたのではないかと思っています。個人的には木魚やおりんは本物だったのでこんなにいい音がするんだという一種の感動もありました。（若干ほしくなったｗ）

【塚谷さんの手で持ち込まれた木魚とおりん】

前日に大垣でMAのハッカソンがあったので、伴野さんも参加していただき、今年のMAイベントの紹介もいただけました！豪華！

今回は募集が一ヶ月前になってしまいましたが、それにもかかわらず10名以上の方がイベントに参加いただき、ほとんどの方がアイデアの供養（LT）を行っていただけました。 通常、この手のLT大会は数人の方のLTを行って、あとはフリータイムのような形になりがちですが、今回は目一杯LTをやったのでむしろ時間がなくなってしまうぐらいで、みんなアイデア供養に飢えているのか（？）とも思えるほどでした。供養に飢えているという表現はなさそうですけど。

今回の目玉！

今回の目玉はやはり…本物の神主さんが供養にご協力いただけたということでしょうか。イベント募集の画像はお坊さんが書いてあったのですが、急遽来ていただくことに成功しました。普通に着ていただけるだけでも嬉しかったのですが、正装で登場したのには驚きです。

自分たちで考えたアイデアには愛着があるので、やはりLTをの時間もしっかり使って来る感じになりますよね。話を聞いていてもすごく楽しかったです。あと、供養会だとLTにも自然にオチがつくというのもいい効果なのかなと。これまで作ってきた作品の歴史を語る方もいれば、印象に残った作品のことを語る方もいて、いろいろな思い出があったんだろうなというのが読み取れます。

私が気になったアイデアは「うしつり」でしょうか。

冷静に考えると、絶対に手を出さないというアイデアでも、イベント、締め切り、圧（謎の力）などでなんとなくやってみたくなる雰囲気があったんだろうなと思いました。こういうアイデアが出るのもMashupAwardsの雰囲気の良さなんだと思っています。素敵です！常連の方もいれば、去年から参加したという方まで幅広い方々に参加していただけて、とてもいいイベントになったなと思うとともに、引き続きアイデアを供養するという場があるというのもなかなかいいなと思ってしまいました。

自分は去年個人で作った作品の供養をしました。はじめて体験したボッチアイデアでしたが、ボッチの作業もなかなか楽しかった。やっていく中で、いろいろなところからコメントをもらったりしてヒントを考えさせられることも多かったアイデアで、本当の意味での作りたいにまっしぐらの「俺得」アイデアであったともいえます。

おわりに

イベントを通してアイデアからモノを作るだけでなく、アフターパーティ的に話すこと、後日談のような形で消化させるようなこと、こういうことを面白いなと思っていただいた参加者が多かったのかなと思います。 アイデアにはやっぱり供養する場が必要ですね。今後も年一回ぐらいはアイデア供養会とかできるといいかなと思いました。

イベントの最後には神主さんからお祓いをしていただきました。

今回イベントにご参加いただいた方々本当にありがとうございました。今年のMashupAwardsのみならず、ものづくりイベント頑張っていきましょう！

告知

来る9/29,30に名古屋でもMashup名古屋ハンズオン＆ミニハッカソン2018を開催いたします。

「自由なものづくり」をテーマに、チャレンジ度、ギーク度、ワクワク度を競い合う日本最大級の開発コンテストであるMashup Aawards。 今年の名古屋のイベントでは、これまでと開催形態を少し変え、技術サポート企業からのハンズオンなどとモノづくりに集中するもくもく会の形式で開催します。

• 【日程】　2018年9月29日(土)10:00 ～ 2018年9月30日(日)17:00（9:30 開場予定）
• 【対象】　アイデアソン・ハッカソンなどにご興味のある方、新しい技術への興味がある方
• 【場所】　名古屋工業大学 講堂 (NITech Hall) 2階 ラーニングコモンズ(愛知県名古屋市昭和区御器所町)
• 【主催】　Mashup名古屋・一般社団法人MA

mashup-nagoya.connpass.com

ぜひ、初参加の方もご参加ただければと思います。

大垣にハッカソンにいってきた

いよいよ9月。ハッカソンなどのものづくりイベントが数多く開催される季節になってきました。 ってことで今回は大垣で開催された「おおがきIoT×AIハッカソン by Mashup Awards 2018」

mashupawards.connpass.com

毎回大垣のハッカソンではロボット関連をテーマとしていましたが、今回はこれまでのテーマに加えてAI・IoTが入った形になっていました。

今回もPepper登場！

LINE Clovaも大量にいました！

大まかな流れに関しては medium.com

d.hatena.ne.jp

こちらを見てもらえればと思います。今回はLINEさんが技術サポートとして来ていらっしゃったので、前から興味のあったLINEビーコンを使用してなにかできないかなと考えました。若干の今更感はあるのですが、ハッカソンでは使ったことが無いデバイスに触れるのも喜びではあるので、ダメ元のチャレンジでした。Bluetoothのビーコンデバイスは実は去年はMAMORIOを使用していたのでなんとなくは分かっていたのですが、LINEビーコンは少し印象が違う感じではありました。

【LINEビーコンの販売ページ】 beacon.theshop.jp

詳細に関しては別のエントリーにしようと思います。

チームビルディングでいろいろと考えていたのですが、今回も結果的にSeyaさんと組むことに。Seyaさんは大垣ハッカソンでは毎度同じチームになるのですが、どちらかが途中で退場するという感じで最後まで発表にいたことのない感じです。とはいっても、実は大垣の作品がMAのセカンドステージに2回も行っているという点ではなかなかいい感じのチームだったと思います。今回もSeyaさんとチームを組んだのですが、2日目がいないということなので、実質ボッチソンって感じ。そのあと2日目の天候が影響してseyaさんもそのままイベントに残ったのでボッチソンではなくなりました。

2日目のことを考えると、自分がコーディングを、その他をSeyaさんという担当で行うことに。

最初のアイデアはビーコンを持った人を探す鬼ごっこ（かくれんぼ？）のようなものを考えていたのですが、アイデアがなかなかうまくまとまらず。モテアイデアに近い感じだったのですが、なんとなく今ひとつ。チームでもう少し考えを変えていって、謎解きゲームっぽいものを作っていこうという話になりました。ビーコンに近づくと位置の検知ができるので、部屋などにおいておけば、部屋の入室がわかるので謎を仕掛けておいて、それをクリアしていってゲームにするってことは、なんとなくできるかなと。

【盗撮をするペッパー、この背中はみたことあるｗ】

一応以下の画像のようなゲームができました。

歩いていると通せんぼする少年。なにかをあげないと通してくれない。

ものを探して違う場所へ…

怪しげな扉と謎の書かれた紙面。

謎を解いて暗証番号を入力すると…扉があき中にプリンが！

アイテムをゲットして、もう一度通せんぼの少年のところに行ってプリンを渡す。

今回は無事に関門をクリア！

最後は4つある扉の中から正解の扉を選ぶというもの正解を選べば無事にクリア！

技術的には単純なのですが、作り始めてからゲームを組み立てていったりしたのでかなり時間がかかってしまいました。 仕様やストーリーをねってから作ればもう少し時間の短縮ができたかな？

終わりに

あとLINEビーコンを使ってみての印象ですが

• 見通しがあれば、距離が離れていてもかなり遠くまで電波は届く。15mぐらいは全然問題ない。（enterのステータスは大丈夫だが、leaveのステータスが使いにくい）
• LineBot側でエリアに入ったか出たかのステータス管理していて、一度エリアに入ったと検出してしまうとバックエンド側を変更してもビーコンのステータスが送信されない（同じ状態を再度送るのは基本できないっぽいのでビーコンの電源のON/OFFまたはがBluetoothのON/OFFが必要です。）
• ドキュメントとGithubの情報が異なっている。Githubにあるソースコードが一番が正しいです。
• Herokuを使うとログ出力などが限定的になったり・表示に時間がかかるので、開発段階ではngrokでつくってからHerokuにシフトするといいもしれません。

基本的に部屋の中でデバックするにはかなり大変な印象を受けました。自分たちも体を動かしながらデバックしてましたｗ

protopedia.net

ついでにいうと、プレゼン中に途中で数字を入れる「謎」が難しすぎて、謎の方に気が引かれたのはハプニングでした。

発表の結果はLINE賞をいただきました。商品は開発で使用していたビーコンだったので今後の開発にも使えそうです！（購入しようと思っていたのでラッキーでした！）

今回は作りたいものを作ったという感じだったので、アイデア的には面白さはなかったかなという感じですが、今後の作品ではぜひWOWを作っていければと思っています。

【今回のMAイスター陣勢揃い写真】

今年も9月6日からMashupAwardsが始まりました。みなさんもお近くのハッカソンがあれば見学でもいいのでぜひのぞきに来てください。

MA2018 〜 ヒーローズ・リーグ 〜 – Make Wow, Feel Wow

あと、このハッカソンを企画していただいた市川さんお疲れ様でした！