JP2014504958A - 物理的および仮想的資源の管理プログラムを備えるヒューマノイドロボット、使用方法、およびプログラミング方法 - Google Patents

Abstract

本発明は、物理的および仮想的資源のための管理プログラムを備えるヒューマノイドロボットと、使用方法と、管理プログラムをプログラムするための方法とに関する。資源（１４０、１４１０、１４２０）は行動（１３０、１３１０、１３２０）を実行するように要求される。資源と行動は、オブジェクトツリーで随意的に定義される階層的サブセットに組織化される。行動による資源の使用の競合は局所的に解決され、資源を予約する行動は、ユーザに、行動を予約することにより資源をロックする選択肢と、第１の他の要求する行動に賛成して解放する選択肢と、進行中のまたは休止の行動の部分的実行の選択肢と、を提示するようにプログラムされる。ソフトウェアツールキットは、行動のプログラミングを可能にする開発環境においてグラフィック的やり方で本発明の資源管理プログラムをプログラムすることを可能にする。

Description

本発明はヒューマノイドロボットの分野に属する。より正確には、本発明は、特には、ヒューマノイドロボットにより実施される行動をヒューマノイドロボットの何人かのユーザが独立にプログラムする際のヒューマノイドロボットの資源の管理に適用される。

ロボットは、人間の外観および機能性（例えば、頭、胴、両腕、両手、両脚、両足など）のいくつかの属性を有する限りヒューマノイドと称され得る。外観以外では、ヒューマノイドロボットが達成できる機能は、運動を行い、話し、「推論する」その能力に依存する。ヒューマノイドロボットは四肢または頭を使って歩行し、身振りをすることができる。ヒューマノイドロボットが行うことができる身振りの複雑さは引き続き増加している。互いに連携されたまたは話すことと連携された身振り（例えば上げられる腕、耳障りなトーンで話されるおどし文句）とロボットの一部（特には、そのＬＥＤ）により発せられる信号は、ロボットの「感情」（例えば怒り）を伝達するロボットの行動の表現である可能性がある。本発明を実施するための概念と手段が開発されたプラットホームであるいくつかのロボット（特にはＮＡＯロボット）は、何人かのユーザに、互いに独立して行動を開発する可能性を提供する。これらの可能性は、Ｃｈｏｒｅｇｒａｐｈｅソフトウェアなどのユーザ言語を採用する開発ツールにより著しく高められる。その結果、付随的に使用されなければならない資源の可用性の同期を保証するとともに一定数の機能の実行の優先度を管理するために特にはロボットまたはロボット群のハードウェアおよびソフトウェア資源の使用の競合を回避するように、異なるユーザによりプログラムされる様々な行動の一貫性をその実行時にいかに保証するかを知る問題が発生する。

モータの保護を保証するとともにいくつかの行動によるそれらの同時使用を禁止することがロボット工学では伝統的である。これは、この資源の管理の一般的問題に対する第１のタイプの解決策であるが一般的解決策ではない。特に、このタイプの解決策は、異なる資源の同期によりもたらされる問題に対するまたは資源の解放の問題に対するいかなる対応も提供しない。

他の技術分野において長期にわたる資源の割り当てのこれらの問題を解決するために、特には制約ベース論理プログラミングタイプのアルゴリズムを使用することにより資源の割り当てに際し最適化機構を実施することが伝統的である。しかし、これらのアルゴリズムは計算資源という意味で大食いであるので、直ちに消費されない資源の割り当ての計算に適する。具体的には、これらは、複数の行動を有するヒューマノイドロボット上のそのごく少数の行動だけに使用できるかもしれない。

したがって、独立処理に対するハードウェアまたはソフトウェア資源の割り当てまたは他のタイプの資源の割り当ての問題を解決できるようにするいかなる解決策も従来技術には存在しない。

本発明は、局所的または非集中的解決機構と結合された資源の階層的定義を提供することによりこの問題を解決する。

この目的のため、本発明は、複数の行動の実行に割り当てることができる複数の資源を管理するためのサブモジュールを含む搭載管理モジュールの制御下で複数の行動を実行することができるヒューマノイドロボットであって、複数の行動と複数の資源はそれぞれ階層的サブセットに組織化され、資源を管理するためのサブモジュールは、複数の行動の少なくとも１つのサブセットに属する少なくとも１つの行動の実行のための複数の資源の少なくとも１つのサブセットに属する少なくとも１つの資源を予約するようにプログラムされることができ、予約は複数の行動のサブセットにより継承されるおよび／または複数の資源のサブセットに適用されるようにプログラムされることができる、ことを特徴とするヒューマノイドロボットを開示する。

有利には、複数の資源を管理するためのサブモジュールは、第１の行動を実行中に、以下の行為、すなわち、資源を第２の行動に利用可能にすることに対する拒絶、第２の行動に対し資源を直ちに利用可能にすること、第２の行動に対し資源を利用可能にすることに続く少なくとも１つの追加の行為の実行、第２の行動に対し資源を利用可能にすることに続く現在実行中の第１の行動の休止、のうちの少なくとも１つを有する第２の行動による資源要求に応答するようにプログラムされる。

有利には、複数の資源を管理するためのサブモジュールは、第２の行動により要求された資源を利用可能にすることに対する拒絶の行為が実行されると、第２の行動が再び、同様に所定の終了期限の終了まで所定の頻度に従って利用可能にする要求を実行するように、プログラムされる。

有利には、複数の資源を管理するためのサブモジュールは、少なくとも２つの行動が同一の資源を利用可能にする要求を実行すると、少なくとも２つの行動の第１の行動は後者が解放されると同じ資源の予約の優先度を有するようにプログラムされる。

有利には、複数の資源を管理するためのサブモジュールは、少なくとも１つの行動が少なくとも２つの資源を利用可能にする要求を実行すると、少なくとも２つの資源は単一資源として処理される新しい資源にグループ化され、上記グループ化は、同一の資源要求を実行するすべての行動に対して一意的やり方で順序付けられるようにプログラムされる。

有利には、複数の資源を管理するためのサブモジュールは、親行動がそれを使用することなく少なくとも１つの資源を予約すると、少なくとも１つの資源は親行動の子行動により使用されることができるようにプログラムされる。

有利には、複数の資源を管理するためのサブモジュールは、第１の子行動が親行動により予約された資源を使用すると、同じ親の第２の子行動は、同資源を使用することができるように第１の子行動により資源を利用可能にする要求を行わなければならないようにプログラムされる。

有利には、複数の資源を管理するためのサブモジュールは、親行動がその予約された資源を解放すると、同資源は親の任意の子行動により解放されなければならないようにプログラムされる。

有利には、複数の資源を管理するためのサブモジュールは、複数の資源のサブセットが可用性を下げたとき、可用性の低下の関数として定義される仮想行動のための資源の予約を実行するようにプログラムされる。

有利には、複数の資源を管理するためのサブモジュールは、可用性の低下の状態の進展の関数として予約を解放するようにプログラムされる。

有利には、複数の資源は、少なくとも１つの行動の実行に必要な予約が行われるように所定の状態でなければならない少なくとも１つの状態変数を含む。

有利には、複数の資源は少なくとも１つの累積資源（ａｃｃｕｍｕｌａｔｉｖｅ ｒｅｓｏｕｒｃｅ）を含み、複数の資源は、後者の使用率が少なくとも１つの資源を使用するようにプログラムされた行動に割り当てられることを特徴とする。

