ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
現在昨日のコメントで言われた通り関数名を修正中です。
それから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の設計指針についてはこのページに詳しく書いてありますが、「細かすぎる粒度は再利用性を（間接的にですが）著しく下げます．」と書いてあります。全く同意見です。とりあえずコメントは書いておいたので返信待ちです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
プロジェクトページにコメントが付きました。
まあこの人どうやら全ての作品にコメントするみたいですけど。
いやでも非常にありがたいです。
そんなに無理に褒めなくてもいいのですけどね。
それにしても少し難しい要求だとは思います。
関数名の付け方が独特なのは薄々指摘されるのではないかと思っていました。
とりあえずMyとかを付けるのをやめます。というよりExcelとCalcで同じ機能の関数は同じ名前に変えた方が良さそうです。
独自のデータポートの定義とはOOoCalcRTC.pyとOOoDrawRTC.pyのMyPortObjectのことですかね？CalcとDrawで内容が違うので無理だと思いますが。ただm_addport、JudgePort等は移動できるので別ファイルに移動します。
実はPythonでExcelを操作しようと思って調べたらpython-excelライブラリというのがあったのですけど、なんだか使い方がよくわからなかったのと3つのパッケージをインストールしなければならないのが気に食わなかったので今の実装方法になりました。とりあえずwin32comをインストールして試してみます。
GPLのコードを分離したいのは山々なんですけどUNOの関数を使ったコードを別ファイルに移動してimportした後使おうとすると何故かエラーが出るので仕方なく同じファイルに書いてあるだけです。できれば移動したいと思っています。
僕の言いたいことはこの人が全て言ってくれそうなので、他の作品へのコメントは今後あまり投稿しないかもしれないです。
コメントに1つ返信があったみたいです。
以前の返信をよく読んでいなかったらしく勘違いをしてしまったのですが、やはりStepwiseCtlCompを起動する必要があったみたいです。訊く前に気付いて良かった。
とりあえずStepwiseECを使う利点もわかったのでこれ以上コメントしないと思います。
ただ、データポートを接続していなかったらif(!InPort.isNew()){STEPWISE_NOTIFY_NO_DATA();の所で再実行し続けるので他のRTCの処理も進まなくなるのでは？と思います。そうだとすると再利用性の低さが問題になりそうですね。まあ通常の実行コンテキストに切り替えれば良いのですが。
他の作品にコメントを2つほど書いてありますがまだ返信はありません。
3日に1回でいいから確認してほしいです。
そりゃ発表当日に質問することもできますけど時間が限られていますからね。
それからRTMコンテスト2014のページに作品一覧が載るようになったみたいなので、投稿されていない作品が何なのかわかりました。低価格患者見守りシステムってどんなものでしょうか？
なんにせよ何らかの機器を使うのは確実だと思うので、動作確認出来る可能性は低そうです。
第一スロットの作品のレベルが異様に高いのですけど、どういう順番なんでしょうね？
奨励賞が増えていますけど僕には関係ないようです。
とりあえずLEDキャンドルのRTCの感想を書きます。
ライセンスを明記していないのですが、iwlib.hとwireless.hがGPLライセンスなのでGPL汚染していると考えられます。GPLライセンスだと明記する必要があります。
マニュアルを読んでみた感じですが、分かりやすい画像等が必要だと思います。
まずovero、summitの説明をしてほしいと思いますし、できれば入手方法まで書いてほしいです。
とりあえずソースコードを読んでみて動作を推測してみます。
getinfo.cppのif(inf_data == 1){～の部分でおそらく他のRTCとの接続を行っているものと考えられます。おそらくですが、shellsフォルダのtest01_1に記述したコマンドを使いたいと思うのですけど、このままではcomが"~/workspace/ledcon/shellstest01_1"という文字列になっているのではないかと思うのですが、動作確認はできませんのでわかりません。
それでtest01_1を見てみたのですが、いろいろと疑問が出てきました。
rtfind localhost > localhost.txtでおそらくlocalhostのコンポーネントを検索して結果をlocalhost.txtに保存しているものと考えられます。
問題は次の行のledcon2が何なのかわかりません。そのような名前のRTCはないようです。
そしてrtconのinとかoutはデータポート名だと思うのですが、そのようなデータポートを持つRTCがないです。
というより誤解があったかもしれないのですが、OveroにOpenRTM-aistをインストールするのだからOveroでネーミングサービスを起動して、そのOveroで起動したRTCはそのネーミングサービスに登録されるものかと思っていたのですが、違うのですかね？
そもそもgetinfoというRTCはOveroそれぞれで起動しているものと考えていたのですが、それも違うとか？
いやそもそもOveroが複数あってそれぞれがLEDキャンドルを動作させるものと思ったのですが、それがまず誤解だったのかもしれません。
今の所どういうシステムなのかが理解できていません。
まだ修正するかもしれないので、それに期待します。
人の作品の感想ばかりを書いてきましたが、まずは自分の作品をなんとかしなければなりません。
というより人のソースコード、マニュアルを読むことで何かヒントが得られるのではないかと思っていたのですが、参考になることはいくつかあったもののなかなか自分のソフトウェアに活かすのは難しいですね。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
まあこの人どうやら全ての作品にコメントするみたいですけど。
いやでも非常にありがたいです。
そんなに無理に褒めなくてもいいのですけどね。
それにしても少し難しい要求だとは思います。
関数名の付け方が独特なのは薄々指摘されるのではないかと思っていました。
とりあえずMyとかを付けるのをやめます。というよりExcelとCalcで同じ機能の関数は同じ名前に変えた方が良さそうです。
独自のデータポートの定義とはOOoCalcRTC.pyとOOoDrawRTC.pyのMyPortObjectのことですかね？CalcとDrawで内容が違うので無理だと思いますが。ただm_addport、JudgePort等は移動できるので別ファイルに移動します。
実はPythonでExcelを操作しようと思って調べたらpython-excelライブラリというのがあったのですけど、なんだか使い方がよくわからなかったのと3つのパッケージをインストールしなければならないのが気に食わなかったので今の実装方法になりました。とりあえずwin32comをインストールして試してみます。
GPLのコードを分離したいのは山々なんですけどUNOの関数を使ったコードを別ファイルに移動してimportした後使おうとすると何故かエラーが出るので仕方なく同じファイルに書いてあるだけです。できれば移動したいと思っています。
僕の言いたいことはこの人が全て言ってくれそうなので、他の作品へのコメントは今後あまり投稿しないかもしれないです。
コメントに1つ返信があったみたいです。
以前の返信をよく読んでいなかったらしく勘違いをしてしまったのですが、やはりStepwiseCtlCompを起動する必要があったみたいです。訊く前に気付いて良かった。
とりあえずStepwiseECを使う利点もわかったのでこれ以上コメントしないと思います。
ただ、データポートを接続していなかったらif(!InPort.isNew()){STEPWISE_NOTIFY_NO_DATA();の所で再実行し続けるので他のRTCの処理も進まなくなるのでは？と思います。そうだとすると再利用性の低さが問題になりそうですね。まあ通常の実行コンテキストに切り替えれば良いのですが。
他の作品にコメントを2つほど書いてありますがまだ返信はありません。
3日に1回でいいから確認してほしいです。
そりゃ発表当日に質問することもできますけど時間が限られていますからね。
それからRTMコンテスト2014のページに作品一覧が載るようになったみたいなので、投稿されていない作品が何なのかわかりました。低価格患者見守りシステムってどんなものでしょうか？
なんにせよ何らかの機器を使うのは確実だと思うので、動作確認出来る可能性は低そうです。
第一スロットの作品のレベルが異様に高いのですけど、どういう順番なんでしょうね？
奨励賞が増えていますけど僕には関係ないようです。
とりあえずLEDキャンドルのRTCの感想を書きます。
ライセンスを明記していないのですが、iwlib.hとwireless.hがGPLライセンスなのでGPL汚染していると考えられます。GPLライセンスだと明記する必要があります。
マニュアルを読んでみた感じですが、分かりやすい画像等が必要だと思います。
まずovero、summitの説明をしてほしいと思いますし、できれば入手方法まで書いてほしいです。
とりあえずソースコードを読んでみて動作を推測してみます。
getinfo.cppのif(inf_data == 1){～の部分でおそらく他のRTCとの接続を行っているものと考えられます。おそらくですが、shellsフォルダのtest01_1に記述したコマンドを使いたいと思うのですけど、このままではcomが"~/workspace/ledcon/shellstest01_1"という文字列になっているのではないかと思うのですが、動作確認はできませんのでわかりません。
それでtest01_1を見てみたのですが、いろいろと疑問が出てきました。
rtfind localhost > localhost.txtでおそらくlocalhostのコンポーネントを検索して結果をlocalhost.txtに保存しているものと考えられます。
問題は次の行のledcon2が何なのかわかりません。そのような名前のRTCはないようです。
そしてrtconのinとかoutはデータポート名だと思うのですが、そのようなデータポートを持つRTCがないです。
というより誤解があったかもしれないのですが、OveroにOpenRTM-aistをインストールするのだからOveroでネーミングサービスを起動して、そのOveroで起動したRTCはそのネーミングサービスに登録されるものかと思っていたのですが、違うのですかね？
そもそもgetinfoというRTCはOveroそれぞれで起動しているものと考えていたのですが、それも違うとか？
いやそもそもOveroが複数あってそれぞれがLEDキャンドルを動作させるものと思ったのですが、それがまず誤解だったのかもしれません。
今の所どういうシステムなのかが理解できていません。
まだ修正するかもしれないので、それに期待します。
人の作品の感想ばかりを書いてきましたが、まずは自分の作品をなんとかしなければなりません。
というより人のソースコード、マニュアルを読むことで何かヒントが得られるのではないかと思っていたのですが、参考になることはいくつかあったもののなかなか自分のソフトウェアに活かすのは難しいですね。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
さっき新たに作品が投稿されたようです。だから、～の開発とか～の実現とか付けないでくれってこのブログで散々言っているのに読んでないのですかね？読んでるわけないだろ
なんだか似たような作品を見たことがあるのですけど、どういう関係なのでしょう？
こういう作品が一番困る印象です。試用したくてもおそらく回路などを自作しなければならないためほとんど使える人はいないと思います。せめて動画を用意してくれれば何をやりたいかぐらいは把握できるのですが。
それにしても締め切りに間に合ったかどうかはどう判断するのでしょうね？
一応プロジェクトページに作成した日時は表示されますが、ソースコードとマニュアルが公開されていたかどうかはわかりません。
既に全作品を一通り見たのだったらコメントぐらいくれてもいいと思うのですけどね。
3つほどコメントの返信を待っているのですが、まだのようですね。
多分ですけど、コメントが付いている事に気づいていないのだと思います。
コメントを確認するにはログインした状態で最近の投稿のページを見ればコメントの付いたページは先頭に表示されるのでわかると思います。
どのOSに対応している作品が多いかを調べてみました。とはいっても作品一覧のページでチラッと見ただけですから合っているかどうかはわかりません。
OpenRTMユーザーってWindowsユーザーとLinuxユーザーが半々ぐらいだろうと思っていたのですが、なにか勘違いしていたかもしれないです。
ロボットを制御するならLinuxというイメージはあると言うか、四足歩行ロボットの制御をやっていたころは実際ART-Linuxを使っていたので固定概念があったかもしれないです。
まあそりゃロボットのほとんどはWindowsで動いているでしょうけどね。
まだ1作品以上は投稿されていないのでどうなるかわからないのではありますが。
次にプログラミング言語です。
Javaは僕も使っていないので何とも思わないのですが、Pythonの人気がないのは少し不満です。
そういえばOpenRTM.NETを使っている人が誰もいませんでしたね。
実は僕は使う予定で、最初はOpenRTM.NETで開発していたのですが動的にデータポートを追加する方法がわからなかったという個人的な理由でOpenRTM-aistで実装してあります。
次にライセンスです。
修正BSD：3
MIT：1
MIT + Apache：1
LGPL、一部GPL：1
不明：9
ソースコード未公開：4
僕以外LGPL、GPLライセンスはいなかったようです。
まあ修正BSDとかMITは比較的緩いのでこのあたりが多いのは良いことだと思います。
最後に配布の方法です。
ソースコードしか入っていない作品があるのですけど、一体どうしてほしいのでしょうか？
それにしてもよく見たらRSNPを使った作品って2つあったようです。
この人たちはどうかはわかりませんが、奨励賞狙いしたのに被ったりしたら相当な計算外ではないのかと思います。
今年は産総研の人は誰も投稿しないのでしょうかね？
ちょっと残念かもしれないです。
全体見た感じですが、一人だけ異彩を放っているとか突出しているとかいうのは今年はないように見えます。まあここ3年ぐらいそんな感じではあるのですが。2010は今考えると異様にレベルが高かったような印象です。
いろいろマニュアルとかソースコードとか読んでいますが、MIDIのRTCは評価が高いのではないかと思い始めました。マニュアルも詳しく書いてあると思いますし。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
なんだか似たような作品を見たことがあるのですけど、どういう関係なのでしょう？
こういう作品が一番困る印象です。試用したくてもおそらく回路などを自作しなければならないためほとんど使える人はいないと思います。せめて動画を用意してくれれば何をやりたいかぐらいは把握できるのですが。
それにしても締め切りに間に合ったかどうかはどう判断するのでしょうね？
一応プロジェクトページに作成した日時は表示されますが、ソースコードとマニュアルが公開されていたかどうかはわかりません。
既に全作品を一通り見たのだったらコメントぐらいくれてもいいと思うのですけどね。
3つほどコメントの返信を待っているのですが、まだのようですね。
多分ですけど、コメントが付いている事に気づいていないのだと思います。
コメントを確認するにはログインした状態で最近の投稿のページを見ればコメントの付いたページは先頭に表示されるのでわかると思います。
どのOSに対応している作品が多いかを調べてみました。とはいっても作品一覧のページでチラッと見ただけですから合っているかどうかはわかりません。
- Windowsのみ：13
- Linuxのみ：4
- Windows、Linux：1
- その他：1
OpenRTMユーザーってWindowsユーザーとLinuxユーザーが半々ぐらいだろうと思っていたのですが、なにか勘違いしていたかもしれないです。
ロボットを制御するならLinuxというイメージはあると言うか、四足歩行ロボットの制御をやっていたころは実際ART-Linuxを使っていたので固定概念があったかもしれないです。
まあそりゃロボットのほとんどはWindowsで動いているでしょうけどね。
まだ1作品以上は投稿されていないのでどうなるかわからないのではありますが。
次にプログラミング言語です。
- C++：12
- Python：1
- C++、Java：4
- C++、Python：2
Javaは僕も使っていないので何とも思わないのですが、Pythonの人気がないのは少し不満です。
そういえばOpenRTM.NETを使っている人が誰もいませんでしたね。
実は僕は使う予定で、最初はOpenRTM.NETで開発していたのですが動的にデータポートを追加する方法がわからなかったという個人的な理由でOpenRTM-aistで実装してあります。
次にライセンスです。
修正BSD：3
MIT：1
MIT + Apache：1
LGPL、一部GPL：1
不明：9
ソースコード未公開：4
僕以外LGPL、GPLライセンスはいなかったようです。
まあ修正BSDとかMITは比較的緩いのでこのあたりが多いのは良いことだと思います。
最後に配布の方法です。
- ソースコード＋CMakeファイル：4
- ソースコード＋CMakeファイル+実行ファイル：3
- ソースコード＋実行ファイル：2
- ソースコード＋プロジェクトファイル：1
- ソースコードのみ：1
- Pythonファイルのみ：1
- VMWareのイメージファイル＋ソースコード＋CMakeファイル：1
- ソースコード＋プロジェクトファイル＋CMakeファイル：1
- ソースコード＋インストーラー＋プロジェクトファイル＋CMakeファイル：1
- ソースコード未公開：4
ソースコードしか入っていない作品があるのですけど、一体どうしてほしいのでしょうか？
それにしてもよく見たらRSNPを使った作品って2つあったようです。
この人たちはどうかはわかりませんが、奨励賞狙いしたのに被ったりしたら相当な計算外ではないのかと思います。
今年は産総研の人は誰も投稿しないのでしょうかね？
ちょっと残念かもしれないです。
全体見た感じですが、一人だけ異彩を放っているとか突出しているとかいうのは今年はないように見えます。まあここ3年ぐらいそんな感じではあるのですが。2010は今考えると異様にレベルが高かったような印象です。
いろいろマニュアルとかソースコードとか読んでいますが、MIDIのRTCは評価が高いのではないかと思い始めました。マニュアルも詳しく書いてあると思いますし。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
せっかくアンケートを作ったのに誰も投票してくれません。
いろいろ手は尽くしたのですがフィードバックは全く得られませんでした。
やはり中身が充実していないと反応もないという事ですかね。
それはさておき今回は以下の作品の感想を書きます。1の作品ですが前書いた感想が適当だったのでもう一度書きます。
なんというかマニュアルが配布されているだけで安心してしまいます。
Port_ctrl.cppのソースコードを読んでいて正直あまり好きな書き方ではないなあとは思いましたが、オーバーライドとか仮想関数を駆使すればもっと面白く書けそうだとしても何だか難しくはなりそうだなあとは思いました。まあどんな方法で書くかなんて正解はないと思いますし。
少し不満があるとすれば、Get_InPort_dataでどのデータ型でもdoubleに変換しているところぐらいですかね。テンプレートを使えば容易に解決できるのではないでしょうか？
ソースコードを読んだ限りでは全体的に完成度は高いと思います。
2の作品なのですが、なんとかRTC起動までできました。
なんだかTwitter4JのJARファイルのクラスパス通さないとエラーがでたのですけど、どうなんでしょうか？
コンフィギュレーションパラメータを見てみると、acccesstoken等よくわからないパラメータが4つありました。Twitter4Jの使い方を調べてみるとアプリケーションの登録をする必要があり、acccess token等はその際に発行されるものだということでした。
いやでもソースコードを見る限りコンフィギュレーションパラメータをどこかで使用した様子はありません。それでさらに調べてみるとtwitter4j.propertiesというファイルに記述できるとのことでした。探してみるとbinフォルダの中にあったのですが、*******となっているので自分で記入しろと言うことなのですかね？ちょっとこれは不親切というか、相当勘のいい人じゃないと動作確認なんてできません。マニュアルは一体どこにあるのでしょうね？
3の作品ですが、凄く頑張っているとは思います。
ただ初心者に厳しいというか、動作確認までのハードルが高すぎます。
一度配布しているソースコードをダウンロードして全てのRTCのビルド、マニュアルの4.2.1～4.2.3の動作例を実行できるまでの時間を測ってほしいです。
4.2.1の例でcontrolPanelのsrcImagePathとmapsManagerのmakeNormSrcImgPathを接続するというところで「え？」って感じになります。おそらくですが画像データが大きいときにコネクタが切断されるとか通信に不具合があるとかいう理由でどこかに保存した画像ファイルのパスを入力するようにしたとかそんなところだと思うのですが、なんだか困惑します。
4.2.1～4.2.3の動作例にしても、ちょっと手順が多すぎるような気がします。
画像を読み込むだけで6つの接続が必要になるとかひょっとしてギャグで言っているのかと思いました。
それならいっそのことcontrolPanel、mapManager、Openpictは単一のRTCの方がよかったかもしれません。OpenPictsのFileNameは実質的にcontrolPanelのopenFilePathとしか接続できないと思いますし、mapManagerはcontrolPanelのGUI無しでは使うことはできないと思います。分割しても実質的に特定のRTCを必要とするのであれば分割する意味がありません。あとimageInpaintのdragedRectも実質的にcontrolPanelのdragedRectangleとしか接続できないと思うので分割する必要性がわかりません。convToLineMapのdragedRectも同様です。
地図モデル作成のためのツールコンポーネント群は単一のRTCでよかったんじゃないの？というのがマニュアルを読んでみての感想です。
そうすれば4.2.1は一つRTCを起動してGUIからファイルを選択するだけで済みます。4.2.2は9つ、4.2.3は6つ接続するだけで済みますし、CMakeとビルドをこちらでする必要があるにしてもRTCが減るので簡単になります。
コメントを書きたいのですが、プロジェクトページにメールで報せてほしいと書いてあります。
僕はちょっと試してみたいだけで別に必要だから使うわけではないので、メールを送ってまで聞こうとする気は起きません。僕が「メールでしか受け付けない」なんて言ったら絶対に何も来ないと思います。ただでさえ何の反応もない状態なのに。
いろいろ文句みたいな事を書いてしまいましたが、個人的にこの作品の評価は高いのですよね。
念のために言っておきますが、あくまで僕の考えとは違うと言っているだけで批判をするつもりはありませんし自分の考えが正しいとは全く思ってません。
それから他の作品のプロジェクトページに投稿したコメントの返信があったようです。
よくわかりませんが、こちらで確認した動作は正しい動作ではないという解釈でいいのですかね？今試してみたところStepwiseCtlCompが起動した状態ならばそうなったのですが、別にそんなこと書いていませんから僕の環境が悪いのかもしれません。詳細なマニュアルがあればその辺も分かるのですが。また返信をくれるみたいなのでその辺をついでに聞いてみます。
実は他の作品すべてのプロジェクトページにコメントを投稿するというノルマを自分に勝手に課していたのですが、無理な感じになってきました。
そもそもこちらに動作できる環境がないのに言うことなんてほとんどないです。
とりあえず後3作品ぐらいにコメントして終わりかなと思っています。
投稿された作品のマニュアルを読んでみての感想なのですが、なかなかこちらで再現するのは難しい作品が多いという印象を持ちました。
まずCMakeとビルドが必要ならその手順とどこに実行ファイルが生成できるのかをマニュアルに書くべきだと思います。それが何のヒントもなしにできるのはかなり手慣れた人だと思います。自分ができるからと人もできるとは思うのはかなり危険な考えです。
あと実行ファイルがあるなら必要なdllも同梱させるか、どうしても同梱できないならマニュアルに入手方法を書いておいてください。使いたくても使えません。
どうにもインストールの方法を書いていないマニュアルが多いと言うか、ただの仕様書になっているような感じです。
もちろん仕様を書くのも大事なのですが、まずは使ってもらうことが第一だと思います。
マニュアルの形式としては以下の4つがありました。
個人的に3はあまり好きではありません。というよりプロジェクトページに直接書いてあるマニュアルで分かりやすいとか詳細に書かれているとかいうのを見たことないような気がします。
マニュアルがあるのかないのかがわからない事があります。
マニュアルがあるならどこで見られるのか分かりやすい所にリンクでも貼っておいてほしいですし、ないならないと書いてほしいです。ないのはかなりまずいのですが、探してしまいますのでマニュアルはないと書いてもらった方がいいです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
いろいろ手は尽くしたのですがフィードバックは全く得られませんでした。
やはり中身が充実していないと反応もないという事ですかね。
それはさておき今回は以下の作品の感想を書きます。1の作品ですが前書いた感想が適当だったのでもう一度書きます。
なんというかマニュアルが配布されているだけで安心してしまいます。
Port_ctrl.cppのソースコードを読んでいて正直あまり好きな書き方ではないなあとは思いましたが、オーバーライドとか仮想関数を駆使すればもっと面白く書けそうだとしても何だか難しくはなりそうだなあとは思いました。まあどんな方法で書くかなんて正解はないと思いますし。
少し不満があるとすれば、Get_InPort_dataでどのデータ型でもdoubleに変換しているところぐらいですかね。テンプレートを使えば容易に解決できるのではないでしょうか？
ソースコードを読んだ限りでは全体的に完成度は高いと思います。
2の作品なのですが、なんとかRTC起動までできました。
なんだかTwitter4JのJARファイルのクラスパス通さないとエラーがでたのですけど、どうなんでしょうか？
コンフィギュレーションパラメータを見てみると、acccesstoken等よくわからないパラメータが4つありました。Twitter4Jの使い方を調べてみるとアプリケーションの登録をする必要があり、acccess token等はその際に発行されるものだということでした。
いやでもソースコードを見る限りコンフィギュレーションパラメータをどこかで使用した様子はありません。それでさらに調べてみるとtwitter4j.propertiesというファイルに記述できるとのことでした。探してみるとbinフォルダの中にあったのですが、*******となっているので自分で記入しろと言うことなのですかね？ちょっとこれは不親切というか、相当勘のいい人じゃないと動作確認なんてできません。マニュアルは一体どこにあるのでしょうね？
3の作品ですが、凄く頑張っているとは思います。
ただ初心者に厳しいというか、動作確認までのハードルが高すぎます。
一度配布しているソースコードをダウンロードして全てのRTCのビルド、マニュアルの4.2.1～4.2.3の動作例を実行できるまでの時間を測ってほしいです。
4.2.1の例でcontrolPanelのsrcImagePathとmapsManagerのmakeNormSrcImgPathを接続するというところで「え？」って感じになります。おそらくですが画像データが大きいときにコネクタが切断されるとか通信に不具合があるとかいう理由でどこかに保存した画像ファイルのパスを入力するようにしたとかそんなところだと思うのですが、なんだか困惑します。
4.2.1～4.2.3の動作例にしても、ちょっと手順が多すぎるような気がします。
画像を読み込むだけで6つの接続が必要になるとかひょっとしてギャグで言っているのかと思いました。
それならいっそのことcontrolPanel、mapManager、Openpictは単一のRTCの方がよかったかもしれません。OpenPictsのFileNameは実質的にcontrolPanelのopenFilePathとしか接続できないと思いますし、mapManagerはcontrolPanelのGUI無しでは使うことはできないと思います。分割しても実質的に特定のRTCを必要とするのであれば分割する意味がありません。あとimageInpaintのdragedRectも実質的にcontrolPanelのdragedRectangleとしか接続できないと思うので分割する必要性がわかりません。convToLineMapのdragedRectも同様です。
地図モデル作成のためのツールコンポーネント群は単一のRTCでよかったんじゃないの？というのがマニュアルを読んでみての感想です。
そうすれば4.2.1は一つRTCを起動してGUIからファイルを選択するだけで済みます。4.2.2は9つ、4.2.3は6つ接続するだけで済みますし、CMakeとビルドをこちらでする必要があるにしてもRTCが減るので簡単になります。
コメントを書きたいのですが、プロジェクトページにメールで報せてほしいと書いてあります。
僕はちょっと試してみたいだけで別に必要だから使うわけではないので、メールを送ってまで聞こうとする気は起きません。僕が「メールでしか受け付けない」なんて言ったら絶対に何も来ないと思います。ただでさえ何の反応もない状態なのに。
いろいろ文句みたいな事を書いてしまいましたが、個人的にこの作品の評価は高いのですよね。
念のために言っておきますが、あくまで僕の考えとは違うと言っているだけで批判をするつもりはありませんし自分の考えが正しいとは全く思ってません。
それから他の作品のプロジェクトページに投稿したコメントの返信があったようです。
よくわかりませんが、こちらで確認した動作は正しい動作ではないという解釈でいいのですかね？今試してみたところStepwiseCtlCompが起動した状態ならばそうなったのですが、別にそんなこと書いていませんから僕の環境が悪いのかもしれません。詳細なマニュアルがあればその辺も分かるのですが。また返信をくれるみたいなのでその辺をついでに聞いてみます。
実は他の作品すべてのプロジェクトページにコメントを投稿するというノルマを自分に勝手に課していたのですが、無理な感じになってきました。
そもそもこちらに動作できる環境がないのに言うことなんてほとんどないです。
とりあえず後3作品ぐらいにコメントして終わりかなと思っています。
投稿された作品のマニュアルを読んでみての感想なのですが、なかなかこちらで再現するのは難しい作品が多いという印象を持ちました。
まずCMakeとビルドが必要ならその手順とどこに実行ファイルが生成できるのかをマニュアルに書くべきだと思います。それが何のヒントもなしにできるのはかなり手慣れた人だと思います。自分ができるからと人もできるとは思うのはかなり危険な考えです。
あと実行ファイルがあるなら必要なdllも同梱させるか、どうしても同梱できないならマニュアルに入手方法を書いておいてください。使いたくても使えません。
どうにもインストールの方法を書いていないマニュアルが多いと言うか、ただの仕様書になっているような感じです。
もちろん仕様を書くのも大事なのですが、まずは使ってもらうことが第一だと思います。
マニュアルの形式としては以下の4つがありました。
- Word
- プロジェクトページに直接記述
- GitHubのReadMe
個人的に3はあまり好きではありません。というよりプロジェクトページに直接書いてあるマニュアルで分かりやすいとか詳細に書かれているとかいうのを見たことないような気がします。
マニュアルがあるのかないのかがわからない事があります。
マニュアルがあるならどこで見られるのか分かりやすい所にリンクでも貼っておいてほしいですし、ないならないと書いてほしいです。ないのはかなりまずいのですが、探してしまいますのでマニュアルはないと書いてもらった方がいいです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
今日は以下の作品の感想を書きます。
なんか動かないなあと思ったらOpenRTM-aist-Javaのバージョンが1.0.0か。
もう面倒なので動作確認はやめておきます。
もう一つ何か機能が欲しいという印象ではありますね。
とりあえずrtc****.logはいらないと思うので消してから配布してほしいです。
2の作品なのですが、当然LeapMotionは持っていないので動作確認はできていません。
というか、この作品もマニュアルは一体どこにあるのでしょうね？
とりあえずLeapMotionData.cppを読んでみました。
LeapのAPIがよくわからないので確証はありませんが、HandList hands = frame.hands()で検出した手の一覧を取得していると思われます。となるとfor (HandList::const_iterator～の部分で検出した全ての手の位置等を出力している事になります。つまり腕が2本検出された状態であれば右腕の位置出力後に左腕の位置が同じデータポートから出力されることになります。個人的な意見ですが、あまり好ましくない仕様だなあと思います。これなら常に右手だけの情報を出力するか、コンフィギュレーションパラメータで右から何番目の腕の情報を出力するかを指定する等した方が良さそうです。
それからせっかく指の位置を出力するAPIがあるのでしたら利用した方が良かったのではないかと思います。
3の作品なのですが、一体どうやって動作確認すれば良いのでしょう？
MIDIParserとMIDIConsoleOutを使ってみても、なにか文字が表示されてるなあぐらいな印象しかありません。多分、MIDIPianoとかいうので動作確認できるとは思うのですが、非公開になっています。MIDIHandBell.pyを読んでみた感じ、onStartupでbell.Bell(self._port[0],～としているのですが、self._port等をコンフィギュレーションパラメータにしている意味ってあるのかな？と思いました。
4の作品もマニュアルがどこにあるのかわかりません。
とりあえずAR_data_outのソースコードを読んでいるのですが、cameraInとcameraOutのデータポートをどこで使っているのかわかりません。それにonExecuteのif(AR_finder(this))で無限ループに入っているのがあまり好ましくないと思います。cameraInから入力した画像からマーカーの姿勢、位置を検出したいのであればARToolKitPlusを使えば簡単に書けたのではないかと思います。
5の作品ですがマニュアルをしっかり書いてある点で評価が高いと思います。
ソフトウェア自体の完成度もソースコードを読んだ感じだと高そうです。
まあHOTMOCKは持っていないので試用できませんが。
HOTMOCKという製品はどのぐらいの人が持っているのでしょうね？
下手すれば審査する方の誰も持っていない可能性もありそうですが。
ソースコードを読んでいるのですが、なかなか難しいです。
想像になるのですがDynamicOutPort、DynamicInPortはaddPortという関数を実行した時点ではRTCにデータポートは追加されておらず、onActivatedのaddInPort(m_DOIn.getName(j+1), m_DOIn.m_port[j+1])で追加されるのだと思います。マニュアルにも書いてありましたがアクティブ化しないとデータポートが追加されません。この仕様はRTシステムエディタの復元機能との相性が悪いと思うのですが、何がベストなのかはわかりません。
それからif(m_DOIn.m_port[portNameList_DO[i]].isNew())となっていますが、それなら前述のonActivateでaddInPortをしたときにDynamicInPortのaddPortを実行してm_portのInPortPtrに追加した方が直感的にソースコードを書けると思うのですが、何故onInitializeであらかじめ一定数追加しておくのかがわかりません。onExecuteのコードも以下のように書けるので簡単だと思うのですが。
for(int i=0;i<m_DOIn.m_port.getSize();i++){
if(m_DOIn.m_port[i].isNew()){
省略
}
}
6の作品ですが、まずMRPTのRTCは以前にあったと思います。もしかして動作しなかったとかそんな所でしょうかね？
マニュアルがあるかどうかはわかりませんが、ソフトウェア自体の完成度は高いと思います。
なので特に言うこともないのですが、VoiceInterfaceのspeech_outは使った様子がないのが気になるのと、VoiceServiceはRTM on Androidを使った方が奨励賞を狙い易くなるので良かったのではないか？と思いました。あとVoiceInterfaceはeSEATを使っても面白いかもしれません。
あまりこういうことは言いたくないのですが、どこかで見たようなRTCばかりであまり新規性があるように思えません。何か新しいアイデアがあったら良かったと思います。
これで感想を書いていない作品はあと4つです。
まあ適当に感想を書いてしまった作品もあるのでもう一度書くものもあると思います。
動作確認できた作品は実はまだ1つしかないわけですが。
やはりインストーラーなり実行ファイルを付属して配布してほしいですし、ライセンス面で可能なら必要なdllも合わせて配布してほしいです。こちらでCMake、ビルドして欲しいのであれば詳細なマニュアルを作ってほしいと思います。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
- Webコンテンツ配信コンポーネント群
- LeapMotionを用いたロボットマニピュレータの操作支援コンポーネント
- 楽器演奏のためのMIDI RTコンポーネント
- HMDを用いたPTカメラのインターネット遠隔操作
- メディアアートコミュニティ実現に向けた RTコンポーネントの開発と提案
- A RTC set of Kobuki
なんか動かないなあと思ったらOpenRTM-aist-Javaのバージョンが1.0.0か。
もう面倒なので動作確認はやめておきます。
もう一つ何か機能が欲しいという印象ではありますね。
とりあえずrtc****.logはいらないと思うので消してから配布してほしいです。
2の作品なのですが、当然LeapMotionは持っていないので動作確認はできていません。
というか、この作品もマニュアルは一体どこにあるのでしょうね？
とりあえずLeapMotionData.cppを読んでみました。
LeapのAPIがよくわからないので確証はありませんが、HandList hands = frame.hands()で検出した手の一覧を取得していると思われます。となるとfor (HandList::const_iterator～の部分で検出した全ての手の位置等を出力している事になります。つまり腕が2本検出された状態であれば右腕の位置出力後に左腕の位置が同じデータポートから出力されることになります。個人的な意見ですが、あまり好ましくない仕様だなあと思います。これなら常に右手だけの情報を出力するか、コンフィギュレーションパラメータで右から何番目の腕の情報を出力するかを指定する等した方が良さそうです。
それからせっかく指の位置を出力するAPIがあるのでしたら利用した方が良かったのではないかと思います。
3の作品なのですが、一体どうやって動作確認すれば良いのでしょう？
MIDIParserとMIDIConsoleOutを使ってみても、なにか文字が表示されてるなあぐらいな印象しかありません。多分、MIDIPianoとかいうので動作確認できるとは思うのですが、非公開になっています。MIDIHandBell.pyを読んでみた感じ、onStartupでbell.Bell(self._port[0],～としているのですが、self._port等をコンフィギュレーションパラメータにしている意味ってあるのかな？と思いました。
4の作品もマニュアルがどこにあるのかわかりません。
とりあえずAR_data_outのソースコードを読んでいるのですが、cameraInとcameraOutのデータポートをどこで使っているのかわかりません。それにonExecuteのif(AR_finder(this))で無限ループに入っているのがあまり好ましくないと思います。cameraInから入力した画像からマーカーの姿勢、位置を検出したいのであればARToolKitPlusを使えば簡単に書けたのではないかと思います。
5の作品ですがマニュアルをしっかり書いてある点で評価が高いと思います。
ソフトウェア自体の完成度もソースコードを読んだ感じだと高そうです。
まあHOTMOCKは持っていないので試用できませんが。
HOTMOCKという製品はどのぐらいの人が持っているのでしょうね？
下手すれば審査する方の誰も持っていない可能性もありそうですが。
ソースコードを読んでいるのですが、なかなか難しいです。
想像になるのですがDynamicOutPort、DynamicInPortはaddPortという関数を実行した時点ではRTCにデータポートは追加されておらず、onActivatedのaddInPort(m_DOIn.getName(j+1), m_DOIn.m_port[j+1])で追加されるのだと思います。マニュアルにも書いてありましたがアクティブ化しないとデータポートが追加されません。この仕様はRTシステムエディタの復元機能との相性が悪いと思うのですが、何がベストなのかはわかりません。
それからif(m_DOIn.m_port[portNameList_DO[i]].isNew())となっていますが、それなら前述のonActivateでaddInPortをしたときにDynamicInPortのaddPortを実行してm_portのInPortPtrに追加した方が直感的にソースコードを書けると思うのですが、何故onInitializeであらかじめ一定数追加しておくのかがわかりません。onExecuteのコードも以下のように書けるので簡単だと思うのですが。
for(int i=0;i<m_DOIn.m_port.getSize();i++){
if(m_DOIn.m_port[i].isNew()){
省略
}
}
6の作品ですが、まずMRPTのRTCは以前にあったと思います。もしかして動作しなかったとかそんな所でしょうかね？
マニュアルがあるかどうかはわかりませんが、ソフトウェア自体の完成度は高いと思います。
なので特に言うこともないのですが、VoiceInterfaceのspeech_outは使った様子がないのが気になるのと、VoiceServiceはRTM on Androidを使った方が奨励賞を狙い易くなるので良かったのではないか？と思いました。あとVoiceInterfaceはeSEATを使っても面白いかもしれません。
あまりこういうことは言いたくないのですが、どこかで見たようなRTCばかりであまり新規性があるように思えません。何か新しいアイデアがあったら良かったと思います。
これで感想を書いていない作品はあと4つです。
まあ適当に感想を書いてしまった作品もあるのでもう一度書くものもあると思います。
動作確認できた作品は実はまだ1つしかないわけですが。
やはりインストーラーなり実行ファイルを付属して配布してほしいですし、ライセンス面で可能なら必要なdllも合わせて配布してほしいです。こちらでCMake、ビルドして欲しいのであれば詳細なマニュアルを作ってほしいと思います。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
