ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
RTCはマネージャで動的ライブラリをロードしてRTCを起動する事を基本としています。
この場合、関数やクラス内で使用したグローバル変数は共有されているので複数のRTCを起動すると都合が悪いです。
なので極力使わない事をお勧めします。
初歩的な事ですけど、
静的メンバ変数やシングルトンも同じです。
確かに使った方が便利な場合も多いのですが、使いどころは考えてください。
先ほどの例だと、静的メンバ変数は以下のようになります。
Pythonの場合少し分かりづらいのですが、
では動作が違います。
下のコードはtestValueが静的な変数になっています。
つまりrtcdでRTCを起動する場合にグローバル変数を使うと、別々のRTCから同じ変数が操作される可能性があります。
int testValue;
(中略)
RTC::ReturnCode_t testRTC::onExecute(RTC::UniqueId ec_id)
{
testValue += 1;
}
(以下略)
この場合、testRTC0とtestRTC1を起動したとすると変数testValueは共有されています。
バグの温床になる可能性が高いので注意してください。
やはり盗用の件を放置するのはまずいです。
過去にこういう問題があったにも拘らず充分な対策をしていなかったという事なので、もう一度同じ問題が起きた時の印象が悪いです。
流石に責任を取れと言う事にはならないと思いますけど、印象としては最悪です。
既に今年の作品が公開されてしまっている時点でいつこうなってもおかしくはありません。
しかも盗用をした作者と同じ大学院の人が応募していますね。
それも例の作品の共著者の一部と研究室が同じだったと思います。
まだソースコードは公開されていないみたいですが、問題が発生する可能性が極めて高くなりました。
と言うか去年あんな事があったら普通は参加するのを躊躇うと思うのですが、一体どういう心境なのかを聞いてみたいです。何の処分もなかったので味を占めたという事でしょうか？
仮に例の作品と関係のある研究室だとすれば何の謝罪もなしに参加する事自体が大問題です。
このままRTM自体と関わらないのであればどう責任を取ろうとどうでもよかったのですが、これは癪に障ります。
言い過ぎかもしれませんが、この作品を審査する必要はないとすら思っています。
僕もこの作品のソースコードは読まないつもりです。なのでこの作品に盗用があったとしても僕は知りません。
そもそもあれは作者個人の問題ではありません。
ソースコードを公開する前に確認しなかった管理責任の問題です。
盗用したソースコードが9割近くを占めているのに盗用元の著者が指摘するまで1年近くも気付かなかったというのは常軌を逸しています。
普通は著作権に問題がないかどうかぐらいは確認するわけで、ソースコードのほとんどに問題があるのに気づかないのはただの怠慢です。
なので作者が違ったから盗用はないだろうと考える事はできません。
だいたい、数十人単位の人間に迷惑をかけたという事を理解しているのでしょうか？
コンテスト運営側にしても盗用した作品と関連する研究室にしても、いつ爆発するかわからない爆弾を抱えてしまっている状態です。
ちなみに爆発したらHSPプログラムコンテスト2013みたいになります。
他人事ですけど、こんなことになったら大変ですね。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
この場合、関数やクラス内で使用したグローバル変数は共有されているので複数のRTCを起動すると都合が悪いです。
なので極力使わない事をお勧めします。
初歩的な事ですけど、
#include <stdlib.h>
#include <iostream>
class testClass
{
public:
testClass(int v)
{
testValue = v;
};
void testPrint()
{
std::cout << testValue << std::endl;
}
int testValue;
};
int main()
{
testClass A(10);
testClass B(20);
A.testPrint();
B.testPrint();
return 0;
}
と#include <stdlib.h>
#include <iostream>
int testValue;
class testClass
{
public:
testClass(int v)
{
testValue = v;
};
void testPrint()
{
std::cout << testValue << std::endl;
}
};
int main()
{
testClass A(10);
testClass B(20);
A.testPrint();
B.testPrint();
return 0;
}
では動作が違います。静的メンバ変数やシングルトンも同じです。
確かに使った方が便利な場合も多いのですが、使いどころは考えてください。
先ほどの例だと、静的メンバ変数は以下のようになります。
#include <stdlib.h>
#include <iostream>
class testClass
{
public:
testClass(int v)
{
testValue = v;
};
void testPrint()
{
std::cout << testValue << std::endl;
}
static int testValue;
};
int testClass::testValue;
int main()
{
testClass A(10);
testClass B(20);
A.testPrint();
B.testPrint();
return 0;
}
つまりこの場合も変数testValueの実体は1つしかないので後から初期化したクラスで上書きされます。
シングルトンの場合は以下のようになります。つまりこの場合も変数testValueの実体は1つしかないので後から初期化したクラスで上書きされます。
#include <stdlib.h>
#include <iostream>
class testClass
{
private:
testClass(int v)
{
testValue = v;
};
public:
static testClass& get_instance(int v) {
static testClass inst(v);
return inst;
}
void testPrint()
{
std::cout << testValue << std::endl;
}
int testValue;
};
int main()
{
testClass A = testClass::get_instance(10);
testClass B = testClass::get_instance(20);
A.testPrint();
B.testPrint();
return 0;
}
この場合はクラスの実体が1つしか生成されません。Pythonの場合少し分かりづらいのですが、
# -*- coding: utf-8 -*-
class testClass:
def __init__(self, v):
self.testValue = v
def testPrint(self):
print self.testValue
def main():
A = testClass(10)
B = testClass(20)
A.testPrint()
B.testPrint()
if __name__ == "__main__":
main()
と、
と、
# -*- coding: utf-8 -*-
class testClass:
testValue = 0
def __init__(self, v):
testClass.testValue = v
def testPrint(self):
print self.testValue
def main():
A = testClass(10)
B = testClass(20)
A.testPrint()
B.testPrint()
if __name__ == "__main__":
main()
では動作が違います。
下のコードはtestValueが静的な変数になっています。
つまりrtcdでRTCを起動する場合にグローバル変数を使うと、別々のRTCから同じ変数が操作される可能性があります。
int testValue;
(中略)
RTC::ReturnCode_t testRTC::onExecute(RTC::UniqueId ec_id)
{
testValue += 1;
}
(以下略)
この場合、testRTC0とtestRTC1を起動したとすると変数testValueは共有されています。
バグの温床になる可能性が高いので注意してください。
やはり盗用の件を放置するのはまずいです。
過去にこういう問題があったにも拘らず充分な対策をしていなかったという事なので、もう一度同じ問題が起きた時の印象が悪いです。
流石に責任を取れと言う事にはならないと思いますけど、印象としては最悪です。
既に今年の作品が公開されてしまっている時点でいつこうなってもおかしくはありません。
しかも盗用をした作者と同じ大学院の人が応募していますね。
それも例の作品の共著者の一部と研究室が同じだったと思います。
まだソースコードは公開されていないみたいですが、問題が発生する可能性が極めて高くなりました。
と言うか去年あんな事があったら普通は参加するのを躊躇うと思うのですが、一体どういう心境なのかを聞いてみたいです。何の処分もなかったので味を占めたという事でしょうか？
仮に例の作品と関係のある研究室だとすれば何の謝罪もなしに参加する事自体が大問題です。
このままRTM自体と関わらないのであればどう責任を取ろうとどうでもよかったのですが、これは癪に障ります。
言い過ぎかもしれませんが、この作品を審査する必要はないとすら思っています。
僕もこの作品のソースコードは読まないつもりです。なのでこの作品に盗用があったとしても僕は知りません。
そもそもあれは作者個人の問題ではありません。
ソースコードを公開する前に確認しなかった管理責任の問題です。
盗用したソースコードが9割近くを占めているのに盗用元の著者が指摘するまで1年近くも気付かなかったというのは常軌を逸しています。
普通は著作権に問題がないかどうかぐらいは確認するわけで、ソースコードのほとんどに問題があるのに気づかないのはただの怠慢です。
なので作者が違ったから盗用はないだろうと考える事はできません。
だいたい、数十人単位の人間に迷惑をかけたという事を理解しているのでしょうか？
コンテスト運営側にしても盗用した作品と関連する研究室にしても、いつ爆発するかわからない爆弾を抱えてしまっている状態です。
ちなみに爆発したらHSPプログラムコンテスト2013みたいになります。
他人事ですけど、こんなことになったら大変ですね。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
僕の勝手な考えなのですが、どうにも最初から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月中にはお願いします。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
昨日のモデル図ですが、依存を使った方が良かったかもしれません。
それかブロックで分割する必要もないだろうし、以下のように操作区画で定義しておけばいいかもしれないです。
後はアクティビティ図とかで動作を表現しておけば何をしたいかは伝わるのではないでしょうか？
まあそもそもSysMLもUMLも詳しくないのでよく分かりませんけど。
UMLとRTミドルウェアによるモデルベースロボットシステム開発を読んだぐらいの知識しかありません。
以下の小型ロボットアームが発売されるとからしいです。
Maximo
Dobot
7Bot
この手のロボットアームが流行っているのでしょうか？
この中だと、精度重視ならDobot、自由度が欲しいのならば7Bot、特に要求がないのであればMaximoを購入すれば良いのではないでしょうか？
ちなみに既存の製品には以下のようなものがあります。
MeArm
uArm
アカデミックスカラロボット
サインスマート製6自由度ロボットアーム
サインスマート製4自由度ロボットアーム
サインスマート製3自由度ロボットアーム
ロボットアーム DIY キット 4自由度
一覧にしてみるとこんな感じです。
自由度はハンドの自由度を除いたものを載せています。
こうしてみると制御基板はArduinoが多いようです。
この手のロボットアームが流行っているのは、Arduinoが売れている事が要因かもしれないです。
サインスマート製のロボットアームのサービスの悪さと言うか、ハンドも無ェ、マイコンも無ェ、説明書も無ェ、開発環境も無ェ、値段もそれほど安くねェとか吉幾三が歌いだしそうな何もなさです。
この何もないところがいいとは思うのですが、どうでしょうね？
そういえば地味にRTMコンテストの奨励賞が増えてます。
今年のコンテストを進める前にやるべきことがあると思うのですが。
盗用の件は一体どうするつもりでしょうか？
まずはRTMコンテストの応募資格をよく読んでください。
「市販製品や他のオープンソースなどのライブラリを利用する場合は、それを明示するとともに利用者にその入手先が分かるようにしてください。」とあります。
つまりこれを守れていない時点で応募資格はないわけで、当然のことながら受賞資格もありません。
僕も受賞を取り消せとまでは言いません。他のコンテストなら受賞を取り消しているとは思っていますけど。
①どのような不正行為だったか？②なぜ受賞を取り消さないのか？③審査にミスはあったのか？の3点をコンテスト参加者も含めた関係者に説明してほしいだけです。
特に不正行為については以下の4つについて正確に説明してください。
受賞が取り消される明確な理由があるわけで、受賞を取り消さないのであればそれなりの説明が必要です。①、③はともかくとして、②に関しては説明する義務があります。
そもそも参加者も含めた関係者のほとんどが盗用があったこと自体を知らないと思います。
このことを知ったらどう思うのでしょうね？
このブログを読んでもらったら分かる通りこの件に関しては僕は相当頭にきています。
まあでも「終わった話だと思っている」と以前の記事で言ったので、受賞取り消しとか何らかの処分までしろとは言いません。
コンテスト運営側と本人との間で話がついているのであれば、それはそれでもいいです。
本人が報告する必要はないと判断したのなら、それはそれでもいいです。別に責めるつもりはありません。この作者の所属する研究室や大学院は二度と信用しませんけど。
ただ、後味が悪いのでコンテスト運営側の人の説明を聞いてみたいのと、今年のコンテストの参加者に対しての注意喚起のために説明が必要ではないかと思っているだけです。
なのでこれ以上事を荒立てたいというわけではありません。
盗用の件に関しては終わった話だと思っています。
作者本人からコンテスト関係者へ経緯の説明や謝罪をしろと言っているわけでもありません。あれは本人の判断に任せると言ったので、もう作者はどうでもいいです。好きなようにしてください。
ただコンテスト運営側の人から説明をしてほしいだけです。
つまりもうあの作品の作者は関係なくて、僕とコンテスト運営側の人との問題です。
もしかしてコンテスト運営側の誰もこの問題を把握していないという可能性もあるのでしょうか？
産総研からアクセスが何度かあったので知られていると思っていましたが、全く関係なかったかもしれないです。
僕は通報しないと言ったので、伝える方法がありません。
これで今年も同じ問題が起こったらどうしましょうね？
そもそも僕があの作品のソースコードの判別ができたのはまぐれなので、また同じ手口の作品が出てきたら今度こそは判別不能です。
どういう経緯で判別できたかと言うと、まずドローンのライブラリについて色々調べていたらたまたま盗用元のソースコードを発見しました。そしてあの作品を見たところ、ライセンスファイルが同封されていると勘違いをしました。この作品のライセンスファイルの名前と似ていて中身が一緒だったのでしばらく気づきませんでした。つまり成りすまし行為に気づくこともなかったので結果的に騙されることもありませんでした。それからマニュアルは真面目に読まなかったのでどっかに使用したことは明記してあるだろうと思っていました。実際はどこにも書いていませんでした。
つまり盗用元のソースコードを偶然見つけたのと勘違いが重なった事で偶然判別できたのであって、普通は判別できません。
これが著者が一人ならRTCの部分だけ雑なので気づくかもしれませんが、著者が複数の場合はソースコードごとに大きな質の差があるかもしれないので気づきません。
とりあえず既にどこかで公開されているソースコードと同じものが同梱されていて、さらにその元のソースコードが違う人間によってアップロードされている場合は要注意です。
もちろん一人でGitHubのアカウントを2つ持っている、もしくは著者が複数の場合で各個人がアカウントを持っている場合がある、もしくは元の作者から直接許可を貰っている場合があるので確実ではありませんけど。
そもそも審査されると分かっていてそんな紛らわしい事する時点でおかしいので騙されるのは仕方ないというか、むしろ騙されるのが普通です。僕だって勘違いがなければ判別できていませんでした。
結局のところ盗用かどうかを判別するには常に疑ってかかるしかないわけで、僕だったらあまりやりたくないです。僕は審査しないので騙されようが関係ないですけど。
受賞の取り消しは要求しませんけど、これで取り消さなかったら今年のコンテストから大変になりそうです。他の人のソースコードを盗用する行為が正当化されるわけですから、やりたい放題になります。後で盗用が発覚しても文句を言われる筋合いはありません。盗用元の著者が話の分かる人だったらそれで何も起こらずに終了です。
要は11月1日から12月14日までに盗用したソースコードを使っている事が審査員にバレなければ大丈夫と言う事になります。その間に万が一に盗用元の著者にバレても審査員が気付かなければ大丈夫です。できれば盗用するソースコードはRTMと関係ないものにしましょう。その点ドローン操作のソースコードを盗用してそのRTCを作ったのは発想としては良かったと思います。人としては駄目ですけど。12月14日を過ぎれば盗用元の作者に怒られないように修正しておきましょう。公開したソースコードを全て削除してもいいかもしれません。11月1日から1か月半は緊張しますが、それぐらいなら発覚しない可能性が高いです。現にソースコードの9割近くが盗用でも10ヶ月も発覚しなかった事例があるわけで、案外バレないものです。と言うか10ヶ月も発覚しなかった時点でほとんど人が来なかった、つまり使った人はおそらく誰もいないという事だと思うので、この結果が本当の評価なのだと思います。
流石にこんな人が何人も出てくるという事態はないとは思いますけど、一人出てきただけでかなりまずいですからね。
まあ僕が知りたいのは受賞を取り消すのかどうかではなくてその理由なので、この記事を読んでいるようであれば説明をしてください。忙しいとは思いますが、10月中ぐらいにはお願いします。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
それかブロックで分割する必要もないだろうし、以下のように操作区画で定義しておけばいいかもしれないです。
後はアクティビティ図とかで動作を表現しておけば何をしたいかは伝わるのではないでしょうか？
まあそもそもSysMLもUMLも詳しくないのでよく分かりませんけど。
UMLとRTミドルウェアによるモデルベースロボットシステム開発を読んだぐらいの知識しかありません。
以下の小型ロボットアームが発売されるとからしいです。
Maximo
Dobot
7Bot
この手のロボットアームが流行っているのでしょうか？
この中だと、精度重視ならDobot、自由度が欲しいのならば7Bot、特に要求がないのであればMaximoを購入すれば良いのではないでしょうか？
ちなみに既存の製品には以下のようなものがあります。
MeArm
uArm
アカデミックスカラロボット
サインスマート製6自由度ロボットアーム
サインスマート製4自由度ロボットアーム
サインスマート製3自由度ロボットアーム
ロボットアーム DIY キット 4自由度
一覧にしてみるとこんな感じです。
自由度はハンドの自由度を除いたものを載せています。
| 名前 | 自由度 | 制御基板 | ハンド | 価格 |
| MeArm | 3 | MeBrain(Arduino互換) | はさみ型 | 15,000円(10,800円という情報もある) |
| uArm | 4 | Arduino+Uduino(特製シールド) | 吸引式、はさみ型 | 42,800円？ |
| アカデミックスカラロボット | 4 | 不明 | はさみ型、ペン固定 | 41,040円 |
| サインスマート製6自由度ロボットアーム | 6 | なし | なし | 21,500円 |
| サインスマート製4自由度ロボットアーム | 4 | なし | なし | 15,800円 |
| サインスマート製3自由度ロボットアーム | 2 | なし | はさみ型 | 7,500円 |
| ロボットアーム DIY キット 4自由度 | 3 | (多分)なし | はさみ型 | 3,980円 |
| Maximo | 4 | Arduino | はさみ型、荷台、ペン固定 | 23,500～35,000円？ |
| Dobot | 3 | Arduino Mega 2560 | はさみ型、ペン固定 | 60,000～96,000円？ |
| 7Bot | 6 | Arduino | はさみ型、ペン固定 | 41,800円？ |
こうしてみると制御基板はArduinoが多いようです。
この手のロボットアームが流行っているのは、Arduinoが売れている事が要因かもしれないです。
サインスマート製のロボットアームのサービスの悪さと言うか、ハンドも無ェ、マイコンも無ェ、説明書も無ェ、開発環境も無ェ、値段もそれほど安くねェとか吉幾三が歌いだしそうな何もなさです。
この何もないところがいいとは思うのですが、どうでしょうね？
そういえば地味にRTMコンテストの奨励賞が増えてます。
今年のコンテストを進める前にやるべきことがあると思うのですが。
盗用の件は一体どうするつもりでしょうか？
まずはRTMコンテストの応募資格をよく読んでください。
「市販製品や他のオープンソースなどのライブラリを利用する場合は、それを明示するとともに利用者にその入手先が分かるようにしてください。」とあります。
つまりこれを守れていない時点で応募資格はないわけで、当然のことながら受賞資格もありません。
僕も受賞を取り消せとまでは言いません。他のコンテストなら受賞を取り消しているとは思っていますけど。
①どのような不正行為だったか？②なぜ受賞を取り消さないのか？③審査にミスはあったのか？の3点をコンテスト参加者も含めた関係者に説明してほしいだけです。
特に不正行為については以下の4つについて正確に説明してください。
- 人のソースコードと自分のソースコードを極めて混同しやすい形で同梱していた
- 人のソースコードを再配布したにもかかわらずライセンスファイルを同封していなかった
- マニュアルなどに人のソースコードを使用したことを一切記載していなかった
- 自分のライセンスファイルに人の名前を書いて成りすまし行為をしていた
受賞が取り消される明確な理由があるわけで、受賞を取り消さないのであればそれなりの説明が必要です。①、③はともかくとして、②に関しては説明する義務があります。
そもそも参加者も含めた関係者のほとんどが盗用があったこと自体を知らないと思います。
このことを知ったらどう思うのでしょうね？
このブログを読んでもらったら分かる通りこの件に関しては僕は相当頭にきています。
まあでも「終わった話だと思っている」と以前の記事で言ったので、受賞取り消しとか何らかの処分までしろとは言いません。
コンテスト運営側と本人との間で話がついているのであれば、それはそれでもいいです。
本人が報告する必要はないと判断したのなら、それはそれでもいいです。別に責めるつもりはありません。この作者の所属する研究室や大学院は二度と信用しませんけど。
ただ、後味が悪いのでコンテスト運営側の人の説明を聞いてみたいのと、今年のコンテストの参加者に対しての注意喚起のために説明が必要ではないかと思っているだけです。
なのでこれ以上事を荒立てたいというわけではありません。
盗用の件に関しては終わった話だと思っています。
作者本人からコンテスト関係者へ経緯の説明や謝罪をしろと言っているわけでもありません。あれは本人の判断に任せると言ったので、もう作者はどうでもいいです。好きなようにしてください。
ただコンテスト運営側の人から説明をしてほしいだけです。
つまりもうあの作品の作者は関係なくて、僕とコンテスト運営側の人との問題です。
もしかしてコンテスト運営側の誰もこの問題を把握していないという可能性もあるのでしょうか？
産総研からアクセスが何度かあったので知られていると思っていましたが、全く関係なかったかもしれないです。
僕は通報しないと言ったので、伝える方法がありません。
これで今年も同じ問題が起こったらどうしましょうね？
そもそも僕があの作品のソースコードの判別ができたのはまぐれなので、また同じ手口の作品が出てきたら今度こそは判別不能です。
どういう経緯で判別できたかと言うと、まずドローンのライブラリについて色々調べていたらたまたま盗用元のソースコードを発見しました。そしてあの作品を見たところ、ライセンスファイルが同封されていると勘違いをしました。この作品のライセンスファイルの名前と似ていて中身が一緒だったのでしばらく気づきませんでした。つまり成りすまし行為に気づくこともなかったので結果的に騙されることもありませんでした。それからマニュアルは真面目に読まなかったのでどっかに使用したことは明記してあるだろうと思っていました。実際はどこにも書いていませんでした。
つまり盗用元のソースコードを偶然見つけたのと勘違いが重なった事で偶然判別できたのであって、普通は判別できません。
これが著者が一人ならRTCの部分だけ雑なので気づくかもしれませんが、著者が複数の場合はソースコードごとに大きな質の差があるかもしれないので気づきません。
とりあえず既にどこかで公開されているソースコードと同じものが同梱されていて、さらにその元のソースコードが違う人間によってアップロードされている場合は要注意です。
もちろん一人でGitHubのアカウントを2つ持っている、もしくは著者が複数の場合で各個人がアカウントを持っている場合がある、もしくは元の作者から直接許可を貰っている場合があるので確実ではありませんけど。
そもそも審査されると分かっていてそんな紛らわしい事する時点でおかしいので騙されるのは仕方ないというか、むしろ騙されるのが普通です。僕だって勘違いがなければ判別できていませんでした。
結局のところ盗用かどうかを判別するには常に疑ってかかるしかないわけで、僕だったらあまりやりたくないです。僕は審査しないので騙されようが関係ないですけど。
受賞の取り消しは要求しませんけど、これで取り消さなかったら今年のコンテストから大変になりそうです。他の人のソースコードを盗用する行為が正当化されるわけですから、やりたい放題になります。後で盗用が発覚しても文句を言われる筋合いはありません。盗用元の著者が話の分かる人だったらそれで何も起こらずに終了です。
要は11月1日から12月14日までに盗用したソースコードを使っている事が審査員にバレなければ大丈夫と言う事になります。その間に万が一に盗用元の著者にバレても審査員が気付かなければ大丈夫です。できれば盗用するソースコードはRTMと関係ないものにしましょう。その点ドローン操作のソースコードを盗用してそのRTCを作ったのは発想としては良かったと思います。人としては駄目ですけど。12月14日を過ぎれば盗用元の作者に怒られないように修正しておきましょう。公開したソースコードを全て削除してもいいかもしれません。11月1日から1か月半は緊張しますが、それぐらいなら発覚しない可能性が高いです。現にソースコードの9割近くが盗用でも10ヶ月も発覚しなかった事例があるわけで、案外バレないものです。と言うか10ヶ月も発覚しなかった時点でほとんど人が来なかった、つまり使った人はおそらく誰もいないという事だと思うので、この結果が本当の評価なのだと思います。
流石にこんな人が何人も出てくるという事態はないとは思いますけど、一人出てきただけでかなりまずいですからね。
まあ僕が知りたいのは受賞を取り消すのかどうかではなくてその理由なので、この記事を読んでいるようであれば説明をしてください。忙しいとは思いますが、10月中ぐらいにはお願いします。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
RTシステムの設計についてはこのサイトやこのスライドが参考になると思います。
まずスライドにも書いてありますが、RTCの開発は簡単ではありません。
アーム制御のRTシステムを例にして考察してみます。
最初はできるだけ粒度を細かくしてみます。
まずは共通I/F仕様書にあるものはこれをできるだけ使いましょう。
ロボットアームの制御の場合、一時停止や原点復帰動作等はデータポートよりもサービスポートで指令した方が簡単です。
個人的な考えなので正解とは限りませんが、複数のRTC間で同一のパラメータ(アームの各リンクの長さ等)を共有する事はできるだけ避けるべきだと思います。
例えばCameraImage型で画像の縦横のサイズ等を取得できますが、こういう場合はいいと思います。前々から言っている通り独自のデータ型はできるだけ使うべきではないと思っているので、新規にデータ型を作成してパラメータを共有できるようにするのはやめましょう。
次にサービスポートを使って共有するようにする場合ですが、これもサービスポートを接続するのが面倒くさい、独自にIDLファイルを作成すると通信できるRTCを作るのが面倒くさくなるとか色々デメリットがあって再利用性が下がるので、データポートと同じく既に利用されているものがない場合はサービスポートでパラメータ取得はやめましょう。
コンフィギュレーションパラメータで設定するのは論外で、関連する全てのRTCで設定するのは非常に面倒くさい、設定を間違うかもしれないとかあり得るかもしれないです。
と言うわけで、以下のように逆運動学、順運動学モジュールを同一のモジュールで実装します。
ロボットアーム共通インターフェースにmoveLinearCartesianAbs(ロボット座標系での目標位置指定、直交空間で直線補間)だけではなくmovePTPJointAbs(関節座標で目標位置指定)、さらにmovePTPCartesianAbs(ロボット座標系での目標位置指定、関節空間で直線補間)と言うようなコマンドがあります。
この機能を実装する場合は軌道生成モジュールから直接関節角速度を入力できなければならないと思います。
なので以下のように軌道生成モジュールと運動学モジュールを同一のモジュールで実装します。
統合モジュールとサーボモジュールを単一のモジュールにしてみたのが以下の図です。
このサイトで「製品ごとにRTC化」が適当だと言っていますが、それならばロボットアームも単一の製品なので上の図も正解ではないかと思います。
ただ難しいのはロボットアームに使用しているサーボを制御するRTCが既に開発されている場合で、どちらが正解とは言えません。
ただアームの制御のように速度が要求される処理の場合は粒度を粗いした方が良いとは思います。
最後に粒度を一番粗くした場合は以下のような図になります。
速度が要求される場合はこれがベストなので、これも不正解ではありません。
これ以外だと同期のために複合化する必要がありますが、その手間も省けます。
まあでもこの図はRTシステムとしては正解かもしれませんが、この図を見てどんなシステムなのか理解するには並外れた想像力が必要なので内部ブロック図としては不正解だと思います。
少なくとも他人が見てどんなシステムかを理解するためには上から2番目の図ぐらい詳しく作図する必要があります。ここにSysMLを使ってRTシステムを設計する場合に陥りやすい罠があります。
上から2番目の図の通りの粒度でRTシステムを実装すると間違いなく失敗します。
おそらくモデル図を作るからには他人に見せることもあるのでしょうけど、その図がSysMLとしては間違っていないかもしれないです。そうなると図を確認した人が問題ないと思っても、実装してみたら滅茶苦茶なものが出来上がっているというのはありがちだと思います。
この点は細心の注意を払わなければならない部分です。前にも言いましたが、そもそもSysMLはRTシステムを設計するためのモデリング言語ではありません。
どうにも手順が逆になってしまう事があるのかもしれないです。
上の考察ではまずは粒度の細かいモデル図を作成してそこから粒度を粗くしていきましたが、RTシステムの設計ではまず粒度の粗いシステムを考えてそこから再利用性の高い部分を切り離していくというのが基本ではないかと考えています。あくまで個人的な考えですけど。
このスライドで「最低限、単体で動くプログラムを作る事」が重要だと書いてありますが、テスト用のプログラムから細分化していると動作確認が大変です。ここはある程度まとめてテストできるようにしておいて、そこからRTCに実装するときに切り離していけばいいのではないでしょうか？そもそもクラスを作る時点で分けておけばRTCで分けるのは簡単です。
偉そうに書いていますけど、あまり参考にはしない方が良いかもしれないです。
そういえば結局RTMコンテストの盗用の件はどうなったのでしょうね？
もう賞を取り消せとか厳しい事は言わないので、参加者も含めて関わった人に経緯の説明ぐらいしてほしいです。このままでは審査にミスがあったかもしれないとか疑惑だけが残るので後味が悪いです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
まずスライドにも書いてありますが、RTCの開発は簡単ではありません。
アーム制御のRTシステムを例にして考察してみます。
最初はできるだけ粒度を細かくしてみます。
まずは共通I/F仕様書にあるものはこれをできるだけ使いましょう。
ロボットアームの制御の場合、一時停止や原点復帰動作等はデータポートよりもサービスポートで指令した方が簡単です。
個人的な考えなので正解とは限りませんが、複数のRTC間で同一のパラメータ(アームの各リンクの長さ等)を共有する事はできるだけ避けるべきだと思います。
例えばCameraImage型で画像の縦横のサイズ等を取得できますが、こういう場合はいいと思います。前々から言っている通り独自のデータ型はできるだけ使うべきではないと思っているので、新規にデータ型を作成してパラメータを共有できるようにするのはやめましょう。
次にサービスポートを使って共有するようにする場合ですが、これもサービスポートを接続するのが面倒くさい、独自にIDLファイルを作成すると通信できるRTCを作るのが面倒くさくなるとか色々デメリットがあって再利用性が下がるので、データポートと同じく既に利用されているものがない場合はサービスポートでパラメータ取得はやめましょう。
コンフィギュレーションパラメータで設定するのは論外で、関連する全てのRTCで設定するのは非常に面倒くさい、設定を間違うかもしれないとかあり得るかもしれないです。
と言うわけで、以下のように逆運動学、順運動学モジュールを同一のモジュールで実装します。
ロボットアーム共通インターフェースにmoveLinearCartesianAbs(ロボット座標系での目標位置指定、直交空間で直線補間)だけではなくmovePTPJointAbs(関節座標で目標位置指定)、さらにmovePTPCartesianAbs(ロボット座標系での目標位置指定、関節空間で直線補間)と言うようなコマンドがあります。
この機能を実装する場合は軌道生成モジュールから直接関節角速度を入力できなければならないと思います。
なので以下のように軌道生成モジュールと運動学モジュールを同一のモジュールで実装します。
統合モジュールとサーボモジュールを単一のモジュールにしてみたのが以下の図です。
このサイトで「製品ごとにRTC化」が適当だと言っていますが、それならばロボットアームも単一の製品なので上の図も正解ではないかと思います。
ただ難しいのはロボットアームに使用しているサーボを制御するRTCが既に開発されている場合で、どちらが正解とは言えません。
ただアームの制御のように速度が要求される処理の場合は粒度を粗いした方が良いとは思います。
最後に粒度を一番粗くした場合は以下のような図になります。
速度が要求される場合はこれがベストなので、これも不正解ではありません。
これ以外だと同期のために複合化する必要がありますが、その手間も省けます。
まあでもこの図はRTシステムとしては正解かもしれませんが、この図を見てどんなシステムなのか理解するには並外れた想像力が必要なので内部ブロック図としては不正解だと思います。
少なくとも他人が見てどんなシステムかを理解するためには上から2番目の図ぐらい詳しく作図する必要があります。ここにSysMLを使ってRTシステムを設計する場合に陥りやすい罠があります。
上から2番目の図の通りの粒度でRTシステムを実装すると間違いなく失敗します。
おそらくモデル図を作るからには他人に見せることもあるのでしょうけど、その図がSysMLとしては間違っていないかもしれないです。そうなると図を確認した人が問題ないと思っても、実装してみたら滅茶苦茶なものが出来上がっているというのはありがちだと思います。
この点は細心の注意を払わなければならない部分です。前にも言いましたが、そもそもSysMLはRTシステムを設計するためのモデリング言語ではありません。
どうにも手順が逆になってしまう事があるのかもしれないです。
上の考察ではまずは粒度の細かいモデル図を作成してそこから粒度を粗くしていきましたが、RTシステムの設計ではまず粒度の粗いシステムを考えてそこから再利用性の高い部分を切り離していくというのが基本ではないかと考えています。あくまで個人的な考えですけど。
このスライドで「最低限、単体で動くプログラムを作る事」が重要だと書いてありますが、テスト用のプログラムから細分化していると動作確認が大変です。ここはある程度まとめてテストできるようにしておいて、そこからRTCに実装するときに切り離していけばいいのではないでしょうか？そもそもクラスを作る時点で分けておけばRTCで分けるのは簡単です。
偉そうに書いていますけど、あまり参考にはしない方が良いかもしれないです。
そういえば結局RTMコンテストの盗用の件はどうなったのでしょうね？
もう賞を取り消せとか厳しい事は言わないので、参加者も含めて関わった人に経緯の説明ぐらいしてほしいです。このままでは審査にミスがあったかもしれないとか疑惑だけが残るので後味が悪いです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
4000円で買えるロボットアームがあるらしいです。
もう入門用ならこれでいいのではないですかね？
安いのはいいのですけど、一体どこが開発した製品なのかが謎です。
マニュアルやサンプルプログラムはあるのかないのかも不明です。
この値段なのでホビー用途なのでしょうけど、おそらくこの製品単体では動作できないので誰向けなのかが不明です。
対象年齢8才以上になっていますが、8才ではちょっと厳しいかもしれないです。
製品が手元にないのでよく分かりませんけど。
ものすごく今更ですが、OpenRTM-aistのbeginnersのメーリングリストに投稿されても僕のところにはメールが来ないのですが、ひょっとしてusersとは別に登録する必要があるのでしょうか？
いやでもbegginnersは登録するページがないように見えます。
よく分かりませんが既に登録している人は返信してあげてください。
トピックの一覧をパッと見た感じですが、2～3週間放置されることはざらにあるみたいです。
ならusersの方に送ればすぐに返信が来るとは思うのですけどね。どうせこっちもたまにしかメールは来ないのだから。
あの質問はrtshellを使うか、あるいはこのサイトやこのサイトを参考にしてプログラムを書くか、それかwasanbon等のツールを使うかという方法があると思います。
いやでもrtshellは内部でRTCを操作するプログラムを書いていて、ツール等では内部でrtshellやrtctreeを使っているので結局同じなのですけどね。
複合コンポーネント作成支援ツールのインストーラーを作成しました。
マニュアルのリンクからダウンロードできます。
別にこのツールでもRTCの起動とRTシステムの復元を自動化する事はできるので使ってほしいのですが、動作確認が不十分なので初心者にはお勧めしません。
誰か犠牲動作確認してください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
もう入門用ならこれでいいのではないですかね？
安いのはいいのですけど、一体どこが開発した製品なのかが謎です。
マニュアルやサンプルプログラムはあるのかないのかも不明です。
この値段なのでホビー用途なのでしょうけど、おそらくこの製品単体では動作できないので誰向けなのかが不明です。
対象年齢8才以上になっていますが、8才ではちょっと厳しいかもしれないです。
製品が手元にないのでよく分かりませんけど。
ものすごく今更ですが、OpenRTM-aistのbeginnersのメーリングリストに投稿されても僕のところにはメールが来ないのですが、ひょっとしてusersとは別に登録する必要があるのでしょうか？
いやでもbegginnersは登録するページがないように見えます。
よく分かりませんが既に登録している人は返信してあげてください。
トピックの一覧をパッと見た感じですが、2～3週間放置されることはざらにあるみたいです。
ならusersの方に送ればすぐに返信が来るとは思うのですけどね。どうせこっちもたまにしかメールは来ないのだから。
あの質問はrtshellを使うか、あるいはこのサイトやこのサイトを参考にしてプログラムを書くか、それかwasanbon等のツールを使うかという方法があると思います。
いやでもrtshellは内部でRTCを操作するプログラムを書いていて、ツール等では内部でrtshellやrtctreeを使っているので結局同じなのですけどね。
複合コンポーネント作成支援ツールのインストーラーを作成しました。
マニュアルのリンクからダウンロードできます。
別にこのツールでもRTCの起動とRTシステムの復元を自動化する事はできるので使ってほしいのですが、動作確認が不十分なので初心者にはお勧めしません。
誰か犠牲動作確認してください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
