1.社会実装実験内容

1-1.目的

本実験は、MIRS2302 TENQ Projectの実証実験を行うにあたって、次の目的で行われた。

・製作したロボットが、想定される使用環境(=人が行き来する学内)で安全に走行可能か検証する。
・製作したwebアプリが一般ユーザにとって(手助けなしで)使用可能か検証する。
・ユーザに製品を使用してもらい、フィードバックを得る。

1-2.実験内容

webアプリをNCT-WL-STに公開し、製品を実際に使用してもらうことで実証実験を行った。

ただし、実証実験とするため下記の機能を実装せず行った。
・デリバリーにおける決済機能(無料で商品を配達することとした。)
・泥棒を検知した際のアラーム機能 (走行中の振動による誤検知が多発してしまったため。ただし、管理者に対する通知は行った。)

詳細な手順を次に示す。

次に、検証する項目について示す。

2.実験スケジュール

計画当初のスケジュールを次に示す。ただし、01 / 15 (月)の実験は行うことができなかった。（後述）

16～22日の実験はスケジュール通り行った。

3.実験結果

3-1.概要

計5日間TENQを稼働し、16件の配達を行った。概要を次に示す。

(1).M/E/D/S科の学生(1-5年)、専攻科生、先生方と、幅広い層の方々がユーザとして協力してくださった。

(2).利用方法として圧倒的に「注文」が多かった。

(3). (平坦な環境では)安定した走行を実現

(4).集荷／受取のしやすさに課題点が残る

3-2.詳細

受け付けた手配について、次に示す。

一例として、No.15の配達の様子を次に示す。

稼働中のログファイルを次に示す。

次に、実験中に発生した問題について示す。

(1). 実際に依頼した学生とは異なる学生が受け取りに来た

大前提として、予知・対策をしていなかったことが原因であるが、実運用環境では詐欺やいたずらの原因となりかねない事案である。
実験時の状態では本人確認を4-8桁のPINコードで行っていた。これをより強固にすることで対策が可能である。
たとえば、依頼者のスマホでリアルタイムな認証を行うように実装することで、依頼者がその場にいないと認証できないようにできる。

(2). C科棟前の坂でトルクが足りず、立ち往生してしまった

当時の動画を次に示す。

また、この原因と対策について、(4). 配達の評価についてに示した。

(3). 走行中にRaspiとJetsonの接続が途切れてしまった

Raspberry PiとJetson nanoは機体に搭載したルータを経由し、イーサネットによって接続されていた。この問題が発生した原因はルータに電力を供給していたバッテリが切断されてしまったことである。

また、これに伴って機体が暴走する問題も同時に発生した。
ROSから指令された速度指令値はJetson→Raspi→Arduinoという経路で通信されていたため、切断直前にArduinoが受け取った速度指令値のまま機体が動き続けてしまったことが原因である。

対策として、通信の切断が検知された場合にモータを停止するよう実装するべきであるとした。

(4). 通信の切断に伴うプログラムの不具合

(3)の対応中にメインプログラムを強制終了せざるを得ない状態になってしまった。これに伴いロボット及び手配の状態遷移ができていない状態となってしまった。

これに伴いプログラムがバグを引き起こし、パスワードを入力しても扉が開かない状態になってしまった。

(5). 通信の切断に伴うwebアプリの不具合

(3)および(4)とは別に、Raspberry Piと学内WiFi間の通信が切断されてしまったことによる問題も発生した。

機体が走行していると、アクセスポイントが切り替わる瞬間にRaspberry Piと学内LANとの通信が切断されてしまう。
再接続を行うスクリプトを稼働させているため自動的に再接続はされるものの、これに最大1分程度の時間を要する。
この間にユーザはwebアプリにアクセスすることができなくなる。

また、切断される前に手配フォームを埋めて、切断後にフォームを送信してしまうと、サーバが正常にPOSTを受け取ることができない。
実験期間中、「送信ボタンを押したのに手配がされない」という問い合わせが1件あったが、上記の問題が原因と考えられる。

対策として、POST通信が失敗した場合にjsでクライアントサイドにエラー表示をさせるよう実装すべきであった。

3-3. 検証項目に対する評価

3-4. 分析結果

実験結果について分析したものを次に示す。

(1). 実証実験ユーザの内訳

(2). 実証実験にて受けた依頼の内訳

(3). 実証実験におけるロボットの目的地の内訳

ただし、ユーザによって指定された集荷／受け取り地点のみ集計した。

(4). 実証実験におけるロボットの移動について

各配達について、集荷地点から受取地点の距離を集計した。

