こんなに苦戦するとは思わなかった

Intel Edison用のRTCを使ってくれた人がいたらしいのですが、なかなか動作せずに苦労を掛けてしまったようです。

• https://github.com/Nobu19800/RobotArmGUI/issues/1
• https://github.com/Nobu19800/RobotArmController/issues/1

流石にこれはまずいのでマニュアルも少し修正しました。



今気づいたのですが、地磁気センサの出力をTimedDoubleSeqにしたのは間違いでした。TimedVector3Dが正しいと思います。面倒なのでもう直しませんけど。





そういえばChoreonoid講習会があるらしいけど、その日はRTM講習会があるので参加できません。
参加のハードル高いなあ。Linuxが使えるだけで相当な上級者だという認識がありますが、確かにRTM講習会もせめてVisual StudioでC++のHello Worldぐらい作ってきてほしいとは思います。
講習会当日にVisual C++がインストールされていなかったというのはやめてほしいです。






それにしてもメーリングリストのあの件はあれでよかったのか謎です。
正直なところ「頑張ってOpenRTM-aistのソースコードを/MT・/MTdでビルドして静的ライブラリ作ってください」とだけ返信して丸投げしようかとも思っていたのですが、それではおそらく無理なので解説ページを作りました。
奇特な人は試してみてください。














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

冷静に考えるとおかしい

OpenRTMで使われているデータ型の説明ページを作成しました。
動画データや音声データのやり取りをするデータ型は無いので誰か作ってください。
と言うか、音声データは未だにTimedOctetSeq型使っているのか。誰か共通化してください。

RTMコンテストで共通化を推進したことを評価する賞なんてものもあっていいような気がしますが、僕は出さないので誰か出してください。


ロボットアームのTimedJointPos型があるのですが、これは同じ配列に距離と角度の違う次元の値を入れているのでよく考えたらおかしいような気もします。
ただ並進だろうが回転だろうが「アクチュエータの移動量」という意味は同じなので直感的には分かりやすいと思います。


おそらくActArrayActuatorGeometry型のようなデータ型の配列で表現するのが正しいのでしょうけど、それでプログラミングが難しくなったら本末転倒のような気もします。



個人的な見解として、パターン別のデータ型利用方法のページも作成中です。

同じ目的に手段が複数あるのは通常であれば悪い事ではないのですが、RTMにおいては邪魔にしかなりません。流石に言い過ぎかもしれませんが。








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

動けばいいという事ではない

中級者向けRTミドルウェア講習会はどうなったのでしょうね？
おそらく例の件は修正があったと思うのですが、あのままやっていたら色々とおかしなことになっていたので事前に知らせることができたのはよかったかもしれません。



データポートで通信する場合、格納するデータには色々な表現方法があるわけですが、基本的に距離の単位はメートルです。

「基本的には」というだけで、センチメートルの方が都合がいいのであればそういうデータ型があってもいいのですが、そもそもRangeData型に格納する距離の単位はメートルと決められているのでそれに従わなくてはなりません。
各々がセンチメートルだったり、尺・寸、インチ、フィートとバラバラな単位で値を入れていたら再利用なんてできるわけがありません。






さっき、「センチメートルの方が都合がいいのであればそういうデータ型があってもいい」と言いましたが、この論文に載っているようなのは個人的には駄目だと思っています。
角度をただのdegreeならまだしも、1/10degreeの単位で格納するとなると説明書を詳細に読まないと使えません。時間がmsec単位なのもよく分かりません。
おそらく全てのデータをTimedLongSeq型に格納するためにこうなっているのだと思いますけど、次元の違うデータを同じ配列に入れているので二重の間違いを犯しています。






データポートにしてもサービスポートにしても距離はメートル単位で表現するのが基本です。
力はN、時間はs、角度はrad、立体角はsr、周波数はHz、エネルギーはJ、質量はkgです。多分。

温度はどうなんでしょうね？
そういえば今まで作ったRTCでは°C単位で出力してたけど、ケルビンの方が正しいのか。
でも分かりづらいしなあ。日常生活でケルビン単位を使う人なんていないし。








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

Lua版RTミドルウェア構想(その6)

RTC-Library-FUKUSHIMAにLua版RTミドルウェアを登録しようと思ったのですが、RTCかRTシステムしか登録できないようなので断念しました。
まあRTCの登録や検索が目的みたいなので仕方ないです。
このサイトの場合はソフトウェアを登録するとトップページの最近の投稿に表示されるようなので多少人が来るかと思ったのですが残念です。




Lua版RTMの実装ですが、先は長そうなのでどこを実装するかを考えます。
まず、OpenRTM-aist 1.2の機能を全て実装するのは時間が無いので無理です。
徹底的に機能を削ります。


実行コンテキストはPeriodicExecutionContextのみ実装します。
データフロー型はPush型のみとします。
サブスクリプション型はもちろんFlushだけです。
複合コンポーネントは実装しません。
通信方法はCORBA通信のみです。
ロガー機能も省きます。
というかポートコールバックもコネクタコールバックもいりません。
SDOサービスは凄まじく面倒くさそうなので存在自体知らなかったことにします。



これで分かりやすくなりました。
大まかには、Manager→RTObject→ExecutionContext→Portの順番で実装します。
実行コンテキストは排他処理を考える必要が無いので、ある意味楽かもしれません。













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

Lua版RTミドルウェア構想(その5)

OpenRTM-aist-1.0以降では通信データをCDRという形式に直列化(マーシャリング)して送信しているわけですが、これによりマーシャリングしたバイナリデータの通信部分をCORBA通信から共有メモリ通信等に変更できるようになっています。

Oilでデータのマーシャリング、アンマーシャリングをするためには以下のようなコードを書く必要があります。



encoder = orb:newencoder()

encoder:put("abcde", orb.types:lookup("::OpenRTM::CdrData"))
--encoder:put({1,2,3}, oil.corba.idl.sequence{oil.corba.idl.long})
--encoder:put(133, oil.corba.idl.long)




decoder = orb:newdecoder(encoder:getdata())

val = decoder:get(orb.types:lookup("OpenRTM::CdrData"))
--val = decoder:get(oil.corba.idl.sequence{oil.corba.idl.long})
--val = decoder:get(oil.corba.idl.long)





あと、IDLファイルで定義した列挙型のデータを利用するには以下のようにします。

LifeCycleState = orb.types:lookup("::RTC::LifeCycleState").labelvalue
state = self.LifeCycleState.ACTIVE_STATE






Lua版のRTミドルウェア実装をしていて気づいたのですが、RTCがCreated状態だとRTシステムエディタ上で黒く表示されます。初めて知りました。






それから一応実装にはUUIDを生成する必要があるのですが、LuaにはデフォルトでUUID生成機能が無いのでどこからかライブラリを入手する必要があります。

とりあえず、このライブラリを使います。





これで実装に必要な準備は整ったのですが、面倒くさいのでやるかどうか未定です。










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