OpenRTM-aistとは?

piping_rtm_logo2.png

OpenRTM-aistはロボットシステムをコンポーネント指向開発するためのソフトウエアプラットフォームです。

OpenRTM-aistでは、ロボットシステムを作る際に、機能要素ごとにソフトウェア ― RTコンポーネント(RTCと呼ぶ)を作成し、それらをつなぎ合わせることでシステムを構築します。RTコンポーネントは、C++PythonJava言語で開発することができ、主要なOS (Linux/Unix、Windows、Mac OS X)をサポートしています。 コンポーネント開発や、コンポーネントを利用したシステム開発には、Eclipseツールおよび、コマンドラインのツールを利用することができます。

RTコンポーネントは、コンポーネント間でデータやコマンドのやり取りをするためのポートと呼ばれる機能や、振る舞いを統一するためのアクティビティと呼ばれる基本的な状態遷移および、パラメーターを外部から操作可能なコンフィギュレーションといった機能が備わっています。 これらの機能を利用することで、独立性や再利用性の高いモジュールを容易に作成することができます。既存のコンポーネントを利用することで、最小限のプログラミングでシステムを構築することができるようになります。

OpenRTM-aistは、ネットワーク透過性、OSやプログラミング言語に対する非依存性を重視して分散オブジェクト規格CORBAを用いて実装されています。現在のところ、OpenRTM-aistはC++、Python、およびJava言語での実装が提供されています。

RTミドルウエア


RTミドルウエア (RTM)

RTミドルウエア(RT-Middleware: RTM)とは、ロボットの機能要素(RT機能要素)ごとにソフトウエアモジュールを作り、それを複数組み合わせてロボットシステム(RTシステム)を構築する為のソフトウエアプラットフォームを指す名前です。 OpenRTM-aistはRTミドルウエア実装の一つであり、Open-source and open architecture Robot Technology Middleware implemented by AIST (産業技術総合研究所)を意味します。

RTシステムを構成するRT機能要素とは、あるまとまった機能を提供するロボットの構成要素で、例えばサーボモーターやセンサー、カメラといったデバイス単位であったり、また、こうしたデバイスの組み合わせにより実現される移動台車やアーム等であったりします。

また、ハードウエアに結びついているものだけでなく制御アルゴリズムや画像処理アルゴリズムといったソフトウエアのみで構成されるものもRT機能要素と考えることができます。 下図に示すようにモジュール化された RT機能要素を階層的に組み合わせることで、容易にロボットシステム構築を実現するためのプラットフォームが RTミドルウエアです。

rtsystem_integration_ja.png
RTミドルウエアによるRTシステムインテグレーション

RTコンポーネント(RTC)

RTミドルウエアでは、RT機能要素をソフトウエアモジュール化したものをRTコンポーネント(RT-Component:RTC)と呼びます。RTコンポーネントでは、他のRTコンポーネントとデータをやり取りしたり通信したりする為にポートと呼ばれるインターフェースを使用します。

図にRTCとRTMの関係を示します。上述したように、RTCはあるひとまとまりの機能をモジュール化したソフトウエアの要素であり、その実体はRTM上で実行される共有オブジェクト(shared object)、DLL (dynamic link library)です。 RTC開発者は、新たに開発した制御アルゴリズムのコードや既存のライブラリコード等(コアロジックと呼ぶ)を、RTCBuilder等のツールによって自動生成されるRTCの雛型コード内に埋め込み、コンパイル(スクリプト言語では不要)することで、RTCを作成します。

rtm_and_rtc_ja.png
RTC(RTコンポーネント)とRTM(RTミドルウエア)

モジュールの分割と統合

RTシステムは、複数のコンポーネントのポートをつなぎ合わせ、それぞれのRTコンポーネント機能の集合体として構築されます。ここで例として対話・認識システムを考えてみます。 対話・認識システムは、ユーザーの声や表情を観測・認識して、音声や身振り手振りなど用いてユーザーと対話する機能を持つシステムで、以下のサブコンポーネントから構成されているとします。

  • カメラコンポーネント
  • ステレオビジョンコンポーネント
  • 顔認識コンポーネント
  • マイクコンポーネント
  • 音声認識コンポーネント
  • 対話コンポーネント
  • 頭・腕コンポーネント
  • 音声合成コンポーネント
    rtcbased_hri_system_ja.png
    RTCより構成される対話・認識システムの例

上図のように、コンポーネントはそれぞれポートと呼ばれる他のコンポーネントと通信するインターフェースを持ち、データやコマンドのやり取りを行い、全体として一つのまとまった機能を実現します。 コンポーネント化することで、コンポーネント単位での並行開発、再利用、交換や更新、分離等が可能になるため、複雑さの軽減、開発効率の向上やシステムの柔軟性・拡張性・安定性の向上が期待できます。

