HAI シンポジウム 2016
Human-Agent Interaction Symposium 2016

G-20

ロボットサービスの検出制御システムの提案
江頭 宏亮 1∗
小嶋 奨 1
Hiroaki Egashira1 , Susumu Kojima1 ,深澤 高雅 1
菅谷 みどり 1
Takamasa Fukasawa1 , Midori Sugaya1

111

芝浦工業大学 大学院理工学研究科 電気電子情報工学専攻
Electrical Engineering and Conmputer Science, Graduate School of Engineering and Science,
Shibaura Institute of Technology

はじめに現在，様々なセンサを搭載した，利用者の用途に合わせてプログラム可能である汎用ロボットが注目されている．こうしたロボットは, 新たな労働力として様々な場所で実際のサービス提供に関わり，活躍の幅を広げている．将来に不足することが予想される労働の新たな担い手として, 複数の役割を担う汎用ロボットはますます活躍が期待されている．
しかし, ユーザから見た場合, こうした汎用ロボットの利用において, 幾つか課題がある. 一つ目の課題は,その汎用ロボットがどのようなサービスを提供するのか, 分かりづらい点である. 汎用ロボットの多くは，用途に合わせてプログラム可能である. そのため，事前にあるサービスロボットがどのようなサービスを提供するものであるのか, そのサービスの利用者が, ロボットの外形から理解することは難しい．例えば，iRobot 社の Roomba[1] であれば，お掃除サービスが利用可能であることはすぐに理解できる．一方で，ソフトバンク
社の Pepper[2] のような汎用ロボットの場合，Pepperの存在を認識していても，その Pepper はどのようなサービスが利用可能であるのかを知ることは，ロボッ
トとインスタラクションするまで分からない. そのロボットがどのようなサービスを提供するのかが分かれば，より効率的にサービスを利用することができる．このことから，我々は利用者が，ある場所において，ロボットのサービスを直ぐに理解することができる, サー
ビス検出のための統一的なシステムが必要である.
二つ目の課題として，利用可能なロボットサービスが特定できた後に，ロボットごとにサービス制御方法が異なる問題がある．現在，ロボットサービスの制御方法はタッチパネルを用いた方法や音声認識を用いた方法など様々なものが存在する．そのため，利用者はそのサービスごとに制御方法を理解し学習し，そのサービスに合わせて対応を変更しなければならない．特に，∗ 連絡先： 芝浦工業大学

理工学研究科 電気電子情報工学専攻〒 135-8548 東京都江東区豊洲 3 丁目 9 番 14 号
E-mail: ma16018@shibaura-it.ac.jp

情報弱者と呼ばれる高齢者などにとっては，サービスごとに新たな制御方法を学習しなければならないことは，大きな負担となる．
このような多様なインターフェイスの問題を解決する方法として，家電を統一的に遠隔から操作することができる iRemocon[3] と呼ばれる製品がある．iRemocon
はスマートフォンの統一的なインターフェイスを用いて，赤外線リモコンの代わりの端末として，ネットワークを通じて通信を行い，家電の制御を行う．しかし，iRemocon は事前にユーザが取り扱う家電の機種とリモコンの種類をユーザが自ら設定しなければならない．
統一的なインターフェイスによる制御の仕組みを提供することは優れているものの，設定が煩雑であることが問題である．
これまでに，Universal Plug and Play（UPnP）[4, 5]をロボットミドルウェアで使用するための要件についての研究がなされている [6]．その研究は，ロボットでセンサなどのモジュール間通信に UPnP を使用する場
合，UPnP にどのような追加要件が必要になるのか述べている．本稿では，ロボットとクライアントアプリケーション間の通信に UPnP を用いるため，UPnP を利用する目的が異なる．
本研究では先に上げた将来的なロボットサービスにおける二つの課題を検出と制御とし, これらの問題に対して，UPnP と Robot Operating System（ROS）[7]を用いたロボットサービスの統一的な検出制御システ
ム，Service Discovery and Control for Robots(SDCR)を提案する．SDCR は，現在，汎用的に利用されているロボット向けミドルウェアである ROS を用い，UPnPに従ったロボットサービスの統一的な検出と制御を実現する.
本稿は，以下のように構成される．2 節で SDCR を提案し，3 節で ROS，4 節で UPnP の概要を述べる．
5 節で設計と実装について述べる．6 節でまとめを述べる．

2. 特別な設定を行わずにネットワークに接続するだ
けで，すぐに SDCR を利用可能にする（効率性）
3. 既存のサービスに特別な変更を加えることなく，SDCR に対応可能にする（再利用性）

図 1: SDCR の概要