有利には、複数の資源は少なくとも１つの必須資源と１つの非必須資源を含み、任意の行動は、必須資源が利用可能でなければ実行することができない少なくとも１つの必須資源であって、少なくとも１つの非必須資源を呼び出さなければならなければたとえ後者が利用可能でなくても実行することができる少なくとも１つの必須資源を呼び出さなければならない。

本発明はまた、搭載管理モジュールの制御下で複数の行動を実行することができるヒューマノイドロボットの資源を管理する方法を開示する。本方法は、行動の実行に割り当てることができる複数の資源を予約する工程を含み、複数の行動と複数の資源はそれぞれ階層的サブセットに組織化され、予約工程は、複数の行動の少なくとも１つのサブセットに属する少なくとも１つの行動の実行に資源の少なくとも１つのサブセットに属する少なくとも１つの資源を割り当て、予約は複数の行動のサブセットにより継承されるおよび／または複数の資源のサブセットに適用されるようにプログラムされることができる、ことを特徴とする。

本発明はまた、コンピュータ上で実行されると本方法の実行を可能にするプログラムコード命令を含むコンピュータプログラムを開示する。上記プログラムは、搭載管理サブルーチンの制御下で複数の行動を実行することができるヒューマノイドロボットの資源の管理を可能にするように適合化され、上記サブルーチンは、複数の行動の実行に割り当てることができる複数の資源の予約のための機能を実行することができるモジュールを含む。本プログラムは、複数の行動と複数の資源がそれぞれ階層的サブセットに組織化され、予約機能が、複数の行動の少なくとも１つのサブセットに属する少なくとも１つの行動の実行に複数の資源の少なくとも１つのサブセットに属する少なくとも１つの資源を割り当て、予約は複数の行動のサブセットにより継承されるおよび／または複数の資源のサブセットに適用されるようにプログラムされることができる、ことを特徴とする。

有利には、複数の行動と複数の資源のサブセットはオブジェクトのクラスとして定義される。

本発明はまた、ヒューマノイドロボットの資源を管理するためのモジュールを開発する方法とこの方法を実施するためのコンピュータプログラムとを開示する。

本発明はさらに、同一のプロセッサ上で並行して実行する処理を有するコンピュータシステムにおいて頻繁であるロックアップ状況を回避するという利点を提供する。本発明はまた、状態に対応する仮想資源を含む多種多様の資源を管理できるようにし、その凍結は、ロボットのロックアップまたは危険な状況を生じる傾向があるであろう行動の起動を回避できるようにする。

本発明は、いくつかの例示的実施形態の以下の説明とその添付図面からより良く理解され、その様々な特性と利点が浮かび上がることになる。

本発明がその実施形態のうちのいくつかにおいて実施される機能アーキテクチャの線図である。 その実施形態のうちのいくつかにおいて本発明の実施を可能にするコンピュータプログラムの画面図である。 本発明のいくつかの実施形態における、利用可能資源のリストの形式とボックスに基づくグラフィックプログラミングの形式の資源管理方式をそれぞれ表す。 本発明のいくつかの実施形態における、機能流れ図の形式とポップアップグラフィックメニュー形式で様々なタイプの資源を同期させるための機構をそれぞれ表す。 本発明のいくつかの実施形態における、機能流れ図の形式とポップアップグラフィックメニュー形式でクリティカル資源を予約するための機構をそれぞれ表す。 本発明のいくつかの実施形態における、ポップアップグラフィックメニュー形式とボックスに基づくグラフィックプログラミングの形式の資源の予約の継承機構をそれぞれ表す。 本発明のいくつかの実施形態における、完全なロボット、胴ロボット、利用可能／利用不能資源のリストをそれぞれ表すことにより、存在しない資源の管理の問題事項を示す。 本発明のいくつかの実施形態における、機能流れ図形式（図８ａ）で、競合の様々な終了オプションに対応するポップアップグラフィックメニューの形式（図８ｂ−ｅ）で、競合を解決するためのいくつかの方式をそれぞれ示す。 本発明のいくつかの実施形態における、ポップアップグラフィックメニュー形式の状態資源（ｓｔａｔｅ ｒｅｓｏｕｒｃｅ）の使用を示す。 本発明のいくつかの実施形態における、共有累積資源の使用の機能流れ図を表す。

図１は、本発明がその実施形態のうちのいくつかにおいて実施される機能アーキテクチャの線図である。根底にある物理的アーキテクチャは、その例示的実施形態が以下に与えられるヒューマノイドロボット１１０と、任意選択的に行動１６０を生成するためのソフトウェアワークショップを備えた遠隔ワークステーション１５０と、からなる。

商標ＮＡＯ（商標）を有するヒューマノイドロボットが知られている。このようなロボットは、特に２００９年１０月１５日公開の国際公開第２００９／１２４９５１号パンフレットに開示されている。このプラットホームは、本発明に至る改良のためのベースとして役立った。以下の説明では、このヒューマノイドロボットはこの総称用語またはその商標ＮＡＯ（商標）のいずれかで示され得るが、これにより参照の一般性が変更されることはない。このロボットは、センサと関節を駆動するアクチュエータとを制御するための約２ダースの電子カードを含む。関節は通常、少なくとも２つの自由度したがって２つのモータを有する。各モータは角度の意味で駆動される。関節はまた、いくつかの位置センサ、特にＭＲＥ（磁気回転符合器：Ｍａｇｎｅｔｉｃ Ｒｏｔａｒｙ Ｅｎｃｏｄｅｒ）を含む。電子制御カードは市販のマイクロコントローラを含む。これは例えばＭｉｃｒｏｃｈｉｐ社のＤＳＰＩＣ（商標）である可能性がある。これはＤＳＰに結合された１６ビットＭＣＵである。このＭＣＵは１ミリ秒のループ連動化サイクル（ｌｏｏｐｅｄ ｓｌａｖｉｎｇ ｃｙｃｌｅ）を有する。ロボットはまた、他のタイプのアクチュエータ、特にその色と強度がロボットの感情を伝えることができるＬＥＤ（発光ダイオード）を含むことができる。後者はまた、他のタイプの位置センサ、特には慣性ユニット、ＦＳＲ（接地圧センサ）を含むことができる。

頭は、ロボットの知能、特にロボットに割り当てられた使命をロボットが達成できるようにするハイレベル機能を実行するカードを含む。カードのプロセッサは市販のｘ８６プロセッサである可能性がある。ＡＭＤ社のＧｅｏｄｅ（商標）（３２ビット、５００ＭＨｚ）などの低消費電力プロセッサが好適なやり方で選択されることになる。カードはまた、一組のＲＡＭとフラッシュメモリを含む。このカードはまた、通常はＷｉＦｉ、ＷｉＭａｘトランスミッションレイヤ上で、任意選択的にはＶＰＮ内の任意選択的にカプセル化された（ｅｎｃａｐｓｕｌａｔｅｄ）標準プロトコルを有するデータの移動体通信用公衆ネットワーク上で、外部（行動のサーバ、他のロボットなど）とロボットとの通信を管理する。プロセッサは通常、標準ＯＳにより駆動され、これにより通常のハイレベル言語（Ｃ、Ｃ＋＋、Ｐｙｔｈｏｎ等）、またはハイレベル機能をプログラムするためのＵＲＢＩ（ロボット工学のための特殊なプログラミング言語）などの人工知能用特定言語を使用できるようにする。

別のカードがロボットの胴内に収容される。これは、頭のカードにより計算される命令の関節制御カードへの送信を保証するコンピュータが位置する場所である。このカードのコンピュータもまた市販のプロセッサである。これは、１００ＭＨｚクロックのＡＲＭ９（商標）タイプの３２ビットプロセッサであると有利である可能性がある。プロセッサのタイプ、オン／オフボタンに近いその中央位置、電源の制御へのそのリンクは、ロボットの電源（アイドルモード、緊急停止等）を管理するのに非常に好適なツールとなる。カードはまた、一組のＲＡＭとフラッシュメモリを含む。

