More Related Content Similar to 130329 01 (20) 130329 012. RT とは ?
• RT = Robot Technology cf. IT
– ≠Real-time
– 単体のロボットだけでなく、さまざまなロボット技術に基づく
機能要素をも含む ( センサ、アクチュエータ , 制御スキーム、
アルゴリズム、 etc….)
産総研版 RT ミドルウエア
OpenRTM-aist
+ + + + +
RT-Middleware
• RT-Middleware ( RTM)
– RT 要素のインテグレーションのためのミドルウエア
• RT-Component ( RTC)
– RT-Middleware におけるソフトウエアの基本単位
2
3. 従来のシステムでは…
Joystick
software
Joystick
Robot Arm
Control software
互換性のあるインターフェース同士は接続可能 Robot Arm
3
4. 従来のシステムでは…
Humanoid’s Arm
Control software
Humanoid’s Arm
Joystick
software
Joystick
Robot Arm
Control software
ロボットによって、インターフェースは色々
互換性が無ければつながらない Robot Arm
4
6. ミドルウエア、コンポーネン
ト、 etc…
• ミドルウエア
– OS とアプリケーション層の中間に位置し、特定の用途に対して利便性
、抽象化向上のために種々の機能を提供するソフトウエア
– 例: RDBMS 、 ORB 等。定義は結構曖昧
• 分散オブジェクト(ミドルウエア)
– 分散環境において、リモートのオブジェクトに対して透過的アクセス
を提供する仕組み
– 例: CORBA 、 Java RMI 、 DCOM 等
• コンポーネント
– 再利用可能なソフトウエアの断片(例えばモジュール)であり、内部
の詳細機能にアクセスするための(シンタクス・セマンティクスとも
にきちんと定義された)インターフェースセットをもち、外部に対し
てはそのインターフェースを介してある種の機能を提供するモジュー
ル。
• CBSD ( Component Based Software Development )
– ソフトウエア・システムを構築する際の基本構成要素をコンポーネン
トとして構成するソフトウエア開発手法
6
7. モジュール化のメリット
• 再利用性の向上
– 同じコンポーネントをいろいろなシステムに使いま
わせる
• 選択肢の多様化
– 同じ機能を持つ複数のモジュールを試すことができ
る
• 柔軟性の向上
– モジュール接続構成かえるだけで様々なシステムを
構築できる
• 信頼性の向上
– モジュール単位でテスト可能なため信頼性が向上す
る
• 堅牢性の向上
8. RT コンポーネント化のメリッ
ト
モジュール化のメリットに加えて
• ソフトウエアパターンを提供
– ロボットに特有のソフトウエアパターンを提供する
ことで、体系的なシステム構築が可能
• フレームワークの提供
– フレームワークが提供されているので、コアのロジ
ックに集中できる
• 分散ミドルウエア
– ロボット体内 LAN やネットワークロボットなど、分
散システムを容易に構築可能
9. RT ミドルウエアの目的
モジュール化による問題解決
• 仕様の明確化
コストの問題 技術の問題 ニーズの問題
• 最新技術を容易に利用可能
• 誰でもロボットが作れる 最新の理 多様なユーザ
A 社製移動ベース B 社製アーム C 社製センサ・・・
論・
アルゴリズ
ム
仕様
! !
RT コンポーネント化
! !
モジュール化・再利用 カスタマイズが容易に
システム開発者
ロボットの低コスト 最新技術を利用可能 多様なニーズに対応
化
ロボットシステムインテグレーションによるイノベーション
9
10. RT ミドルウエアと RT コンポーネ
ント
ロジック
・デバイス制御
・制御アルゴリズ RT
ム コンポーネント
RT
・アプリケーショ コンポーネント
フレームワーク
ン
etc…
ロジックを箱(フレームワーク)に入れたもの= RT コンポーネント( RTC )
RTC RTC RTC RTC RTC RTC RTC RTC
RT ミドルウエア
RTC の実行環境( OS のようなもの)= RT ミドルウエア( RTM )
※RTC はネットワーク上に分散可能
10
11. RT コンポーネントの主な機能
アクティビティ・実行コンテ データポー
キスト 複合実行 • ト
データ指向ポート
共通の状態遷移
• 連続的なデータの送受信
センサ RTC • 動的な接続・切断
Inactive Active サーボの例
位置
目標値
制御 RTC 電圧
1
+ Kp
- TI s
Error アクチュエータ RTC
T Ds
エンコーダ 位置 制御器 アクチュエータ
コンポーネント コ
ンポーネント コンポーネント
ライフサイクルの管理・コアロジックの データ指向通信機
実行 能
サービスポー コンフィギュレー
• ト
定義可能なインターフェースを持 ション
つ • パラメータを保持する仕組
• ステレオビジョンの例
内部の詳細な機能にアクセス み 複数のセットを
– パラメータ取得・設定 サービスポート • いくつかのセットを保持可 動作時に
– モード切替 能 切り替えて
ステレオビジョン – etc… • 実行時に動的に変更可能 使用可能
インターフェース 3D デプス 名前
セット名
データ 値
・モード設定関数
・座標系設定関数 画像 ステレオビジョン 名前
データ セット名
・キャリブレーション コンポーネント 値
・ etc… データポート
サービス指向相互作用機能
11
12. RTC の分割と連携
ロボット体内のコンポーネントによる構成例
画像データ ポート
データ・コマンドの流れ
顔位置
問合せ
カメラ 顔認識
コ
ンポーネント コ
ンポーネント
画像データ
人物データ
ステレオビジョン 表情データ
コ
ンポーネント
頭・腕駆動
ジェスチャ コ
ンポーネント
カメラコントロール 軌道データ
カメラ
コ
ンポーネント
音声データ
音声認識 対話 音声合成
コ
ンポーネント コ
ンポーネント コ
ンポーネント
文字データ 文字データ
マイク
コ
ンポーネント
(モジュール)情報の隠蔽と公開のルールが重要
13. RT ミドルウエアによる分散システ
ム ロボット C
ロボット A ロボット B
RTM により、
ネットワーク上に
分散する RTC を
OS ・言語の壁を
越えて接続する RTC RTC RTC RTC RTC RTC RTC
ことができる。 RTM RTM RTM
Solaris FreeBSD ARTLinux
ネットワーク
Linux Windows TRON
RTM RTM RTM
RTC RTC RTC RTC RTC RTC RTC 同士の接続
は、プログラム
実行中に動的に
行うことが出来る。
アプリケーション 操作デバイス センサ
14. OpenRTM-aist
• コンポーネントフレームワーク + ミドルウエアライブラリ
• コンポーネントインターフェース :
– OMG Robotic Technology Component Specification ver1.0 準拠
• OS
– 公式: FreeBSD, Linux (Fedora, Debian, Ubuntu, Vine, Scientific), Windows
– 非公式: Mac OS X, uITRON, T-Kernel, VxWorks
• 言語 :
– C++ (1.1.0), Python (1.0.0), Java (1.0.0)
– .NET (implemented by SEC)
• CPU アーキテクチャ ( 動作実績 ):
– i386, ARM9, PPC, SH4
– PIC, dsPIC, H8 (RTC-Lite)
• ツール (Eclipse プラグイン )
– テンプレートソースジェネレータ : rtc-template 、 RTCBuilder
– システムインテグレーションツール : RTSystemEditor
– その他
• Pattern weaver for RT-Middleware ( 株式会社テクノロジックアートより発売中 )
14
15. OMG RTC 標準化
• 2005 年 9 月
RFP : Robot Technology
Components (RTCs) 公開。
• 2006 年 2 月
Initial Response : PIM and PSM for
RTComponent を執筆し提出
提案者: AIST( 日 ) 、 RTI( 米 )
• 2006 年 4 月
両者の提案を統合した仕様を提案
• 2006 年 9 月
AB にて承認、事実上の国際標準獲
得
FTF が組織され最終文書化開始
• 2007 年 8 月
FTF の最後の投票が終了
• 2007 年 9 月
AB にて FTF の結果を報告、承認
• 2008 年 4 月
OMG RTC 標準仕様公式リリース
• 2010 年 1 月
OpenRTM-aist-1.0 リリース
15
16. OMG RTC ファミリ
Name Vendor Feature
OpenRTM-aist AIST C++, Python, Java
OpenRTM.NET SEC .NET(C#,VB,C++/CLI, F#, etc..)
miniRTC, microRTC SEC CAN ・ ZigBee 等を利用した組込用 RTC 実装
Dependable RTM SEC/AIST 機能安全認証 (IEC61508) capable な RTM 実装
RTC CANOpen SIT, CiA CANOpen のための CiA (Can in automation) にお
ける RTC 標準
PALRO 富士ソフト 小型ヒューマノイドのための C++ PSM 実装
OPRoS ETRI 韓国国家プロジェクトでの実装
GostaiRTC GOSTAI, ロボット言語上で動作する C++ PSM 実装
THALES
H-RTM ( 仮称 ) 本田 R&D OpenRTM-aist 互換、 FSM 型コンポーネントをサ
ポート
同一標準仕様に基づく多様な実装により
• 実装(製品)の継続性を保証
• 実装間での相互利用がより容易に
16
17. Success stories
DAQ-Middleware: KEK/J-PARC
KEK: High Energy Accelerator Research Organization
J-PARC: Japan Proton Accelerator Research Complex
HRP-4: Kawada/AIST
TAIZOU: General Robotics Inc. HIRO: Kawada/GRX HRP-4C: Kawada/AIST
17
18. OpenRTM and HRP4
• New real-time control • Hardware/simulator
framework for concurrent development
is realized by OpenRTM
humanoid robot
and OpenHRP3
HRP4
This control system can be more general and for various kind of
robots.
19. Japan Proton Accelerator Research Complex
Model : Dell PowerEdge SC1430
( J-PARC, 大強度陽子加速器施設)
CPU :Intel Xeon 5120 @ 1.86GHz 2 Cores ×2
Memory: 2GB ハドロン実験施設
物質・生命科学実験施設 Hadron Beam
NIC: Intel Pro 1000 PCI/e (1GbE) Materials and Life Science F acility
OS: Scientific Linux 5.4 (i386) Experimental Facility
核変換施設
Nuclear
Source Sink Transmutatio
n 500 m
ニュートリノ
実験施設
Neutrino to
Kamiokande
Ethernet 3 GeV Synchrotron
Linac 50 GeV
(25 Hz, 1MW) Synchrotron
(350m)
(0.75 MW)
J-PARC = Japan Proton Accelerator Research Complex
© KEK Joint Project between KEK and JAEA (former JAERI)
88MB/s = 704 Mbps
Readout modules x102
PSDs x816
© KEK
20. RT ミドルウエア PJ
FY2002.12-FY2004
• 名称: NEDO 21 世紀ロ
ボットチャレンジプログ
ラム
– 「ロボット機能発現のため
に必要な要素技術開発」
• 目的:
– RT 要素の部品化(モジュ
ール化)の研究開発
– 分散オブジェクト指向開発
– RT 要素の分類・モジュー
ル化に必要な機能・インタ
フェース仕様の明確化
• 予算規模:
– 65 百万円
– 全体 267.3 百万円
20
21. NEDO 基盤 PJ その他の
FY2003-FY2007 ロボッ 開発
ト
ツール
プラグイン
追加・拡張
名称:「運動制御デバイスお
Java開発環境 C++開発環境 RtcLink
• プラグイン プラグイン プラグイン
よびモジュールの開発」
Eclipse Paltform
• 目的:
– 運動制御デバイスの開発 JavaVM
– デバイスに搭載する RTC の開 ツールの Eclipse プラグイン化
発
– その他モーションコントロー
ルに資する RTM/RTC の開発
• 予算規模:
– 15 百万円 / 年
– 371 百万円、全体 1,259 百万円
RTC-CAN の開発
dsPIC 版 RTC-Lite の開発
21
22. 知能化 PJ
FY2007-FY2012
• 名称:「次世代ロボット
知能化技術開発プロジェ
クト」
• 目的
– ソフトウエアプラット
フォームの開発
– 作業知能、移動知能、コ
ミュニケーション知能に関
するモジュールの開発
• 予算:
– 400 百万円
– 全体 7,000 百万円
• 研究グループ
– 15 グループ
22
23. RT ミドルウエアの広がり
ダウンロード
ユーザ数
数 2012 年 2 月現在
2008 2009 2010 2011 2012 タイプ 登録数
合計
年 年 年 年 年 Web ページユーザ 365 人
C++ 4978 9136 12049 1851 253 28267
Web ページアクセス 約 300 visit/day
Python 728 1686 2387 566 55 5422 約 1000 view/day
Java 643 1130 685 384 46 2888
メーリングリスト 447 人
Tool 3993 6306 3491 967 39 14796
All 10342 18258 18612 3768 393 51373 講習会 のべ 572 人
利用組織( Google 46 組織
Map )
プロジェクト登録 OMG RTC 規格実装 ( 11 種
数 類)
タイプ 登録数 Name Vendor Feature
RT コンポーネント 287 OpenRTM-aist AIST C++, Python, Java
群 OpenRTM.NET SEC .NET(C#,VB,C++/CLI, F#, etc..)
RT ミドルウエア 14 miniRTC, microRTC SEC CAN ・ ZigBee 等を利用した組込用 RTC 実装
ツール 19
Dependable RTM SEC/AIST 機能安全認証 (IEC61508) capable な RTM 実
仕様・文書 4 装
RTC CANOpen SIT, CiA CANOpen のための CiA (Can in automation)
ハードウエア 28
における RTC 標準
PALRO 富士ソフト 小型ヒューマノイドのための C++ PSM 実装
OPRoS ETRI 韓国国家プロジェクトでの実装
GostaiRTC GOSTAI, THALES ロボット言語上で動作する C++ PSM 実装
23
24. プロジェクトページ
• ユーザが自分の作品
を登録
• 他のユーザの作った
RTC を探すことがで
きる
タイプ 登録数
RT コンポーネント 287
群
RT ミドルウエア 14
ツール 19
仕様・文書 4
ハードウエア 28
24
26. NEDO RT コンポーネント集
• www.openrtm.org に
NEDO 知能化 PJ 成果
物の特別ページを設
置
–ツール
–作業知能モジュール
–移動知能モジュール
–対話知能モジュール
–商用ライセンスモジュ
ール
の 5 カテゴリに分けて掲
載
28. OpenRTM を使った開発の流れ
どのようなコンポーネント
か?
コンポーネン ・名前
・データポート
トの仕様 ・サービスポート コアロジック
・コンフィギュレーション
RTC 開発者が
コードの雛型 開発したプロ
RtcTemplate ( C++ のクラ グラム資産
ス)
コード生成
コンパイル
雛型にコアロジッ
クを埋め込む
.so or DLL
マネージャ
(ミドルウエ
ア)
実行
28
29. フレームワークとコアロジック
R T コ ンポーネント R T コ ンポーネント
標 準 イ ン タ ー フ ェー ス 標 準 イ ン タ ー フ ェー ス
ス テ レ オ ビ ジ ョン
ア ル ゴ リズ ム
左 目 画 像 右 目 画 像 左 目 画 像 右 目 画 像
中 身 は 空
+ デ プ ス マ ップ
= デ プ ス マ ップ
R T コ ンポーネント コ ア ロ ジ ック ス テ レ オ ビ ジ ョン
フレー ム ワー ク R T コ ンポーネント
RTC フレームワーク+コアロジック= RT コンポーネント
30. コンポーネントの作成
( Windows の場合)
RTBUilder CMake Visual C++
コンポーネントの VC のプロジェクト 実装および
仕様の入力 ファイルの生成 VC でコンパイル
実行ファイルの生成
テンプレートコード
の生成
30
31. コード例
• 生成されたクラスの
メンバー関数に必要
な処理を記述
• 主要な関数
– onExecute ( 周期実行 )
• 処理
– InPort から読む
– OutPort へ書く
– サービスを呼ぶ
– コンフィギュレーショ
ンを読む
31
32. コンポーネント内の状態遷移
ユーザがあまり
意識しなくてよい部分
コンポーネント開発時に
必要な部分
ActiveDo/RTC::onExecute はここに入る
( DataFlow 型のコンポーネントのとき)
33. コールバック関数
RTC の作成=コールバック関数に処理を埋め込む
コールバック関 処理
数
onInitialize 初期化処理 とりあえずは
この 5 つの関数
onActivated アクティブ化されるとき 1 度だけ呼ばれる を押さえて
おけば OK
onExecute アクティブ状態時に周期的に呼ばれる
onDeactivated 非アクティブ化されるとき 1 度だけ呼ばれる
onAborting ERROR 状態に入る前に 1 度だけ呼ばれる
onReset reset される時に 1 度だけ呼ばれる
onError ERROR 状態のときに周期的に呼ばれる
onFinalize 終了時に 1 度だけ呼ばれる
onStateUpdate onExecute の後毎回呼ばれる
onRateChanged ExecutionContext の rate が変更されたとき 1 度だけ呼ばれ
る
onStartup ExecutionContext が実行を開始するとき 1 度だけ呼ばれる
onShutdown ExecutionContext が実行を停止するとき 1 度だけ呼ばれる
34. InPort
• InPort のテンプレート第 2 引
数:バッファ In P o r t
– ユーザ定義のバッファが利
用可能 re a d ()
• InPort のメソッド o p e ra to r> >
– read(): InPort バッファか 最 新 値
らバインドされた変数へ最
新値を読み込む
バ イ ン ドさ れ た 変 数
– >> : ある変数へ最新値を
読み込む リン グ バ ッフ ァ
基本的に OutPort と対にな 例
る
データポートの型を
Sensor Data Robot
同じにする必要あり Component
35. OutPort
• OutPort のテンプレート第 2 引
数:バッファ Ou t Po r t
– ユーザ定義のバッファが利
wr it e ()
用可能
• OutPort のメソッド 最新値
o p e r a t o r <<
– write(): OutPort バッファ
へバインドされた変数の最
新値として書き込む
– >> : ある変数の内容を最 バインドされた変数
新値としてリングバッファ リングバッファ
に書き込む
基本的に InPort と対になる 例
Sensor Data
Sensor
データポートの型を Component
同じにする必要あり
36. データ変数
struct TimedShort struct TimedShortSeq
{ {
Time tm; Time tm;
short data; sequence<short> data;
}; };
• 基本型 • シーケンス型
– tm :時刻 – data[i]: 添え字によるアクセス
– data: データそのもの – data.length(i): 長さ i を確保
– data.length(): 長さを取得
• データを入れるときにはあらかじ
め長さをセットしなければならな
い。
• CORBA のシーケンス型そのもの
• 今後変更される可能性あり
37. データポート
• データ指向 (Data Centric) な
ストリームポート
A c tiv ity C O R B A I/F
– 型: long, double×6, etc…
P u b lis h e r
N o tif y i n p op ru t t. (p d u a t t( ad ) a t a ) o p e r a t i o n
• ユーザが任意に定義可能 b u ffe r O r ig in a l P r o to c o l
– 出力: OutPort a s y n c h ro n o u s (a ) “ n e w ” ty p e s u b s c rip tio n
– 入力: InPort R aw T C P S ocket
(a ) P u s h (p u b lis h e r/s u b s c rib e r) c o m m u n ic a tio n m o d e l
• 接続制御(接続時に選択可能) A c tiv ity P u b lis h e r
p u t(d a ta )
– Interface type T im e r
o u tp o r t.g e t( ) o p e r a tio n
• CORBA,TCP socket, b u ffe r C o n n e c te d b y o r ig in a l p r o to c o l
other protocol, etc… (b ) “ p e rio d ic ” ty p e s u b s c rip tio n
– Data flow type
• push/pull A c tiv ity
D a ta tr a n s fe r th r o u g h “ O r ig in a l P r o to c o l”
( b ) P pu u l t c( do am t am ) u n i c a t i o n m o d e l
l
– Subscription type
• Flush, New, Periodic
s y n c h ro n o u s (c ) “ flu s h ” ty p e s u b s c rip tio n
37
38. データポートモデル
• Connector:
– バッファと通信路を抽象化したオブジェクト。 OutPort からデータを受
け取りバッファに書き込む。 InPort からの要求に従いバッファからデ
ータを取り出す。
– OutPort に対してバッファフル・タイムアウト等のステータスを伝える
。
– InPort に対してバッファエンプティ・タイムアウト等のステータスを伝
える。
• OutPort:
– アクティビティからの要求によってデータをコネクタに書き込むオブ
ジェクト
• InPort:
– アクティビティからの要求によってデータをコネクタから読み出すオ
ブジェクト
notify full/timeout status notify empty/timeout status
38
39. Push 型データポートモデル
ネットワーク等による通信
• Connector
– 実際には間に通信が入
る可能性がある
• 3 つの送信モデル
– “new”,“periodic”,“flush”
– パブリッシャによる実
現
• バッファ、パブリッ
シャ、通信インター
フェースの 3 つを
Connector に内包
39
40. バッファインターフェース
BufferBase <T>
• バッファ操作のため advanceRptr(long n) : ReturnCode
advanceWptr(long n) : ReturnCode
のインターフェース empty() : bool
full() : bool
を定義 get(T& data) : ReturnCode
put(T& data) : ReturnCode
– より詳細な操作を提供 read(T& data, int sec, int nsec) : ReturnCode
write(T& data, int sec, int nsec) : ReturnCode
– バッファフル / エンプ
ティを検出可能に リターンコード
• BUFFER OK 正常終了
– タイムアウトを検出可 • BUFFER ERROR エラー終了
能に • BUFFER FULL バッファフル状態
• BUFFER EMPTY バッファ空状態
• NOT SUPPORTED サポート外の要求
• TIMEOUT タイムアウト
• PRECONDITION NOT MET 事前状態を満たさ
ない
40
41. Push ポリシー
• バッファ残留データ
ALL
– 送り方のポリシ
ポリ 送り方 FIFO
シ
ALL 全部送信
FIFO 先入れ後だしで 1 個ずつ送信 NEW
NEW 最新値のみ送信
SKIP n 個おきに間引いて送信
– データ生成・消費速度 SKIP
を考慮して設定する必
要がある。
予稿には NEW の説明に LIFO と記述していましたが正確には
LIFO ではなく最新値のみの送信です。 LIFO 形式のポリシを
導入するかどうかは検討中です。ご意見ください。
41
42. 動作シーケンス
③ 参照を取得
ネームサーバ
④ ポートを接続
① 参照を登録 ② 参照を登録
42
43. ネットワークインターフェース
が
2 つある場合の注意
RTC-A (Address RTC-A ( Address B )
B)
ってどこ?
ネーム
Address B
サーバ
登録はアドレス B 側の
RTC-A ネームサーバ
登録はアドレス B 側の こちらのアドレスを基に
ネームサーバ CORBA 参照を生成
Address A
43
44. Rtc.conf について
RT Component 起動時の登録先 NamingService や、登
録情報などについて記述するファイル
記述例:
corba.nameservers: localhost:9876
naming.formats: SimpleComponent/%n.rtc
(詳細な記述方法は etc/rtc.conf.sample を参照)
以下のようにすると、コンポーネント起動時に読み込
まれる
./ConsoleInComp –f rtc.conf
45. ネーミングサービス設定
corba.nameservers host_name:port_number で指定、デフォルトポート
は 2809(omniORB のデフォルト ) 、複数指定可能
naming.formats %h.host_cxt/%n.rtc →host.host_cxt/MyComp.rtc
複数指定可能、 0.2.0 互換にしたければ、
%h.host_cxt/%M.mgr_cxt/%c.cat_cxt/%m.mod_cxt/
%n.rtc
naming.update.enable “YES” or “NO”: ネーミングサービスへの登録の自動
アップデート。コンポーネント起動後にネームサー
ビスが起動したときに、再度名前を登録する。
naming.update.interval アップデートの周期 [s] 。デフォルトは 10 秒。
timer.enable “YES” or “NO”: マネージャタイマ有効・無
効。 naming.update を使用するには有効でなければ
ならない
timer.tick タイマの分解能 [s] 。デフォルトは 100ms 。
必須の項目 必須でない Option 設定
46. ログ設定
logger.enable “YES” or “NO”: ログ出力を有効・無効
logger.file_name ログファイル名。
%h :ホスト名、 %M: マネージャ名 ,%p :プロセス ID
使用可
logger.date_format 日付フォーマット。 strftime(3) の表記法に準拠。
デフォルト: %b %d %H:%M:%S → Apr 24 01:02:04
logger.log_level ログレベル: SILENT, ERROR, WARN, NORMAL,
INFO, DEBUG, TRACE, VERBOSE, PARANOID
SILENT :何も出力しない
PARANOID :全て出力する
※ 以前は RTC 内で使えましたが、現在はまだ使えま
せん。
必須の項目 必須でない Option 設定
47. その他
corba.endpoints IP_Addr:Port で指定: NIC が複数あるとき、 ORB をどち
らで listen させるかを指定。 Port を指定しない場合で
も”:”が必要。 例 “ corba.endpoints: 192.168.0.12:”
使いたい NIC に割り当
NIC が 2 つある場合必ず指定。 てられている IP アドレ
ス
( 指定しなくても偶然正常に動作することもあるが念のた
め。 )
corba.args CORBA に対する引数。詳細は omniORB のマニュアル参
照。
[ カテゴリ名 ]. コンポーネントの設定ファイル
[ コンポーネント •カテゴリ名: manipulator,
名 ]. config_file
•コンポーネント名: myarm,
または •インスタンス名 myarm0,1,2,…
[ カテゴリ名 ]. の場合
[ インスタンス manipulator.myarm.config_file: arm.conf
名 ]. config_file
manipulator.myarm0.config.file: arm0.conf
のように指定可能
必須の項目 必須でない Option 設定
48. まとめ
• RT ミドルウエアの概要
– 背景、目的、利点
– 標準化、適用例
– 過去のプロジェクト、 Web ページ
• RT コンポーネントの開発
– 開発の流れ
– 動作シーケンス
– コールバック、データポート、 rtc.conf
48
Editor's Notes At first, I’d like to mention about RT. What is RT? RT means Robot Technology. This is not only standalone robots like this, but also robotic elements, sensors, actuators and so on. We have studied on RT-Middleware. RT-Middleware is software platform to integrate these RT-elements. The basic concept of RT-Middleware is like this. Now we assume that we have a system made of a joystick and a robot arm. Of course, system developer intends to connect these two software modules, they can be connected. Because they have compatible interfaces. However, in conventional robot system integration, we try to add another robot arm software module developed by other vender, it is difficult to connect our system. Because nobody guarantees compatibility of these modules’ interfaces. Therefore, these modules cannot be connected. So we tried to modularize these software which has compatible standard interfaces. RT-Middleware provides compatible interfaces and common software development methods. If software modules are developed on RT-Middleware, modules which are developed different vendors, can be connected. RT-Middleware have a common interfaces set to develop RT software modules.