ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
前回の記事で「これからマニュアルの作成に集中できる」みたいな事を書きましたが、よく考えてみればロボットアーム制御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自由度ずつあるみたいです。
なかなか面白そうなので、買った人がいればどんな感じなのか教えてください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
ロボットアーム、クローラー制御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コンテストに出す作品のソースコードにコメントを書いているところですが、量が多すぎるので苦戦しています。
一体何万行あるんだろ。5万行から10万行の間だとは思いますが不明です。
これに関してはコメントが少なすぎだと去年怒られたので、今年は多めに書きます。
全くコメントを書いていない作品もあったわけで、何で僕だけ怒られるんだという感じがしなくもないですが、ソースコードの量が多かったので読むのは本当に苦しかったのかもしれないです。
今年は去年の倍の量はあるのでまさに苦行です。
それはさておき、面白い発表スライドを見つけました。
特に最後の方は非常にいいことを書いているので、RTMコンテストに参加する人は是非参考にしてください。
すぐに試せるようになっていれば好印象だと思います。できれば対応デバイスは3万円以下ぐらいで購入できるようにしてほしいです。
とは言っても、実際に審査には影響する事はないと思います。最初から高価で導入しづらい製品をターゲットにしている作品もあるわけで、導入しやすい作品ばかり贔屓にしていたら不公平になるからです。その辺が影響しているのか、簡単に動作できるかどうかもあまり重要ではないように感じます。
逆に審査と言う意味では独自性はかなり重要な項目だと思っています。
下調べは入念に行ってください。
どうやらROSに似たタイプのモジュールがある作品が高評価を受ける事も少なくないみたいなので、これは少し狙い目かもしれないです。
流石に9回目ともなると新規のアイデアはなかなか出辛いので、何らかの機器を使うなりする方向でいく人がほとんどになると思います。
個人的にはメディアアートで何が出てくるかが気になります。やりたい放題できそうな分野なだけに、何が出るかわからないという楽しみはあります。
僕もメディアアートをやれば良かったかな？と思ったのですが、よく考えてみればドラえもんバトルドームのシミュレーションは一種のメディアアートととも言えなくもないかもしれないです。流石にこれはやりたい放題すぎて各所から苦情がくるので、僕はメディアアートはやらなくて正解だったのかもしれないです。
誰かしらメディアアートをやる人はいると思いますが、僕がドン引きするぐらいのものを作ってほしいです。
「対応OSを広くする工夫」は重要です。
coilにある機能ならばできるだけcoilを使いましょう。
Boost、Qt等クロスプラットフォームなライブラリを使えば移植が楽かもしれません。
それからマニュアルはPDFよりもWiki等で公開する事を推奨しています。
僕も前々から言っている通り同じ意見なのですが、理由は違います。まあ確かに更新が簡単というのも一理ありますけれど。
PDFのマニュアルが読みづらいと思っています。印刷してから読むのであれば楽かもしれませんが、ほとんどの人はそんな事しません。
インストーラーの作成ですが、そもそもRTMコンテストでインストーラー付属の作品なんてほとんど見ないので審査で有利になるかは不明です。最近は便利なツールも色々とあるのでインストーラーの作成はそこまで苦しくはありません。
そして最重要なのはライセンスに関する項目です。
何でここまでライセンスを重要視するかは最近のこのブログの内容で察してください。
最低でもソースコードの区別はできるようにして、さらにOSSライセンス違反にもならないようにしてください。
大抵の場合、オープンソースのライセンスはMIT、GPL、LGPL、BSD、修正BSD、Apache、PSF、EPLだとは思うのですが、独自ライセンスの場合もあります。
まず自分の作品のライセンスをどうするかですが、依存ライブラリ等に問題がないのであれば制約の緩いBSDやMITをお勧めします。逆にお勧めできないのはGPLで非常に制約がきついです。
明日はRTMではじめる ロボットアプリ開発の感想を書きます。
別に予告するほどの事でもないですけど。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
一体何万行あるんだろ。5万行から10万行の間だとは思いますが不明です。
これに関してはコメントが少なすぎだと去年怒られたので、今年は多めに書きます。
全くコメントを書いていない作品もあったわけで、何で僕だけ怒られるんだという感じがしなくもないですが、ソースコードの量が多かったので読むのは本当に苦しかったのかもしれないです。
今年は去年の倍の量はあるのでまさに苦行です。
それはさておき、面白い発表スライドを見つけました。
特に最後の方は非常にいいことを書いているので、RTMコンテストに参加する人は是非参考にしてください。
すぐに試せるようになっていれば好印象だと思います。できれば対応デバイスは3万円以下ぐらいで購入できるようにしてほしいです。
とは言っても、実際に審査には影響する事はないと思います。最初から高価で導入しづらい製品をターゲットにしている作品もあるわけで、導入しやすい作品ばかり贔屓にしていたら不公平になるからです。その辺が影響しているのか、簡単に動作できるかどうかもあまり重要ではないように感じます。
逆に審査と言う意味では独自性はかなり重要な項目だと思っています。
下調べは入念に行ってください。
どうやらROSに似たタイプのモジュールがある作品が高評価を受ける事も少なくないみたいなので、これは少し狙い目かもしれないです。
流石に9回目ともなると新規のアイデアはなかなか出辛いので、何らかの機器を使うなりする方向でいく人がほとんどになると思います。
個人的にはメディアアートで何が出てくるかが気になります。やりたい放題できそうな分野なだけに、何が出るかわからないという楽しみはあります。
僕もメディアアートをやれば良かったかな？と思ったのですが、よく考えてみればドラえもんバトルドームのシミュレーションは一種のメディアアートととも言えなくもないかもしれないです。流石にこれはやりたい放題すぎて各所から苦情がくるので、僕はメディアアートはやらなくて正解だったのかもしれないです。
誰かしらメディアアートをやる人はいると思いますが、僕がドン引きするぐらいのものを作ってほしいです。
「対応OSを広くする工夫」は重要です。
coilにある機能ならばできるだけcoilを使いましょう。
Boost、Qt等クロスプラットフォームなライブラリを使えば移植が楽かもしれません。
それからマニュアルはPDFよりもWiki等で公開する事を推奨しています。
僕も前々から言っている通り同じ意見なのですが、理由は違います。まあ確かに更新が簡単というのも一理ありますけれど。
PDFのマニュアルが読みづらいと思っています。印刷してから読むのであれば楽かもしれませんが、ほとんどの人はそんな事しません。
インストーラーの作成ですが、そもそもRTMコンテストでインストーラー付属の作品なんてほとんど見ないので審査で有利になるかは不明です。最近は便利なツールも色々とあるのでインストーラーの作成はそこまで苦しくはありません。
そして最重要なのはライセンスに関する項目です。
何でここまでライセンスを重要視するかは最近のこのブログの内容で察してください。
最低でもソースコードの区別はできるようにして、さらにOSSライセンス違反にもならないようにしてください。
大抵の場合、オープンソースのライセンスはMIT、GPL、LGPL、BSD、修正BSD、Apache、PSF、EPLだとは思うのですが、独自ライセンスの場合もあります。
まず自分の作品のライセンスをどうするかですが、依存ライブラリ等に問題がないのであれば制約の緩いBSDやMITをお勧めします。逆にお勧めできないのはGPLで非常に制約がきついです。
明日はRTMではじめる ロボットアプリ開発の感想を書きます。
別に予告するほどの事でもないですけど。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
今回は諸事情によりRTMコンテストへの参加はやめようかと思っていたのですが、参加を申し込んでしまいました。それも2つ。
1つは複合コンポーネント作成支援ツールです。
こっちがメインで、最優秀賞を狙っているのはこっちです。
2つめはロボットアーム、クローラー制御RTC群です。
こちらは奨励賞狙いです。
2つの作品で合わせて最優秀賞を含めた6つ以上の賞を取るのが今回の目標です。
今考えると、サインスマート製4自由度ロボットアームを使う必然性ってないかもしれないです。
最低でも手先位置の制御はしたいので3自由度はほしいのですよね。
例えばこのロボットアームも3自由度あるので条件は満たしています。
ただ値段はほぼ同じなのでハンドの自由度を取るか、手先の姿勢の自由度を取るかになります。僕は後者を取りました。ハンドは後からでも追加できます。
ちょっと事前調査が足らなかったかもしれないので、もっと適したロボットアームがあったかもしれません。
あまり関係ないけど、このロボットアームってAmazonで買ったら見ての通り12万円なのですが、何故かStrawberry Linuxでは4万2800円で買えるみたいです。
一体何が違うのでしょうね？
過去の記事について、誤解があったかもしれないので弁明しておきます。
「簡単とか簡易とか嘘ばっかり書いていると詐欺でつかまる」とか書きましたが、あれは半分冗談のつもりです。
「簡単に再現できる」と書いているけど本当に簡単に再現できるかどうか分からない場合や、タイトルに簡易とか書いているのに実際使ってみたら全然簡易じゃなかった場合とかありましたけど、あれはただの表現の一種なので実際に問題になることはないと思います。
単に僕は好ましくないと思っているだけです。嘘つき呼ばわりは少しやりすぎだったかもしれないです。
ただ、あまりに露骨に事実と違う事を書いてしまうとまずいかもしれないです。
ここから下は他の参加者に知ってもらいたいことを書きます。
まず、参加するうえで公式サイトは必ず読んでください。
僕も去年エントリー登録ができていなかったので、注意してください。
重要な点を抜き出すと、
エントリー登録
これは忘れがちなので必ずやっておいてください。
何故忘れるかと言うと、ログインしていないとそもそも入力フィールドが表示されないからだと思うので、まずはログインをしてください。
プロジェクトページに紹介ビデオを掲載することを推奨
これは割と重要だと思います。
あった方が分かりやすいです。
分かりやすいマニュアルを添付し、できるだけ第三者が結果を再現できるようにすること。
マニュアルを公開していない人が毎年多くいますが、公式ページを読んでいないのでしょうか？
特に某R大学の某研究室は毎年参加する割に誰もマニュアルを書いていないので、研究室内で徹底させた方がいいと思います。おそらくですが、大幅に減点されていると思います。
マニュアル・プロジェクトページを作成する際ですが、この作品のコメント欄が参考になるかもしれません。公式ページに書いてほしいぐらいの事を書いています。
参考にしたRTコンポーネントやソースコードがある場合は、マニュアル・論文中で出典を明記してオリジナル作者に敬意を払うこと。
これが一番重要です。
マニュアルには必ず明記してください。
予稿原稿にももちろん書くべきですが、SI2015の参加者にしか配布されないのであまり意味はないと思います。
最近やたらと取り上げますが、ドローンの作品はそもそもどれが自作のソースコードで、どれが外部のソースコードなのかの区別ができません。
同梱しているCV Droneのソースコードが作品の共同開発者のものならば問題はないのですが、全くの他人のものだった場合はかなりやばいです。
CV Droneのライセンスを記述したテキストファイルを同梱していないので、人のソースコードを不法に再配布して利益を得たという事になります。
配布してあるものだけを見たらCV Droneのソースコードも作品の一部だとしか思えません。
RTMコンテストから犯罪者は出したくないので、人のソースコードを再配布する際はライセンスに注意してください。
仮に僕のソースコードが再配布されていて、さらにライセンスを記述したテキストファイルを同梱していなかった場合を考えてみます。
これで何も利益が発生していない、ただ再配布しているだけならライセンスを同梱してもらえるように連絡するか、あるいはそれも面倒なので放置するかもしれません。
ただRTMコンテストのように賞金が出る場合、そうでなくても何らかの受賞をした場合は、コンテストの主催者に連絡して賞を撤回するように要求すると思います。
それができない場合は法的措置も考えます。
まあでもファイル1～2つぐらいなら影響はないとみて放置するとは思います。
似ているとか、参考にしたんだろうな程度の場合も放置します。
例えばthirdpartyという名前のフォルダに入っているとか、明らかに他人のソースコードだと分かる場合も気にしないと思います。
CV Droneの開発者の人がどう考えるかは知りませんけど、僕がその立場なら怒ります。
今更ですが、これはかなり重要な問題だと思うのでドローンの作品については白黒はっきりさせてほしいです。
黒(CV Droneの開発者が共著者ではない)の場合は事が大きくなる前に賞状と賞金を返還した方が良いかもしれません。
最近は某事件で研究の盗用とかに敏感になっているので、万が一訴えられた場合は共著者の先生が解雇されるという事態もありうるかもしれないです。
まあ流石に裁判沙汰にまではならないとは思いますけど。
ライセンスを記述したテキストファイルを同梱すれば再配布できるかどうかは何のライセンスかによります。
例えばLGPL、BSD、MIT、GPL等は大丈夫です。
まずはライセンスを確かめて、再配布可能かを確認してください。
ここからは、公式サイトに書いてある事以外で注意してほしいことを書きたいと思います。
まずビルド済み実行ファイルを付属している作品が多いのですが、必要なDLLが付属していないので動作できません。
公式サイトで複数バージョンのOpenRTM-aistをインストールすることは非推奨と書いてあります。環境変数の設定が面倒くさくなるので、できれば新たにOpenRTM-aistはインストールしたくありません。
必要なDLLを付属してくれるのがベストではあるのですが、付属させないのであればインストーラーから抽出する方法をマニュアルに書いてほしいです。
この件に関してまず勘違いしないでほしいのは、ビルド済み実行ファイルがあれば必ず動作できるというわけではないということです。特にOpenRTM-aist、OmniORB、OpenCV等の場合は動的にリンクしているのでDLLがないと動作できません。
それからデバッグビルドした実行ファイルを配布している人が何人もいますが、リリースビルドする事を推奨します。
あと、既存のソフトウェアに関しては必ず入念に調べてください。
wasanbonのリストに載っているRTCは特にチェックしておかないと、当日の質疑応答等で「僕も作ったが」とか言われることになります。その時点で大きな減点を喰らう事は間違いありません。
できるだけ簡単に動作確認できるように工夫をしてほしいです。
開発したのがRTシステムであるのならば、起動からシステムを復元する自動化スクリプトを作成してください。僕のツールを使ってくれてもいいのですが、wasanbon等のツールを使うと作業が楽になるかもしれません。
僕の勝手な考えですが、どうにも人の作品をちゃんと見ていないのではないかと思います。
人の作品の動作確認をしてみれば、自分の作品が動作できないかもしれないと気付くと思います。同じ原因で他の環境では動作できない作品は必ずあります。そしてその作品の開発者にもその事を教えてあげることで、自分、その作品の開発者、後から使う別のユーザーが全員幸せになれます。
後気を付けてほしいことはプロジェクトページのコメントへの返信ですかね。
こちらの質問と意図がずれている場合はもう一度質問するだけなので問題はないのですが、質問に答えずに丁寧なお礼だけを書くのはこちらもイラッとするのでやめてほしいです。例のごとくドローンの作品の事なんですけど。僕はあなたの指導をする立場の人間ではありません。アドバイスをもらったとか勘違いしないでほしいです。
後、こちらで間違いを修正してほしいといって本人も「修正します」と言ったのに、見てみたら修正されていないのは一体何なのでしょうね？これも(ry。
それなら最初から修正するなんて言わないでほしいです。
これはコメントへの対応が悪いというより、こちらとの認識の違いだとは思いますけど、以下の事はできればやめてほしいです。
RTCの粒度が細かすぎてシステムが分かりづらい
↓
各RTCの詳細な説明を追加します
これは何か違うと思います。
そもそもマニュアルに頼りすぎるというのが間違いで、マニュアルを読まなくても動作できるというのが理想です。
なのでこの場合は複合コンポーネントで細かい部分を隠蔽するか、あるいは粒度を大きくして作り直すかが正解だと思います。
まあ他にも色々言いたいことはありますけど、以前の記事で書いたことばかりなので省略します。
一番やってほしいことは他の作品にコメントを投稿してほしいという事なのでよろしくお願いします。
そういえばRTMではじめる ロボットアプリ開発が8月24日に発売されるらしいです。
今から楽しみです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
1つは複合コンポーネント作成支援ツールです。
こっちがメインで、最優秀賞を狙っているのはこっちです。
2つめはロボットアーム、クローラー制御RTC群です。
こちらは奨励賞狙いです。
2つの作品で合わせて最優秀賞を含めた6つ以上の賞を取るのが今回の目標です。
今考えると、サインスマート製4自由度ロボットアームを使う必然性ってないかもしれないです。
最低でも手先位置の制御はしたいので3自由度はほしいのですよね。
例えばこのロボットアームも3自由度あるので条件は満たしています。
ただ値段はほぼ同じなのでハンドの自由度を取るか、手先の姿勢の自由度を取るかになります。僕は後者を取りました。ハンドは後からでも追加できます。
ちょっと事前調査が足らなかったかもしれないので、もっと適したロボットアームがあったかもしれません。
あまり関係ないけど、このロボットアームってAmazonで買ったら見ての通り12万円なのですが、何故かStrawberry Linuxでは4万2800円で買えるみたいです。
一体何が違うのでしょうね？
過去の記事について、誤解があったかもしれないので弁明しておきます。
「簡単とか簡易とか嘘ばっかり書いていると詐欺でつかまる」とか書きましたが、あれは半分冗談のつもりです。
「簡単に再現できる」と書いているけど本当に簡単に再現できるかどうか分からない場合や、タイトルに簡易とか書いているのに実際使ってみたら全然簡易じゃなかった場合とかありましたけど、あれはただの表現の一種なので実際に問題になることはないと思います。
単に僕は好ましくないと思っているだけです。嘘つき呼ばわりは少しやりすぎだったかもしれないです。
ただ、あまりに露骨に事実と違う事を書いてしまうとまずいかもしれないです。
ここから下は他の参加者に知ってもらいたいことを書きます。
まず、参加するうえで公式サイトは必ず読んでください。
僕も去年エントリー登録ができていなかったので、注意してください。
重要な点を抜き出すと、
エントリー登録
これは忘れがちなので必ずやっておいてください。
何故忘れるかと言うと、ログインしていないとそもそも入力フィールドが表示されないからだと思うので、まずはログインをしてください。
プロジェクトページに紹介ビデオを掲載することを推奨
これは割と重要だと思います。
あった方が分かりやすいです。
分かりやすいマニュアルを添付し、できるだけ第三者が結果を再現できるようにすること。
マニュアルを公開していない人が毎年多くいますが、公式ページを読んでいないのでしょうか？
特に某R大学の某研究室は毎年参加する割に誰もマニュアルを書いていないので、研究室内で徹底させた方がいいと思います。おそらくですが、大幅に減点されていると思います。
マニュアル・プロジェクトページを作成する際ですが、この作品のコメント欄が参考になるかもしれません。公式ページに書いてほしいぐらいの事を書いています。
参考にしたRTコンポーネントやソースコードがある場合は、マニュアル・論文中で出典を明記してオリジナル作者に敬意を払うこと。
これが一番重要です。
マニュアルには必ず明記してください。
予稿原稿にももちろん書くべきですが、SI2015の参加者にしか配布されないのであまり意味はないと思います。
最近やたらと取り上げますが、ドローンの作品はそもそもどれが自作のソースコードで、どれが外部のソースコードなのかの区別ができません。
同梱しているCV Droneのソースコードが作品の共同開発者のものならば問題はないのですが、全くの他人のものだった場合はかなりやばいです。
CV Droneのライセンスを記述したテキストファイルを同梱していないので、人のソースコードを不法に再配布して利益を得たという事になります。
配布してあるものだけを見たらCV Droneのソースコードも作品の一部だとしか思えません。
RTMコンテストから犯罪者は出したくないので、人のソースコードを再配布する際はライセンスに注意してください。
仮に僕のソースコードが再配布されていて、さらにライセンスを記述したテキストファイルを同梱していなかった場合を考えてみます。
これで何も利益が発生していない、ただ再配布しているだけならライセンスを同梱してもらえるように連絡するか、あるいはそれも面倒なので放置するかもしれません。
ただRTMコンテストのように賞金が出る場合、そうでなくても何らかの受賞をした場合は、コンテストの主催者に連絡して賞を撤回するように要求すると思います。
それができない場合は法的措置も考えます。
まあでもファイル1～2つぐらいなら影響はないとみて放置するとは思います。
似ているとか、参考にしたんだろうな程度の場合も放置します。
例えばthirdpartyという名前のフォルダに入っているとか、明らかに他人のソースコードだと分かる場合も気にしないと思います。
CV Droneの開発者の人がどう考えるかは知りませんけど、僕がその立場なら怒ります。
今更ですが、これはかなり重要な問題だと思うのでドローンの作品については白黒はっきりさせてほしいです。
黒(CV Droneの開発者が共著者ではない)の場合は事が大きくなる前に賞状と賞金を返還した方が良いかもしれません。
最近は某事件で研究の盗用とかに敏感になっているので、万が一訴えられた場合は共著者の先生が解雇されるという事態もありうるかもしれないです。
まあ流石に裁判沙汰にまではならないとは思いますけど。
ライセンスを記述したテキストファイルを同梱すれば再配布できるかどうかは何のライセンスかによります。
例えばLGPL、BSD、MIT、GPL等は大丈夫です。
まずはライセンスを確かめて、再配布可能かを確認してください。
ここからは、公式サイトに書いてある事以外で注意してほしいことを書きたいと思います。
まずビルド済み実行ファイルを付属している作品が多いのですが、必要なDLLが付属していないので動作できません。
公式サイトで複数バージョンのOpenRTM-aistをインストールすることは非推奨と書いてあります。環境変数の設定が面倒くさくなるので、できれば新たにOpenRTM-aistはインストールしたくありません。
必要なDLLを付属してくれるのがベストではあるのですが、付属させないのであればインストーラーから抽出する方法をマニュアルに書いてほしいです。
この件に関してまず勘違いしないでほしいのは、ビルド済み実行ファイルがあれば必ず動作できるというわけではないということです。特にOpenRTM-aist、OmniORB、OpenCV等の場合は動的にリンクしているのでDLLがないと動作できません。
それからデバッグビルドした実行ファイルを配布している人が何人もいますが、リリースビルドする事を推奨します。
あと、既存のソフトウェアに関しては必ず入念に調べてください。
wasanbonのリストに載っているRTCは特にチェックしておかないと、当日の質疑応答等で「僕も作ったが」とか言われることになります。その時点で大きな減点を喰らう事は間違いありません。
できるだけ簡単に動作確認できるように工夫をしてほしいです。
開発したのがRTシステムであるのならば、起動からシステムを復元する自動化スクリプトを作成してください。僕のツールを使ってくれてもいいのですが、wasanbon等のツールを使うと作業が楽になるかもしれません。
僕の勝手な考えですが、どうにも人の作品をちゃんと見ていないのではないかと思います。
人の作品の動作確認をしてみれば、自分の作品が動作できないかもしれないと気付くと思います。同じ原因で他の環境では動作できない作品は必ずあります。そしてその作品の開発者にもその事を教えてあげることで、自分、その作品の開発者、後から使う別のユーザーが全員幸せになれます。
後気を付けてほしいことはプロジェクトページのコメントへの返信ですかね。
こちらの質問と意図がずれている場合はもう一度質問するだけなので問題はないのですが、質問に答えずに丁寧なお礼だけを書くのはこちらもイラッとするのでやめてほしいです。例のごとくドローンの作品の事なんですけど。僕はあなたの指導をする立場の人間ではありません。アドバイスをもらったとか勘違いしないでほしいです。
後、こちらで間違いを修正してほしいといって本人も「修正します」と言ったのに、見てみたら修正されていないのは一体何なのでしょうね？これも(ry。
それなら最初から修正するなんて言わないでほしいです。
これはコメントへの対応が悪いというより、こちらとの認識の違いだとは思いますけど、以下の事はできればやめてほしいです。
RTCの粒度が細かすぎてシステムが分かりづらい
↓
各RTCの詳細な説明を追加します
これは何か違うと思います。
そもそもマニュアルに頼りすぎるというのが間違いで、マニュアルを読まなくても動作できるというのが理想です。
なのでこの場合は複合コンポーネントで細かい部分を隠蔽するか、あるいは粒度を大きくして作り直すかが正解だと思います。
まあ他にも色々言いたいことはありますけど、以前の記事で書いたことばかりなので省略します。
一番やってほしいことは他の作品にコメントを投稿してほしいという事なのでよろしくお願いします。
そういえばRTMではじめる ロボットアプリ開発が8月24日に発売されるらしいです。
今から楽しみです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
サインスマート製のロボットアームって7500円のものもあったみたいですね。
説明文のサバーってなんぞやって思いましたが、多分サーボの間違いでしょうか？
サインスマートなので説明書はついてこないでしょうし、マイコン等は自分で用意する必要はあると思うので、値段が安いからと言っても初心者には手を出しづらいと思います。
15000円とかならまだしも、7500円というとこのホビー用ロボットアームと値段が変わらないわけで、知識のない人が購入して全く動かし方が分からないなんていう事故が起こりそうです。
まずサインスマート製のロボットアームは6自由度、4自由度、2自由度＋グリッパーの製品があるわけですが、この製品単体では動かすことはできません。
何らかの方法でRCサーボにPWMを入力できるようにしなければなりません。
どうやらArduinoの使用を推奨しているようなので、持っていない人は購入してください。
一応このサイトに仕様らしきものは載っていますが、制御用のプログラムはどこにもないようですね。
まあでもArduinoでRCサーボを制御する方法を説明しているサイトなんてたくさんあるのでなんとかなるとは思います。
あと6自由度のロボットアームが少し値下げしたように見えるのですが、どうだったでしょうかね？
確か以前は25000円ぐらいだったような気がしますが、定かではありません。
それにしてもレビューを書いている人がいますが、なんだか独特の表現と言うか面白い事を書くなあと思いました。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
説明文のサバーってなんぞやって思いましたが、多分サーボの間違いでしょうか？
サインスマートなので説明書はついてこないでしょうし、マイコン等は自分で用意する必要はあると思うので、値段が安いからと言っても初心者には手を出しづらいと思います。
15000円とかならまだしも、7500円というとこのホビー用ロボットアームと値段が変わらないわけで、知識のない人が購入して全く動かし方が分からないなんていう事故が起こりそうです。
まずサインスマート製のロボットアームは6自由度、4自由度、2自由度＋グリッパーの製品があるわけですが、この製品単体では動かすことはできません。
何らかの方法でRCサーボにPWMを入力できるようにしなければなりません。
どうやらArduinoの使用を推奨しているようなので、持っていない人は購入してください。
一応このサイトに仕様らしきものは載っていますが、制御用のプログラムはどこにもないようですね。
まあでもArduinoでRCサーボを制御する方法を説明しているサイトなんてたくさんあるのでなんとかなるとは思います。
あと6自由度のロボットアームが少し値下げしたように見えるのですが、どうだったでしょうかね？
確か以前は25000円ぐらいだったような気がしますが、定かではありません。
それにしてもレビューを書いている人がいますが、なんだか独特の表現と言うか面白い事を書くなあと思いました。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