開発の経緯

RTミドルウエアは、(独)新エネルギー・産業技術総合開発機構(NEDO)の21世紀ロボットチャレンジプログラム(2002~2004年度)のプロジェクトにおいて、そのコンセプトが提唱され、(独)産業技術総合研究所(産総研)、松下電工(現パナソニック電工株式会社)、(社)日本ロボット工業会により研究・開発・標準化が行われました。

プロジェクトの成果として、RTミドルウエアの参照実装であるOpenRTM-aist-0.2およびそのインターフェース仕様が公開されました。その後、国際標準化団体OMG(Object Manegement Group: http://www.omg.org )においてRTCインターフェース仕様の標準化が進められ、2008年4月にOMG公式標準仕様となりました。この標準に準拠したRTミドルウエア実装の一つが2010年1月に公開されたOpenRTM-aist-1.0です。

RTC OMG標準

OpenRTM-aistの大きな特徴として、コンポーネントモデルとそのインターフェースがOMGという国際標準化団体で標準化されていることが挙げられます。

OMG は1989年に設立されたソフトウエア標準化団体であり、分散オブジェクトミドルウエア:CORBA (Common Object Request Broker Architecture)、ソフトウェアモデリング言語:UML (Unified Modeling Language)を始めとして、様々な分野のソフトウエア標準を策定・管理している組織として知られています。

RTCのインターフェース仕様も、CORBA同OMGにおいて、産総研と米国ミドルウエアベンダRTI (Real Time Innovations)により標準化され、RTC (Robotic Technology Component) Specification (http://www.omg.org/spec/RTC/1.0/ )として2008年4月に公式リリースされました。

標準化のメリットとして、標準に基づき多くのベンダ、開発者が自由にミドルウエアを実装することができる点が挙げられます。現在、OMG RTC仕様に準拠、または一部準拠するミドルウエアとして、表に示す7種類(OpenRTM-aistの3種類の言語を含む)が存在します。

OMG RTC準拠のミドルウエア一覧

名称 ベンダー名 概要
OpenRTM-aist 産総研 C++、Python、Java の3種類
OpenRTM.NET (株)セック .NET による実装、OpenRTM-aistと互換性あり
OPRoS Project 韓国 ETRI 独自ミドルウエア上の実装
PALRO(パルロ) 富士ソフト株式会社 小型人型ロボットPARLO(パルロ)の制御ソフトウエアがC++言語レベルで互換
GostaiRTC GOSTAI/Thales OMG RTC Local PSMに準拠


このうち、通信を介して互換性がある物は、OpenRTM-aistとOpenRTM.NET のみですが、他の実装とは内部モデルが同一であるため、ブリッジ等を作り連携させることも可能であり、またその際に全体としての整合性に矛盾が生じる可能性を最小化できるでしょう。 また、複数の組織による多様な実装が存在することで、用途に応じて適切な言語やライセンスを選択することも可能であり、プラットフォームとしての永続性や可搬性も高いと言えるでしょう。

ライセンス

OpenRTM-aistは、各言語版(C++、Java、Python)のミドルウエアライブラリと、RTCBuilder、RTSystemEditorなどツールから構成されており、それぞれ

  • OpenRTM-aist (C++、Java、Python版)は LGPLと個別契約のデュアルライセンス
  • RTSystemEditor、RTCBuilderは EPLと個別契約のデュアルライセンス

のもとでオープンソース形式で配布しています。

LGPL(GNU Lesser General Public License)はフリーソフトウェア財団(Free Software Foundation、以下FSFと略称)が提唱しているコピーレフト型のフリーソフトウェアライセンスです。

EPL(Eclipse Public License)はFSFによって認められている「フリーソフトウェアライセンス」の1つであり、CPL(一部はLGPL)等と似たライセンス形態であり、より商業利用を促進するものとなっています。

これらのライセンスは、(i) 別モジュールとして頒布されるソフトウエアや、(ii) 許諾プログラムの派生物でないもの には及びません。またEPLライセンスは、特許に関する条項が含まれており、コントリビューターが持つ特許が当該ソフトウエアの使用に影響しない(使用者には使用料無料の特許ライセンスが付与される)形態となっています。

なお、LGPLライセンスの詳細については、

以下、OpenRTM-aistを用いた生成物の例に関連するライセンスと制約条件を説明します。

RTコンポーネント開発・配布

OpenRTM-aisのライセンスは、個々のRTコンポーネントには及びません。したがって、RTコンポーネントの作成者は、自由なライセンスで配布・販売することができます

RTコンポーネントは、OpenRTM-aist の libRTC.so (またはRTC.DLL) と動的リンクされており、また、RTコンポーネント自体も共有オブジェクト(またはダイナミックリンクライブラリ)として配布可能です。したがって、RTコンポーネント自体はライセンスが定める派生物とはみなされず、LGPLは及びません。

license_for_rtcs_ja.png
RTコンポーネントのライセンス

RTコンポーネントを作成して配布する場合、任意のライセンスの元でRTコンポーネントを配布または販売することができ、ソースコードをオープンにするかクローズにするかを自由に選ぶことができます。

LGPLに基づくOpenRTM-aist の改編と再配布

産総研が公開するOpenRTM-aistをLGPLに基づき利用する場合、産総研は利用者に対して、OpenRTM-aistを実行、改編、再配布、無料使用するライセンスを付与します。 ただし、LGPLでは再配布する場合に、再配布するプログラムについて、LGPLと矛盾しないことを要求しており、その中には改編されたソースコードを第三者が入手可能であることも含まれています。 したがって、LGPL のもとに OpenRTM-aist を改編して再配布したり販売する場合には、ソースコードを開示することが要求されます。

組込みシステムなどにおいては、ソースコードを改編せずにターゲットに適用することが困難で、改変したソースを開示することに抵抗がある場合が数多くあり、これはロボットを事業化したい会社等にとっては不都合であると言えます。 こうした場合を考慮して、OpenRTM-aist は次に説明する、個別契約に基づくライセンス付与の形態もとれるよう、デュアルライセンス形式となっています。

個別契約に基づくOpenRTM-aist の改編と再配布

上記の場合のように、ロボットシステムを商業化する際に、ソースコードを改編しつつ、技術の流出を防ぐためにソースコードをクローズにしたい場合、LGPLやEPLではなく、個別契約のライセンスを用いることができます。

OpenRTM-aistを改編、再配布する場合、産総研の知的財産部門と個別に協議のうえ、個別契約として産総研から利用者に対して非LGPL・非EPLのライセンスを付与することができます。 その場合のソースコードの利用料(実施料)やライセンスの範囲等の条件については、利用形態、ソースコードの改編の度合いや両者の知的財産の割合等に応じて、詳細を決定します。ただし、産総研は産業振興を目的とする非営利法人であり、その実施料は高価なものにはならないはずです。

license_for_rtms_ja.png
RTミドルウエアのライセンス

RtcLink、RtcTemplate(RTSystemEditor、RTCBuilderの以前のバージョン)およびOpenRTM-aist(Java版)については、ソースコードの開示および実施(製品への利用)について個別契約によるライセンス提供の実績があります。

OpenRTM-aist 諸元

OpenRTM-aistは、RTコンポーネントフレームワーク、RTミドルウエア、基本RTコンポーネント群、ライブラリ、基本サービス群、基本ツール群等から構成されています。 RTコンポーネントフレームワークは、RTコンポーネントを作るための基本クラスであり、すべてのRTコンポーネントはこの基本クラスのサブクラスとして作成されます。 RTミドルウエアは、フレームワークに基づいて作成されたRTコンポーネントのモジュールのロードや、インスタンスの生成・解体等のライフサイクルの管理、コンポーネントのネームサービスへの登録等を行う部分です。 これらの中には、ユーザーの利便性を向上させるライブラリ、RTコンポーネントの登録検索等の基本的サービス(現在はCORBAのNaming Serviceを利用)、RTコンポーネントの雛型コードを生成するRTCBuilder、RTコンポーネントの接続・制御等を行うRTSystemEditor等のツール群が含まれています。

現在のところ、OpenRTM-aistは C++、Python、Javaの各言語をサポートしており、Windows、UNIX系OS、μITRON(C++のみ対応)系の各OS上で動作可能です。 さらに、株式会社セックがOpenRTM-aist互換のミドルウエア:OpenRTM .NETを公開しており、C#を始めとする.NET環境でRTCを作成・実行することができます。 異なる言語で作成したRTCや異なるOS上で動作するRTCを相互に接続し連携させることが可能です。

インターフェース仕様

参考

構成

OpenRTM-aist は以下の各言語版のミドルウエアライブラリおよびツール群から構成されています。

OpenRTM-aistの構成

名前 概要
OpenRTM-aist (C++版) C++言語でRTコンポーネントを作成するためのコンポーネントフレームワークとミドルウエアライブラリおよびコマンド群
OpenRTM-aist (Python版) Python言語でRTコンポーネントを作成するためのコンポーネントフレームワークとミドルウエアライブラリおよびコマンド群
OpenRTM-aist (Java版) Java言語でRTコンポーネントを作成するためのコンポーネントフレームワークとミドルウエアライブラリおよびコマンド群
RTCBuilder RTコンポーネントの設計、コード生成を行うためのEclipseプラグイン
RTSystemEditor RTコンポーネントの操作およびRTシステムの設計・操作を行うためのEclipseプラグイン
rtshell RTコンポーネント、RTシステムの操作をCUIから行うためのコマンド群

これらの配布物はそれぞれEPLと個別契約のデュアルライセンスの元配布されています。

動作条件

OpenRTM-aist (C++版)

コンパイラ gcc 3.x 以上、Visual C++ 2008、2010、2012、2013、2015、2017、2019
OS Linux、FreeBSD、Windows、Mac OS X、TOPPERS ASP
CPU i386、x86_64、ppc、arm
依存ライブラリ omniORB 4.0以上、libuuid (Linux)

OpenRTM-aist (Python版)

Python Python 2.7、Python3.6、Python 3.7
依存ライブラリ omniORBpy-2.3以上

OpenRTM-aist (Java版)

Java JDK5 以上
依存ライブラリ JDK に含まれる Java IDL

RTCBuilder/RTSystemEditor

Eclipse 3.4 以上
Java JDK6 以上
依存ライブラリ Eclipse EMF 2.2以上(SDO,XSD含む)、
Eclipse GEF 3.2以上(Draw2D含む)

rtshell

Python Python 2.7、Python3.6、Python 3.7
依存ライブラリ omniORBpy-2.3以上

RTコンポーネントアーキテクチャ

RTコンポーネントフレームワーク

RTコンポーネントを作成するためのフレームワークです。

ロボットシステムを構成する要素をモジュール化するとき、様々な粒度でのモジュール化が考えられます。たとえば、モーターやセンサーといった単機能のデバイス、移動ロボットやアームなど複合的なシステム、あるいは様々な処理を行うアルゴリズムといった単位が考えられ、それらの階層的な集積によりシステムが構築されます。RTミドルウエアでは、これらのRT機能要素の本質的なソフトウエア部分をコアロジックと呼びます。RTコンポーネントフレームワークは、コアロジックに共通のインターフェースという皮を被せて、これらのモジュールを統一的に扱うことができるようにするための仕組みです。

rtc_framework_ja.png
RTコンポーネントフレームワークとコアロジック

上図のように、ステレオビジョンのアルゴリズムをコンポーネント化する例を考えると、アルゴリズムを実装したプログラムそのものはコアロジックに相当します。適切なポートを設定したRTコンポーネントフレームワークを基に、ステレオビジョンアルゴリズムをこのフレームワークに実装してやることで、ステレオビジョンコンポーネントを作ることができます。このように、コンポーネントフレームワークに基づきコンポーネント開発者がコアロジックを実装しシステムに組み込むことができるようにしたモジュールを、RTコンポーネントと呼びます。RTコンポーネントフレームワークは、共通インターフェースの実装を、コンポーネント開発者や、コンポーネントを組合わせてシステムを構築するインテグレータに対して隠蔽します。こうすることによって、コンポーネント開発者はメインのロジックの実装に集中でき、インテグレータは実装の詳細を気にすることなくシステム全体の設計に集中することができます。

RTコンポーネントアーキテクチャ

RTシステムでは、低レベルのセンサ処理やアクチュエータ制御から、高レベルの認識、判断、行動制御など、様々なレベルの処理を連携して行う必要があります。低レベルの制御プログラムには、速度やリアルタイム性の要求を満たす言語が求められる一方で、高レベルのプログラムには、抽象度や記述力の高い言語が求められます。また、現在のRTシステムは、複数のCPUで構成されるケースが増えており、並列制御やネットワークを介した連携機能も必要です。

これらの機能要素をモジュール化するため、RTコンポーネントは、様々な粒度でモジュール化が可能で、かつ、多様な言語、OS上で動作する分散コンポーネント型のフレームワークを提供しています。

図にRTCの基本的なアーキテクチャを示します。RTCの主な機能としては以下のものがあります。

rtc_architecture_ja.png
RTコンポーネントアーキテクチャ

メタ情報取得

RTCはメタ情報(RTCプロファイル)取得のためのインターフェース(イントロスペクション機能)を持ちます。RTCプロファイルとは、コンポーネントの名前や所有しているポートのプロファイルなど、コンポーネントの特性を表わす一連の情報です。この機能は実行時の動的なシステム構成時に必要となります。

イントロスペクション: 日本語で内省と訳される、オブジェクトやコンポーネントのメタ情報を取得する仕組みのこと。定義は一定していないが、Java におけるリフレクションと類似の機能。OMG RTC仕様ではこの機能をintrospectionと定義している。
rtc_arch_introspection_ja.png
メタ情報取得

アクティビティ

コンポーネン内の主たるロジックを実行する仕組み。RTCの統一的管理のため、Inactive(OFF状態)、Active(ON状態)、Error(エラー状態)等の共通の状態が決められています。RTC開発者は、主に、それぞれの状態や状態遷移イベントに割り当てられた関数(コールバック関数)に実現したい機能を実装することでRTCを作成します。

rtc_arch_activity_ja.png
アクティビティと実行コンテキスト

実行コンテキスト

アクティビティを構成するコールバック関数は、実行コンテキスト(Execution Context: EC)と呼ばれるスレッドにより実行されます。ECは、RTCに対して動的にアタッチ/デタッチ可能で、一つのECを複数のRTCにアタッチし、直列に同期的に実行させたり、リアルタイム実行可能なECと入れ替えることでRTCの実行をリアルタイム化することも可能です。

データポート

連続的なデータの送受信を行うためのデータ指向ポート。入力ポート(InPort)と出力ポート(OutPort)の2種類があり、同じデータ型同士なら、言語やOSが異なっていても、ネットワークを介して接続/通信することができます。

rtc_arch_dataport_ja.png
データポート

サービスポート

コマンドレベルの詳細な機能の提供/利用を行うポートです。ユーザー定義可能なプロバイダ(提供(Provided)インターフェース)とコンシューマー(要求(Required)インターフェース)があり、それぞれ外部に機能を提供するインターフェースをProvided Interface、外部の機能を要求/利用するインターフェースをRequired Interfaceと呼びます。データポート同様、言語、OSが異なっていてもインターフェース型が同じなら接続し関数を呼び出すことができます。

rtc_arch_serviceport_ja.png
サービスポート

コンフィギュレーション

ユーザー定義のパラメーターを、実行時に外部から変更するための機能。複数のパラメーターセットを持ち、それらを一斉に入れ替えることができます。パラメーターを予め変更可能にしておくことで、RTCを様々なシステムで再利用可能にします。

rtc_arch_configuration_ja.png
コンフィギュレーション

一般に、RTシステムにおける低レベル部分では、サーボコントローラー等粒度が細かくデータ指向の密結合なサブシステムが主体であり、判断や振る舞いを決める高レベルの部分では、粒度の粗いサービス指向のサブシステムが主体となります。RTCでは、こうした多様な粒度のモジュール化を共通のフレームワークで実現しているため、階層化フレームワークで問題となる、階層間の結合は問題となりません。

異なる言語、およびOS上のRTC間の透過的連携は、分散オブジェクトミドルウエアの標準仕様であるCORBA(Common Object Request Broker Architecture)を利用することで実現されています。

RTC開発の流れ

#contents

本節では、RTミドルウエア(OpenRTM-aist)を利用した、RTコンポーネントの開発方法について説明します。

開発の流れ

OpenRTM-aistは、コンポーネント化のためのフレームワークと、コンポーネントを管理/実行するためのミドルウエアから構成されています。

OpenRTM-aistは、コンポーネントを開発したいユーザー(コンポーネントデベロッパ)が持つ既存のソフトウエア資産、あるいは新たに作成したソフトウエアを容易にRTC化するためのフレームワークを提供します。RTC作成の大まかな流れは下図のようになります。

rtc_devel_flow_ja.png
RTCおよびRTシステム開発の流れ

上述したように、RTコンポーネントが持つ共通インターフェースに関するコード、他のコンポーネントとのデータのやり取りの処理などは、RTコンポーネントフレームワークにより隠蔽されています。これらの処理は共通であるため、多くの部分はライブラリ化や自動生成が可能です。OpenRTM-aistでは RTCの雛型を生成するためのツールとしてRTCBuilderを提供しています。

RTC開発者は、自分が開発した既存のプログラムをコンポーネントフレームワークに組み込むことでRTコンポーネントを作成し、複数のRTCを組合わせてロボットシステムを構築します。既存のソフトウエア資源をソフトウエア部品であるRTコンポーネントとして作成しておけば、様々な場面での再利用が容易になります。作成されたRTCは、ネットワーク上のノードに配置し、任意の別のノードから利用することもできます。

RTCフレームワークに則って作成されたRTCは大きく分けて2種類の形態があります。スタンドアロンRTC(Standalone RT-Component)とローダブルモジュールRTC(Loadble Module RT-Component)です。スタンドアロンRTCは単一の実行形式のバイナリです。ローダブルモジュールRTCは動的にロード可能なバイナリファイルで、1プロセスで複数種類のRTCを同時起動する場合等に用いられます。

RTCBuilderによるひな形コードの作成

RTCBuilderはRTコンポーネントの雛型コードを自動生成する開発ツールです。 このツールを用いて、RTCの基本プロファイルやデータポート、サービスポート、コンフィギュレーションに関する情報を入力することでコアロジック以外の大半のコードを自動生成することができます。対応している言語は、C++、Java、Python、Luaです。コンポーネントを作成する前に、おおよそ以下のことを決めておきます。

  • プロファイル(名前、カテゴリ名、バージョン等)
  • データポート(InPort/OutPort、ポート名、データ型)
  • サービスポート(ポート名、サービスインターフェース)
  • コンフィギュレーション(変数の名前、変数の型)

Eclipseメニューの [ファイル] > [新規] > [その他]と選択してダイアログを開き、表示されたツリーで [その他] > [RTCBuilder] 選択して [次へ] をクリックします。プロジェクト名を入力して [終了] をクリックします。下図の画面が表示され、「基本」「アクティビティ」「データポート」「サービスポート」「コンフィギュレーション」「ドキュメント生成」「言語・環境」「RTC.xml」のタブがあります。「基本」から「言語・環境」までのタブのページを順に必要に応じて項目を埋めていき、最後に、「基本」タブページにある、[コード生成] ボタンをクリックすることで、雛型コードが生成されます。生成されたコードは、Eclipse起動時に指定したワークスペース内にあるプロジェクト名のフォルダーの下に生成されます。

rtcbuilder_ja.png
RTCBuilderの開発画面

RTCの実装

RTコンポーネントのプログラミングでは通常のプログラミングと異なり、main関数に直接処理を実装することはありません。ここでは、例として C++版の実装について述べます。

RTコンポーネントは、ある基底クラスを継承した一つのクラスとして実装されます。 RTコンポーネントにおいてコアロジックが行う処理は、その基底クラスのメンバ関数(メソッド)をオーバーライドする形で記述します。例えば、初期化時に行う処理は、onInitialize関数の中に、RTCがアクティブ時に周期的に処理したい内容はonExecute関数に記述します。

 class MyComponent
  : public DataflowComponentBase
 {
 public:
   // 初期化時に実行したい処理
   virtual ReturnCode_t onInitialize()
   {
     if (mylogic.init())
       return RTC::RTC_OK;
     return RTC::RTC_ERROR;
   }
 
   // 周期的に実行したい処理
   virtual ReturnCode_t onExecute(RTC::UniqueId ec_id)
   {
     if (mylogic.do_someting())
       return RTC::RTC_OK;
     RTC::RTC_ERROR;
   }
 
 private:
   MyLogic mylogic;
   // ポート等の宣言
   //   :
 };

上記はC++での実装例です。 この例では、説明のためにクラス宣言と実装が一体で記述されていますが、実際にはヘッダファイル(.h)と実装ファイル(.cpp)に分割されてコードが生成されます。 MyLogicクラスのオブジェクトmylogicは、このコンポーネントが実際に行うコアロジックが実装されたクラスのインスタンスです。 例では、非常に簡潔にmylogicの関数を呼ぶことでRTCが実装されています、実際の実装でも、コアロジックを予めこの例のように簡単に利用可能なクラス化しておき、コールバック関数内での呼び出しは最低限にする方がよいでしょう。

RTCBuilderにより同時に生成されるMakefileやプロジェクトファイルでこのコードをコンパイル/ビルドすることで、実行ファイルや共有オブジェクト(又はDLL)が作成できます。

RTC ライフサイクル

上述したように、RTCの実装では、予め決められた関数(コールバック関数)に処理を記述することで、コンポーネントを作成します。どのような関数があり、どういったタイミングで呼ばれるのかを知るためには、RTCの状態遷移すなわちライフサイクルを理解する必要があります。下に、RTCの状態遷移図を示します。

rtc_state_machine_ja.png
RTC ライフサイクル (UML ステートマシン図)

コンポーネントは基本的に以下の状態を持ちます。

  • 生成状態(Created)
  • 活動状態(Alive)
    • 非アクティブ状態(Inactive)
    • アクティブ状態(Active)
    • エラー状態(Error)
  • 終了状態

これらの各状態や遷移時には、決められた関数(コールバック関数)がECによって呼び出されます。 表に、コールバック関数とそれぞれが呼ばれるタイミングを示します。

関数名 概要
onInitialize ライフサイクル初期化時に1度だけ呼ばれる。
onActivated アクティブ化する際に1回呼ばれる。
onDeactivated 非アクティブ化する際に1回呼ばれる。
onExecute アクティブ状態にあるとき周期的に呼ばれる。
onStateUpdate onExecuteの後に毎回呼ばれる。
onAborting エラー状態に移行する際に1回呼ばれる。
onError エラー状態にあるとき周期的に呼ばれる。
onReset エラー状態から復帰する際に1回呼ばれる。
onShutdown ECの駆動が停止する際に1回呼ばれる。
onStartup ECの駆動が開始する際に1回呼ばれる。
onFinalize ライフサイクル終了時に1度だけ呼ばれる。

RTシステム開発の流れ

ここでは、作成したRTCを複数組み合わせて, システムを構築する手法について説明します。

ネームサービス

分散オブジェクトミドルウエアは、任意の場所にある計算機上のオブジェクトに対して、参照を保持する代理オブジェクトを介して透過的アクセスを提供します。 この参照は CORBAではIOR(Interoperable Object Reference)と呼ばれ、実体はオブジェクトが存在するコンピュータのネットワークアドレスやポート番号、オブジェクト固有のキー等がエンコードされたものです。 あるオブジェクトのIORを別のコンピュータ上のプログラムから利用する方法としては、ネットワーク上のサーバー上にIORを登録するのが一つの方法です。この参照を登録したり取得したりするサービスがネームサービスです。ネームサービスはCORBAで標準的に定義されているサービスの一つであり、OpenRTM-aistでは、rtm-namingというラッパーコマンドとして提供されています。

RTシステムを起動する前に、RTCを登録するネームサーバーを起動させる必要があります。また、各RTCに対しては、ネームサーバーの場所を前もって調べておく必要があり、そのために設定ファイルrtc.confにその情報を指定します。例えば、ネームサーバーをホスト名openrtm.mydomain.net上で起動した場合、全てのRTCにはそれに対応したrtc.confに以下の内容を書く必要があります。

 corba.nameservers: openrtm.mydomain.net

ネームサーバーはIPアドレスでも指定することができ、「,」で区切ることで複数のサーバーに同時にRTCを登録することができます。ネームサーバーは、通常長時間起動したまま使われ、システムにおいて固定的であるので、設定ファイルを頻繁に書き換える必要はありません。

RTSystemEditorによるシステム構築

作成されたいくつかのRTCを実行し、それらのポートを接続し、アクティブ化することでシステムが動作します。RTC同士の接続やRTCに対してアクティブ化や非アクティブ化のコマンドを送り、システムを起動するためのツールとしてRTSystemEditorが提供されています。

rtse_ja.png
RTSystemEditorによるシステム構築

RTCは起動後メモリーにロードされると、左側のネームサービスビューに表示されます。 ネームサービスビュー上のRTCを中央のエディタにドラッグアンドドロップすると、RTCがシステムエディタ内にアイコンで表示されます。 長方形の辺上の凸部がポートを表しており、RTC間のこれらのポートを接続することでシステムを構築します。また、画面中央下部にはRTCのコンフィギュレーションビューが表示されており、ここで任意のRTCのパラメーターを編集することができるようになっています。

システムを構築したら、エディタ上で右クリックし「All Activate」を選択することで、全てのRTCをアクティブ化することが可能です。また、エディタ上で右クリックし「Save as」を選択することで、システムの構成情報を保存することができます。保存したシステム構成情報は、再度呼び出すことでシステムの接続情報、コンフィギュレーションの情報等を復元することが可能です。

現在のところ、システム構成情報を復元する際には予めRTCを起動しメモリにロードしておく必要がありますが、将来的にはRTCの起動から接続復元までが自動で行えるようになる予定です。

研究開発

開発の経緯

RTミドルウエアは、(独)新エネルギー・産業技術総合開発機構(NEDO)の21世紀ロボットチャレンジプログラム(2002~2004年度)のプロジェクトにおいて、そのコンセプトが提唱され、(独)産業技術総合研究所(産総研)、松下電工(現パナソニック電工株式会社)、(社)日本ロボット工業会により研究/開発/標準化が行われました。

プロジェクトの成果として、RTミドルウエアの参照実装: OpenRTM-aist-0.2およびそのインターフェース仕様が公開されました。その後、国際標準化団体OMG(Object Manegement Group: https://www.omg.org )においてRTCインターフェース仕様の標準化が進められ、2008年4月にOMG公式標準仕様となりました。この標準に準拠したRTミドルウエア実装の一つが2010年1月に公開されたOpenRTM-aist-1.0です。

図に現在の研究/開発/標準化体制を示します。

rtm_randd_ja.png
OpenRTM-aistの研究/開発/標準化体制

RTミドルウエアに関する研究開発は、2002年のRTミドルウエアプロジェクトに始まり、様々なプロジェクトで周辺技術の充実を図りながら、2007年からのNEDO知能化プロジェクトまで継続的に行われてきました(下図)。

rtm_projects_ja.png
OpenRTM-aistに関連した様々なプロジェクト

以下ではこれまでの主なプロジェクトの概要を説明します。

RTミドルウエア関連プロジェクト

RTミドルウエアプロジェクト

独立行政法人新エネルギー・産業技術統合開発機構(NEDO)21世紀ロボットチャレンジプログラム(2002~2004年度)において「ロボット機能発現のために必要な要素技術開発」プロジェクト(通称:RTミドルウエアプロジェクト)が行われました。このプロジェクトでは、ロボット用分散ミドルウェア(RTミドルウエア)の研究開発が行われました。その成果として、ミドルウエアのインターフェース仕様が策定され、その仕様に基づいた実装OpenRTM-aist-0.2.0がリリースされました。

分散コンポーネント型ロボットシミュレーター

科学振興調整費により2005~2007年度にかけて行われたこのプロジェクトは、ロボットソフトウェアの蓄積に適した分散コンポーネントフレームワークと、この上に構築されたロボットワールドシミュレーターを開発することにより、基盤ソフトウェアの再利用を促進し、次世代ロボットの開発を効率化することを目的としています。

openhrp_openrtm_ja.png
分散コンポーネント型ロボットシミュレーター

このプロジェクトにより、これまで産総研において別々に開発されていた、ロボット用動力学シミュレータであるOpenHRP3と、OpenRTM-aistが統合されることになりました。

シミュレーター内の対象システムおよび、外部のコントローラーモジュール等を、RTコンポーネントとして開発し、かつ、コントローラーコンポーネントをシミュレーター/実機ともに再コンパイルすることなしに再利用できるよう、RTコンポーネントのロジック駆動主体である実行コンテキストが拡張されました。

次世代ロボット知能化技術開発プロジェクト

経済産業省およびNEDOによる「次世代ロボット知能化技術開発プロジェクト」(2007~2011年度)は、5年間で総額70億(予想)の大規模プロジェクトです。次世代ロボットシステムのための要素技術を、RTコンポーネントとして作成・蓄積し、再利用の方法やインターフェースの共通化に関する議論を通して、次世代ロボットの設計・実装するための方法論を確立するとともに、実際に使える多くのRTコンポーネント群を蓄積することを目的としています。

また、ロボットシステム開発の様々なフェーズで利用できる各種ツール群、ミドルウエア、ライブラリを含むRTシステム開発のためのプラットフォーム(OpenRT プラットフォーム(OpenRTP)と呼ぶ)をOpenRTM-aistの上に構築しました。開発ツール群は、Eclipseのプラグインとして実装され、一連の作業を同一の開発環境で行うことのできるツールチェーンとなっています。

openrtp_ja.png
OpenRT プラットフォーム (OpenRTP)

ツール間のデータは、RTコンポーネントを基盤としたモジュール仕様記述方式やシステム仕様記述方式 (UMLモデルとXMLスキーマから成る。) に基づいたフォーマットで記述され、ツール間の連携をより確かなものにするとともに、将来的には標準化も目指しています。プロジェクトの最終成果として、作成した多くのRTコンポーネント群やツール群をソースコード公開の上オープン化、あるいは事業化についても検討されています。

オープンイノベーション促進プロジェクト

NEDOにより2008年から3年間実施された「基盤ロボット技術活用型オープンイノベーション促進プロジェクト」です。このプロジェクトでは、既存の要素部品を容易に RTコンポーネント化するため、安価で小型な基盤通信モジュールを開発することを目指しています。さらに、この基盤通信モジュールを利用して、実際に家屋の様々な部分に、センサーやアクチュエーターを配置し、多様なデバイスが連携して安心・安全・快適な居住空間を作り出す知能化住宅を実証システムとして構築しました。

その他

プロジェクト以外においても、OpenRTM-aistの研究/開発/普及のための活動を行っています。

講習会

不定期ですが、年に数回のペースで実習形式の講習会を様々な場所で行っています。特に、機械学会ロボティクス・メカトロニクス講演会においては、チュートリアルとして毎年講習会を実施しています。

RTMコンテスト

ロボットビジネス推進協議会の主催、SICEシステムインテグレーション部門講演会の併設行事として、RTミドルウエアやRTコンポーネントの作品を募集しコンペティションを行うRTミドルウエアコンテストを行っています。