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

中級者向け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生成機能が無いのでどこからかライブラリを入手する必要があります。

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





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










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

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

どうも一部のソフトウェアでOilのCORBA通信が上手くいかないことがあるらしい。
ネームサーバーへの登録などクライアント側で動作する分には問題ないのですが、サーバー側で動作しているときにクライアントから操作しようとした瞬間に落ちます。

調べてみた結果、Oilの使用しているLOOPライブラリのCoSocket.luaの以下の部分で落ちていることが分かりました。






function select(self, recvt, sendt, timeout) 

・・・・・

local readok, writeok, errmsg = scheduler.select(recvt, sendt, 0)

・・・・

readok[#readok+1] = wrapper






どうやら、scheduler.select関数でLuaSocketライブラリのselect関数が呼ばれているらしく、このselect関数で取得したテーブルに上みたいに要素を追加しようとすると途端に落ちます。


落ちるコードの簡単な例は以下の通りなので、今後Oil、というかLOOPを使う予定のある人は試してみてください。






local socket = require( "socket" )

local server = socket.bind("localhost", 2810)
local servers = {server}
local readok = socket.select(servers, nil, 0)
readok[1] = 100






ちなみに、以下のような感じでテーブルをコピーしてから処理すると何も問題は起こらないので、場合によってはLOOPライブラリの修正が必要です。



local readok, writeok, errmsg = scheduler.select(recvt, sendt, 0)

readok = {unpack(readok)}

writeok = {unpack(writeok)}

OilもLOOPも2008年ごろから開発が止まっているみたいなので、不具合があったら自分で何とかするしかありません。





正直これの原因究明はかなりきつかったと思います。
エラーが出るならともかく、突然落ちる理由が見当もつかず、調べるのに1週間近くかかりました。

おそらくですが、この修正をする事で20以上のソフトウェア上にOilを使用したLuaスクリプトを組み込むことができるようなります。
つまりLua版RTミドルウェアも動作できます。




まあ問題はLua版RTミドルウェアの中身が全く実装できていない事ですけど、気が向いたら作業はするかもしれないですし、飽きたらやめるかもしれません。













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

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

LuaはC/C++等の他の言語に組み込むのが主な用途なので、既存のLuaが使えるソフトウェアに適用できるかを考えてみます。

考えた結果が以下の通りです。



○V-rep
△Snes9x-ReRecording
×AviUtl、RigidChips




V-repは問題なく使えます。
ただ、simSetThreadAutomaticSwitch関数により自動的にスレッドを切り替える機能を無効にすることと、実行コンテキストでsimSwitchThread関数を呼び出してLua側でスレッドを切り替える必要があるので、やや工夫が必要です。


Snes9x-ReRecordingのようなEmuLuaには一つ重大な問題があります。
Luaスクリプト内でフレームを進めるように命令するためにはframeadvance関数を使う必要がありますが、これがコルーチンからは呼び出せません。なので、Loopライブラリを改変してframeadvance関数を呼び出してやります。

thread/Scheduler.luaのrun関数を改変します。





local snes9x      = require "snes9x"
・・・・・

function run(self, ...)
・・・・・

snes9x.frameadvance()

return self:run()

こういうソフトウェアを出すと炎上する可能性があるのですが、別にエミュレータ自体は違法ではないので叩くのはやめてください。
ただ、Luaライブラリのバージョンが違うとクラッシュするという情報もあるので、動作できるかは不明です。

AviUtlのスクリプトはフレームごとに実行して画像を動かしたりするようなので不可能です。
RigidChipsもシミュレーションのステップごとにスクリプトを実行するようなので無理です。






調べてみた感じですが、多少の需要はありそうな感じです。











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