ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
僕の勝手な考えなのですが、どうにも最初からRTCで実装しようとすると失敗するのではないかと思います。
まずは単一のプログラムで実装する事を目指して、それから切り離せる部分は切り離していけばいいのではないですかね?何だか似たような事を言ったような記憶がありますけど。
やりがちな失敗として他のRTCに依存しすぎるという事があります。
そもそもコンポーネント指向の基本として「コンポーネント間の依存を少なくする」と言う事があると思います。
「はじめてのコンポーネント指向ロボットアプリケーション開発 ~RTミドルウェア超入門~」ではやたらとこの点を押してきます。RTM関連の人は大抵この本を読んでいると思うので、分かっていても間違うのだから難しい部分ではあります。
よくこんな感じでRTC同士が沢山のコネクタで接続されている事例がありますが、こうなってしまったら少し考えた方が良いかもしれません。片方のRTCがもう片方のRTCへの依存が大きいために起こったのかもしれません。
ただまあこんな感じの場合はやむ負えないかもしれないです。
この場合は9軸センサRTCの加速度、地磁気、角速度は個別に使う事も可能なので特に問題はないです。
こういうGUI上でマウスを操作してその位置などを送信して処理をするというRTシステムをたまに見ますけど、これはどうかと思いました。この例はかなり簡略化していますが、実際はもっと複雑だったと思います。
そもそもGUIは特定のシステム専用に作られている事が多いので再利用性は低いです。これでRTC2の再利用性が高ければ問題ありませんが、再利用性の低いGUIのRTCへの依存が大きい時点でRTC2の再利用性も低いと思います。
接続するコネクタ数が1~2つならまだ我慢できますけど、それ以上になると再利用するときに接続が面倒なだけです。おそらく拡張性を高めるためにRTCで分割したのでしょうけど、常に3本以上のポートを接続するRTCを起動する事を強いられると考えると逆効果です。
なので最初に言った通り、まずは一つのプログラムで実装する事を目指しましょう。
最初からRTCで実装しようとすると失敗します。
RTM講習会って四国では一回もやった事ないみたいですけど、ちょっと冷遇しすぎだと思います。完全な空白地帯になっているので、気が向いたらやってください。できれば愛媛で。
RTMコンテスト2015の作品が投稿されているみたいです。
ダウンロードするときにやたらと重かったのですけど、VSのsdfファイルを入れるのはどうかと思います。でも実行ファイルはちゃんと削除しているんだよなあ。
あとは何でもグローバル変数で書くのは個人的には好きではありません。と言うか何でクラス内でしか使っていない変数までグローバルにしているんだ・・・
そして何故KinectCameraの初期化失敗時にRTC_ERRORに遷移するようにしていないのか、何故かKinectDepthではちゃんとエラーに遷移するようになっているので謎です。
JPEG圧縮した画像データを出力するデータポートのデータ型が何故TimedOctetSeqになっているのかも謎です。
コンフィギュレーションパラメータで圧縮形式を変更できるようにして、無圧縮の画像データと同じデータポートから出力すれば良いのではないですかね?
後は受信先で圧縮形式を識別して復元すればいいと思いますけど。
仕様なのかどうかは知りませんけど、KinectDepthのRAWというデータポートって何もデータがない状態で出力されています。
KinectHumanTracking.cppの284行目のIf文ですが、preと言う変数は宣言されてからIf文まで一度も変更していないようなので分岐する意味がありません。と言うかどっちにしても同じ処理をしているように見えます。まあだからと言って何か影響があるかと言えば特にないのですけど。
僕の勘違いでなければ271~283行目の処理は全く意味がないように見えます。そもそもどういう意図で記述したのでしょうか?それに伴ってcommand_img_dataと言う変数も意味がないので188~195行目も必要ありません。なんだか全体的に意図が読み取りづらい印象です。
後はSafeRelease関数が他のソースコードからコピーしたものであれば一応そのソースコードの入手先とライセンスを明記する必要があるとは思います。
まあ数行なので審査には影響しないでしょうし別に誰かに損害を与えるとかいうわけではないですけど、無用なトラブルを避けるためです。
大抵の作品に言える事なのですが、ロジック部分は別ファイルに切り離すのが基本です。
全部onExecuteとかに書くのは少し問題だと思います。
最初からRTCで実装しようとするからこうなるのではないでしょうか?
RTC化する以前にまずは単体のプログラムで動作できる事が重要で、テスト用プログラムでロジック部分をクラスで実装しておけばRTCへの再実装も簡単です。
そのせいか、特にKinectHumanTrackingのソースコードの見通しが悪い感じがします。
このブログで散々言った通り、ソースコードのみで配布はあり得ないなと思います。
こっちでビルドするのは地味に面倒なので、全く使ってもらえない可能性が高いです。
このブログを読んでいないのでしょうか?読んでいるわけないだろ
致命的に大きな問題があるわけではないのですが、一体何が特徴なのかが分かりません。
まだ全容が分からないので何とも言えませんが、奇抜さとか斬新さというものが感じられませんでした。
こういう作品が一番辛い評価になるので、もう少し何か欲しいかなとは思いました。
ちょっと今のままでは受賞は厳しいかなという印象です。
この作品には全く関係はないのですが、去年のコンテストで盗用した作品があった件についてコンテスト運営側から何の説明もないうちに今年の作品が投稿されてしまったことは大変遺憾です。
受賞を取り消さないと決めたのであればそれでもいいのですよ。
ただ何の説明もないのは、非常に後味が悪いです。
このままではあの作品は盗用で賞を取ったという認識になってしまうわけで、もしも違うのであれば否定した方が良いとは思っています。少なくとも僕の中ではそういう認識になっています。
何にせよもう時間がないので、10月中にはお願いします。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
まずは単一のプログラムで実装する事を目指して、それから切り離せる部分は切り離していけばいいのではないですかね?何だか似たような事を言ったような記憶がありますけど。
やりがちな失敗として他のRTCに依存しすぎるという事があります。
そもそもコンポーネント指向の基本として「コンポーネント間の依存を少なくする」と言う事があると思います。
「はじめてのコンポーネント指向ロボットアプリケーション開発 ~RTミドルウェア超入門~」ではやたらとこの点を押してきます。RTM関連の人は大抵この本を読んでいると思うので、分かっていても間違うのだから難しい部分ではあります。
よくこんな感じでRTC同士が沢山のコネクタで接続されている事例がありますが、こうなってしまったら少し考えた方が良いかもしれません。片方のRTCがもう片方のRTCへの依存が大きいために起こったのかもしれません。
ただまあこんな感じの場合はやむ負えないかもしれないです。
この場合は9軸センサRTCの加速度、地磁気、角速度は個別に使う事も可能なので特に問題はないです。
こういうGUI上でマウスを操作してその位置などを送信して処理をするというRTシステムをたまに見ますけど、これはどうかと思いました。この例はかなり簡略化していますが、実際はもっと複雑だったと思います。
そもそもGUIは特定のシステム専用に作られている事が多いので再利用性は低いです。これでRTC2の再利用性が高ければ問題ありませんが、再利用性の低いGUIのRTCへの依存が大きい時点でRTC2の再利用性も低いと思います。
接続するコネクタ数が1~2つならまだ我慢できますけど、それ以上になると再利用するときに接続が面倒なだけです。おそらく拡張性を高めるためにRTCで分割したのでしょうけど、常に3本以上のポートを接続するRTCを起動する事を強いられると考えると逆効果です。
なので最初に言った通り、まずは一つのプログラムで実装する事を目指しましょう。
最初からRTCで実装しようとすると失敗します。
RTM講習会って四国では一回もやった事ないみたいですけど、ちょっと冷遇しすぎだと思います。完全な空白地帯になっているので、気が向いたらやってください。できれば愛媛で。
RTMコンテスト2015の作品が投稿されているみたいです。
ダウンロードするときにやたらと重かったのですけど、VSのsdfファイルを入れるのはどうかと思います。でも実行ファイルはちゃんと削除しているんだよなあ。
あとは何でもグローバル変数で書くのは個人的には好きではありません。と言うか何でクラス内でしか使っていない変数までグローバルにしているんだ・・・
そして何故KinectCameraの初期化失敗時にRTC_ERRORに遷移するようにしていないのか、何故かKinectDepthではちゃんとエラーに遷移するようになっているので謎です。
JPEG圧縮した画像データを出力するデータポートのデータ型が何故TimedOctetSeqになっているのかも謎です。
コンフィギュレーションパラメータで圧縮形式を変更できるようにして、無圧縮の画像データと同じデータポートから出力すれば良いのではないですかね?
後は受信先で圧縮形式を識別して復元すればいいと思いますけど。
仕様なのかどうかは知りませんけど、KinectDepthのRAWというデータポートって何もデータがない状態で出力されています。
KinectHumanTracking.cppの284行目のIf文ですが、preと言う変数は宣言されてからIf文まで一度も変更していないようなので分岐する意味がありません。と言うかどっちにしても同じ処理をしているように見えます。まあだからと言って何か影響があるかと言えば特にないのですけど。
僕の勘違いでなければ271~283行目の処理は全く意味がないように見えます。そもそもどういう意図で記述したのでしょうか?それに伴ってcommand_img_dataと言う変数も意味がないので188~195行目も必要ありません。なんだか全体的に意図が読み取りづらい印象です。
後はSafeRelease関数が他のソースコードからコピーしたものであれば一応そのソースコードの入手先とライセンスを明記する必要があるとは思います。
まあ数行なので審査には影響しないでしょうし別に誰かに損害を与えるとかいうわけではないですけど、無用なトラブルを避けるためです。
大抵の作品に言える事なのですが、ロジック部分は別ファイルに切り離すのが基本です。
全部onExecuteとかに書くのは少し問題だと思います。
最初からRTCで実装しようとするからこうなるのではないでしょうか?
RTC化する以前にまずは単体のプログラムで動作できる事が重要で、テスト用プログラムでロジック部分をクラスで実装しておけばRTCへの再実装も簡単です。
そのせいか、特にKinectHumanTrackingのソースコードの見通しが悪い感じがします。
このブログで散々言った通り、ソースコードのみで配布はあり得ないなと思います。
こっちでビルドするのは地味に面倒なので、全く使ってもらえない可能性が高いです。
このブログを読んでいないのでしょうか?読んでいるわけないだろ
致命的に大きな問題があるわけではないのですが、一体何が特徴なのかが分かりません。
まだ全容が分からないので何とも言えませんが、奇抜さとか斬新さというものが感じられませんでした。
こういう作品が一番辛い評価になるので、もう少し何か欲しいかなとは思いました。
ちょっと今のままでは受賞は厳しいかなという印象です。
この作品には全く関係はないのですが、去年のコンテストで盗用した作品があった件についてコンテスト運営側から何の説明もないうちに今年の作品が投稿されてしまったことは大変遺憾です。
受賞を取り消さないと決めたのであればそれでもいいのですよ。
ただ何の説明もないのは、非常に後味が悪いです。
このままではあの作品は盗用で賞を取ったという認識になってしまうわけで、もしも違うのであれば否定した方が良いとは思っています。少なくとも僕の中ではそういう認識になっています。
何にせよもう時間がないので、10月中にはお願いします。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
この記事にコメントする