JP2019054455A - 通信デバイス、情報通信端末装置及び通信方法 - Google Patents

Abstract

【課題】少ないハードウエア資源によって構築し、画像処理などの処理を高速化するとともに、通信遅延の低減と低消費電力化を実現する通信デバイスなどを提供すること。【解決手段】ロボットシステム１は、駆動コンポーネント２０に形成される通信デバイス２００が必要なメッセージを受信する際の通信コネクションを確立するまでの通信制御については、アプリケーションと連動するＸＭＬ−ＲＰＣなどの通信プロトコルを用いるとともに、メッセージの配信については、並列処理が可能な論理回路の出力を他の通信デバイスに直接的に提供するためのＴＣＰＲＯＳなどの通信プロトコルを用いる構成を有している。【選択図】図１

Description

本発明は、他の通信デバイスとの間においてデータ通信を行う通信デバイスなどに関する。

従来、飛行型ドローン、陸上移動型ロボット、水中ロボット等の各種ロボットが開発されてきており、特に、ヒューマノイド（人型ロボット）のようなロボットシステムにおいては、一般的に、頭部等に設けたカメラや当該カメラを駆動する駆動回路（ＣＰＵも含む。）などから構成されるコンポーネント（以下、「カメラコンポート」ともいう。）と、手足を駆動させるためのモータやアクチュエータ（以下、これらをまとめて「モータ」という。）とこれらの駆動回路（ＣＰＵも含む。）などから構成される駆動制御用コンポーネント（以下、「駆動コンポーネント」ともいう。）と、を備えている。

また、この種のロボットシステムにおいては、カメラコンポーネントは、カメラ画像データに対する特徴点の抽出や認識結果を得るための画像処理を実行するとともに、その結果を示すデータ（以下、「画像処理結果データ」ともいう。）を、駆動コンポーネントに送信し、各駆動コンポーネントは、取得した画像処理結果データに基づいて、モータを駆動して、障害物回避等の自律駆動を実現する構成を有している。

一方、最近では、この種のロボットシステムにおいて、各コンポーネント間をギガビットイーサネット（例えば、１０００ｂａｓｅ−Ｔ等の通信規格／登録商標）によって相互接続して、コンポーネント間の配線を単純化する方法が採用されている。

また、最近では、画像処理結果データ送信時に通信遅延を解消し、かつ、データのリアルタイム性を確保するため、ＦＰＧＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）を用いる通信デバイスが提案されている。

特に、ＦＰＧＡを用いてカメラ画像に画像処理を実行させることによって、マイクロプロセッサの処理負担を低減し、かつ、当該ＦＰＧＡの出力となる画像処理結果データの送受信処理のみをマイクロプロセッサを用いたアプリケーションの処理を実現するＳｏＣ（ｓｙｓｔｅｍ ｏｎ ｃｈｉｐ）通信デバイス（ＲＯＳ：ｒｏｂｏｔ ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ）準拠ＦＰＧＡコンポーネントが知られている（例えば、非特許文献１）。

さらに、通信遅延を削減するため、ＳｏＣ上のロジック回路（以下、「論理回路」ともいう。）によって実行する通信デバイスも提案されており（例えば、特許文献１）、また、当該通信デバイスは、画像処理用のＦＰＧＡと組み合わせることによって、通信遅延を防止しつつ、かつ、低消費電力化をも実現可能となっている。

ＵＳ２００６０１６８０７０Ａ１

Ｋａｚｕｓｈｉ Ｙａｍａｓｈｉｎａ，Ｔａｋｅｓｈｉ Ｏｈｋａｗａ，Ｋａｎｅｍｉｔｓｕ Ｏｏｔｓｕ ａｎｄ Ｔａｋａｓｈｉ Ｙｏｋｏｔａ， "Ｐｒｏｐｏｓａｌ ｏｆ ＲＯＳ−ｃｏｍｐｌｉａｎｔ ＦＰＧＡ Ｃｏｍｐｏｎｅｎｔ ｆｏｒ Ｌｏｗ−Ｐｏｗｅｒ Ｒｏｂｏｔｉｃ Ｓｙｓｔｅｍｓ −−−ｃａｓｅ ｓｔｕｄｙ ｏｎ ｉｍａｇｅ ｐｒｏｃｅｓｓｉｎｇ ａｐｐｌｉｃａｔｉｏｎ−−−，" Ｐｒｏｃｅｅｄｉｎｇ ｏｆ ２ｎｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｗｏｒｋｓｈｏｐ ｏｎ ＦＰＧＡｓ ｆｏｒ Ｓｏｆｔｗａｒｅ Ｐｒｏｇｒａｍｍｅｒｓ（ＦＳＰ２０１５）， Ｐ６２〜６７, ２０１．０９．０１

しかしながら、上記特許文献１に記載の方法では、ＲＯＳのプロトコルに従った通信処理を、組込み向けのマイクロプロセッサ上のアプリケーションにより実現するので通信遅延時間が大きくなり、そのため、通信遅延時間を削減するために、ハードウエア化をすると、ハードウエア量が多くなり、通信デバイスの設計コストと製造コストが増大してしまう。

本発明は、上記課題を解決するためになされたものであり、その目的は、少ないハードウエア資源で実現し、画像処理等の処理を高速化し、かつ、通信遅延の低減と低消費電力化を実現する通信デバイス等を提供することにある。

（１）上述した課題を解決するため、本発明は、
論理回路によって加工された、予め定められたトピックに属する実データを他の通信デバイスに配信する通信デバイスであって、
所定のアプリケーションと連動する第１通信プロトコルに従って、前記トピックにおける前記他の通信デバイスとのデータ通信を実行するための通信制御用のデータであって、当該データ通信を行う際に割り当てられた第１通信アドレスを含む第１通信制御用データを、前記通信デバイス間のデータ通信を管理する管理装置に登録する登録手段と、
特定の前記トピックにおける前記第１通信アドレスを含む前記第１通信制御用データを前記管理装置から取得した前記他の通信デバイスから、前記第１通信プロトコルに従って、当該特定のトピックに関するデータ通信を実行するための第１通信コネクションの確立要求を受け付ける第１受付手段と、
前記第１通信コネクションの確立要求が受け付けられた場合に、前記第１通信プロトコルに従って、当該確立要求をした他の通信デバイスとの前記第１通信コネクションを確立する第１確立手段と、
前記第１通信プロトコルとは異なり、かつ、前記論理回路を用いる第２通信プロトコルによって前記特定されたトピックにおける実データを配信するための通信用制御データであって、当該実データを配信する際に用いる前記第１通信アドレスとは異なる第２通信アドレスを含む第２通信用制御データを、前記第１通信プロトコルに従って、前記第１通信コネクションが確立された他の通信デバイスに配信する第１配信手段と、
前記配信された第２通信用制御データに含まれる第２通信アドレスを用いることによって、前記他の通信デバイスから、前記第１通信プロトコルに従って、前記特定のトピックにおける実データのデータ通信を実行するための第２通信コネクションの確立要求を受け付ける第２受付手段と、
前記第２通信コネクションの確立要求が受け付けられた場合に、前記第２通信プロトコルに従って、当該確立要求をした他の通信デバイスとの第２通信コネクションを確立する第２確立手段と、
前記第２通信プロトコルに従って、前記確立された第２通信コネクションを介して、前記論理回路から出力された前記特定のトピックにおける実データを、該当する他の通信デバイスに配信する第２配信手段と、
を備える構成を有している。

この構成より、本発明は、特定のトピックにおける実データが必要な他の通信デバイスとはアプリケーション（ソフトウエア）と連動する第１通信プロトコル（例えば、ＸＭＬ−ＲＰＣ：Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ−Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ）によって通信コネクションを確立し、実データの配信については、第２通信プロトコル（例えば、ＴＣＰＲＯＳ：Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ ｆｏｒ ＲＯＳ Ｍｅｓｓａｇｅｓ ａｎｄ Ｓｅｒｖｉｃｅ）によって論理回路（例えば、ＦＰＧＡ：Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）の出力を直接的に提供する通信コネクション（例えば、ＴＣＰコネクション）を確立することができるので、実データについては、通信遅延なく、他の通信デバイスに提供することができる。

そして、本発明は、実データの配信についてのみ論理回路のハードウエア資源を用いるので、少ないハードウエアによって構成することができるとともに、当該実データの配信については、マイクロプロセッサなどのＣＰＵや種々の回路が不要となるので、実データに関する処理の高速化を実現し、かつ、低消費電力によって駆動することができる。

特に、ＸＭＬ−ＲＰＣなどのアプリケーションに従った通信プロトコルは、アプリケーションに従ってマイクロプロセッサが各処理を実行するが、処理能力が低い低消費電力のマイクロプロセッサを用いた場合であっても、実データの配信の通信遅延には影響しない。

しかしながら、このようなアプリケーションに従った通信処理は、ハードウエア資源によって通信パートを構築する場合には、当該通信パートにおける通信ポートをハードウエア資源によって複数実装する必要がある。

このため、通信ポートの増加は、ハードウエア資源の増加に直結するため、当該アプリケーションに従った通信処理を用いる場合には、少ないハードウエア資源によって実現することは難しく、さらに、ハードウエアの開発コスト及び製造コストが増大することも想定される。

一方、ＴＣＰＲＯＳなどの論理回路の出力を直接的に提供することが可能な通信プロトコルは、少ない数の通信ポート（例えば、１ポート）で実現できるため、少ないハードウエアで実現可能である。

しかしながら、このような通信プロトコルをアプリケーションに従ってマイクロプロセッサが各処理を実行することによって実現すると、当該マイクロプロセッサの処理負担が大きくなり、結果的には通信遅延の原因となる。

そこで、本発明は、他の通信デバイスが必要な実データを受信する際の通信コネクションを確立するまでの通信制御については、アプリケーションと連動する通信プロトコルを用いるとともに、実データの配信については、論理回路の出力を他の通信デバイスに直接的に提供するための通信プロトコルを用いることによって、少ないハードウエア資源によって構成することができるとともに、画像処理等の処理を高速化し、かつ、通信遅延の低減と低消費電力化を実現することができる。

本発明は、少ないハードウエア資源によって構成することができるとともに、画像処理等の処理を高速化し、かつ、通信遅延の低減と低消費電力化を実現することができる。

本発明の一実施形態におけるロボットシステムの構成例を示すシステム構成図である。 従来のＲＯＳシステムにおけるパブリッシュ／サブスクライブ型の通信原理を説明するための図である。 一実施形態のロボットシステムにおいて実行される通信原理について説明するための図である。 一実施形態の通信デバイス（送信側）一構成例を示すブロック図である。 一実施形態のロボットシステムにおいて実行されるメッセージの取得開始処理を示すシーケンス図である。 一実施形態の通信デバイス（受信側）一構成例を示すブロック図である。 本発明の通信デバイスを用いた性能評価実験の評価条件を説明するための図（その１）である。 本発明の通信デバイスを用いた性能評価実験の評価条件を説明するための図（その２）である。 本発明の通信デバイスを用いた性能評価実験の評価条件を説明するための図（その３）である。 本発明の通信デバイスを用いた性能評価実験において、「ｓｎｄ＿ｄａｔａ」ノードが画像メッセージを送信開始してから、「ｒｃｖ＿ｄａｔａ」ノードが画像メッセージを受信完了するまでの遅延時間の測定結果を示すグラフである。 本発明の通信デバイスを用いた性能評価実験において、「ｓｎｄ＿ｄａｔａ」ノードが画像メッセージを送信開始してから、「ｒｃｖ＿ｄａｔａ」ノードが終了メッセージを受信完了するまでの遅延時間の測定結果を示すグラフである。