4. ユーザ評価

4-1. 実際にTENQを使用したユーザによる評価 (n = 18)

(1).Webアプリの使いやすさについて (10段階評価)

(2).集荷／受取がどれほどしやすいものであったか (10段階評価)

(3).セキュリティがどれほど信頼できるか (10段階評価)

(4).配達に対する評価 (10段階評価)

(5).今後のTENQに対する期待度 (10段階評価)

(6).総合評価 (10段階評価)

(7).webアプリに対する感想 (コメント・一部抜粋)

(8).モジュールに対する感想 (コメント・一部抜粋)

(9).配達に対する感想 (コメント・一部抜粋)

(10).プロジェクトに対する感想 (コメント・一部抜粋)

4-2. TENQを使用していないユーザによる評価 (n = 22)

(1).『自分がどこかに持っていかなければいけない荷物』を、ロボットが代わりに配達してくれるとしたらどれくらい使いたいと思うか (10段階評価)

(2).『自分が誰かにもらいに行かなければいけない荷物』を、ロボットが代わりに配達してくれるとしたらどれくらい使いたいと思うか (10段階評価)

(3).『尚友会館の商品』を、ロボットがデリバリーしてくれるとしたらどれくらい使いたいと思うか (10段階評価)

(4).ロボットに運んでほしいもの (コメント・一部抜粋)

(5).（稼働中のロボットを見た人）良い、すごいと感じた点 (コメント・一部抜粋)

(6).（稼働中のロボットを見た人）悪い、微妙と感じた点 (コメント・一部抜粋)

5. 考察

5-1.実験結果より

3-4.分析結果 よりわかることと、その考察を次に示す。

(1). 実証実験に協力してくださったユーザのうち、4割超をD科学生が占めており、C科学生の協力は得られなかった。

実証実験を行うにあたって、C科学生に対して最も参加を期待していた。尚友会館や学生課など、あらゆる施設から遠い場所に位置しているためである。
しかし、実際にはC科学生からの協力は得られず、D＞E/S＞Mという順であった。

D科はMIRSを行っている学科であることから、D科学生の協力が最多であるのは順当であるといえる。
次いでE/S科学生の協力が多かった理由として、専攻分野によるものではないかと考えた。
電気系・情報系を専攻するE科、S科性にとって、MIRSのロボットが興味を惹くものであった可能性がある。
これに対し、C科、M科生にとってはロボットは比較的馴染みのない存在であることから、参加人数が少なくなってしまったと考えた。

実際に、ユーザからのフィードバックの中で『移動時間短縮』に関連するキーワードより『ロボットが云々』といった内容が多く目立っていた。

(2).利用方法の内、「注文する」が圧倒的な割合を占めていた

実験期間中にすべてのモードでの配達を実験することができたが、注文による利用が8割超を占めていた。

その要因として、次が考えられる。

・商品が無料であったため
・(送る・受け取ると異なり)相手がいなくても利用できるため

実験結果のみからは「注文」のニーズが大きな割合を占めていると読み取れるが、アンケートからはこれに矛盾する結果が得られた。（後述）
したがって、前述した2点が大きな要因であり、各機能の需要に大きな偏りが生じているわけではないと考える。

また、手配の中で「保冷／保温モジュール」を利用したものはすべて「注文する」であった。

(3).移動目的地の内訳について

集荷・受取地点として指定された場所についても、(1)と同様にD科が最も多かった。

要因として、D科のユーザが多かったことの他に、HRの場所も挙げられる。

たとえば、D科棟にHRが位置するE科学生がD科棟を受け取り場所に指定していた。また、E科棟に一番近い場所にも受け取り場所を設定していたが、ここの利用回数は0回であった。

ほかにも、D科棟が比較的売店から遠いことも要因のひとつと考えた。

これに反して、学生課前を受け取り地点に設定したユーザが次点であった。学生課で受け取りしたユーザの一人に、体育が終わったあとに受け取りに来たユーザがいた。

このことから、「いつもいる部屋 (HRなど)」のほかに、「ついでに寄りやすい場所」も受け取り地点としての需要があることがわかった。

(4).移動目的地の内訳について

実験前は、遠ければ遠いほど需要が大きくなるものと予測していた。
しかし、結果に示したように標準偏差σ=52mであり、利用パターンに大きなばらつきがあった。

ほとんどの移動が「注文」によるものであるため、配達距離によるニーズの分布とは一概に結びつけることができない。

また、実験目的にあったように(発着地点が)多くのパターンでの走行を試行できたといえる。

5-2.フィードバックより

