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

8 個の投稿 / 0 new

コメントを投稿するにはログインまたはユーザー登録を行ってください

最終投稿

金, 2012-01-06 18:10

Kei Okada

オフライン

Last seen: なし前

登録日: 2011-05-17 20:20

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

岡田です．度々お騒がせしております．

ECから時刻をとれるようにする，という機能があると以下の状況で
便利かと思いましたので，よろしくご検討いただければ幸いです．

ー
シミュレータと実機で同じコンポーネントを使うような状況で，
コンポーネント内で，例えば実行周期を確認する為などの場合で，
シミュレータではシミュレーションの時刻を知りたく，実機では実時刻を
知りたい場合，ECから現在の時刻をとれるような機能があれば，
コンポーネントでonExecuteが呼ばれる度にこれを参照する，という
プログラムがかけそうです
_______________________________________________
openrtm-users mailing list
openrtm-users@openrtm.org
http://www.openrtm.org/mailman/listinfo/openrtm-users

言語未定義

火, 2012-01-10 10:38

パーマリンク

root

オフライン

Last seen: 3時間 33分前

登録日: 2009-06-23 14:31

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

岡田先生、皆様

安藤です

我々も、とある用途でそういった仕様の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 :
> 岡田です．度々お騒がせしております．
>
> ECから時刻をとれるようにする，という機能があると以下の状況で
> 便利かと思いましたので，よろしくご検討いただければ幸いです．
>
> ー
> シミュレータと実機で同じコンポーネントを使うような状況で，
> コンポーネント内で，例えば実行周期を確認する為などの場合で，
> シミュレータではシミュレーションの時刻を知りたく，実機では実時刻を
> 知りたい場合，ECから現在の時刻をとれるような機能があれば，
> コンポーネントでonExecuteが呼ばれる度にこれを参照する，という
> プログラムがかけそうです
> _______________________________________________
> openrtm-users mailing list
> openrtm-users@openrtm.org
> http://www.openrtm.org/mailman/listinfo/openrtm-users

火, 2012-01-10 12:56