以下、図面を参照しつつ、本発明の実施形態について説明する。なお、以下の実施形態は、ＲＯＳに準拠した複数のコンポーネントを組み合わせることにより実現されるロボットシステムに対して、本発明に係る通信デバイスなどを適用した場合の実施形態である。ただし、以下に説明する実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではなく、本実施形態で説明される構成の全てが、本発明の必須構成要件であるとは限らない。

［１］ロボットシステム
まず、図１を用いて、本発明の第１実施形態におけるロボットシステム１の構成及び概要について説明する。

なお、図１は、第１実施形態のロボットシステム１の構成を示すシステム構成図である。また、図１においては、図面が煩雑となることを防止するためロボットシステム１を構成する複数のコンポーネントのうち、一部のコンポーネントのみを示している。すなわち、ロボットシステム１は、図１に示すコンポーネントの一部をロボットシステムの構成に合わせて追加又は削除して、適宜変更することができる。

本実施形態のロボットシステム１は、例えば、ヒューマノイドなどの自律駆動型のロボットシステムであり、カメラＣと通信デバイス（送信側）１００が接続されたカメラコンポーネント１０と、モータＭと通信デバイス（受信側）２００が接続された複数の駆動コンポーネント２０と、各コンポーネント間における通信を管理するマスターデバイス３０と、を有している。

なお、カメラコンポーネント１０、駆動コンポーネント２０及びマスターデバイス３０は、ギガビットイーサネット（登録商標）Ｎを介して相互に接続され、各コンポーネント間において、後述するパブリッシュ／サブスクライブ型のデータ通信が実行されるようになっている。

特に、本実施形態のロボットシステム１において、ロボットシステム１の自律駆動を実現するため、
（１）通信デバイス（送信側）１００は、カメラＣにおいて撮像されて供給されるカメラ画像データに対して、画像認識処理、特徴点抽出処理等の画像処理を実行しつつ、当該処理によって得られたデータ（以下、「画像処理結果データ」という。）を、イーサネット（登録商標）Ｎを介して各駆動コンポーネント２０に配信（送信側）し、
（２）通信デバイス（受信側）２００は、モータＭの駆動に用いるために、当該配信された画像処理結果データを受信し、受信した画像処理結果データを当該モータＭに提供する
構成を有している。

本実施形態のカメラコンポーネント１０は、例えば、画像中に存在する障害物等の物体の位置座標情報や当該物体までの距離及び角度などのデータ、及び、当該画像中における曲がり角などの特徴点に関するデータを、画像処理結果データとして、カメラ画像に基づき生成し、駆動コンポーネント２０に供給するようになっている。

具体的には、カメラコンポーネント１０は、ロボットシステム１の周囲環境に対応する画像を撮像するカメラＣと、当該カメラＣと接続された通信デバイス（送信側）１００と、を有している。

カメラＣは、図示せぬＣＣＤＩセンサと、ＣＣＤＩセンサにおいて得られた画像信号を処理して、ＲＧＢ、ＣＹＭＫ等の形式のカメラ画像データに変換する信号処理部と、を有し、自機の周囲環境を撮像して、対応するカメラ画像データを通信デバイス（送信側）１００に供給する構成を有している。

通信デバイス（送信側）１００は、マイクロプロセッサやＦＰＧＡが搭載されたＳｏＣデバイスによって構成され、カメラＣにより撮像されたカメラ画像データに対して、ＦＰＧＡを用いた画像処理を実行する構成を有している。

また、通信デバイス（送信側）１００は、当該カメラ画像データに対して実行されたことによって得られた画像処理結果データを、イーサネット（登録商標）Ｎを介して、パブリッシュ／サブスクライブ型の通信方式にて、駆動コンポーネント２０の通信デバイス（受信側）２００に配信する機能を有している。

特に、通信デバイス（送信側）１００は、マイクロプロセッサを用いたソフトウエア処理によって、上記パブリッシャーアプリケーションノード機能を実現するとともに、ＦＰＧＡにより上記パブリッシャーＦＰＧＡノード機能を実現して、自ノードに対応するトピックを介して、駆動コンポーネント２０の通信デバイス（受信側）２００に画像処理結果データを配信する構成を有している。

なお、本実施形態においては、カメラコンポーネント１０の通信デバイス（送信側）１００によって、各駆動コンポーネント２０の通信デバイス（受信側）２００に対して配信される画像処理結果データの内容については、特に限定されない。

駆動コンポーネント２０は、配信された画像処理結果データを取得するとともに、当該取得した画像処理結果データに基づいて、例えば、ロボットシステム１の手足などの該当する部位を駆動させ、障害物を回避し、対象物体を把持し、又は、通路に沿って進むなどの行動を自律的に行わせるようになっている。

具体的には、駆動コンポーネント２０は、モータＭと、当該モータＭに接続され、カメラコンポーネント１０の通信デバイス（送信側）１００から受信した画像処理結果データに基づき、当該モータＭを駆動する通信デバイス（受信側）２００と、を有している。

例えば、駆動コンポーネント２０が、ヒューマノイドの足部分を駆動するコンポーネントである場合には、自律的に周囲の障害物を回避しつつ移動させ、又は、実空間上の通路に沿って移動させるため、駆動コンポーネント２０は、画像処理結果データによって示される周囲の物体の位置や物体までの距離、角度、画像中の曲がり角などに対応する特徴点等のデータからロボットシステム１が向かうべき方向、及び、進むべき距離などを算出し、当該算出結果に基づきロボットシステム１が移動するように、又は、対象物を把持し、又は、把持している物体を他所に向けて投射する動作するように、モータＭを駆動させる構成を有している

マスターデバイス３０は、イーサネット（登録商標）Ｎ用の図示せぬインターフェースを有するとともに、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等のメモリを有し、通信デバイス（送信側）１００によって送信される第１通信制御データとトピックデータ（すなわち、パブリッシャーノード情報）を受信して、両者を対応付けて、メモリに記録させる。

特に、マスターデバイス３０は、パブリッシャーノードである通信デバイス（送信側）１００と、サブスクライバーノードである通信デバイス（受信側）２００との間における通信を管理するマスターノードとして機能するとともに、ＲＯＳシステムにおけるネームサーバとして機能する構成を有している。

そして、マスターデバイス３０は、通信デバイス（受信側）２００によって送信されるトピックデータに基づき、メモリに記録されたトピックデータを検索し、当該トピックデータにより示されるトピックにメッセージをパブリッシュするパブリッシャーノードの第１通信制御データをメモリから読み出しつつ、サブスクライバーノードに通知する機能を有する。

なお、マスターデバイス３０は、従来のＲＯＳシステムにおけるマスターノードと同様の役割及び機能を有するものであるため詳細を省略する。

なお、本実施形態においては、イーサネット（登録商標）Ｎを介して、送受信するデータ量を削減し、通信デバイス（送信側）１００及び２００における通信処理の負荷を軽減するため、カメラコンポーネント１０の通信デバイス（送信側）１００においてカメラ画像データに対する画像処理を実行し、通信デバイス（送信側）１００から画像処理結果データのみを駆動コンポーネント２０の通信デバイス（受信側）２００に配信する構成を採用している。ただし、カメラコンポーネント１０の通信デバイス（送信側）１００からカメラ画像データ本体を駆動コンポーネント２０の通信デバイス（受信側）２００に配信して、通信デバイス（受信側）２００側において、画像処理を実行するようにしてもよい。

また、この場合には、通信デバイス（受信側）２００においてカメラ画像データに対する画像処理後、当該処理によって得られた画像処理結果データに基づき、モータＭを駆動するようにすればよい。

［２］ロボットシステムにおける通信原理
［２．１］パブリッシュ／サブスクライブ型の通信方式
次に、本実施形態のロボットシステム１において用いられるパブリッシュ／サブスクライブ型の通信方式について説明する。

本実施形態パブリッシュ／サブスクライブ型の通信方式は、通信デバイス（例えば、本実施形態の通信デバイス１００及び２００）を有するＲＯＳノード（以下、「ノード」という。）が、他のノードとトピックを介して通信する非同期メッセージングモデルである。

特に、パブリッシャーとなるノード（以下、「パブリッシャーノード」ともいう。）は、所定のトピックに対して、マスターとなるノード（以下、「マスターノード」ともいう。）を用いてメッセージ（すなわち、データ）をパブリッシュ（発行）し、また、当該トピックをサブスクライブ（予約購読）する他のノード（以下、「サブスクライバーノード」ともいう。）は、マスターノードを介して当該トピックに対して発行されたメッセージを取得することによって、ノード間におけるデータの送受信が実現される。

そして、本実施形態においては、カメラコンポーネント１０に搭載された通信デバイス（送信側）１００は、パブリッシャーノードとして機能し、具体的には、カメラ画像データに対応する画像処理結果データを、マスターデバイス３０を用いてメッセージとしてパブリッシュするようになっている。

例えば、本実施形態のロボットシステム１は、図１に示すコンポーネント以外に、マイクを接続した音声処理回路、ジャイロセンサ、加速度センサ、及び、温度センサなどの各種センサや処理回路を接続したコンポーネントを有していてもよい。

そして、各センサや処理回路のコンポーネントは、当該センサや当該処理回路に対応するトピックに対して、センサや処理回路において取得されたデータそのもの、又は、当該データに所定の処理を施して得られた処理結果データをメッセージとしてパブリッシュし、当該トピックを介して、他のコンポーネントに、加工したデータを提供するようになっている。

一方、実施形態においては、駆動コンポーネント２０に搭載された通信デバイス（受信側）２００は、サブスクライバーノードとして機能し、カメラコンポーネント１０によってパブリッシュされた画像処理結果データを、マスターデバイス３０を介して、取得するようになっている。

そして、駆動コンポーネント２０は、モータＭを駆動するために参照すべきデータに対応する全てのトピックに属するメッセージをサブスクライブし、他のコンポーネントから得たデータに基づきモータＭを駆動するようになっている。

例えば、本実施形態のロボットシステム１において、画像処理結果データのみに基づき、モータＭを駆動する場合には、駆動コンポーネント２０は、カメラコンポーネント１０によってパブリッシュされる画像処理結果データに対応するトピックのみをサブスクライブするようになっている。

また、例えば、本実施形態のロボットシステム１において、画像処理結果データとともに当該画像処理結果データ以外のデータをも参照して、モータＭを駆動する場合には、駆動コンポーネント２０は、画像処理結果データ以外のデータも含めて当該参照するデータに対応する全てのトピックにパブリッシュされるメッセージについて、サブスクライブするようになっている。

