(57)【要約】【課題】ネットワーク基盤のロボット・システムで重要データは必ず伝達し、伝送データの大きさを最小化することができる通信方式等を提供する。【解決手段】必ず伝達されるべきである重要データの伝送のために、送信側では受信側から伝送された応答パケットから、前記重要データ等に対応するデバイス・マップ領域の活性化の要否と対応ペイロード領域に存在するデータを通し、送信側が送信した前記重要データ等を受信側が受信したかを確認し、受信したことと確認される時まで続けて次のパケット・データ伝送時に、該受信することができなかった重要データに対するデバイス・マップ領域の当該部分を活性化させ続けて、該送信することができなかった重要データを当該ペイロード領域に含ませ続けて、パケット・データを形成して受信側へ伝送するサービス・サーバーとロボットを含む。【選択図】図５
2008278451.tif 000002
【特許請求の範囲】
【請求項１】
サービス・サーバーとロボットを含むネットワーク基盤のロボット・システムの通信方法において、
相手方の受信の要否を待たせず、次のパケット・データを伝送する方式で通信を行ない；
前記パケット・データのそれぞれには、前記ロボットの構成要素に対する活性化の要否が格納されるデバイス・マップ領域と、前記デバイス・マップ領域で活性化された部分に対応するデータ等が格納されるペイロード(payload)領域が含まれて；
必ず伝達されるべきである重要データの伝送のために、
送信側では受信側から伝送された応答パケットで、前記重要データ等に対応するデバイス・マップ領域の活性化の要否と、対応ペイロード領域に存在するデータを通し、送信側が送信した前記重要データ等を受信側が受信したか否かを確認して、受信したものと確認される時まで続けて次のパケット・データの伝送時に、該受信することができなかった重要データに対するデバイス・マップ領域の当該部分を活性化させ続けて、該受信することができなかった重要データを当該ペイロード領域に含まさせ続け、パケット・データを形成して受信側へ伝送することを特徴とするサービス・サーバーとロボットを含むネットワーク基盤のロボット・システムの通信方法。
【請求項２】
第１項において、
前記ロボットは、ロボット端末機であることを特徴とするサービス・サーバーとロボットを含むネットワーク基盤のロボット・システムの通信方法。
【請求項３】
第２項において、
前記ロボット端末機に前記サービス・サーバーの役割をするローカル・サーバーが内蔵されていることを特徴とするサービス・サーバーとロボットを含むネットワーク基盤のロボット・システムの通信方法。
【請求項４】
第１項において、
前記通信は、ＵＤＰ/ＩＰ方式で行なわれることを特徴とするサービス・サーバーとロボットを含むネットワーク基盤のロボット・システムの通信方法。
【請求項５】
第１項において、
前記活性化の要否は、活性化ビットで指定されることを特徴とするサービス・サーバーとロボットを含むネットワーク基盤のロボット・システムの通信方法。
【請求項６】
第１項において、
前記パケット・データは、ロボットの動作を制御する動作制御データを含むことを特徴とするサービス・サーバーとロボットを含むネットワーク基盤のロボット・システムの通信方法。
【請求項７】
サービス・サーバーとロボットを含むネットワーク基盤のロボット・システムで、相手方の受信の要否を待たせず、次のパケット・データを伝送する方式で通信を行なう通信方式のためのパケット・データ構造において、
前記パケット・データのそれぞれには、
前記ロボットの各構成要素に対して送信または受信されるデータが存在するか否かの要否を示す活性化の要否が格納されるデバイス・マップ領域と、
前記デバイス・マップ領域で活性化された部分に対するデータ等が格納されるペイロード領域を含むことを特徴とするネットワーク基盤のロボット・システムの通信方式のためのパケット・データ構造。
【請求項８】
第７項において、
前記通信は、ＵＤＰ/ＩＰ方式で行なわれることを特徴とするネットワーク基盤のロボット・システムの通信方式のためのパケット・データ構造。
【請求項９】
第７項において、
前記活性化の要否は、活性化ビットで指定されることを特徴とするネットワーク基盤のロボット・システムの通信方式のためのパケット・データ構造。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はネットワーク基盤のロボット・システムの制御のための通信方式と、該通信方式のためのデータ構造に関するものである。
【背景技術】
【０００２】
未来には多様なホーム・ロボットが各家庭毎に補給され、ホーム・ロボットを用いて多様な機能を行なうことになるが、その代表的利用分野の一つが口演童話聞かせや、英語教育等の音声及び映像コンテンツ(以下、マルチメディア・コンテンツ)の再生による教育分野である。
【０００３】
しかし、このような従来のホーム・ロボット・システムにおいて、使用者がホーム・ロボットまたはPCを通してサービス・サーバーに接続してホーム・ページで特定の口演童話や英語学習コンテンツを有料または無料で購買すれば、該サービス・サーバーに格納された該コンテンツのための文章/音声ファイルと、映像ファイルの全体がホーム・ロボットにダウンされてホーム・ロボットに格納されて使用者が望みの時期に、ホーム・ロボットから文章をＴＴＳ(text to speech)・エンジンを用いて音声ファイルに変換して発声するとか、伝達された音声ファイルで発声しながら映像ファイルを再生し、口演童話や英語学習コンテンツを再生してくれるので、該ダウンされた大容量の音声及び映像を再生するためにはホーム・ロボットには殆どPC水準の大容量の処理装置と格納装置(メモリ、ＨＤＤ等)が必要でホーム・ロボットの値段が上昇になる。
【０００４】
なお、該口演童話や英語学習用音声と映像の再生時にホーム・ロボットは音声及び映像再生のみをするだけ、該音声及び映像と関連された動作(例えば、“おはいよう？”または“Ｈｅｌｌｏ”との文章が出るとホーム・ロボットが挨拶する動作をしたり、文章を発声時の文章に合うように口を開閉する動作等)をせず、口演童話や英語学習用コンテンツを用いる幼児と子供に興味を誘発させることができない。
【０００５】
結局、現在のホーム・ロボット・システムでは、音声及び映像コンテンツを用いるためにはホーム・ロボットに大容量の中央処理装置と格納装置が必要であり、音声及び映像に対応する動作なしに興味を誘発させることができない。
【０００６】
この問題点を解決するために、本出願人の先行出願である特許出願 2005-378264(2005.12.28出願)と、特許出願 2006-2898(2006.1.10出願)では、図１のような構成を有するロボット端末機システムを提案した。
【０００７】
該先行出願等では、各家庭のロボット端末機(１−１、１−２．．．１−Ｎ)には関節や輪を駆動するためのモーター(２−１、２−２．．．２−Ｎ)と、モーター及びリレー(２−１、２−２．．．２−Ｎ)を駆動するための駆動回路(３−１、３−２．．．３−Ｎ)と、マイク等のセンサー等(４−１、４−２．．．４−Ｎ)と、センサー等(４−１、４−２．．．４−Ｎ)からのセンシング信号をサーバー(７)へ伝送し、サーバー(７)からのデータをロボット端末機(１−１、１−２．．．１−Ｎ)で受信する送受信装置(５−１、５−２．．．５−Ｎ)と、サーバー(７)から伝達される音声ファイルを発声するためのＤ/Ａ変換機(６−１、６−２．．．６−Ｎ)とスピーカー(１０−１、１０−２．．．１０−Ｎ)、ロボット端末機(１−１、１−２．．．１−Ｎ)に映像再生用モニター(図示せず)を有している時伝達される映像ファイルをモニターに表示するための映像表示制御装置(図示せず)を含んでいる。
【０００８】
それで、ロボット端末機(１−１、１−２．．．１−Ｎ)にはサーバー(７)とのデータ送受信のための送受信装置(５−１、５−２．．．５−Ｎ)と、マイク等のセンサー等(４−１、４−２．．．４−Ｎ)と、モーター/リレー(２−１、２−２．．．２−Ｎ)と、モーター/リレーの駆動回路(３−１、３−２．．．３−Ｎ)と、Ｄ/Ａ変換機(６−１、６−２．．．６−Ｎ)と、スピーカー(１０−１、１０−２．．．１０−Ｎ)及び/または映像表示制御装置とモニターのみを設け、ロボット端末機(１−１、１−２．．．１−Ｎ)の動作のための動作制御データの形成、音声ファイル及び/または映像ファイルの形成のための大容量のデータ処理はサービス・サーバ(７)で行なうようにすれば、ロボット端末機(１−１、１−２．．．１−Ｎ)には大容量の中央処理装置やメモリが不要になり、低コストのホーム・ロボットを提供することが可能となる。
【０００９】
しかし、このような先行出願では、図２のように音声及び/または映像と同期された動作データの伝送方式を行なうために、サービス・サーバー(７)とロボット端末機(１)との間にパケット・データ方式でデータ送受信する方法を用い、図３のように常に同一パケット・フォマットを用いるようになる。各領域の詳細な意味は先行出願に詳しく説明されているので省略する。
【００１０】
結局、先行出願では図３のように常に同一大きさを有するパケットを用いてサービス・サーバー(７)とロボット端末機(１)との間に通信する方式を用いるので、伝送しようとする動作制御データや、マルチメディア・データが多くない場合、例えば、発声のみで動作制御データの伝送が不要の場合までも動作制御データ領域(ＭＤ)を用いるべきであるので、パケット方式で伝送する全体データの大きさが大きくなって通信負荷を起こすようになる。
【００１１】
従って、伝送が不要であるデータ領域は伝送しないようにする可変的なデータの大きさを有するパケット・データ・フォマットが必要になる。
【００１２】
また、パケット・データを相手方(サービス・サーバ(７)またはロボット端末機(１))へ伝送する方式では、インターネットで広く用いられるＴＣＰ/ＩＰ方式を用いるとか、ＵＤＰ/ＩＰ方式を用いることができるが、ＴＣＰ/ＩＰ方式は一般的インターネットではパケット・データが必ず伝送されるものが必要で、通常的伝送所要時間の２倍程を待って相手方からパケット・データの受信信号が来なければ、再試する方式を用いるので、通信線路等の不良により伝送が円滑しない場合には続けて同一データ・パケットを伝送しようとする試みによって送信測と通信線路に相当の負荷を起こすようになる。
【００１３】
しかし、ＵＤＰ/ＩＰ方式を用いれば受信の要否に関係せず、次に伝送すべきであるパケット・データを送信し続けるので、伝送線路等に問題がある場合には若干のパケットが損失されて必ず相手方に伝達されるべきである重要命令データまでも損失されるので問題を引き起こすようになる。
【００１４】
例えば、ロボット端末機に緊急停止命令を下す命令データが含まれたパケット・データが損失されれば、送信測(サービス・サーバー(７))では緊急状況と判断して緊急停止命令を受信測(ロボット端末機(１))へ送信しても、ロボット端末機(１)で受信できなくて緊急停止ができないので、大きい事故を起こす問題点がある。
【００１５】
結局、ロボット端末機(１)のようなネットワーク基盤のロボット・システムに適合する通信方式と、該通信方式のためのデータ・パケット用データ構造に対する研究が必要である。
【発明の開示】
【発明が解決しようとする課題】
【００１６】
本発明は前記のような従来技術の問題点を勘案し、ネットワーク基盤のロボット・システムで重要データは必ず伝達し、伝送データの大きさを最小化することができる通信方式と、該通信方式のためのパケット・データのデータ構造を提供する。
【課題を解決するための手段】
【００１７】
本発明は、サービス・サーバーとロボットを含むネットワーク基盤のロボット・システムの通信方法において、相手方の受信の要否を待ちせず、次のパケット・データを伝送する方式で通信を行ない；
前記パケット・データのそれぞれには、前記ロボットの構成要素に対する活性化の要否が格納されるデバイス・マップ領域と、前記デバイス・マップ領域で活性化された部分に対応するデータ等が格納されるペイロード領域が含まれ；
必ず伝達されるべきである重要データの伝送のために、送信側では受信側から伝送された応答パケットから、前記重要データ等に対応するデバイス・マップ領域の活性化の要否と対応ペイロード領域に存在するデータを通し、送信側が送信した前記重要データ等を受信側が受信したかを確認し、受信したことと確認される時まで続けて次のパケット・データ伝送時に、該受信することができなかった重要データに対するデバイス・マップ領域の当該部分を活性化させ続けて、該送信することができなかった重要データを当該ペイロード領域に含ませ続けて、パケット・データを形成して受信側へ伝送することを特徴とするサービス・サーバーとロボットを含むことを特徴とする。
【発明の効果】
【００１８】
以上のような本発明を用いれば、サービス・サーバー(７)とロボット端末機(１)との間にＵＤＰ/ＩＰ方式を用いながら、活性化の要否のビットを用いて送信するデータに対する活性化の要否のビットのみを活性化して関連データを添付し、必ず伝送されるべきである重要データは相手側から受信の要否に対して確認を受けるようにし、受信しなかったら受信する時まで送信し続けるようになり、ＵＤＰ/ＩＰ方式を通す高速パケット・データ伝送が可能となり、パケット・データの大きさを最小限に減らしながら、重要データは必ず伝送することができるロボット端末機用通信プロトコルを提供することが可能となる。
【００１９】
そんなにして、ネットワーク基盤のロボット端末機システムに適合する通信方式と、該通信方式のためのデータ・パケット用データ構造を提供することが可能となる。
【発明を実施するための最良の形態】
【００２０】
先ず、ネットワーク基盤のロボット端末機システムに適合する通信方法と、該通信方式のためのパケット・データのデータ構造のために、必ず達成されるべきである原則に対して察して見るようにする。
【００２１】
１．パケット・データの伝送時に、送信測と通信線路の負荷を起こさないためには、受信の要否に関係せず、続けて次のパケット・データを伝送するＵＤＰ/ＩＰ方式の伝送方式を用いるのが好ましい。
【００２２】
一般的インターネットではパケット・データの損失があってはいけないから、相手方が受信していなっかたら再試する過程を通して必ず送信する過程が必要であるが、動作制御データ、音声データ、映像データのような動作含みのマルチメディア・データはデータの連続性により連続されたパケット・データから、小数のパケットが伝送されないで抜けても、受信側では望んだら補間方法によって復元でき、一部のパケットが抜けた状態で再生されていても、使用者が全然認識できない場合(例えば、音声データ等のうち、一部が抜けても殆ど音声の連続性が割れないとか、割れても極めて短い時間だけ割れて使用者が音声を認識するのに差し支えがない。)が多く、送信測と通信線路の再試による負荷を除去するために、若干のデータ損失があっても動作含みのマルチメディア・パケット・データはＵＤＰ/ＩＰ方式で、相手方からパケット・データの受信信号を待たせず、続けて次のパケット・データを伝送するのが好ましい。
【００２３】
２．ＵＤＰ/ＩＰ方式を用いても必ず伝送すべきである重要データは、必ず伝送することができるデータ構造が必要である。
【００２４】
例えば、緊急状況による緊急停止命令、戦闘用ロボット端末機で勝敗の重要変数になる赤外線弾丸の発射回数と、赤外線弾丸の受信回数のような重要データは、ＵＤＰ/ＩＰ方式を用いても必ず伝送することができる方案が必要である。
【００２５】
さて、以上で言及した２つの原則を達成することができる本発明のパケット・データ構造を説明する。ここで、ロボット端末機(１)を用いて戦闘ゲームをするものと仮定する。
【００２６】
図４のようにロボット端末機(１)は、左側輪(１１)、右測輪(１２)、銃身役割をする右腕(１３)、右腕(１３)の端に設けられた赤外線送信部(１４)、 ボディーの中央に付着された赤外線受信部(１５)、前記赤外線受信部(１５)の下段に付着された近接センサー(１６)を含み、左側輪(１１)と右側輪(１２)を用いて移動し、赤外線銃をうつため右腕(１３)を上げて、赤外線送信部(１４)により赤外線弾丸を反射し、他のロボット端末機から発射された赤外線弾丸を赤外線受信部(１５)により受信し、近接センサー(１６)を通して前方物体との距離を測定する。
【００２７】
この時、該戦闘用ロボット端末機(１)では、ロボット端末機(１)の移動関連の左右測輪(１１、１２)制御データ、銃身制御データ、ロボット端末機(１)の銃身角度をモニターリングした銃身モニター・データ、近接センサー(１６)により測定された近接距離データは、仮に一部が損失したても移動とか銃身制御、競技場離脱の要否の判断に大きい問題が発生しないから、続けて次のデータを伝送する。それで、このように一部が損失してもあまり問題がないデータを非重要データと称する。
【００２８】
しかし、戦闘ゲームにおいて、赤外線弾丸の発射回数とか、相手方からの赤外線弾丸を当たる回数は命中率を計算して弾丸消尽の要否を判断する重要データで、勝敗を左右する重要データであるので、サービス・サーバー(７)で要請する赤外線弾丸の発射命令とか、ロボット端末機(１)の赤外線受信部(１６)で認知する赤外線弾丸を当たった回数は必ず伝達されるべきであり、若し伝達することができなかったものと確認されれば、伝達するまで次にパケット・データを送る時に送信し続けなければならない。
【００２９】
なぜならば、サービス・サーバー(７)で発射要請の試みをしたにも関わらず、ロボット端末機(１)が通信線路等の問題により受信することができなければ、サービス・サーバー(７)では赤外線弾丸が発射されたと認知して赤外線弾丸の発射回数を増加させるが、ロボット端末機(１)では該命令を受信することができなくて赤外線送信部(１４)により赤外線弾丸発射をしないようになって、命中率とか戦闘勝者の決定時、誤計算の問題が発生するからである。
【００３０】
また、ロボット端末機(１)で赤外線受信部(１５)により相手方から発射された赤外線弾丸を当たって認知し、該事実をサービス・サーバー(７)に知らせる試みをしたにもかかわらず、通信線路等の問題でサービス・サーバー(１)が受信することができなかった場合にも命中率とか戦闘勝者の決定時、誤計算の問題が発生する。
【００３１】
総合すれば、戦闘用ロボット端末機では、各パケットの左右輪制御データ、銃身制御データ、銃身モニター・データ、近接センサー・データは一部損失されても復元により問題が発生しないとか、復元をしなくても問題とならない非重要データであるが、赤外線発射命令、赤外線受信発生の感知データは必ず伝達されるべきである重要データである。
【００３２】
さて、ロボット端末機システムでＵＤＰ/ＩＰ方式で重要データが必ず伝達されるようにパケット・データを伝送する本発明によるパケット・データ構造に対して図５を参考にして説明する。
【００３３】
図５の左側に図示されたとおり、本発明のパケット・データ構造は大きく、ＩＰヘッダーとしてＵＤＰ/ＩＰ方式で伝送するためのＵＤＰヘッダーと、ロボット・シミュラークルム・プロトコル・ヘッダー(Robot Simulacrum Protocol Header：略称してＲＳＰヘッダー)と、各データ等の活性化の要否のビット領域に該当するデバイス・マップ領域と、前記デバイス・マップ領域で活性化された要素等に対するデータを有するペイロード領域からなる。
【００３４】
ここで、シミュラークルムは、影、像、姿を示し、その意味は、以下のアップ・リンク・パケット・フォーマットと、ダウン・リンク・パケット・フォーマットに対する説明を通して明確になる。
【００３５】
ＵＤＰヘッダーはＵＤＰ/ＩＰ方式で通信するためのヘッダーとして、当業者に広く知られた事項であるので、これに対しては説明を省略し、以下ではＲＳＰヘッダーに対し図５の右側を参考にして説明する。
【００３６】
領域(Version)は、パケット・データのプロトコル・バージョン番号(Protocol Version Number)を示し、領域(Model ID)はロボット端末機のモデルＩＤを示し、領域(Encryption)は、パケット・データに暗号化となっているか否かの要否を示し、領域(Type)は、パケット・データに含まれたデータのタイプ等(オーディオ・データ、ビデオ・データ、動作データ、システム・コマンド、ＡＣＫ等)を示し、領域(Sequence Number)は、パケットが伝送される順を示し、領域(Time Stemp)は、パケットが作られた時刻を示し、領域(Session ID)は、現在通信中のサーバーとロボット端末機のセッション区別及び保安のためのセッションＩＤ領域を示す。
【００３７】
そして、最後に受信されたシークエンス番号は、領域(Last received sequence number)に格納されて、アップ・バッファーとか、ダウン・バッファーがクリアーされているか否か(クリアーされれば使用可能のバッファー数が最大である)、または使用可能のバッファー数がどの位であるかが分かる領域(Clear Buffer/Number of free buffers)が存在する。このようなロボット・プロトコル・ヘッダーの各領域は、設計者が必要によって設定して変更するようになる。
【００３８】
デバイス・マップ領域は、ロボットのデバイス(構成要素)が定義されれば、これによってその大きさと構成要素のビット位置が決定される。
【００３９】
また、デバイス・マップは送受信に関係せず、常に同一デバイス・マップを用い、サービス・サーバー(７)がロボット(１)の各デバイスを活性化しろとの活性化の指示のために、またはロボット(１)の各デバイスの活性化の要否をサービス・サーバー(７)へ通知するために用いられる。
【００４０】
そして、ペイロード領域は、前記デバイス・マップ領域で活性化された構成要素に対応する伝送データが格納されるようになる。
【００４１】
次に、本発明の核心的な事項であるデータ・パケット領域のデータ構造、またはフォーマットに対して詳しく察して見るようにする。
【００４２】
サービス・サーバー(７)からロボット端末機(１)へのデータの伝送時には、ダウン・リンク・パケット・フォーマット(Down Link Packet Format：ＤＬＰＦ)で格納され、ロボット端末機(１)からサービス・サーバー(７)へのデータの伝送時には、アップ・リンク・パケット・フォーマット(Up Link Packet Format：ＵＬＰＦ)で格納されるが、これらに対して図５の右側を参考にして詳しく説明する。
【００４３】
ＤＬＰＦは最上段にダウン・リンク・パケット・フォーマットで伝送される各データの活性の要否のビット等(ｂ７．．．ｂ０)(“１”であれば活性化、“０”であれば非活性化)のためのデバイス・マップ領域が存在する。
【００４４】
図５のＤＬＰＦでは、左側輪データ(ＬＷＤ)、右側輪データ(ＲＷＤ)、銃身制御データ(ＴＲＤ)が活性化されているので、その下段のペイロード領域に関連データがあるとの意味でビット(ｂ７、ｂ６、ｂ５)に“１”が割当されていて、活性化の要否のビット(ｂ２、ｂ１)は、それぞれ赤外線発射命令のＩＤ番号(ＩＲＦ ＩＤ)及び、赤外線受信発生番号認知(ＩＲＲ ＡＣＫ)の活性化の要否のビットであり、図５では活性化されるので“１”が割当されていて、下段のペイロード領域に赤外線発射命令ＩＤ番号(ＩＲＦ ＩＤ)と、赤外線受信発生認知番号(ＩＲＲ ＡＣＫ)が示している。
【００４５】
結局、図５のＤＬＰＦのデバイス・マップ領域の活性化の要否のビット等(ｂ７．．．ｂ０)のみ見ても、サービス・サーバー(７)からロボット端末機(１)へどんなデータを送信するか(ＬＷＤ、ＲＷＤ、ＴＲＤ)、どんな命令を送信するか(ＩＲＦ ＩＤ)、ロボット端末機(１)でどんな認知信号が受信されるか(ＩＲＲ ＡＣＫ)を全体的に直ぐにわかるようになる。
【００４６】
同じく、ＵＬＰＦでは銃身モニター・データ(ＴＭＤ)及び、近接センサー・データ(ＰＳＤ)を用いるので、活性化の要否のビット等(ｂ４、ｂ３)は活性化(“１”)したし、赤外線発射命令ＩＤ認知番号(ＩＲＦ ＡＣＫ)及び、赤外線受信発生ＩＤ番号(ＩＲＲ ＩＤ)を用いるので、活性化の要否のビット等(ｂ２、ｂ１)は活性化(“１”)になる。
【００４７】
結局、ＵＬＰＦの活性化ビット等(ｂ７．．．ｂ０)のみ見ると、ロボット端末機(１)からサービス・サーバー(７)へどんなデータが伝達されたか(ＴＭＤ、ＰＳＤ)、サービス・サーバー(７)からどんな命令が受信されたか(ＩＲＦ ＡＣＫ)、赤外線受信部(１５)で赤外線受信が発生するか(ＩＲＲ ＩＤ)がわかる。
【００４８】
この時、ＤＬＰＦとＵＬＰＦの活性化の要否のバット(ｂ０)は、余分のビットであるので非活性化(“０”)になる。
【００４９】
従って、ＤＬＰＦとＵＬＰＦは、各パケット・データ等に含まれたデータ、命令ＩＤ番号/発生ＩＤ番号、命令ＩＤ番号/発生ＩＤ番号に対する受信の要否を全体的に直ぐに把握することができるシミュラークロム(Simulacrum：像、イメージ、影、姿)になる。
【００５０】
この時、図５でＤＬＰＦの左側輪データ(ＬＷＤ)と、右側輪データ(ＲＷＤ) 及び 銃身制御データ(ＴＲＤ)、ＵＬＰＦの銃身モニター・データ(ＴＭＤ) 及び近接センサー・データ(ＰＳＤ)は、今回のパケット・データの送信周期に損失されて受信側で受信することができなくても、以降の送信周期に伝達されたデータで復元可能のデータや、損失されても殆ど問題がない非重要データである。
【００５１】
しかし、赤外線発射命令ＩＤ番号(ＩＲＦ ＩＤ)とか、赤外線受信発生ＩＤ番号(ＩＲＲ ＩＤ)は、今回の送信周期に損失されて受信側で受信することができなければ、赤外線発射命令に対して実際に赤外線発射が行われないとか、赤外線弾丸を当たったにもかかわらず、当たらないものと認識できるので、受信側で受信するまで伝送し続けて受信したかの要否を確認すべきである重要データである。
【００５２】
さて、このようなＤＬＰＦとＵＬＰＦを用い、サービス・サーバー(７)とロボット端末機(１)がＵＤＰ/ＩＰ方式で、必ず伝送されるべきである命令や受信発生信号を伝達するようにする通信方式に対し、図６、７(デバイス・マップ領域と、ペイロード領域のみ示す)を参考にして説明する。
【００５３】
図６では必ず伝送されるべきである命令や受信発生信号が、伝送損失無しに伝達される場合を図示したものである。
【００５４】
図６には左側にＤＬＰＦとＵＬＰＦが示していて、左側にサービス・サーバー(７)からロボット端末機(１)へ伝送するダウン・リンク・パケット等(Ｓ１、Ｓ２、Ｓ３、Ｓ４)と、右側にロボット端末機(１)からサービス・サーバー(７)へ伝送するアップ・リンク・パケット等(Ｒ１、Ｒ２、Ｒ３、Ｒ４)が示している。
【００５５】
先ず、サービス・サーバー(７)はロボット端末機(１)が左側輪(１１)と、右側輪(１２)で望みの位置(５８ｈ、００ｈ)に移動するようにし、赤外線送信部(１４)に赤外線弾丸を発射するために銃身を望みの角度(７Ｆｈ)に入るようにするために、パケット(Ｓ１)の活性化の要否のビット等を“１１１０００００”にして左側輪データ(ＬＷＤ)、右側輪データ(ＲＷＤ)、銃身データ(ＴＲＤ)関連の活性化の要否のビット(ｂ７、ｂ６、ｂ５)を活性化させる。そして関連データ(５８ｈ、００ｈ、７Ｆｈ)をペイロード領域に入れてパケット(Ｓ１)を形成してロボット端末機(１)へＵＤＰ/ＩＰ方式で送信する。
【００５６】
この時、ＵＤＰ/ＩＰ方式で伝送され、パケット(Ｓ１)が非重要データ(ＬＷＤ、ＲＷＤ、ＴＲＤ)のみ含むので、伝送中に損失されても再度送信しない。
【００５７】
さて、ロボット端末機(１)は銃身角度をモニターリングしたデータ(ＴＭＤ)と、近接センサーで測定した距離に対するデータ(ＰＳＤ)を送信するために、活性化の要否のビット等を“０００１１０００”にして銃身モニター・データ(ＴＭＤ)と、近接センサー・データ(ＰＳＤ)関連の活性化の要否のビット等(ｂ４、ｂ３)を活性化させる。
【００５８】
そして、関連データ(７３ｈ、３３ｈ)を入れてパケット(Ｒ１)を形成してサービス・サーバー(１)へ送信する。
【００５９】
この時にも、ＵＤＰ/ＩＰ方式で伝送され、パケット(Ｒ１)が非重要データ(ＴＭＤ、ＰＳＤ)のみ含むので、伝送中に損失されても再度送信しない。
【００６０】
同じ方式で、サービス・サーバー(７)はロボット端末機(１)が左側輪(１１)と右側輪(１２)で望みの位置(６３ｈ、ＥＦｈ)に移動するようにし、赤外線送信部(１４)に赤外線弾丸を発射するため銃身を望みの角度(７Ｆｈ)に入るようにするために、パケット(Ｓ２)の活性化の要否のビット等を“１１１０００００”にして左側輪データ(ＬＷＤ)、右側輪データ(ＲＷＤ)、銃身制御データ(ＴＲＤ)関連の活性化の要否のビット(ｂ７、ｂ６、ｂ５)を活性化させ、関連データ(６３ｈ、ＥＦｈ、７Ｆｈ)をペイロード領域に入れてパケット(Ｓ２)を形成してロボット端末機(１)へＵＤＰ/ＩＰ方式で送信する。
【００６１】
この時、ＵＤＰ/ＩＰ方式で伝送され、パケット(Ｓ２)が非重要データ(ＬＷＤ、ＲＷＤ、ＴＲＤ)のみ含むので、伝送中に損失されても再度送信しない。
【００６２】
さて、ロボット端末機(１)は銃身角度をモニターリングしたデータ(ＴＭＤ)と近接センサーで測定した距離に対するデータ(ＰＳＤ)を送信するために、活性化の要否のビット等を“０００１１０００”にして銃身モニター・データ(ＴＭＤ)と、近接センサー・データ(ＰＳＤ)関連の活性化の要否のビット等(ｂ４、ｂ３)を活性化させ、関連データ(７Ｆｈ、３２ｈ)を入れてパケット(Ｒ２)を形成してサービス・サーバー(１)へ送信する。
【００６３】
この時にも、ＵＤＰ/ＩＰ方式で伝送され、パケット(Ｒ２)が非重要データ(ＴＭＤ、ＰＳＤ)のみ含むので、伝送中に損失されても再度送信しない。
【００６４】
次に、サービス・サーバー(７)は、ロボット端末機(１)が左側輪(１１)と、右側輪(１２)で望みの位置(６３ｈ、ＥＦｈ)に移動し、赤外線送信部(１４)へ赤外線弾丸を発射するため銃身を望みの角度(７Ｆｈ)に入るようにし、また、ロボット端末機(１)の赤外線送信部(１４)に一番目の赤外線弾丸を発射するようにするために、パケット(Ｓ３)の活性化の要否のビット等を“１１１００１００”にして左側輪データ(ＬＷＤ)、右側輪データ(ＲＷＤ)、銃身制御データ(ＴＲＤ)、赤外線発射命令ＩＤ番号(ＩＲＦ ＩＤ)関連の活性化の要否のビット(ｂ７、ｂ６、ｂ５、ｂ２)を活性化させ、関連データ(６３ｈ、ＥＦｈ、７Ｆｈ)と、赤外線発射命令ＩＤ番号(０１ｈ)をペイロード領域に入れてパケット(Ｓ３)を形成してロボット端末機(１)へＵＤＰ/ＩＰ方式で送信する。
【００６５】
さて、ロボット端末機(１)が該一番目の赤外線発射命令(ＩＲＦ ＩＤ)(重要データ)を受信して該事実をサービス・サーバー(７)へ知らせてサービス・サーバー(７)がこれ以上該一番目の赤外線発射命令(ＩＲＦ ＩＤ)を送信しないようにし、他のロボット端末機の赤外線送信部(１４)から発射された赤外線弾丸を当たり、三番目で赤外線受信部(１５)により感知され、該三番目の赤外線受信発生ＩＤ番号(ＩＲＲ ＩＤ)(重要データ)をサービス・サーバー(７)へ送信しようとすると仮定する。
【００６６】
それでは、銃身モニター・データ(ＴＭＤ)と、近接センサー・データ(ＰＳＤ)とともに、赤外線発射命令認識番号(ＩＲＦ ＡＣＫ)(０１ｈ)と、赤外線受信発生ＩＤ番号(ＩＲＲ ＩＤ)(０３ｈ)を送信するために、活性化の要否のビット等を“０００１１１１０”にして銃身モニター・データ(ＴＭＤ)と、近接センサー・データ(ＰＳＤ)、及び、赤外線発射命令認知番号(ＩＲＦ ＡＣＫ)と、赤外線受信発生ＩＤ番号(ＩＲＲ ＩＤ)関連の活性化の要否のビット等(ｂ４、ｂ３、ｂ２、ｂ１)を活性化させ、関連データ(７Ｆｈ、４８ｈ、０１ｈ、０３ｈ)を入れてパケット(Ｒ３)を形成してサービス・サーバー(１)へ送信する。
【００６７】
この時、ＵＤＰ/ＩＰ方式で伝送され、パケット(Ｒ３)が重要データ(ＩＲＦ ＡＣＫ、ＩＲＲ ＩＤ)を含む。
【００６８】
次に、サービス・サーバー(７)では該パケット(Ｒ３)を受信すれば、該パケット(Ｒ３)で赤外線発射命令認知番号(ＩＲＦ ＡＣＫ)関連の活性化のビット(ｂ２)が活性化されていて、該パケットの当該データが“０１ｈ”でサービス・サーバー(７)が一番目の赤外線発射命令を要請時のＩＤ番号(０１ｈ)と同一であるので、一番目の赤外線発射命令がロボット端末機(１)で受信されたことがわかるようになり、これ以上該一番目の赤外線発射命令を送信しない。
【００６９】
また、サービス・サーバー(７)が三番目の赤外線受信発生ＩＤ番号(ＩＲＲ ＩＤ)を受信したので、該受信事実をロボット端末機(１)へ知らせるためにパケット(Ｓ４)で活性化の要否のビット(ｂ１)を“１”にして、下段の当該部分に“０３ｈ”を入力して形成されたパケット(Ｓ４)を形成し、ロボット端末機(１)へ送信する。
【００７０】
ロボット端末機(１)では受信されたパケット(Ｓ４)で赤外線受信発生認知番号(ＩＲＲ ＡＣＫ)に対する活性化の要否のビット(ｂ１)が活性化されているので、当該データ(０３ｈ)を読み出して自ら送信した“０３ｈ”と同一であるので、自らサービス・サーバー(７)へ送信した三番目の赤外線受信発生認知番号(ＩＲＲ ＩＤ)をサービス・サーバー(７)が受信したことが確認されたので、これ以上三番目の赤外線受信発生認知番号(ＩＲＲ ＩＤ)をサービス・サーバー(７)へ送信しない。
【００７１】
さて、ロボット端末機(１)は銃身角度をモニターリングしたデータ(ＴＭＤ)と近接センサーで測定した距離に対するデータ(ＰＳＤ)を送信するために、活性化の要否のビット等を“０００１１０００”にして銃身モニター・データ(ＴＭＤ)と、近接センサー・データ(ＰＳＤ)関連の活性化の要否のビット等(ｂ４、ｂ３)を活性化させ、関連データ(７Ｆｈ、９０ｈ)をペイロード領域に入れてパケット(Ｒ４)を形成してサービス・サーバー(１)へ送信する。
【００７２】
この時にも、ＵＤＰ/ＩＰ方式で伝送され、パケット(Ｒ４)が非重要データ(ＴＭＤ、ＰＳＤ)のみ含むので、伝送中に損失されても再度送信しない。
【００７３】
以上で察して見たとおり、本発明の伝送方法を用いれば伝送損失がない場合に重要データは必ず伝送されるようになる。
【００７４】
次に、伝送損失がある場合にも重要データが必ず伝送されるようにする本発明の実施例を図７を参考にして説明する。
【００７５】
この時、パケット(Ｓ１、Ｒ１、Ｓ２、Ｒ２)までは伝送損失がなかったり、パケット(Ｓ３)に対して伝送損失が発生してその他パケット(Ｒ３、Ｓ４、Ｒ４)は伝送損失がないと仮定する。
【００７６】
サービス・サーバー(７)からロボット端末機(１)へ伝送するパケット(Ｓ３)を通信線路等の問題でロボット端末機(１)が受信することができなくて重要データ(一番目の赤外線発射命令)が伝達されることができなかった場合には、ロボット端末機(１)は望むならば補間等の方法で今回の伝送周期に当該する非重要データ(左側輪データ(ＬＷＤ)、右側輪データ(ＲＷＤ)、銃身データ(ＴＲＤ))を復元する。
【００７７】
そしてから、ロボット端末機(１)は自らの任務を行ない続けて銃身モニター・データ(ＴＭＤ)(７Ｆｈ)と、近接センサー・データ(ＰＳＤ)(４８ｈ)を送信し、三番目の赤外線弾丸を当たった場合には三番目の赤外線受信発生の事実を知らせるために、活性化ビット(ｂ４、ｂ３、ｂ１)を活性化させ、銃身モニター・データ(ＴＭＤ)(７Ｆｈ)及び、近接センサー・データ(ＰＳＤ)(４８ｈ)と三番目の赤外線受信発生ＩＤ番号である“０３ｈ”に載せてパケット(Ｒ３)を形成してサービス・サーバー(７)へ送信する。
【００７８】
それでは、サービス・サーバー(７)は該パケット(Ｒ３)を通して自らが送った一番目の赤外線発射命令に対応する活性化の要否のビット(ｂ２)が非活性化の状態であるので、ロボット端末機(１)が一番目の赤外線発射命令を受信することができなかったことがわかることになる。
【００７９】
そして、パケット(Ｒ３)の活性化の要否のビット(ｂ１)の活性化を通してロボット端末機(１)から送信した三番目の赤外線受信発生ＩＤ番号(０３ｈ)を認識する。
【００８０】
このようになれば、サービス・サーバー(７)は、再度一番目の赤外線発射命令(ＩＲＦ ＩＤ)を再送信し、三番目の赤外線受信ＩＤ番号の受信事実(ＩＲＲ ＡＣＫ)をロボット端末機(１)に知らせてくれるために、パケット(Ｓ４)のように活性化の要否のビット(ｂ２、ｂ１)を活性化して一番目の赤外線発射命令ＩＤ番号(ＩＲＦ ＩＤ)である“０１ｈ”と、三番目の赤外線受信発生認知番号(ＩＲＲ ＡＣＫ)である“０３ｈ”をパケット(Ｓ４)に載せてロボット端末機(１)へ送信する。
【００８１】
さて、ロボット端末機(１)が該パケット(Ｓ４)を受信すれば、活性化の要否のビット(ｂ２、ｂ１)が活性化されていてペイロード領域の当該データ(０１ｈ、０３ｈ)を読み出して見ると、サービス・サーバー(７)が一番目の赤外線発射命令を下したし、自らが送信した三番目の赤外線受信発生ＩＤ番号をサービス・サーバー(７)が受信したことがわかるようになる。
【００８２】
このように一番目の赤外線発射命令を受信すれば、ロボット端末機(１)は赤外線送信部(１４)へ赤外線弾丸を発射し、自らが送信した三番目の赤外線受信発生ＩＤ番号をサービス・サーバー(７)が受信したことがわかるようになれば、これ以上ロボット端末機(１)は三番目の赤外線受信発生ＩＤ番号をサービス・サーバー(７)へ送信しないようになる。
【００８３】
次に、ロボット端末機(１)はこのようにサービス・サーバー(７)で下した一番目の赤外線発射命令を受信すれば、活性化の要否のビット(ｂ２)を活性化して当該データ(０１ｈ)を銃身モニター・データ(ＴＭＤ)(７Ｆｈ)と、近接センサー・データ(ＰＳＤ)(９０ｈ)とともに付加して該パケット(Ｒ４)を形成してサービス・サーバー(７)へ送信して一番目の赤外線発射命令が受信されたことを知らせる。
【００８４】
さて、サービス・サーバー(７)からパケット(Ｒ４)を受信すれば、該パケットの活性化の要否のビット(ｂ２)と、当該データ(０１ｈ)を通して一番目の赤外線発射命令をロボット端末機(１)が受信したことがわかるようになり、これ以上サービス・サーバー(７)が一番目の赤外線発射命令をロボット端末機(１)へ送信しないようになる。
【００８５】
結局、以上のような本発明のデータ構造を用いれば、ＵＤＰ/ＩＰ方式の伝送時に伝送損失があっても重要データを必ず伝送することができるようになる。
【００８６】
また、図６、７に示されたとおり、本発明を用いれば、伝送する必要があるデータだけでパケット・データの大きさを最小化することによって伝送の負荷を減らすことができるようになる。
【００８７】
以上では本発明の好ましい実施例を説明したが、本発明は該実施例に限定されるものでなく、本発明の精神を脱しない範囲内で多様な変形が可能であることを留意すべきである。
【００８８】
例えば、以上では説明の便宜上、戦闘ゲームを行なうロボット端末機を仮定し、左右輪データ、銃身角度データ、銃身モニター・データ、近接センサー・データのように、ロボット端末機の動作データ及びセンサー・データを送受信するものと記載したが、本発明はロボット端末機が他のアプリケーションのために動作だけでなく発声をしたり映像表示をする場合に、動作データだけでなくオーディオ(音声、音楽)データ、映像データまでパケット方式で送受信する場合にも適用可能である。
【００８９】
また、以上では、サービス・サーバー(７)とロボット端末機(１)との間での通信のためのパケット・データ・フォーマットに対して説明したが、ロボット端末機(１)がPCと同じローカル・サーバーを内臓している場合には、PCがサービス・サーバーの役割を行なうようにし、ロボット端末機とPCとの間で本発明のパケット・データ・フォーマットを用いた内部通信をするようにすることも可能である。
【００９０】
そして、以上では、ＵＤＰ/ＩＰ方式に対して説明したが、本発明はブルーツース、ＩＥＥＥ ８０２．１５．４(ジグビー(Ｚｉｇｂｅｅ)方式)、無線ＵＳＢ等を用いる時にも適用可能である。
【００９１】
（索引語）
ロボット端末機、ネットワーク、パケット、データ構造、重要データ、活性化。
【図面の簡単な説明】
【００９２】
【図１】図１は、従来技術によるロボット端末機システムを示す。
【図２】図２は、図１の従来技術で用いられる通信方式を説明する図面。
【図３】図３は、図２の従来技術で用いられるパケット・データのフォーマットを示す。
【図４】図４は、本発明が適用されることができる戦闘ゲーム用ロボット端末機の外形図。
【図５】図５は、本発明のパケット・データ・フォーマットを示す。
【図６】図６は、図５のパケット・データ・フォーマットを用いて伝送損失がない場合にパケット・データを伝送する方法を示す。
【図７】図７は、図５のパケット・データ・フォーマットを用いて伝送損失がある場合にパケット・データを伝送する方法を示す。
【図１】
2008278451.tif 000003
【図２】
2008278451.tif 000004
【図３】
2008278451.tif 000005
【図４】
2008278451.tif 000006
【図５】
2008278451.tif 000007
【図６】
2008278451.tif 000008
【図７】
2008278451.tif 000009