pepperから顔を覚えたよ、通知機能を実装してみた
お疲れ様です。
今日は以前qiitaで書いた記事を実用的にしようと思い、
pepperでAzure Cognitive ServicesのFace APIで顔認証が初めての場合に顔登録を行う処理の後にslackにそのpepperで認証させた顔写真を送るという処理を実装しました。
そもそもそれをやろうと思ったのが、
pepperがどのタイミングで接客して顔を覚えてるのかが気になったため。
普段は受付に置いているので、私の仕事部屋とは離れたところでpepperはお仕事をしています。
そのため、顔を覚えさせるところまでやってくれるお客さんは果たしているのかとか、リアルタイムで通知が来るので、呼び出し機能とかにと応用できると思いました。
実装は本当に簡単で以前書いた以下の記事を参考にやれば、超簡単！すぐできます。
気をつけなきゃ行けないのが、slackのaccess tokenはアカウントごとに異なること。たしかファイルアップロードのAPIじゃないやつは、どのユーザーとして、postみたいな使い方だったのに、ファイルアップロードAPIはユーザーを変えてらaccess tokenを生成しなければなりません。
今回はpepper用にアカウントを作成して、pepperが通知してくれる用のチャネルを作って、そのチャネルに招待してそこのチャネルIDをファイルアップロードAPIのパラメータに指定しました。
これで、pepperくんが
〇〇さんを覚えたよー
みたいな通知を顔登録がされる度に写真と一緒に飛ぶようになりました。
一度覚えてしまうと、新しく顔を覚えるルートを通らないので、自分の顔は覚えさせてしまってる都合上、スマホで検索して表示した画像で勉強させてます。
ちなみにこの写真は実際にpepperの目から見た画像でslackに飛んだ画像です。
slackには、きたがわ けいこさん の顔を覚えたなー
みたいに通知がきます。
本当にきたがわけいこが来てくれればいいのに。
実はスマホのこういう学習でも十分顔の特徴量をAzureは捉えてくれます。
普段近くにいない人とかは、こんな感じで何枚か学習させとけば、いざ生身の人間が来てもちゃんと顔認証できます。
Cogbot勉強会に参加して、Cognitive Toolkitをはじめて触る
Cognitive ToolKitって？
お疲れ様です。マイクロソフト本社で開催されたcogbot勉強会に参加してきました。
今日で第9回目を迎えるらしく、これまではMicrosoft cognitive servicesの画像解析や音声解析のハンズオンだったり、Bot Frameworkを使ってチャットボットを作ったりということをしてきたようです。
今回はCNTKとAzure MLがテーマでした。Azure MLは多少触ったことがありましたが、CNTKは触ったことがなかったため、これは絶対ためになるだろうなと思い参加しました。
そもそもCNTKってよく聞くけど、詳しく知らず。
一応調べてみると、
Microsoft Cognitive Toolkit(マイクロソフトコグニティブツールキット)とは、AI技術を利用したディープラーニング(深層学習)ツールキットです。旧称「CNTK」から改名されました。
とのこと。
簡単にいうとPythonで記述する深層学習などをやるときのライブラリでTensorflow、Chainer、Caffeと同じようなものです。
TensorflowとかChainerはやっとかないとなという感覚になるのですが、どうもそれ以外に手を出す余裕がなくて。やるきっかけがないと、なかなかやらないですよね、、、抵抗があったのが、今日やってみて他のライブラリと対して変わらないなと思えるようになりました。
Azure notebookも楽でいいですね。もともとjupyter notebookの環境構築をローカルですることなしにマイクロソフトアカウントがあれば、すぐに使いはじめることができます。
Azure notebookを立ち上げると、cntkを個別にインストールすることなく、もともと入っているようです。
anacondaを立ち上げて、tensorflowを使うときのように
pip install tensorflow
のようなことをしなくてもすぐにpythonコードで
import cntk
で使えます。
それからAzure notebookで他の人が立ち上げたプロジェクト画面からクローンするとすぐに自分の環境でコードが動かせます。
Setup CNTK on your machine | Microsoft Docs
CNTKをAzure notebookでチュートリアルをやりながら学ぶと言った内容で、準備していただいたスライドと説明がわかりやすくてよかったです。
スライドはこちら
今回の参加者は比較的CNTKのほうがAzure MLより興味があったようで、
私もAzure MLのほうはまだあまり見れていないのですが、
スライドはこちら
まだ詳しいところまでは見れていないので、また明日以降じっくりと復習をしたいと思います。
きっかけって大事ですね。興味ある分野で手をつけれていないところは、こういったハンズオン形式の勉強会に出るのが自分にはあっている なというのがわかりました。
Cogbot勉強会、おすすめです。次回以降も参加してみようと思います。
AWS Developer アソシエイトに合格する方法
はじめに
昨日（2017/11/27）AWS Developerアソシエイトに無事一発合格してきたので、その報告と勉強方法について残したいと思います。
当資格を受験する前に、私は以下二つの資格を取得しました。
- AWS ソリューションアーキテクト アソシエイト
- AWS SysOps アドミニストレーター アソシエイト
上記二つの勉強方法については、以下記事を参照してください。
最初にソリューションアーキテクトを受けてから、SysOpsアドミニストレーターを受けました。この順番で正解だったと思います。
王道ですよね、自分のポジション的にはディベロッパーを取得しなければというところですが、まずはソリューションアーキテクトは取っておきたいと思ったので。
共に一発で合格し、得点もほぼ同じくらいでしたが、難易度はSys Opsアドミニストレーターのほうが高かったです。
試験の難易度について
私はディベロッパーが一番難易度が高そうだなと警戒して、一番最後に回していたのですが、それほど差はなかったです。実際、Sys Opsアドミニストレーターが一番難しかったかもしれません。
すべてのカテゴリで模擬試験を受けたのですが、唯一Sys Opsアドミニストレーターだけが不合格になったので、焦って直前で勉強しまくりました。
勉強期間はどのくらい必要か
ディベロッパーはSys Opsアドミニストレーターを取得してから期間としては1ヶ月と少し開く形になりました。本当は覚えてるうちにすぐに受けたほうがよかったのですが、色々とやらなければならないことがたくさんその時期重なってしまい、すぐに受けられない状態に。。
そのおかげで、以前勉強した内容が結構頭から抜けた状態になっていたので、過去の記事でも書いているWEB問題集を三回周ほど解きました。
実際にまじめに勉強したのは一週間くらいだったと思います。
合計勉強時間は20時間くらいだったと思います。
WEB問題様をやってる人はわかると思いますが、3周はかなりの労力です。なのでそこそこ勉強しないと受からないってことですよね。
ちなみに、現時点ではWEB問題集はディベロッパーだけ問題集が存在しません。プラチナ契約をしてても、Sys Opsアドミニストレーターまでしかないんですよね、残念です。
それと今回はディベロッパーの範囲で絶対cloudformationとかBeanstalkはでるだろうなと思い、再度ソリューションアーキテクトの資格本をその範囲だけ読み直しました。
模擬試験も三日前に受けて、これがかなり重要だと感じました。同じような問題でました。
おすすめの取得方法
３つとも受けてみて感じたのは、それぞれ出題傾向が異なるので、ソリューションアーキテクト受かったからといっても、他のカテゴリの資格は合格できないだろうなということ。
難易度に差はそこまではないのですが、全体的にまずは見渡せてたほうが、理解が深まると思うのでソリューションアーキテクトをまずは受けてから、その後に自身の業務にあったカテゴリを選ぶと良いと思います。
全部狙うという人は、まずはディベロッパーを先に受けたほうが勢いに乗れるのかなとも個人的には思いました。
さいごに
これでAWS三冠👑になったので、このあとは五冠を目指して頑張りたいと思います。
来月に日本ディープラーニング協会がデータサイエンスの新資格を立ち上げました。
それをチャレンジしようと思います。知ったの昨日なので、あと二週間くらいしか勉強期間ないので、受かる気がしませんが、勉強することに意味があると開き直っています。
AWSディベロッパー アソシエイト模擬試験に合格
最近忙しくてAWSの勉強できてなかったけど、いよいよ来週月曜が試験なので、そろそろ模擬試験を受けとかないとということで、先程受けましたよ。
明日、明後日の土日で追い込みをかけるつもりでいるので、今日のところは問題傾向が確認できれば良くて不合格でもいいや、という気持ちで模試を受験しましたが、
意外といけるもので、70%で合格でした💮
Cloudformationは出てくるはずと予想してたとおり出てきたので、その辺は問題ありませんでした。
AWS SysOpsアドミニストレーターの時は、模試は全然ダメだったんですけど、ディベロッパーは割といけることに驚きました。
自分の勝手な妄想ではディベロッパーが一番難しいのでは？と思っていたのですが、そうでもないのか？
本番を受けてみないことには何とも行けないので、まずは土日に追い込みかけてきっちりと合格したいと思います。
自信なかったけど、今日で少し自信つきました。よい結果報告ができるよう本番まで頑張るので、期待してください。
pepperの可能性を考える
SoftBank Robot World 2017の二日目の感想を残しておこうと思います。
二日目は展示会場にいる時間が長めになりました。お仕事簡単生成ツールがバージョンアップするということで、SoftBank の方に影響を確認したところ、1.0で作ったシナリオが消えてしまう可能性があることからバックアップは取った方がよいとのアドバイスを頂きました。
それから1.0で作ったものは、2.0に単純にインポートで移行できないようなので、セリフをコピペして貼っていくような作業をしていかなければならないとのこと。
私がお仕事かんたん生成ツールで作っていた分に関しては、まあなくなってもいいのですが、ほかの人のやつはどうしたものか、、もはやもういらなそうなものが多そうですが、一応伝えておくか。
そのほか、セッションの方もpepperアプリコンテストを一通り見て、すごく参考になりました。
審査員が何名かいて、各チームプレゼンをした後に、最後に審査員による審査結果で賞が発表されていくという形式で、シリコンバレーを思い出しましたw
他のデバイスと連携して何かをするというものが評価が高くなりそうな感じがしました。
汎用的ではなく、ある特定の分野でのアイデアとなると、その分野に特化したデバイスから取得したデータを使ってpepperが何かをするという形になるんでしょうね。
汎用的に使えるようなものだったら、そもそもpepperに内蔵すべきですよね。
pepper単体では出来ることが限られてるので、外部連携させて作り上げていく必要があり、そのアイデア次第で色んなものができます。
このイベントに参加してみて、どこの会社も中身の技術の差はほとんどないけど、アイデアや見た目が重要なんだなと思いました。
だいたいAzureのFace APIで顔認証したり、Google translateで翻訳したりが多いですね。
たぶんまだpepperアプリですごい儲かってる企業ってないんじゃないかな。
たまたま聞いた企業もまだ黒字にはなってないらしく先行投資でこれからといったところらしい。
たしかにロボティクスやAIに先行投資しておくことは無駄にはならなそうな気がします。
pepperに限らず、色んなロボットが増えていくのは時間の問題だと思います。人がやるより、ロボットがやったほうが効果がある業務はまだまだたくさんありそうです。
人間による温かみが欲しい！って思うシーンもあるかもしれませんが、単純な作業とかだったり、あまり深い関係に店員となりたくないと思うことも多いと思います。
人に話しかけるのは嫌だけどロボットなら聞きやすいとか絶対自分はありそうw
そういうところからロボットが少しずつ置き換わっていって、そのうち感情表現など人間により近づけるような技術が進歩すると、深い関係が求められる接客シーンにもロボットが対応し、単純な接客でなく、臨機応変にできるようになるといった流れになるでしょう。
参考になることが多かったので、早くまたpepperの作業をしたくなりました。
SoftBank Robot World 2017に参加してきました
pepperを最近触っているということもあり、外の会社がどういう感じで進めてるのかを調査しにSoftBank robot world 2017に行ってきました。
pepperだけでなくSoftBankが進めるロボット事業についても話があり、最近動画が話題の高い台からバック宙して見事に着地するロボットの話も出てきて、会場が湧きました。Boston Dynamics社とSoftBankが提携するようです。
いくつか事例のセッションを聞いて感じたことは、人間の代わりとなってロボットがやったほうが利益がある業務があり、やってみないとわからないということ。
導入したものの投資対効果を出せない
とよく言われるそうですが、たしかにそうだなと感じます。
何か現行の人間がやっている業務をロボットに置き換えることで期待できることを考えた上で、導入前の実績値を取っておいて、導入後の値との比較をしっかりやらないといけません。
導入したからといって、必ず効果が出るわけではなく、効果が出るような作り込みが絶対必要です。
他の企業がやったから、うちでもうまく行くというものでもなさそうな気がします。
pepperがロボットだから人よりも○○しやすい。
というのは、あるかもしれませんが、○○しやすくても、操作性が悪ければ、途中でやめてしまいますし、その機能まで導くのも重要だと思います。
pepperのUIUXデザインパターンのようなものがあれば、ある程度全体的に統一されるとは思います。
うまくできてる企業は、なんとなくパターンみたいなのがわかってる気がします。
そうそう、昨日のブログで歌を歌わせるためにpepperが発する言葉の音程の調整が難しかったという話をしましたが、
それをちょっと解決してくれる機能が11/30にリリースされるお仕事かんたん生成2.0で追加されるとのことです。
GUI上で、音の高さを視覚的に調整してすぐに再生できるようです。
これがコレグラフで使える形で出力できればいいのですが、よくわかりません。
その他、お仕事かんたん生成のシュミレーターが機能アップして3Dとして、pepperの動きを確認できるようになるのもいいですね。
Javaで完全に作り変えたらしく、速度もデモを見る限りかなり速くなっている印象を受けました。シナリオもシーンごとにテンプレートがあるようなので、簡単なものならすぐに作り上げることができそうです。
シナリオの作成もこれまでの画面切り替えて1ページずつ作るようなものでなく、フローをペタペタ機能のノードを貼り付けて作っていく形式に変わるのもわかりやすくて良いです。
11/30になったらさっそく使ってみたいと思います。
明日はpepperアプリをもう少し展示会のほうで見てきたいと思います。
pepperに歌わせるのに苦戦
今日はpepperに歌を歌わせるために、時間を結構使ってしまった。。
結局、うまく歌わせることができずに、ヘッタクソな歌で我慢してもらうことにしました。
pepperはsay という喋らせるためのpythonボックスの中で、音の高さや、スピード、大きさといったパラメータを数値で指定してあげることで、上手いこと音程を作りだして、歌ってるようにみせるのですが、、これが難しい。
まともに普通に喋らせるのも、変な漢字を使ったり、カタカナに途中で変えたりすることで、人間のイントネーションにしなければなりません。
SoftBankさんがpepperセリフ集というものを作ってくれているので、こちらを使っている人が多いと思いますが、これを自分でやるとなると相当大変ですよね。
一回一回実行して、pepperの声を聞いて、微調整していくという思い出しただけで憂鬱になる作業です。
こんな感じなのに歌を歌わせるとか、恐ろしいですよね。
というか私がそもそも音楽が苦手で、聞いたメロディの音の高さを判別することができないのが、無謀な挑戦だと思いました。
絶対音感のようなものを持っている人なら、なんとなく数値で表せるんでしょうね。
pepperは動かしながら、プログラミングできて楽しいのですが、結構地味な作業も多いのが悩ましいです。この辺が解消されるといいんですけど。
明日から SoftBankのpepperのイベントに二日間行ってきます。楽しみです。