次に、フィードバックよりわかることとその考察を示す。

5-2-1. 機能ごとの評価について

フィードバックより、各機能に対する評価を次に示す。(n = 18)

(fig.5) webアプリに対する評価	(fig.6) 荷物の出し入れに対する評価	(fig.7) セキュリティに対する評価	(fig.8) 配達(移動)に対する評価
平均値　: 8.28 中央値　: 8 標準偏差: 1.48	平均値　: 8.33 中央値　: 9 標準偏差: 1.86	平均値　: 8.28 中央値　: 8.5 標準偏差: 1.63	平均値　: 7.94 中央値　: 8 標準偏差: 1.87

(1). webアプリの評価について

評価の平均値は2番目に高く、比較的好評な機能であったといえる。また、標準偏差値は最も小さかったことから、webアプリに対する評価はばらつきが小さく、個人差が比較的小さかったといえる。
しかし、自由記述のコメントのなかにはwebアプリに対する肯定的な意見も否定的な意見も存在したため、これについて次に示す。

実証実験中に得たフィードバックの中で圧倒的な割合を占めていたものが、webアプリについてであり、

・ロード時間が長い、レスポンスが遅い
・UIがわかりやすい
・UIがわかりにくい

という意見があった。

レスポンスの遅さについては明白であり、APIの応答に10秒近くかかってしまうことが原因である。
このAPIは、ダブルブッキングを阻止するために手配の時間の選択肢を制限するためのものである。pythonにより実装した上、アルゴリズムが複雑かつ冗長となってしまったがために処理時間が長くなってしまった。

次に、UIのわかりやすさについて、肯定的な意見が7割程度を占める一方、否定的な意見もあった。

その要因について、挙げられるものを次に示す。

(i). デバイス差によるもの

このwebアプリは、スマホによる使用を想定して実装した。

しかし、開発はPCで行っていたことから自然と横画面に適したUIになってしまったと考えられる。

下図に示すように、PCでは適切なサイズである各要素が、スマホ表示では非常に小さくなっている。

改善の余地として、デバイスによってcssを切り替え、適切なレイアウトで表示すること可能である。

(ii). 事前知識の有無による差

webアプリを使用したユーザの中には、システム提案やMIRS発表会をみていないユーザもいる。

そのようなユーザがこのwebアプリを使用するにあたって、利用の流れなどの事前知識が皆無であることが問題である。

左端のタブ(TENQとは？)を選択することで大雑把な使い方を知ることができるものの、それを見ながら操作することができない仕様も改善点である。

(2). 集荷／受取の評価について

評価の平均値が最も高く、半数が満点評価だった。しかし、標準偏差値は2番目に大きい値であり、評価に比較的大きな個人差があったといえる。

実験中にユーザが荷物を出し入れする際、スムーズに手続きを済ませた例と途中でつまずいてしまった例に二分された。
これにより評価が極端に分かれてしまったと考える。

実証実験中の実例を示す。

・タブレットによって、開いた扉から荷物を出し入れするよう促したものの、どの扉が開いているのかわからず戸惑っていたユーザ
・扉を開けて荷物の出し入れをすることができたが、扉を閉めずに去ってしまったユーザ
・扉を閉めることができたが「受け取り完了」ボタンを押さずに去ってしまったユーザ
・指が乾燥してタッチパネルが反応しなかったユーザ

上記より、「ユーザが次行うべき操作」をより直感的に、わかりやすく伝え操作を促すよう改良する余地があるとした。
たとえば、

・扉の解錠後に扉の縁を発光させる
・扉を手動でも自動でも開け閉め可能にする
・取り残しを検知できるようにする（これにより、「取り忘れはありませんか？」という確認操作が不要になるため、「受け取り完了ボタン」の存在が不要になる）
・タッチペンを備え付ける

などがある。

(3). セキュリティの評価について

評価の平均値は2番目に高く、webアプリと同等であった。
しかし、標準偏差はwebアプリよりも大きく、個人差が生じていたことがわかる。
ヒストグラムもほかの項目と異なり二峰性があるといえる。このことから、この設問に回答したユーザに異なる性質が含まれていると考えられる。（後述）

セキュリティに関するコメントには、『扉がこじ開けれそうだった』というご意見があった。
実際に、扉およびロック機構はそれぞれMDF材とABS樹脂によって製作したため、強度が不十分である。
したがって、扉とロック機構の剛性を高め、物理的なセキュリティを強固にすることが今後の課題である。

