ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
マニュアルの作成は一旦中断して、今は予稿原稿を書いています。
別に審査基準に予稿原稿はないみたいなのですが、一応見た目だけはそれなりにしておきます。
色々論文を読んだりしているところですが、複合コンポーネントや実行コンテキスト、マネージャー関連の論文はかなり少ないみたいですね。ほとんど産総研関連の発表しかないようです。
もっと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ヶ月の間になんとかします。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
前回の記事で「これからマニュアルの作成に集中できる」みたいな事を書きましたが、よく考えてみればロボットアーム制御RTCをかなり適当に作っていたのを忘れていました。
と言うわけで大幅に修正しました。
こんな感じになりました。
これでマニュアルの作成に取り掛かれそうですが、RTCの数が多いので非常に面倒くさいです。
wasanbonみたいにRTC.xmlからマニュアルを自動生成できる機能を使えば良いのかもしれないですが、使い方がよく分かりません。
今気づいたのですけど、カテゴリ名で検索できるようになったみたいですね。
ただカテゴリ名の付け方のルールが曖昧なのが現状だと思うので、効果は薄いかもしれないです。OpenRTM-aistをインストールしたときに付いてくるOpenCVのサンプルのカテゴリ名がCategoryとなっているぐらいですから、そもそも明確なルール自体ないのかもしれないです。
あるRTCはカテゴリ名をRobotArmと付けていて、別のRTCはカテゴリ名をArmとか付けていたら実質的に同じカテゴリにもかかわらず非常にややこしい事になりそうです。
他の人のマニュアルを読んでいる中で気づいたことがあります。
まずRTCの詳細などを説明するのは最低限必要ですが、データポートやコンフィギュレーションパラメータの一覧を載せた表を載せただけでは分かりづらいです。一目で分かるように図がある方が分かりやすいです。コンフィギュレーションパラメータは仕方ないですが、データポート・サービスポートの入出力は簡単なものでいいので図で表現してほしいです。それを見てから詳細は表等を見ます。
要はこんな感じでデータポート・サービスポート・コンフィギュレーションパラメータの一覧を載せた表に加えて図も載せてほしいです。
とりあえず今のところマニュアルはこんな感じになっています。
それから複合コンポーネント作成支援ツールに同梱するために新規作成したサンプルのRTCのマニュアルも作成しました。
実を言うとロボットアーム・クローラー制御RTC群のマニュアルに載せた画像の一部が使った製品のマニュアル等からコピーした画像を使っていたのですが、これは非常にまずそうなので自分で撮った画像に差し替えました。一部画像が汚くなったのはそのせいです。
例のオリンピックのエムブレム問題で人のサイトの画像をわざわざコピーライトを削除して無断使用していたとかで問題になったばかりなので、この辺は注意した方がよいかもしれません。
まあ引用したとか書けばセーフの場合も多いのかなあ？とは思いますが、アウトの場合もあるかもしれないです。まあ大抵の場合そこまで怒る人はいないとは思いますけど。
例えばこの作品の画像の一部がこのサイトの画像と同じに見えます。まあ別にこの作品に関しては画像に問題があってもそれで僕は嫌な思いをしていないのでどうでもいいですけど。
全然関係ないけど、18000円で購入できる四足歩行ロボットがあるらしいですね。
ちゃんと各脚に3自由度ずつあるみたいです。
なかなか面白そうなので、買った人がいればどんな感じなのか教えてください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
と言うわけで大幅に修正しました。
こんな感じになりました。
これでマニュアルの作成に取り掛かれそうですが、RTCの数が多いので非常に面倒くさいです。
wasanbonみたいにRTC.xmlからマニュアルを自動生成できる機能を使えば良いのかもしれないですが、使い方がよく分かりません。
今気づいたのですけど、カテゴリ名で検索できるようになったみたいですね。
ただカテゴリ名の付け方のルールが曖昧なのが現状だと思うので、効果は薄いかもしれないです。OpenRTM-aistをインストールしたときに付いてくるOpenCVのサンプルのカテゴリ名がCategoryとなっているぐらいですから、そもそも明確なルール自体ないのかもしれないです。
あるRTCはカテゴリ名をRobotArmと付けていて、別のRTCはカテゴリ名をArmとか付けていたら実質的に同じカテゴリにもかかわらず非常にややこしい事になりそうです。
他の人のマニュアルを読んでいる中で気づいたことがあります。
まずRTCの詳細などを説明するのは最低限必要ですが、データポートやコンフィギュレーションパラメータの一覧を載せた表を載せただけでは分かりづらいです。一目で分かるように図がある方が分かりやすいです。コンフィギュレーションパラメータは仕方ないですが、データポート・サービスポートの入出力は簡単なものでいいので図で表現してほしいです。それを見てから詳細は表等を見ます。
要はこんな感じでデータポート・サービスポート・コンフィギュレーションパラメータの一覧を載せた表に加えて図も載せてほしいです。
とりあえず今のところマニュアルはこんな感じになっています。
それから複合コンポーネント作成支援ツールに同梱するために新規作成したサンプルのRTCのマニュアルも作成しました。
実を言うとロボットアーム・クローラー制御RTC群のマニュアルに載せた画像の一部が使った製品のマニュアル等からコピーした画像を使っていたのですが、これは非常にまずそうなので自分で撮った画像に差し替えました。一部画像が汚くなったのはそのせいです。
例のオリンピックのエムブレム問題で人のサイトの画像をわざわざコピーライトを削除して無断使用していたとかで問題になったばかりなので、この辺は注意した方がよいかもしれません。
まあ引用したとか書けばセーフの場合も多いのかなあ？とは思いますが、アウトの場合もあるかもしれないです。まあ大抵の場合そこまで怒る人はいないとは思いますけど。
例えばこの作品の画像の一部がこのサイトの画像と同じに見えます。まあ別にこの作品に関しては画像に問題があってもそれで僕は嫌な思いをしていないのでどうでもいいですけど。
全然関係ないけど、18000円で購入できる四足歩行ロボットがあるらしいですね。
ちゃんと各脚に3自由度ずつあるみたいです。
なかなか面白そうなので、買った人がいればどんな感じなのか教えてください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
OpenRTM-aistのPython版の複合コンポーネントのサンプルが動作できたと思っていたのですが、動作できていませんでした。僕の環境だけなのかは定かではないので、Composite.pyが動作できるかどうか教えてください。
どうにもbindParameter関数の第3引数が空の文字列だとバインドされないみたいです。
つまりrtshell等で後で追加する場合は問題ありません。
今は独自の複合コンポーネントを作成しているのですが、その過程で色々と問題が起きています。
複合コンポーネントをリセットすると子コンポーネントが全てリセットできるみたいですが、そもそも複合コンポーネントがエラーにならないとリセットできないので意味がありません。
作成した複合コンポーネントがこれです。
C++版では非アクティブ化するときに子コンポーネントの非アクティブ化は別スレッドで処理するようにしました。Python版では上記の部分を修正しました。あと両方にいえる事ですが、子コンポーネントのどれかがエラー状態になると複合コンポーネントもエラーに遷移するようにしました。
とりあえずロボットアーム制御RTC群、クローラー制御RTC群を以下のように複合化しました。
これで一通りの機能は実装できたのでマニュアルの作成に集中できそうです。
クロスコンパイルのやり方も説明しようかとも思いましたが、そもそもIntel Edisonはx86なので開発PC上のLinuxで普通にビルドしてコピーすれば動作できます。mraaを動作してみた人もいるみたいです。OpenRTM-aistを使う場合でもビルドした実行ファイルに必要なライブラリをlddコマンドで調べてコピーすれば普通に動くのではないですかね？
そうなるとIntel EdisonのLinux用のクロスコンパイルツールは何の意味があるのかが不明ですけど。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
どうにもbindParameter関数の第3引数が空の文字列だとバインドされないみたいです。
つまりrtshell等で後で追加する場合は問題ありません。
今は独自の複合コンポーネントを作成しているのですが、その過程で色々と問題が起きています。
複合コンポーネントをリセットすると子コンポーネントが全てリセットできるみたいですが、そもそも複合コンポーネントがエラーにならないとリセットできないので意味がありません。
作成した複合コンポーネントがこれです。
C++版では非アクティブ化するときに子コンポーネントの非アクティブ化は別スレッドで処理するようにしました。Python版では上記の部分を修正しました。あと両方にいえる事ですが、子コンポーネントのどれかがエラー状態になると複合コンポーネントもエラーに遷移するようにしました。
とりあえずロボットアーム制御RTC群、クローラー制御RTC群を以下のように複合化しました。
これで一通りの機能は実装できたのでマニュアルの作成に集中できそうです。
クロスコンパイルのやり方も説明しようかとも思いましたが、そもそもIntel Edisonはx86なので開発PC上のLinuxで普通にビルドしてコピーすれば動作できます。mraaを動作してみた人もいるみたいです。OpenRTM-aistを使う場合でもビルドした実行ファイルに必要なライブラリをlddコマンドで調べてコピーすれば普通に動くのではないですかね？
そうなるとIntel EdisonのLinux用のクロスコンパイルツールは何の意味があるのかが不明ですけど。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
ロボットアーム、クローラー制御RTC群ですが、RTCの設計を変更します。
アーム制御関連のRTCは変更しないのですが、クローラー制御RTCを分割します。
あまり分割しすぎるとオーバーヘッドが大きくなったりシステムの見通しが悪くなったりデメリットが大きいのですが、それはrtcdで起動することによる通信の高速化と複合コンポーネント化による内部の隠蔽でカバーします。いろいろ考えた結果、センサRTCを交換できるメリットの方が大きいと思いました。
以前と言っている事が逆ですが、複合コンポーネントとして配布すればユーザー側の手間が増えたりシステムの見通しが悪くなったりはしないので複合コンポーネント作成支援ツールでパッケージを作成して配布すれば問題はありません。何だかこのツールを使うためにわざと細分化してしまったような気がしなくもないですけど。
とりあえず8つのRTCを複合化してみたのですが、非アクティブ化しようとすると固まりますね。
OpenRTM-aistの問題なのかこちらのプログラムにバグがあるのか、原因は分かっていません。そもそもC++版のサンプルのCompositeで非アクティブ化しようとしたところ固まってしまったので、多分僕は悪くないです。実行周期1000Hzの時はまだ大丈夫なのですが、50Hzとかになると完全に固まります。PeriodicExecutionContext.cppのdeactivate_component関数でsleepする時間が実行周期が長いほど長くなるからとかそんな話があったような気がしますが、全く覚えていません。よく考えてみれば実行周期1Hzの場合は10秒もsleepするわけで、何かおかしいです。あれ？でも10秒になるのはRtORBの場合で、それ以外だと1秒でしょうか？でも実行周期を1Hzにして試してみると10秒ぐらい時間がかかっているようなのですが、何が起こっているのかがよく分かりません。ログを見てみたところ1000Hzで10000usのスリープをするようになっているみたいなので、1Hzでは10秒であっていると思います。
複合コンポーネントとなると、外側から非アクティブ化するように指令を出して、さらに複合コンポーネントのonDeactivated関数内部で子コンポーネントの非アクティブ化を行うので相当な時間sleepし続けるという事になります。とはいってもいくらなんでも時間がかかりすぎのような気がしますけど。例えば実行周期が50Hzで3つの子コンポーネントを含む複合コンポーネントを非アクティブ化しようと思ったら0.8秒ぐらいじゃないの？と思ったのですが、200秒は固まっています。と言うか1000Hzでも10秒ぐらい固まっています。試しに1つだけ子コンポーネントを含む複合コンポーネントで非アクティブ化してみたのですがどうやら子コンポーネントの数は無関係みたいです。予想と違いました。
今気づいたのですが、deactivate_componentのwhile文で1000回ループしてエラーで終了しているみたいです。つまり複合コンポーネントの場合は非アクティブ化自体が失敗していて、1000回ループするのでその時間だけ固まっているということになります。何でこんな事になるのかが分かりません。
かなり悪い想像にはなるのですが、ひょっとして以下のような事が起こっているのではないでしょうか？
まず複合コンポーネント化すると実行コンテキストには複合コンポーネント、子コンポーネントがアタッチされます。複合コンポーネント→子コンポーネントの順に実行されると思います。
そして外部から複合コンポーネントの非アクティブ化を指令すると、実行コンテキストのsvc関数で複合コンポーネントを実行をしたところでonDeactivatedが呼び出されます。そしてそのonDeactivatedでは子コンポーネントの非アクティブ化を指令します。ただ子コンポーネントが非アクティブになるには実行コンテキストのsvc関数で子コンポーネントを実行する必要があります。しかしこの場合は、複合コンポーネントの実行で処理が止まっていて子コンポーネントの実行ができない状態なので子コンポーネントを非アクティブ化できません。
まとめると、複合コンポーネントは子コンポーネントの非アクティブ化をしたいけど、複合コンポーネントが処理を止めているので子コンポーネントが非アクティブ状態になれないという事です。しかも子コンポーネントが非アクティブ状態にならないと複合コンポーネントの処理が終了しないという地獄に嵌っています。
上記の推測が正しかったとすれば、かなり致命的なミスかもしれません。
Python版のサンプルのCompositeは普通に動作しているのでC++版も問題ないと思っていました。
これは少し困りました。とりあえずツールではPython版のrtcdで複合コンポーネントを起動するようにして対応します。いやでも複合コンポーネントから子RTCのコールバックを呼び出すのに別プロセスからでは時間がかかるのでできれば避けたいです。
多分すぐには対応してくれないだろうし、独自の複合コンポーネントを作成できるようなら作ります。
色々動作確認しているうちに実行順序設定可能な実行コンテキストのPython版に致命的なバグがある事が発覚しました。どうやらOpenRTM-aist-Python-1.1.0-Releaseに対応する際に発生したみたいです。OpenRTM-aist-Python-1.1.0-Releaseでは実行コンテキストにRTCをアタッチしたときに、一旦ExecutionContextWorkerの_addedCompsというリストに追加してupdateComponentListという関数で_compsというリストに_addedCompsの中身を追加、そして_addedCompsを空にするというよく分からない手順を踏むみたいです。つまりupdateComponentListをどこかで呼び出さなければRTCが追加されたことにはなりません。
これに関しては修正したような記憶があるのですが勘違いだったみたいです。それか修正したけど何らかの理由でファイルを保存し忘れたのか定かではありません。
とりあえず以下の順序で実行するようなシステムを作成しました。
このシステムを作成してからまたしても致命的なミスに気が付きました。
ADコンバータは単一のSPIで通信しているので距離センサ0から4の計測値を同時に取得する事はできません。並列に処理しても直列に処理した場合と何も変わりません。
それでも加速度・地磁気センサの計測は並列に処理できるので多少早くなるかな？と思いましたが実行コンテキスト内部のオーバーヘッドの影響でほとんど変わらないぐらいになってしまいました。
それにしても複合コンポーネントの一部のRTCがエラー状態になったらどうすればいいのでしょうね？
それから複合コンポーネントを終了させようとすると失敗します。
どうやら別プロセスの複合コンポーネントに複合しようとすると失敗するらしい。それともPythonで複合コンポーネントを起動すると失敗するのか、まだどこに原因があるのかは分かっていません。
最初に複合コンポーネントをexitしようとすると、後で子コンポーネントをexitしようとしたときにエラーが出ます。逆に子コンポーネントから消そうとすると何故かエラーも出てないのに子コンポーネントが消えません。どうしてでしょうね？そもそもどっちから消すのが正しいのかが分からないので何とも言えません。
RTCの設計に関しては予稿原稿に書いたことは変更したくないので、予稿原稿締切までには仕様を固めたいと思います。
だいぶソースコードへのコメントは書けたのですが、マニュアルがまだまだ充実していません。
実装した機能の2割も説明できていません。
まだ予稿原稿の締め切りまでは時間があるので、まずはマニュアルです。
今年のRTMコンテストには18件の応募があったらしいので、僕を除くと16件みたいですね。
去年より少ないからと言ってレベルが低いとは限らないので油断はできません。
正直なところ、RTMではじめるロボットアプリ開発に載っていたOpenCV-RTCとか出されるとかなり厳しいです。多分画像処理は何かしら出るのでしょうし、産業用ロボットアームも何か出ると思いますし、あとはメディアアートも何件か出ると思います。もっと目の付け所からおかしいような作品が出てくることに個人的には期待しています。
複合コンポーネント作成支援ツールはともかく、ロボットアーム・クローラー制御RTC群は他と被らないかが心配です。この手の卓上サイズのロボットアームはここ数年でかなり増えた感じがするので他の人も似たようなRTCを作ってくるかもしれません。
ただ同じ製品を使ってくる可能性はほぼないと考えています。
似たような製品には以下のようなものがあります。
MeArm
ミニチュアサイズのロボットアーム。3自由度＋グリッパー付き。
こっちのページによるとMeBrainというマイコンが付いてくるらしいです。
uArm
4自由度＋吸引ポンプ付きロボットアーム。
Arduino互換ボードとUduinoと言うシールドが付いてくるらしい。
アカデミック スカラロボット
水平多関節ロボットアーム。
専用モーションエディタ等ソフトウェアも充実しているみたいです。
他にもいろいろな卓上サイズのロボットアームがある中で何故サインスマート製4自由度ロボットアームを選んだのか、これは聞かれた時のために何か言い訳を考えておかねばなりません。
まずサインスマート製4自由度ロボットアームの特徴としてロボットアーム本体以外何も付いてきません。制御基板もそうですが、手先にグリッパーもありません。制御基板が付いてこないので、当然サンプルプログラムなども充実していません。
これは一見短所に見えますが、僕は逆に考えています。何もないという事はこちらで自由に選べるという事です。別にArduinoで制御する必要はありません。
手先にも何もついていないのであれば、グリッパーに限らず好きなものを取り付けたら良いと思います。
この何もないところがRTM向きに感じました。要は足りない部分は他のモジュールを持ってくれば良いという事です。グリッパー制御RTCが他にあるのであればそれを持ってきて、対応したグリッパーを取り付ければ良いという事です。
サンプルプログラムもですが、公式サイトを見る限り他社の製品に比べるとソフトウェアの充実度が格段に劣ります。これが狙い目だと考えています。ロボットアーム自体はそれなりに売れているとは思うので、それを制御するソフトウェア等を作れば使ってもらえる可能性はあると思います。つまりRTMに関係ない人もロボットアーム制御RTC群を使う事になるので、RTMの普及にもつながります。そんなに上手くいくわけないだろ
どの製品を選んだかは置いておいて、Intel Edisonから制御したという事で他の作品との差別化はできると思います。単純に動作させるだけではなく、PWMサーボドライバRTCをRTnoに交換するだけでIntel Edisonを使わずに普通のPCとArduinoで制御できるようにした点は評価してほしいです。あと20個のRTCを新規開発したので、評価もそうですがまずは使ってほしいです。
とはいってもロボットアーム・クローラー制御RTC群の方があくまで奨励賞狙いなので、他と被るのも仕方ないぐらいには考えています。別にどっかのデザイナーと違ってパクったわけじゃないし。
まあ完全にもろ被りすると言う事はないと思うので、違う部分を強調できれば大丈夫だと思いますけどね。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
アーム制御関連のRTCは変更しないのですが、クローラー制御RTCを分割します。
あまり分割しすぎるとオーバーヘッドが大きくなったりシステムの見通しが悪くなったりデメリットが大きいのですが、それはrtcdで起動することによる通信の高速化と複合コンポーネント化による内部の隠蔽でカバーします。いろいろ考えた結果、センサRTCを交換できるメリットの方が大きいと思いました。
以前と言っている事が逆ですが、複合コンポーネントとして配布すればユーザー側の手間が増えたりシステムの見通しが悪くなったりはしないので複合コンポーネント作成支援ツールでパッケージを作成して配布すれば問題はありません。何だかこのツールを使うためにわざと細分化してしまったような気がしなくもないですけど。
とりあえず8つのRTCを複合化してみたのですが、非アクティブ化しようとすると固まりますね。
OpenRTM-aistの問題なのかこちらのプログラムにバグがあるのか、原因は分かっていません。そもそもC++版のサンプルのCompositeで非アクティブ化しようとしたところ固まってしまったので、多分僕は悪くないです。実行周期1000Hzの時はまだ大丈夫なのですが、50Hzとかになると完全に固まります。PeriodicExecutionContext.cppのdeactivate_component関数でsleepする時間が実行周期が長いほど長くなるからとかそんな話があったような気がしますが、全く覚えていません。よく考えてみれば実行周期1Hzの場合は10秒もsleepするわけで、何かおかしいです。あれ？でも10秒になるのはRtORBの場合で、それ以外だと1秒でしょうか？でも実行周期を1Hzにして試してみると10秒ぐらい時間がかかっているようなのですが、何が起こっているのかがよく分かりません。ログを見てみたところ1000Hzで10000usのスリープをするようになっているみたいなので、1Hzでは10秒であっていると思います。
複合コンポーネントとなると、外側から非アクティブ化するように指令を出して、さらに複合コンポーネントのonDeactivated関数内部で子コンポーネントの非アクティブ化を行うので相当な時間sleepし続けるという事になります。とはいってもいくらなんでも時間がかかりすぎのような気がしますけど。例えば実行周期が50Hzで3つの子コンポーネントを含む複合コンポーネントを非アクティブ化しようと思ったら0.8秒ぐらいじゃないの？と思ったのですが、200秒は固まっています。と言うか1000Hzでも10秒ぐらい固まっています。試しに1つだけ子コンポーネントを含む複合コンポーネントで非アクティブ化してみたのですがどうやら子コンポーネントの数は無関係みたいです。予想と違いました。
今気づいたのですが、deactivate_componentのwhile文で1000回ループしてエラーで終了しているみたいです。つまり複合コンポーネントの場合は非アクティブ化自体が失敗していて、1000回ループするのでその時間だけ固まっているということになります。何でこんな事になるのかが分かりません。
かなり悪い想像にはなるのですが、ひょっとして以下のような事が起こっているのではないでしょうか？
まず複合コンポーネント化すると実行コンテキストには複合コンポーネント、子コンポーネントがアタッチされます。複合コンポーネント→子コンポーネントの順に実行されると思います。
そして外部から複合コンポーネントの非アクティブ化を指令すると、実行コンテキストのsvc関数で複合コンポーネントを実行をしたところでonDeactivatedが呼び出されます。そしてそのonDeactivatedでは子コンポーネントの非アクティブ化を指令します。ただ子コンポーネントが非アクティブになるには実行コンテキストのsvc関数で子コンポーネントを実行する必要があります。しかしこの場合は、複合コンポーネントの実行で処理が止まっていて子コンポーネントの実行ができない状態なので子コンポーネントを非アクティブ化できません。
まとめると、複合コンポーネントは子コンポーネントの非アクティブ化をしたいけど、複合コンポーネントが処理を止めているので子コンポーネントが非アクティブ状態になれないという事です。しかも子コンポーネントが非アクティブ状態にならないと複合コンポーネントの処理が終了しないという地獄に嵌っています。
上記の推測が正しかったとすれば、かなり致命的なミスかもしれません。
Python版のサンプルのCompositeは普通に動作しているのでC++版も問題ないと思っていました。
これは少し困りました。とりあえずツールではPython版のrtcdで複合コンポーネントを起動するようにして対応します。いやでも複合コンポーネントから子RTCのコールバックを呼び出すのに別プロセスからでは時間がかかるのでできれば避けたいです。
多分すぐには対応してくれないだろうし、独自の複合コンポーネントを作成できるようなら作ります。
色々動作確認しているうちに実行順序設定可能な実行コンテキストのPython版に致命的なバグがある事が発覚しました。どうやらOpenRTM-aist-Python-1.1.0-Releaseに対応する際に発生したみたいです。OpenRTM-aist-Python-1.1.0-Releaseでは実行コンテキストにRTCをアタッチしたときに、一旦ExecutionContextWorkerの_addedCompsというリストに追加してupdateComponentListという関数で_compsというリストに_addedCompsの中身を追加、そして_addedCompsを空にするというよく分からない手順を踏むみたいです。つまりupdateComponentListをどこかで呼び出さなければRTCが追加されたことにはなりません。
これに関しては修正したような記憶があるのですが勘違いだったみたいです。それか修正したけど何らかの理由でファイルを保存し忘れたのか定かではありません。
とりあえず以下の順序で実行するようなシステムを作成しました。
このシステムを作成してからまたしても致命的なミスに気が付きました。
ADコンバータは単一のSPIで通信しているので距離センサ0から4の計測値を同時に取得する事はできません。並列に処理しても直列に処理した場合と何も変わりません。
それでも加速度・地磁気センサの計測は並列に処理できるので多少早くなるかな？と思いましたが実行コンテキスト内部のオーバーヘッドの影響でほとんど変わらないぐらいになってしまいました。
それにしても複合コンポーネントの一部のRTCがエラー状態になったらどうすればいいのでしょうね？
それから複合コンポーネントを終了させようとすると失敗します。
どうやら別プロセスの複合コンポーネントに複合しようとすると失敗するらしい。それともPythonで複合コンポーネントを起動すると失敗するのか、まだどこに原因があるのかは分かっていません。
最初に複合コンポーネントをexitしようとすると、後で子コンポーネントをexitしようとしたときにエラーが出ます。逆に子コンポーネントから消そうとすると何故かエラーも出てないのに子コンポーネントが消えません。どうしてでしょうね？そもそもどっちから消すのが正しいのかが分からないので何とも言えません。
RTCの設計に関しては予稿原稿に書いたことは変更したくないので、予稿原稿締切までには仕様を固めたいと思います。
だいぶソースコードへのコメントは書けたのですが、マニュアルがまだまだ充実していません。
実装した機能の2割も説明できていません。
まだ予稿原稿の締め切りまでは時間があるので、まずはマニュアルです。
今年のRTMコンテストには18件の応募があったらしいので、僕を除くと16件みたいですね。
去年より少ないからと言ってレベルが低いとは限らないので油断はできません。
正直なところ、RTMではじめるロボットアプリ開発に載っていたOpenCV-RTCとか出されるとかなり厳しいです。多分画像処理は何かしら出るのでしょうし、産業用ロボットアームも何か出ると思いますし、あとはメディアアートも何件か出ると思います。もっと目の付け所からおかしいような作品が出てくることに個人的には期待しています。
複合コンポーネント作成支援ツールはともかく、ロボットアーム・クローラー制御RTC群は他と被らないかが心配です。この手の卓上サイズのロボットアームはここ数年でかなり増えた感じがするので他の人も似たようなRTCを作ってくるかもしれません。
ただ同じ製品を使ってくる可能性はほぼないと考えています。
似たような製品には以下のようなものがあります。
MeArm
ミニチュアサイズのロボットアーム。3自由度＋グリッパー付き。
こっちのページによるとMeBrainというマイコンが付いてくるらしいです。
uArm
4自由度＋吸引ポンプ付きロボットアーム。
Arduino互換ボードとUduinoと言うシールドが付いてくるらしい。
アカデミック スカラロボット
水平多関節ロボットアーム。
専用モーションエディタ等ソフトウェアも充実しているみたいです。
他にもいろいろな卓上サイズのロボットアームがある中で何故サインスマート製4自由度ロボットアームを選んだのか、これは聞かれた時のために何か言い訳を考えておかねばなりません。
まずサインスマート製4自由度ロボットアームの特徴としてロボットアーム本体以外何も付いてきません。制御基板もそうですが、手先にグリッパーもありません。制御基板が付いてこないので、当然サンプルプログラムなども充実していません。
これは一見短所に見えますが、僕は逆に考えています。何もないという事はこちらで自由に選べるという事です。別にArduinoで制御する必要はありません。
手先にも何もついていないのであれば、グリッパーに限らず好きなものを取り付けたら良いと思います。
この何もないところがRTM向きに感じました。要は足りない部分は他のモジュールを持ってくれば良いという事です。グリッパー制御RTCが他にあるのであればそれを持ってきて、対応したグリッパーを取り付ければ良いという事です。
サンプルプログラムもですが、公式サイトを見る限り他社の製品に比べるとソフトウェアの充実度が格段に劣ります。これが狙い目だと考えています。ロボットアーム自体はそれなりに売れているとは思うので、それを制御するソフトウェア等を作れば使ってもらえる可能性はあると思います。つまりRTMに関係ない人もロボットアーム制御RTC群を使う事になるので、RTMの普及にもつながります。そんなに上手くいくわけないだろ
どの製品を選んだかは置いておいて、Intel Edisonから制御したという事で他の作品との差別化はできると思います。単純に動作させるだけではなく、PWMサーボドライバRTCをRTnoに交換するだけでIntel Edisonを使わずに普通のPCとArduinoで制御できるようにした点は評価してほしいです。あと20個のRTCを新規開発したので、評価もそうですがまずは使ってほしいです。
とはいってもロボットアーム・クローラー制御RTC群の方があくまで奨励賞狙いなので、他と被るのも仕方ないぐらいには考えています。別にどっかのデザイナーと違ってパクったわけじゃないし。
まあ完全にもろ被りすると言う事はないと思うので、違う部分を強調できれば大丈夫だと思いますけどね。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
RTMではじめる ロボットアプリ開発を購入しました。
とりあえず目次を見た感じで、どっかのRTMの本と見せかけたUMLの本とは違ってRTMの内容がほとんどみたいなので一安心です。あの本も最初からUMLの本だと思えば悪くないのですけどね。
このページからサンプル等がダウンロードできるみたいです。
2章のアプリがバッチファイルを起動するだけで一発で起動できました。
これは凄いです。こんなに簡単に動作できるRTシステムは貴重です。今年RTMコンテストに参加する人は是非参考にしてください。音声合成、会話制御にクラウドサービスを使ってこちらでのソフトウェアのインストールを不要にしたところは良かったと思います。
どうやらこのアプリは本を購入してなくても入手できるみたいです。一つ不満な点を挙げるとすれば同じDLLが沢山同梱されており(例えばomniDynamic415_vc10_rt.dllは4つも入っています)、ダウンロードする時に重いです。DLLを単一のフォルダに集めておいて、start.bat内でパスを通した方が良いのではないかと思いました。
一番驚いたのはOpenCV-RTCで、凄く簡単に動作確認ができるようになっています。
別にこの本に直接かかわることじゃないのかもしれませんが、あの共有メモリ通信のできる独自のデータ型が今後どうなるかが気になります。なんでも同一プロセス同士のRTCの通信であれば直接データに書き込めるようになるとからしいので、将来的には独自のデータ型にした事が足を引っ張るのではないかと思っています。なんだか90ページの②の利点はどういう意味なのかよく分かりません。
サンプルの話はこのぐらいにしておいて、本の内容について感想を書きます。
サポートページの目次を見た感じでサンプルのRTシステムの説明がほとんどのように見えますが、実際は6章のRTCのプログラミングが本の半分近くを占めています。この辺の量を多めにしたのは良かったと思います。RTCを作成する上で重要度が高い部分を重点的に説明しているので分かりやすかったと思います。ただ逆に言えば細かい部分については書かれていません。マネージャの説明とかはあっても良かったかもしれないです。あとこの本のサンプルプログラムは短いのでいいのですけど、ロジック部分は切り離すのが基本なので別ファイルに分離したときのためにCMakeLists.txtの編集の仕方にも軽く触れておいた方が良かったと思います。
全体的に使い方を説明した感じでRTMの詳細な仕様などは掲載されていません。まさに入門書と言った感じです。
3.8節の「音声処理部で利用している既存の技術と知見」は面白かったと思いました。サンプルのRTCにどのような工夫をしたのかが分かりやすかったと思います。
2つだけ不満な点があります。
まず4章でラジオとかババ抜きとか謎の例えが出てくるのですが、何だか分かりづらいです。と言うより4章は全体的に分かりづらかった印象です。何だかこの章は具体的な話をしているのに抽象的に感じるというか、全体的にふわふわした感じがしました。93ページの②で言っている「独自定義のファイル」とかよく分からないので具体例を見せてほしかったと思いました。
あとDAN Ⅱ世と言うキャラクターはあまりかわいくないので、独自のキャラクターを使った方が良かったと思います。
どうでもいいですけど、161ページに誤字があります。
全体的に面白い内容だったと思います。入門書ですけど、RTMに精通している人でもそれなりに楽しめると思います。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
とりあえず目次を見た感じで、どっかのRTMの本と見せかけたUMLの本とは違ってRTMの内容がほとんどみたいなので一安心です。あの本も最初からUMLの本だと思えば悪くないのですけどね。
このページからサンプル等がダウンロードできるみたいです。
2章のアプリがバッチファイルを起動するだけで一発で起動できました。
これは凄いです。こんなに簡単に動作できるRTシステムは貴重です。今年RTMコンテストに参加する人は是非参考にしてください。音声合成、会話制御にクラウドサービスを使ってこちらでのソフトウェアのインストールを不要にしたところは良かったと思います。
どうやらこのアプリは本を購入してなくても入手できるみたいです。一つ不満な点を挙げるとすれば同じDLLが沢山同梱されており(例えばomniDynamic415_vc10_rt.dllは4つも入っています)、ダウンロードする時に重いです。DLLを単一のフォルダに集めておいて、start.bat内でパスを通した方が良いのではないかと思いました。
一番驚いたのはOpenCV-RTCで、凄く簡単に動作確認ができるようになっています。
別にこの本に直接かかわることじゃないのかもしれませんが、あの共有メモリ通信のできる独自のデータ型が今後どうなるかが気になります。なんでも同一プロセス同士のRTCの通信であれば直接データに書き込めるようになるとからしいので、将来的には独自のデータ型にした事が足を引っ張るのではないかと思っています。なんだか90ページの②の利点はどういう意味なのかよく分かりません。
サンプルの話はこのぐらいにしておいて、本の内容について感想を書きます。
サポートページの目次を見た感じでサンプルのRTシステムの説明がほとんどのように見えますが、実際は6章のRTCのプログラミングが本の半分近くを占めています。この辺の量を多めにしたのは良かったと思います。RTCを作成する上で重要度が高い部分を重点的に説明しているので分かりやすかったと思います。ただ逆に言えば細かい部分については書かれていません。マネージャの説明とかはあっても良かったかもしれないです。あとこの本のサンプルプログラムは短いのでいいのですけど、ロジック部分は切り離すのが基本なので別ファイルに分離したときのためにCMakeLists.txtの編集の仕方にも軽く触れておいた方が良かったと思います。
全体的に使い方を説明した感じでRTMの詳細な仕様などは掲載されていません。まさに入門書と言った感じです。
3.8節の「音声処理部で利用している既存の技術と知見」は面白かったと思いました。サンプルのRTCにどのような工夫をしたのかが分かりやすかったと思います。
2つだけ不満な点があります。
まず4章でラジオとかババ抜きとか謎の例えが出てくるのですが、何だか分かりづらいです。と言うより4章は全体的に分かりづらかった印象です。何だかこの章は具体的な話をしているのに抽象的に感じるというか、全体的にふわふわした感じがしました。93ページの②で言っている「独自定義のファイル」とかよく分からないので具体例を見せてほしかったと思いました。
あとDAN Ⅱ世と言うキャラクターはあまりかわいくないので、独自のキャラクターを使った方が良かったと思います。
どうでもいいですけど、161ページに誤字があります。
全体的に面白い内容だったと思います。入門書ですけど、RTMに精通している人でもそれなりに楽しめると思います。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