なお、本実施形態においては、駆動コンポーネント２０は、サブスクライブするトピック数は任意に設定できるようになっている。ただし、以下の説明においては、説明の理解を容易化するため、駆動コンポーネント２０が、画像処理結果データのみに基づいて、モータＭを駆動するものとして、説明を行う。すなわち、本実施形態の駆動コンポーネント２０は、カメラコンポーネント１０によってパブリッシュされるメッセージのみをサブスクライブするものとして説明を行う。

［２．２］従来のＲＯＳシステムにおけるパブリッシュ／サブスクライブ型の通信原理
次に、図２を用いて、従来のＲＯＳシステムにおけるパブリッシュ／サブスクライブ型の通信原理について説明する。なお、図２は、従来のＲＯＳシステムにおけるパブリッシュ／サブスクライブ型の通信原理を説明するための図である。

従来のＲＯＳシステムは、図２に示すように以下の方法によってパブリッシュ／サブスクライブ型の通信を実行するようになっている。

（１）まず、パブリッシャーノードとサブスクライバーノードは、例えば、ＸＭＬ−ＲＰＣの通信手順に従って、自ノード（自機ともいう。）に割り当てられた、ＩＰアドレス又はホスト名と、ＸＭＬ−ＲＰＣポート番号と、を含む通信制御データ（以下、「第１通信制御データ」ともいう。）と、自ノードがパブリッシュするメッセージが属するトピック名（例えば、画像処理結果データトピックなど）を示すトピックデータと、が対応付けられたパブリッシャーノード情報を、マスターノードに予めに登録する（図２のステップ［ａ１］）。

（２）次いで、サブスクライバーノードは、自ノードがサブスクライブする特定のトピックに対してメッセージを発行するパブリッシャーノードをマスターノードに広告させて（図２のステップ［ａ２］）、特定トピックに対応する第１通信制御データを、ＸＭＬ−ＲＰＣに従って、マスターノードから取得する（ステップ［ａ２］）。

このとき、マスターノードは、既に登録済みのトピックデータにおいて、サブスクライバーノードから送信されたトピックデータと同一のトピック名を有するトピックデータと対応付けられた第１通信制御データをサブスクライバーノードに配信する。

（３）次いで、サブスクライバーノードは、マスターノードから取得したパブリッシャーノードの第１通信制御データに含まれるＩＰアドレスとＸＭＬ−ＲＰＣポート番号に基づき、パブリッシャーノードのＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ）であるｒｅｑｕｅｓｔＴｏｐｉｃを呼び出し、ＸＭＬ−ＲＰＣに従って、パブリッシャーノードに通信制御データ送受信用の通信コネクション（以下、「第１通信コネクション」ともいう。）の確立要求を送信する（図２のステップ［ａ４］）。

（４）次いで、パブリッシャーノードは、当該確立要求に基づき、サブスクライバーノードとの間において第１通信コネクションを確立し、当該第１通信コネクションを介して、自機のＩＰアドレス及びＴＣＰＲＯＳポート番号を含む第２通信制御データを、ＸＭＬ−ＲＰＣに従って、サブスクライバーノードに送信する（図２のステップ［ａ５］）。

（５）そして、サブスクライバーノードは、第２通信制御データに基づき、自機のサブスクライブするメッセージの送受信に用いるＴＣＰコネクション（以下、「第２通信コネクション」ともいう。）の確立要求（例えば、ＳＹＮパケット）を、ＴＣＰＲＯＳに従って、パブリッシャーノードに送信する（図２のステップ［ａ６］）。

なお、ＴＣＰＲＯＳとは、ＲＯＳにおけるメッセージングのトランスポートレイヤープロトコルであり、標準的なＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ソケットを用いるプロトコルである。また、ＴＣＰＲＯＳは、特に明記しない限り、従来のＴＣＰと同様の処理手順に従って通信を行うものである。

（６）次いで、サブスクライバーノードは、ＴＣＰコネクションの確立要求に基づき、パブリッシャーノードからＴＣＰＲＯＳに従った応答（例えば、ＡＣＫ＋ＳＹＮパケット）を受信する（図２のステップ［ａ７］）。

なお、サブスクライバーノードが、ＴＣＰＲＯＳに従った応答を受信した時点で、パブリッシャーノードとサブスクラバーノード間におけるハンドシェイクが完了し、パブリッシャーノード−サブスクライバーノード間にＴＣＰコネクションが確立される（図２のステップ［ａ８］）。

（７）最後に、パブリッシャーノードとサブスクライバーノードの間にＴＣＰコネクションが確立されると、パブリッシャーノードは、当該ＴＣＰコネクションを介して、サブスクライバーノードにメッセージを送信する処理を繰り返し実行し、データ配信が完了した時点、又は、ＲＯＳシステムの電源がＯＦＦにされた時点で、処理を終了する。

［３．２］本実施形態のパブリッシュ／サブスクライブ型通信における基本原理
次に、本実施形態のロボットシステム１おいて、パブリッシュ／サブスクライブ型通信における基本原理について説明する。

本実施形態において、ロボットシステム１の自律駆動を実現するためには、カメラコンポーネント１０は、当該カメラコンポーネント１０に接続されたカメラＣにおいて撮像されたカメラ画像に対して、リアルタイムに画像処理を実行するとともに、画像処理結果データを、各駆動コンポーネント２０に対して、リアルタイムに供給する必要がある。

例えば、ロボットシステム１を陸上移動させる場合には、周囲環境に合わせて、ロボットシステム１の各部を駆動させる必要があるため、カメラコンポーネント１０は、カメラ画像データに基づき、リアルタイムに画像処理結果データを生成するとともに、当該画像処理結果データをリアルタイムにロボットシステム１の各駆動コンポーネント２０に配信することが必要である。

一方、上述したようにロボットシステム１は、バッテリーによって駆動されるケースが多く、消費電力を削減することが求められるので、当該ロボットシステム１に、マルチコアなどの消費電力量が大きい高性能なマイクロプロセッサを搭載することは難しい。

そこで、本実施形態のロボットシステム１は、駆動コンポーネント２０に形成される通信デバイス２００が必要なメッセージ（すなわち、実データ）を受信する際の通信コネクションを確立するまでの通信制御については、アプリケーション（ソフトウエア）と連動するＸＭＬ−ＲＰＣなどの通信プロトコルを用いるとともに、メッセージの配信については、並列処理が可能な論理回路の出力を他の通信デバイスに直接的に提供するためのＴＣＰＲＯＳなどの通信プロトコルを用いることができるようになっている。

特に、本実施形態のロボットシステム１は、１ポート及び１セッションに機能を限定したハードウエアＴＣＰ／ＩＰスタックと、画像処理と並列して、当該通信ポートを利用した、ＦＰＧＡによるハードウエア通信処理を実行し、画像処理によって得られた画像処理結果データを駆動コンポーネント２０の通信デバイス（受信側）２００に順次、配信するＦＰＧＡと、を通信デバイス（送信側）１００に搭載するようになっている。

また、本実施形態のロボットシステム１は、ＦＰＧＡに通信ポートが１つしかないため、ＸＭＬ−ＲＰＣに従った処理（すなわち、図２のステップ［ａ１］〜［ａ５］の処理）をＦＰＧＡに実行させることができないので、ＴＣＰＲＯＳに従った通信パート（すなわち、図２のステップ［ａ６］〜［ａ８］）を、ＦＰＧＡを用いた制御処理によって実行するようになっている。

すなわち、本実施形態のロボットシステム１は、ＸＭＬ−ＲＰＣに従った図２のステップ［ａ１］〜［ａ５］の通信処理（以下、「ＸＭＬ−ＲＰＣ通信パート」という。）に関しては、ＦＰＧＡではなく、通信デバイス（送信側）１００に搭載したアプリケーションに連動するマイクロプロセッサ（ＣＰＵ）を用いて実行し、メッセージの配信に関しては、ＦＰＧＡを用いた制御処理によって実行するようになっている。

また、本実施形態のロボットシステム１は、通信デバイス１００に搭載するマイクロプロセッサによって、画像処理及びＴＣＰＲＯＳ通信パートの処理を実行する必要性がなくなり、本来通信デバイス１００のマイクロプロセッサが担当すべき処理の大部分をＦＰＧＡにオフロードし、マイクロプロセッサの担当する処理を減らすことができるようになっている。

したがって、本実施形態のロボットシステム１は、通信デバイス１００の消費電力を低減し、かつ、処理能力が十分ではないシングルコアなどのマイクロプロセッサを用いた場合であっても、リアルタイム性を確保しつつ、画像処理結果データを配信できるので、例えば、マルチコアを搭載した高性能なマイクロプロセッサを通信デバイス１００に搭載する必要がなくなり、画像処理及び通信処理の高速化と、低消費電力化を両立することができるようになっている。

なお、本実施形態においては、パブリッシャーノードとなる通信デバイス（送信側）１００は、アプリケーションを実行することによって実現されるパブリッシャーノード（以下、「パブリッシャーアプリケーションノード」という。）と、ＦＰＧＡを用いた制御処理を実行することによって実現されるパブリッシャーノード（以下、「パブリッシャーＦＰＧＡノード」という。）の２つのノードを有している。

そして、本実施形態においては、通信デバイス（送信側）１００は、パブリッシャーアプリケーションノードと、パブリッシャーＦＰＧＡノードと、に対して、それぞれ、異なるＩＰアドレス及びポート番号を割り当て、両者を論理的にかつ物理的に分離する構成を有している。

また、ＲＯＳにおけるパブリッシュ／サブスクライブ型の通信モデルにおいては、ＵＤＰ（ｕｓｅｒ ｄｉａｇｒａｍ ｐｒｏｔｏｃｏｌ）もサポートされており、厳格なリアルタイム性を要求される場合には、ＵＤＰを用いることも可能である。ただし、本実施形態においては、通信時におけるデータの欠落やエラーの発生を防止するため、ＴＣＰを用いた通信方式を採用するようになっている。

さらに、通信デバイス（送信側）１００に対して割り当てるＩＰアドレス及びポート番号は、固定設定されていてもよいし、変動するように設定されていてもよい。ただし、ロボットシステム１を構成するコンポーネントの数は、通常変動することはなく、通信方式が簡素化し、かつ、通信トラブルの発生を抑制することもできるので、本実施形態においては、固定したＩＰアドレス及び固定したポート番号が予め割り当てられることが好ましい。

［２．３］本実施形態のパブリッシュ／サブスクライブの通信原理
次に、本実施形態のロボットシステム１における通信原理について説明する。なお、図３は、本実施形態のロボットシステム１において実行される通信原理について説明するための図である。

本通信原理の説明においては、パブリッシャーアプリケーションノード及びパブリッシャーＦＰＧＡノードに対して、それぞれ、「ｆｏｏ」と、「ＦＰＧＡ」なるホスト名を割り当てるとともに、パブリッシャーアプリケーションノードに、ＸＭＬ−ＲＰＣポート番号「１２３４」、及び、パブリッシャーＦＰＧＡノードにＴＣＰＲＯＳポート番号「３４５６」が静的に割り当てた場合をもちいて説明する。

