[この記事はQiitaより再掲となります。］
このブログ記事は、2019年6月23日にドイツのメッセフライブルクで開催されたRobotics：Science and Systems（RSS）2019ワークショップにて発表したクラウドロボティクスの将来に関するラピュタロボティクスのビジョンと展望についての詳細になります。
クラウドロボティクスの概要
クラウドロボティクスという用語は、2010年当時Googleの従業員だったJames Kuffner氏によって作られました[1]。この新しい概念はロボット工学とクラウドコンピューティングの統合によるロボットのための “拡張、共有された頭脳” について言及しました。ロボットが大量の計算処理をデータセンターにあるサーバへ委譲することで “頭脳を拡張” し、実世界の情報(環境やロボットの能力・行動の情報)収集および整理したデータベースを “共有”し、構築できるとしています。
一方、ヨーロッパでは2010年〜2014年の間、EUが資金提供したRoboEarth [2] が “ロボットのためのインターネット” を構築しようとしていました。これはロボット専用インターネットであり、クラウドにあるデータベースと計算処理能力によってロボットの拡張（データセンター内のサーバーによる）、共有された頭脳を実現します。
ラピュタロボティクスの設立メンバーは、元々RoboEarthプロジェクトのETH Zurichチームに所属していました。私たちのパートナーには6つの大学とPhilipsがいました。私たちの共通データベースとクラウドによる計算処理の結果は[3]や[4]、そして以下の動画をご覧ください。
我々の研究を通じて、幾つかのコラボレーションが生まれました。James Kuffner氏はRoboEarthのIndustrial Advisory CommitteeにBrian Gerky氏（Open Source Robotics Foundation（OSRF）のCEO[5]）とともに参加しました[5]。
クラウドロボティクスの研究は90年代まで遡ることができます。外部頭脳ロボットに関する研究 [9] 、インターネットを用いたテレロボティクスに関する研究も行われています[8]。
ラピュタロボティクスのビジョン
課題
１０年近くクラウドロボティクスを経験し、特に会社としての４年の経験より、クラウドロボティクスをより広く再定義すべきだと考えています。クラウドロボティクスを再定義する必要性は、次の二つの主要な理由が挙げられます。
技術より人とプロセスを優先する。技術を選択する前に、まず利用者に共感し、彼らの目標やプロセス、制約を理解しなければなりません。また、よく知られた技術への過剰な依存を伴う認知バイアスに注意しなければなりません。
個人の開発者または一つの会社よりもコミュニティを優先する。人々の繋がりには強さがあります。
クラウドロボティクス分野でよく見落とされるのですが、クラウドベースのロボットシステムの価値はコンピューティングだけではありません。ロボットの頭脳は、動作するためにセンサーやアクチュエーターといったハードウェアを必要とします。さらにロボティクスのユースケースの多くにおいて、複数台のロボットを用いたシナリオが含まれます。つまり複数セットのコンピューティングパワー、センサー、およびアクチュエーターが連携して動作するのです。そしてそれら上位に、従うべき人やプロセスがあります
クラウドとロボットを接続する利点については異論はありません。私たちは頭脳を拡張、そして共有する利点を信じています。
最終的な目標は、クラウドロボティクスの範囲をクラウドだけでなくロボットのハードウェアや周辺環境を含めたものに拡張することです。それにより、クラウドを含めたロボットをより身近な存在にしたいと考えてます。
ロボットソリューションに関わる開発者、利用するエンドユーザから聞かれるロボティクスの課題は次の通りです。
- 技術的な複雑さ：ロボティクスソリューションは非常に高レベルな技術が求められ、専門家でない人が扱うのが困難です。
- 大規模な設備投資：ロボティクスソリューションを実現するにはかなりの資本が必要です。
- 柔軟性のないシステム構成： ロボティクスソリューションは特定の目的に対して構築され、環境やプロセスの変化に対して柔軟性はありません。
- アクセス制限：ほとんどのシステムは現地からしかアクセスできず、そのことがシステムの運用や拡張に対して課題になっています。
- 独自のインタフェース：ソフトウェアやハードウェア間のAPIは標準化されておらず、イノベーションを阻害しています。
発見
旧来のサーバ操作と最新のクラウドコンピューティングに関する共通点を見いだした時、アイディアがひらめきました。詳しく紹介します。
クラウドコンピューティングが登場する以前はサーバとアプリケーションのインストール、構成、テスト、実行、保守などを行うのに専門チームが必要でした。大企業でさえ、その問題に頭を悩ませており、中小企業にとってはチャンスは皆無でした。
そして、クラウドコンピューティングが登場しました。
クラウドコンピューティングによって誰もが無限とも言えるコンピューティングリソースにアクセスできるようになりました。その課金は時間単位で行われ、スタートアップ企業でさえ大企業と同じ市場で戦えるようになりました。米国標準技術局（NIST）[6]では、クラウドは以下の特徴を持つコンピューティングリソース（サーバ、ストレージ、ソフトウェアなど）をユーザに対して提供すると定義しています。
- On-demand self-service：コンピューティングリソースが必要なときはいつでも、専門家を必要とせず入手できる。
- Shared resource：サーバを所有するのではなく、リソースを共有する。
- Rapid elasticity：需要に応じてスケールアップ（またはダウン）できる。
- Ubiquitous access：どこからでもネットワーク/インターネットを介してリソースへアクセスできる。
- Measured service：リソース使用量は、利用した機能（ストレージ利用量、処理時間、帯域幅、アクティブなユーザアカウントなど）によって透過的に課金され（別名、従量課金）、利用量が予測可能である [7]。
例えば上記の特徴をロボット工学に適用したら、世界がどのように変わるのかを考えてみましょう。
On-demand self-service
エンドユーザは必要に応じてロボットを利用または停止できます。ハードウェアとソフトウェアの多様性を考えると、準備段階においては専門家の助けを必要とせずに、ユーザがハードウェアおよびソフトウェアの一覧から必要な構成を選べると良いでしょう。これによりイノベーションや価格競争力があるオープンな市場が生まれます。
Shared resource
エンドユーザはロボットを所有する必要がありません。その代わりに大資本を持つ企業がハードウェアを所有して提供します。特定のハードウェアの全ユニットを共通した方法で管理できれば、ハードウェアに対する規模の経済性が高まり、メンテナンスコストが削減されます。
Rapid elasticity
ロボットの“頭脳”、つまりコンピューティング部分は高い柔軟性をもちます。本体、つまりハードウェアは瞬時に用意できませんので、ロボットが出荷および稼働可能になるまで、しばらく待つ必要があります。
Ubiquitous access
エンドユーザは、ブラウザのようなシンクライアントを使って直感的な方法でロボットを操作し、どこからでも自分のロボット（群）にアクセスできるでしょう。例えばこのビデオではエンドユーザがWebブラウザを使用して、ドローンをリモートで起動および制御できています。
Measured service
リソース使用量は測定できるものであり、エンドユーザやソリューションプロバイダ、ハードウェア開発者、ソフトウェア開発者などを含むすべてのユーザに対してオープンになります。例えば、ロボットが完了した仕事の量、稼働していた時間、APIが呼び出された回数、ログ/測定のための帯域幅/ストレージ使用量など測定します。これらの測定情報は課金を最適化、さらにコストを最適化する予測に用いられます。
良さそうに見えますが、問題点もありそうです。ロボット工学により関連性のある特性を見いだし、修正しなければなりません。
まず、On-demand は除外します。ハードウェアと安全性を考えると、少なくとも今後数年間は、エンドユーザが人手を介さずにロボットソリューションを準備するのは困難でしょう。
第二にRapid elasticityのRapidを削除 ハードウェアをお客様の現場に準備する手間を考えると、Rapidに需要に応じてシステムをスケールアップ（ダウン）することを短中期的に実現することは難しく、また、お客様のフィードバックによると、優先度の高い需要ではないと考えられます。
最後に、Measured serviceはopen interfacesに置き換わります。Measured serviceと言うと、クラウド外部で多くの監視が必要とします。透明性とコミュニティを主体とした、open interfacesを採用しましょう。
つまり、クラウドロボティクスの将来とは以下のように考えられます。
クラウドロボティクスは、オープンなインターフェースを備え、
伸縮性を持つ共有のロボティックス資源を専門家の力を借りずにいつでも、
どこからでもアクセスできるようにし、提供するモデルである。
私たちが構築したソリューション例を使って詳細に説明します。これは、ピッキング効率を高めるために、人と協力するロボットシステムです。ピッキングは倉庫で最も人手が必要なプロセスです。
上記のピックアップ支援システムにおけるクラウドロボティクスの特徴は次の通りです。
Self-service：エンドユーザは専門家の助けを必要とせずにロボティクスソリューションの設定変更やオペレーションを行えます。
Shared resource ：エンドユーザはロボットを所有せず、毎月レンタルしています。
Elasticity： 最小のコストでビジネスプロセスに適合させ、拡大または縮小を容易に可能にします。
Ubiquitous access： ロボティクスシステムおよびサブコンポーネントの状態は、権限を持った人であればどこからでも監視および制御できます。
Open interfaces：
定義されたインターフェイスによって、WMS / ERPなどのサードパーティとの統合が容易になります。
すべてのステークホルダーにとってプロセスがオープンです。たとえばハードウェア保守企業は運用データ、ハードウェアおよびその使用法にフルアクセスでき、タイムリーな保守によって高い稼働時間を保証できます。
素晴らしい、でも…
もちろん、課題はあります。特徴を強調した際に気付いていたかも知れません。この新しい考え方で取り組む上での上位3つの課題を以下に紹介します。
- ロボットは多種多様である
- ロボットは物理的に分布している
- ロボットは自律的である必要がある
最初の2つの課題（多種多様ささ、物理的な分布）は、クラウドコンピューティングで使用される「ペットと家畜」という考え方から理解を深められます。ペットモデルでは、ペット（リソース）は唯一無二であり、愛情を込めて育てられ、病気になったときには手厚く介護されるでしょう。あなたは成長を促進するために手を尽くし、そしてペットに問題、または病気になってもすぐに気付きます。一方、家畜サービスモデルでは、家畜は「ほぼ同一」であり、病気になった場合は別のリソースと交換します。家畜の数を増減させることで規模を拡大、または縮小します[10]。ペットと家畜の歴史および適切な利用について [11] を参照してください。 「ペットと家畜」はクラウドコンピューティングにおける不均一性とスケールの文脈で語られますが、物理的な側面もあります。ペットカフェを除けば、通常ペットは家の中にいて、そこに住む人々との間に特別な絆が生まれます。一方、家畜は農場内で飼育されています。つまり、データセンター内のサーバとして存在するのです。
現在の課題は＃robots-are-petsです。ペットのように扱わなければなりません。それは、ロボットが大事だからというわけではなく、以下のような理由によります。
多様多様 – 特定のタスクをロボットで実行し、最適化を達成するためには特別なメカニズム（ロボット）が必要です。この課題を解決するために汎用ロボットを構築するという考えがありますが、すぐに実現できるものではありません。
物理的分布 – ロボット特定の場所で物理的作業を行うことが期待されます。これはインターネット接続さえあれば任意の場所に配置できるサーバとは異なります。
次に3番目の課題である自律性を考えます。自律性は、周囲の状況をどれだけよく理解し、最適な結果を出すために、どれだけ速く反応、うまく処理を行うかという尺度であると見なせます。もちろん人の介入は最小限とします。この定義を踏まえた上で、課題の全体像を把握するために次の3種類の領域と比較してみましょう。
クラウド – システムへの入力/検知は、不確実性がなく、適切に設計されています（APIが明確に定義されています）
IoT – センサーの帯域幅は小さく、多くの場合、厳しいリアルタイム要件はありません
スマートフォン – ロボットのセンサーと比較すると、スマートフォンのセンサーはまだ精度が低く、スマートフォンは人が使用する適切なアプリを選択します。
上記の比較は自動化のみについてです。それぞれ領域ごとに特有の課題があります。
さぁ、どうやってペット（ロボット）を飼えば良いでしょうか。
光明が見えてきました
要点は次のとおりです。ペットを飼うには、家畜の放牧に比べて少なくとも一桁以上の多様なスキル、ロールおよびリソースセットが必要です。ラピュタロボティクスでは技術スタック（プラットフォームとも呼びます）の構築においてオープンな手法を取っています。
ペットの飼育の可能な範囲での自動化を支援します
ペットの飼い主、ペットの飼育者、ペットの医師などの効率的なやり取りを可能にします。
この詳細については、今後のフォローアップ記事をご覧ください。
クラウドロボティクスに興味を持ちましたか？我々はハイアリングも行っています。ロボットの放牧に興味がありますか？rapyuta.ioをぜひチェックしてください。
参考文献
[1] Kuffner, James (2010). “Cloud-Ehttps://www.scribd.com/doc/47486324/Cloud-Enabled-Robotsnabled Robots”. IEEE-RAS International Conference on Humanoid Robotics.
[2] http://roboearth.ethz.ch
[3] M. Tenorth, A. C. Perzylo, R. Lafrenz, and M. Beetz, “Representation and Exchange of Knowledge About Actions, Objects, and Environments in the RoboEarth Framework,” in IEEE Transactions on Automation Science and Engineering, vol. 10, no. 3, pp. 643-651, July 2013.
[4] G. Mohanarajah, D. Hunziker, R. D’Andrea and M. Waibel, “Rapyuta: A Cloud Robotics Platform,” in IEEE Transactions on Automation Science and Engineering, vol. 12, no. 2, pp. 481-493, April 2015.
[5] http://roboearth.ethz.ch/iac/index.html
[6] The NIST Definition of Cloud
Computing https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf
[7] https://www.techopedia.com/definition/14469/measured-service-cloud-computing
[8] K. Goldberg and R. Siegwart, Eds., Beyond webcams: an introduction to online
robots. Cambridge, MA, USA: MIT Press, 2002.
[9] M.Inaba, S.Kagami, F.Kanehiro, Y.Hoshino, and H.Inoue, “A Platform for Robotics Research Based on the Remote-brained Robot Approach.” I. J. Robotic Res., vol. 19, no. 10, pp. 933–954, 2000.
[10] https://medium.com/@Joachim8675309/devops-concepts-pets-vs-cattle-2380b5aab313
[11] http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/
