ロボット接客システム開発の裏側の話
この記事は CyberAgent Developers Advent Calendar 2019 の20日目の記事です。
なんやかんやあり、今僕はCyberAgentという会社のロボットサービス事業部 R＆Dセンターというところにいます。
コミュニケーションロボットをはじめとする物理対話エージェントを活用したサービスの研究開発などをやっていて、これまで以下のような実証実験に携わっていました。
これらの経験を通じて得られたコミュニケーションロボットサービス開発の知見(苦労？)について、今回はいくつかピックアップしてご紹介できればと思います。
- システム構成の話
- モックアップ開発の話
- 運用の話
- 人物センシングの話
システム構成の話
前提として、ロボットを取り巻くシステム構成は、設置する環境や提供したいUXによって大きく変化するのが当然と言っていいでしょう。 これはあくまで一例ですが、とある商業施設にて案内ロボットを設置した際の構成です。
タッチディスプレイで案内コンテンツを表示し、案内役である横のロボットが口頭で情報提供をします。 周囲の人の動きをセンサ(深度カメラ)で読み取り、近くで立ち止まっている人に集客担当ロボットが自ら声をかけるといったこともやっています。
このシステムの母体(Main App)はElectronで構成されたデスクトップアプリケーションです。Electronはマルチプラットフォームで動作するアプリケーションを開発できる上、ReactJSやTypeScriptなどWebのプラクティスにあやかることができるので助かっています。
ディスプレイコンテンツの表示、人物検知スクリプトの起動および検知情報の取得、ロボットの発話/モーションの制御などをMain Appが一挙に担っています。各モジュール同士の通信は主にHTTP/HTTPSになるため、施設内にLAN環境を構築しています。
そして、ロボットが対応する案内コンテンツなどはクラウド上のCMSで管理しているため、遠隔からコンテンツを更新することが可能です。
モックアップ開発の話
当たり前ですが、接客ロボットはお客様にベストな接客体験を提供しなければなりません。 ディスプレイやセンサなどの周辺機器と連携した効果的なアプローチや情報提供を始め、 言葉の選び方、身振りのとり方、間の空け方といった対話術についても検討の余地があります。要はUXデザインがサービスの命運を大きく分けます。
そのため、開発プロセスにおいてはUX設計→プロトタイプ開発→デモ(フィードバック会)のサイクルを高速に回していきたいところです。
しかし、技術的な検証やシステムのインテグレーションなど、全てをまともに設計/実装していると1回あたりの作業コストが大きくなり、このサイクルが中々回りません。UXの設計方針が大きく変わったりすると、フルスクラッチでの作り直しを余儀なくされることもあります。
そこで最近、プロトタイプの前段階としてモックアップを作成するプロセスに変えてみました。
ハリボテを用意して黒子役の人が裏でゴニョゴニョすれば、開発しなくても体験を確認できるじゃん！ってやつですね(雑)。 Webの開発でペーパープロトタイピングとかがあるように、ロボットにおいてもWizard of Oz法などといったデザインの手法があったりするので、その辺が参考になります。
モックアップでのレビューを支援するため、裏方の操作に特化したツールを作ってみたら便利でした。
運用の話
ロボットを使ったサービスを提供するにあたって欠かせない要素が、現場での運用のフォローです。
盗難防止などの観点から、ほぼ全ての機材は毎日の営業終了後に収納が必要で、翌朝には再設営することになります。 開発者が現場に常駐し続けるわけにもいかないので、基本的にはこの作業を施設側従業員の方にお願いすることになります。
現場の方々に設営/撤収のオペレーションを回してもらう上でも、様々な工夫が必要です。
- 全ての機材の設置/片付け/トラブルシューティングマニュアルを用意
- それぞれが数十ページにわたる超大作になりがち
- 機材の設置位置、接続ポートなどの全てにマーキングを施す(いわゆるバミリ)
- 各ソフトウェアの起動操作の簡便化
- 稼働状況などを遠隔地からモニタリング
機材の設営において一番難所となるのがセンサ(深度カメラ)の設置です。 高所に設置しなければならない上、アングルや画角の調整がシビアなので、この緻密な調整を現場の方々に毎日依頼するのはかなりの負担になってしまいます。
考えた末に、オリジナルのセンサ設置台を作ったこともありました。センサの土台が着脱可能になっており、こうすることで角度を維持したままセンサだけを収納できます。
東急ハンズの木材コーナーには大変お世話になりました。
あと、Electronアプリケーションの起動時には全ての機材との疎通チェックを行い、人物検知スクリプトなどの周辺モジュールはElectronのサブプロセスとして実行しています。
この起動シーケンスにて何らかの異常が認められた場合は、エラー情報を可視化し、マニュアルの確認へと誘導しています。
1ヶ月程度の実証実験の中だけでも色々なリスクが想定されましたが、いざ長期運用となった場合は可用性、保守性、耐久性など更に視野を広げて対策を考える必要がありそうです。
人物センシングの話
接客ロボットは接客機会を作らないことにはどうしようもないので、お客様に自ら声かけをするなど、アテンションの効果を高めることが重要です。
これをやるにあたり、人物の検出や追跡、滞留/離脱の判定が技術的には重要な要素となってきます。
人物の追跡
人物を検出するにあたっては、IntelのRealSenseという深度カメラを使うことが多いです。 このカメラからRGB映像と深度映像(奥行き)を毎フレームごとに取得し、画像処理を通じてRGB映像から人物を探します。深度映像の情報と組み合わせることで人物の3次元座標を作ることができます。
次に必要な処理として、この人物が前のフレームにもいた人物であるかを推定する必要があります。 直近20フレームくらいの間に取得した人物の座標を保持しておき、DBSCANクラスタリングを使って座標密度のクラスタを作っています。
過去の座標には人物ID(人物ごとに付与した一意なID)が紐付いており、最新フレームの人物座標が属するクラスタ内で、最も出現している人物(のID)を最新座標と同一人物とみなします。下画像の場合だと最新座標はID:1となります。
過去座標のサンプルが少ないうちはクラスタが作れず全て外れ値になってしまう(別人とみなされてしまう)ので、外れ値に対してもユークリッド距離を使った前フレーム座標との比較判定を入れることで追跡精度を補完しています。
人物の滞留/離脱
人物の追跡ができてしまえば、時間と人物座標の推移に基づいて滞留と離脱を判定することができます。 この判定を用いることで、立ち止まった相手に声をかける、相手が立ち去ったタイミングで接客をやめるといったことを実現できます。
とはいったものの、この判定ロジックは人物の検出や追跡が成功しているという前提に依存しています。 現実的な問題として、後ろや横を向かれたり体が見切れてしまったりすると、人物検出精度は落ちる傾向があります。 万人に対して十分な画角やアングルを確保するのは中々骨の折れる作業です…
目の前にいるにも関わらず離脱判定が暴発し接客が打ち切られてしまえば、その人の体験は最悪なものとなってしまうでしょう。
これを防ぐ方法の一つとして、ソナー(音波)や赤外線などを通じて得られるアナログ情報を併用するという手法があります。
例えばPepperは足元にソナーがついているので、付近の物体との距離を逐一監視することができます。 手前に人が立っている状態であれば距離に大きな変化が発生するため、より確実な精度で滞留や離脱の判定を行うことができます。
「じゃあ全部ソナーで良くね？」ってなるかもしれませんが、 カメラはカメラで広範囲を見渡せるし、画像処理を併用すれば物体の特徴を区別したり追跡できるので、アテンションなどには幅広い使い道があるでしょう。 それぞれのセンシング手法も適材適所があるので、どのように組み合わせ、使い分けていくかを考えるのはとても面白そうです。
おわり
コミュニケーションロボットを使ったサービス開発の裏側について、さくっとご紹介しました。 「楽しそう！」とか「大変そう！」とか思ってもらえれば幸いです。
僕も去年まではごく普通の(ちょっとだけ電話に詳しい)Webアプリケーションエンジニアだったので、センシングやったり画像処理やったりDIYやったりと新鮮で面白いことにチャレンジできました。
改めて振り返ると触った技術も多岐に渡っていて、この仕事はまさに総合格闘技だなぁと思います。ニッチな領域ゆえ手探り状態が続いており、今回の知見もまたすぐに置き換わるかもしれません。 とりあえず音声認識とか人物認識とかで詳しい方がいたら是非繋がりたいのでご連絡ください！
