マニュアル執筆中(その39)

動作できなかったとかいうコメントがないのはそもそもインストールしてもらうところまで行きつかないのか、それとも動作ができてないけどコメントするのが面倒なのか、どちらなのかがよくわかりません。
アンケートを作成したのでコメントしづらい人はこれの好きな選択肢を選んでください。


今回はコンフィギュレーションコールバックをやります。
以前書いたのですが、その時とは仕様が変わったためもう一度書いておきます。

とりあえず簡単なプログラムを作ってみました。

ポイントはonInitializeの、

1. self.addConfigurationSetListener(OpenRTM_aist.ConfigurationSetListenerType.ON_SET_CONFIG_SET, MyConfigurationSetListener("ON_SET_CONFIG_SET"))
2. self.addConfigurationSetListener(OpenRTM_aist.ConfigurationSetListenerType.ON_ADD_CONFIG_SET , MyConfigurationSetListener("ON_ADD_CONFIG_SET"))
3. self.addConfigurationParamListener(OpenRTM_aist.ConfigurationParamListenerType.ON_UPDATE_CONFIG_PARAM, MyConfigurationParamListener("ON_UPDATE_CONFIG_PARAM"))
4. self.addConfigurationSetNameListener(OpenRTM_aist.ConfigurationSetNameListenerType.ON_UPDATE_CONFIG_SET, MyConfigurationSetNameListener("ON_UPDATE_CONFIG_SET"))
5. self.addConfigurationSetNameListener(OpenRTM_aist.ConfigurationSetNameListenerType.ON_REMOVE_CONFIG_SET, MyConfigurationSetNameListener("ON_REMOVE_CONFIG_SET"))
6. self.addConfigurationSetNameListener(OpenRTM_aist.ConfigurationSetNameListenerType.ON_ACTIVATE_CONFIG_SET, MyConfigurationSetNameListener("ON_ACTIVATE_CONFIG_SET"))

の6つです。
1ではコンフィギュレーションが設定された時のリスナの設定だとは思います。
コンフィギュレーションパラメータを変更したとき等に呼び出されることがわかると思います。
2はコンフィギュレーションセットが追加されたときのリスナを設定しています。
4はコンフィギュレーションセットがアップデートされたときぼリスナの設定です。
RT System Editorでコンフィギュレーションセットの追加、パラメータの変更をした後にRTCをアクティブにすると呼び出されたのがわかると思います。
5はコンフィギュレーションセットが削除されたときのリスナの設定みたいです。
コンフィギュレーションセットの名前を変更したときにも呼び出されるので、名前変更時に一旦削除しているみたいです。
6はコンフィギュレーションセットがアクティブにしたときのリスナの設定みたいです。
少し分かりづらいので、このプログラムを使うと多少動作がわかりやすいかもしれません。

conf.activate_configuration_set("default")

でコンフィギュレーションセットをアクティブにして変更を反映しています。
このときに6のリスナが呼び出されています。


よくわからないのが3でパラメータの変更時に呼び出されるのかなと思っていたのですが呼び出されている様子はありません。
このページで配布しているプログラムがおかしいのかもしれませんが、どういうタイミングで呼び出されるのか詳しい人は教えて頂けると助かります。






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

マニュアル執筆中(その38)

なんか最近RTCのプログラミングの話ばかりしてるなあ。
マニュアルも最近修正とかしてないですからね。


今回は実行コンテキストのコールバックを設定します。
簡単なプログラムを作ってみました。


重要なところはコンストラクタの、

self.addExecutionContextActionListener(OpenRTM_aist.ExecutionContextActionListenerType.EC_ATTACHED, self.ECListener.onAttached)

    self.addExecutionContextActionListener(OpenRTM_aist.ExecutionContextActionListenerType.EC_DETACHED,self.ECListener.onDetached)

    

の2つです。

実行コンテキストに関連付け、関連付け解除のリスナを設定しています。


・・・あまり言うこともないなあ。

ついでにComponentActionの直前、直後に発生するイベントリスナの設定もやっておきます。
とりあえず一部だけ抜粋します。

まず直後のイベントリスナの設定は以下のように書けます。

self.addPostComponentActionListener(OpenRTM_aist.PostComponentActionListenerType.POST_ON_INITIALIZE, self.POST_CAListener.onInitialize)

次に直前のイベントリスナです。

self.addPreComponentActionListener(OpenRTM_aist.PreComponentActionListenerType.PRE_ON_INITIALIZE, self.PRE_CAListener.onInitialize)

設定できるComponentActionは12種類あります。詳しくはこのページに書いてあるようです。




今日はこれぐらいにしておきます。
ネタがもうほとんどない。あと1週間が限界です。
次はコンフィギュレーションコールバックを少しやります。







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

マニュアル執筆中(その37)

今回も書くことなし。
ひょっとしたら10月中旬ぐらいまで誰も投稿しないのではないかと思い始めました。
そもそも10月31日締め切りが早いですし。



