補足等

EdisonのBreakout Boardは持っていないのでよく分かりませんが、アナログ入力ができるのはArduinoボードだけらしいです。
まあそりゃEdison自体にADCの機能がないのだからBreakout Boardにもないか。
ちなみにArduinoボードにはADS7951というADCを搭載しているみたいです。


一応、MCP3002にSPIで通信して電圧値を取得するプログラムを作ってはみました。
ここからダウンロードできます。
まあとりあえず試してみると言う事で作ってみただけなので実用性はないです。
ライブラリにしておいた方が便利かもしれません。
ついでにPythonでも作成してみました。
ここからダウンロードできます。



完全に余談ですけど、I2CやSPIのプログラムを作っているとバイナリデータからint、floatへの変換をする必要があると思います

たとえばC++で記述すると、


int x = (x_h << 8) | x_l;


のように記述できると思います。


これをPythonで記述すると、


b = chr(x_h) + chr(x_l)
x = struct.unpack('h', b)[0]



これで一応同じ動作にはなります。










にほんブログ村のロボットのカテゴリから
全然人が来ない・・・

思考中

ひょっとしたらジャイロセンサ、地磁気センサ、加速度センサとの通信処理、姿勢の算出を別の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自由度マニピュレータの手先位置制御ぐらいならできるかもしれないです。












にほんブログ村のロボットのカテゴリから
全然人が来ない・・・

マニュアル更新

昨日作成したマニュアルを加筆しました。


よく考えてみたらシステム構成図が無かったので追加しました。


ただ、このマニュアルを読んでシステムを再現できるかと言われればかなり難しいと思います。
Edisonを使わずにArduinoで制御するシステム例も用意したのですが、あのシステムの説明を増やした方が良いかもしれません。こちらの方が再現するのが簡単なので、とりあえずこちらを確実に再現できるようにしておきたいです。
まあベストなのはマニュアルを読まずに再現する事ですけどね。



OpenRTM-aistはEdisonとかRaspberry Piなどシングルボードコンピュータで動作させてこそ本領が発揮できるのではないかと思いました。通信の処理を簡単に記述できるのもそうですが、RTシステムエディタで起動したRTCを操作できるのが大きいと思います。今回作成したシステムのようにアームの制御のみを行うか、クローラーの制御のみを行うか、あるいは両方の制御を行うかの切り替えが容易にできます。どちらしかハードウェアがない場合がほとんどだと思うので地味に便利かもしれません。
Edisonで各GPIOの操作するRTC、あるいはI2C、SPIでデバイスを制御するRTCを自動起動するようなプログラムを作成して自動起動しておくようにしておけばプロトタイピングツールとして使う事もできるかもしれません。






にほんブログ村のロボットのカテゴリから
全然人が来ない・・・

GUIを更新しました

よく分かりませんが、あるRTC_Aから別のRTC_Bのコンフィギュレーションパラメータを変更する状況がありえるのでしょうか？
RTC_Aにコンフィギュレーションパラメータ変更のプログラムを記述しなければならないわけで再利用性が著しく下がりそうです。サービスポートを使った方が良いと思います。
いやでも他のRTCでパラメータを変更したいけどRTシステムエディタやrtshellでも変更したい場合はあるかもしれないです。その場合はサービスポートとコンフィギュレーションパラメータを両方用意した方が簡単だとは思いますけど。



それはさておきGUIを更新しました。
CEGUIを最新版に合わせるのは大変でした。

とりあえずそれに合わせてマニュアルも作成しました。
まだ完成度が低いので修正していきたいとは思っています。

未だにGUIの動作が怪しいのも問題です。
何が原因でDirect3Dでのみ動作したり、OpenGLでのみ動作したりするのかが分かりません。
まあ大抵の場合OpenGLで動作できるのでOpenGLでレンダリングしてください。








にほんブログ村のロボットのカテゴリから
全然人が来ない・・・

EdisonでOpenRTM-aist(考察編)

クローラー制御RTCにジャイロセンサ、加速度センサ、地磁気センサ、距離センサの機能を詰め込んだわけですが、正しい設計だったかどうかは微妙ですね。

ただ個別にRTCを作ってしまうとシステムが分かりづらくなるのもそうですし、複合コンポーネント化等をして同期させる必要も出てくるのが非常に面倒くさいのであまりやりたくはないです。

デバッグが難しくなるのもそうですし、別スレッドで処理する必要性もないどころか上で言ったように同期させる必要があるので、個別にRTCを作る利点がないと思っています。

これが画像処理とか絡んできたら別スレッドで処理する必要性も出てくるかもしれませんけど。


何が最大の問題かと言うとセンサの値をそのまま出力するRTCを作成したとして、大抵の場合その値をそのまま使う事は出来ないと言う事だと思います。
データ受信側のRTCで変換処理をするのであればまだ良いのですが、変換RTCを挟んだりすると一気にシステムの見通しが悪くなるのでできればやってほしくないです。
ましてや単位の設定を適当にやっていると変換RTCが必須になるので、単位には特に注意してください。

ひょっとしたらRTCが10個以上動作する大規模なシステムになったら、RTCが一つ落ちてもrtcdで同一プロセスで起動していない限り他のRTCが一緒に落ちる事はないので、RTCが落ちた事に気付かないなんて事もありえない話ではないかもしれないです。


RTCとして分割するかどうかは以下の基準で判断できるかなあと思います。

• 他のモジュールで置き換える事が可能か？

→置き換える事ができないのであれば全く分割する必要はありません

• 変換RTCを挟む必要はあるか？

→変換RTCが必要ならば極力分割する事は避けるべき

• 同期する必要があるか？

→複合コンポーネント化等が必要になるとデバッグが面倒になるので再考すべき

• マルチスレッドで処理する必要はあるか？

→必要ならばやるメリットはあると思います

• リアルタイムが要求されるか？

→rtcdでの起動、複合コンポーネント化が必須なため考え直した方が良いと思う。ただし片方のRTCをリアルタイム化する必要があるのなら、むしろ分割した方が良いと思います

• 他の言語で作成したRTCと連携させる必要はあるか？

→それが容易にできるのがRTMの特徴でもあるので、必要ならばやっても構わない



後はオーバーヘッドの影響やら分割後の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が削除された事により発生したエラーがほとんどなので、その辺を何とかしなくてはなりません。



まだまだ時間がかかりそうです。
















にほんブログ村のロボットのカテゴリから
全然人が来ない・・・