(Reply to #2) パーマリンク

ysuga

オフライン

Last seen: 1年 8ヶ月前

登録日: 2011-05-23 10:14

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

安藤先生，岡田先生，皆さま：
菅です．お世話になっております．

前者はプロセス内部のグローバル時間を変更するEC，
後者はEC内部にクロックを持ち，ECから時刻を取得する，
と判断します．

これについては，後者がよいかと思いました．
理由はぱっと考えると以下の二点．

１．同一プロセス内でECを多数使う場合に，後者の方が混乱しないのでは？
２．ECにアクセスして，他のプロセスからRTC内部の時刻にアクセスできそう
３．coilがRTMに依存するモデルは美しくない

ECで時刻を取得できるとなれば，利用したい場面が増えてくると思いますが，
問題が切り分けやすそうな後者の方が魅力を感じます．
また，僕はRTC内では出来るだけcoilのオペレーションを使っていますが，
ECでcoil内部の値がすり替わるというのは，
coilがRTMに依存するということでしょうから，
coilを独立したモジュールとして開発していた意味もなくなってしまうのではないですか？

僕の感覚だと，「美しくない」です．

ではでは

2012年1月10日10:38 Ando Noriaki :
> 岡田先生、皆様
>
> 安藤です
>
> 我々も、とある用途でそういった仕様の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 :
>> 岡田です．度々お騒がせしております．
>>
>> 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
>

火, 2012-01-10 13:26

(Reply to #3) パーマリンク

root

オフライン

Last seen: 3時間 33分前

登録日: 2009-06-23 14:31

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

安藤です

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

まず、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 :
>> 岡田先生、皆様
>>
>> 安藤です
>>
>> 我々も、とある用途でそういった仕様の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 :
>>> 岡田です．度々お騒がせしております．
>>>
>>> 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

水, 2012-01-11 12:49

(Reply to #4) パーマリンク

池添明宏

オフライン

Last seen: なし前

登録日: 2011-06-08 10:20

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

池添です。

私も若干コンセプトは違うのですが、後者の方針のようなものを試験的に
実装したことがあります。（C++ではないのですが）

そのときは、時間とスレッドの動きを管理するスケジューラクラスを、
ECとRTCから参照するようなモデルとしました。
# このため、ECとRTCが同一メモリ上にないと動作しません・・・

スケジューラは、実際の時間のものと論理時間のものを切り替えられる
ようにしました。
論理時間のスケジューラは、例えば、スケジューラの時間を10秒進めると、
1秒周期のECの周期処理が10回動作するような仕組みになっています。
周期の異なる複数のECを、1つのスケジューラで制御することも可能です。

ちなみに、データポートのコールバックやセンサ用の受信スレッドと、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:
>>> 岡田先生、皆様
>>>
>>> 安藤です
>>>
>>> 我々も、とある用途でそういった仕様の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:
>>>> 岡田です．度々お騒がせしております．
>>>>
>>>> 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
>
>
>

金, 2012-01-13 11:07

(Reply to #5) パーマリンク

root

オフライン

Last seen: 3時間 33分前

登録日: 2009-06-23 14:31

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

池添さん

安藤です

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

2012年1月11日12:49 池添明宏 :
> 池添です。
>
> 私も若干コンセプトは違うのですが、後者の方針のようなものを試験的に
> 実装したことがあります。（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:
>>>> 岡田先生、皆様
>>>>
>>>> 安藤です
>>>>
>>>> 我々も、とある用途でそういった仕様の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:
>>>>> 岡田です．度々お騒がせしております．
>>>>>
>>>>> 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
_______________________________________________
openrtm-users mailing list
openrtm-users@openrtm.org
http://www.openrtm.org/mailman/listinfo/openrtm-users

月, 2012-01-16 22:15

(Reply to #6) パーマリンク

池添明宏

オフライン

Last seen: なし前

登録日: 2011-06-08 10:20

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

安藤様

池添です。

>> 私も若干コンセプトは違うのですが、後者の方針のようなものを試験的に
>> 実装したことがあります。（C++ではないのですが）
>
> やはりそういう需要は色々とあるんですね。
> ちなみに、どんなシステムで使用したのでしょうか？

需要があったわけではないのですが、複数データポートの同期待ちや、
複数スレッド間の同期を簡単に書ければ便利ではないかと思い、
試しに実装してみたものです。
論理時間で動かせるようにしたのは、その中の一部の機能です。

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

基本的には1:1になります。
コールバック関数をキューに登録しておいて、任意のタイミング（周期的なタイミングや
イベント発生時）にコールバック関数をキューから取り出し、順次動作させるような仕組み
になっております。

>> ちなみに、データポートのコールバックやセンサ用の受信スレッドと、ECの
>> スレッドを同期させることも考えているので、スケジューラは時間だけでなく
>> スレッドも併せて管理するような構成としています。
>
> 確かに、いろいろなものをECのトリガにしたいケースは色々有りそうですね。
> 可能でしたら、もう少し具体的な使い方を教えていただけますか？

例えば、データポートのコールバックと、コンポーネントのアクティビティを
同じスレッドで動かすことにより、同じリソースにアクセスする場合に
明示的な排他制御を不要にできたりします。

もとの話題から少しずれてしまいましたね…

以上です。

(2012/01/13 11:07), Ando Noriaki wrote:
> 池添さん
>
> 安藤です
>
> コメントありがとうございます。
>
> 2012年1月11日12:49 池添明宏:
>> 池添です。
>>
>> 私も若干コンセプトは違うのですが、後者の方針のようなものを試験的に
>> 実装したことがあります。（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:
>>>>> 岡田先生、皆様
>>>>>
>>>>> 安藤です
>>>>>
>>>>> 我々も、とある用途でそういった仕様の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:
>>>>>> 岡田です．度々お騒がせしております．
>>>>>>
>>>>>> 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
> _______________________________________________
> openrtm-users mailing list
> openrtm-users@openrtm.org
> http://www.openrtm.org/mailman/listinfo/openrtm-users
>
>

火, 2013-01-08 11:33

(Reply to #7) パーマリンク

Kei Okada

オフライン

Last seen: なし前

登録日: 2011-05-17 20:20

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

岡田です．

古い話になりましたが，やはりこの機能が必要ですね，という声が私の周囲で聞こえてきましたので，
掘り起こしてみました．既に対応済みでしたら無視してください．

私の感覚的には前者だと，coil::gettimeofday() を呼べばシミュレーションなら論理時間が，
実機なら実時間が帰ってくるので，ユーザ側からすると，やや使いやすいのかな，と思いました．
％　とはいえ，色々な見方がありますね，

2012/1/16 池添明宏 :
> 安藤様
>
> 池添です。
>
>>> 私も若干コンセプトは違うのですが、後者の方針のようなものを試験的に
>>> 実装したことがあります。（C++ではないのですが）
>>
>> やはりそういう需要は色々とあるんですね。
>> ちなみに、どんなシステムで使用したのでしょうか？
>
> 需要があったわけではないのですが、複数データポートの同期待ちや、
> 複数スレッド間の同期を簡単に書ければ便利ではないかと思い、
> 試しに実装してみたものです。
> 論理時間で動かせるようにしたのは、その中の一部の機能です。
>
>
>>> そのときは、時間とスレッドの動きを管理するスケジューラクラスを、
>>> ECとRTCから参照するようなモデルとしました。
>>> # このため、ECとRTCが同一メモリ上にないと動作しません・・・
>>>
>>> スケジューラは、実際の時間のものと論理時間のものを切り替えられる
>>> ようにしました。
>>> 論理時間のスケジューラは、例えば、スケジューラの時間を10秒進めると、
>>> 1秒周期のECの周期処理が10回動作するような仕組みになっています。
>>> 周期の異なる複数のECを、1つのスケジューラで制御することも可能です。
>>
>> これは、スケジューラ：スレッド=1:1という関係でしょうか？
>
> 基本的には1:1になります。
> コールバック関数をキューに登録しておいて、任意のタイミング（周期的なタイミングや
> イベント発生時）にコールバック関数をキューから取り出し、順次動作させるような仕組み
> になっております。
>
>
>>> ちなみに、データポートのコールバックやセンサ用の受信スレッドと、ECの
>>> スレッドを同期させることも考えているので、スケジューラは時間だけでなく
>>> スレッドも併せて管理するような構成としています。
>>
>> 確かに、いろいろなものをECのトリガにしたいケースは色々有りそうですね。
>> 可能でしたら、もう少し具体的な使い方を教えていただけますか？
>
> 例えば、データポートのコールバックと、コンポーネントのアクティビティを
> 同じスレッドで動かすことにより、同じリソースにアクセスする場合に
> 明示的な排他制御を不要にできたりします。
>
>
> もとの話題から少しずれてしまいましたね…
>
> 以上です。
>
>
>
> (2012/01/13 11:07), Ando Noriaki wrote:
>> 池添さん
>>
>> 安藤です
>>
>> コメントありがとうございます。
>>
>> 2012年1月11日12:49 池添明宏:
>>> 池添です。
>>>
>>> 私も若干コンセプトは違うのですが、後者の方針のようなものを試験的に
>>> 実装したことがあります。（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:
>>>>>> 岡田先生、皆様
>>>>>>
>>>>>> 安藤です
>>>>>>
>>>>>> 我々も、とある用途でそういった仕様の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:
>>>>>>> 岡田です．度々お騒がせしております．
>>>>>>>
>>>>>>> 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
>> _______________________________________________
>> 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
_______________________________________________
openrtm-users mailing list
openrtm-users@openrtm.org
http://www.openrtm.org/mailman/listinfo/openrtm-users

コメントを投稿するにはログインまたはユーザー登録を行ってください

RTコンポーネント	307
RTミドルウエア	35
ツール	22
文書・仕様書	2

OpenRTM-aist

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

ダウンロード

最新バージョン : 2.0.1-RELESE

統計

Choreonoid

OpenHRP3

OpenRTP

産総研RTC集

TORK

DAQ-Middleware

Navigation

News

About us

検索フォーム

ダウンロード

最新バージョン : 2.0.1-RELESE

統計

Choreonoid

OpenHRP3

OpenRTP

産総研RTC集

TORK

DAQ-Middleware