EdisonでOpenRTM-aist(RTC設計編その2)

例のロボットアームの6自由度版があるみたいですが、なんだか妙に高いですね。
そりゃ2つサーボが追加はされていますけど、機構は簡単になってそうなので部品の数は減ってそうな感じに見えるのですが。
まあ別に買う予定なんてないので気にしない事にします。
4自由度の方はそれなりに売れているみたいです。
公式サイトを読んでて気づいたのですが、一応arduinoで制御するためのサンプルプログラムはあったみたいです。仕様書がないので使い方はよくわかりませんが、サインスマート製の製品ではよくあることらしいですね。一体他の人はどんなプログラムで制御しているのか気になります。





それはさておき、I2CのデバイスをどのようにRTCとして実装するかを考えています。
Raspberry Piですけど参考になりそうな資料があったのでちょっと読んでみました。

Pi_I2CSensorというサンプルプログラムを読んでみたのですが・・・なんだか色々と疑問があります。
まずセンサで取得した値は角速度ならrad/sに変換して出力すべきではないか？と思います。TimedLong型で出力したデータを使いたい人なんてほとんどいないと思います。

後、その辺りも含めてセンサごとに別ファイルに処理を分離しておけば他の人が使う場合も使いやすいかもしれないです。

まあ実際の使用例がないので実際使ってみたら今のままの方が使いやすいとかなのかもしれませんけど、正直想像ができません。



一番下のスケジューリングの問題ですが、アーム制御のPCA9685搭載PWM/サーボ ドライバーのRTCとクローラー制御関連のセンサRTCは分離したいのでセマフォで排他制御をします。


ただ、I2Cに限らず全てセンサで個別にRTCを実装するのは使いづらくなるだけなのでやめておきます。
この場合何が問題になるかと言うとオーバーヘッドやシステムの見通しの悪さももちろんそうですが、RTCが同期していないと必要な時にデータを取得できてないかもしれない事が最大の問題です。おそらくセンサの情報をもとに何らかの制御をする事も多いとは思いますが、例えばisNew関数でデータが到着していると判断したとき、あるいはそのデータがある値以上の場合のみなんらかの制御をするのであれば同期する必要はありません。しかし複数のセンサのデータを必要とする場合、フィードバック制御等で連続的に制御する場合はRTCが同期している必要がありそうです。そのために複合コンポーネントにしたり実行コンテキストを共有するのは正直面倒くさいです。RTCの粒度を小さくすることで拡張性を高くしたつもりが、その使いづらさで逆に機能の変更、拡張がやりづらくなると思います。以前GUI上でクリックした座標を他のRTCに送信してそのRTCで何らかの処理をするRTCを見た事がありますが、その両方のRTCでGUIで何を表示しているのか、大きさはどのぐらいか等を共有しておく必要があるのでソースコードを書きかえるよりも拡張するのが難しくなっていると言う印象を持ちました。結果的に使いづらくなったしまっては意味がありません。
実行コンテキストを共有していなくてもサービスポートを使うか、あるいはコネクタコールバックを使えばセンサのデータを取得したタイミングで何らかの処理を実行する事は可能ですが、サービスポートを使うと再利用性が低くなりますし、コネクタコールバックを使う場合は複数のセンサのデータを必要とする場合の処理が難しくなるのでやめておきます。


少し考えてみたのですが、

1. RTC1でセンサのデータを取得
2. RTC1からRTC2にデータを送信
3. RTC2でデータが到着していれば何らかの処理をする

ではなくて、

1. RTC2からRTC1にデータの送信を要求する
2. RTC1でセンサのデータを取得
3. RTC1からRTC2にデータを送信
4. RTC2で何らかの処理をする

と言う事がサービスポートを使わずにできれば同期とか考えなくてもよいのではないかと思いました。センサのデータを送信するデータポートとは別にRTC2にOutPort、RTC1にInPortを追加してコネクタコールバックを使えば実現できそうですがデータポートを無暗に増やすとRTCの機能が見た目からは分かりづらくなるのでやめておきましょう。



最初からRTCとして機能を分割する事は考えずにファイルやライブラリとして分割する事をまず考えた方が良いかもしれません。そこからRTCで実装した方が便利な部分を見つけていけばよいシステムが出来上がるのではないでしょうか？








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