また、上記のようにセキュリティを懸念する評価がある一方で高評価が多かったのも事実である。
これは、主にシステム提案や発表会を聞いたことのある人によるものだと予想される。
両発表では、扉のこじ開けやモジュールの持ち去りが生じた際にこれを検知できることを明確に述べており、これを知っていたことからセキュリティ面に対する心配を和らげていた可能性がある。
これに対し、発表を聞いたことがないユーザにとってはセキュリティ面に対する周知がなにもされておらず、不安／懸念を解消できていなかったと考える。
また、上記がヒストグラムに二峰性があらわれた要因であると考えられる。

したがって、セキュリティの強化とともに挙げられる改善点として、「どのようなセキュリティが施されているのかしっかりアピールする」ことが有効であると考えた。

(4). 配達の評価について

大きな差が見られなかった上記の3点とは異なり、配達評価は平均値・中央値・標準偏差どれも最も悪い評価を得た。
ほかの項目と比べたとき、評価のばらつきが多いうえ、全体的に低い評価に偏っているといえる。
その要因について、コメントおよび実験中のデータに基づいた考察を次に示す。

フィードバックのコメントの内、UIに次いで多くを占めていたのが走行に関するものであった。そのなかに、

・坂道／段差で苦戦していた
・速度が速かった
・速度が遅かった

という意見があった。

坂道や段差で苦戦してしまう原因は、トルク不足の他でもない。改良した足回りに次の問題があったと考える。

・シャフト(φ8)がロボットの自重で曲がってしまった。これによりギアの噛み合いが悪くなってしまった。
・ギア比が適切でなかった。タイヤの直径が2倍だからとギア比を1:2と設定していたが、これをもっと大きくするべきであった。

平坦な場所の走行では、速度が速いという意見も遅いという意見もあった。
ROSのパラメータによって、最高速度は600mm/sに制限していたが、常にその速度で走行していたわけではない。そこで、D科ラボ前からC科棟前まで走行した際の平均速度を計測した。

記録によると、168mの道のりを5分5秒で走行した。したがって、平均速度は約510mm/s (=1.8km/h) であった。

これは、人間の平均歩行速度の大体半分である。また、これを速いととるか遅いととるかは個人差があるが、その人の開発経験による影響もあると考えた。
たとえば、MIRSでの開発経験のあるユーザからは「速い」という意見が多く見られたが、学科・学年が違うユーザからは「遅い」という意見が多く見られた。

システム提案でも明記したように、本製品の目的は「迅速にものを運ぶ」ことではなく「代わりに運ぶ」ことである。
しかし、「時間は人間の倍かかるが、人の手を煩わせず配達するロボット」が一般のユーザ層からは受け入れられにくいことがわかった。

このことから、ロボットの高速化は比較的優先すべき改善事項であると考えた。

5-2-2. 利用シーンごとの需要

次に、製品の利用方法によるニーズの差について示す。

本製品の利用方法として、「送る」「受け取る」「注文する」の3つがある。これら3パターンの利用方法に対して、どの程度使いたいと思うか、評価を得た。

なお、前述したとおり実験の結果としては「注文する」による利用が8割超であった。

(fig.11) 「送る」に対する評価	(fig.12) 「受け取る」に対する評価	(fig.13) 「注文する」に対する評価
平均値　: 7.59 中央値　: 8 標準偏差: 1.44	平均値　: 8.45 中央値　: 8 標準偏差: 1.12	平均値　: 8.09 中央値　: 8 標準偏差: 1.65

・最も評価の平均が高く、標準偏差値が小さかったのは「受け取る」であった。
・これに対し、最も平均値が低かったのは「送る」であった。
・中間に位置している「注文」は標準偏差が最も大きく、ヒストグラムの尖度も小さい。

上記のように、「注文する」が圧倒的な支持を得ていた実験結果とは、相反する評価を得た。

評価より、次の2点について考察した。

(1).「送る」の需要 ＜ 「受け取る」の需要

前述したように、「送る」と「受け取る」のニーズには大きな差が生じた。
考えられる要因のひとつとして、各機能の利用場面がある。
たとえば、「送る」を利用する動機は「本来自分が移動すべき時間を短縮したい」というものである。
これに対し、「受け取る」を利用する動機は「相手が移動すべき時間を短縮したい」というものであろう。
もしそうであれば、得られた結果は「自分に生じる利益」より「他人に生じる利益」を重んじる気持ちの表れともいえる。

ほかにも、想定される運搬物品にも差があると考えられる。
結果にて示した表を再掲する。