SDCR の提案

2

SDCR は，ロボットサービスの統一した検出と制御方法を提供する．SDCR の概要を図 1 に示す．SDCRは ROS と UPnP を基盤としたシステムである．SDCRは複数のロボットを複数人で共有して利用する環境を想定する．SDCR は，ROS を用いて実装され，検出と制御の対象となるロボットサービスも ROS を用いて実装されていることを想定する．そして，クライアントはスマートフォンのアプリケーションやウェブアプリケーションなどのインターフェイスを通して，サービスの検出制御を行う．ロボットとクライアント端末間の通信は，UPnP を用いて行う．
SDCR では，汎用性を考慮して，固有のクライアントアプリケーションを必要としない設計とする．ロボット
サービスとクライアントアプリケーション間の通信は，UPnP の仕様に従って行われる．そのため，開発者はUPnP の仕様に従って独自にクライアントアプリケーションを開発可能である．ただし，本研究では評価のためにクライアントアプリケーションの開発も行った．

2.1

設計目標

SDCR を設計するにあたり，考慮した点を以下に示す．
1. ネットワークを介して通信を行うことでロボットの位置を意識せずにアクセス可能にする（透過性）（1）について，SDCR は，無線 LAN や有線 LANなどを介してロボットとクライアントアプリケーション間の通信を行う．そのため，ネットワークに接続されていれば，ロボットの位置に関係なくサービス検出制御が可能である．さらに，（2）についても，ロボットやクライアント端末のモデルに関係なく，ネットワークに接続可能な様々なデバイスを SDCR に対応させることが可能である．
（3）について，SDCR は，新しいロボットやクライアントアプリケーションを追加しても，ロボットやクライアントアプリケーションに特別な変更を行わずに，すぐに SDCR に対応可能にする．
そのため，スケーラビリティが高い．既存のサービスのソースコードに変更を加えることなく，設定ファイルを追加するだけで，SDCR に対応可能にする．そのため，既に稼働しているロボットに容易に SDCR を導入可能である．次節より，SDCR の基盤となる ROS とUPnP について説明する．

3ROS

ロボットのハードウェアには，ロボットのモデルごとに様々なものが用いられているため，プログラムの再利用が難しい． そこで，プログラムの再利用を支援することを目的として，ロボット向けのオペレーティ
ングシステム，ROS が開発された．ROS のモジュールは，C++や Python などの様々な言語で実装可能であり，ROS の提供する機能を用いることでスムーズに連携可能である．
ROS は，1 つのプロセスのことをノードと呼ぶ．そして，ROS のソフトウェアは複数のノードで構成され，実行時に疎結合することにより，1 つのシステムとして実行可能となる．以下で，ROS の概要について述べる．

3.1

ノード間の通信ノード同士は，ROS の通信基盤を用いて通信を行う．
ROS のノード間通信の概要を図 2 に示す．通信方法
は，トピックを用いた非同期通信とサービスを通じた
Remote Procedure call（RPC）型の同期通信の 2 つある．
トピックを用いた通信は，Pub/Sub メッセージング
モデルで通信を行う．あるノードはあるトピックにメッセージを配信する．そして，別のノードはそのトピックを購読し，メッセージを受信する．メッセージは，整数

図 2: ROS のノード間通信の概要
図 3: UPnP 対応機器の構成型や浮動小数点型，真偽値などの一般的な基本型から成るデータ構造であり，C 言語の構造体のように任意にネストや配列を含むことが可能である．1 つのトピッ
クには複数の配信者や購読者が存在可能であり，配信者も購読者もお互いの存在を意識せずに通信可能である．出版者と購読者の結合度が低いため，スケーラビリティが高い．しかし，非同期通信であり，購読者からレスポンスは得られない．
一方，サービスを通じた通信は，RPC モデルで通信を行う．供給側のノードは，サービス名を指定してサービスを要求し，そのサービスを通じてリクエストを送り，レスポンスを待つ．トピックのメッセージと同様に，リクエストとレスポンスのデータ構造を定義可能である．

3.2

パッケージ管理ツール

ROS のノードは，パッケージという単位でグループ化される，パッケージは，ソフトウェアを簡単に共有と配布可能にする．パッケージはノードだけでなく，ライセンス情報や依存関係が記述されたマニフェスト，メッセージのデータ構造を宣言したメーセージタイプ，サービスのリクエストとレスポンスのデータ構造を宣言したサービスタイプなどで構成される．
ROS のソフトウェアは複数のノードで構成されるため，ソフトウェアを起動するには複数のノードを起動しなければならない．複数のノードを起動する煩雑さを解消するために，ROS は roslaunch というツールを提供している．roslaunch とは，ROS 複数のノードを簡単に起動させることを目的としている．roslaunch を利用するには，起動したいノードの情報を XML 形式で記述した roslaunch.xml が必要である．

