[openrtm-users 02397] Re: ECから時刻をとれるようにする

2012年 1月 13日 (金) 11:07:29 JST

池添さん

安藤です

コメントありがとうございます。

2012年1月11日12:49 池添明宏 <ikezoe ＠ sec.co.jp>:
> 池添です。
>
> 私も若干コンセプトは違うのですが、後者の方針のようなものを試験的に
> 実装したことがあります。（C++ではないのですが）

やはりそういう需要は色々とあるんですね。
ちなみに、どんなシステムで使用したのでしょうか？

> そのときは、時間とスレッドの動きを管理するスケジューラクラスを、
> ECとRTCから参照するようなモデルとしました。
> # このため、ECとRTCが同一メモリ上にないと動作しません・・・
>
> スケジューラは、実際の時間のものと論理時間のものを切り替えられる
> ようにしました。
> 論理時間のスケジューラは、例えば、スケジューラの時間を10秒進めると、
> 1秒周期のECの周期処理が10回動作するような仕組みになっています。
> 周期の異なる複数のECを、1つのスケジューラで制御することも可能です。

これは、スケジューラ：スレッド=1:1という関係でしょうか？

> ちなみに、データポートのコールバックやセンサ用の受信スレッドと、ECの
> スレッドを同期させることも考えているので、スケジューラは時間だけでなく
> スレッドも併せて管理するような構成としています。

確かに、いろいろなものをECのトリガにしたいケースは色々有りそうですね。
可能でしたら、もう少し具体的な使い方を教えていただけますか？

> 参考になるかどうか分かりませんが、以上です。

大変参考になりました。ありがとうございました。