なお、図３は、通信デバイス（送信側）１００及び通信デバイス（受信側）２００が、トピック「ｂａｒ」を介して画像処理結果データの送受信を行う場合を例にロボットシステム１の通信動作を示しており、ＸＭＬ−ＲＰＣに従った手順を点線矢印、及び、ＴＣＰＲＯＳに従った手順を実線矢印によって示している。

本実施形態のパブリッシャーＦＰＧＡノードは、ロボットシステム１の電源が投入されると、
（Ａ１）自ノードに割り当てられたホスト名「ＦＰＧＡ」及びポート番号「３４５６」から構成される第２ＩＰアドレスを含む第２通信制御データと、
（Ａ２）自ノードがパブリッシュするメッセージに対応するトピック名「ｂａｒ」を示すトピックデータと、
を有するアドバタイズ要求を、パブリッシャーアプリケーションノードに送信する（図３のステップ［ｂ０］）。

次いで、パブリッシャーアプリケーションノードは、アドバタイズ要求の受信をトリガとして、ＸＭＬ−ＲＰＣに従って、
（Ｂ１）自ノードに割り当てられたホスト名「ｆｏｏ」及びポート番号「１２３４」を含む第１通信制御データと、
（Ｂ２）トピックをパブリッシュする画像処理結果データに対応するトピックデータ「ｂａｒ」と、
を対応付けたパブリッシャーノード情報を、マスターデバイス３０にアドバタイズして、マスターデバイス３０に登録する（図３のステップ［ｂ１］）。

そして、サブスクライバーノード（通信デバイス（受信側）２００）は、ＸＭＬ−ＲＰＣに従って、自ノードのサブスクライブするデータの特定トピックを示すトピックデータ「ｂａｒ」をマスターデバイス３０にアドバタイズ（すなわち、広告）する（図３のステップ［ｂ２］）。

次いで、マスターデバイス３０は、ＸＭＬ−ＲＰＣに従って、トピック「ｂａｒ」に対応する画像処理結果データを、パブリッシュするノード（すなわち、パブリッシャーノード）の情報として、パブリッシャーアプリケーションノードのホスト名「ｆｏｏ」とポート番号「１２３４」を含む第１通信制御データをサブスクライバーノードに通知する（図３のステップ［ｂ３］）。

次いで、サブスクライバーノードは、マスターデバイス３０から取得したパブリッシャーアプリケーションノードに対応する第１通信制御データに基づき、ＸＭＬ−ＲＰＣに従いつつ、ｒｅｑｕｅｓｔＴｏｐｉｃを用いてパブリッシャーアプリケーションノードに第１通信コネクションの確立要求を送信する（図３のステップ［ｂ４］）。

なお、パブリッシャーＦＰＧＡノードとパブリッシャーアプリケーションノード間における通信に対して、専用の通信ポートを設ける必要はなく、パブリッシャーＦＰＧＡノードとパブリッシャーアプリケーションノード間において各種の通信を実行するように設計することによって、ＦＰＧＡに設ける通信ポート数の増加を防止するようになっている。

次いで、パブリッシャーアプリケーションノードは、ＸＭＬ−ＲＰＣに従って、ステップ［ｂ０］において、パブリッシャーＦＰＧＡノードから取得した第２通信制御データ（すなわち、パブリッシャーＦＰＧＡノードに対応するホスト名「ＦＰＧＡ」及びポート番号「３４５６」）を、第１通信コネクションを介してサブスクライバーノードに通知する（図３のステップ［ｂ５］）。

次いで、サブスクライバーノードは、パブリッシャーアプリケーションノードからパブリッシャーＦＰＧＡノードのホスト名などを含む第２通信制御データを取得すると、第２通信制御データに基づき、パブリッシャーＦＰＧＡノード（すなわち、ＦＰＧＡ）との間においてＴＣＰＲＯＳに従って、パブリッシャーＦＰＧＡノードに第２通信コネクションの確立要求をする（図３のステップ［ｂ６］）。

次いで、サブスクライバーノードは、ＴＣＰコネクションの確立要求に基づき、パブリッシャーＦＰＧＡノードからＴＣＰＲＯＳに従った応答（例えば、ＡＣＫ＋ＳＹＮパケット）を受信する（図３のステップ［ｂ７］）。

なお、サブスクライバーノードが、ＴＣＰＲＯＳに従った応答を受信した時点で、パブリッシャーＦＰＧＡノードとサブスクラバーノード間におけるハンドシェイクが完了し、パブリッシャーＦＰＧＡノード−サブスクライバーノード間にＴＣＰコネクションが確立される（図３のステップ［ａ８］）。

最後に、パブリッシャーＦＰＧＡノードとサブスクライバーノードの間にＴＣＰコネクションが確立されると、パブリッシャーＦＰＧＡノードは、画像処理と並列して、当該処理によって得られた画像処理結果データを、当該ＴＣＰコネクションを介して、サブスクライバーノードにメッセージを送信する処理を繰り返し実行し、データ配信が完了した時点、又は、ＲＯＳシステムの電源がＯＦＦにされた時点で、処理を終了する。

［３］通信デバイス（送信側）
次に、図４を参照して本実施形態の通信デバイス（送信側）１００について説明する。なお、図４は、本実施形態の通信デバイス（送信側）１００の一構成例を示すブロック図である。

本実施形態の通信デバイス（送信側）１００は、図４に示すようにアプリケーションを実行するアプリケーション実行部１１０と、ＦＰＧＡによって実現されるＦＰＧＡ制御処理部１２０と、を有している。

アプリケーション実行部１１０は、通信デバイス（受信側）２００に画像処理結果データを送信する際に、上記ＸＭＬ−ＲＰＣ通信パートに対応する通信処理を実行して、パブリッシャーアプリケーションノードとしての機能を実現する。

また、アプリケーション実行部１１０は、ＴＣＰ／ＩＰスタック１１１と、解釈部１１２と、制御部１１３と、ＸＭＬ−ＲＰＣメッセージ生成部１１４と、を有している。

ＴＣＰ／ＩＰスタック１１１は、アプリケーションによって実現され、ＴＣＰ／ＩＰ通信を行うために用いられる。特に、ＴＣＰ／ＩＰスタック１１１は、ＴＣＰ／ＩＰに従ってデータの送受信を行うため、ネットワークレイヤー及びトランスポートレイヤーに関する処理を実行する。

また、ＴＣＰ／ＩＰスタック１１１は、イーサネット（登録商標）Ｎを介して通信デバイス（受信側）２００及びマスターデバイス３０から送信されたデータを受信し、受信したデータをプロトコル変換して解釈部１１２に供給する。

具体的には、ＴＣＰ／ＩＰスタック１１１は、図４に示すように、
（Ａ１）図３のステップ［ｂ０］において、パブリッシャーＦＰＧＡノードとなるＦＰＧＡ制御処理部１２０（ＦＰＧＡ）から通知されるパブリッシャーＦＰＧＡノードのホスト名及びＴＣＰＲＯＳポート番号を含む第２通信制御データと、トピックデータと、を受信して解釈部１１２に供給し、
（Ａ２）図３のステップ［ｂ４］において、サブスクライバーノードとなる通信デバイス（受信側）２００からｒｅｑｕｅｓｔＴｏｐｉｃを用いて送信される第１通信コネクションの確立要求を受信し、当該受信したデータを解釈部１１２に出力する。

一方、ＴＣＰ／ＩＰスタック１１１は、ＸＭＬ−ＲＰＣメッセージ生成部１１４から供給されるデータをイーサネット（登録商標）Ｎに送信する。

具体的には、ＴＣＰ／ＩＰスタック１１１は、図４に示すように、
（Ｂ１）図３のステップ［ｂ１］において、ＸＭＬ−ＲＰＣに従った形式で、ＸＭＬ−ＲＰＣメッセージ生成部１１４から供給されるパブリッシャーアプリケーションノードのホスト名（例えば、図３に例示する場合には「ｆｏｏ」）及びＸＭＬ−ＲＰＣポート番号（例えば、図３に例示する場合には、「１２３４」）を含む第１通信制御データと、トピックデータ（例えば、図３に例示する場合には、「トピック名：ｂａｒ」）と、を対応付けたパブリッシャーノード情報を、マスターデバイス３０に送信し、
（Ｂ２）図３のステップ［ｂ５］において、第１通信コネクションを介して、ＸＭＬ−ＲＰＣに従った形式でＸＭＬ−ＲＰＣメッセージ生成部１１４から供給されるパブリッシャーＦＰＧＡノードのホスト名（例えば、図３に例示する場合には「ＦＰＧＡ」）及びＴＣＰＲＯＳポート番号（例えば、図３に例示する場合には「３４５６」）を含む第２通信制御データを通信デバイス（受信側）２００に送信する。

解釈部１１２は、ＴＣＰ／ＩＰスタック１１１から供給されるデータに対してＸＭＬ−ＲＰＣに基づく処理を実行し、当該処理されたデータを制御部１１３に供給する。

制御部１１３は、ＣＰＵを有し、所定のアプリケーションをＣＰＵによって実行することによって、パブリッシャーアプリケーションノードとして機能するアプリケーション実行部１１０の各処理を制御する。

特に、制御部１１３は、上記図４ステップ［ｂ０］において、解釈部１１２からパブリッシャーＦＰＧＡノードに対応する第２通信制御データの付加されたアドバタイズ要求がＴＣＰ／ＩＰスタック１１１に供給された場合に、通信デバイス（受信側）２００に第２通信制御データを配信するまでの間、当該第２通信制御データを図示せぬメモリに一時記憶させ、その管理を実行する。

また、制御部１１３は、アプリケーション実行部１１０に割り当てられた第１通信制御データ、ＦＰＧＡ制御処理部１２０に割り当てられた第２通信制御データ及びトピックデータを図示せぬメモリに一時記憶させ、その管理を実行する。

ＸＭＬ−ＲＰＣメッセージ生成部１１４は、制御部１１３による制御の下、通信デバイス（受信側）２００及びマスターデバイス３０に対して送信する各種のデータをＸＭＬ−ＲＰＣの形式に変換して、ＴＣＰ／ＩＰスタック１１１に供給することで、通信デバイス（受信側）２００及びマスターデバイス３０に各種のデータを送信させる。

ＦＰＧＡ制御処理部１２０は、ＦＰＧＡによって構成され、パブリッシャーＦＰＧＡノードとしての機能を実現する。

特に、ＦＰＧＡ制御処理部１２０は、例えば、カメラＣから供給されるカメラ画像データに対して各種の画像処理を実行して画像処理結果データを生成するとともに、通信デバイス（受信側）２００との間においてパブリッシュ／サブスクライブ型の通信を行う際に、ＴＣＰＲＯＳ通信パート処理を実行する機能を有している。

