ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
ロボットアーム、クローラー制御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群の方があくまで奨励賞狙いなので、他と被るのも仕方ないぐらいには考えています。別にどっかのデザイナーと違ってパクったわけじゃないし。
まあ完全にもろ被りすると言う事はないと思うので、違う部分を強調できれば大丈夫だと思いますけどね。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
この記事にコメントする