4UPnP

UPnP は機器をネットワークに接続するだけで，複雑な設定なしに他の機器との通信を可能にすることを目的としたプロトコルである．UPnP は既に標準化された基本的な通信プロトコルをベースに，取り決めを追加することで，ネットワークに接続した機器の検出や制御を容易に行う．既に広く普及しており，PC やプリンタ，無線機器など，様々な機器を制御するために利用されている．以下で，UPnP の概要について述べる．

4.1

UPnP 対応機器の構成

UPnP に対応した機器は，Control Point，Device，Service の 3 つのコンポーネントから構成される．UPnPに対応した機器の構成を図 3 に示す．
Control Point はネットワーク経由で Device を検出し，制御するコンポーネントである．例えば，UPnPを利用して PC からプリンタを制御する場合，PC がControl Point に相当する．Device は Control Point と通信を行い，自身の持つ機能を提供する．この，Deviceが持つ機能の一つ一つを Service と呼ぶ．先述の例では，プリンタが Device に相当し，印刷する機能が Serviceに相当する．複数の機器を組み合わせて構成される機器では Device の中に更に複数の Device を持つ構造となる．同様に，Device は複数の Service を持つこともある．

4.2

UPnP の通信手順

UPnP は，表 1 に示す 6 つのステップで機器の検出及び制御などを行う．また，UPnP を利用した通信の例を図 4 に示す．
それぞれのステップについて以下で述べる．
Addressing ステップでは，Dynamic Host Configuration Protocol（DHCP）や，Auto IP と呼ばれる方図 4: UPnP を利用した通信例

法を用いて IP アドレスの取得を行う．DHCP は，ネットワークに一時的に接続するコンピュータに対して，自動的に IP アドレスなどの必要な情報を割り当てるためのプロトコルである．Auto IP とは，デバイス自身がIP アドレスをランダムに振り，ネットワーク内に同一の IP アドレスを持つ機器がいないことを確認して IPを決定する方法である．
Discovery ステップでは，ネットワーク機器の発見を行うためのプロトコルである SSDP を利用して Deviceの検出を行う．UPnP では，マルチキャストグループ
239.255.255.250，ポート番号 1900 番を用いる．Control Point がネットワークに接続されたとき，（1）MSearch メッセージという Device 検出のためのメッセー

表 1: UPnP の 6 つのステップ
ステップ
Addressing
Discovery
Description
Control
Eventing
Presentation

内容
Device の IP アドレスの決定
Device の検出
Device，Service 情報の取得
Device の制御
Device の状態の通知
Web コンテンツの提供

ジを UDP マルチキャストで送信する．M-Search メッ
セージを受け取った Device は，（2）後述する Device
Description を取得するために必要な URL を応答する．
また，Device がネットワークに接続されたときは，Advertisement メッセージを UDP マルチキャストで送信する．Advertisement メッセージに記述される情報は，M-Search メッセージに対する応答と同様である．
Description ステップでは，HTTP GET メソッドを利用して，Device の持つサービスなどの詳細な情報が記述された xml を取得する．xml には，Device の情報が記述された Device Description と Service の情報が記述された Service Description の 2 種類が存在する．
Control Point は（3），（5）それぞれ HTTP の GET メ
ソッドを送信することで，（4），（6）取得する．Device
Description の取得に必要な URL は先述した Discoveryステップで知ることができる．Service Description の取得に必要な URL は Device Description に記述されている．
Control ステップでは，Device の動作を制御する Action Invoke や，Device から変数の値を取得する Query
Invoke を行う．Device Description に記述されている
controlURL に対して，Control Point は，（7）これらのメッセージを HTTP を使用して SOAP プロトコルで送信する．SOAP とは，XML ベースの RPC プロトコルである．Device は，受信したメッセージに従って制御プログラムを実行する．制御の実行後，（8）SOAPで返り値を含む応答を返す．制御に必要な引数や実行するメソッドの名前などの情報は，Service Descriptionに記述されている．
Eventing ステップでは，Device の持つ変数が変化したとき，Pub/Sub メッセージングモデルで Control
Point へ通知を行う．また，Presentation ステップはDevice の持つ Web コンテンツの提供をする．

5

設計・実装

