ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
関数、変数、クラス名を修正中ですが、まだ時間がかかりそうです。
コメントでARToolkitPlusのRTCの情報を教えていただきました。
大変ありがたいです。
ソースコードを読んでみた感じでは処理としてはARTplusReader.cppのlocalize関数のcvUndistort2～で歪み補正をしている以外は昨日作成したものとあまり違いがないように見えます。どうやらInPortのデータ型が例のimg.idlのTimedCameraImage型らしく、カメラのパラメータをそこから取得しているためらしいです。
OutPortはTimedDoubleSeq型でマーカー情報等＋同次変換行列を出力するみたいです。少しOutPortの仕様が好きではないなあという感じはします。実質的に独自のデータ型を使うのとあまり変わらないような気がしますので。
付属していたimg.idlとこのページのimg.idlの内容が違うのですが、大丈夫でしょうか？
頻繁に仕様を変更されると使われなくなると思います。
それはさておき他の作品を見ているとCMakeとビルドの必要があるにもかかわらずCMakeLists.txtに追加のソースファイル、ライブラリ等の記述をしていない事が多いです。
何故このような現象が起こるかというと使い方がよくわからないからだと思います。
誰かOpenRTMをやっている人でCMakeに詳しい人がいたら解説でもしてください。
一応このブログでも以前に少しだけ使い方に触れましたが、所詮素人の書いたものなので詳しい人に書いてほしいです。
むしろCMakeを使わずに上手くやる方法はないものですかね？
それからコメントは3日1回ぐらいは確認するようにした方が良いと思います。
僕のコメントは無視しても特に影響はないと思いますが、原さんは審査委員長らしいので審査に影響があるかもしれません。まあ、ないかもしれないですけど。
そういえば、GitHubを見ているとREADME.mdの編集で大量にコミットしている事がありますが、GitHubのwikiにはプレビュー機能があるのでそれを利用すると簡単に編集できると思います。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
コメントでARToolkitPlusのRTCの情報を教えていただきました。
大変ありがたいです。
ソースコードを読んでみた感じでは処理としてはARTplusReader.cppのlocalize関数のcvUndistort2～で歪み補正をしている以外は昨日作成したものとあまり違いがないように見えます。どうやらInPortのデータ型が例のimg.idlのTimedCameraImage型らしく、カメラのパラメータをそこから取得しているためらしいです。
OutPortはTimedDoubleSeq型でマーカー情報等＋同次変換行列を出力するみたいです。少しOutPortの仕様が好きではないなあという感じはします。実質的に独自のデータ型を使うのとあまり変わらないような気がしますので。
付属していたimg.idlとこのページのimg.idlの内容が違うのですが、大丈夫でしょうか？
頻繁に仕様を変更されると使われなくなると思います。
それはさておき他の作品を見ているとCMakeとビルドの必要があるにもかかわらずCMakeLists.txtに追加のソースファイル、ライブラリ等の記述をしていない事が多いです。
何故このような現象が起こるかというと使い方がよくわからないからだと思います。
誰かOpenRTMをやっている人でCMakeに詳しい人がいたら解説でもしてください。
一応このブログでも以前に少しだけ使い方に触れましたが、所詮素人の書いたものなので詳しい人に書いてほしいです。
むしろCMakeを使わずに上手くやる方法はないものですかね？
それからコメントは3日1回ぐらいは確認するようにした方が良いと思います。
僕のコメントは無視しても特に影響はないと思いますが、原さんは審査委員長らしいので審査に影響があるかもしれません。まあ、ないかもしれないですけど。
そういえば、GitHubを見ているとREADME.mdの編集で大量にコミットしている事がありますが、GitHubのwikiにはプレビュー機能があるのでそれを利用すると簡単に編集できると思います。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
コメントを書こうとしたらちょっと面白い事になりました。
多分大半の人は何が笑えるのかがわからないと思いますので分かる人だけ笑ってください。
僕もロッテファンじゃなかったら知らなかったと思います。
ARToolkitを使ったRTCはいくつかあるのですが、何と言うかどれも仕様が僕の考えているものと違う感じです。まあそれが仕様なので良いとか悪いとか言うつもりはないですが。
例えばこのRTCは何故か図形を合成した画像を出力しているようです。
今一どう使うのかがわかりません。
今年のRTMコンテストの作品にARToolkitを使ったRTCがあるようですが、ソースコードを読んだ感じCameraImage型のデータポートを使っていないように見えます。あとPanTiltAngles型で出力するのもあまり汎用性がないような印象です。
このRTCが理想に近いのですが、配布していないようです。
画像データを入力後マーカーの位置姿勢を出力するという単純なRTCが欲しいと思います。
ないなら作るしかないので、昨日から作り始めました。
とりあえずここでソースコードを配布しています。
とは言っても、個人で使うために作ったものなので出来は良くないです。
特別な理由がなければ前述したRTCを使った方が良いでしょう。
CameraImage型のInPortから画像データを読み込んでTimedPose3D型のOutPortから位置姿勢、TimedDoubleSeq型のOutPortから同次変換行列を出力します。
今の所ソースコードのみの配布です。
ビルドする手順を説明します。
まずはARToolkitPlusをダウンロードして解凍したフォルダをCドライブの直下にコピーしてください。そしてbuild/VC8.XPのARToolKitPlus.slnを開いてビルドしてください。するとlib/Win32フォルダにARToolKitPlus.libが生成されます。
それが終わったらここからダウンロードしたファイルを解凍してCMakeしてプロジェクトファイルを作成してください。先ほどARToolkitPlusのフォルダをCドライブ直下以外にコピーした場合はsrcフォルダのCMakeLists.txtを編集してください。
そしてartp.slnを開いてビルドするとsrc/Releaseフォルダに実行ファイルが生成できます。その後、ARToolkitPlus/sample/simpleフォルダのdataフォルダを先ほどのReleaseフォルダにコピーしてください。これでとりあえず動作できます。マーカーはARToolkitPlusのフォルダのid-markers内の画像を使用してください。コンフィギュレーションパラメータmarkerModeでSIMPLEを選択した場合はsimple/std-borderのフォルダ、BCHを選んだ場合はbchのフォルダの画像を検出できます。画像の番号はpatternIDで指定してください。
ただ、これでも不満な点が多いです。
この作品のソースコードが公開されたようなので感想を書きます。マニュアルは一体どこでしょうね？
それにしてもOpenCVを使った作品がやたら多い気がします。
画像処理は苦手、というか興味がないのでソースコードを読んでもよくわかりません。ロボットで一番興味のない分野がマシンビジョンと言っても過言ではないです。
それはさておきソースコードを読んでみます。
結構複雑ですね。予稿原稿を読んでみないとわからないかもしれないです。
とりあえずonExecuteでwhile文を使っていますが、読んでみた感じ長時間処理を止めてしまう可能性がありそうなのであまり好ましい仕様ではないと思います。長時間止めてしまったらエラーに遷移してくれないとRTシステムエディタなどによる操作ができなくなります。単純に複数のデータの到着を待ちたいのであれば全てのデータポートのisNew()関数でTrueにならない場合は何もせずに終了すれば良いだけだと思うのですが。
EstimateToe.hとCalculateToePosition.hの内容がほとんど同じにしか思えないのですが、もっと簡単にかけたかもしれません。
m_depthの点群から近似的に平面の方程式を求める(estimateFloor.Estimate_plane～)→各点のうち平面から離れている点を抽出する(separateFoot.SeparateFootFromFloor～)までは理解できたようなできてないような感じですが、estimateFoot.Execlabel～で何をしているのかがよくわかりません。どういう基準でラベル付けをしたのでしょうか？
あとcv::Point tipToePoint = calcToePosition.GetToePosition～もよくわかりません。
GetToePosition関数ではbasePointとの距離がm_minDistance以下の点の座標をtipToePointに入れて最終的にtipToePointをreturnしているようですが、m_minDistanceという変数は一度も変更されていません。つまり距離がどんな値になろうとfor文で最後にtipToePointに代入した座標がretrunされることになります。ちょっとよくわからないですね。
マニュアルがないのでソースコードを読んでみての推測ですが、おそらくKinectで地面と足しか検出できない状態で使用するのではないかと思います。
とりあえずマニュアルが公開されるのを待ちたいと思います。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
多分大半の人は何が笑えるのかがわからないと思いますので分かる人だけ笑ってください。
僕もロッテファンじゃなかったら知らなかったと思います。
ARToolkitを使ったRTCはいくつかあるのですが、何と言うかどれも仕様が僕の考えているものと違う感じです。まあそれが仕様なので良いとか悪いとか言うつもりはないですが。
例えばこのRTCは何故か図形を合成した画像を出力しているようです。
今一どう使うのかがわかりません。
今年のRTMコンテストの作品にARToolkitを使ったRTCがあるようですが、ソースコードを読んだ感じCameraImage型のデータポートを使っていないように見えます。あとPanTiltAngles型で出力するのもあまり汎用性がないような印象です。
このRTCが理想に近いのですが、配布していないようです。
画像データを入力後マーカーの位置姿勢を出力するという単純なRTCが欲しいと思います。
ないなら作るしかないので、昨日から作り始めました。
とりあえずここでソースコードを配布しています。
とは言っても、個人で使うために作ったものなので出来は良くないです。
特別な理由がなければ前述したRTCを使った方が良いでしょう。
CameraImage型のInPortから画像データを読み込んでTimedPose3D型のOutPortから位置姿勢、TimedDoubleSeq型のOutPortから同次変換行列を出力します。
今の所ソースコードのみの配布です。
ビルドする手順を説明します。
まずはARToolkitPlusをダウンロードして解凍したフォルダをCドライブの直下にコピーしてください。そしてbuild/VC8.XPのARToolKitPlus.slnを開いてビルドしてください。するとlib/Win32フォルダにARToolKitPlus.libが生成されます。
それが終わったらここからダウンロードしたファイルを解凍してCMakeしてプロジェクトファイルを作成してください。先ほどARToolkitPlusのフォルダをCドライブ直下以外にコピーした場合はsrcフォルダのCMakeLists.txtを編集してください。
そしてartp.slnを開いてビルドするとsrc/Releaseフォルダに実行ファイルが生成できます。その後、ARToolkitPlus/sample/simpleフォルダのdataフォルダを先ほどのReleaseフォルダにコピーしてください。これでとりあえず動作できます。マーカーはARToolkitPlusのフォルダのid-markers内の画像を使用してください。コンフィギュレーションパラメータmarkerModeでSIMPLEを選択した場合はsimple/std-borderのフォルダ、BCHを選んだ場合はbchのフォルダの画像を検出できます。画像の番号はpatternIDで指定してください。
ただ、これでも不満な点が多いです。
- 動作が分かりづらいので画像を表示するかコンフィギュレーションで選択できるようにした方が便利
- クォータニオンを出力できた方が計算量が減る場合もある
- ARToolKitPlus_2.1.1/id-markersフォルダにあるマーカーしか検出できないが独自のマーカーを検出できた方が便利
この作品のソースコードが公開されたようなので感想を書きます。マニュアルは一体どこでしょうね？
それにしてもOpenCVを使った作品がやたら多い気がします。
画像処理は苦手、というか興味がないのでソースコードを読んでもよくわかりません。ロボットで一番興味のない分野がマシンビジョンと言っても過言ではないです。
それはさておきソースコードを読んでみます。
結構複雑ですね。予稿原稿を読んでみないとわからないかもしれないです。
とりあえずonExecuteでwhile文を使っていますが、読んでみた感じ長時間処理を止めてしまう可能性がありそうなのであまり好ましい仕様ではないと思います。長時間止めてしまったらエラーに遷移してくれないとRTシステムエディタなどによる操作ができなくなります。単純に複数のデータの到着を待ちたいのであれば全てのデータポートのisNew()関数でTrueにならない場合は何もせずに終了すれば良いだけだと思うのですが。
EstimateToe.hとCalculateToePosition.hの内容がほとんど同じにしか思えないのですが、もっと簡単にかけたかもしれません。
m_depthの点群から近似的に平面の方程式を求める(estimateFloor.Estimate_plane～)→各点のうち平面から離れている点を抽出する(separateFoot.SeparateFootFromFloor～)までは理解できたようなできてないような感じですが、estimateFoot.Execlabel～で何をしているのかがよくわかりません。どういう基準でラベル付けをしたのでしょうか？
あとcv::Point tipToePoint = calcToePosition.GetToePosition～もよくわかりません。
GetToePosition関数ではbasePointとの距離がm_minDistance以下の点の座標をtipToePointに入れて最終的にtipToePointをreturnしているようですが、m_minDistanceという変数は一度も変更されていません。つまり距離がどんな値になろうとfor文で最後にtipToePointに代入した座標がretrunされることになります。ちょっとよくわからないですね。
マニュアルがないのでソースコードを読んでみての推測ですが、おそらくKinectで地面と足しか検出できない状態で使用するのではないかと思います。
とりあえずマニュアルが公開されるのを待ちたいと思います。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
AR.DroneのRTCに投稿したコメントの返信があったみたいです。
それにしても独自のデータ型を使用したRTCなんてレアだと思いますけどね。
個人的な意見ですが、仕様を変更した方が良いと思います。
まあでも確かにAR.Droneを持っていない僕がとやかく言う事ではないですね。
そういえばTwitterのRTCのマニュアルが公開されているみたいです。
それにしてもこの人の名前何て読むんだろう。
なんでOpenRTM-aistのサンプルのOpenCVCameraCompを使わなかったのでしょうね？
他の作品でやたらとKinectを使っている人が多いですが、何故か既存のRTCを使わずに自作している事が多いような気がします。おそらくですが64bit用のOpenRTM-aistを使用しているためだと思います。さきほどのリンク先のRTCは32bit用のOpenRTM-aistを使用しています。32bit用のOpenRTM-aistを一度インストールするか抽出ツールをつかってcoil110.dll、omniDynamic415_vc10_rt.dll、omniORB415_vc10_rt.dll、omnithread34_vc10_rt.dll、RTC110.dllを入手してRTCと同じフォルダにコピーすると動作すると思うのでそうしてください。
というよりソースコードが公開されているのだから64bit用のOpenRTM-aistでもビルドできるとおもうのですが。
再利用しなければOpenRTM-aistを使う意味があまりないように思います。
それはさておきTwitterのRTCの話に戻ります。
手順を詳しく書いてあるのは良い事なのですが、やることが多いなあって印象です。
もっと簡略化できるのであればした方が良いと思います。
前も言ったと思いますが、少し内容が物足りない印象です。
どうやらTwitter4Jでは特定のツイートに返信することができるみたいなので、@ユーザー名を含むツイートを検索して返信していないツイートのIDと文章をOutPortから出力→簡単な人口無能のプログラムで返答を生成し出力→ツイッターのRTCでそのツイートに返信するとかできればいいかもしれません。はじめてのAIプログラミングという本の6章のサンプルプログラムみたいに形態素を切り出して保存後そこからランダムに文章を生成するだけでもそれなりに面白くはなると思います。
まあ勝手な考えなので無視してください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
それにしても独自のデータ型を使用したRTCなんてレアだと思いますけどね。
個人的な意見ですが、仕様を変更した方が良いと思います。
まあでも確かにAR.Droneを持っていない僕がとやかく言う事ではないですね。
そういえばTwitterのRTCのマニュアルが公開されているみたいです。
それにしてもこの人の名前何て読むんだろう。
なんでOpenRTM-aistのサンプルのOpenCVCameraCompを使わなかったのでしょうね？
他の作品でやたらとKinectを使っている人が多いですが、何故か既存のRTCを使わずに自作している事が多いような気がします。おそらくですが64bit用のOpenRTM-aistを使用しているためだと思います。さきほどのリンク先のRTCは32bit用のOpenRTM-aistを使用しています。32bit用のOpenRTM-aistを一度インストールするか抽出ツールをつかってcoil110.dll、omniDynamic415_vc10_rt.dll、omniORB415_vc10_rt.dll、omnithread34_vc10_rt.dll、RTC110.dllを入手してRTCと同じフォルダにコピーすると動作すると思うのでそうしてください。
というよりソースコードが公開されているのだから64bit用のOpenRTM-aistでもビルドできるとおもうのですが。
再利用しなければOpenRTM-aistを使う意味があまりないように思います。
それはさておきTwitterのRTCの話に戻ります。
手順を詳しく書いてあるのは良い事なのですが、やることが多いなあって印象です。
もっと簡略化できるのであればした方が良いと思います。
前も言ったと思いますが、少し内容が物足りない印象です。
どうやらTwitter4Jでは特定のツイートに返信することができるみたいなので、@ユーザー名を含むツイートを検索して返信していないツイートのIDと文章をOutPortから出力→簡単な人口無能のプログラムで返答を生成し出力→ツイッターのRTCでそのツイートに返信するとかできればいいかもしれません。はじめてのAIプログラミングという本の6章のサンプルプログラムみたいに形態素を切り出して保存後そこからランダムに文章を生成するだけでもそれなりに面白くはなると思います。
まあ勝手な考えなので無視してください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
これは少し困りましたね。
win32comでMS OfficeのRTCをPythonに移植しようと思ったのですけど、どうやらメインスレッドからしか関数を使用できないらしくonExecute等ではWord、Excel等の操作はできないかもしれない可能性が出てきました。いきなり計画が頓挫しそうになっています。なにかいい方法を知っている人がいたら教えてください。
とりあえず最優先事項は関数、変数、クラス名の修正なのでそれに集中します。
それだけでも1週間はかかりそうですが。
そう言えばAR.DroneのRTCのコメントの返信があったみたいです。
丁重にお礼を書いていますが、そう言う事ではなくて個人的な興味として独自のデータ型を使う理由を知りたいのですけど、何かずれていますね。もう一回コメント書いておきました。
それから地図作成のRTCのコメントにも返信があったようですが、だいたい質問の意図は分かってもらえたみたいです。
それにしても、他の参加者はコメントを貰って嬉しくないのですかね？
僕なんか一昨日コメントを確認して凄いテンションが上がったのですけど。
昨日いいねが1つ増えていた事ぐらいでもその場で奇声を発するぐらいなんですけど。
いやそれはさすがに嘘ですけど、そのぐらい嬉しいという事です。
まだ以下の作品の感想を書いていません。
というよりこのデータポートは名前から察するに目標値を出力していると思っていたのですが、それならTimedDoubleSeq等になるかとおもうのですが、そもそもGoalSetがなんでint型なのかも謎ですね。いやでもそもそも移動ロボットならTimedPose2D型とかの方が良いのでは？とか思ったりします。
あと、compare = compare + abs( GoalSet[i][j] - (int)m_ResultSetIn.data[1+4*i+j])の所で目標点に到達したかを判定していると思いますが、なんでint型にしているのかがわかりません。m_ResultSetInの値の単位は何なのでしょうね？
既に謎だらけなのでマニュアルを読んでみたいです。
4の作品はマニュアルは公開されているようなので読んでみたのですが、あまり再利用性が高いようには思えません。なんでTransformationというRTCでTimedLongSeqに変換しているのかわかりません。なんというかこの作品のRTC群だけで完結している印象で、他のRTCと組み合わせられるように思えません。ならばOpenRTM-aistを使う意味があまりないように思うのですが。
後は全てのソースコード、マニュアルが公開されてから感想は書くようにします。
今見るとスクリーンショットを設定していない作品が多いので後で怒られそうですね。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
win32comでMS OfficeのRTCをPythonに移植しようと思ったのですけど、どうやらメインスレッドからしか関数を使用できないらしくonExecute等ではWord、Excel等の操作はできないかもしれない可能性が出てきました。いきなり計画が頓挫しそうになっています。なにかいい方法を知っている人がいたら教えてください。
とりあえず最優先事項は関数、変数、クラス名の修正なのでそれに集中します。
それだけでも1週間はかかりそうですが。
そう言えばAR.DroneのRTCのコメントの返信があったみたいです。
丁重にお礼を書いていますが、そう言う事ではなくて個人的な興味として独自のデータ型を使う理由を知りたいのですけど、何かずれていますね。もう一回コメント書いておきました。
それから地図作成のRTCのコメントにも返信があったようですが、だいたい質問の意図は分かってもらえたみたいです。
それにしても、他の参加者はコメントを貰って嬉しくないのですかね？
僕なんか一昨日コメントを確認して凄いテンションが上がったのですけど。
昨日いいねが1つ増えていた事ぐらいでもその場で奇声を発するぐらいなんですけど。
いやそれはさすがに嘘ですけど、そのぐらい嬉しいという事です。
まだ以下の作品の感想を書いていません。
- 低価格患者見守りシステムの開発
- 複数台の移動ロボットを対象とした経路計画法の検証用RTC
- ロボットとインタラクションを行うためのつま先の位置推定コンポーネント
- コサイン類似度を用いた日常動作認識のためのテンプレート作成および動作認識RTコンポーネント群
- OpenRTMにより複数台Kinectを連携させた室内人物位置計測コンポーネント
というよりこのデータポートは名前から察するに目標値を出力していると思っていたのですが、それならTimedDoubleSeq等になるかとおもうのですが、そもそもGoalSetがなんでint型なのかも謎ですね。いやでもそもそも移動ロボットならTimedPose2D型とかの方が良いのでは？とか思ったりします。
あと、compare = compare + abs( GoalSet[i][j] - (int)m_ResultSetIn.data[1+4*i+j])の所で目標点に到達したかを判定していると思いますが、なんでint型にしているのかがわかりません。m_ResultSetInの値の単位は何なのでしょうね？
既に謎だらけなのでマニュアルを読んでみたいです。
4の作品はマニュアルは公開されているようなので読んでみたのですが、あまり再利用性が高いようには思えません。なんでTransformationというRTCでTimedLongSeqに変換しているのかわかりません。なんというかこの作品のRTC群だけで完結している印象で、他のRTCと組み合わせられるように思えません。ならばOpenRTM-aistを使う意味があまりないように思うのですが。
後は全てのソースコード、マニュアルが公開されてから感想は書くようにします。
今見るとスクリーンショットを設定していない作品が多いので後で怒られそうですね。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
現在昨日のコメントで言われた通り関数名を修正中です。
それからWin32comを使ってWordを操作するRTCを試しに作っている所です。
しかしそれをするにはOOoとの共通部分を別ファイルに分けた方が便利なのですが、その作業がかなり面倒ですね。
多分ソフトウェアの更新には3週間ぐらいかかるかなと思っています。
それにしてもソースコードを公開していないのに作品公開のメールを送った人がいるようですが、一体どういう意図なんでしょうね？
何か不測の事態でも生じたのかもしれません。
他の作品のコメントを読んでいて思ったのですが、定量的なデータ等がないからそういう事を書かれるのかな？とは思います。多分予稿原稿には書いてあるのでしょうけど。
この作品のコメントに関してですが画像データを通信するのに時間がかかるのは事実なので共有メモリを使う事自体は間違っていないとは思うのですけど、どの程度効果があるのかがわからないですね。実際画像処理に時間がかかるのであって通信にかかる時間は微々たる時間じゃないかなとは思います。既存のRTCと接続できる利点を捨ててまで共有メモリを使う必要があるのかと言えば怪しいと思います。ちなみに「共有メモリを使う必然性は何なのでしょうか？」の質問の意図としては、リアルタイム制御では時間がかかりやすいプロセス間通信は避けるべきなのですが、あの作品はリアルタイムではないので共有メモリを使用する必要がないかもしれないとかいう事だとは思います。
この作品のコメントに関しては、おそらく制作者側の意図としてはresult_checkというRTCがあらかじめ設定した値より大きなデータが入力されたときに正しいかどうかをユーザーに確認するシステムだと言いたいのだとは思いますが、「動作確実性の向上」と言われれば何か不測の事態が起きた時に自動的に修正するように制御するのかと思ってもおかしくはないですね。
そもそも動作確実性とはなんでしょうか？誤動作の確率が下がるという意味でしょうかね？でもresult_checkというRTCはデータの大小しか判断していないわけで後の確認は人任せなので動作確実性が向上するかどうかはわかりません。まあ単純にタイトルの問題なので個人的にはどうでもいいのですが。
個人的な意見ですが独自のデータ型を使うのは嫌いですし、RTC同士がお互い接続の必要があるにもかかわらず分割するのも好きではありません。
AR.DroneのRTCのページに「何故独自のデータ型をつかうのか？」とコメントして数日たつのですが、まだ返信は無いようです。独自のデータ型についてはこのページに詳しく書いてあるようですが、「オレオレデータ型は作ってはいけません」と書いてあります。正直なところ僕にはこの作品のデータ型が「オレオレデータ型」にしか思えないのでぜひとも意見を聞きたいのですが。MIDIのRTCは独自のデータ型を使うのも仕方ないと思います。他で代用するのは無理だと思うので。
あと地図作成のRTC群はなんでこんなにRTCを分割してしまったのかが謎です。
おそらくGUIはJavaで作りたくて他はC++で作成したかったとかそんな理由だとは思いますが、別にC++でもGUIはプログラミングできるのでそれは制作者側の理由でユーザー側からしたら使いづらいだけです。RTCの設計指針についてはこのページに詳しく書いてありますが、「細かすぎる粒度は再利用性を（間接的にですが）著しく下げます．」と書いてあります。全く同意見です。とりあえずコメントは書いておいたので返信待ちです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
それからWin32comを使ってWordを操作するRTCを試しに作っている所です。
しかしそれをするにはOOoとの共通部分を別ファイルに分けた方が便利なのですが、その作業がかなり面倒ですね。
多分ソフトウェアの更新には3週間ぐらいかかるかなと思っています。
それにしてもソースコードを公開していないのに作品公開のメールを送った人がいるようですが、一体どういう意図なんでしょうね？
何か不測の事態でも生じたのかもしれません。
他の作品のコメントを読んでいて思ったのですが、定量的なデータ等がないからそういう事を書かれるのかな？とは思います。多分予稿原稿には書いてあるのでしょうけど。
この作品のコメントに関してですが画像データを通信するのに時間がかかるのは事実なので共有メモリを使う事自体は間違っていないとは思うのですけど、どの程度効果があるのかがわからないですね。実際画像処理に時間がかかるのであって通信にかかる時間は微々たる時間じゃないかなとは思います。既存のRTCと接続できる利点を捨ててまで共有メモリを使う必要があるのかと言えば怪しいと思います。ちなみに「共有メモリを使う必然性は何なのでしょうか？」の質問の意図としては、リアルタイム制御では時間がかかりやすいプロセス間通信は避けるべきなのですが、あの作品はリアルタイムではないので共有メモリを使用する必要がないかもしれないとかいう事だとは思います。
この作品のコメントに関しては、おそらく制作者側の意図としてはresult_checkというRTCがあらかじめ設定した値より大きなデータが入力されたときに正しいかどうかをユーザーに確認するシステムだと言いたいのだとは思いますが、「動作確実性の向上」と言われれば何か不測の事態が起きた時に自動的に修正するように制御するのかと思ってもおかしくはないですね。
そもそも動作確実性とはなんでしょうか？誤動作の確率が下がるという意味でしょうかね？でもresult_checkというRTCはデータの大小しか判断していないわけで後の確認は人任せなので動作確実性が向上するかどうかはわかりません。まあ単純にタイトルの問題なので個人的にはどうでもいいのですが。
個人的な意見ですが独自のデータ型を使うのは嫌いですし、RTC同士がお互い接続の必要があるにもかかわらず分割するのも好きではありません。
AR.DroneのRTCのページに「何故独自のデータ型をつかうのか？」とコメントして数日たつのですが、まだ返信は無いようです。独自のデータ型についてはこのページに詳しく書いてあるようですが、「オレオレデータ型は作ってはいけません」と書いてあります。正直なところ僕にはこの作品のデータ型が「オレオレデータ型」にしか思えないのでぜひとも意見を聞きたいのですが。MIDIのRTCは独自のデータ型を使うのも仕方ないと思います。他で代用するのは無理だと思うので。
あと地図作成のRTC群はなんでこんなにRTCを分割してしまったのかが謎です。
おそらくGUIはJavaで作りたくて他はC++で作成したかったとかそんな理由だとは思いますが、別にC++でもGUIはプログラミングできるのでそれは制作者側の理由でユーザー側からしたら使いづらいだけです。RTCの設計指針についてはこのページに詳しく書いてありますが、「細かすぎる粒度は再利用性を（間接的にですが）著しく下げます．」と書いてあります。全く同意見です。とりあえずコメントは書いておいたので返信待ちです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