表より、「送りたい物品」はほとんど「受け取りたい物品」に内包されていることがわかる。
これに加えて、「受け取りたい物品」には受け取り機能ならではの消耗品がいくつか含まれている。
たとえば、ごみ袋やチョーク、寮の消耗品である。

ただし、このアンケートの回答者のほとんどは学生である。したがって「消耗品を提供する側」のユーザからの回答は得られなかった。
たとえば学生係の方々が利用することを想定すると、「送る」の運搬物品に消耗品が含まれるはずである。

したがって、「『送る』の需要 ＜ 『受け取る』の需要」という結果が得られた要因として、
・自分より他人を労わろうとする気持ちのあらわれがある
・ただし、アンケートの対象に偏りが生じており、あくまで学生による評価であること
があるとした。

(2). 「注文する」の需要

アンケートによると、「注文する」のニーズは中間に位置していた。
これに対し、実験では「注文する」の手配が14件、その他が2件であった。

この大きな要因として、実証実験において商品の注文が無料であった点がある。
実証実験の結果は「商品が無料でデリバリーされる」という条件のもとであったのに対し、 アンケート調査は「webアプリ上で決済して商品がデリバリーされる」という条件のもとで回答を得た。

このことから、実運用環境と同じ条件で回答を得たアンケート調査による評価のほうが信頼性が高いものといえる。

アンケート結果によると、「注文する」機能の需要評価はもっとも標準偏差の値が大きく、ヒストグラムの尖度も小さかった。
したがって、売店の商品をデリバリーすることに対する需要は個人差が大きいといえる。
アンケート内のコメントにおいても、売店をあまり利用しないと回答したユーザがいた。

これらの結果を踏まえると、各機能の需要は人によって異なるが、ユーザ層／運用環境の種類だけ需要の種類があるといえる。
本製品は、モジュールの切り替えによって、各ニーズに柔軟に対応できるとしている。
しかし、モジュールだけでなく機能にも柔軟性をもたせ、運用環境によって適した機能を有効化できるよう改善することができると考えた。

一例として、アンケート結果にて、「自分のカバンや部活の道具を送りたい」というコメントが多くあった。
そこで、いまある利用方法のほかに「自分の荷物を自分に配達させる」機能の実装も可能であるのではないかと考えた。

6. 今後の展望

今回の実証実験結果およびユーザ・学生からのフィードバックをもとに、今後の課題および製品に施せる改善点を挙げた。

(1). webアプリの改善

ユーザからのフィードバックより、webアプリがもつ課題点がいくつも浮き彫りになった。
改善すべき点として、次を挙げた。

・スマホでもPCでもタブレットでも見やすい、操作しやすいUIの実現(レスポンシブ化)
・事前知識がなくても使える、親切なUIの実現
・ダブルブッキングを阻止しつつ、高速なレスポンスが可能なAPIの実現
・受け取り時の認証をより強固なものにする
・タッチペンの搭載

(2). 機体の改善

同様に、実験やフィードバックから機体に関する改善点を挙げた。

・トルク改善や足回り強化による悪路の走行
・ロック機構を強固なものにする
・むき出しになっている各部品をカバーする
・モバイルネットワークを搭載し、WiFiが無い環境でも運用可能にする

(3). 運用方法の改善

同様に、システムが有する機能に関する改善点を挙げた。

・施されているセキュリティ対策をしっかりアピールし、安心して利用してもらう
・自分⇔他人だけでなく、自分の荷物を遠いところまで運ばせる機能の実装
・搭載するモジュールだけでなく、運用時に利用できる機能（モード）も切り替えられるようにする
(ex. 小中学校では「注文」を無効化する、 「先生からの受け取り」のみ有効化)

7. さいごに

社会実装実験を行うにあたって、計画時から実験時までご協力いただいた教職員の皆様方、実験に参加してくださった学生・教職員の皆様方、フィードバックを送信してくださった皆様方に、班員一同より深く感謝申し上げます。

開発に関係していなかったり、専門分野の異なる方からは、自分たちでは視れない視点からのフィードバックをいただきました。
また、MIRSを控えている・経験した学生からは、専門的な鋭いフィードバックをいただきました。

いずれもとても参考になるフィードバックであり、上記のようにたくさんの改善点を見つけることができました。

また、実際に手配をし、ロボットを利用してくださった皆様方におかれましては、実験にご協力いただきありがとうございました。
実物と対面したときに頂いたお褒めの言葉の数々は、我々のモチベーションを大きく向上させました。
不具合が発生してしまったことも幾度となくありましたが、暖かくご対応いただきました。

改めて、深く感謝申し上げます。

MIRS2302メンバー 一同