ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
ひょっとしたらジャイロセンサ、地磁気センサ、加速度センサとの通信処理、姿勢の算出を別のRTCに分離した方が良かったかもしれません。それで姿勢をOutPortから出力するようにしておいた方が再利用性があったかもしれません。
今後変更するかもしれないです。
ただ、センサごとにRTCを作るのは前から言っているように間違いだと思っています。
今回の場合だと姿勢の計算まで含めるべきですし、その計算に必要なセンサ(今回の場合ジャイロセンサ、地磁気センサ、加速度センサ)の計測値取得は単一のRTCで処理すべきだとは思います。
つまりこれは間違いです。
この4つのRTCは単一のRTCで実装するべきです。
一見各センサの置き換えが容易になりそうな感じに見えますが、このシステムを作るのに手間がかかるので反って面倒になります。
RTCの数が増えれば増えるほど他の人がそのシステムを理解するのが困難になるので、細分化しすぎには注意してください。
一応Edisonで制御するロボットを作ってみたわけですが、今の所Edisonの値段の高さに見合うほど有効な使い方ができていないと思っています。
単純にモーター制御とかしたいだけならAVRみたいな8bitマイコンを使えば良いですし、マニピュレータの制御とか複雑な計算が絡んできたらSH2みたいな32bitマイコンを使えば良いと思うので個人で使う分にはシングルボードコンピュータは手に余ると思います。
Linuxが動作するので通常のPCで動作しているソフトウェアが使えたり、Pythonとかでプログラミングができたりメリットはあるけど、あまり有効には使えていませんからね。
まあこれからEdisonで動作するRTCを増やしたり、他の人の作成したRTCを使ってみたりする中で何らかのメリットを見出せるかもしれないので試行錯誤してみます。
あまり関係ないけど、どのような処理の時に8bitマイコンを使うか、32bitマイコンを使うかあまり理解していなかったので調べてみました。 このサイトなんか参考になるかなと思ったのですが、どうにもATmega168Pの結果が怪しいです。こちらでもSH7144FとATmega168Pで調べてみたのですが、SH7144Fは似たような結果になりましたがATmega168Pは行列計算(float)の計算が10msぐらいだったので大きく違う結果になりました。 8倍ぐらい違うと言う事は発振クロックを8分周にしているからこうなっているのかもしれません。
それにしてもSH7144Fは50MHzの32bitで、ATmega168Pは20MHzの8bitなんだからもっと差が開きそうですが4～5倍ぐらいの差しかないのですからどこで使い分けるかは微妙ですね。
ATmega168Pでも3自由度マニピュレータの手先位置制御ぐらいならできるかもしれないです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
今後変更するかもしれないです。
ただ、センサごとにRTCを作るのは前から言っているように間違いだと思っています。
今回の場合だと姿勢の計算まで含めるべきですし、その計算に必要なセンサ(今回の場合ジャイロセンサ、地磁気センサ、加速度センサ)の計測値取得は単一のRTCで処理すべきだとは思います。
つまりこれは間違いです。
この4つのRTCは単一のRTCで実装するべきです。
一見各センサの置き換えが容易になりそうな感じに見えますが、このシステムを作るのに手間がかかるので反って面倒になります。
RTCの数が増えれば増えるほど他の人がそのシステムを理解するのが困難になるので、細分化しすぎには注意してください。
一応Edisonで制御するロボットを作ってみたわけですが、今の所Edisonの値段の高さに見合うほど有効な使い方ができていないと思っています。
単純にモーター制御とかしたいだけならAVRみたいな8bitマイコンを使えば良いですし、マニピュレータの制御とか複雑な計算が絡んできたらSH2みたいな32bitマイコンを使えば良いと思うので個人で使う分にはシングルボードコンピュータは手に余ると思います。
Linuxが動作するので通常のPCで動作しているソフトウェアが使えたり、Pythonとかでプログラミングができたりメリットはあるけど、あまり有効には使えていませんからね。
まあこれからEdisonで動作するRTCを増やしたり、他の人の作成したRTCを使ってみたりする中で何らかのメリットを見出せるかもしれないので試行錯誤してみます。
あまり関係ないけど、どのような処理の時に8bitマイコンを使うか、32bitマイコンを使うかあまり理解していなかったので調べてみました。 このサイトなんか参考になるかなと思ったのですが、どうにもATmega168Pの結果が怪しいです。こちらでもSH7144FとATmega168Pで調べてみたのですが、SH7144Fは似たような結果になりましたがATmega168Pは行列計算(float)の計算が10msぐらいだったので大きく違う結果になりました。 8倍ぐらい違うと言う事は発振クロックを8分周にしているからこうなっているのかもしれません。
それにしてもSH7144Fは50MHzの32bitで、ATmega168Pは20MHzの8bitなんだからもっと差が開きそうですが4～5倍ぐらいの差しかないのですからどこで使い分けるかは微妙ですね。
ATmega168Pでも3自由度マニピュレータの手先位置制御ぐらいならできるかもしれないです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
昨日作成したマニュアルを加筆しました。
よく考えてみたらシステム構成図が無かったので追加しました。
ただ、このマニュアルを読んでシステムを再現できるかと言われればかなり難しいと思います。
Edisonを使わずにArduinoで制御するシステム例も用意したのですが、あのシステムの説明を増やした方が良いかもしれません。こちらの方が再現するのが簡単なので、とりあえずこちらを確実に再現できるようにしておきたいです。
まあベストなのはマニュアルを読まずに再現する事ですけどね。
OpenRTM-aistはEdisonとかRaspberry Piなどシングルボードコンピュータで動作させてこそ本領が発揮できるのではないかと思いました。通信の処理を簡単に記述できるのもそうですが、RTシステムエディタで起動したRTCを操作できるのが大きいと思います。今回作成したシステムのようにアームの制御のみを行うか、クローラーの制御のみを行うか、あるいは両方の制御を行うかの切り替えが容易にできます。どちらしかハードウェアがない場合がほとんどだと思うので地味に便利かもしれません。
Edisonで各GPIOの操作するRTC、あるいはI2C、SPIでデバイスを制御するRTCを自動起動するようなプログラムを作成して自動起動しておくようにしておけばプロトタイピングツールとして使う事もできるかもしれません。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
よく考えてみたらシステム構成図が無かったので追加しました。
ただ、このマニュアルを読んでシステムを再現できるかと言われればかなり難しいと思います。
Edisonを使わずにArduinoで制御するシステム例も用意したのですが、あのシステムの説明を増やした方が良いかもしれません。こちらの方が再現するのが簡単なので、とりあえずこちらを確実に再現できるようにしておきたいです。
まあベストなのはマニュアルを読まずに再現する事ですけどね。
OpenRTM-aistはEdisonとかRaspberry Piなどシングルボードコンピュータで動作させてこそ本領が発揮できるのではないかと思いました。通信の処理を簡単に記述できるのもそうですが、RTシステムエディタで起動したRTCを操作できるのが大きいと思います。今回作成したシステムのようにアームの制御のみを行うか、クローラーの制御のみを行うか、あるいは両方の制御を行うかの切り替えが容易にできます。どちらしかハードウェアがない場合がほとんどだと思うので地味に便利かもしれません。
Edisonで各GPIOの操作するRTC、あるいはI2C、SPIでデバイスを制御するRTCを自動起動するようなプログラムを作成して自動起動しておくようにしておけばプロトタイピングツールとして使う事もできるかもしれません。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
よく分かりませんが、あるRTC_Aから別のRTC_Bのコンフィギュレーションパラメータを変更する状況がありえるのでしょうか？
RTC_Aにコンフィギュレーションパラメータ変更のプログラムを記述しなければならないわけで再利用性が著しく下がりそうです。サービスポートを使った方が良いと思います。
いやでも他のRTCでパラメータを変更したいけどRTシステムエディタやrtshellでも変更したい場合はあるかもしれないです。その場合はサービスポートとコンフィギュレーションパラメータを両方用意した方が簡単だとは思いますけど。
それはさておきGUIを更新しました。
CEGUIを最新版に合わせるのは大変でした。
とりあえずそれに合わせてマニュアルも作成しました。
まだ完成度が低いので修正していきたいとは思っています。
未だにGUIの動作が怪しいのも問題です。
何が原因でDirect3Dでのみ動作したり、OpenGLでのみ動作したりするのかが分かりません。
まあ大抵の場合OpenGLで動作できるのでOpenGLでレンダリングしてください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
RTC_Aにコンフィギュレーションパラメータ変更のプログラムを記述しなければならないわけで再利用性が著しく下がりそうです。サービスポートを使った方が良いと思います。
いやでも他のRTCでパラメータを変更したいけどRTシステムエディタやrtshellでも変更したい場合はあるかもしれないです。その場合はサービスポートとコンフィギュレーションパラメータを両方用意した方が簡単だとは思いますけど。
それはさておきGUIを更新しました。
CEGUIを最新版に合わせるのは大変でした。
とりあえずそれに合わせてマニュアルも作成しました。
まだ完成度が低いので修正していきたいとは思っています。
未だにGUIの動作が怪しいのも問題です。
何が原因でDirect3Dでのみ動作したり、OpenGLでのみ動作したりするのかが分かりません。
まあ大抵の場合OpenGLで動作できるのでOpenGLでレンダリングしてください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
クローラー制御RTCにジャイロセンサ、加速度センサ、地磁気センサ、距離センサの機能を詰め込んだわけですが、正しい設計だったかどうかは微妙ですね。
ただ個別にRTCを作ってしまうとシステムが分かりづらくなるのもそうですし、複合コンポーネント化等をして同期させる必要も出てくるのが非常に面倒くさいのであまりやりたくはないです。
デバッグが難しくなるのもそうですし、別スレッドで処理する必要性もないどころか上で言ったように同期させる必要があるので、個別にRTCを作る利点がないと思っています。
これが画像処理とか絡んできたら別スレッドで処理する必要性も出てくるかもしれませんけど。
何が最大の問題かと言うとセンサの値をそのまま出力するRTCを作成したとして、大抵の場合その値をそのまま使う事は出来ないと言う事だと思います。
データ受信側のRTCで変換処理をするのであればまだ良いのですが、変換RTCを挟んだりすると一気にシステムの見通しが悪くなるのでできればやってほしくないです。
ましてや単位の設定を適当にやっていると変換RTCが必須になるので、単位には特に注意してください。
ひょっとしたらRTCが10個以上動作する大規模なシステムになったら、RTCが一つ落ちてもrtcdで同一プロセスで起動していない限り他のRTCが一緒に落ちる事はないので、RTCが落ちた事に気付かないなんて事もありえない話ではないかもしれないです。
RTCとして分割するかどうかは以下の基準で判断できるかなあと思います。
後はオーバーヘッドの影響やら分割後のRTCの数などを考えれば適当な粒度のRTCが出来あがりそうな感じはします。
他のモジュールで置き換えができないのであればその時点で分割する事はやめるべきと言うのは間違いないと思っていますが、他は各自の裁量次第なので明確な答えはありません。
Ogre3Dについて調べてみたところ、SDKの1.9.0にはRenderSystem_Direct3D11.dllが付いてくるのですが、1.8.1にはRenderSystem_Direct3D9.dllしか同梱されていないらしい。自分でビルドすれば作成できるとは思いますけど。
さすがにそろそろOgre3D、CEGUIのバージョンが古くなってきたので、Ogre3Dは1.9.0、CEGUIは0.8.4を使う事にします。
・・・と思っていたのですがCEGUIの仕様変更が多いためエラーを大量に出ます。
CEGUI::colourがCEGUI::Colourになっていたのは理解に苦しみます。
とりあえず今気付いた点だけでも以下の変更があるみたいです。
まだまだ時間がかかりそうです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
ただ個別にRTCを作ってしまうとシステムが分かりづらくなるのもそうですし、複合コンポーネント化等をして同期させる必要も出てくるのが非常に面倒くさいのであまりやりたくはないです。
デバッグが難しくなるのもそうですし、別スレッドで処理する必要性もないどころか上で言ったように同期させる必要があるので、個別にRTCを作る利点がないと思っています。
これが画像処理とか絡んできたら別スレッドで処理する必要性も出てくるかもしれませんけど。
何が最大の問題かと言うとセンサの値をそのまま出力するRTCを作成したとして、大抵の場合その値をそのまま使う事は出来ないと言う事だと思います。
データ受信側のRTCで変換処理をするのであればまだ良いのですが、変換RTCを挟んだりすると一気にシステムの見通しが悪くなるのでできればやってほしくないです。
ましてや単位の設定を適当にやっていると変換RTCが必須になるので、単位には特に注意してください。
ひょっとしたらRTCが10個以上動作する大規模なシステムになったら、RTCが一つ落ちてもrtcdで同一プロセスで起動していない限り他のRTCが一緒に落ちる事はないので、RTCが落ちた事に気付かないなんて事もありえない話ではないかもしれないです。
RTCとして分割するかどうかは以下の基準で判断できるかなあと思います。
- 他のモジュールで置き換える事が可能か？
- 変換RTCを挟む必要はあるか？
- 同期する必要があるか？
- マルチスレッドで処理する必要はあるか？
- リアルタイムが要求されるか？
- 他の言語で作成したRTCと連携させる必要はあるか？
後はオーバーヘッドの影響やら分割後のRTCの数などを考えれば適当な粒度のRTCが出来あがりそうな感じはします。
他のモジュールで置き換えができないのであればその時点で分割する事はやめるべきと言うのは間違いないと思っていますが、他は各自の裁量次第なので明確な答えはありません。
Ogre3Dについて調べてみたところ、SDKの1.9.0にはRenderSystem_Direct3D11.dllが付いてくるのですが、1.8.1にはRenderSystem_Direct3D9.dllしか同梱されていないらしい。自分でビルドすれば作成できるとは思いますけど。
さすがにそろそろOgre3D、CEGUIのバージョンが古くなってきたので、Ogre3Dは1.9.0、CEGUIは0.8.4を使う事にします。
・・・と思っていたのですがCEGUIの仕様変更が多いためエラーを大量に出ます。
CEGUI::colourがCEGUI::Colourになっていたのは理解に苦しみます。
とりあえず今気付いた点だけでも以下の変更があるみたいです。
- CEGUIFalagardWRBase.lib → CEGUICoreWindowRendererSet.lib
- colour → Colour
- colourRect → ColourRect
- removeChildWindow → removeChild
- addChildWindow → addChild
- 文字変換 PropertyHelper::型名ToString → PropertyHelper<型>::toString
- Vector3にテンプレート引数を指定
- Checkbox → ToggleButton
- EventCheckStateChanged → EventSelectStateChanged
- setGUISheet → setRootWindow
- setRotationの引数 Quatanionのみ(Vector2Dは不可) 変換にはeulerAnglesRadiansを使用
- setSizeの引数 USizeのみ(Vector2Dは不可)
- Sizeにテンプレート引数を指定
- Point mousePos = MouseCursor::getSingleton().getPosition(); → Vector2f mousePos = System::getSingleton().getDefaultGUIContext().getMouseCursor().getPosition();
- ImageSet → Image
- ImagesetManager → ImageManager
- Pointが削除、Vector2を使用
- Systemの関数が一部GUIContextに移動
未だに20個以上のエラーが残っている状態で修正がなかなか終わりません。
特にImageSetが削除された事により発生したエラーがほとんどなので、その辺を何とかしなくてはなりません。まだまだ時間がかかりそうです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
突然ですがクイズです。
下の画像の白い物体は何でしょうか？
解答はこの記事の最後にします。
それはさておき、何をやるのか決まっていない状態なのでとりあえず絵に描いてみるとします。
まずは貯金できない人用に財布から金を無理やり強奪して貯金するロボットを考えました。
ドラえもんでこんな道具があったような気がします。
まずこっそり、もしくは無理やり財布を奪い取ります。
そしてハンドで財布の小銭入れを開くのは困難なので何らかの方法で財布を破壊します。上のGIFアニメでは仮定はよく分かりませんが真っ二つになっています。
そして中身から10円を取り出してロボット本体に設置しておいた容器に入れます。
すごい完璧じゃないか！！！！
・・・・何を言っているのかよく分からなくなってきたのでこの辺でやめておきます。
他にも色々と考えたのですが絵に描くのが非常に面倒くさいのでやめておきます。
上の糞くだらないGIFアニメでも5枚も絵を描いてあるので決して楽な作業ではありません。
あまり関係ないけど、Edisonを使ってロボットを制御する上で気付いた事を書いておきます。
まずArduinoと通信させようと思ってEdisonのUSBポートにUSBシリアル変換ケーブルを差してみたのですが認識してくれませんでした。FTDIドライバがインストールされていないと言う事でしょうかね？
とか考えていたのですが、冷静に考えればRXピン、TXピンに接続すれば良かっただけだったかもしれないですね・・・・試してないけど。
インクリメンタルエンコーダもタコジェネレータも持っていないので今の所クローラーの速度制御はできていません。
となるとこのサイトみたいに逆起電力から推定するという方法もあります。
そうなるとEdisonから直接制御するのは無理そうなので別のマイコンで制御する必要がありそうです。それはそれで部品が増えるので嫌だなあ。
何かいい方法はないかと探してみるとこれなんか面白そうだと思いました。
大した精度が要求されるわけでもないですし、これでも良いかもしれないです。
特に答え合わせする必要もないと思いますけど、一応クイズの解答をしたいと思います。
正解は猫でした。
どうでもいいけど、ロボットで猫の柔らかさは絶対に表現できないと思う。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
下の画像の白い物体は何でしょうか？
解答はこの記事の最後にします。
それはさておき、何をやるのか決まっていない状態なのでとりあえず絵に描いてみるとします。
まずは貯金できない人用に財布から金を無理やり強奪して貯金するロボットを考えました。
ドラえもんでこんな道具があったような気がします。
まずこっそり、もしくは無理やり財布を奪い取ります。
そしてハンドで財布の小銭入れを開くのは困難なので何らかの方法で財布を破壊します。上のGIFアニメでは仮定はよく分かりませんが真っ二つになっています。
そして中身から10円を取り出してロボット本体に設置しておいた容器に入れます。
すごい完璧じゃないか！！！！
・・・・何を言っているのかよく分からなくなってきたのでこの辺でやめておきます。
他にも色々と考えたのですが絵に描くのが非常に面倒くさいのでやめておきます。
上の糞くだらないGIFアニメでも5枚も絵を描いてあるので決して楽な作業ではありません。
あまり関係ないけど、Edisonを使ってロボットを制御する上で気付いた事を書いておきます。
まずArduinoと通信させようと思ってEdisonのUSBポートにUSBシリアル変換ケーブルを差してみたのですが認識してくれませんでした。FTDIドライバがインストールされていないと言う事でしょうかね？
とか考えていたのですが、冷静に考えればRXピン、TXピンに接続すれば良かっただけだったかもしれないですね・・・・試してないけど。
インクリメンタルエンコーダもタコジェネレータも持っていないので今の所クローラーの速度制御はできていません。
となるとこのサイトみたいに逆起電力から推定するという方法もあります。
そうなるとEdisonから直接制御するのは無理そうなので別のマイコンで制御する必要がありそうです。それはそれで部品が増えるので嫌だなあ。
何かいい方法はないかと探してみるとこれなんか面白そうだと思いました。
大した精度が要求されるわけでもないですし、これでも良いかもしれないです。
特に答え合わせする必要もないと思いますけど、一応クイズの解答をしたいと思います。
正解は猫でした。
どうでもいいけど、ロボットで猫の柔らかさは絶対に表現できないと思う。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