また、ＦＰＧＡ制御処理部１２０は、ＴＣＰ／ＩＰ通信用のＴＣＰ／ＩＰスタック１２１と、解釈部１２２と、制御部１２３と、登録処理部１２４と、カメラ画像データの入力インターフェースであるデータ入力部１２５と、カメラ画像データに画像処理を施すためのデータ処理部１２６と、符号化処理部１２７と、マルチプレクサ１２８と、を有している。

ＴＣＰ／ＩＰスタック１２１は、例えば、ＳｉＴＣＰなどのＦＰＧＡに搭載されたハードウエアＴＣＰ／ＩＰスタックであり、１ポート１セッションにてイーサネット（登録商標）Ｎを介したＴＣＰ／ＩＰ通信処理を実行する。

特に、ＴＣＰ／ＩＰスタック１２１は、イーサネット（登録商標）Ｎから受信したデータをＴＣＰ／ＩＰに従って処理し、当該処理後のデータを解釈部１２２に供給する受信部１２１１と、マルチプレクサ１２８から供給されるデータに対してＴＣＰ／ＩＰに従った処理を実行してデータを送信するための処理を実行する送信部１２１２と、を有している。

具体的には、受信部１２１１は、図４に示すように、図３のステップ［ｂ６］において、通信デバイス（受信側）２００から送信されるＴＣＰコネクションの確立要求を受信し、送信部１２１２と連動しつつ、通信デバイス（受信側）２００との間においてＴＣＰコネクションを確立するための処理を実行する。

また、送信部１２１２は、
（１）図３のステップ［ｂ０］において、マルチプレクサ１２８から第２通信制御データ（すなわち、図３に例示する場合には、ホスト名「ＦＰＧＡ」及びＴＣＰＲＯＳポート番号「３４５６」）と、トピックデータ（例えば、図３に例示する場合には「ｂａｒ」）と、が供給されると、当該供給されたデータをアプリケーション実行部１１０に送信し、
（２）図３のステップ［ｂ７］において、マルチプレクサ１２８から画像処理結果データが供給されると、当該画像処理結果データを、順次、通信デバイス（受信側）２００に送信する（図３のステップ［ｂ７−１］、［ｂ７−２］…）。

なお、本実施形態においては、第２通信制御データ及びトピックデータに関しては、通信デバイス（送信側）１００内部において入出力を行うものであるため、送信部１２１２は、イーサネット（登録商標）Ｎを介して送受信を行う必要はなく、アプリケーション実行部１１０に対して直接送信する構成になっている。

解釈部１２２は、受信部１２１１から供給されるデータに対して、ＴＣＰＲＯＳに従って、プロトコル変換などの処理を施して、制御部１２３に供給する。

制御部１２３は、登録処理部１２４、符号化処理部１２７及びマルチプレクサ１２８に接続され、これら各部に制御信号を供給して、各部の動作を制御する。

登録処理部１２４は、ＴＣＰ／ＩＰスタック１２１を介して、ＦＰＧＡ制御処理部１２０に割り当てられたホスト名及びポート番号を含む第２通信制御データ及びトピックデータを付加したアドバタイズ要求をアプリケーション実行部１１０に送信するための処理を実行する。

なお、ＦＰＧＡ制御処理部１２０に割り当てられた第２通信制御データ及びトピックデータは、通信デバイス（送信側）１００に設けられた図示せぬメモリ内に予め記録されており、登録処理部１２４は、が当該メモリから第２通信制御データを読み出しつつ、アプリケーション実行部１１０に送信する。

データ入力部１２５は、所定の入力インターフェースであり、カメラＣから供給されるカメラ画像データをデータ処理部１２６に供給する。

データ処理部１２６は、カメラ画像データに対して、ノイズ除去、色変換、特徴点検出、ニューラルネットワーク、又は、画像認識処理などの各種画像処理を実行して画像処理結果データを生成し、生成した画像処理結果データを符号化処理部１２７に供給する。

符号化処理部１２７は、データ処理部１２６から供給される画像処理結果データを、ＲＯＳシステムに用いられるデータ形式に変換する。すなわち、符号化処理部１２７は、画像処理結果データのＴＣＰＲＯＳプロトコルへの変換する変換処理、及び、テキスト形式やＸＭＬ形式への変換処理を実行する。

そして、符号化処理部１２７は、各種処理後の画像処理結果データをマルチプレクサ１２８に供給する。

なお、符号化処理部１２７は、さらに画像処理結果データにデータ圧縮処理や冗長化処理を施すようにしてもよい。

マルチプレクサ１２８は、制御部１２３による制御の下、登録処理部１２４から供給されるアドバタイズ要求（第２通信制御データ及びトピックデータの付加されたデータ）と、符号化処理部１２７から供給される画像処理結果データの何れか一方を選択しつつ、送信部１２１２に出力する。

［４］ロボットシステムの動作
次に、図５を用いて本実施形態のロボットシステム１において実行される各トピックのメッセージの取得する処理（以下、「メッセージの取得処理」ともいう。）の動作について説明する。なお、図５は、本実施形態のロボットシステム１におけるメッセージの取得開始処理を示すシーケンス図である。

本動作は、カメラコンポーネント１０から提供されるトピックに関するトピックデータを駆動コンポーネント２０によって取得する場合を用いて説明する。

なお、本動作は、主に、該当するトピックデータをマスターデバイスに登録する登録処理（以下、「トピックデータの登録処理」ともいう。）と、登録されたメッセージの取得を開始する処理（以下、「メッセージの取得開始処理」ともいう。）と、の２つの処理によって構成される。

（トピックデータの登録処理）
まず、カメラコンポーネント１０の通信デバイス（送信側）１００においては、ＦＰＧＡ制御処理部１２０は、ロボットシステム１の電源がＯＮされたタイミングなどの所定のタイミングに、予め割り当てられたホスト名及びポート番号を含む第２通信制御データと、トピックデータと、を有するアドバタイズ要求をアプリケーション実行部１１０（具体的には、ＴＣＰ／ＩＰスタック１１１）に送信する（ステップＳａ１０１）。

具体的には、登録処理部１２４は、制御部１２３の制御指示に基づいて、図示せぬメモリからＦＰＧＡ制御処理部１２０に対応する第２通信制御データ及びトピックデータを読み出し、当該第２通信制御データ等を有するアドバタイズ要求をマルチプレクサ１２８に供給する。

また、マルチプレクサ１２８は、制御部１２３の制御指示に基づいて、登録処理部１２４から供給されるデータを選択して、送信部１２１２に供給し、送信部１２１２は、第２通信制御データが付加されたアドバタイズ要求をアプリケーション実行部１１０のＴＣＰ／ＩＰスタック１１１に送信する。

なお、アプリケーション実行部１１０（具体的には、制御部１１３）は、アドバタイズ要求に付加された第２通信制御データを抽出して、図示せぬメモリに一時記憶させる。

次いで、アプリケーション実行部１１０は、当該アプリケーション実行部１１０に割り当てられた第１通信制御データとトピックデータを図示せぬメモリから読み出して、当該第１通信制御データとトピックデータを対応付けて、マスターデバイス３０に登録する（ステップＳａ１０２）。

なお、マスターデバイス３０は、通信デバイス（送信側）１００からトピックデータ及び第１通信制御データを受信すると、当該受信したデータを図示せぬメモリに対応付けて記憶する。

（トピックデータの登録処理）
一方、駆動コンポーネント２０の通信デバイス（受信側）２００は、ロボットシステム１の電源ＯＮなどの所定のタイミングに、サブスクライブするトピック名を示すトピックデータをＸＭＬ−ＲＰＣに従って、マスターデバイス３０に送信する（ステップＳａ２０１）。

そして、マスターデバイス３０は、通信デバイス（受信側）２００から受信したトピックデータと同一のトピック名のトピックデータと対応付けて記録された第１通信制御データを読み出し、ＸＭＬ−ＲＰＣに従って、当該第１通信制御データを、通信デバイス（受信側）２００に送信する（ステップＳａ３０１）。

次いで、通信デバイス（受信側）２００は、受信した第１通信制御データに基づき、ｒｅｑｕｅｓｔＴｏｐｉｃを用いて、通信デバイス（送信側）１００のアプリケーション実行部１１０に対して、第１通信コネクションの確立要求を送信する（ステップＳａ２０２）。

なお、このとき、通信デバイス（送信側）１００においては、この確立要求がＴＣＰ／ＩＰスタック１１１によって受信され、解釈部１１２によってデータ形式が変換されて、制御部１１３に供給される。

一方、通信デバイス（送信側）１００においては、アプリケーション実行部１１０は、通信デバイス（受信側）２００との間において第１通信コネクションを確立すると（ステップＳａ２０３）、メモリに一時記憶された第２通信制御データを、第１通信コネクションを介して、通信デバイス（受信側）２００に送信する（ステップＳａ１０３）。

具体的には、制御部１１３は、メモリに一時記憶された第２通信制御データを読み出して、ＸＭＬ−ＲＰＣメッセージ生成部１１４に供給し、ＸＭＬ−ＲＰＣメッセージ生成部１１４は、制御部１１３の指示に基づいて、供給される第２通信制御データをＸＭＬ−ＲＰＣ形式のデータに変換して、ＴＣＰ／ＩＰスタック１１１に供給する。

次いで、通信デバイス（受信側）２００は、第２通信制御データを受信すると、当該受信した第２通信制御データに基づいて、通信デバイス（送信側）１００のＦＰＧＡ制御処理部１２０のホスト名及びＴＣＰＲＯＳポート番号を指定しつつ、ＴＣＰコネクションの確立要求（例えばＳＹＮパケット）を該当するＦＰＧＡ制御処理部１２０に送信し（ステップＳａ２０４）、通信デバイス（受信側）２００との間においてＴＣＰコネクションを確立すると本動作を終了させる。

他方、通信デバイス（送信側）１００においては、ＦＰＧＡ制御処理部１２０は、ＴＣＰコネクションの確立要求を受信すると、通信デバイス（受信側）２００に応答（例えばＡｃｋ＋ＳＹＮパケットの送信）し、通信デバイス（受信側）２００との間においてＴＣＰコネクションを確立する（ステップＳａ２０５）。

具体的には、受信部１２１１は、通信デバイス（受信側）２００に応答（例えばＡｃｋ＋ＳＹＮパケットの送信）し、通信デバイス（受信側）２００との間においてＴＣＰコネクションを確立する。

また、このとき、解釈部１２２は、ＴＣＰコネクションの確立要求をＴＣＰＲＯＳに従って、プロトコル変換して、制御部１２３に供給する。

次いで、ＦＰＧＡ制御処理部１２０は、ＴＣＰコネクションを確立すると、画像処理結果データをＲＯＳに対応したフォーマットへの変換を開始し、かつ、通信デバイス（受信側）２００への当該画像処理結果データの送信（メッセージの配信）を開始して（ステップＳａ１０４）本動作を終了させる。

特に、ＦＰＧＡ制御処理部１２０においては、制御部１２３は、解釈部１２２から確立要求が供給されると、符号化処理部１２７及びマルチプレクサ１２８に対して、データ処理部１２６から供給される画像処理結果データをＲＯＳに対応したフォーマットへの変換を開始させつつ、当該フォーマット変換された画像処理結果データの通信デバイス（受信側）２００への送信を開始させる。