ロボットの知能は、ＮＡＯＱＩの異名をもつ真のオペレーティングおよびロボットインターフェース管理システム１２０を構成する特定のソフトウェアアーキテクチャに従ってインストールされる。このアーキテクチャは、特には２００９年１０月１５日公開の国際公開第２００９／１２４９５５号パンフレットに開示されている。このアーキテクチャを構成するソフトウエアモジュールは、ロボットとＰＣまたは遠隔場所との間の通信を管理するためのシステム機能と、本発明を実施するために必要なソフトウェアインフラストラクチャを提供するソフトウェアを交換するためのシステム機能とを含む。このアーキテクチャは、移動、一肢を動かす、センサの信号を解釈する、アクチュエータを介し信号を送るなどのロボットの基本機能を管理するために必要な機能を含む。このアーキテクチャはまた、ロボットのユーザが、ダンスステップ、スピーチ、または感情などの複雑な連携された身振り（これらは通常、身振り、スピーチ、ＬＥＤなどのアクチュエータによる信号の発射の組合せである）を含む行動（身振りでもよい）１３０、１３１０、１３２０のロボットによる実行を制御するためのソフトウエアプログラムを後者の内蔵メモリ内にインストールできるようにする。これらの行動の実行に関し、ロボットは資源１４０、１４１０、１４２０を呼び出さなければならなくなる。本発明は、複数の行動の葛藤の無い実行を可能にするように資源を管理するための方式に関係する。それは、実質的に、資源を管理するためのモジュールすなわち「資源管理プログラムサーバ（Ｒｅｓｏｕｒｃｅ ｍａｎａｇｅｒ ｓｅｒｖｅｒ）」１２１０において実施される。このモジュールの詳細な動作については本明細書において以降説明する。

その目的言語がＣ、Ｃ＋＋、Ｐｙｔｈｏｎ、またはＵｒｂｉである任意のソフトウェアを使用することにより、ワークステーション１５０などの遠隔端末装置上でロボットにより実行される行動をプログラムすることが可能である。しかし、本発明を実施するためには、ヒューマノイドロボットの行動を編集およびプログラムするための特定の機能アーキテクチャが有利には使用されることになる。このようなアーキテクチャについては、２０１０年５月２５日出願の欧州特許出願第２０１０／０５７１１１号明細書により説明されている。上記アーキテクチャを実装できるようにするヒューマノイドロボット１６０の行動を編集しプログラムするためのソフトウェアワークショップは商標Ｃｈｏｒｅｇｒａｐｈｅ（商標）を有しており、上記特許文献の一般性を損なうことなくその総称または商標のいずれかで呼ぶことがある。このアーキテクチャは、その時間次元を有する事象によりトリガされる指令の表現を容易に実現できるようにするので、ロボット行動を生成するのに特に有効である。事象によりトリガされる指令は、Ｃｈｏｒｅｇｒａｐｈｅでは「ボックス」または「制御ボックス」により表される。ボックスは、この後定義される以下の要素の１つまたは複数を含むことができるツリー状のプログラミング構造である。
−フレームの「タイムライン」または時間軸、
−「図表」または流れ図、
−スクリプト。

制御ボックスは通常、事象情報項目を１つのボックスから別のボックスへ通常は送信する接続部により相互にリンクされる。いかなるボックスも、ロボットの行動／動きのシナリオを初期化する「ルートボックス」またはルートへ直接または間接的にリンクされる。

フレームの時間軸は、フレームの時間軸すなわちタイムラインが挿入されるボックス内に定義されたロボットの行動と動きとが受ける時間的制約を表す。したがってタイムラインはボックスの行動と動きの同期を行う。タイムラインは、毎秒当たりのフレームの数すなわち毎秒フレーム数（ＦＰＳ：Ｆｒａｍｅｓ Ｐｅｒ Ｓｅｃｏｎｄ）として定義される進捗速度に関連付けられたフレームに細切れにされる。各タイムラインのＦＰＳはユーザによりパラメタータ化可能である。デフォルト設定では、ＦＰＳは任意の値（例えば、１５ＦＰＳ）で固定することができる。

タイムラインは次のものを含むことができる。ｉ）それぞれが１つまたは複数の行動キーフレーム（Ｂｅｈａｖｉｏｒ Ｋｅｙ Ｆｒａｍｅｓ）または「主行動フレーム（ｍａｉｎ ｂｅｈａｖｉｏｒ Ｆｒａｍｅ）」を含む１つまたは複数の行動レイヤ（Ｂｅｈａｖｉｏｒ Ｌａｙｅｒ）であって、上記行動キーフレーム自体が、行動レイヤまたはタイムラインを通過することなく、実際はより高いレベルのボックスにも直接取り付けることができるボックスの組である１つまたは複数の図表または「流れ図」を含むことができる、行動レイヤ、ｉｉ）それぞれが、１つまたは複数の運動画面（Ｍｏｔｉｏｎ Ｓｃｒｅｅｎ）を含むことができる、１つまたは複数の運動キーフレームまたは「主運動フレーム」。

流れ図は後で詳述されるように相互に接続された一組のボックスである。ボックスのそれぞれは次に、新しい行動または運動レイヤが取り付けられる他のタイムラインを含むことができる。

スクリプトはロボットにより直接実行可能なプログラムである。本発明の枠組み内では、スクリプトは好ましいやり方でＣ＋＋言語で書かれる。スクリプトを含むボックスはいかなる他の要素も含まない。

ソフトウェアは、Ｗｉｎｄｏｗｓ（商標）、Ｍａｃ（商標）、またはＬｉｎｕｘ（商標）オペレーティングシステムを使用するＰＣ上またはパーソナルコンピュータ型の別のプラットホーム上にインストールすることができる。

本発明の枠組み内では、「資源管理クライアント」の異名をもつＣｈｏｒｅｇｒａｐｈｅモジュールであると考えられ得る特定のＣｈｏｒｅｇｒａｐｈｅ画面１６１０が、資源管理プログラムサーバモジュール１２１０上に埋め込まれるスクリプトを生成することによりＮＡＯなどのヒューマノイドロボットの資源を管理するための規則のプログラミングを可能にする。互いの中に含むことができるＣｈｏｒｅｇｒａｐｈｅボックスの設計は、本発明の実施に特に有利である。実際、親行動として記載することができる図１のより高いレベルの行動１３０は、親行動のボックス内に含まれるボックスによりグラフィック的（予めプログラムされたボックスと相互接続部のドラッグアンドドロップ）に符号化することが可能な例えば２つの子行動１３１０、１３２０を含み得る。例えば左脚資源と右脚資源を示す基本資源１４１０、１４２０は下肢単一資源１４０にグループ化することができる。左脚と右脚自体は、それぞれが腿、膝、下肢脚、足首、足を含む複合資源であり、これらのサブセットのそれぞれ自体が１つまたは複数のモータ、１つまたは複数のセンサ、１つまたは複数のアクチュエータを含むことができる。Ｃｈｏｒｅｇｒａｐｈｅは、行動が必要とするものが利用可能であると仮定することにより、タイムラインを手段として資源の同期を管理する。Ｃｈｏｒｅｇｒａｐｈｅは、本発明の資源管理プログラムサーバが無ければ、資源を利用可能にすることを管理しない。