SDCR の設計は，検出と制御に ROS と UPnP を基盤として利用する．さらに，本稿では，ROS のアプリケーションを UPnP に対応させるために幾つかの設計，実装を行った．SDCR は，設定ファイルを解析することによりメッセージとサービスのリクエスト，レスポンスの型が決まる．そのため，ランタイムに型の決定可能な Python を用いて実装した．
以下で，SDCR とクライアントアプリケーション間での通信方法について述べる．さらに，サービスの検出及び制御の設計と実装，設定ファイルについて説明する．

Listing 1: sdcr.xml の例

表 2: sdcr.xml の service 要素の構成
要素
serviceType型
文字列

条件
必須

versionserviceID
controlURL

数値
数値
文字列

必須
必須
必須

5.1

説明
サービスの種類を判別するための任意の文字列
サービスのバージョン
サービスに固有の任意の ID
UPnP で操作に用いる URL

SDCR とクライアントアプリケーション間の通信

SDCR とクライアントアプリケーションの間での通信は，UPnP プロトコルに従って行う．SDCR が Deviceに相当し，クライアントアプリケーションが Control
Point に相当する．
検出は UPnP の Discovery ステップと Description
ステップを利用する．Discovery ステップを利用してSDCR に対応したロボットを発見する．Description ス
テップにより，ロボットの詳細な情報，利用できるサービスの情報や制御方法を知る．
制御は UPnP の Control ステップを利用して行う．
Action Invoke メッセージに制御に必要な呼び出すメソッドの名称や，引数を格納する．

5.2

ロボットとサービスの検出

SDCR でのロボットとサービスの検出では，ROS のソフトウェアはパッケージという単位で形成されるので，パッケージ≒サービスと捉えることが可能である．
しかし，ROS のインストールと同時に多数のパッケージがインストールされるため，意図しないパッケージをサービスとして検出してしまう．そこで，検出制御の対象となるパッケージとならないパッケージを明確に区別するために，対象となるパッケージには SDCR用の設定ファイル（sdcr.xml）を設置することにする．
sdcr.xml は，XML 形式で記述される．sdcr.xml の例
を Listing 1 に示す．そして，sdcr.xml の service 要素と action 要素の詳細を表 2, 3 に示す．
設定ファイルの有無によりサービスの検出を行うので，開発者はソフトウェアのソースコードに変更を加えることなく，ソフトウェアを SDCR に対応させることが可能である．
また，UPnP の通信にはデバイスの情報が必要である
ので，デバイス情報を記述した設定ファイル (device.xml)
を SDCR のパッケージ直下に設置することにする．device.xml の例を Listing 2 に示す．そして，device.xmlの device 要素の詳細を表 4 に示す．

<?xml version=”1.0”?><service><serviceType>sdcrservice:1</serviceType><version>1</version><serviceID>00000003</serviceID><controlURL>controlURL</controlURL><actionList><action><name>talker</name><description>chat service</description><actionType>topic</actionType><topic>chatter</topic><msgClass>std msgs/String</msgClass><argumentList><argument><name>文字列</name><dataType>String</dataType><desc>メッセージを入力</desc></argument></argumentList></action></actionList></service>

表 3: sdcr.xml の action 要素の構成要素
namedescription
actionType
topic

5.3型
文字列
文字列
文字列
文字列

条件
必須
必須
必須
任意

説明
アクション名アクションの説明
Topic, Service or roslaunch
actionType が Topic の場合，必須

検出手順

SDCR のサービスの検出手順は図 5 のように設計し，実装を行った．まず，SDCR は起動後に rospack を用いて（1）パッケージ一覧を取得する．次に，（2）取得したパッケージ一覧に SDCR の設定ファイルである
sdcr.xml があるか，sys モジュールの isFile() 関数を用いて調べる．そして，sdcr.xml がある場合，（3）そのパッケージを SDCR の検出対象とし，検出対象のサービスが決定すると（5）Device Description と Service を生成する．xml の生成には，XML を扱うためのライブラリである ElementTree[8] を利用する．一方，sdcr.xml がない場合，（4）検出対象としない．初期処理の後，SDCRは，（6）M-Search のリクエストを待ち，（7）M-Searchメッセージを受信すると，Device Description 取得用の URL を応答で返す．Service Description は，Device
Description に記述されている URL からアクセスすることができる．このようにして，クライアントアプリ
ケーションは，ロボットとサービスを知る．

Listing 2: device.xml の例<?xml version=”1.0”?><device><location>SIT</location><domain>SIT</domain><deviceType>rosdevice:1</deviceType><version>1.0</version><name>robot−ubuntu</name><manufacture>SIT</manufacture><modelName>first model</modelName><UDN>
uuid:550e8400−e29b−41d4−a716−446655440000</UDN><iconList></iconList></device>

