調査 #943
完了[RTM-1.0.0-RC1]データポートのTimeStampにCPU時刻が自動付与によるシミュレータ側の影響
100%
説明
OpenRTM-1.0.0-RC1-C++を使ってますが、データポート型のデータ(例えばTimedDooubleSeqなど)
にある「tm.sec」「tm.nsec」について、0.4.2では空だったものが、1.0.0ではCPU時刻が自動で
付与されているようです。
仕様でしょうか？
実時間で処理する際、特にロボット実機で処理する際には何ら不都合はないのですが、
OpenHRP3のようにシミュレータを使う際に、シミュレーション時刻の取得が出来ないので
不都合が生じてます。
ちなみに、自分で自作RTCのデータ送信元にてtm.secなどの値を入れて送信すると、
受信側では、CPU時刻に上書きされているようです。
どのタイミングでCPU時刻がつけられているのでしょうか？
複数台PCに分散したRTCでNW上でやりとりする場合、もしPCの時刻がNTPなどで一致させて
いない場合、どうなるでしょうか？
自動で、どのタイミングでついているか分かりませんが、0.4.2では、よく
受け取り側でデータ順が入れ替わって取得することがありました。
その際、自作RTCで付与したtimestampにてソートをして正確性を保ってましたが、データの入れ替わりが1.0.0系でも起きる場合の弊害などが懸念される。
自動付与、手動付与の選択が可能、もしくは、手動付与がされていない場合
（tmがnullの時）だけ自動付与などはどうでしょう。
とりあえずの報告です。
匿名ユーザー さんが約15年前に更新
- 優先度 を 通常 から 高め に変更
新たな問題が見つかりました。「バグ」です。
テスト用RTCを３つ用意し、RTCa->RTCb->RTCcとデータポートでやりとりし、RTCaでテスト用のデータに内部でtimestampを付与したものを送信するテストを実施。
RTCbでRTCaからのデータを受信すると、内部で付与したtimestampは無視されCPU自国が付与されている。
これをそのまま内部でコピーしたものをRTCcに送信すると、本来変更されてはならないtimestamp値が、RTCcで受信した際には新たなCPU時刻になっている。
つまり、唯一のデータの時刻データが、例えばスルーさせるだけのRTCなどを挟んだ際に、
その時の送信時刻で再上書きされている。
単純に送信時にCPU時刻を付与するというロジックでは、問題あり。