ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
昨日のモデル図ですが、依存を使った方が良かったかもしれません。
それかブロックで分割する必要もないだろうし、以下のように操作区画で定義しておけばいいかもしれないです。
後はアクティビティ図とかで動作を表現しておけば何をしたいかは伝わるのではないでしょうか？
まあそもそも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月中ぐらいにはお願いします。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
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コンテストの盗用の件はどうなったのでしょうね？
もう賞を取り消せとか厳しい事は言わないので、参加者も含めて関わった人に経緯の説明ぐらいしてほしいです。このままでは審査にミスがあったかもしれないとか疑惑だけが残るので後味が悪いです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
以前の記事で言った通りrtresurrectコマンドが動作できないのですが、どうにもrtconコマンドも動作できないらしいです。
つまりポートの接続に問題がある可能性が高いわけですが、調べてみるとrtshellではなくrtctreeに何らかの問題があるみたいです。
それでrtctreeでデータポートを接続するプログラムを作って動作確認してみたところ、utils.pyのdict_to_nvlist関数でエラーが出ているみたいです。
ulils.pyを以前のバージョンのファイルに差し替えたら問題なく動作したので、おそらくutils.pyでの変更が何らかの不具合を引き起こしている可能性が高そうです。
どうやらあのエラーの内容は「omniORBオブジェクトにはanyというアトリビュートはない」と言う意味だったみたいです。
つまり、ulils.pyの上の方に以下のコードを追加すれば動作できます。
import omniORB.any
ひょっとしたらomniORBpyのバージョンの問題かもしれません。
そう思って公式サイトを見てみると、「omniORB-py 4.x 以上が必要となります」と書いてありました。
僕の記憶が正しければOpenRTM-aist-Python-1.1.0-ReleaseのインストーラーでインストールされるomniORBpyは3.7だったような気がします。
つまり手動でomniORBpyとOpenRTM-aist-Pythonをインストールしろと言う事でしょうかね？
とりあえず古いバージョンをインストールするか、あるいはutils.pyを編集するかすればomniORB-py 3系でも動作できます。
おそらくですけど、rtshellが動作できない人が続出すると思います。
omniORBpyのバージョンの問題もそうですが、pipで文字コードエラーが出る問題やC:\Python27\Scriptsに手動でパスを通す必要があるとかないとからしいという問題もあるので、初心者であれば対処できません。
pipは確かに便利なのですけど、初心者にとってはインストーラーでやってくれた方が簡単なんですよね。そもそもコマンドラインでの操作なんてやりたくありません。
とりあえずインストール支援ツールでは古いバージョンをインストールするように変更しておいたので、インストールで躓いた人は使ってほしいです。動作できるかどうかは怪しいですけど。C:\Python27とC:\Python27\Scriptsにも自動的にパスを通すように機能を追加しました。
これで多少はインストールが楽になれば良いのですけど、そもそも動作できるかが謎なので誰か試してください。犠牲になれと言う意味ではありません。ただのお願いです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
つまりポートの接続に問題がある可能性が高いわけですが、調べてみるとrtshellではなくrtctreeに何らかの問題があるみたいです。
それでrtctreeでデータポートを接続するプログラムを作って動作確認してみたところ、utils.pyのdict_to_nvlist関数でエラーが出ているみたいです。
ulils.pyを以前のバージョンのファイルに差し替えたら問題なく動作したので、おそらくutils.pyでの変更が何らかの不具合を引き起こしている可能性が高そうです。
どうやらあのエラーの内容は「omniORBオブジェクトにはanyというアトリビュートはない」と言う意味だったみたいです。
つまり、ulils.pyの上の方に以下のコードを追加すれば動作できます。
import omniORB.any
ひょっとしたらomniORBpyのバージョンの問題かもしれません。
そう思って公式サイトを見てみると、「omniORB-py 4.x 以上が必要となります」と書いてありました。
僕の記憶が正しければOpenRTM-aist-Python-1.1.0-ReleaseのインストーラーでインストールされるomniORBpyは3.7だったような気がします。
つまり手動でomniORBpyとOpenRTM-aist-Pythonをインストールしろと言う事でしょうかね？
とりあえず古いバージョンをインストールするか、あるいはutils.pyを編集するかすればomniORB-py 3系でも動作できます。
おそらくですけど、rtshellが動作できない人が続出すると思います。
omniORBpyのバージョンの問題もそうですが、pipで文字コードエラーが出る問題やC:\Python27\Scriptsに手動でパスを通す必要があるとかないとからしいという問題もあるので、初心者であれば対処できません。
pipは確かに便利なのですけど、初心者にとってはインストーラーでやってくれた方が簡単なんですよね。そもそもコマンドラインでの操作なんてやりたくありません。
とりあえずインストール支援ツールでは古いバージョンをインストールするように変更しておいたので、インストールで躓いた人は使ってほしいです。動作できるかどうかは怪しいですけど。C:\Python27とC:\Python27\Scriptsにも自動的にパスを通すように機能を追加しました。
これで多少はインストールが楽になれば良いのですけど、そもそも動作できるかが謎なので誰か試してください。犠牲になれと言う意味ではありません。ただのお願いです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
rtshellを4にアップグレードしたのですが、どうにもrtresurrectコマンドが動作できません。
他のコマンドは問題なさそうですが、rtresurrectコマンドでは以下のエラーが出ます。
rtresurrect: 'module' object has no attribute 'any'
そもそもどこからこのエラーが出ているのかの見当がつきません。
よく使うコマンドだろうから動作確認をしていないという事はないと思うので、他の環境で再現できるのかも不明です。誰か動作確認してください。
リリースノートを見る限り、rtresurrectコマンドに変更はないみたいなので謎です。
全然関係ないけど、フリーのUML、SysMLモデリングツールのPapyrusの使い方について書こうと思います。
インストールの方法は分かりやすいサイトがあったのでそちらを参考にしてください。
まず最初に、Window→Perspactive→Open Perspactive→Otherを選択して表示されるダイアログでPapyrusを選択してください。
次にFile→New→Papyrus Projectを選択してプロジェクトを新規作成します。
後はSysmlを選択して、適当にプロジェクト名を選択してください。
そしてSelect a Diagram KindでBlock Definition DiagramとInternal Block Diagramにチェックを入れてください。
これでFInishを押すとプロジェクトを作成します。
次にブロック定義図を適当に編集します。
右のリストのModelElementsからブロックを選択して適当に並べてください。
左のModel ExplorerからBlock1を選択してエディタ上にドラッグ＆ドロップしてください。
そして右のリストのAssociationsからコンポジションを選択して、以下のように線を引いてください。
次に内部ブロック図を編集します。
先ほどコンポジションを作成したときに左のModel ExplorerのBlock1の下にBlock2とBlock3のパートが追加されていると思うので、それらをドラッグ＆ドロップしてください。
後は適当にフローポートやコネクタを追加してください。
困ったのがインターフェースを追加したときで、UMLのコンポーネント図だと以下のようにロリポップで表示できるわけですが、内部ブロック図ではどうするのかは分かりませんでした。そもそも内部ブロック図で作成できるのかどうかが分かっていません。詳しい人は教えてください。
コンポーネント図での手順も分かりづらいので説明します。
まずはModelsからInterfaceを選択して適当にインターフェースを作成してください。
作成したインターフェースを右クリックしてFormat→Display Interface as lollipopを選択すれば形状が変化します。
ただソケットの作り方が謎で、どうやら作成できるらしいのですけど同じ手順を踏んでも再現できませんでした。
そういえば、今日は誕生日でした。
昔は誕生日が来るのが楽しみだったのですが、最近は嫌悪感、もしくは恐怖しかありません。
夢も希望もないとはまさにこのことです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
他のコマンドは問題なさそうですが、rtresurrectコマンドでは以下のエラーが出ます。
rtresurrect: 'module' object has no attribute 'any'
そもそもどこからこのエラーが出ているのかの見当がつきません。
よく使うコマンドだろうから動作確認をしていないという事はないと思うので、他の環境で再現できるのかも不明です。誰か動作確認してください。
リリースノートを見る限り、rtresurrectコマンドに変更はないみたいなので謎です。
全然関係ないけど、フリーのUML、SysMLモデリングツールのPapyrusの使い方について書こうと思います。
インストールの方法は分かりやすいサイトがあったのでそちらを参考にしてください。
まず最初に、Window→Perspactive→Open Perspactive→Otherを選択して表示されるダイアログでPapyrusを選択してください。
次にFile→New→Papyrus Projectを選択してプロジェクトを新規作成します。
後はSysmlを選択して、適当にプロジェクト名を選択してください。
そしてSelect a Diagram KindでBlock Definition DiagramとInternal Block Diagramにチェックを入れてください。
これでFInishを押すとプロジェクトを作成します。
次にブロック定義図を適当に編集します。
右のリストのModelElementsからブロックを選択して適当に並べてください。
左のModel ExplorerからBlock1を選択してエディタ上にドラッグ＆ドロップしてください。
そして右のリストのAssociationsからコンポジションを選択して、以下のように線を引いてください。
次に内部ブロック図を編集します。
先ほどコンポジションを作成したときに左のModel ExplorerのBlock1の下にBlock2とBlock3のパートが追加されていると思うので、それらをドラッグ＆ドロップしてください。
後は適当にフローポートやコネクタを追加してください。
困ったのがインターフェースを追加したときで、UMLのコンポーネント図だと以下のようにロリポップで表示できるわけですが、内部ブロック図ではどうするのかは分かりませんでした。そもそも内部ブロック図で作成できるのかどうかが分かっていません。詳しい人は教えてください。
コンポーネント図での手順も分かりづらいので説明します。
まずはModelsからInterfaceを選択して適当にインターフェースを作成してください。
作成したインターフェースを右クリックしてFormat→Display Interface as lollipopを選択すれば形状が変化します。
ただソケットの作り方が謎で、どうやら作成できるらしいのですけど同じ手順を踏んでも再現できませんでした。
そういえば、今日は誕生日でした。
昔は誕生日が来るのが楽しみだったのですが、最近は嫌悪感、もしくは恐怖しかありません。
夢も希望もないとはまさにこのことです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
マニュアルの作成は一旦中断して、今は予稿原稿を書いています。
別に審査基準に予稿原稿はないみたいなのですが、一応見た目だけはそれなりにしておきます。
色々論文を読んだりしているところですが、複合コンポーネントや実行コンテキスト、マネージャー関連の論文はかなり少ないみたいですね。ほとんど産総研関連の発表しかないようです。
もっとRTCの設計に関する論文があってもよいのではないかと思うのですが、それも少ないみたいです。
たまにSysMLで設計してRTシステムに実装する人がいますが、実のところこれはかなり特殊な技能が必要になるのではないかと思っています。そもそも当たり前ですがSysMLはRTシステムを設計するためのモデリング言語ではありません。ブロック定義図・内部ブロック図で設計→RTCに実装の過程を間違うと後で苦労する事になると思います。
この辺のノウハウを書いた論文でもあれば良かったと思うのですが、見当たりませんね。
今気づいたのですが、RTMコンテスト2015のページのスケジュールに「12月15日(予定)：SI2015総会にて最優秀者表彰」がありますね。
なので参加する人は12月15日までに帰ったりしないようにしてください。
誰が受賞するかはコンテスト当日まで分かりません。
どうにもロボットアーム・クローラー制御RTC群の内容が物足りないなあ。
まあ奨励賞狙いなのでこれでも構わないのですけど、なんだか不満です。
もっと高度な制御がやりたいのは山々ですけど、車輪の角速度が計測できないので自己位置推定をするにも他の手段を考える必要があります。
どっちにしても予稿原稿に書くのは不可能なので、発表までの3ヶ月の間になんとかします。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
別に審査基準に予稿原稿はないみたいなのですが、一応見た目だけはそれなりにしておきます。
色々論文を読んだりしているところですが、複合コンポーネントや実行コンテキスト、マネージャー関連の論文はかなり少ないみたいですね。ほとんど産総研関連の発表しかないようです。
もっとRTCの設計に関する論文があってもよいのではないかと思うのですが、それも少ないみたいです。
たまにSysMLで設計してRTシステムに実装する人がいますが、実のところこれはかなり特殊な技能が必要になるのではないかと思っています。そもそも当たり前ですがSysMLはRTシステムを設計するためのモデリング言語ではありません。ブロック定義図・内部ブロック図で設計→RTCに実装の過程を間違うと後で苦労する事になると思います。
この辺のノウハウを書いた論文でもあれば良かったと思うのですが、見当たりませんね。
今気づいたのですが、RTMコンテスト2015のページのスケジュールに「12月15日(予定)：SI2015総会にて最優秀者表彰」がありますね。
なので参加する人は12月15日までに帰ったりしないようにしてください。
誰が受賞するかはコンテスト当日まで分かりません。
どうにもロボットアーム・クローラー制御RTC群の内容が物足りないなあ。
まあ奨励賞狙いなのでこれでも構わないのですけど、なんだか不満です。
もっと高度な制御がやりたいのは山々ですけど、車輪の角速度が計測できないので自己位置推定をするにも他の手段を考える必要があります。
どっちにしても予稿原稿に書くのは不可能なので、発表までの3ヶ月の間になんとかします。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
