ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
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コンテストの盗用の件はどうなったのでしょうね?
もう賞を取り消せとか厳しい事は言わないので、参加者も含めて関わった人に経緯の説明ぐらいしてほしいです。このままでは審査にミスがあったかもしれないとか疑惑だけが残るので後味が悪いです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
この記事にコメントする