ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
ExcelRTCのPythonへの移植を行っていますが、かなり苦戦しています。
まだまだ時間がかかると思います。
カメラ機能共通インタフェース仕様書を読んでいて気付いたのですが、どうやらTimedImage型というデータ型はあるらしいです。かなり恥ずかしい発言をしてしまいました。申し訳ないです。記事ごと削除するのもあれなので取り消し線を引いときました。
しかし何故か最終的にIDLファイルでは定義されていません。
正直何が何やらさっぱりわからないので詳しい人は教えてください。
個人的な意見ですが、カメラ機能共通インターフェース仕様書のTimedImage型とTimedCameraImage型を比較するとカメラの内部パラメータ、外部パラメータの行列が追加されただけのようなので、カメラのパラメータが必要ない時でもTimedCameraImage型を使った方が他のRTCと接続しやすくなるのではないかなあと思います。画像データに比べたらカメラのパラメータなんて微々たる量だと思うので影響はないと思います。まあそんな事を言い始めたら「TimedPose2D型ではなく常にTimedPose3D型を使った方が良い」とか、極端な話になると「TimedFloat型ではなく常にTimedDouble型を使えば簡単に他のRTCと接続できる」となるかもしれませけど、露骨にデータ量が増えるのでそれは少し気に食わないなあという感じはしなくもないです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
まだまだ時間がかかると思います。
カメラ機能共通インタフェース仕様書を読んでいて気付いたのですが、どうやらTimedImage型というデータ型はあるらしいです。かなり恥ずかしい発言をしてしまいました。申し訳ないです。記事ごと削除するのもあれなので取り消し線を引いときました。
しかし何故か最終的にIDLファイルでは定義されていません。
正直何が何やらさっぱりわからないので詳しい人は教えてください。
個人的な意見ですが、カメラ機能共通インターフェース仕様書のTimedImage型とTimedCameraImage型を比較するとカメラの内部パラメータ、外部パラメータの行列が追加されただけのようなので、カメラのパラメータが必要ない時でもTimedCameraImage型を使った方が他のRTCと接続しやすくなるのではないかなあと思います。画像データに比べたらカメラのパラメータなんて微々たる量だと思うので影響はないと思います。まあそんな事を言い始めたら「TimedPose2D型ではなく常にTimedPose3D型を使った方が良い」とか、極端な話になると「TimedFloat型ではなく常にTimedDouble型を使えば簡単に他のRTCと接続できる」となるかもしれませけど、露骨にデータ量が増えるのでそれは少し気に食わないなあという感じはしなくもないです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
データの転送時間を計測するにはこのサイトみたいにコネクタコールバックを使う必要があると思うのですが、この作品のコメントで言っているデータはどのようにして計測したのかが書いていないのでよくわかりません。
共有メモリの通信の時間を計測したい場合はコールバック時に共有メモリからデータを取得する処理を記述して、その時間も含めて計測する必要があると思います。
しばらくして他の人が誰も質問しないようであればコメントしておきたいと思います。
それにしてもメーリングリストに投稿されていた時刻を戻すと動作が停止するとかいう問題ってPeriodicExecutionContext.cppのcoil::sleep((coil::TimeValue)(m_period - (t1 - t0)));の部分でt1で取得した時間が戻るので待つ時間がその分多くなるだけだと思います。しばらくすれば動作します。かなり特殊な状況ですが、回避するにはt1がt0より小さいときはsleepしないとかする必要がありそうですね。バグというより、単に想定していない使い方なだけな感じもしますね。
なんだか人の作品にコメントしてて思った事があるのですが、「こうした方が良かったのではないでしょうか？」とか書いたときの対応が少し不満な事があります。
もちろんその意見を聞き入れるか自分のやり方が正しいと思うのかは自由です。
ただ僕の提案した意見のどこが駄目なのかの反論がないのは不満です。
こっちはひょっとしたらそこから自分の知らない考え方を知ることができるかもしれないと思って質問をしています。
ちょっと自分勝手なことを言いすぎたかもしれないです。
不快に思った方は無視してください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
共有メモリの通信の時間を計測したい場合はコールバック時に共有メモリからデータを取得する処理を記述して、その時間も含めて計測する必要があると思います。
しばらくして他の人が誰も質問しないようであればコメントしておきたいと思います。
それにしてもメーリングリストに投稿されていた時刻を戻すと動作が停止するとかいう問題ってPeriodicExecutionContext.cppのcoil::sleep((coil::TimeValue)(m_period - (t1 - t0)));の部分でt1で取得した時間が戻るので待つ時間がその分多くなるだけだと思います。しばらくすれば動作します。かなり特殊な状況ですが、回避するにはt1がt0より小さいときはsleepしないとかする必要がありそうですね。バグというより、単に想定していない使い方なだけな感じもしますね。
なんだか人の作品にコメントしてて思った事があるのですが、「こうした方が良かったのではないでしょうか？」とか書いたときの対応が少し不満な事があります。
もちろんその意見を聞き入れるか自分のやり方が正しいと思うのかは自由です。
ただ僕の提案した意見のどこが駄目なのかの反論がないのは不満です。
こっちはひょっとしたらそこから自分の知らない考え方を知ることができるかもしれないと思って質問をしています。
ちょっと自分勝手なことを言いすぎたかもしれないです。
不快に思った方は無視してください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
とりあえずPowerPointRTCも9割ぐらいPython移植ができました。
なんだか最近言う事が辛辣だったかもしれないです。
僕みたいな素人が言えるような事ではなかったと思っています。
今後はあまり言わないようにします。
作品一覧のページですが、どうやら評価の星の数が並び順に影響しているらしいです。
同じ評価の場合はアクセス数で並び替えているように見えます。
僕が適当に評価を付けたおかげで変な順序になってしまっています。
客観的に評価するのであれば僕の作品は1～2点ぐらいだと思うのですが、並び順が下がるのが嫌なので下げることができません。
自分に5点を付けるなんてアホなことするんじゃなかったと後悔しています。
気に入らない人は僕の作品に1点とか付ければ並び順が下がるのでそうしてください。
この作品のコメントを見て驚いたのですが、なんでも同一プロセスで起動したRTCのデータ受け渡しよりも共有メモリによる通信の方が速いらしいです。にわかには信じがたい話ではあるのですが。そもそもデータ転送にかかる時間とは一体何なのでしょね？push型の通信でwrite関数が処理を完了するまでの時間でしょうか？
だとすれば通常の通信の場合はInPort側のバッファに書き込まれているはずで後はそこからデータを取得するだけです。ただ、共有メモリを使う場合はInPort側で共有メモリにアクセスする必要があるわけでまた話は変わってくると思います。
それでもなんだかおかしな結果だなあという印象です。
また測定してくれるみたいなのでその結果を見てみたいです。
一応こちらで通常のRTC同士の通信とrtcdで起動したRTC同士で画像データを通信したときのwrite関数の処理にかかる時間を計測してみたのですが、平均で前者が12ms、後者が3msでした。
いやでもこのサイトでも通信時間を計測しているみたいですが、この結果を見ると確かに半分ぐらい時間がかかっても不思議ではないのかな？という感じがしなくもないです。
何にせよ、何から何までの時間なのか書かれていないので今の所わかりません。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
なんだか最近言う事が辛辣だったかもしれないです。
僕みたいな素人が言えるような事ではなかったと思っています。
今後はあまり言わないようにします。
作品一覧のページですが、どうやら評価の星の数が並び順に影響しているらしいです。
同じ評価の場合はアクセス数で並び替えているように見えます。
僕が適当に評価を付けたおかげで変な順序になってしまっています。
客観的に評価するのであれば僕の作品は1～2点ぐらいだと思うのですが、並び順が下がるのが嫌なので下げることができません。
自分に5点を付けるなんてアホなことするんじゃなかったと後悔しています。
気に入らない人は僕の作品に1点とか付ければ並び順が下がるのでそうしてください。
この作品のコメントを見て驚いたのですが、なんでも同一プロセスで起動したRTCのデータ受け渡しよりも共有メモリによる通信の方が速いらしいです。にわかには信じがたい話ではあるのですが。そもそもデータ転送にかかる時間とは一体何なのでしょね？push型の通信でwrite関数が処理を完了するまでの時間でしょうか？
だとすれば通常の通信の場合はInPort側のバッファに書き込まれているはずで後はそこからデータを取得するだけです。ただ、共有メモリを使う場合はInPort側で共有メモリにアクセスする必要があるわけでまた話は変わってくると思います。
それでもなんだかおかしな結果だなあという印象です。
また測定してくれるみたいなのでその結果を見てみたいです。
一応こちらで通常のRTC同士の通信とrtcdで起動したRTC同士で画像データを通信したときのwrite関数の処理にかかる時間を計測してみたのですが、平均で前者が12ms、後者が3msでした。
いやでもこのサイトでも通信時間を計測しているみたいですが、この結果を見ると確かに半分ぐらい時間がかかっても不思議ではないのかな？という感じがしなくもないです。
何にせよ、何から何までの時間なのか書かれていないので今の所わかりません。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
Win32Comがメインスレッド以外では使えないかもしれない問題は無事解決しました。
日本語の情報は皆無だったので相当苦戦しました。よく考えてみれば、あのコメントって相当な無茶振りですよね。ただ内容では勝てないのだから無理な要求でも実践して少しでも点数を稼がなければならないという苦しい状況なので仕方ないです。
とりあえずWordRTCのPython移植が9割ぐらいできました。PowerPointRTCはまだ1割ぐらいです。一番苦戦しそうなのはExcelRTCで今の所何もできていません。問題はGUIを作り直さなければならない所で何で作るかも決まっていません。とりあえずPyQtでも使ってみようかな？
やはり2週間ぐらいはかかりそうな感じですね。
ORiNのRTCにコメントしてから2週間ぐらい経ちますが未だに返信はありません。
最初のコメントの返信は早かったのに、一体どうしたのでしょうね？
そんなに難しい質問はしていないと思うのですが。
それにしてもHOTMOCKのRTCと指先指示のRTCなんか簡単にコメントが付きそうなのになかなかコメントが投稿されませんね。
単純に絶賛するコメントを書く人なんてほとんどいないので、少しぐらい穴があった方がコメントが投稿されやすいのかもしれないです。
この作品のソースコードが公開されたみたいなので感想を書きます。
マニュアルがどこにあるのかわかりません。ないならないと書いてほしいです。
TimedImage型という謎のデータ型があるのですが、これは何でしょうね？
img.idlというファイルで定義されているみたいですが、例のimg.idlと同じように見えるのですが少し違います。
どこかで見たなあと思ったら、ちょっと前にコメントで教えて頂いたARToolkitPlusのRTCに付属していたimg.idlのver.1.0にTimedImage型という謎のデータ型の記述を追加しただけのようです。
何で古いバージョンを使用するのか、というか何で独自のデータ型をわざわざ既存のファイルに追加したのか全く意図がわかりません。
僕の見間違いでなければstateclassification.cppのonExecuteでm_imageInにデータが入力される度にm_imageBuff = cvCreateImage～としてメモリを確保していますが、これがonDeactivatedでしか解放していないのでメモリリークを引き起こすと思うのですが、どうやら用途からして長時間動作しなければならないのでそんなわけないか。
ちょっと身の程をわきまえずに苦言を書きすぎました。ごめんなさい。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
日本語の情報は皆無だったので相当苦戦しました。よく考えてみれば、あのコメントって相当な無茶振りですよね。ただ内容では勝てないのだから無理な要求でも実践して少しでも点数を稼がなければならないという苦しい状況なので仕方ないです。
とりあえずWordRTCのPython移植が9割ぐらいできました。PowerPointRTCはまだ1割ぐらいです。一番苦戦しそうなのはExcelRTCで今の所何もできていません。問題はGUIを作り直さなければならない所で何で作るかも決まっていません。とりあえずPyQtでも使ってみようかな？
やはり2週間ぐらいはかかりそうな感じですね。
ORiNのRTCにコメントしてから2週間ぐらい経ちますが未だに返信はありません。
最初のコメントの返信は早かったのに、一体どうしたのでしょうね？
そんなに難しい質問はしていないと思うのですが。
それにしてもHOTMOCKのRTCと指先指示のRTCなんか簡単にコメントが付きそうなのになかなかコメントが投稿されませんね。
単純に絶賛するコメントを書く人なんてほとんどいないので、少しぐらい穴があった方がコメントが投稿されやすいのかもしれないです。
この作品のソースコードが公開されたみたいなので感想を書きます。
マニュアルがどこにあるのかわかりません。ないならないと書いてほしいです。
TimedImage型という謎のデータ型があるのですが、これは何でしょうね？
img.idlというファイルで定義されているみたいですが、例のimg.idlと同じように見えるのですが少し違います。
どこかで見たなあと思ったら、ちょっと前にコメントで教えて頂いたARToolkitPlusのRTCに付属していたimg.idlのver.1.0にTimedImage型という謎のデータ型の記述を追加しただけのようです。
何で古いバージョンを使用するのか、というか何で独自のデータ型をわざわざ既存のファイルに追加したのか全く意図がわかりません。
僕の見間違いでなければstateclassification.cppのonExecuteでm_imageInにデータが入力される度にm_imageBuff = cvCreateImage～としてメモリを確保していますが、これがonDeactivatedでしか解放していないのでメモリリークを引き起こすと思うのですが、どうやら用途からして長時間動作しなければならないのでそんなわけないか。
ちょっと身の程をわきまえずに苦言を書きすぎました。ごめんなさい。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
とりあえず関数、クラス、変数名を変更、一部のソースコードを別のファイルに分離するなどしました。
これで少しでも評価が上がると良いのですが。
前々から疑問に思っているのですが、僕はビギナー限定賞を受賞できないのですかね？
それはさておき以下の作品が投稿されたみたいです。だから～の開発とか付けるなって何度言ったら(ry
前々から疑問なんですけど「データポートの型に画像処理用データ型（CameraImage）を採用」って別に特徴でも何でもないですよね？
まだソースコードが公開されていないようなので内容はよくわかりません。感想は後で書きます。
MIDIのRTCのコメントを見ていて疑問に思ったのですが、Pythonラッパーが問題ならば配布しているライブラリをC++でそのまま使えば良かっただけじゃないかなあという気がしなくもないです。
どうやらライブラリ自体はLGPLライセンスみたいなので、特に問題なさそうですが。
この作品のコメントで定量的なデータがあれば良いとか書かれていますね。他の人も同じような考えになるみたいです。
OpenRTM-aistでリアルタイムシステムを扱ったことのある人なら知っていると思いますが、rtcd等で同一プロセスで複数のRTCを起動すると、それらのRTC間のデータの受け渡しは関数呼び出しで行われるためプロセス間通信を行うよりも高速になります。
まあデメリットがないわけではないですけど。RTCが一つ落ちればrtcd自体が落ちてしまうわけですからね。
確かにデータの受け渡しを高速に行いたいならrtcdを使えば良い訳ですし、特に速度が求められないならば通常の通信を行えば良いだけなので今一つ共有メモリを使う利点は見えてこない感じはあります。
C++とPython、JavaのRTC間で高速に通信したいならわからなくもないのですが、C++にしか対応していないみたいですからよくわかりません。
まあ当日の発表でわかるならそれで良いのですが。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
これで少しでも評価が上がると良いのですが。
前々から疑問に思っているのですが、僕はビギナー限定賞を受賞できないのですかね？
それはさておき以下の作品が投稿されたみたいです。だから～の開発とか付けるなって何度言ったら(ry
前々から疑問なんですけど「データポートの型に画像処理用データ型（CameraImage）を採用」って別に特徴でも何でもないですよね？
まだソースコードが公開されていないようなので内容はよくわかりません。感想は後で書きます。
MIDIのRTCのコメントを見ていて疑問に思ったのですが、Pythonラッパーが問題ならば配布しているライブラリをC++でそのまま使えば良かっただけじゃないかなあという気がしなくもないです。
どうやらライブラリ自体はLGPLライセンスみたいなので、特に問題なさそうですが。
この作品のコメントで定量的なデータがあれば良いとか書かれていますね。他の人も同じような考えになるみたいです。
OpenRTM-aistでリアルタイムシステムを扱ったことのある人なら知っていると思いますが、rtcd等で同一プロセスで複数のRTCを起動すると、それらのRTC間のデータの受け渡しは関数呼び出しで行われるためプロセス間通信を行うよりも高速になります。
まあデメリットがないわけではないですけど。RTCが一つ落ちればrtcd自体が落ちてしまうわけですからね。
確かにデータの受け渡しを高速に行いたいならrtcdを使えば良い訳ですし、特に速度が求められないならば通常の通信を行えば良いだけなので今一つ共有メモリを使う利点は見えてこない感じはあります。
C++とPython、JavaのRTC間で高速に通信したいならわからなくもないのですが、C++にしか対応していないみたいですからよくわかりません。
まあ当日の発表でわかるならそれで良いのですが。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