表 4: device.xml の device 要素の構成
要素
location
domaindeviceTypeversionnamemanufacture
modelName
UDN

型
文字列
文字列
文字列
数値
文字列
文字列
文字列
文字列

条件
必須
必須
必須
必須
必須
必須
必須
必須

説明
場所
ドメイン名
rosdevice:1 で固定
バージョン
デバイス名
デバイスの製造者
デバイスのモデル
デバイスのユニーク ID
UUID を指定

図 5: サービスの検出手順

5.4

サービスの制御

SDCR でのサービスの制御では，ROS のソフトウェ
アでは，一般的に roslaunch を用いて起動し，topic とservice を用いて制御を行う．したがって，SDCR では，サービスの制御を roslaunch，topic，service を用いて行えるようにする．SDCR が，どのような制御方法がサービスにあるのか検出可能にするため，開発者はサービスの制御方法を sdcr.xml に記述する．記述する内容
は，サービス名と制御方法，そして，制御方法ごとの情報である．制御方法には，「roslaunch」，「topic」などの制御方法の名前をそのまま記述する，制御方法ごとの情報には，roslaunch の場合，実行に必要なパッケージ名と roslaunch ファイルの名前を記述する．topic の場合，topic の名前，メッセージタイプ，メッセージタイプの型を記述する．service の場合，サービスの名前とサービスのリクエストとレスポンスの型を記述する．

5.5

制御手順

SDCR の制御手順は図 6 のように設計し，実装を行う．SDCR は，（1）Action Invoke メッセージを受け取ると，xml の記述から引数や動作の名称を読み出す．
そして，（2）サービスが実際に存在するかを確認する．

サービスが存在した場合，（3）〜（6）roslaunch, topic,service を用いてサービスの制御を行う．各制御に必要な情報は，各パッケージの sdcr.xml の action タグから取得する．
（4）topic を用いた通信による制御は，rospy パッケー
ジの Publisher クラスの publish(message instance) メソッドを用いて実装した．メッセージインスタンスの生成は，roslib パッケージの Message クラスの get messa
ge class(class name) メソッドを用いて，メッセージのクラス名から生成した．生成したインスタンスのメンバ変数には，genpy パッケージの message クラスの fil
l message args(msg instance,args) メソッドを用いて，クライアントアプリケーションから受け取った値を代入した．
（5）Service を通じた通信は，rospy パッケー
ジの ServiceProxy クラスを用いて生成した Service のインスタンスを用いて実装した．ServiceProxy クラスのコンストラクタは，service 名と service クラスを必要とする．service 名は，sdcrx.xml から取得する．そして．service クラスは，rosservice パッケージの get s
ervice class by name(service name) メソッドを用いて取得する．service を呼び出すときのリクエストの生成は，topic を用いた通信時と同様に，genpy パッケージの message クラス fill message args(msg instance,arg[3] iRemocon トップ ペ ー ジ, http://i-remocon.
com/, (2016/7/23 アクセス)[4] OCF UPnP, https://openconnectivity.org/upnp/, (2016/7/23 アクセス)[5] 浜田憲一郎: UPnP 入門, ブイツーソリューショ
ン，(2008).
[6] Ahn, S. C.: Requirements to UPnP for robot
middleware; 2006 IEEE/RSJ International Conference on Intelligent Robots and Systems,
pp.4716-4721, (2006)[7] ROS.org |Powering the world’s robots, http://www.ros.org/, (2016/7/23 アクセス)[8] 19.13.
xml.etree.ElementTree
ElementTree XML API Python 2.7.x Document,
http://docs.python.jp/2/library/xml.
etree.elementtree.html, (2016/7/23 ア クセス)
図 6: サービスの制御手順s) メソッドを用いて行う．
（6）roslaunch によるサービスの起動は，roslaunch パッケージを用いて実装した．
そして，制御を終了した後，（7）ElementTree ライブラ
リを用いて返り値の情報を xml で記述した応答を生成し，送信する．

6まとめ

UPnP や ROS を用いてサービスの検出制御を行うことで SDCR の目的である「ロボットの位置を意識せずにアクセスが可能」や「特別な設定を行わずにネットワークに接続するだけで利用可能」，「既存のサービスに特別な変更が必要ない」を実装することができた．
しかし，設定ファイルに記述された情報を元にサービスを検出しているため，動的にサービスを変更できないという問題がある．今後は動的にサービスを変更できるシステム構築が必要である．

参考文献[1] iRobot ロボット掃除機ルンバ 公式サイト, https://www.irobot-jp.com/, (2016/7/23 アクセス)[2] ロボット | ソフトバンク, http://www.softbank.
jp/robot/, (2016/7/23 アクセス)