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

RTミドルウェアを実装する上で重要の要素として実行コンテキストがあるわけですが、LuaのC APIはマルチスレッドで動作させることができません。

上のリンクのサイトではC側のプログラムで並列処理ができるようにしていますが、Luaだけでやろうと思うとこのようなコルーチンによる疑似マルチスレッドを使うことになります。
yieldで処理を中断して、他の処理に移るということなので、見かけ上は並列にしているように見えます。
つまりyieldで中断しなければ永久に他の処理は実行されません。
oilの中身もこんな感じの処理をしているので、同じようにyieldで中断すれば実行コンテキストも実装できます。

local coroutine = require "coroutine"

ExecutionContext = {}

ExecutionContext.new = function()

local obj = {}

obj.run = function()

while true do

print("run")

coroutine.yield(1)

end

end

return obj

end

oil.main(function()
・・・・・

　　ec = ExecutionContext.new()

　　oil.newthread(ec.run)

あと、V-rep等でoil実行の際に必要なファイルについてメモしておきます。

luaフォルダからは以下のファイル、フォルダをコピーします。

• oil.lua
• luaidl.lua
• socket.lua※
• oil
• luaidl
• loop
• socket※

LuaSocketのライブラリはV-Repには最初から入っているので不要です。

さらにclibsフォルダからCモジュールをコピーする必要があります。

• oil/bit.dll
• socket/core.dll※

socket/core.dllはV-Repには最初から入っているので不要です。











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

Lua版RTミドルウェア構想

Lua for WindowsのインストーラーでLuaをインストールするとOilというライブラリが付いてきます。
これはLuaのCORBA実装なので、C++、PythonのomniORB等の他のCORBA実装とも通信できます。
このOilを使う事で、RTミドルウェアのLua実装を開発する事もできます。



これはネームサーバー、RTシステムエディタと通信してRTCを活性化したときにアクティブ状態に遷移して、非活性化したときに非アクティブ状態に遷移するだけの実装なので、中身はほとんど実装できていません。

一応ソースコードはここにあります。



Oilの使い方に関する資料が極めて少なく調べるのに苦労したので、今後のためにいくつかメモを書いておきます。

ORBの初期化の引数なのですが、以下のようにludoを入れるとLuDOという謎機能で通信をするようなので入れないようにしてください。


orb = oil.init{ flavor = "ludo;cooperative;base", port = 2810 }


とりあえず、以下のように初期化します。


local orb = oil.init{ flavor = "intercepted;corba;typed;cooperative;base", port=2810 }


次にIDLファイルを読み込みます。


orb:loadidlfile("CosNaming.idl")


このとき読み込むIDLファイルですが、IDL読み込みの機能が完全ではないらしく原因不明のエラーが発生することがあるので、Oilのexampleに入っているものを使用してください。



次にネームサーバーに接続します。
インターフェースの名称には注意してください。

ns = orb:newproxy("corbaloc:iiop:localhost:2809/NameService","IDL:omg.org/CosNaming/NamingContext:1.0")


最後にオブジェクトをネームサーバーにバインドします。


obj = orb:newservant(Hello, nil, "IDL:Hello:1.0")
ns:rebind({{id="testComp",kind="rtc"}},testComp)







次にRTCプロファイルのような複数のデータを含む構造体を返すオペレーションを実行した際に、どのようにその構造体を表現するかについてメモします。
これは実は簡単で、テーブルに同じ名前の変数を追加して、そのテーブルを返すだけです。

local testComp = {}

function testComp:get_component_profile()

print("get_component_profile")

return {instance_name="testComp",type_name="testComp",

 description="description",version="0", vendor="sample",

 category="test",port_profiles={},

 parent=testComp,properties={

 {name="implementation_id",value="testComp"}, {name="type_name",value="testComp"},

 {name="description",value="description"},{name="version",value="0"},

 {name="vendor",value="sample"},{name="category",value="test"},

 {name="activity_type",value="STATIC"},{name="max_instance",value="1"},

 {name="language",value="Lua"},{name="lang_type",value="SCRIPT"},

 {name="instance_name",value="testComp0"}

 }

 }

end

さっきも言ったのですが、IDLの読み込み機能が不完全らしく、特にSDOPackage.idlの読み込みには苦労しました。読み込めるように改変したものは、先ほどのソースコードと一緒に置いてあります。
何故かconst修飾子が全く使えないらしく、CosNotification.idlからconst定数は全て削除しました。それ以外にもエラーが多数発生したので大幅に変更してあります。






多分これの開発は滞る、というか先が長すぎてあまりやる気がでないので、しばらく放置します。








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

一応解説

メーリングリストで問題になっている「ポートプロファイルから出力データを取得する機能」ですが、あそこで機能の内容を説明するのは適当ではないので一応解説します。

この機能があるのはC++版のみで、PythonとJavaには最新のソースコードにも実装はありません。※Javaには実装がありました。間違えてごめんなさい。


まず、この機能を知っていた人はほとんどいないと思います。
僕もこの機能についてはソースコードを読んだ以上の知識はないので、分からないことがあったら自分で調べてください。


機能の説明の前に、RTシステムエディタで何故RTCの情報、保持しているポート等が確認できるかというと、RTCを起動しているプロセスとCORBA通信をすることでコンポーネントプロファイル(ComponentProfile)を取得しているからです。

このコンポーネントプロファイルは保持しているデータポート、サービスポートのプロファイル(PortProfile)を持っているので、RTシステムエディタではここからポートの情報を取得してシステムダイアグラム上にRTCを表示できているということです。



さて「ポートプロファイルから出力データを取得する機能」ですが、これはアウトポートから出力したデータをポートプロファイルから取得できる機能です。
取得できるデータはアウトポートからデータを出力すると上書きされるので、直前に出力したデータしか取得できません。

あの問題ですが、RTシステムエディタでプロファイル取得中に、同時に出力データのポートプロファイルへの格納を行った場合にアクセス違反で落ちます。
これは画像データなど大容量のデータを通信すると問題が起きやすいというだけで、小さいデータを通信するRTCでも運が悪ければ発生します。






ちなみにですが、omniORBのデフォルトの設定では2MBがデータサイズの上限なので、640×480の画像データを送信するアウトポートが3つ以上あると、RTシステムエディタではコンポーネントプロファイルが取得できなくなるのでRTCの表示がバグります。
ただでさえRTシステムエディタとRTCの通信量が増えるので、動きが悪くなるかもしれません。





この機能の内容、利点・欠点はこんな感じです。











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

Japan Robot Week 2016 RTミドルウエア講習会感想

Japan Robot Week 2016のRTM講習会に教える側で参加してきました。

10人受講者がいたはずなのですが、何故か5人に減っていました。
ロボットは人数分用意して準備しているので、サインアップをキャンセルするなり連絡するなりしてほしいです。

人数は少なかったのですが、かなり難しい環境の人が多かったように思います。
正直、Visual C++のインストールができていないのは厳しいです。

ただ僕個人の考えとしては自分でRTCを作成するのは間違いだと思っているので、プログラミングの経験がない人がRTMに興味を持ってくれるのは良い事だと思います。

そういう人でも適当にRTCを並べるだけでロボットを制御できるようになるのが本来の姿だとは思うので、RTCやツールが充実するように皆さん頑張ってください。








そういえばコンテストのプロジェクトページ作成の締め切りが10月31日までです。
もうあまり時間はないのですが、プロジェクトページ作成後ソースコードとマニュアルをアップロードしてください。

作品一覧を見たのですが、もう教育用や入門用は飽きているごろではないでしょうかね？
僕は飽きたので何か別の着眼点が欲しいです。
それがあるのかどうかはまだ見ていないので分かりませんが、楽しみにしています、











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

色々と勘違いしていた

僕はOpenRTM-aist-0.4.2から使っているのですが、当時はRT System EditorではなくRtcLinkというツールを使っていました。

「RtcLinkは軽くてよかったのにeclipseのプラグイン化されてから重くなった」と記憶していたのですが、0.4.0の時点でeclipseに統合されているので僕はPythonで実装していたRtcLinkを使った事はないはずです。

何と勘違いしていたのかと調べてみたところ、OpenRTM.NET-0.4.0にRtcStudioというツールが付属していて、これと勘違いしていたようです。
当時の僕のノートPCではeclipseをVisual Studio等と同時に動かすと重くて非常に不快だったので、RtcStudioをよく使っていたのだとは思います。


OpenRTM.NET-1.3にはRtcStudioは付いていないようなのですが、「はじめてのコンポーネント指向ロボットアプリケーション開発」のサポートページからOpenRTM.NET-0.4.0をダウンロードできるので入手は可能です。

ちなみにインターフェースが変わったせいか、RTCの操作は一切できないので意味はないです。



まあでも、まだ0.4.2を使っている人もいるかもしれないし・・・いや、いないか。







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