また、マルチプレクサ１２８は、制御信号に従い、符号化処理部１２７から供給される画像処理結果データを選択して、送信部１２１２に出力し、送信部１２１２に画像処理結果データを送信させる。

［５］変形例
［５．１］変形例１
本動作は、サブスクライバーノードとしての通信デバイス（受信側）２００について特に限定されていないが、当該通信デバイス（受信側）２００も、カメラコンポーネント１０に形成される通信デバイス１００が必要なメッセージ（すなわち、実データ）を受信する際の通信コネクションを確立するまでの通信制御については、アプリケーション（ソフトウエア）と連動するＸＭＬ−ＲＰＣなどの通信プロトコルを用いるとともに、メッセージの受信については、並列処理が可能な論理回路によって他の通信デバイスから出力されたメッセージを直接的に並列に処理するＴＣＰＲＯＳなどの通信プロトコルを用いる構成を有していてもよい。

この場合には、本実施形態の信デバイス（受信側）２００は、
（Ｂ１）所定のアプリケーションと連動するＸＭＬ−ＲＰＣに従って、通信デバイス（送信側）１００がマスターデバイス３０に登録している通信制御用のデータであって、当該データ通信を行う際に割り当てられた第１ＩＰアドレスを含む第１通信制御用データを、当該マスターデバイス３０から、取得し、
（Ｂ２）特定のトピックにおけるＸＭＬ−ＲＰＣを含む第１通信制御用データに基づいて、該当する通信デバイス（送信側）１００に、ＸＭＬ−ＲＰＣに従って、当該特定のトピックに関するメッセージの通信を実行するための第１通信コネクションの確立要求を実行し、
（Ｂ３）第１通信コネクションの確立要求が受け付けられた場合に、ＸＭＬ−ＲＰＣに従って、当該確立要求を受け付けた通信デバイス（送信側）１００との第１通信コネクションを確立し、
（Ｂ４）ＦＰＧＡを用いるＴＣＰＲＯＳによって特定されたトピックにおけるメッセージを確立要求を受け付けた通信デバイス（送信側）１００によって配信するための通信用制御データであって、当該メッセージを配信する際に用いる第２ＩＰアドレスを含む第２通信用制御データを、ＸＭＬ−ＲＰＣに従って、第１通信コネクションが確立された通信デバイス（送信側）１００から取得し、
（Ｂ５）配信された第２通信用制御データに含まれる第２ＩＰアドレスを用いることによって、第１通信コネクションが確立された通信デバイス（送信側）１００に、ＴＣＰＲＯＳに従って、特定のトピックにおけるメッセージのデータ通信を実行するための第２通信コネクションの確立要求を実行し、
（Ｂ６）ＴＣＰＲＯＳに従って、当該確立要求を受け付けた通信デバイス（送信側）１００との第２通信コネクションを確立し、
（Ｂ７）ＴＣＰＲＯＳに従って、確立された第２通信コネクションを介して、ＦＰＧＡから出力された特定のトピックにおけるメッセージを、該当する通信デバイス（送信側）１００から取得する、
構成を有している。

そして、本実施形態の通信デバイス（受信側）２００は、取得したメッセージをＦＰＧＡの論理回路によって並列処理する構成を有している。

本実施形態の通信デバイス（受信側）２００は、図６に示すように、アプリケーションを実行するアプリケーション実行部２１０と、ＦＰＧＡによって実現されるＦＰＧＡ制御処理部２２０と、を有している。なお、図６は、本実施形態の通信デバイス（受信側）２００の一構成例を示すブロック図である。

アプリケーション実行部２１０は、通信デバイス（送信側）１００から画像処理結果データを取得する際に、上記ＸＭＬ−ＲＰＣ通信パートに対応する通信処理を実行し、サブスクライバーのパブリッシャーアプリケーションノードとしての各機能を実現する。

また、アプリケーション実行部２１０は、ＴＣＰ／ＩＰスタック２１１と、解釈部２１２と、制御部２１３と、ＸＭＬ−ＲＰＣメッセージ生成部２１４と、を有している。

ＴＣＰ／ＩＰスタック２１１は、イーサネット（登録商標）Ｎを介して、通信デバイス（送信側）１００及びマスターデバイス３０から送信されたデータを受信してプロトコル変換を実行し、当該プロトコル変換をしたデータを解釈部２１２に供給する。

具体的には、ＴＣＰ／ＩＰスタック２１１は、
（１）ＦＰＧＡ制御処理部２２０により送信されるトピック要求を受信して、解釈部２１２に出力し、
（２）マスターデバイス３０により送信される通信デバイス（送信側）１００のホスト名及びＸＭＬ−ＲＰＣポート番号を含む第１通信制御データを受信して、解釈部２１２に出力し、
（３）通信デバイス（送信側）１００により送信される第２通信制御データを受信して、解釈部２１２に出力する。

さらに、ＴＣＰ／ＩＰスタック２１１は、自身がサブスクライブするトピックに対応するトピックデータをＸＭＬ−ＲＰＣ形式に変換し、当該変化したデータをマスターデバイス３０に送信し、通信デバイス（送信側）１００のｒｅｑｕｅｓｔＴｏｐｉｃを呼び出しつつ、ＸＭＬ−ＲＰＣメッセージ生成部２１４から供給されるＸＭＬ−ＲＰＣ形式の第１通信コネクション確立要求を通信デバイス（送信側）１００に送信する。

解釈部２１２は、ＴＣＰ／ＩＰスタック１１１から供給されるデータに対してＸＭＬ−ＲＰＣに基づく処理を実行し、当該処理されたデータを制御部２１３に供給する。

制御部２１３は、ＣＰＵを有し、所定のアプリケーションをＣＰＵで実行することによって、サブスクライバーのアプリケーションノードとして機能するアプリケーション実行部２１０の各処理を制御する。

ＸＭＬ−ＲＰＣメッセージ生成部２１４は、制御部２１３による制御の下、通信デバイス（送信側）１００及びマスターデバイス３０に対して送信する各種のデータをＸＭＬ−ＲＰＣの形式に変換して、ＴＣＰ／ＩＰスタック１１１に供給し、通信デバイス（送信側）１００及びマスターデバイス３０宛てに各種のデータを送信させる。

ＦＰＧＡ制御処理部２２０は、モータＭの接続されたＦＰＧＡによって構成され、サブスクライバーハードウエアとしての機能を実現し、ＴＣＰＲＯＳ通信パート処理を実行する機能を有している。

また、ＦＰＧＡ制御処理部２２０は、通信デバイス（送信側）１００から供給される画像処理結果データに基づき、モータＭを駆動するための処理を実行する。

特に、ＦＰＧＡ制御処理部２２０は、ＴＣＰ／ＩＰ通信用のＴＣＰ／ＩＰスタック２２１と、解釈部２２２と、制御部２２３と、要求処理部２２４と、接続処理部２２５と、マルチプレクサ２２６と、復号化処理部２２７と、データ処理部２２８と、データ出力部２２９と、を有している。

特に、ＴＣＰ／ＩＰスタック２２１は、イーサネット（登録商標）Ｎから受信したデータをＴＣＰ／ＩＰに従って処理し、当該処理後のデータを解釈部２２２に供給する受信部２２１１と、マルチプレクサ２２６から供給されるデータに対してＴＣＰ／ＩＰに従った処理を実行してデータを送信するための処理を実行する送信部２２１２と、を有している。

具体的には、受信部２２１１は、
（１）アプリケーション実行部２１０により送信される通信デバイス（送信側）１００に対応する第２通信制御データを受信して、解釈部２２２に供給するとともに、
（２）通信デバイス（送信側）１００により送信される画像処理結果データを受信して、解釈部２２２に供給する。

また、送信部２２１２は、
（１）マルチプレクサ２２６から供給されるトピック要求をアプリケーション実行部２１０に送信するとともに、
（２）マルチプレクサ２２６から供給されるデータ（すなわち、ＴＣＰコネクションの確立要求）を通信デバイス（送信側）１００に送信する。

なお、トピックの広告に関しては、通信デバイス（受信側）２００内部において入出力を行うものであるため、イーサネット（登録商標）Ｎを介して送受信する必要はなく、送信部１２１２が、アプリケーション実行部２１０に対して直接送信する構成になっている。

解釈部２２２は、受信部２２１１、制御部２２３及び復号化処理部２２７に接続され、受信部１２１１から供給されるデータに対して、ＴＣＰＲＯＳに従った、プロトコル変換等の処理を施して、各部に供給する。

このとき、解釈部２２２は、通信デバイス（送信側）１００から送信された画像処理結果データに関しては、復号化処理部２２７に供給するとともに、アプリケーション実行部２１０により送信された通信デバイス（送信側）１００の通信制御データに関しては、制御部１２３に供給する。

制御部２２３は、ＦＰＧＡ制御処理部２２０の各部を統合制御するため、要求処理部２２４、接続処理部２２５及びマルチプレクサ２２６に接続され、これらに対して制御を実行する。

復号化処理部２２７は、解釈部２２２から供給されるデータ（すなわち画像処理結果データに対応するデータ）に対して、通信デバイス（送信側）１００において実行される符号化形式に対応した復号化処理を実行する。

具体的には、復号化処理部２２７は、解釈部２２２から供給されるデータをＲＯＳに対応する形式からＦＰＧＡ上で扱う数値データ表現への変換処理を行う。すなわち、復号化処理部２２７は、ＴＣＰＲＯＳプロトコルからの変換、テキスト形式やＸＭＬ形式からの変換、ネットワークバイトオーダの変換、データ伸長処理、冗長化符号からの復号処理などを実行する。

データ処理部２２８は、復号化処理部２２７から供給される画像処理結果データに基づき、モータの種別、個体差に応じた制御上の誤差を補正するため、キャリブレーションを行いつつ、画像処理結果データに基づき、モータの駆動量、駆動時間、駆動速度等を決定するための演算を行い、演算結果に対応するデータをデータ出力部２２９に供給する。

データ出力部２２９は、モータＭの駆動回路を有し、入力端が、データ処理部２２８に、出力端が、モータＭに、各々、接続され、データ処理部２２８から供給されるデータに基づき、モータＭを駆動させるようになっている。
この結果、駆動コンポーネント２０において、モータＭが駆動され、障害物回避等の自律的な動作が実現されることとなる。

［５．２］変形例２
本変形例においては、第１実施施形態のように、パブリッシャーノードをパブリッシャーアプリケーションノードと、パブリッシャーＦＰＧＡノードに分割し、又は、変形例１のように、サブスクライバーノードを、サブスクライバーアプリケーションノードと、サブスクライバーＦＰＧＡノートに分割した場合の構成例について説明したが、通信デバイスに第１実施形態のパブリッシャーノード機能と、変形例１のサブスクライバーノード機能と、を搭載してもよい。
［５．３］変形例３
すなわち、１つの通信デバイス中にパブリッシャーアプリケーションノード機能と、パブリッシャーＦＰＧＡノードド機能と、サブスクライバーアプリケーションノード機能と、サブスクライバーパブリッシャーＦＰＧＡノード機能の全てを搭載することもできる。