今回はコンポーネントオブザーバについて書いておきます。
コンポーネントオブザーバは外部からRTCの状態を監視する際に使用します。
別に周期的に外部ツールでRTCの状態を取得する方法を取ることもできますが、コンポーネントオブザーバを使用した場合RTC側から状態が変化したときにオブザーバに通知します。


コンポーネントオブザーバに関してはほとんど情報がなく、このサイトで取り上げているぐらいしか見つかりませんでした。


とりあえずPython版のサンプルで実験してみようかと思いますが、

C:\Python26\Lib\site-packages\OpenRTM_aist\ext\sdo\observer

にサンプルがあるはずなのですがComponentObserverConsumer.pyはあるのに何故かComponentObserverProvider.pyは存在しません。皆さんの環境ではどうなっているでしょうか？

とりあえずOpenRTM-aistのサイトからダウンロードできるソースコードには含まれていますのでそれをダウンロードしてください。

そして解凍したフォルダの、

OpenRTM-aist-Python-1.1.0\OpenRTM_aist\ext\sdo\observer
OpenRTM-aist-Python-1.1.0\OpenRTM_aist\ext\sdo\observer\test

のsetup.batを実行してください。



次にCOCTestRTC.pyを実行します。
するとCOCTestRTCというRTCが起動するのでこのRTCの監視を行います。


次にtestフォルダのComponentObserverProvider.pyを起動するわけですがConsoleIn0という名前のRTCを監視するようになっているので、43行目のConsoleIn0をCOCTestRTC0に変更してください。変更後ComponentObserverProvider.pyを実行してください。


その後COCTestRTCをActiveにしてみたりDeactiveにしてみたり、あるいは数値を入力せずにエンターキーを押す等してError状態にしてみたりいろいろやってみてください。



heartbeatはRTCが生存していると周期的に送信されるようです。

次にどのように使用するかを見てみます。
まずはrtc.confを見てみます。

manager.modules.load_path:  .

manager.modules.preload: ComponentObserverConsumer



ComponentObserverConsumer.pyをあらかじめ読み込んでおきます。
するとComponentObserverConsumer.pyのComponentObserverConsumerInitが実行されます。ComponentObserverConsumerのinit関数でself._rtobjにRTCオブジェクトを入力して、self._rtobj.addPostComponentActionListenerで状態変化のリスナを設定していると思いますがよくわかりません。
多分、ComponentObserverConsumerのupdateStatus関数で

self._observer._ptr().update_status(statuskind, msg)

とすることでComponentObserverProviderのComponentObserver_iのupdate_status関数の処理が実行されて状態を取得できるのだとは思います。
とりあえずインターフェースComponentObserverを使って状態を通知しているみたいです。

次にComponentObserverProvider.pyを見てみます。
ComponentObserver_iのupdate_status関数で状態変化時の処理を行っています。

以下でheartbeatの通知の有無、heartbeatの周期、監視する状態の指定は以下のコードで記述しているようです。

properties = [OpenRTM_aist.NVUtil.newNV("heartbeat.enable","YES"),

                OpenRTM_aist.NVUtil.newNV("heartbeat.interval","10"),

                OpenRTM_aist.NVUtil.newNV("observed_status","ALL")]

とりあえず、どのように使用するかをまとめると、

1. rtc.confの変更する
2. ComponentObserverProvider.pyのComponentObserver_iのように状態変化時の処理を実装する
3. 必要な数だけComponentObserver_iを生成して各RTCと接続する

という感じなのかなあ？
詳しい資料が見つからないので詳しい人は教えてください。




RTCのプログラミングに関してもあまり書くことがなくなってきたなあ。
今回のサンプルプログラムを見ていてそういえば実行コンテキストのコールバックに関してまだ書いたことなかったなと思ったので明日はそれを書きます。
その次からは、

• manager
• サービスポート
• omniORB

に関する事で埋めたいとは思いますがネタ切れが近いです。








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

マニュアル執筆中(その36)

もうコメントくれくれなんて乞食みたいなことは言わないので、プロジェクトページ下の評価(星が5つ並んでいるところです)を付けてもらえませんか？
好きな星の数を選ぶだけなので気が向いた人はよろしくおねがいします。


今回も書くことがないので共有メモリによる通信を行うRTCを調べてみました。
以下の2つがあるようです。

1. 共有メモリを用いたRTコンポーネント間の大容量データ通信
2. クァッドロータを制御するRTコンポーネント群

他にもあるとは思いますが、ソースコードを読む気力がないのでこれぐらいにしておきます。


まず1について想像半分ですが説明します。
TimedString型のOutPortを持つRTC_AとInPortを持つRTC_Bがあるとします。
RTC_Aで共有メモリの領域の作成、書き込みを行いOutPortから共有メモリの空間名を送信します。そしてRTC_BのInPortで読み込んだ名前で共有メモリを開いてデータの読み込みを行います。多分こんなかんじの動作です。

次に2ですがこのプログラムを書いた人はかなり高度な技術を持っているらしく、ソースコードを読んで動作を理解するのは苦労しました。
まず、自分のRTCで2の共有メモリのポートを利用するためには以下のような記述をします。

宣言
ShmOutPort<long> m_shmOutPort;

