EdisonでOpenRTM-aist(考察編)

クローラー制御RTCにジャイロセンサ、加速度センサ、地磁気センサ、距離センサの機能を詰め込んだわけですが、正しい設計だったかどうかは微妙ですね。

ただ個別にRTCを作ってしまうとシステムが分かりづらくなるのもそうですし、複合コンポーネント化等をして同期させる必要も出てくるのが非常に面倒くさいのであまりやりたくはないです。

デバッグが難しくなるのもそうですし、別スレッドで処理する必要性もないどころか上で言ったように同期させる必要があるので、個別にRTCを作る利点がないと思っています。

これが画像処理とか絡んできたら別スレッドで処理する必要性も出てくるかもしれませんけど。


何が最大の問題かと言うとセンサの値をそのまま出力するRTCを作成したとして、大抵の場合その値をそのまま使う事は出来ないと言う事だと思います。
データ受信側のRTCで変換処理をするのであればまだ良いのですが、変換RTCを挟んだりすると一気にシステムの見通しが悪くなるのでできればやってほしくないです。
ましてや単位の設定を適当にやっていると変換RTCが必須になるので、単位には特に注意してください。

ひょっとしたらRTCが10個以上動作する大規模なシステムになったら、RTCが一つ落ちてもrtcdで同一プロセスで起動していない限り他のRTCが一緒に落ちる事はないので、RTCが落ちた事に気付かないなんて事もありえない話ではないかもしれないです。


RTCとして分割するかどうかは以下の基準で判断できるかなあと思います。

• 他のモジュールで置き換える事が可能か？

→置き換える事ができないのであれば全く分割する必要はありません

• 変換RTCを挟む必要はあるか？

→変換RTCが必要ならば極力分割する事は避けるべき

• 同期する必要があるか？

→複合コンポーネント化等が必要になるとデバッグが面倒になるので再考すべき

• マルチスレッドで処理する必要はあるか？

→必要ならばやるメリットはあると思います

• リアルタイムが要求されるか？

→rtcdでの起動、複合コンポーネント化が必須なため考え直した方が良いと思う。ただし片方のRTCをリアルタイム化する必要があるのなら、むしろ分割した方が良いと思います

• 他の言語で作成したRTCと連携させる必要はあるか？

→それが容易にできるのがRTMの特徴でもあるので、必要ならばやっても構わない



後はオーバーヘッドの影響やら分割後のRTCの数などを考えれば適当な粒度のRTCが出来あがりそうな感じはします。
他のモジュールで置き換えができないのであればその時点で分割する事はやめるべきと言うのは間違いないと思っていますが、他は各自の裁量次第なので明確な答えはありません。











Ogre3Dについて調べてみたところ、SDKの1.9.0にはRenderSystem_Direct3D11.dllが付いてくるのですが、1.8.1にはRenderSystem_Direct3D9.dllしか同梱されていないらしい。自分でビルドすれば作成できるとは思いますけど。
さすがにそろそろOgre3D、CEGUIのバージョンが古くなってきたので、Ogre3Dは1.9.0、CEGUIは0.8.4を使う事にします。

・・・と思っていたのですがCEGUIの仕様変更が多いためエラーを大量に出ます。
CEGUI::colourがCEGUI::Colourになっていたのは理解に苦しみます。
とりあえず今気付いた点だけでも以下の変更があるみたいです。

• CEGUIFalagardWRBase.lib → CEGUICoreWindowRendererSet.lib
• colour → Colour
• colourRect → ColourRect
• removeChildWindow → removeChild
• addChildWindow → addChild
• 文字変換 PropertyHelper::型名ToString → PropertyHelper<型>::toString
• Vector3にテンプレート引数を指定
• Checkbox → ToggleButton
• EventCheckStateChanged → EventSelectStateChanged
• setGUISheet → setRootWindow
• setRotationの引数 Quatanionのみ(Vector2Dは不可) 　変換にはeulerAnglesRadiansを使用
• setSizeの引数 USizeのみ(Vector2Dは不可)
• Sizeにテンプレート引数を指定
• Point mousePos = MouseCursor::getSingleton().getPosition(); → Vector2f mousePos = System::getSingleton().getDefaultGUIContext().getMouseCursor().getPosition();
• ImageSet → Image
• ImagesetManager → ImageManager
• Pointが削除、Vector2を使用
• Systemの関数が一部GUIContextに移動

未だに20個以上のエラーが残っている状態で修正がなかなか終わりません。

特にImageSetが削除された事により発生したエラーがほとんどなので、その辺を何とかしなくてはなりません。



まだまだ時間がかかりそうです。
















にほんブログ村のロボットのカテゴリから
全然人が来ない・・・