［５．４］変形例４
上記変形例１においては、データ出力部２２９にモータの駆動回路を設けるとともに、データ出力部２２９にモータＭを接続して、モータＭを駆動する構成を採用したが、データ出力部２２９にＴＣＰ／ＩＰスタックの機能を設け、通信デバイス（受信側）２００のデータ処理部２２８において、画像処理結果データに対する処理を実行した後に、当該処理後のデータをさらに他のコンポーネントに送信する構成としてもよい。

［５．５］変形例５
上記第１実施形態においては、ロボットシステム１内において通信処理を実行する場合を例に説明を行ったが、イーサネット（登録商標）Ｎに代えてインターネットを介して、ロボットシステムＲにおいて撮像されたカメラ画像データを通信端末装置Ｔに送信する場合についても本発明の通信デバイスを利用することができる。

例えば、カメラ画像データに対する画像処理は、非常に高度かつ複雑であるため、クラウド上の処理リソースを利用し、又は、クラウド側の大規模データベースを利用して、カメラ画像データに画像処理を施すような場合が、これに相当する。

この場合には、変形例１のようにパブリッシャーアプリケーションノード機能と、パブリッシャーＦＰＧＡノード機能と、サブスクライバーアプリケーションノード機能及びサブスクライバーＦＰＧＡノード機能を設けた通信デバイスをロボットシステムＲに搭載するようにする。

そして、ロボットシステム１が通信端末装置Ｔにカメラ画像データを送信する際に、第１実施形態の方法にて、カメラ画像データをパブリッシュし、通信端末装置Ｔにおいて、画像処理を実行するようにする。

また、この場合には、通信デバイス（送信側）１００のデータ処理部１２６において、カメラ画像データを、Ｈ．２６４、ＭＰＥＧ２（Ｍｏｖｉｎｇ Ｅｘｐｅｒｔ Ｇｒｏｕｐ２）等の形式で圧縮し、当該圧縮後のカメラ画像データを通信端末装置Ｔに配信するようにすればよい。

本変形例の方法を採用した場合には、例えば、通信端末装置Ｔをロボットシステム１のリモートコントローラーとして構成し、ロボットシステム１から供給されるカメラ画像を通信端末装置Ｔの図示せぬ表示部に表示させるようにしてもよい。

そして、当該表示された画像に従って、ユーザ（すなわち、オペレータ）が行った操作に応じて、ロボットシステム１の各部を駆動させるための操作コマンドデータを通信端末装置Ｔが、パブリッシュし、当該パブリッシュされた操作コマンドデータをロボットシステム１が、再度サブスクライブして、ロボットシステムＲの各部を駆動させるようにすればよい。

また、本変形例の構成を採用した場合には、例えば、高齢者や障害者等の利用者宅にロボットシステムＲを設置して、カメラ画像や脈拍、脳波等の生体情報をロボットシステムＲから通信端末装置Ｔに配信して、利用者の日常生活支援や医療支援に利用できる。

さらに、リハビリテーション用のロボットシステムＲにおいて、患者のリハビリテーションに関するデータを収集するとともに、当該データを通信端末装置Ｔに送信して、新たなリハビリテーション方法の開発やリハビリテーションの進捗、効果等の確認等に利用できるようにしてもよい。

また、ロボットシステムＲを災害地域や事故現場に派遣して、災害復旧に利用し、又は、事故理由の解析に必要なデータ収集に利用することが可能となる。

［６］性能評価結果
次に、図７〜図１１を用いて、実際にロボットシステム１を構築して行った性能評価の結果について説明する。

［６．１］ 本評価を行った評価システム
まず、図７及び図８を用いて本評価を行う評価システムについて説明する。なお、図７及び図８は、本評価システムにおける本性能評価実験の評価条件を説明するための図である。

本評価システムは、図７に示すＲＯＳシステムによって構築した。特に、本評価システムにおいて、「ｓｎｄ＿ｄａｔａ」ノードは、配信するトピックである、「ｉｎｐｕｔ＿ｄａｔａ」トピックのメッセージ１を「ｐｒｏｃｅｓｓ」ノードに送信し、「ｐｒｏｃｅｓｓ」ノードは「ｉｎｐｕｔ＿ｄａｔａ」トピックをサブスクライブし、メッセージ１を受信したら、「ｏｕｔｐｕｔ＿ｄａｔａ」トピックのメッセージ２を「ｒｃｖ＿ｄａｔａ」ノードに送信するようになっている。そして、「ｒｃｖ＿ｄａｔａ」ノードは、「ｏｕｔｐｕｔ＿ｄａｔａ」トピックをサブスクライブし、メッセージ２を受信する。

また、メッセージ１及びメッセージ２は、共に「ｓｅｎｓｏｒ＿ｍｓｇｓ／ｉｍａｇｅ」型によって形成されており、そのデータ構造を図８に示す。特に、このメッセージ型は、ＲＯＳで用意されているメッセージ型であり、画像の幅、高さ、エンコードに関する変数を持ち、変数「ｓｔｅｐ」に入れた値によって、配列である「ｄａｔａ」のサイズが決まる。例えば「ｓｔｅｐ」の値を「１」とすれば、１ｂｙｔｅの配列が用意され、「１０００」とすれば、１０００ｂｙｔｅの配列となる。

そして、このシステムにおいて、「ｐｒｏｃｅｓｓ」ノードと同等の動作をする通信デバイスを実装し、「ｓｎｄ＿ｄａｔａ」ノードがメッセージ１を送信してから「ｒｃｖ＿ｄａｔａ」ノードがメッセージ２を受信するまでの時間を計測した。

なお、測定に用いたメッセージ１及びメッセージ２のサイズは、画像サイズを「４８０×６４０」でピクセルで３バイト（すなわち、ＲＧＢ）を想定した１Ｍｂｙｔｅ、２値化されたフルＨＤ画像「１９２０×１０８０×１」の２Ｍｂｙｔｅ、「１９２０×１０８０×３」の６Ｍｂｙｔｅで行った。

［６．２］測定環境
次に、図９を用いて本評価システムにおける測定環境について説明する。なお、図９は、本評価システムにおける本性能評価実験の評価条件を説明するための図である。

本評価システムは、通信デバイスの通信遅延を比較するために、汎用的なプロセッサを搭載したＰＣ−ＰＣ間、ＰＣ−ＡＲＭ（登録商標）プロセッサ間、ＰＣ−ＦＰＧＡ間の３通りで計測を行った。

特に、ＦＰＧＡには、上記変形例１と同様に、第１実施形態のパブリッシャーアプリケーションノード機能と、パブリッシャーＦＰＧＡノード機能と、サブスクライバーソフトウエア機能と、サブスクライバーハードウエア機能と、１つの通信デバイス内に搭載したものを利用した。

また、本評価システムの測定環境は、図１３に示すように、ＰＣ１、ＰＣ２、ＡＲＭ、ＦＰＧＡは全てギガビットイーサネット（登録商標）によって接続されている。特に、ＰＣ１で実行している「ｓｎｄ＿ｄａｔａ」ノードがデータを送信すると、レイヤ２スイッチ（Ｌ２スイッチ）を経由して、ＰＣ２またはＡＲＭプロセッサで実行している「ｐｒｏｃｅｓｓ」ノードがデータを受信するようになっている。そして、データを全て受信したら、ＰＣ１上で実行している「ｒｃｖ＿ｄａｔａ」ノードに対してデータ送信を行う。

さらに、ＰＣ１及びＰＣ２には、ＣＰＵが、ＩｎｔｅｌＣｏｒｅｉ７（登録商標）８７０（２．９３ＧＨｚ）、メモリが４ＧＢのものを使用した。なお、ＰＣ１及び２に搭載したＯＳはＵｂｕｎｔｕ（登録商標）１６．０４であり、ＡＲＭプロセッサには、Ｘｉｌｉｉｎｘ社製ＺＣ７０２０搭載のＺｅｄｂｏａｒｄ（登録商標）上のＡＲＭＣｏｒｔｅｘ−Ａ９（登録商標）プロセッサを用いた。

特に、ＦＰＧＡボードには、Ｘｉｌｉｉｎｘ社製のＳｐａｒｔａｎ−６(ＸＣ６ＳＬＸ１００) （登録商標）を搭載した、株式会社ｅ−ｔｒｅｅｓ．ＪａｐａｎのｅｘＴｒｉ−ＣＳＩを用いた。なお、このボードは、ギガビットイーサネット（登録商標）を３ポート持っており、そのうちの２つとＳｉＴＣＰのインスタンスを接続している。

［６．３］評価結果
次に、図１０及び図１１を用いて本評価システムにおける評価結果について説明する。なお、図１０及び図１１は、本評価システムにおける評価結果を示すグラフである。

図１０に示すように、「ｓｎｄ＿ｄａｔａ」ノードが画像メッセージを送信開始してから、「ｒｃｖ＿ｄａｔａ」ノードが画像メッセージを受信完了するまでの遅延時間の測定結果に基づくと、画像サイズが増加するにつれて、遅延時間も増加していることが分かる。

特に、６Ｍサイズの送受信にかかる遅延時間は、ＰＣ−ＰＣ間の場合は１２９ｍｓ、ＰＣ−ＡＲＭ間の場合は２９０ｍｓ、ＰＣ−ＦＰＧＡ間の場合は１７５ｍｓであった。なお、画像メッセージは、メッセージサイズを１Ｍ、２Ｍ、６Ｍｂｙｔｅにしたものである。

また、ＡＲＭプロセッサと比較して、ＦＰＧＡ（すなわち、本発明の通信デバイス）を用いた場合に、画像メッセージの送受信時における遅延時間が短くなることが分かった。

その一方、ＳｉＴＣＰのスループットである９４９Ｍｂｐｓと比較したときに、大きな速度向上を得られていないことから、ＦＰＧＡにより受信のみを行った場合について、さらに性能評価を行った。

図１１に示すように、「ｓｎｄ＿ｄａｔａ」ノードが画像メッセージを送信開始してから、「ｒｃｖ＿ｄａｔａ」ノードが終了メッセージを受信完了するまでの遅延時間の測定結果に基づくと、遅延時間は、主に実装した通信デバイスが画像データを受信するためにかかった時間になっている。なお、終了メッセージとはメッセージ２の「ｓｔｅｐ」値を「１」としたものであり、メッセージサイズは４６ｂｙｔｅである。

特に、６Ｍｂｙｔｅの画像データを送受信する場合には、本発明の通信デバイス（すなわち、本評価におけるＦＰＧＡ）と、ＰＣ間の通信時間が、５７ｍｓとなり、ＰＣ−ＰＣ間の通信時間（６７ｍｓ）よりもさらに短いことが分かった。

