こんにちは。🍩です。
会社に受付ロボットがいたら面白いよね。
そんな話から、実際に作ってみました。名前は「めだか」です。
今回は、Forone Labの取り組みとして、Reachy Miniというロボットに音声AIをつないで、来訪者と会話し、Slackへ受付の通知を送る仕組みを作った話です。
会社にロボットがいると面白そう
きっかけは、そのくらいシンプルでした。
会社に来たら、ロボットがいて、話しかけると返事をしてくれる。そのまま担当者を呼んでくれるところまでできたら、ちゃんと受付になる。
想像するだけでも、ちょっと楽しそうですよね。
今回使ったのは、Reachy Mini。ロボット本体を一から作ったわけではなく、この本体に会話や受付の仕組みをつないでいます。
Forone Labでは、興味を持ったことを試作して、実際にどうなるかを確かめています。今回も「面白そう」を、会社で試せる形にしてみました。
話した内容がSlackに届く
受付でやりたいことは、来た人と話して、その内容を社内の担当者に伝えることです。
めだかから届くSlackの通知には、会社名、お名前、訪問先、用件がまとまっています。担当者へのメンションもつきます。
ロボットと話すところだけを見ると、音声AIとの会話に見えるかもしれません。でも、その会話が普段使っているSlackにつながると、会社の受付として使うイメージが湧いてきます。
通知の記録も残るので、誰が、誰に会いに来たのかを社内で確認できます。
どうやってつないだのか
仕組みは、大きく分けると、ロボット、パソコン、音声AI、Slackです。
ロボットが来訪者との会話の入口になり、パソコン側で音声AIやSlackとの連携を動かします。音声AIとの会話から、必要な処理を呼び出して通知につなげます。
こういう「AIが会話の途中で外部の処理を呼ぶ仕組み」を、tool callと呼びます。
難しく聞こえますが、今回は「会話で受け付けた情報を、Slackへ送る処理につなぐ」と考えてもらえれば大丈夫です。
会話を始めるためのボタン
最初に考えたのは、いつ会話を始めるかでした。
音声AIにずっと接続していると、待機中の費用も気になります。人が来たときにボタンを押して、そこから会話を始められるようにしたい。人感センサーまで用意しなくても、まずは「押したことがわかればいい」と考えました。
そこで調べたのが、M5StackのATOMという小さな制御用の機器と、キー型のボタンユニットU144です。大きなボタンのKailh Big Switchも候補にして、どう置けば押しやすいか、どう固定するかを相談していました。
できれば、はんだ付けをせずにつなぎたい。棚に置くなら、ボタンが動かないようにもしたい。
ボタンをひとつ用意するだけでも、電気的につながることと、人が使いやすいことの両方を考える必要がありました。
Groveの4本線から理解する
ボタンとATOMをつなぐところで出てきたのが、Groveケーブルです。黒、赤、黄色、白の4本の線があります。
最初は、この色の違いから確認しました。U144の標準的な接続では、こういう役割になっています。
| 色 | 役割 |
|---|---|
| 黒 | GND。電圧の基準をそろえる |
| 赤 | 5Vの電源を供給する |
| 黄 | ATOMからLEDへ、光り方の指示を送る |
| 白 | ボタンの状態をATOM側で読み取る |
同じ4本線でも、つなぐ機器によって信号線の役割は変わります。この表はU144の場合です。（U144の公式資料）
赤と黒は電源に関係する。黄と白は情報のやり取りに使う。
ここが分かれているんですね。ボタンを押すための電気が、そのままロボットまで流れて会話を始める、というわけではありません。
ボタン側の変化を読み取って、「押されました」という情報として次の処理へ渡す。その間に、プログラムが入っています。
押したことをどうやって知るのか
この橋渡しをするのが、ATOMに載っているマイコンです。決められたプログラムを動かして、端子の状態を読んだり、信号を出したりする小さなコンピューター、と考えるとわかりやすいです。
そこでまた、GPIOという言葉が出てきます。外の部品の状態を読み取ったり、外へ信号を出したりするための端子のことです。
ATOMがボタンの状態を読み、USB通信でMac側のプログラムに伝える。Mac側が、その情報を受けて会話の開始を処理する。ボタン、マイコン、パソコンに、それぞれ役割があります。
さらに、「ボタンを押していないときは、何を読んでいるんだろう」という話になりました。
入力端子は、回路によっては何にもつながっていない状態だと、電圧が不安定になります。そこで、抵抗を使って普段の電圧を高い側に寄せておくのがプルアップです。低い側に寄せるものはプルダウン。
例えば、普段は高い電圧として読み、ボタンを押すとGNDにつながって低い電圧として読む。こうすると、押した・押していないを区別できます。
「押したとき」だけでなく、「何もしていないとき」の状態も決めておく。ボタンの仕組みを追って、そこまで考えることになりました。
5Vと3.3Vと光るボタン
配線を調べていると、今度は5Vと3.3Vが出てきます。
U144は5Vで給電する一方、ボタンの出力信号は3.3Vです。電源として入れる電圧と、信号に使う電圧は、同じとは限らないんですね。
そこで調べたのが、HT7533というレギュレータの話でした。レギュレータは、部品に必要な電圧を供給するために調整するものです。5Vを受け取って、3.3Vを必要とする回路へ渡す、といった役割があります。
そして、U144にはSK6812という制御できるLEDも入っています。ボタンの状態を読む線とは別に、LEDへ光り方の指示を送る線がある。
プルアップの先にLEDがつながっているのか、LEDへの指示はどこを通るのか。図にしてもらっても、そのつながりが見えないと理解できませんでした。
線の色を合わせてもらい、どこからどこにつながっているかを確認する。線が重なって見えるところも直してもらう。そんなふうに、一つずつ追っていました。
指を離しても会話は続けたい
もうひとつ気になったのが、「ボタンを押して話し始めた後、指を離したらどうなるの？」ということです。
受付で話す間、ずっと押し続けてもらうのは避けたい。一度押したら、手を離して会話できるようにしたい。
ここで分けて考えるのは、ボタンの状態と、会話の状態です。
ボタンは、押しているか、離しているかを伝える。一方、会話を始めた後に続けるか、終わらせるかは、ソフトウェア側で管理できます。
押したことを開始のきっかけとして扱えば、指を離すことと会話の終了を切り離せます。物理ボタン自体が押されたままにならなくてもいい。
ボタンの配線を考えていたはずが、いつの間にか受付での会話の流れまで考えていました。
マイクが動かない
実際に進めると、音声まわりでつまずきました。
首やアンテナは動く。でも、マイクの入力がうまく入らない。
Macの音声入力に「Reachy Mini Audio」が出ていても、入力メーターが動かない。音声の初期化でエラーが出ることもありました。
首が動くことと、USB機器として見えていることと、マイクに音が入ること。全部まとめて「つながった」と考えてはいけないんですね。
入力と出力にどの音声デバイスを使っているかを確認して、本体の音声まわりのファームウェアも更新しました。ファームウェアは、機器の中で動いているソフトウェアです。Mac上のアプリとは別に、本体側にも更新するものがある。
途中ではマイクのケーブルを確認する方法も調べましたが、頭のカバーはなるべく開けずに済ませたい、と相談していました。
原因がわからないときに、いきなり全部を触るのではなく、どこまで動いているかを一つずつ確認していく。音声のトラブルでは、その切り分けが必要でした。
9月29日には、音声AIとつないで会話できるところまで進みました。翌日には、社内のSlackに動画を載せて、受付ロボが完成したことを報告しています。
ケーブルと開発環境にもつまずく
USBケーブルについても、改めて調べました。
端子の形が合えば何でも同じ、ではない。電源を供給できるか、データ通信ができるか、どれくらいの速さで送れるかは別の話です。
カメラも使うなら、音声だけでなく映像を送ることまで考えて選ぶ必要があります。ケーブルを買うときも、写真を見ながら、これで大丈夫かを確認していました。
パソコン側では、Pythonのバージョンの違いでセットアップが止まりました。新しいバージョンなら何でも動く、というわけでもない。使うソフトウェアに合うバージョンを指定し、プロジェクト用の実行環境を用意しました。
配線が正しくても、プログラムを動かす環境が合わなければ進まない。逆に、プログラムがあっても、音が入らなければ会話にならない。両方を行ったり来たりしながら準備しました。
開発用のMacから会社に置くMacへ
開発用のMacBook Proで動かした後は、会社に置くためのMac miniを準備しました。
今度は、モニターに画面が映らない。「信号なし」と出るところから始まりました。
接続を確認して画面が出るようになり、Mac miniを初期化。ロボット専用のパソコンとして使う準備を進めました。
会社に置くなら、普段使っている開発用パソコンをつないだままにはできません。本体とボタンをどこに置くか、ケーブルをどう収めるか、マイクがその場所で使えるかも考える必要があります。
手元で動くようにするところと、会社に置いて使えるようにするところで、やることがまた増えました。
動いた後にも調整することがある
動画を共有すると、社内からは、応答の中で確認する回数を少し減らせるとよさそう、という反応がありました。
たしかに、受付で何度も確認されると、会話が長くなってしまいます。必要なことを聞いて、担当者に伝える。そのやり取りをどれくらいスムーズにできるかは、調整していくところです。
また、Slackに通知が来た後、社員が追加で聞きたいことを入力したら、めだかが来訪者に聞き返してくれると面白そう、という案も出ました。
これは次に試したい機能です。受付から社内へ伝えるだけでなく、社内から受付にいる人へも、ロボットを通して話しかけられるようにしたい。
作ったものを見てもらうと、次にやりたいことが具体的になるのがいいですね。
Forone Labで試していくこと
今回、会話して受付の通知を送るところまで作れました。
次は、初めて来た人が迷わず使えるか、聞き返しが多すぎないか、実際の受付でやり取りが途切れないかを見ながら、調整していきたいと思っています。
会社に受付ロボットがいたら面白いよね。
最初はGroveの4本の線も、GPIOも、プルアップも、ひとつずつ調べるところからでした。ボタンを押したことがどう伝わるのかを追って、マイクの入力を確認して、会話とSlack通知までつなぐ。
AIに聞きながら進めていても、図のつながりがわからなければ聞き直すし、実物が動かなければ確認する必要があります。今回は、そのやり取りも含めてハードウェアを学ぶ機会になりました。
Forone Labでは、こういう試作や、作る途中でわかったことも発信していきます🍩