モータなどの低レベル資源を利用可能にすることに関する競合は、「相互排除」すなわちミューテックス（ｍｕｔｅｘ）タイプの在来型アルゴリズムにより解決することができる。このようなアルゴリズムは、２つの同時処理により、このようにして管理される資源の獲得を排除する一般的な特徴を有する。このタイプのアルゴリズムは、特に優先度と待機を管理する機構によって異なる。しかし、このようなアルゴリズムは、処理が複合資源にアクセスしなければならないとき、より高いレベルの競合の簡単な解決を可能にしない。さらに、この問題に対する解決策は、ロボットが人間の外観を有するためにロボットの行動の必然的に非常に短い時定数と、アルゴリズムのＣＰＵ消費電力と、ロボット上に埋め込まれた計算資源の弱さとを考慮した資源間割り当て最適化アルゴリズムの行使によっては考えられ得ない。

本発明の枠組み内で解決される資源管理問題に関する別の困難さは、何人かのユーザが互いに独立して行動をプログラムし、それぞれが同一のロボット（当然、そうする権利を与えられているという条件で）上にその行動をインストールできるということである。

本明細書を通して説明されるように、行動および資源のアーキテクチャとこれらのエンティティ間の関係を管理するための機能とは、特に本発明の枠組み内で、以下のことを可能にする：資源競合を回避すること（２つの行動が同じモータを同時に使用できない、同一のボールを操作する２つの行動は同時に実行できない）；異なる資源の使用を同期すること（こんにちはと言う、腕とオーディオが使用される；これらの２つの資源は一貫性のある行動を得るために同時に利用可能でなければならない）；様々なロボットモデル（例えば、腕を持たなく、脚と車輪等を有するロボット）と欠陥があるまたは低下（省エネ）モードで動作中の四肢を有するロボットを管理すること；マルチスレッドシステム（いくつかの処理が並行して実行される）における資源の割り当てに関するデッドロックまたはロックアップの状況を回避すること；競合解決機構を有すること；クリティカル行動のための資源の可用性を保証すること；どんな行動でもロボットを保護すること（例えば転倒しないこと）。

資源管理プログラムサーバ１２１０は資源の可用性を保証する。資源管理プログラムサーバ１２１０は、オブジェクト開発のフレームワーク内に階層的データ構造を有し、親オブジェクトまたは行動は資源を予約することができ、次に子行動は資源を得ることを保証される。資源管理プログラムサーバ１２１０はまた、競合を速やかに解決できるようにする。この解決策は非集中的／局所的であり、これにより制約解決エンジンの数学的およびアルゴリズム的複雑さ（計算時間）を回避できるようにする。競合を発生するものがその競合を解決し、資源管理クライアントはいかなる計算も行わない。

資源管理プログラムサーバは、マルチスレッドシステムにおけるロックアップ／デッドロックを回避できるようにする機構を含む（例えば、一群の資源の共同管理−すなわちすべてのモータを単一資源すなわち１つのモータとして共同管理）。システムはまた包括的であり、機能性と資源がネスト化される他のシステムと対照的に、資源管理プログラムは任意のタイプの資源を管理することができ、機能性に拘束されない。従来の手法と、本発明の資源管理プログラムがそうであるように追加の抽出レベル（これらの様々な資源の同期）を許容することなく機能性内のデータの正確な項目を保護するセマフォ／ミューテックスと、を比較することが可能である。

図２ａと図２ｂは、その実施形態のうちのいくつかにおいて本発明の実施を可能にするコンピュータプログラムの画面図である。

図２ａでは、Ｃｈｏｒｅｇｒａｐｈｅ画面が表される。Ｃｈｏｒｅｇｒａｐｈｅモジュール１６０はロボット上に行動１３０，１３１０，１３２０および行動により使用される資源１４０、１４１０、１４２０をロードし、資源を予約するための規則は、本明細書の後で詳述される方式に従って資源管理プログラムクライアント１６１０において予め定義される。資源管理プログラムサーバ１２１０は資源管理プログラムクライアントに対応するロボット上の相手方である。

Ｃｈｏｒｅｇｒａｐｈｅが資源を参照するとき、Ｃｈｏｒｅｇｒａｐｈｅはロボットのサーバ（またはＰＣ上に模擬されたロボットから）からの資源を要求する。実行毎に、Ｃｈｏｒｅｇｒａｐｈｅコードがロボットに転送される。

図２ｂに表された初期設定ファイルは、ロボットの一組の資源を列挙する。ロボットは有利には、クライアント１６１０の要求があるとステーション１５０へ資源のリストを戻すウェブサーバ１２２０を含む。上記リストは資源管理プログラムクライアント１６１０において閲覧することができる。上記リストはＣｈｏｒｅｇｒａｐｈｅ（ロボットのクライアントＣｈｏｒｅｇｒａｐｈｅ）またはウエブブラウザ（ロボットのクライアントウェブページ）により閲覧することができる。しかし、本発明はＣｈｏｒｅｇｒａｐｈｅまたは資源管理プログラムクライアントモジュール１６１０に頼ることなく完全に実施することができるということに留意されたい。この場合、サーバステーション１５０はＮＡＯＱＩモジュール１２０により解釈される行動をロボットへ送り、サーバ１２２０上の資源のリストを獲得し、行動の階層化と併せて資源のグループ化は資源管理プログラムサーバ１２１０において行われる。

したがって、資源管理プログラムサーバ１２１０は利用可能な一組の資源を定義するロボットのモジュール（ＮＡＯＱＩのサブセット）である。行動は行為（運動、オーディオ、映像）を含む。行動は、Ｃ＋＋またはＰｙｔｈｏｎで符号化される、またはグラフィック的に実行される（ＰｙｔｈｏｎまたはＣ＋＋隠蔽（ｅｎｃａｐｓｕｌａｔｉｏｎ））。ロボットのウェブサーバは、ブラウザ内に、資源のリストと、資源を使用する行動と、資源の可用性を待つ行動と、を戻すことができる。資源は階層的であるので、ユーザは、ロボットの最上部、最下部、脚を、これらのパーツのそれぞれに位置するモータの詳細を知ることなしに容易に占有することができる。

ＡＰＩ（アプリケーションプログラミングインターフェース：Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）は、Ｃ＋＋、ｐｙｔｈｏｎ（ラップＣ＋＋（ｗｒａｐｐｅｄ Ｃ＋＋））、またはグラフィック言語（Ｃ＋＋またはｐｙｔｈｏｎの隠蔽）で資源管理プログラム１２１０を使用できるようにし、また以下の指令を発生できるようにする。
−単一資源を獲得するまたは待つ、すなわち空（ｖｏｉｄ）ｗａｉｔＦｏｒＲｅｓｏｕｒｃｅ（ｃｏｎｓｔ ｓｔｒｉｎｇ& ｒｅｓｏｕｒｃｅＮａｍｅ、ｃｏｎｓｔ ｓｔｒｉｎｇ& ｏｗｎｅｒＮａｍｅ、ｃｏｎｓｔ ｓｔｒｉｎｇ& ｃａｌｌｂａｃｋＮａｍｅ、ｃｏｎｓｔ ｉｎｔ& ｔｉｍｅｏｕｔＳｅｃｏｎｄｓ）；
−行動間の階層的情報を与える一方で単一資源を獲得するまたは待つ（以降の本明細書では、資源を予約する行動は「オーナ（Ｏｗｎｅｒ）」と呼ばれる）、すなわちｖｏｉｄｗａｉｔＦｏｒＬｏｃａｌＲｅｓｏｕｒｃｅｓＴｒｅｅ（ｃｏｎｓｔ ｖｅｃｔｏｒ<ｓｔｒｉｎｇ>& ｒｅｓｏｕｒｃｅＮａｍｅ、ｃｏｎｓｔ ｃｌａｓｓ ＡＬ：：ＡＬＰｔｒ<ｃｌａｓｓ ＡＬ：：ＡＬＨｉｅｒａｒｃｈｙＯｗｎｅｒ>& ｔｒｅｅＯｗｎｅｒＰｔｒ、ｃｏｎｓｔ ｓｔｒｉｎｇ& ｃａｌｌｂａｃｋＮａｍｅ、ｃｏｎｓｔ ｉｎｔ& ｔｉｍｅｏｕｔＳｅｃｏｎｄｓ）；
−資源を解放する、すなわちｖｏｉｄｒｅｌｅａｓｅＲｅｓｏｕｒｃｅ（ｃｏｎｓｔ ｓｔｒｉｎｇ& ｒｅｓｏｕｒｃｅＮａｍｅ、ｃｏｎｓｔ ｓｔｒｉｎｇ& ｏｗｎｅｒＮａｍｅ）。