初期化
m_shmOutPort("shmOut")

サービスポートの追加
m_shmOutPort.attachTo(*this);

データの書きこみ
m_shmOutPort.write(10);


多分、こんな感じで書けます。
ShmOutPortクラス、ShmInPortクラスはサービスポートm_servicePortを変数として持っています。
ちなみにShmOutPortがコンシュマー、ShmInPortクラスがプロバイダのインターフェースを持つサービスポートになります。

ShmOutPort側のサービスポートのsetShmSegmentID関数で空間名を書き込んで、ShmInPort側でshmSegmentID関数で空間名を取得して共有メモリ空間からデータを読み込むという方法みたいなので、大雑把にいえば1の方法とやりかたは同じです。

ただ1はWindowsAPI、2はBoostのライブラリで共有メモリに関する処理をしているようなので2の方がいろいろなOSで使用できそうですし、1は画像データだけみたいですが2はいろいろなデータを扱える点では汎用性はありそうです。

ただ、2のソフトウェアのプロジェクトページを見たところクァッドロータの制御がメインみたいなのに何故か特徴は共有メモリという風に書いてあります。
ソフトウェア自体のクオリティは高いのだから、せめてクァッドロータで共有メモリによるデータ送信がどのように役立つかを書いておけば良くなるかなあと思わなくもないです。偉そうなことを言ってしまって申し訳ないです。


今年投稿される作品もこんな感じでソースコードを解析するかもしれないので、作った側からしたら不快に思う人もいるかもしれません。
その場合、コメント欄にそう書いてくれたら記事は消しますのでそうしてください。






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

マニュアル執筆中(その35)

なんであんなに早く作品投稿してしまったんだろうか？
ずっと一人なのでそろそろ恥ずかしくなってきたのですが。
もしかしてまだ作品投稿してはいけなかったとか？
いやそれならメールを送ったときに指摘されると思うので違うか。



まだ先の話なのですが、発表当日は賞金の振り込みのために通帳の口座番号を控えておいてください。後でFAXを送る羽目になります。僕も一応準備はして行きます。ビギナー限定賞とかもらえるかもしれないので。






今回も特に書くことがありません。
とりあえずInPortでread関数を使わずにコネクタ取得→Buffer取得からのデータ取得をするプログラムを書いてみたので今回はこれで埋めます。

#!/usr/bin/env python

# -*- coding: utf-8 -*-

import sys

import OpenRTM_aist

import RTC

 

bufftest_spec = ["implementation_id", "BuffTest",

                  "type_name",         "BuffTest",

                  "description",       "Console input component",

                  "version",           "1.0",

                  "vendor",            "sample",

                  "category",          "example",

                  "activity_type",     "DataFlowComponent",

                  "max_instance",      "10",

                  "language",          "Python",

                  "lang_type",         "script",

                  ""]

 

class BuffTest(OpenRTM_aist.DataFlowComponentBase):

    def __init__(self, manager):

        OpenRTM_aist.DataFlowComponentBase.__init__(self, manager)

        self._data = RTC.TimedLong(RTC.Time(0,0),0)

        self._inport = OpenRTM_aist.InPort("in", self._data)

       

 

    def onInitialize(self):

        self.registerInPort("in", self._inport)

        return RTC.RTC_OK

 

    def onExecute(self, ec_id):

        sys.stdin.readline()

        print self._inport.connectors()[0].getBuffer().length()

        print self._inport.connectors()[0].getBuffer().get()

        self._inport.connectors()[0].getBuffer().advanceRptr(1)

        

        #self._inport.connectors()[0].getBuffer().put(RTC.TimedLong(RTC.Time(0,0),34))

        

        #value = [0]

        #self._inport.connectors()[0].getBuffer().read(value)

        #print value[0]

        

        return RTC.RTC_OK

 

def MyModuleInit(manager):

    profile = OpenRTM_aist.Properties(defaults_str=bufftest_spec)

    manager.registerFactory(profile,

                            BuffTest,

                            OpenRTM_aist.Delete)

    comp = manager.createComponent("BuffTest")

 

def main():

    mgr = OpenRTM_aist.Manager.init(sys.argv)

    mgr.setModuleInitProc(MyModuleInit)

    mgr.activateManager()

    mgr.runManager()

 

if __name__ == "__main__":

    main()

このRTCはTimedLong型のInPortを持っています。

onExecuteで、

1. Buffer長の表示(self._inport.connectors()[0].getBuffer().length())
2. Bufferからデータを読みだして表示(self._inport.connectors()[0].getBuffer().get())
3. Bufferの読み出し位置のポインタを1進める(self._inport.connectors()[0].getBuffer().advanceRptr(1))

という動作をするようにプログラムを書いています。
関数の詳しい説明はC:\Python2X\Lib\site-packages\OpenRTM_aist\BufferBase.pyに書いてあるのでそちらを参考にしたほうが良いと思います。


まあでもデータは読みだしたいけど位置は進めたくないなんて状況はあまりなさそうなのでマメ知識ぐらいな感じで覚えておくぐらいで良いかもしれません。








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