>
>
>
> (2012/01/10 13:26), Ando Noriaki wrote:
>> 安藤です
>>
>> コメントありがとうございます。
>>
>> まず、coil::gettimeofday が論理時間を返すという機能を持つに当たって、
>> これがRTMに依存するということはありません。
>>
>> 一般的な要求として、複数のノード間で時間を同期させたいということが
>> あると思います。その際、coilレベルで、ノード間の時刻同期をさせることを
>> 考えていました。（まだ実装はしていませんが。）
>>
>> この考え方を拡張して、coil::gettimeofdayを複数のクロックソースから
>> 時刻を取得する機能を持たせたいと思っています。
>>
>> なので、まず1.については、この論理時間ECは、シミュレータ等の特殊な
>> 用途で利用するためのもので、かつ論理時間は単一のアプリケーションが
>> 全てを管理するので問題なし、という前提です。
>> また、3.については、coilの論理時間クロックソースの機能にECが
>> アクセスするだけですので、coilがRTMに依存することにはなりません。
>>
>> 2.については、前者も後者も実現できますね。一応、こういうインターフェースを
>> 考えていますので。
>>
>> interface LogicalTimeTriggeredEC
>>   : RTC::ExecutionContext
>> {
>>     void tick(in long sec, in long usec);
>>     void get_time(out long sec, out long usec);
>> };
>>
>>
>> あと、ECにクロックを持たせる機能後者の方が美しいとのことですが、
>> 実際インターフェースをどうするか考えると、あまり美しくはできないことが
>> 分かると思います。
>> RTC内のロジックがEC依存になってしまう恐れがあり、また最悪、
>> RTC::ExecutionContext (LogicalTimeTriggeredECではなく) に
>> get_time() オペレーションを追加しないと、希望のことが実現できないように思います。
>> ＃ECは同一メモリ空間内にあるとは限りませんので。。。
>>
>> まぁ、菅さんがおっしゃるようにECから時刻を取得するというのは正しいと言えば正しいのですが、
>> gettimeofdayで取得する時刻とECの時刻が違うというのも、変な気もします。
>> とりあえず、いまは前者を実装していますが、後者についても考え中ということで。。。。
>>
>> 他にご意見のある方、よろしくお願いします。
>>
>>
>>> 安藤先生，岡田先生，皆さま：
>>> 菅です．お世話になっております．
>>>
>>> 前者はプロセス内部のグローバル時間を変更するEC，
>>> 後者はEC内部にクロックを持ち，ECから時刻を取得する，
>>> と判断します．
>>>
>>> これについては，後者がよいかと思いました．
>>> 理由はぱっと考えると以下の二点．
>>>
>>> １．同一プロセス内でECを多数使う場合に，後者の方が混乱しないのでは？
>>> ２．ECにアクセスして，他のプロセスからRTC内部の時刻にアクセスできそう
>>> ３．coilがRTMに依存するモデルは美しくない
>>>
>>> ECで時刻を取得できるとなれば，利用したい場面が増えてくると思いますが，
>>> 問題が切り分けやすそうな後者の方が魅力を感じます．
>>> また，僕はRTC内では出来るだけcoilのオペレーションを使っていますが，
>>> ECでcoil内部の値がすり替わるというのは，
>>> coilがRTMに依存するということでしょうから，
>>> coilを独立したモジュールとして開発していた意味もなくなってしまうのではないですか？
>>>
>>> 僕の感覚だと，「美しくない」です．
>>>
>>>
>>> ではでは
>>>
>>> 2012年1月10日10:38 Ando Noriaki<n-ando ＠ aist.go.jp>:
>>>> 岡田先生、皆様
>>>>
>>>> 安藤です
>>>>
>>>> 我々も、とある用途でそういった仕様のECを検討しています。
>>>>
>>>> 具体的に言いますと、現在のECのトリガオペレーション tick() の代わりに
>>>> tick (in long sec, in long usec) を使ってアプリケーション側から
>>>> 時刻を与えられるようにし、ECは与えられた時刻を論理クロック
>>>> (グローバルに1個、論理時間を保持するだけのもの) に書き込み、
>>>> coil::gettimeofday() が返す値に反映させる、というものです。
>>>> ＃添付のホワイトボードの図を参照ください。
>>>>
>>>> もう一つ考えているのは、この論理クロックをEC内部に持たせ、
>>>> RTObject_implにECの時刻を取得するメンバ関数を追加するというものです。
>>>>
>>>> 最初の方法は、クロックを論理クロックに切り替えたあとは、
>>>> すべてcoil:gettimeofday で取得した時刻が論理時間に切り替わるので、
>>>> 例えば、ログに記録される時刻もすべて論理時間と同じになるので、
>>>> 挙動とログを照らし合わせるときなどは便利ですが、そのたgettimeofday
>>>> に依存してロジックを組んでいる場合、そこでおかしな現象が起こる可能性もあります。
>>>>
>>>> 後者は、ECに論理時間を取得しに行くロジックだけ、論理時間を元に
>>>> 動作するのでわかりやすいといえばわかりやすいですが、他の時刻は
>>>> 実際のクロックのままです。
>>>>
>>>> 今のところ、前者の実装を行なっているところですが、みなさんでなにか
>>>> アイディアがおありの方がいらっしゃいましたら、コメントいただければ幸いです。
>>>>
>>>> よろしくお願いします。
>>>>
>>>>
>>>> 2012年1月6日18:10 Kei Okada<k-okada ＠ jsk.t.u-tokyo.ac.jp>:
>>>>> 岡田です．度々お騒がせしております．
>>>>>
>>>>> ECから時刻をとれるようにする，という機能があると以下の状況で
>>>>> 便利かと思いましたので，よろしくご検討いただければ幸いです．
>>>>>
>>>>> ー
>>>>> シミュレータと実機で同じコンポーネントを使うような状況で，
>>>>> コンポーネント内で，例えば実行周期を確認する為などの場合で，
>>>>> シミュレータではシミュレーションの時刻を知りたく，実機では実時刻を
>>>>> 知りたい場合，ECから現在の時刻をとれるような機能があれば，
>>>>> コンポーネントでonExecuteが呼ばれる度にこれを参照する，という
>>>>> プログラムがかけそうです
>>>>> _______________________________________________
>>>>> openrtm-users mailing list
>>>>> openrtm-users ＠ openrtm.org
>>>>> http://www.openrtm.org/mailman/listinfo/openrtm-users
>>>>
>>>>
>>>>
>>>> --
>>>> 安藤慶昭＠独立行政法人産業技術総合研究所 知能システム研究部門
>>>>     統合知能研究グループ 主任研究員, 博士(工学)
>>>>     〒305-8568 つくば市梅園1-1-1 中央第2
>>>>     e-mail: n-ando ＠ aist.go.jp, web: http://staff.aist.go.jp/n-ando
>>>>     OpenRTM-aist: http://www.openrtm.org
>>>>
>>>> Noriaki Ando, Ph.D.
>>>>     Senior Research Scientist, RT-Synthesis R.G., ISRI, AIST
>>>>     AIST Tsukuba Central 2, Tsukuba, Ibaraki 305-8568 JAPAN
>>>>     e-mail: n-ando ＠ aist.go.jp, web: http://staff.aist.go.jp/n-ando
>>>>     OpenRTM-aist: http://www.openrtm.org
>>>>
>>>> _______________________________________________
>>>> openrtm-users mailing list
>>>> openrtm-users ＠ openrtm.org
>>>> http://www.openrtm.org/mailman/listinfo/openrtm-users
>>>>
>>>
>>>
>>>
>>> --
>>> ///////////////////////////////////////////////////////////////////
>>> // Yuki Suga, Ph.D.
>>> // URL: http://www.ysuga.net/?lang=en
>>> // E-mail: ysuga ＠ ysuga.net
>>> ///////////////////////////////////////////////////////////////////
>>> _______________________________________________
>>> openrtm-users mailing list
>>> openrtm-users ＠ openrtm.org
>>> http://www.openrtm.org/mailman/listinfo/openrtm-users
>>
>>
>>
>
>
> --
>
> ----------------------------------------------
> 株式会社セック 開発本部 第四開発部
> 池添 明宏 ikezoe ＠ sec.co.jp
> 〒158-0097 東京都世田谷区用賀4-10-1 SBSビル
> TEL： 03-5491-4404 FAX： 03-5491-4771
> ----------------------------------------------
>
> ======================================================================
> この電子メールの内容および添付されている情報は、機密情報であると同時に、
> 宛先として意図した特定の受信者のみに送信いたしております。当方の誤送信
> 等により、心当たりのない方が受信された場合は、大変お手数ですが、受信さ
> れましたメール内容は削除していただきますようお願いいたします。
> ======================================================================
> _______________________________________________
> openrtm-users mailing list
> openrtm-users ＠ openrtm.org
> http://www.openrtm.org/mailman/listinfo/openrtm-users