図３ａと図３ｂは、本発明のいくつかの実施形態における、利用可能資源のリストの形式とボックスに基づくグラフィックプログラミングの形式の資源管理方式をそれぞれ表す。

これらの図は、単一資源上の競合の管理に適用される処理動作の原理を示す。

単一資源（例えばモータ）の場合、これはいかなるデッドロックも回避するようにする。資源のリストだけがミューテックスタイプのアルゴリズムの助けを借りて保護され、このミューテックスは資源追加または削除に使用される。（資源の解放を待つ）競合自体はスレッドセーフであるが保護されない。ミューテックスはアプリケーションをスレッドセーフ（いくつかのスレッドを有する並列システム上でアクセス可能）にするために標準ライブラリを保護するシステムである。一方、これらはデッドロックを防止しない。したがって、我々は資源のリストを保護するためにミューテックスだけを使用する。競合解決策はロックアップシステム（すなわちミューテックス）を呼び出さないが、スレッドセーフである。

資源の予約の際の競合解決策は以下の原理を適用することにより行われる。ｉ）マルチスレッドシステムでは、２人のオーナが同時に同じ資源を獲得することができない。したがって、我々は、ミューテックスによりロックされた資源を取得する非無効化試み（ｎｏｎ−ｄｉｓａｂｌｉｎｇ ａｔｔｅｍｐｔ）であるトライロック（ｔｒｙ−ｌｏｃｋ）を有する要求を保護する。ｉｉ）２人のオーナが（ＯＳのスケジューラにより定義された）全く同時に同じ資源を要求すると、すべてのオーナは競合を解決しなければならないが、資源が自由になった時にその資源を最初のオーナが取得する（早い者勝ち）。

このタイプの例は、図３ａの資源のリストと、図３ｂのボックスと、Ｃｈｏｒｅｇｒａｐｈｅ依存関係を定義するための画面の図とにより示される。

この例では、ＭｏｖｅＨｅａｄ１が資源を保有する。ＭｏｖｅＨｅａｄ２は資源を待つ。ＭｏｖｅＨｅａｄ３もまた資源を待つであろうが、ＭｏｖｅＨｅａｄ２はそれを最初に取得するだろう（早い者勝ち）。

資源の割り当てはスマートポインタにより行われる（インテリジェントポインタは、指示された資源上で実行されこれによりミューテックスの使用を回避するカプセル化コード（ｅｎｃａｐｓｕｌａｔｅｄ ｃｏｄｅ）を含む（割り当てはＯＳにとってアトミックでなければならない））。

２つのスレッドがＡ＝Ｂ（または示されたアプリケーションの場合にはＯｗｎｅｒＲｅｓｏｕｒｃｅＡ＝ｎｅｗ＿Ｏｗｎｅｒ）を実行している場合、コードラインＡ＝Ｂはミューテックスにより保護されなければならなく、そうでなければアプリケーションは２つのスレッドがそれを実行した瞬間に妨げられる。今や、我々はこの競合を解決するためにミューテックスを使用したくない。しかし、ある特定の状況では、Ａ＝Ｂは、特にはＡとＢが別のスレッドによるＡ＝Ｂの遮断を決して引き起こす（およびアプリケーションをクラッシュさせる）ことができないアトミックタイプ（整数、浮動型等の）であれば、保護される必要はない。これが、ＯｗｎｅｒＲｅｓｏｕｒｃｅＡ＝ｎｅｗ＿ＯｗｎｅｒにおいてｏｗｎｅｒＲｅｓｏｕｒｃｅＡとｎｅｗ＿Ｏｗｎｅｒが整数（ポインタ）である理由である。したがって、いかなるミューテックスも存在しない状況では、我々のアプリケーションはロックアップ（デッドロック）することができない。

このときアルゴリズムは以下のタイプである。
資源ヘッド（Ｒｅｓｏｕｒｃｅ−ｈｅａｄ）を待つ
トライロックによる同時要求の検出
競合の解決（待つまたはタイムアウト）
自分がトライロックによる最初の入力者ならば、
ｐｏｉｎｔ−ｔｏ−ｍｙ−ｏｌｄ−ｏｗｎｅｒ＝ｐｏｉｎｔ−ｔｏ−ｍｙ−ｎｅｗ−ｏｗｎｅｒ
そうでなければさらに競合を解決する。

Ｃｈｏｒｅｇｒａｐｈｅでは、ＭｏｖｅＨｅａｄボックスが使用される。２つの頭移動は並列であり、それらのそれぞれは同じモータを参照する。ここで、ロックオプションは、他の要求者が、それらのタイムアウトの限界を待つスタンバイ状態に置かれることになることを意味する。

図４ａと図４ｂは、本発明のいくつかの実施形態における、機能流れ図の形式とポップアップグラフィックメニュー形式で様々なタイプの資源を同期させるための機構をそれぞれ表す。

これらの図は、同一のオーナ（行動、オブジェクト）が、実行できるように利用可能でなければならないいくつかの資源を要求する場合を示す。オーナはＣｈｏｒｅｇｒａｐｈｅボックスであり得るが、階層的特性も保有するＣ＋＋オブジェクト（オブジェクト指向の意味内で）でもよい。

オブジェクトまたは行動は待機して待つまたは既に資源を予約している。オーナがいくつかの資源を要求すると、サブ資源を参照する新しい一意的資源が生成される。この新しい資源は、各資源（例えばモータ）と資源群を同じ様に処理できるようにする（同じタイムアウト）。図４ａの機能流れ図により示されたこの機構は、特に、単一の資源が利用可能でなければすべての資源を待つことを停止できるようにする。本発明の方法はこうしてロックアップ（デッドロック）を回避する。

一方、次のアルゴリズムはうまくいかないであろう。
ｓｅｉｚｅ（Ｌｉｓｔ＿ｒｅｓｏｕｒｃｅｓ）
Ｆｏｒ ｅａｃｈ ｒｅｓｏｕｒｃｅ
ｒｅｑｕｅｓｔ＿ａｎｄ＿ｓｅｉｚｅ ｔｈｅ ｒｅｓｏｕｒｃｅ

図４ｂに示すように、Ｃｈｏｒｅｇｒａｐｈｅでは、いくつかの資源の選択が引き受けられ、これによりｗａｉｔＲｅｓｏｕｒｃｅｓ方法（資源のリスト、オーナ、コールバック、タイムアウト）の呼出しと当初選択された資源のリストを参照する新しい一意的資源の生成とにつながる。