１ ：ロボットシステム
１０ ：カメラコンポーネント
２０ ：駆動コンポーネント
３０ ：マスターデバイス
１００ ：通信デバイス
１１０ ：アプリケーション実行部
１１１ ：ＩＰスタック
１１２ ：解釈部
１１３ ：制御部
１１４ ：ＸＭＬ−ＲＰＣメッセージ生成部
１２０ ：ＦＰＧＡ制御処理部
１２１ ：ＩＰスタック
１２２ ：解釈部
１２３ ：制御部
１２４ ：登録処理部
１２５ ：データ入力部
１２６ ：データ処理部
１２７ ：符号化処理部
１２８ ：マルチプレクサ
２００ ：通信デバイス
２１０ ：アプリケーション実行部
２１１ ：ＩＰスタック
２１２ ：解釈部
２１３ ：制御部
２１４ ：ＸＭＬ−ＲＰＣメッセージ生成部
２２０ ：ＦＰＧＡ制御処理部
２２１ ：ＩＰスタック
２２２ ：解釈部
２２３ ：制御部
２２４ ：要求処理部
２２５ ：接続処理部
２２６ ：マルチプレクサ
２２７ ：復号化処理部
２２８ ：データ処理部
２２９ ：データ出力部
１２１１ ：受信部
１２１２ ：送信部
２２１１ ：受信部
２２１２ ：送信部

Claims (10)

1. 論理回路によって加工された、予め定められたトピックに属する実データを他の通信デバイスに配信する通信デバイスであって、
   所定のアプリケーションと連動する第１通信プロトコルに従って、前記トピックにおける前記他の通信デバイスとのデータ通信を実行するための通信制御用のデータであって、当該データ通信を行う際に割り当てられた第１通信アドレスを含む第１通信制御用データを、前記通信デバイス間のデータ通信を管理する管理装置に登録する登録手段と、
   特定の前記トピックにおける前記第１通信アドレスを含む前記第１通信制御用データを前記管理装置から取得した前記他の通信デバイスから、前記第１通信プロトコルに従って、当該特定のトピックに関するデータ通信を実行するための第１通信コネクションの確立要求を受け付ける第１受付手段と、
   前記第１通信コネクションの確立要求が受け付けられた場合に、前記第１通信プロトコルに従って、当該確立要求をした他の通信デバイスとの前記第１通信コネクションを確立する第１確立手段と、
   前記第１通信プロトコルとは異なり、かつ、前記論理回路を用いる第２通信プロトコルによって前記特定されたトピックにおける実データを配信するための通信用制御データであって、当該実データを配信する際に用いる前記第１通信アドレスとは異なる第２通信アドレスを含む第２通信用制御データを、前記第１通信プロトコルに従って、前記第１通信コネクションが確立された他の通信デバイスに配信する第１配信手段と、
   前記配信された第２通信用制御データに含まれる第２通信アドレスを用いることによって、前記他の通信デバイスから、前記第１通信プロトコルに従って、前記特定のトピックにおける実データのデータ通信を実行するための第２通信コネクションの確立要求を受け付ける第２受付手段と、
   前記第２通信コネクションの確立要求が受け付けられた場合に、前記第２通信プロトコルに従って、当該確立要求をした他の通信デバイスとの第２通信コネクションを確立する第２確立手段と、
   前記第２通信プロトコルに従って、前記確立された第２通信コネクションを介して、前記論理回路から出力された前記特定のトピックにおける実データを、該当する他の通信デバイスに配信する第２配信手段と、
   を備えることを特徴とする通信デバイス。
2. 請求項１に記載の通信デバイスにおいて、
   前記論理回路が、
   複数の処理を並列して実行可能なプログラマブルロジック回路によって構成されている、通信デバイス。
3. 請求項１又は２に記載の通信デバイスにおいて、
   第２通信プロトコルが、
   単一のＴＣＰポートを用いた手順を規定する通信プロトコルであり、
   前記第２確立手段が、
   前記ＴＣＰポートを用いて、前記他の通信デバイスとの間において、前記第２通信コネクションを確立する、通信デバイス。
4. 請求項１〜３の何れか１項に記載の通信デバイスにおいて、
   前記登録手段が、
   自機の通信環境に応じて、前記アプリケーションの手順に従って、前記管理装置に登録する際の前記通信用制御データを変更する処理を実行する、通信デバイス。
5. 請求項１〜４の何れか１項に記載の通信デバイスにおいて、
   自機の置かれている状況又は自機の周囲環境を示す環境データを取得する取得手段と、
   前記取得された環境データを前記論理回路によって加工して前記実データを生成する生成手段と、
   を更に備える、通信デバイス。
6. 予め定められた他の通信デバイスから出力され所定のトピックに関する実データを取得し、当該取得した実データに対して所定の処理を実行する通信デバイスであって、
   所定のアプリケーションと連動する第１通信プロトコルに従って、前記他の通信デバイスが管理装置に登録している通信制御用のデータであって、当該データ通信を行う際に割り当てられた第１通信アドレスを含む第１通信制御用データを、当該管理装置から、取得する第１取得手段と、
   特定の前記トピックにおける前記第１通信アドレスを含む前記第１通信制御用データに基づいて、該当する前記他の通信デバイスに、前記第１通信プロトコルに従って、当該特定のトピックに関するデータ通信を実行するための第１通信コネクションの確立要求を行う第１確立要求手段と、
   前記第１通信コネクションの確立要求が受け付けられた場合に、前記第１通信プロトコルに従って、当該確立要求を受け付けた他の通信デバイスとの前記第１通信コネクションを確立する第１確立手段と、
   前記第１通信プロトコルとは異なり、かつ、論理回路を用いる第２通信プロトコルによって前記特定されたトピックにおける実データを前記確立要求を受け付けた他の通信デバイスによって配信するための通信用制御データであって、当該実データを配信する際に用いる前記第１通信アドレスとは異なる第２通信アドレスを含む第２通信用制御データを、前記第１通信プロトコルに従って、前記第１通信コネクションが確立された他の通信デバイスから取得する第２取得手段と、
   前記配信された第２通信用制御データに含まれる第２通信アドレスを用いることによって、前記第１通信コネクションが確立された他の通信デバイスに、前記第２通信プロトコルに従って、前記特定のトピックにおける実データのデータ通信を実行するための第２通信コネクションの確立要求を行う第２確立要求手段と、
   前記第２通信プロトコルに従って、当該確立要求を受け付けた他の通信デバイスとの第２通信コネクションを確立する第２確立手段と、
   前記第２通信プロトコルに従って、前記確立された第２通信コネクションを介して、前記論理回路から出力された前記特定のトピックにおける実データを、該当する他の通信デバイスから取得する第２取得手段と、
   を備えることを特徴とする通信デバイス。
7. 請求項６に記載の通信デバイスにおいて、
   第２通信プロトコルが、
   単一のＴＣＰポートを用いた手順を規定する通信プロトコルであり、
   前記第２確立手段が、
   前記ＴＣＰポートを用いて、前記他の通信デバイスとの間において、前記第２通信コネクションを確立する、通信デバイス。
8. 請求項１〜７のいずれか１項に記載の通信デバイスを備えた情報通信端末装置。
9. 論理回路によって加工された、予め定められたトピックに属する実データを他の通信デバイスに配信する通信方法であって、
   所定のアプリケーションと連動する第１通信プロトコルに従って、前記トピックにおける前記他の通信デバイスとのデータ通信を実行するための通信制御用のデータであって、当該データ通信を行う際に割り当てられた第１通信アドレスを含む第１通信制御用データを、前記通信デバイス間のデータ通信を管理する管理装置に登録するステップと、
   特定の前記トピックにおける前記第１通信アドレスを含む前記第１通信制御用データを前記管理装置から取得した前記他の通信デバイスから、前記第１通信プロトコルに従って、当該特定のトピックに関するデータ通信を実行するための第１通信コネクションの確立要求を受け付けるステップと、
   前記第１通信コネクションの確立要求が受け付けられた場合に、前記第１通信プロトコルに従って、当該確立要求をした他の通信デバイスとの前記第１通信コネクションを確立するステップと、
   前記第１通信プロトコルとは異なり、かつ、前記論理回路を用いる第２通信プロトコルによって前記特定されたトピックにおける実データを配信するための通信用制御データであって、当該実データを配信する際に用いる前記第１通信アドレスとは異なる第２通信アドレスを含む第２通信用制御データを、前記第１通信プロトコルに従って、前記第１通信コネクションが確立された他の通信デバイスに配信するステップと、
   前記配信された第２通信用制御データに含まれる第２通信アドレスを用いることによって、前記他の通信デバイスから、前記第１通信プロトコルに従って、前記特定のトピックにおける実データのデータ通信を実行するための第２通信コネクションの確立要求を受け付けるステップと、
   前記第２通信コネクションの確立要求が受け付けられた場合に、前記第２通信プロトコルに従って、当該確立要求をした他の通信デバイスとの第２通信コネクションを確立するステップと、
   前記第２通信プロトコルに従って、前記確立された第２通信コネクションを介して、前記論理回路から出力された前記特定のトピックにおける実データを、該当する他の通信デバイスに配信するステップと、
   を含むことを特徴とする通信方法。
10. 予め定められた他の通信デバイスから出力され所定のトピックに関する実データを取得し、当該取得した実データに対して所定の処理を実行する通信方法であって、
    所定のアプリケーションと連動する第１通信プロトコルに従って、前記他の通信デバイスが管理装置に登録している通信制御用のデータであって、当該データ通信を行う際に割り当てられた第１通信アドレスを含む第１通信制御用データを、当該管理装置から、取得するステップと、
    特定の前記トピックにおける前記第１通信アドレスを含む前記第１通信制御用データに基づいて、該当する前記他の通信デバイスに、前記第１通信プロトコルに従って、当該特定のトピックに関するデータ通信を実行するための第１通信コネクションの確立要求を行うステップと、
    前記第１通信コネクションの確立要求が受け付けられた場合に、前記第１通信プロトコルに従って、当該確立要求を受け付けた他の通信デバイスとの前記第１通信コネクションを確立するステップと、
    前記第１通信プロトコルとは異なり、かつ、論理回路を用いる第２通信プロトコルによって前記特定されたトピックにおける実データを前記確立要求を受け付けた他の通信デバイスによって配信するための通信用制御データであって、当該実データを配信する際に用いる前記第１通信アドレスとは異なる第２通信アドレスを含む第２通信用制御データを、前記第１通信プロトコルに従って、前記第１通信コネクションが確立された他の通信デバイスから取得するステップと、
    前記配信された第２通信用制御データに含まれる第２通信アドレスを用いることによって、前記第１通信コネクションが確立された他の通信デバイスに、前記第２通信プロトコルに従って、前記特定のトピックにおける実データのデータ通信を実行するための第２通信コネクションの確立要求を行うステップと、
    前記第２通信プロトコルに従って、当該確立要求を受け付けた他の通信デバイスとの第２通信コネクションを確立するステップと、
    前記第２通信プロトコルに従って、前記確立された第２通信コネクションを介して、前記論理回路から出力された前記特定のトピックにおける実データを、該当する他の通信デバイスから取得するステップと、
    を含むことを特徴とする通信方法。