ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
実行コンテキストの自作の方法について説明しておきたいと思います。
まずはPythonで作成してみます。
前にも言った通り1.1.0-RC1以前と1.1.0-RELEASEでは仕様が大きく変わっています。
とりあえずTestEC.pyという名前のファイルを作成してください。
まずOpenRTM-aistをインポートします。
import OpenRTM_aist
そしてPeriodicExecutionContextを継承したクラスを作成します。
class TestEC(OpenRTM_aist.PeriodicExecutionContext):
def __init__(self):
OpenRTM_aist.PeriodicExecutionContext.__init__(self)
そしてsvc関数に実行コンテキストのスレッドで何を実行するかを記述します。
def svc(self):
while self.threadRunning():
OpenRTM_aist.ExecutionContextBase.invokeWorkerPreDo(self)
OpenRTM_aist.ExecutionContextBase.invokeWorkerDo(self)
OpenRTM_aist.ExecutionContextBase.invokeWorkerPostDo(self)
次に実行コンテキストの初期化関数を記述してください。
ファイル名+Initという名前の関数から実行コンテキストを動的にロードするようになるので、関数名には注意してください。
def TestECInit(manager):
OpenRTM_aist.ExecutionContextFactory.instance().addFactory("TestEC", TestEC, OpenRTM_aist.ECDelete)
あとはrtc.confに以下のように記述すれば使えるようになります。
manager.modules.load_path: TestEC.pyの存在するディレクトリへのパス
manager.modules.preload:TestEC.py
exec_cxt.periodic.type:TestEC
ここで注意すべきなのはTestEC.pyまでのパスで、これはRTCを実行したフォルダからのパスになります。
例えば、
python TestRTC.py -f conf/rtc.conf
とした場合、rtc.confの存在するconfフォルダではなく現在のフォルダからのパスを指定しなければならないので注意してください。
以前作成したrtc.conf設定用ツール、複合コンポーネント作成支援ツールを使えばファイルを開くダイアログでファイルを選ぶだけで上記の設定を記述した設定ファイルを作成することができます。
次にC++版の作成方法を説明します。
TestEC.h、TestEC.cppというファイルを作成してください。
TestEC.hから編集します。
まずは必要なヘッダーファイルを読み込みます。
#include <rtm/RTC.h>
#include <rtm/Manager.h>
#include <rtm/PeriodicExecutionContext.h>
そしてPeriodicExecutionContextを継承したクラスを作成して、コンストラクタとsvc関数を宣言しておきます。
classTestEC : public virtual PeriodicExecutionContext
{
public:
TestEC();
virtual int svc();
};
そして外部からTestECInit関数を明示的リンクできるように以下の記述を追加します。
extern "C"
{
DLL_EXPORT void TestECInit(RTC::Manager* manager);
};
次にTestEC.cppを編集します。
まずはTestEC.hをインクルードします。
#include "TestEC.h"
次にコンストラクタ、スレッド実行関数を記述してください。
TestEC::TestEC() : PeriodicExecutionContext()
{
}
int TestEC::svc(void)
{
do
{
std::for_each(m_comps.begin(), m_comps.end(), invoke_worker());
}while (m_svc);
}
最後に実行コンテキストの初期化関数を定義します。
extern "C"
{
void TestECInit(RTC::Manager* manager)
{
manager->registerECFactory("PeriodicExecutionContext", RTC::ECCreate, RTC::ECDelete);
}
};
次にビルドするためにVC++のプロジェクトを作成してみるわけですが、ここではCMakeからプロジェクトを作成するためのCMakeLists.txtを作成してみます。
cmake_minimum_required (VERSION 2.6)
#プロジェクト名
project(TestEC)
#OpenRTM-aistのパッケージ検索find_package(OpenRTM REQUIRED)
#インクルードするヘッダーファイルの存在するディレクトリへのパスを設定
include_directories(${OPENRTM_INCLUDE_DIRS})
include_directories(${OMNIORB_INCLUDE_DIRS})
#/dオプションの設定add_definitions(${OPENRTM_CFLAGS})
add_definitions(${OMNIORB_CFLAGS})
#リンクライブラリの存在するディレクトリへのパスを設定
link_directories(${OPENRTM_LIBRARY_DIRS})
link_directories(${OMNIORB_LIBRARY_DIRS})
#Test#C.cppから動的ライブラリを作成するように指定ADD_LIBRARY(TestEC SHARED TestEC.cpp)
#リンクするライブラリの指定
target_link_libraries(TestEC ${OPENRTM_LIBRARIES} )
他にも必要なライブラリがある場合は前回の記事のように追加してください。
後はCMakeしてプロジェクトを作成後、VC++で開いてビルドしてください。
Linuxの場合は以下のコマンドを入力してください。
cmake .
make
単純にビルドするだけであればこれで良いのですが、統合開発環境で開発した方が僕はやりやすいので、
cmake . -G "CodeBlocks - Unix Makefiles"
と入力してCode::Blocksで開発した方が良いかもしれないです。
そして先ほどと同じようにrtc.confを編集します。
manager.modules.load_path: TestEC.dll、soの存在するディレクトリへのパス
manager.modules.preload:TestEC.dll(.so)
exec_cxt.periodic.type:TestEC
これで使えるようになるはずですが、配布する場合はビルド済みのdllも付属させた方が使いやすいと思います。ダウンロード先でビルドが失敗する可能性もありますし、そもそもCMakeがインストールされていない可能性もあります。違う環境で使いたい場合のみビルドしてもらうぐらいなら事故も少ないと思います。
ライセンスには注意する必要はあるわけですが、OpenRTM-aist、OmniORBはLGPLなのでこれだけなら大丈夫だと思います。
前回のRTMコンテストで実行ファイルを付属させているにもかかわらず、必要なDLL(64bit用OpenRTM-aistのDLL等)を付属させていない作品が多かったように思います。
ライセンスを気にしたのであれば、そもそもヘッダーファイルを読み込んだビルド済み実行ファイルを付属させている時点でアウトの可能性があるので考える意味はありません。ライセンスを記述したtxtファイルを付属させてください。
追記:そういえばRTCの配布に関してはライセンスは自由に決めて良いとかだったと思うので問題はありませんでした。
そういえばOpenRTM-aistの公式サイトが更新されています。
どうにもRTCビルダの動作確認が不十分だと思うのですけど大丈夫なのでしょうかね?
一度更新されると何年も更新されないので不安です。LibreOfficeみたいに2か月に1回更新するぐらいの更新頻度なら問題ありませんが、そもそも開発に関わっている人数が少ないので無理だと思います。
まあ生成したコードをこちらで修正すれば大丈夫な場合がほとんどみたいなので大丈夫か。
メーリングリストでRTCビルダで生成した***impl.h、****impl.cppに関する不具合が幾つか報告されているみたいです。
RC4以前から発生していた現象のように思うのですけど、どうなんでしょうね?
ManipulatorCommonInterface_Common.idl、ManipulatorCommonInterface_DataTypes.idl、ManipulatorCommonInterface_MiddleLevel.idlを使ってimplファイルを生成した時ですが、相当な数のエラーが出て何か所も修正した記憶があります。
まあこちらで生成したコードを修正すれば対応できるので仕様かどうかが判断しづらいところではあるとは思います。開発者サイドが仕様と言えば仕様、バグと言えばバグになる程度だと思います。
今更ですが、僕はRC4で生成したコードはCMakeが通らなかったので今までRC3を使っていました。本当に今更なのでどうでもいいのですけど。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
まずはPythonで作成してみます。
前にも言った通り1.1.0-RC1以前と1.1.0-RELEASEでは仕様が大きく変わっています。
とりあえずTestEC.pyという名前のファイルを作成してください。
まずOpenRTM-aistをインポートします。
import OpenRTM_aist
そしてPeriodicExecutionContextを継承したクラスを作成します。
class TestEC(OpenRTM_aist.PeriodicExecutionContext):
def __init__(self):
OpenRTM_aist.PeriodicExecutionContext.__init__(self)
そしてsvc関数に実行コンテキストのスレッドで何を実行するかを記述します。
def svc(self):
while self.threadRunning():
OpenRTM_aist.ExecutionContextBase.invokeWorkerPreDo(self)
OpenRTM_aist.ExecutionContextBase.invokeWorkerDo(self)
OpenRTM_aist.ExecutionContextBase.invokeWorkerPostDo(self)
次に実行コンテキストの初期化関数を記述してください。
ファイル名+Initという名前の関数から実行コンテキストを動的にロードするようになるので、関数名には注意してください。
def TestECInit(manager):
OpenRTM_aist.ExecutionContextFactory.instance().addFactory("TestEC", TestEC, OpenRTM_aist.ECDelete)
あとはrtc.confに以下のように記述すれば使えるようになります。
manager.modules.load_path: TestEC.pyの存在するディレクトリへのパス
manager.modules.preload:TestEC.py
exec_cxt.periodic.type:TestEC
ここで注意すべきなのはTestEC.pyまでのパスで、これはRTCを実行したフォルダからのパスになります。
例えば、
python TestRTC.py -f conf/rtc.conf
とした場合、rtc.confの存在するconfフォルダではなく現在のフォルダからのパスを指定しなければならないので注意してください。
以前作成したrtc.conf設定用ツール、複合コンポーネント作成支援ツールを使えばファイルを開くダイアログでファイルを選ぶだけで上記の設定を記述した設定ファイルを作成することができます。
次にC++版の作成方法を説明します。
TestEC.h、TestEC.cppというファイルを作成してください。
TestEC.hから編集します。
まずは必要なヘッダーファイルを読み込みます。
#include <rtm/RTC.h>
#include <rtm/Manager.h>
#include <rtm/PeriodicExecutionContext.h>
そしてPeriodicExecutionContextを継承したクラスを作成して、コンストラクタとsvc関数を宣言しておきます。
classTestEC : public virtual PeriodicExecutionContext
{
public:
TestEC();
virtual int svc();
};
そして外部からTestECInit関数を明示的リンクできるように以下の記述を追加します。
extern "C"
{
DLL_EXPORT void TestECInit(RTC::Manager* manager);
};
次にTestEC.cppを編集します。
まずはTestEC.hをインクルードします。
#include "TestEC.h"
次にコンストラクタ、スレッド実行関数を記述してください。
TestEC::TestEC() : PeriodicExecutionContext()
{
}
int TestEC::svc(void)
{
do
{
std::for_each(m_comps.begin(), m_comps.end(), invoke_worker());
}while (m_svc);
}
最後に実行コンテキストの初期化関数を定義します。
extern "C"
{
void TestECInit(RTC::Manager* manager)
{
manager->registerECFactory("PeriodicExecutionContext", RTC::ECCreate
}
};
次にビルドするためにVC++のプロジェクトを作成してみるわけですが、ここではCMakeからプロジェクトを作成するためのCMakeLists.txtを作成してみます。
cmake_minimum_required (VERSION 2.6)
#プロジェクト名
project(TestEC)
#OpenRTM-aistのパッケージ検索find_package(OpenRTM REQUIRED)
#インクルードするヘッダーファイルの存在するディレクトリへのパスを設定
include_directories(${OPENRTM_INCLUDE_DIRS})
include_directories(${OMNIORB_INCLUDE_DIRS})
#/dオプションの設定add_definitions(${OPENRTM_CFLAGS})
add_definitions(${OMNIORB_CFLAGS})
#リンクライブラリの存在するディレクトリへのパスを設定
link_directories(${OPENRTM_LIBRARY_DIRS})
link_directories(${OMNIORB_LIBRARY_DIRS})
#Test#C.cppから動的ライブラリを作成するように指定ADD_LIBRARY(TestEC SHARED TestEC.cpp)
#リンクするライブラリの指定
target_link_libraries(TestEC ${OPENRTM_LIBRARIES} )
他にも必要なライブラリがある場合は前回の記事のように追加してください。
後はCMakeしてプロジェクトを作成後、VC++で開いてビルドしてください。
Linuxの場合は以下のコマンドを入力してください。
cmake .
make
単純にビルドするだけであればこれで良いのですが、統合開発環境で開発した方が僕はやりやすいので、
cmake . -G "CodeBlocks - Unix Makefiles"
と入力してCode::Blocksで開発した方が良いかもしれないです。
そして先ほどと同じようにrtc.confを編集します。
manager.modules.load_path: TestEC.dll、soの存在するディレクトリへのパス
manager.modules.preload:TestEC.dll(.so)
exec_cxt.periodic.type:TestEC
これで使えるようになるはずですが、配布する場合はビルド済みのdllも付属させた方が使いやすいと思います。ダウンロード先でビルドが失敗する可能性もありますし、そもそもCMakeがインストールされていない可能性もあります。違う環境で使いたい場合のみビルドしてもらうぐらいなら事故も少ないと思います。
ライセンスには注意する必要はあるわけですが、OpenRTM-aist、OmniORBはLGPLなのでこれだけなら大丈夫だと思います。
前回のRTMコンテストで実行ファイルを付属させているにもかかわらず、必要なDLL(64bit用OpenRTM-aistのDLL等)を付属させていない作品が多かったように思います。
ライセンスを気にしたのであれば、そもそもヘッダーファイルを読み込んだビルド済み実行ファイルを付属させている時点でアウトの可能性があるので考える意味はありません。ライセンスを記述したtxtファイルを付属させてください。
追記:そういえばRTCの配布に関してはライセンスは自由に決めて良いとかだったと思うので問題はありませんでした。
そういえばOpenRTM-aistの公式サイトが更新されています。
どうにもRTCビルダの動作確認が不十分だと思うのですけど大丈夫なのでしょうかね?
一度更新されると何年も更新されないので不安です。LibreOfficeみたいに2か月に1回更新するぐらいの更新頻度なら問題ありませんが、そもそも開発に関わっている人数が少ないので無理だと思います。
まあ生成したコードをこちらで修正すれば大丈夫な場合がほとんどみたいなので大丈夫か。
メーリングリストでRTCビルダで生成した***impl.h、****impl.cppに関する不具合が幾つか報告されているみたいです。
RC4以前から発生していた現象のように思うのですけど、どうなんでしょうね?
ManipulatorCommonInterface_Common.idl、ManipulatorCommonInterface_DataTypes.idl、ManipulatorCommonInterface_MiddleLevel.idlを使ってimplファイルを生成した時ですが、相当な数のエラーが出て何か所も修正した記憶があります。
まあこちらで生成したコードを修正すれば対応できるので仕様かどうかが判断しづらいところではあるとは思います。開発者サイドが仕様と言えば仕様、バグと言えばバグになる程度だと思います。
今更ですが、僕はRC4で生成したコードはCMakeが通らなかったので今までRC3を使っていました。本当に今更なのでどうでもいいのですけど。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
この記事にコメントする