さらに、資源のリストはいくつかの不必要なタイムアウトを回避するように順序付けられると有利である。資源Ａがオーディオ信号処理（Ａｕｄｉｏ−ＴＴＳ）であり資源Ｂが左腕のピッチング運動（Ａｒｍ−Ｌｅｆｔ ａｒｍ−ＳｈｏｕｌｄｅｒＰｉｔｃｈ）である図４ｂに示す例では、
オーナ１（スレッド１）はＡ＋Ｂを要求する。
オーナ１はＡを獲得し、Ｂを待つ。
オーナ２（スレッド２）はＢ＋Ａを要求する。
オーナ２はＢを獲得し、Ａを待つ。
資源のソーティング無しでは、いかなる制御もロボットへ送られない。ソーティングにより、
オーナ１（スレッド１）はＡ＋Ｂを要求する。
オーナ１はＡを獲得し、オーナ１はＢを獲得し、こうして指令の実行を可能にする。
オーナ２（スレッド２）はＡ＋Ｂを要求する。
オーナ２は、タイムアウトまで、またはオーナ１による資源Ａ＋Ｂの解放までＡを待つ。

図５ａと図５ｂは、本発明のいくつかの実施形態における、機能流れ図の形式とポップアップグラフィックメニュー形式でクリティカル資源を予約するための機構をそれぞれ表す。

クリティカル行動（例えば電池の充電）のためにいくつかの資源が利用可能でなければならない。この可用性は資源のオブジェクト継承により保証される。親オブジェクトまたは行動は資源を予約することができる。次に、これらの資源は子達に利用可能となり、一方、子達はこれらの資源について争うことになる。

図５ａの機能流れ図に示したように、オーナ１は資源を必ずしも使用しなく、子オブジェクトまたは行動のためにそれらを占有する。資源管理プログラムのアルゴリズムは、すべての子に、すべての子自身がその資源を解放するとその資源を放棄ようにさせる。特にことわらない限り、子との競合を解決することは、子がこれらの資源を解放すれば、親との競合も解決させる。

図５ｂに示すように、Ｃｈｏｒｅｇｒａｐｈｅでは、流れ図型の親ボックス（資源管理プログラムサーバまたはボックス群を含むボックスの階層的オブジェクト）が生成される。

図６ａと図６ｂは、本発明のいくつかの実施形態における、ポップアップグラフィックメニュー形式とボックスに基づくグラフィックプログラミングの形式の資源の予約の継承機構をそれぞれ表す。

これら２つの図により示されるような本発明の実施の場合、親オーナ１は資源Ａ＋Ｂ（Ａ＝ＴＴＳとＢ＝Ａｒｍｓ−ＬｅｆｔＡｒｍ−ＳｈｏｕｌｄｅｒＰｉｔｃｈ）を予約する。

この複合資源は親オーナ１内にカプセル化されたボックス群（行動オーナ２、オーナ３）に利用可能であり、この複合資源を要求する最初のものがそれを直ちに使用することができる。

図７ａ、７ｂ、７ｃは、本発明のいくつかの実施形態における、完全なロボット、胴ロボット、利用可能／利用不能資源のリストを表すことにより、存在しない資源の管理の問題事項をそれぞれ示す。

資源管理プログラムは存在しない資源を凍結することによりロボットモデルを管理することができる。したがって、本発明の有利なモードでは、ロボットモデルに関係無く行動を実行することが可能である。企業は実際には、ロボットが変わればそのクライアントの一組の行動を改修することができない。

完全なロボットのすべてのパーツ（特には、図７ａに示すようなそのすべての肢）を有するロボットモデルの場合、資源管理プログラムは、ロボットモデルが完全であることを認識し、資源凍結機構を実施しない。

図７ｂに示すような脚の無い胴ロボットモデルの場合、アプリケーションの初期化後、我々は、図７ｃに表される、胴ロボットモデルから失われた脚に対応する資源が凍結された（すなわち、いかなるオーナにも利用可能でない）資源のリストを取得する。それらはＬＨｉｐＹａｗＰｉｔｃｈ−>ＡＬＦｒａｍｅＭａｎａｇｅｒ＿０ｘ９４２５ａｆ８＿ｒｏｏｔ＿ＲｏｂｏｔＭｏｄｅｌ＿３ｅＳｔｒｏｎｇ０（図７ｃの資源のリストの脚サブセットの第１番目の行）などの行動により予約される。この行動は、実行されることを目的としない限りでは、アーティファクトまたは仮想行動として説明することができる。

資源の完全または部分凍結の同じ機構は、ロボットのいくつかのパーツの故障を管理するまたはそれらを防止するために適用することができる。特に頭のモータが熱くなったと仮定すると、ｈｏｔＥｎｇｉｎｅ行動は、モータが冷却するまで、送られるエネルギーを削減することによりモータを占有することになる。同様に、腕が壊れれば、他の行動が壊れたモータを使用しないようにｂｒｏｋｅｎＡｒｍ行動が壊れたモータを占有することになる。

存在しないまたは不足資源の管理のこの概念の拡張により、行動については必須／非必須資源を定義することが可能である。行動に関し必須であると宣言された資源の可用性は、この行動の実行には極めて重要である。一方、この行動は、非必須であると宣言された資源の非可用性にもかかわらず実行することできるようになる。例えば、行動が、音声メッセージ「こんにちは」（資源Ａ＝オーディオ）と右腕（資源Ｂ＝右腕）と２歩前に（資源Ｃ＝左脚；資源Ｄ＝右脚）の身振りとの組合せを通常は含む挨拶であれば、そして資源ＡとＢが必須と宣言され資源ＣとＤが非必須と宣言されれば、挨拶行動は、資源ＣとＤが利用可能でなくても、例えばロボットが歩行中であるので、実行できることになる。

必須／非必須資源の概念が使用されれば、いくつかの資源が非必須と定義され、存在しないまたは不足であるいくつかの資源の行動は、実行できるようになるが、同じ資源が必須と宣言された行動は、実行できなくなる。行動が必須資源と非必須資源の両方を呼び出せば、行動は、可用性またはそうでなければ非必須資源の関数として、異なるやり方で実行することになる。

しかし、同じ機能を取得して実施するためには、すべての資源を必須として定義し、行動をサブ行動に分割することもまた可能である。デフォルト設定では、サブ行動は、資源が利用不能であれば実行しない。また、デフォルト設定では、グローバル（親）行動は常に実行することになる。しかし、上に説明したように、親行動のレベルとサブ行動（すなわち子行動）のレベルにおいてデフォルト選択を修正することが可能である。

図８ａ〜ｅは、本発明のいくつかの実施形態における、機能流れ図形式（図８ａ）で、競合の様々な終了オプションに対応するポップアップグラフィックメニューの形式（図８ｅ〜ｂ）で、競合を解決するためのいくつかの方式をそれぞれ示す。

図８ａに示すように、マルチエージェント／分散型アプローチ手法が、実時間との相性が悪い複雑なアルゴリズムを回避できるようにする。オブジェクトまたは行動自体は局所的やり方で競合を解決する。オブジェクトまたは行動自体は、資源を要求する他の行動または行動群により資源の要求を拒否する（図８ｂに示す場合）か、または、オブジェクトまたは行動自体は、資源を要求する別の行動によりそれらを使用することができるように、直ちに資源を解放する（図８ｃに示す場合）。または、オブジェクトまたは行動自体は、上記資源を解放する前に安定性の位置を採用できるようにする行動部分を予め実行する（図８ｄに示す場合；例えば、動作が進行中であるときは、オブジェクトまたは行動自体は安定性の次の位置までにこの動きを終了する）。または、資源を所有する行動自体は休止し、要求された資源を解放し、休止は、資源を獲得する他の行動が資源を解放するまで続く（図８ｅに示す場合）。資源が直ちに解放されないすべての場合、要求者行動は、その持続時間を予め定義することができるタイムアウトまで資源を待つスタンバイ位置を採る。すべての場合において、デッドロックが回避される。

