Warning: file_put_contents(temporary://fileqHAk85): failed to open stream: "DrupalTemporaryStreamWrapper::stream_open" call failed in file_unmanaged_save_data() (line 2024 of includes/file.inc).
ファイルを作成できませんでした。
Warning: file_put_contents(temporary://fileYLB8E5): failed to open stream: "DrupalTemporaryStreamWrapper::stream_open" call failed in file_unmanaged_save_data() (line 2024 of includes/file.inc).
一般的な設定
config.version
コンフィギュレーションファイルのバージョン。
このパラメータは内部的にセットされるコンフィギュレーションのバージョン。 通常、OpenRTM-aistと同じバージョンである。rtc.confでセットする必要はなく、読み取り専用のパラメータ。 このバージョンを読み取ることで、rtc.confとOpenRTM-aistのバージョンを知ることができる。
openrtm.name
このパラメーターは、内部で設定されているバージョンを含むOpenRTM-aistの名前である。 読み取り専用のパラメータでありrtc.confで設定する必要はない。 このパラメーターを読み取ることにより、OpenRTM-aistの名前とバージョンがわかる。
openrtm.version
OpenRTM-aist のバージョン。ネームサービスに関する設定
naming.enable
このオプションはネーミングサービスに関する機能の有効・無効を切り替える。 YESを指定した場合、ネームサービスへRTCの参照を登録する。NOの場合、ネー ムサービスへのRTCの参照の登録は行われない。
naming.type
このオプションはネームサービスのタイプを指定する。現在のところはcorbaの みをサポートしている。naming.formats
RTCをネームサーバに登録する際のフォーマットを指定する。以下の %で始 まる指定子を利用することができる。名前階層のデリミタは / であり、名 前と種類(kind)のデリミタは . である。
naming.update.enable
RTCのネームサーバへの登録は通常インスタンス生成時に行われる。したがって、 RTCの生成以降に起動されたネームサーバには、当該RTCの名前と参照は登録さ れない。このオプションを指定することで、定期的にネームサーバを確認し、 ネームサーバの起動が確認された場合、改めて名前と参照を登録する。
naming.update.interval
naming.update.enable が YES の場合、ネームサーバの確認および再登録を行 う周期を指定する。
naming.update.rebind
このオプションに YES を指定すると、すでに名前と参照が登録されているネー ムサーバ上で名前が削除されるなどした場合にもの、再度登録を行う。
ロガー関係の設定
logger.enable
ロガーの有効化・無効化の指定。
logger.file_name
ログファイル名の指定。カンマ区切りで複数のファイルへ出力することもでき る。プロセスIDを置き換える指定子 %p が利用可能。また、ファイル名 stdout とするとログを標準出力する。
logger.date_format
ログに記載する日付・時刻のフォーマット指定。以下の strftime(3) に似た フォーマット指定子を利用可能。時刻を指定しない場合、No または Disable を指定する。
Note: some versions of Microsoft Visual C++ may use values that range from 0-11.
logger.log_level
以下のログレベルを指定可能。
各ログレベルを指定した際に実際にログに記録されるログメッセージのレベ ルは以下の通り。
TRACE, VERBOSE, PARANOID の各ログレベルは通常巨大なログファイルを生成します。PARANOIDを指定すると、ログフォーマットが崩れる場合があります。
logger.clock_type
logger.clock_type オプションはログメッセージのタイムスタンプに使用するクロックのタイプを指定します。 現在以下の3種類のクロップタイプが使用可能です
論理時間クロック (logical time clock) を利用するには、プログラム中のどこかに以下のように指定してください。
logger.escape_sequence_enable
このオプションはログ出力に色を付けるかどうかを指定する。logger.file_name: stdout と指定した場合、端末がエスケープシーケンスをサポートしていれば、ログ出力がカラーで表示される。ファイルへの出力に色を付けることはおすすめしない。
CORBAに関する設定
corba.args
CORBAに与える引数を指定する。CORBA は実装毎に異なるコマンドラインオプショ ンを持つ。通常コマンドライン引数は、CORBA の API である ORB_init() 関数 に与えられるが、このオプションは指定された文字列をこの ORB_init() 関数 に渡す。
指定例1
画像データなどをデータポートで送る際、1回に送信するデータサイズ約2MBを超える場合には注意が必要。 omniORBでは、giop(General Inter-ORB Protocol)で扱えるサイズはデフォルトで"2097152B(2MB)"であり このサイズを超えるデータを送ろうとすると、giopの制限のため正しいデータを送ることができない。 corba.args オプションを利用して、最大サイズを変更することが可能である。この指定は、OutPort、InPort両方にて指定する必要がある。
なお、corba.args に指定する以外に、環境変数を以下のように指定することでこの制限を緩和することができる。
corba.endpoint [非推奨]
このプションは corba.endpoints に置き換えられた。非推奨。
corba.endpoints
CORBAにおいては、リモートのオブジェクトのIORと呼ばれる参照によりアクセ スするが、IORには当該オブジェクトが動作するノードのアドレスとポート番号 が通常1セットのみ記述されている。OpenRTMが動作しているノードに2つ以上の ネットワークインターフェースが存在する場合、IORに含まれるノードのアドレ スとして意図しないアドレスが割り振られる場合がある。
これを解消するために、本オプションでCORBAで利用するネットワークのアドレ スを指定することができる。ホストアドレス:ポート番号 として指定するが、ポート番号は省略できる。
ORBの実装によっては、IORに複数のアドレスを含めることができる。ただし、 Java標準のCORBAであるJavaIDLにおいては、複数のアドレスを指定したIOR経由 で当該オブジェクトにアクセスする場合、動作が遅くなるなど問題も報告され ているので注意が必要である。
アドレス:ポート の対を ,(カンマ)で区切り複数指定することができ る。特別な文字列として all を指定することで、ノードのすべてのアドレ スをIORに含めることもできる。
corba.endpoints:
corba.endpoints_ipv4: [readonly]
このパラメータは読み取り専用で、現在のプロセスが使用しているIPv4のエンドポイントがセットされます。 このパラメータを読むことで、現在使用しているエンドポイントを知ることができます。
corba.endpoints_ipv6: [readonly]
このパラメータは読み取り専用で、現在のプロセスが使用しているIPv6のエンドポイントがセットされます。 このパラメータを読むことで、現在使用しているエンドポイントを知ることができます。
corba.endpoint_property
このプションは、利用可能なエンドポイントのうち何番目のアドレスをIPv4, IpV6のいずれかのアドレスとして利用するかどうかについて指定する。
corba.nameservers
このプションはRTC等を登録するネームサーバを指定する。カンマ区切りで複数のネームサーバを指定することができる。指定したアドレスおよびポート番号にネームサーバがない場合でも特にエラーにはならず、存在するネームサーバにのみRTCの名前を登録する。 ポート番号が省略された場合はデフォルトのポート番号 2809 が使われます。
corba.nameservice.replace_endpoint
ノードに複数のNICが存在する場合、ネームサーバ上に登録されるRTCのIORに含 まれるアドレスが、適切でない場合が存在する。例えば、あるノードが 192.168.0.10と192.168.1.10という2つのアドレスを持ち、192.168.0.1 および 192.168.1.1 に存在する2つのネームサーバ上に登録される場合、仮に 192.168.0.10 が当該ノードでデフォルトで利用されるネットワークインター フェースだとすると、上記2つのネームサーバネームサーバに登録されるIORには、 192.168.0.10 のみが含まれる。このとき、192.168.1.0 のネットワークではネームサーバ上のIORは到達不可能なアドレスが記載された無意味なものとなる。
このオプションを指定すると、上記のケースのような場合、192.168.1.1 のネー ムサーバに登録されるIORのアドレスを 192.168.1.10 に置き換える。
ただし、このオプション指定することによって、192.168.1.0 ネットワーク上 の他のノードからは、当該RTCのプロファイル等を利用することはできるが、ポー トの接続等は行うことはできない。
corba.alternate_iiop_addresses
このオプションは、代替IIOPアドレスをIORプロファイルに追加します。 IORにはサーバント(CORBAオブジェクトのサーバ)の追加のエンドポイント を含めることができます。これは、"corba.endpoints"オプションとほぼ 同等ですが、実際にエンドポイントを作成しない点が異なります。 ("corba.endpoints" オプションでは実際のエンドポイントを作ろうとし、 できなければエラーが返されます。) このオプションは単に代替のIIOPエ ンドポイントアドレス情報をIORに追加します。
このオプションは、RTCをNATやルータの内部に配置する場合に使用します。 一般的には、プライベートネットワーク内のRTCはグローバルネットワー ク上のRTCを接続することはできません。しかしながら、NATやルータのポー トフォワーディングが適切に設定されていればグローバル側のRTCはプライ ベートネットワークのRTCに接続することが可能です。
設定は以下のように行います。
なお、RTSystemEditorでは、プライベート側のRTCへのアクセスが極端に 遅くなる場合があります。これはJavaのIOR追加プロファイル機能の実装 が十分でないため、プライベート側に到達するのに時間がかかるためと考 えられます。rtshellなどを利用すると、接続にかかる時間を減らすこと ができます。また、RTSystemEditorやrtshellでの接続に時間がかかった 場合でも、一旦接続したポート間の通信速度は通常とほとんど変わりませ ん。
manager に関する設定
manger.name
managerの名前。マネージャがネームサーバで登録される際には、ここで設定した名前で登録される。 この "manager.name" は、ストリング化されたCORBAオブジェクト名でマスター/スレーブマネージャーをグループ化するために使用されます。 "manager.name" が "manager" に設定され、マネージャーがマスターである場合、オブジェクト参照は次のように配置されます。
また、他のスレーブマネージャは以下のストリング化されたIORを持ちます。
manager.instance_name
マネージャのインスタンス名。
この "manager.instance_name" は、ネームサービス登録時のマネージャーの名前に使用されます。 通常、マスターマネージャーの参照は、"manager|mgr" という名前でネームサーバーに登録されます。 このオプションが "foobar" に設定されている場合、登録されたマースターマネージャー名は "foobar|mgr" になります。manager_naming_formats
マネージャをネームサーバに登録する際のフォーマットを指定する。以下の %で始まる指定子を利用することができる。
manager.is_master
当該プロセスをマスターマネージャにするかどうか?コマンドラインオプショ ン -d を指定すると、この値が NO に設定されていてもマスターマネージャ になる。
manager.corba_servant
マネージャのCORBAサーバントを起動するかどうかの設定。YES を設定すると、 マネージャのCORBAサーバントが起動するため、リモートからマネージャの操作 が可能になる。NO の場合には、CORBAサーバントが起動しないため、マネージャ のCORBA経由での操作はできなくなる。
corba.master_manager
マスターマネージャのアドレスとポート番号。マスターマネージャは、 corbaloc 形式のURL指定でアクセス可能であるが、その際に使用するポート番 号を指定する。また、スレーブマネージャは、ここで指定されたマスターマネー ジャを自身のマスターマネージャとして解釈、起動時にマスターマネージャに アクセスしネゴシエーションを行う。
manager.update_master_manager.enable
スレーブマネージャへのマスターマネージャの登録の自動更新
このオプションは、スレーブマネージャで有効です。 スレーブマネージャーは、自分自身をマスターマネージャーに登録する必要があります。 このオプションを "YES"に設定すると、スレーブマネージャーは定期的にマスターマネージャーに登録します。 「NO」を設定すると、スレーブマネージャは、起動時に一度だけマスタマネージャに登録されます。
manager.update_master_manager.interval
スレーブマネージャのマスターマネージャへの登録更新周期
このオプションは、corba.update_master_manager.enableに関連します。 「corba.update_master_manager.enable」オプションがYESに設定されている場合、更新間隔はこのオプションによって設定されます。 デフォルトの間隔は10秒です。manager.components.naming_policy
このオプションは、RTCの命名(番号付け)ポリシーを指定します。 RTCインスタンスが作成されると、コンポーネントタイプ名(type_name)に次のように増分番号が付けられた名前が割り当てられます。
デフォルトでは、同じプロセスの同じタイプのコンポーネントには0から順番に番号が付けられるため、異なるプロセスまたは異なるノード(コンピューター)で作成されたRTCは同じ名前を持つ場合があります。これらのRTCがネームサーバー(ns)に登録されると、同じパスと同じ名前のRTCが互いのオブジェクト参照を上書きし、目的のRTCにアクセスできなくなります。したがって、2つのポリシーが提供されます。各ノードに一意の番号を割り当てる「node_unique」とネームサーバーに一意の番号を割り当てる「ns_unique」です。
デフォルトでは、次の3つのオプションを指定できます。
ポリシーはユーザーが拡張できます。
manager.components.precreate
事前のコンポーネント作成
このオプションは、マネージャーのイベントループを開始する前に事前に作成するコンポーネントの名前(モジュール名)を指定します。 コンポーネントのファクトリーは、「manager.module.preload」オプションで登録するか、マネージャーに静的にリンクする必要があります。
manager.components.preconnect
事前の接続生成。このオプションは、マネージャーイベントループを開始する前に作成するコネクタを指定します。 ターゲットコンポーネントとポートは、"manager.components.precreate" オプションを使用して事前に作成されている必要があります。 ポートは、"<comp0>.<Port0>?port=<comp1>.<port1>&<option_key>=<option_value>&..." の形式で指定されます。 dataflow_type または interface_type が指定されていない場合、"dataflow_type = push", "interface_type = corba_cdr" が自動的に指定されます。
manager.components.preactivation
以前のコンポーネントのアクティブ化。このオプションは、マネージャーのイベントループを開始する前に、事前にアクティブにするコンポーネントの名前(モジュール名)を指定します。 ターゲットコンポーネントは、あらかじめ manager.components.precreate オプションで作成しておく必要があります。
manager.cpu_affinity
このオプションは、マネージャのプロセスを特定のCPUにバインドする。 オプション引数は、カンマで区切られた1つ以上のCPU IDでなければならない。 CPU IDは0から始まり、最大値はCPUコア数-1となる。 もし不正なCPU IDが指定された場合、このプロセスはすべてのCPUを利用するよう設定される。
マネージャのライフサイクルオプション
manager.shutdown_on_nortcs:
プロセス上にRTCが一つもなくなった場合、すなわち同一プロセス上のRTCの最 後の1つが終了した場合に、マネージャをシャットダウンし当該プロセスを終了 させるかどうかを指定する。YES の場合には、RTCが一つもなくなった時点でプ ロセスが終了する。NOの場合は、RTCが一つもない状態でもマネージャ、プロセ スともに動き続ける。
manager.shutdown_auto
プロセス内のRTCの有無を一定時間ごとに調べ、RTCがない場合には、マネージャ およびプロセスをシャットダウンするかどうかを設定する。YESの場合、RTCが 一つもなければ、マネージャおよびプロセスは自動的にシャットダウンされる。 NOの場合、RTCが一つもなくともマネージャおよびプロセスが動作し続ける。
manager.shutdown_on_nortcs との違いは、シャットダウンのトリガが、 manager.shutdown_on_nortcs ではRTCの削除であるのに対して、 manager.shutdown_auto は時間となっている点である。manager.auto_shutdown_duration
プロセス内のRTCの有無調べる周期。単位は秒。上記の manager.shutdown_auto が YESに設定されている場合、このオプションで設定された周期でRTCの有無を確認 しにいく。
manager.termination_waittime
マネージャ終了ウェイト時間指定。 このオプションは、マネージャーへの終了要求から実際の終了スレッドが実行を開始するまでの時間を指定します。 単位は秒です。 通常、このオプションを指定または変更する必要はありません。 ただし、CORBAの終了処理が正常に終了する前に別の終了処理を実行して例外が発生した場合は、この時間を調整することで問題が解決する場合があります。
モジュール管理に関するオプション
manager.modules.load_path
マネージャはこのオプションで指定されたサーチパスリストからモジュールを 探索する。パスはカンマ区切りで列挙する。パスのデリミタは、UNIXでは /、Windows \\である。
manager.modules.preload:
マネージャは起動時に予めローダブルモジュールをロードすることができる。 このオプションで指定されたローダブルモジュール を、manager.modules.load_path で指定されたサーチパスから探し出す。 もし、manager.modules.abs_path_allowed で YES が指定されていれば、 ローダブルモジュールを絶対パスで指定することもできる。
manager.modules.abs_path_allowed
モジュールの絶対パス指定許可フラグ。もしこのオプションがYESの場合、モジュールの接待パス指定が許可される。
manager.modules.search_auto
モジュールの自動検索機能を有効にする。 このオプションは、RTCロード可能モジュールを自動的に検索するかどうかを指定します。 このオプションが "YES" に設定されている場合、RTCインスタンス化がマネージャーに要求されると、ターゲットRTCロード可能モジュール(DLLなど)が自動的に検索され、モジュール検索パスからロードされて、コンポーネントがインスタンス化されます。 NOの場合、ターゲットRTCのロード可能モジュールを事前にロードする必要があります。
manager.preload.modules: none
CORBA初期化前にロードするモジュールリスト
このオプションは、CORBAの初期化前にロードするモジュールを指定します。 一部の機能を実装するロード可能なモジュールは、CORBAの初期化前にロードする必要があり、そのようなモジュールはこのオプションで指定されます。 モジュールの指定方法はmanager.modules.preloadと同じです。
マネージャの言語サポートオプション
manager.supported_languages
マスターマネージャは、リモートアプリケーションなどからの要求に応じて、 スレーブマネージャおよびRTCを起動する。スレーブマネージャは、C++言語版 だけでなく、Java版、Python版などの可能性もある。
manager.modules.<lang>.suffixes
言語ごとのRTCモジュールの拡張子。 このオプションは、ロード可能なモジュールRTCの拡張を指定します。
<lang>の部分はmanager.supported_languagesで指定する必要があります。 "."(ドット)は不要です。 C ++、Python / Python3、Java言語にはそれぞれ適切なデフォルトの拡張子が指定されているため、通常は設定は必要ありません。
manager.modules.<lang>.manager_cmd
言語ごとのマネージャプログラム名。 このオプションは、各言語の実行可能マネージャーの名前を指定します。 マスターマネージャーがRTCのインスタンス化を要求されると、スレーブマネージャーが実行され、RTCがスレーブマネージャープロセスでインスタンス化されます。 C++版のRTCはC++版のマネージャ(rtcd)を使用し、Python版RTCはPython版マネージャ(rtcd_python)を使用します。 コマンド検索パスのデフォルトの実行可能ファイルは、C ++、Python / Python3、およびJava言語に対してそれぞれ指定されます。通常、設定は必要ありません。
manager.modules.<lang>.profile_cmd
言語ごとのプロファイル取得コマンド名。 このオプションは、RTCプロファイルを取得するコマンドであるプロファイル実行可能ファイルの名前を言語ごとに指定します。 既存のロード可能なモジュールからRTCを検索する場合、マスターマネージャーはプロファイルコマンドを実行して、ロード可能なモジュールから各コンポーネントのプロファイルを取得します。 C++版RTCはC++版プロファイルコマンド(rtcprof)を使用し、PythonバージョンRTCはPythonバージョンマネージャ(rtcprof_python)を使用します。 コマンド検索パスは、指定された実行可能ファイルに設定する必要があります。 C++、Python / Python3、およびJava言語にはそれぞれ適切なデフォルトの実行可能ファイルが指定されているため、通常は設定は必要ありません。
manager.modules.<lang>.load_paths
言語ごとのRTCモジュールロードパス。 このオプションは、各言語のロード可能なモジュールRTCのロードパスを指定します。 マスターマネージャーがどこかからRTCを検索する場合、指定されたロードパスが使用されます。
タイマに関する設定
timer.enable
タイマ機能を有効/無効にする。タイマを無効にするとタイマを利用している機 能、例えばネームサーバの定期的確認と再登録等が無効になる。
timer.tick
タイマの精度を指定する。
実行コンテキストオプション
exec_cxt.periodic.type
デフォルトの実行コンテキストのタイプ。 デフォルトでは以下の実行コンテキストが指定可能。
exec_cxt.periodic.rate
デフォルトの実行コンテキストの周期。このオプションはシステム全体のECの周期を指定する。RTCが明示的にECの周期を指定しない場合、この周期が利用される。
exec_cxt.sync_transition
exec_cxt.sync_activation
exec_cxt.sync_deactivation
exec_cxt.sync_reset
RTCはアクティブ化、非アクティブ化、およびリセットにより、状態が遷移します。 一部の実行コンテキストは、メインロジックを異なるスレッドで実行します。 これらのフラグがYESに設定されている場合、アクティブ化、非アクティブ化、およびリセットは同期して実行されます。 つまり、これらのフラグがYESの場合、状態遷移の完了後にはアクティブ化/非アクティブ化/リセット操作の呼び出しから戻っていることが保証されます。
"sync_transition" は、同期遷移フラグを他のすべての同期遷移フラグ (sync_activation / deactivation / resetting) に一括設定します。
exec_cxt.transition_timeout
exec_cxt.activation_timeout
exec_cxt.deactivation_timeout
exec_cxt.reset_timeout
動機遷移時のタイムアウト指定。 動機遷移フラグがYESに設定されているとき、以下のタイムアウトの設定が有効になります。"timeout_transition" オプションが設定された場合、他の activation/deactivation/reset のタイムアウト値が一括で設定されます。
SDO サービスオプション
sdo.service.provider.available_services
このパラメータは現在利用可能なSDOサービス(プロバイダ)のリストが入る。
sdo.service.provider.enabled_services
このオプションは有効にSDOサービス(プロバイダ)を指定する。 特定のサービスをサービス型名で指定するか、全てを有効にする場合は "ALL" を指定する。
sdo.service.provider.providing_services
このオプションは現在インスタンス化され提供されているSDOサービス(プロバイダ)が入る。
sdo.service.consumer.available_services
このパラメータは現在利用可能なSDOサービス(コンシューマ)のリストが入る。
sdo.service.consumer.enabled_services
このオプションは使用するSDOサービス(コンシューマ)を指定する。 特定のサービスをサービス型名で指定するか、全てを有効にする場合は "ALL" を指定する。
ローカルサービスオプション
#============================================================
manager.local_service.modules
ローカルサービスモジュールをロードする。 同一プロセス内のRTCに対してユーザ定義のサービを提供するためにローカルサービスメカニズムが提供されています。 コンポーネントは、ローカルサービスをマネージャから取得したり、使用したりすることができます。 例えば、この仕組を利用すると、複数のRTC間で共通のリソースにアクセスしたりできます。
ローカルサービスモジュールは、しばしばコンポーネントのロードやインスタンス化よりも前に初期化されなければいけません。 そのため、ローカルサービスモジュールはこのオプションで指定して事前にロードと初期化を行う必要があります。
manager.local_service.enabled_services
有効にするローカルサービスを指定する。デフォルトではすべてのローカルサービスがアクティブ化および利用可能に設定されます。このオプションは有効にする特定のローカルサービスを指定します。
ポートの設定
ポートの設定は以下のport.inport.dataport、port.{ポート型}.{ポート名}、{カテゴリ名}.{インスタンス名}.port.inport.{ポート名}.{設定項目}の文字列の後に項目名を指定することで設定できます。 接続時のコネクタプロファイルで同じ設定をしている場合は、コネクタプロファイルの設定で上書きするのでrtc.confの設定は無効になります。
allow_dup_connection
2つのポートの間で複数のコネクタを生成しないようにします。 NO(不許可)にした場合、ポートAとポートBで接続した場合、もう一度connect関数を実行してポートAとポートBを接続しようとしてもPRECONDITION_NOT_METの値を返して接続失敗になります。
fan_in
InPortのコネクタの最大数を指定する。例えば100に設定すると、InPort Aと接続したポートの数が100以上になると、connect関数実行時にPRECONDITION_NOT_METを返して接続失敗になります。
fan_out
OutPortのコネクタの最大数を指定する。例えば100に設定すると、OutPort Aと接続したポートの数が100以上になると、connect関数実行時にPRECONDITION_NOT_METを返して接続失敗になります。
buffer.length
InPort、OutPortのリングバッファのバッファサイズを指定します。OutPortの場合はサブスクリプション型がNew、Periodic型の時に有効です。InPortは常に有効です。
buffer.write.full_policy
InPort、OutPortのリングバッファの上書き時のポリシーを指定します。OutPortの場合はサブスクリプション型がNew、Periodic型の時に有効です。InPortは常に有効です。
buffer.read.empty_policy
InPort、OutPortのリングバッファの読み込み時のポリシーを指定します。OutPortの場合はサブスクリプション型がNew、Periodic型の時に有効です。InPortは常に有効です。