通知はコールバックシステムにより行われる。Ｃ＋＋またはｐｙｔｈｏｎでは、オーナが資源を保有すれば、オーナはコールバックで要求について通知される。Ｃｈｏｒｅｇｒａｐｈｅでは、行動は、このコールバック手順（ユーザはその存在について知る必要はない）において解決策を提案することによりユーザに支援を与えることによりコールバック手順において要求について通知される。
＊通知は、資源を保有した行動の停止を引き起こす。
＊通知は何もしなく、資源を保有した行動はそれを維持する。
＊通知は資源を保有した行動を休止させる。
＊通知は、ユーザが望むものを行うユーザの機能を呼び出す（例えば、資源を解放する前に安定した位置を採る）。

より正確には、Ｃｈｏｒｅｇｒａｐｈｅでは、以下のオプションがユーザによりプログラム可能である。
−ロック：資源が別の行動により要求されればそれらを解放することなく獲得する（図８ｂ）。
−要求に応じて停止する：資源を獲得し、その資源が要求されればそれらを解放する（図８ｃ）。
−要求に応じたコールバック：資源競合の場合は任意のユーザコードを行えるようにする。例えば、ダンスの場合、ダンスを停止して資源を解放する前にロボットを安定した位置に置く。
−要求に応じて休止する：資源競合の場合は行動を休止できるようにし、資源が再び自由になれば、行動が休止した場所で行動を再開できるようにする。

デフォルト設定では、行動は資源を維持する。したがって、資源を待つものは行動の終了を待つことになる。

図９は、本発明のいくつかの実施形態における、ポップアップグラフィックメニュー形式の状態資源の利用を示す。

この図は、状態資源の異名をもつ特定タイプの資源の本発明のいくつかの実施形態における使用を示す。

モータ、オーディオ、映像の使用の競合を回避することは、ヒューマノイドロボットを特には故障または破損となり得る転倒の危険性に対して保護するためには不十分である。本出願人により申請された仏国特許出願第１０５６７９８号明細書により開示された転倒管理方法などの下位レベルの保護メカニズムが存在する。しかし、転倒を防止することができると有利である。例えば、ロボットの歩行中にモータを切ることはロボットを転倒させる。このタイプの状況を防止するためには、本発明によると、その可用性（状態資源の活性状態により定義される）がいくつかの行動の実行に必要である状態資源を定義することが可能である。状態資源は共有される（いくつかのオブジェクトまたは行動は状態資源を占有することができる）。資源の単一状態（活性状態）が利用可能である。状態が利用可能でなければ、資源は先に説明された同じ機構に応答する（資源を占有するもののタイムアウトと通知まで、資源を待つスタンバイ）。図９に示す場合、状態資源は「座る」である、すなわち、ロボットは、いくつかの行動（特にすべてのモータを切る）が実行されるように、「座る」（または着座）位置でなければならない。この資源が利用可能でない限り、「すべてのモータを切る」行動は実行され得ない（この行動に固定されたタイムアウト時に非活性化される）。

Ｃｈｏｒｅｇｒａｐｈｅでは、したがって、状態資源を選択することが可能である。図９の例を、以下の他の状態へ一般化することが可能である。主電源に接続された／接続されないカメラ１／カメラ２（ロボットは、その使用がいくつかの位置においてだけ関連する異なる視野を有するいくつかのカメラを備えることができる）（いくつかの機能はロボットの自律資源と相容れないエネルギーの使用を必要とする）等。

図１０は、本発明のいくつかの実施形態における、共有累積資源の利用の機能流れ図を表す。

この図は、累積資源の異名をもつ特定タイプの資源の本発明の実施形態における使用を示す。

このタイプの資源は、特にロボットのＣＰＵの管理を最適化するための用途を見出す。様々なユーザはすべての行動を起動することができなく、ネットワーク（累積資源）のＣＰＵ（累積資源）のロボットの位置の資源（状態資源）（モータなどの単一資源）の可用性の関数としてそうすることができる。

各行動は、占有するＣＰＵの共有を宣言する。このＣＰＵは状態資源タイプの資源のような共有資源である。しかし、その使用は１００％に限られる。図１０に示す場合では、オーナ１は累積資源Ａの１０％を使用することを宣言し、オーナ２は同じ累積資源Ａの９０％を使用することを宣言する。オーナ３はそのタイムアウトまで累積資源Ａの可用性を待つ。オーナ１とオーナ２はオーナ３の要求について通知され、上に示されたオプションのうちの１つにより要求に応答することができる。

本発明は、図面に表され、明細書内で独立に説明された様々な例示的な実施形態を組み合わせることにより実施することができる。したがって、いくつかの現実的または仮想的行動またはサブ行動を定義することができ、必須資源または非必須資源である可能性がある単一資源、状態資源、累積資源を組合せて呼び出すことができる。

本発明の実施形態は単一ロボットの場合において説明された。しかし、互いに通信するいくつかのロボットが資源を共有するようにされる場合に用途を一般化することが可能である。したがって、
−我々が１台のロボットの資源を使用すれば、システムの任意のロボット（クライアント）は資源を獲得するために他のロボット（サーバ）の資源管理プログラムに問い合わせることができる。
−ロボットはまた、仮想資源例えばボールを使用することができる。この場合、単一サーバロボットはボール資源を参照しなければならない。次に、他のロボット（クライアント）は、サーバロボットからこの資源を獲得することができる。

第２のケースの具体的例が以下に示される。
−ロボット１はボールを獲得したい（サーバロボットに要求する）。
−ロボット１は、別のロボットがボール資源を保有するので、ボールを獲得することができない（タイムアウト）。
−したがって、このように、同じチームの２台のロボットは同じボールについて言い争おうとしない。

上に述べた例は本発明の実施形態の例示として与えられた。これは決して本発明の分野を限定するものではなく、本発明の分野は以下の特許請求範囲により規定される。

Claims (18)

1. 複数の行動（１３０，１３１０，１３２０）の実行に割り当てることができる複数の資源（１４０，１４１０，１４２０）を管理するためのサブモジュール（１２１０）を含む搭載管理モジュール（１２０）の制御下で前記複数の行動（１３０，１３１０，１３２０）を実行することができるヒューマノイドロボットであって、
   前記複数の行動と前記複数の資源がそれぞれ階層的サブセットに組織化され、
   前記資源を管理するための前記サブモジュールは、複数の行動の少なくとも１つのサブセットに属する少なくとも１つの行動の実行のための複数の資源の少なくとも１つのサブセットに属する少なくとも１つの資源を予約するようにプログラムされることができ、
   前記予約が前記行動のサブセットにより継承されるおよび／または前記資源のサブセットに適用されるようにプログラムされることができる、ことを特徴とするヒューマノイドロボット。
2. 前記複数の資源を管理するための前記サブモジュールは、第１の行動を実行中に、以下の行為、すなわち、
   前記資源を前記第２の行動に利用可能にすることに対する拒絶、
   前記第２の行動に対し前記資源を直ちに利用可能にすること、
   前記第２の行動に対し前記資源を利用可能にすることに続く少なくとも１つの追加の行為の実行、
   前記第２の行動に対し前記資源を利用可能にすることに続く現在実行中の第１の行動の休止の、少なくとも１つを有する第２の行動による資源要求に応答するようにプログラムされる、ことを特徴とする請求項１に記載のヒューマノイドロボット。
3. 前記複数の資源を管理するための前記サブモジュールは、前記第２の行動により要求された前記資源を利用可能にすることに対する前記拒絶の行為が実行されると、前記第２の行動が再び、同様に所定の終了期限の終了まで所定の頻度に従って利用可能にする要求を実行する、ことを特徴とする請求項２に記載のヒューマノイドロボット。
4. 前記複数の資源を管理するため前記サブモジュールは、少なくとも２つの行動が、同一の資源を利用可能にする要求を実行すると、前記少なくとも２つの行動の第１の行動は後者が解放されると前記同じ資源の予約の優先度を有するようにプログラムされる、ことを特徴とする請求項１乃至３のいずれか一項に記載のヒューマノイドロボット。
5. 前記複数の資源を管理するため前記サブモジュールは、少なくとも１つの行動が、少なくとも２つの資源を利用可能にする要求を実行すると、前記少なくとも２つの資源は単一資源として処理される新しい資源にグループ化され、前記グループ化は、同一の資源要求を実行するすべての行動に対して一意的やり方で順序付けられるようにプログラムされる、ことを特徴とする請求項１乃至４のいずれか一項に記載のヒューマノイドロボット。
6. 前記複数の資源を管理するため前記サブモジュールは、親行動がそれを使用することなく少なくとも１つの資源を予約すると、前記少なくとも１つの資源は前記親行動の子行動により使用されることができるようにプログラムされる、ことを特徴とする請求項１乃至５のいずれか一項に記載のヒューマノイドロボット。
7. 前記複数の資源を管理するため前記サブモジュールは、第１の子行動が前記親行動により予約された資源を使用すると、同じ親の第２の子行動は、前記資源を使用することができるように前記第１の子行動により前記資源を利用可能にする要求を行わなければならないように、プログラムされる、ことを特徴とする請求項６に記載のヒューマノイドロボット。
8. 前記複数の資源を管理するため前記サブモジュールは、親行動がその予約された資源を解放すると、前記資源は前記親の任意の子行動により解放されなければならないようにプログラムされる、ことを特徴とする請求項６乃至７のいずれか一項に記載のヒューマノイドロボット。
9. 前記複数の資源を管理するための前記サブモジュールは、資源のサブセットが可用性を下げたとき、可用性の前記低下の関数として定義された仮想行動のための前記資源の予約を実行するようにプログラムされる、ことを特徴とする請求項１乃至８のいずれか一項に記載のヒューマノイドロボット。
10. 前記複数の資源を管理するための前記サブモジュールは、可用性の前記低下の状態の進展の関数として前記予約を解放するようにプログラムされる、ことを特徴とする請求項９に記載のヒューマノイドロボット。
11. 前記複数の資源は、少なくとも１つの行動の実行に必要な予約が行われるように所定の状態でなければならない少なくとも１つの状態変数を含む、ことを特徴とする請求項１乃至１０のいずれか一項に記載のヒューマノイドロボット。
12. 前記複数の資源は少なくとも１つの累積資源を含み、後者の使用率は、前記少なくとも１つの資源を使用するようにプログラムされた行動に割り当てられる、ことを特徴とする請求項１乃至１１のいずれか一項に記載のヒューマノイドロボット。
13. 前記複数の資源は少なくとも１つの必須資源と１つの非必須資源を含み、任意の行動は、前記必須資源が利用可能でなければ実行できない少なくとも１つの必須資源であって、前記少なくとも１つの非必須資源を呼び出さなければならなければたとえ後者が利用可能でなくても実行することができる少なくとも１つの必須資源を呼び出さなければならない、ことを特徴とする請求項１乃至１２のいずれか一項に記載のヒューマノイドロボット。
14. 搭載管理モジュール（１２０）の制御下で複数の行動（１３０，１３１０，１３２０）を実行することができるヒューマノイドロボットの資源を管理するための方法であって、前記行動の実行に割り当てることができる複数の資源（１４０，１４１０，１４２０）を予約する工程を含む、方法において、
    前記複数の行動と前記複数の資源がそれぞれ階層的サブセットに組織化され、
    前記予約工程は、行動の少なくとも１つのサブセットに属する少なくとも１つの行動の実行に資源の少なくとも１つのサブセットに属する少なくとも１つの資源を割り当て、
    前記予約が前記行動のサブセットにより継承されるおよび／または前記資源のサブセットに適用されるようにプログラムされることができる、ことを特徴とする方法。
15. コンピュータプログラムがコンピュータ上で実行されると請求項１４に記載の方法の実行を可能にするプログラムコード命令を含むコンピュータプログラムであって、
    前記プログラムは、搭載管理サブルーチン（１２０）の制御下で複数の行動（１３０，１３１０，１３２０を実行することができるヒューマノイドロボットの資源の管理を可能にするように適合化され、
    前記サブルーチンは、前記行動の実行に割り当てることができる複数の資源（１４０，１４１０，１４２０）の予約のための機能を実行することができるモジュール（１２１０）を含み、前記コンピュータプログラムは、
    前記複数の行動と前記複数の資源がそれぞれ階層的サブセットに組織化され、
    前記予約機能が、行動の少なくとも１つのサブセットに属する少なくとも１つの行動の実行に資源の少なくとも１つのサブセットに属する少なくとも１つの資源を割り当て、
    前記予約が前記行動のサブセットにより継承されるおよび／または前記資源のサブセットに適用されるようにプログラムされることができる、ことを特徴とするコンピュータプログラム。
16. 行動と資源の前記サブセットはオブジェクトのクラスとして定義される、ことを特徴とする請求項１５に記載のコンピュータプログラム。
17. 搭載管理サブルーティン（１２０）の制御下で複数の行動（１３０，１３１０，１３２０）を実行することができるヒューマノイドロボットの資源を管理するためのモジュール（１６１０）を開発するための方法であって、
    前記サブルーチンは、前記行動の実行に割り当てることができる複数の資源（１４０，１４１０，１４２０）の予約のための機能を実行することができ、前記方法は、
    前記複数の行動と前記複数の資源がそれぞれ階層的サブセットに組織化され、
    前記予約機能が、行動の少なくとも１つのサブセットに属する少なくとも１つの行動の実行に資源の少なくとも１つのサブセットに属する少なくとも１つの資源を割り当て、
    前記予約が前記行動のサブセットにより継承されるおよび／または前記資源のサブセットに適用されるようにプログラムされることができる、ことを特徴とする方法。
18. コンピュータプログラムがコンピュータ上で実行されると請求項１７に記載の方法の実行を可能にするプログラムコード命令を含むコンピュータプログラムであって、
    前記プログラムは、複数の行動（１３０、１３１０、１３２０）を実行することができるヒューマノイドロボットの資源を管理するための遠隔モジュール（１６１０）との相互作用により、前記ロボット上の搭載管理サブルーチン（１２０）のパラメタータ化を可能にすることように適合化され、
    前記サブルーチンは、前記行動の実行に割り当てることができる複数の資源（１４０，１４１０，１４２０）の予約のための機能を実行することができるモジュール（１２１０）を含み、
    前記プログラムは、前記複数の行動と前記複数の資源がそれぞれ階層的サブセットに組織化され、
    前記予約機能が、行動の少なくとも１つのサブセットに属する少なくとも１つの行動の実行に資源の少なくとも１つのサブセットに属する少なくとも１つの資源を割り当て、前記予約が前記行動のサブセットにより継承されるおよび／または前記資源のサブセットに適用されるようにプログラムされることができる、を特徴とするプログラム。

Images