ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
前回の記事で取り上げなかったロボット用ミドルウェアについて取り上げます。
何度も言いますが、以下は間違い、偏見、悪意に満ち溢れているため、真に受けないでください。
一言コメント：もう疲れた
ロボットナビゲーションキットという位置づけなので、少し毛色が違うかもしれない。
2000年ぐらいから動いているので歴史は長いが、2008年を最後に更新がないので終わってからの歴史も長い。
OS：Linux
言語：C
結論を言ってしまうと、好きなものを使えばいいじゃない、としか言えません。
物好きな人はCCAとかMIRAとかMOOSとか使えばいいと思います。どうせROSだって10年後には「え？ROSなんてまだ使ってるのwww」みたいな扱いになってるだろうし、標準規格とか細かいことは考えずに好きなものを使えばいいと思いますよ。
ここで取り上げたロボット用ミドルウェアの性能比較をだれかやってください。
(追記)
そういえばRobolinkとかいうのもあったね。よく知らないけど。
OrcaとORCAは別物なんだっけ？なんだか被る名前付けたのがOrca最大のミスだったような気がする。
RockはOROCOSベースで作っているものだから、別に取り上げなくていいか。
OpenRDKは・・・・まあいいか。面倒くさい。
ERSP11とか言うのもあるらしい。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
何度も言いますが、以下は間違い、偏見、悪意に満ち溢れているため、真に受けないでください。
一言コメント：特徴は何？
日本でもそこそこ知名度があるが、ユーザーは見たことないです。
通信ライブラリの提供になるわけですが、いまだにYARPの特徴は理解できてません。
たくさんの通信プロトコルが扱えるのが特徴なのか。
OS：Linux、Mac
言語：C++
一言コメント：他の分野では使われているのだろうか・・・
先に言っておきますが、LCMは通信部分を提供するライブラリであって、ロボット用ミドルウェアではありません。
通信部分だけの提供なので、確かにシンプルではあるけど、それならロボット屋さんはROS使うよね・・・
LCMを使ってRTMを実装することもできるだろうけど、需要は特になさそうです
LCMを使ってRTMを実装することもできるだろうけど、需要は特になさそうです
OS：Linux、Mac、Windows、Solaris、FreeBSD
言語：C、C++、.NET、Java、Lua、Python、MATLAB
一言コメント：StageやGazebo目的で使う(僕は)
正直、今の状況は分かりません。
ただ10年ぐらい前でも、日本で使っている人が少数ですがいました。
どっちかと言えば、PlayerよりもStageやGazeboを目的で使います、いや、別にそれはROSだってそうか。
OS：Linux、Solaris、FreeBSD
言語：C++、Tcl、Java、Python
OS：Linux、Solaris、FreeBSD
言語：C++、Tcl、Java、Python
一言コメント：これも今更感が
今も頻繁に更新されている。
比較対象にRTMが無い当たり、欧米でのRTMの知名度もよく分かります。
データを格納するキューに工夫があるらしいが、別にそれだったら既存のものに機能を追加するか互換のものを作れたんじゃないかなあ？
それ以外に特徴は、これと言ってないです。
OS：Linux、Windows
言語：C++
一言コメント：もうROSでいいよ
もうここまでくると日本での知名度は0だよ・・・・
コールバック関数を定義する当たり、コーディングがRTMっぽい。
というか全然他と差別化できていない。
OS：Linux、Mac、Windows
言語：C++
一言コメント：ごめんなさい。わかりません。
一言コメント：ロストテクノロジー
マニュアルもソースコードもダウンロードできないため、詳細がよく分かりません。
TAOの上に作ったあたりはOpenRTM-aistと近いと思う。
OS：Linux
言語：C++
一言コメント：世界最古のロボット用ミドルウェアかもしれない
1998年時点でロボット用ミドルウェアの標準インターフェースを考えていたことが地味に凄い。
データポートのみではなく、コンフィギュレーションパラメータのような仕組みもある。
どうして流行らなかったのか。そもそも知名度が低いのか。
OS：Linux、Windows、Mac
言語：C++
OPEN-R
一言コメント：もうこれはいいだろ・・・
ソニーのAIBO用のソフトウェア開発キットです。それ以上でも以下でもありません。
OS：Windows、Linux、FreeBSD、Solaris、Mac
言語：C++
OPEN-R
一言コメント：もうこれはいいだろ・・・
ソニーのAIBO用のソフトウェア開発キットです。それ以上でも以下でもありません。
OS：Windows、Linux、FreeBSD、Solaris、Mac
言語：C++
一言コメント：もう疲れた
ロボットナビゲーションキットという位置づけなので、少し毛色が違うかもしれない。
2000年ぐらいから動いているので歴史は長いが、2008年を最後に更新がないので終わってからの歴史も長い。
OS：Linux
言語：C
結論を言ってしまうと、好きなものを使えばいいじゃない、としか言えません。
物好きな人はCCAとかMIRAとかMOOSとか使えばいいと思います。どうせROSだって10年後には「え？ROSなんてまだ使ってるのwww」みたいな扱いになってるだろうし、標準規格とか細かいことは考えずに好きなものを使えばいいと思いますよ。
ここで取り上げたロボット用ミドルウェアの性能比較をだれかやってください。
(追記)
そういえばRobolinkとかいうのもあったね。よく知らないけど。
OrcaとORCAは別物なんだっけ？なんだか被る名前付けたのがOrca最大のミスだったような気がする。
RockはOROCOSベースで作っているものだから、別に取り上げなくていいか。
OpenRDKは・・・・まあいいか。面倒くさい。
ERSP11とか言うのもあるらしい。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
以下は個人の感想であって、間違いや偏見に満ち溢れています。真に受けないでください。
OROCOS
一言コメント：ROSより流行っていてもおかしくないぐらい洗練はされている
OROCOSはRTT(リアルタイムツールキット)、KDL(キネマティクス・ダイナミクスライブラリ)、BFL(ベイジアンフィルタライブラリ)の3つの要素から構成されています。このうちミドルウェアに相当するのはRTT。
OS：Windows、Linux
OS：Linux、QNX、Windows、Mac
他のミドルウェアと比較すると圧倒的なシェアを誇るが、研究用途から脱するのは相当先の話だと思う。
OS：Linux、(Mac、Android、Windows？)(追記)
ここで取り上げなかったロボット用ミドルウェアについては次の記事で取り上げます。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
OROCOS
一言コメント：ROSより流行っていてもおかしくないぐらい洗練はされている
OROCOSはRTT(リアルタイムツールキット)、KDL(キネマティクス・ダイナミクスライブラリ)、BFL(ベイジアンフィルタライブラリ)の3つの要素から構成されています。このうちミドルウェアに相当するのはRTT。
やたらとリアルタイム性を主張していますが、このリアルタイムが何を指しているのかがよく分からない。
2002年の時点でリリースされており歴史はかなり古い。
状態遷移マシン、1つのスレッドで複数のコンポーネントを実行するなどの機能があり洗練されている。
RTMに一部準拠という記述を他のサイトで見たのですけど、そうなのかどうか分かりません。
OS：Windows、Linux
言語：C++
CCA
一言コメント：今更感漂う
2011年ぐらいに初回リリースがあったみたいだけど、なんだかものすごく今更感が漂っています。
一言コメント：全体的にRTMっぽい
コンポーネントベースを開発コンセプトにしているあたり、RTMに近いのだろうとは思う。
CCA
一言コメント：今更感漂う
2011年ぐらいに初回リリースがあったみたいだけど、なんだかものすごく今更感が漂っています。
そのころになったらROSやOpenRTM-aistだってあったわけだし、どうして独自に作ろうと思ったのか。なんだか状態遷移がRTMとよく似ています。
実行コンテキストのような仕組みがあるあたり、ROS1より洗練されていると言えなくもないですが、車輪の再発名を無くそうというのがロボット用ミドルウェア利用の目的にあるはずなのに、ミドルウェアの再発名をしていたら本末転倒です。せめて他のミドルウェアと互換のものを作っていたらなあ。別にRTM準拠でも良かっただろうに。
OS：Linux
OrcaOS：Linux
言語：C++
一言コメント：全体的にRTMっぽい
コンポーネントベースを開発コンセプトにしているあたり、RTMに近いのだろうとは思う。
通信にIceを利用した点もなんか似ている。
やたらと対応するOSが多いのも似ている。
標準規格を持っていないOpenRTM-aistなので、流行る理由も特になかったような気がする。
OS：Linux、QNX、Windows、Mac
言語：C++、Java、Python、PHP
Microsoft Robotics Developer Studio
一言コメント：ツールは非常に充実
VPL等のツールは非常に充実しているが、他のロボット用ミドルウェア上に作ればよかったのではないかという感じがします。ROSが普及したあたり、Windowsでの動作は必須ではなかったのも問題かもしれません。
一言コメント：産業機器用ミドルウェア、競合相手は別にいる
FA機器をターゲットにしているため、他のミドルウェアとは少し違う。
一言コメント：他の活用分野を見つける方が・・・
規格としては一番洗練されている。
OS：Windows、Linux、VxWorks、QNX、(FreeBSD、Mac、Android、Toppers、RTA-OSEK、OSなし)
ROS
一言コメント：実用化への道は果てしなく遠いが、そんな事考える必要はない？Microsoft Robotics Developer Studio
一言コメント：ツールは非常に充実
VPL等のツールは非常に充実しているが、他のロボット用ミドルウェア上に作ればよかったのではないかという感じがします。ROSが普及したあたり、Windowsでの動作は必須ではなかったのも問題かもしれません。
まあでも、2006年ごろはまだこれといったミドルウェアが無かったかもしれません。当時のことは知りませんけど。
既に開発終了しているみたいです。
OS：Windows
OS：Windows
言語：.NET、VPL(ビジュアルプログラミング言語)
RSNP
一言コメント：インターネットで接続するロボット用、そもそもロボットである必要はあるのか？
インターネットでサービスロボットを接続することを目的にしており、他とは毛色が違う。
OS：Windows、Linux、Android
RSNP
一言コメント：インターネットで接続するロボット用、そもそもロボットである必要はあるのか？
インターネットでサービスロボットを接続することを目的にしており、他とは毛色が違う。
サーバーとクライアント間の通信ライブラリを提供している。
最近の動向はよく分からない。WebSocketには対応したのだろうか？
ライブラリの入手のハードルは高い。一見さんが取っ付きやすいように、お試し用のRSNPサーバーをいくつか運用しないと普及はしない。というか、動かしてみようのページにあるRSiロボットマップにアクセスできないのだけど、やる気はあるのだろうか？
OS：Windows、Linux、Android
一言コメント：産業機器用ミドルウェア、競合相手は別にいる
FA機器をターゲットにしているため、他のミドルウェアとは少し違う。
最初から研究や教育ではなく実用化を目的としており、ROSとは違う独自の立ち位置を築いている。逆に言えばFL-net等の別の競合相手がいる状態なので、今後生き残れるかはよく分かりません。
2001年にバージョン1.0が制定されており、歴史はかなり古い。
基本的には産業用ロボットとアプリケーションを連携させるミドルウェアであり、他のミドルウェアよりもモジュールの抽象度が高い部分を扱うのだとは思います。
ORiN2 SDKを購入する必要があるわけですが、逆に言えば金で解決できるのはいい点かもしれません。
OS：Windows、Linux
言語：C++、.NET※、Java※、VBScript※
一言コメント：他の活用分野を見つける方が・・・
規格としては一番洗練されている。
ただコンポーネントベースの開発を念頭に置いたツールがロボット屋さんには取っ付きづらく、足を引っ張る結果になっている感は否めない。肝心のツールもなんだか中途半端で使いづらい部分がある。
大学の研究者や学生は全部main文に処理を記述してただ実験中だけ動くものを作れればいいと思っている連中なので、RTCを状態遷移などは煩わしいだけです。
例えば、サービスポートは非アクティブ状態の時に呼び出しができないようになっているわけですが、これはただ使いたいだけの人には理解不能です。大学の研究者と企業のシステムエンジニアとの考え方の乖離が大きすぎる。
前から言っているが、ロボット以外の活用分野を見出す方が現実的だと思う。
RTMには一応、RTMSafetyという有料で購入できるミドルウェア実装があるので、金で解決することもできます。
標準規格を持っているのはかなり優位になる点になる可能性はあります。ROSはただのソフトウェアなわけだから10年後に消えていてもおかしくありませんが、RTMは標準規格なので10年後に消えているということはあり得ません。まあOpenRTM-aistがROSより先に消えて規格だけ残っている可能性が高そうですが。
標準規格を持っているのはかなり優位になる点になる可能性はあります。ROSはただのソフトウェアなわけだから10年後に消えていてもおかしくありませんが、RTMは標準規格なので10年後に消えているということはあり得ません。まあOpenRTM-aistがROSより先に消えて規格だけ残っている可能性が高そうですが。
OS：Windows、Linux、VxWorks、QNX、(FreeBSD、Mac、Android、Toppers、RTA-OSEK、OSなし)
言語：C++、Python、Java、(C、.NET、Erlang、Lua)
ROS
他のミドルウェアと比較すると圧倒的なシェアを誇るが、研究用途から脱するのは相当先の話だと思う。
豊富な計算資源を前提としているため、製品に組み込んで使うのは難しい。
ROS2が普及すれば状況が良くなる可能性はありますが簡単な話ではありません。
ROSでロボットを開発していたけど、結局ほぼすべてのノードを自前で作ったなんでネガティブな話を聞くことも珍しくないし。まあROSに限った話ではないけど。
そもそもROSの場合、製品でROSを動かすことは考えずに、研究、教育目的かプロトタイピング用と割り切るのが正解です。ROS2は普及しないと思う。
OS：Linux、(Mac、Android、Windows？)
言語：C++、Python、(Java、octave、Lisp、Ruby、Lua)
現在も更新されているロボット用ミドルウェアは、ROS、RTM、OROCOS、Player/Stageぐらい？ORiNとRSNPはちょっと毛色が違うので。
まとめると以下のような感じ。
現在も更新されているロボット用ミドルウェアは、ROS、RTM、OROCOS、Player/Stageぐらい？ORiNとRSNPはちょっと毛色が違うので。
まとめると以下のような感じ。
- 企業の人は安易にROSに手は出さないほうがいい。どうせ全部作り直すことになります。
- RTM、ORiNは金でサポートを受けられる製品もありますが、それだけの見返りがあるかは不明。RTMSafetyは使ったことないです。
- CCAがなぜ今更独自のミドルウェアを作ったのか意味不明と言ったが、ROSも出てきたときには既にRTMやOROCOSがあったので意図が不明ではある。
- Microsoft Robotics Developer Studioはいろいろと惜しい
- RSNPは存在感が(僕の中で)年々薄れている。
ここで取り上げなかったロボット用ミドルウェアについては次の記事で取り上げます。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
なんだか最近、いろんなサイト上にペーパークラフトの兜を作ってサッカー日本代表を応援しようとか言う広告が出てくるのですが、流行らないものを無理やり流行らせようとしているごり押し感しかしないため非常に不快です。
それはさておき、RTM講習会等でファイアウォールを切れとか強要されますが、多分嫌な人もいるかもしれないので、ファイアウォールを切らなかった場合の動作について説明します。
まず、以下のように2台のマシンを用意してマシン1ではファイアウォールが有効、マシン2ではファイアウォールが無効の場合を考えます。
なお、RTシステムエディタがマシン2で動作している場合は、マシン2側からポート1への接続がブロックされるためコネクタの接続は不可能です。
コネクタを接続するときのシーケンス図が以下のようになっています。
RTシステムエディタからポート1のconnect関数を呼び出して、さらにポート1は内部のnotify_connect関数を呼び出します。さらにポート1からポート2のnotify_connect関数を呼び出すという流れになっています。
この場合はポート1からポート2に接続しにいっているので、問題なく接続できます。
しかし、以下のようにコネクタプロファイルに登録したポートのリストの順番が変わりポート2がポート1のnotify_connect関数を呼び出す場合は、ファイアウォールにブロックされるため接続できません。
RTシステムエディタがポート2のconnect関数を呼び出した場合も、ポート2からポート1のnotify_connect関数がリモート呼び出しできないため接続不可です。
このためファイアウォールを有効にした場合のポートの接続には注意が必要ですが、現状RTシステムエディタの機能としてどちらのポートのconnect関数を呼ぶのか、ポートの登録順をどうするかなどの設定はできないため、自分で接続するためのコードを書くしかありません。
そしてデータ転送時の動作ですが、以下のようにPush型接続で通信する場合、マシン1からマシン2に接続しにいくので、問題なく接続できます。
これがPull型接続の場合にはマシン2からマシン1に接続しにいくのでブロックされます。
マシン2でファイアウォールが有効になっている場合、Push型接続はマシン1からマシン2に接続しにいくのでブロックされます。
Pull型接続の場合はマシン2からマシン1に接続しにいくので、問題なく通信できます。
このため、以下のようにインポート、アウトポートでPush型、Pull型を使い分けることで、ファイアウォールが有効な場合でも理論上は通信ができます。
なぜ理論上はと言ったかというと、現状のOpenRTM-aistの実装の問題によりマシン2からマシン1に接続しにいく場合があるからです。
OpenRTM-aistはポートのプロファイル取得時等にポートのオブジェクトの存在確認を行い、オブジェクトが存在しない場合は切断するという処理を実行しています。
マシン2のRTCでその処理が実行された場合、オブジェクトの存在確認時にマシン1へ接続しにいってしまうためブロックされてしまいます。
ちなみにファイアウォールを有効にした場合でも何故か外部のRTCと接続できたり、ネットワークを切り替えたら通信できなくなる場合がありますが、単純にファイアウォールの設定が原因であることが多いです。このページの手順で確認すると、例えばPythonはプライベートがチェックされていて、パブリックにはチェックが無い場合があります。このためパブリックネットワークに接続した場合はファイアウォールにブロックされてしまいます。
ちなみにサービスポートを使用する場合、マシン2のRTCからマシン1のRTCのサービスは呼び出すことはできないため注意が必要になります。
マシン1、マシン2でファイアウォールが有効の場合は、通常の方法では相互通信はできません。
会津大が開発しているようなメッセージブローカをサーバーに配置する仕組みが必要になります。
ただし、この場合でもRTシステムエディタからの操作、サービスポートの利用はできないため、何かしら新しい仕組みが必要になります。
と言うか、ここまで長々と説明しておいてなんですが、ポート番号指定でRTCを起動してもらってファイアウォールの設定してもらう方が簡単です。
そうした場合に外部からRTCを操作されてしまう可能性があるわけですが、ファイアウォールで特定IPアドレス以外制限するようにして、さらにSSL暗号化を有効にしてもらうぐらいしか対策は無いです。
違う話になりますが、以下のようにマシン1とマシン2が内部ネットワークにある場合は、現状のOpenRTM-aistの仕組みでは通信できないため諦めましょう。
ポートフォワーディングを設定したらできるかもしれませんが、両方のルーターで設定する必要があるためあまり現実的ではないように思います。
どうしてもこの構成で通信したかったら、メッセージブローカを配置したサーバーを作るか、UDPホールパンチングをするデータポートでも作ってもらうしかなさそうです。あるいはVPN接続するというのはOpenRTMでは昔から行われているようですが、それも色々と面倒くさいのであまりやりたくありません。メッセージブローカのサーバーを使う場合は誰かが用意したものを使うという選択肢もありますが、VPNを使う場合は自前で色々と準備しなければならないのであまりお勧めはできません。
ちなみに、片方のマシンが外部からアクセスできる場合は、Pull型通信を駆使することで通信できます。理論上はですが。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
それはさておき、RTM講習会等でファイアウォールを切れとか強要されますが、多分嫌な人もいるかもしれないので、ファイアウォールを切らなかった場合の動作について説明します。
まず、以下のように2台のマシンを用意してマシン1ではファイアウォールが有効、マシン2ではファイアウォールが無効の場合を考えます。
なお、RTシステムエディタがマシン2で動作している場合は、マシン2側からポート1への接続がブロックされるためコネクタの接続は不可能です。
コネクタを接続するときのシーケンス図が以下のようになっています。
RTシステムエディタからポート1のconnect関数を呼び出して、さらにポート1は内部のnotify_connect関数を呼び出します。さらにポート1からポート2のnotify_connect関数を呼び出すという流れになっています。
この場合はポート1からポート2に接続しにいっているので、問題なく接続できます。
しかし、以下のようにコネクタプロファイルに登録したポートのリストの順番が変わりポート2がポート1のnotify_connect関数を呼び出す場合は、ファイアウォールにブロックされるため接続できません。
RTシステムエディタがポート2のconnect関数を呼び出した場合も、ポート2からポート1のnotify_connect関数がリモート呼び出しできないため接続不可です。
このためファイアウォールを有効にした場合のポートの接続には注意が必要ですが、現状RTシステムエディタの機能としてどちらのポートのconnect関数を呼ぶのか、ポートの登録順をどうするかなどの設定はできないため、自分で接続するためのコードを書くしかありません。
そしてデータ転送時の動作ですが、以下のようにPush型接続で通信する場合、マシン1からマシン2に接続しにいくので、問題なく接続できます。
これがPull型接続の場合にはマシン2からマシン1に接続しにいくのでブロックされます。
マシン2でファイアウォールが有効になっている場合、Push型接続はマシン1からマシン2に接続しにいくのでブロックされます。
Pull型接続の場合はマシン2からマシン1に接続しにいくので、問題なく通信できます。
このため、以下のようにインポート、アウトポートでPush型、Pull型を使い分けることで、ファイアウォールが有効な場合でも理論上は通信ができます。
なぜ理論上はと言ったかというと、現状のOpenRTM-aistの実装の問題によりマシン2からマシン1に接続しにいく場合があるからです。
OpenRTM-aistはポートのプロファイル取得時等にポートのオブジェクトの存在確認を行い、オブジェクトが存在しない場合は切断するという処理を実行しています。
マシン2のRTCでその処理が実行された場合、オブジェクトの存在確認時にマシン1へ接続しにいってしまうためブロックされてしまいます。
ちなみにファイアウォールを有効にした場合でも何故か外部のRTCと接続できたり、ネットワークを切り替えたら通信できなくなる場合がありますが、単純にファイアウォールの設定が原因であることが多いです。このページの手順で確認すると、例えばPythonはプライベートがチェックされていて、パブリックにはチェックが無い場合があります。このためパブリックネットワークに接続した場合はファイアウォールにブロックされてしまいます。
ちなみにサービスポートを使用する場合、マシン2のRTCからマシン1のRTCのサービスは呼び出すことはできないため注意が必要になります。
マシン1、マシン2でファイアウォールが有効の場合は、通常の方法では相互通信はできません。
会津大が開発しているようなメッセージブローカをサーバーに配置する仕組みが必要になります。
ただし、この場合でもRTシステムエディタからの操作、サービスポートの利用はできないため、何かしら新しい仕組みが必要になります。
と言うか、ここまで長々と説明しておいてなんですが、ポート番号指定でRTCを起動してもらってファイアウォールの設定してもらう方が簡単です。
そうした場合に外部からRTCを操作されてしまう可能性があるわけですが、ファイアウォールで特定IPアドレス以外制限するようにして、さらにSSL暗号化を有効にしてもらうぐらいしか対策は無いです。
違う話になりますが、以下のようにマシン1とマシン2が内部ネットワークにある場合は、現状のOpenRTM-aistの仕組みでは通信できないため諦めましょう。
ポートフォワーディングを設定したらできるかもしれませんが、両方のルーターで設定する必要があるためあまり現実的ではないように思います。
どうしてもこの構成で通信したかったら、メッセージブローカを配置したサーバーを作るか、UDPホールパンチングをするデータポートでも作ってもらうしかなさそうです。あるいはVPN接続するというのはOpenRTMでは昔から行われているようですが、それも色々と面倒くさいのであまりやりたくありません。メッセージブローカのサーバーを使う場合は誰かが用意したものを使うという選択肢もありますが、VPNを使う場合は自前で色々と準備しなければならないのであまりお勧めはできません。
ちなみに、片方のマシンが外部からアクセスできる場合は、Pull型通信を駆使することで通信できます。理論上はですが。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
昨日、OiLのマーシャリング、アンマーシャリングの話をしましたが、あの問題は解決しました。
やはりアラインメントの問題だったのですが、OiLの以下の部分の-1を-2に変更したら解決しました。そりゃ1つ位置がずれていたら、アラインメントのために移動するポインタの位置が変わってしまうので上手くいくはずがありません。
ただOiLのソースコードのこの部分を変更すると他にも影響が出る可能性があるため、OpenRTM内でalign関数を差し替えています。
理屈ではポインタの初期位置を一つ前にするだけで良さそうなのですが、何故かアンマーシャリングが上手くいきません。
これでCameraImage型の通信もできるようになったので、以下のようにOpenResty上で起動したRTCが画像データを受け取ってWEBブラウザで表示することもできます。
昨日ver.0.2.1をリリースしたのですが、舌の根も乾かないうちに0.2.2をリリースするのは面倒なので、こっそりファイルだけ差し替えます。どうせ誰もダウンロードしていないだろうと思います。というかいたら気持ち悪い
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
やはりアラインメントの問題だったのですが、OiLの以下の部分の-1を-2に変更したら解決しました。そりゃ1つ位置がずれていたら、アラインメントのために移動するポインタの位置が変わってしまうので上手くいくはずがありません。
local function alignment(self, size)
local extra = (self.cursor-1)%size
if extra > 0 then return size-extra end
return 0
end
ただOiLのソースコードのこの部分を変更すると他にも影響が出る可能性があるため、OpenRTM内でalign関数を差し替えています。
理屈ではポインタの初期位置を一つ前にするだけで良さそうなのですが、何故かアンマーシャリングが上手くいきません。
これでCameraImage型の通信もできるようになったので、以下のようにOpenResty上で起動したRTCが画像データを受け取ってWEBブラウザで表示することもできます。
昨日ver.0.2.1をリリースしたのですが、舌の根も乾かないうちに0.2.2をリリースするのは面倒なので、こっそりファイルだけ差し替えます。どうせ誰もダウンロードしていないだろうと思います。というかいたら気持ち悪い
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
以前の記事でUSBラズパイとかいう製品の存在価値が分からないと言いましたが、案の定叩かれているようです。そりゃそうだよなあ。買うことを検討している人は考え直したほうがいいと思う。
それはさておき。OiLのマーシャリング、アンマーシャリングの動作がどうにも不可解なので調べてみます。
CDRの先頭に1,255,255,255という謎の値がくっついているのは以前言った通りなのですが、TimedVelocity2D型、CameraImage型等で調べたところ、他の部分にも謎の値が挿入されてしまいます。
まずTimedVelocity2D型をマーシャリングすると以下のようになります。
格納されている値は全て0に設定してあるため、全て0になるはずですが、13～16にかけて255という値が挿入されています。
位置 値
1 1
TimedVelocity2D型について推測すると、structの変数の前に255が挿入されると推測されます。
位置 値
------------------------
CameraImage型は以下のようになります。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
それはさておき。OiLのマーシャリング、アンマーシャリングの動作がどうにも不可解なので調べてみます。
CDRの先頭に1,255,255,255という謎の値がくっついているのは以前言った通りなのですが、TimedVelocity2D型、CameraImage型等で調べたところ、他の部分にも謎の値が挿入されてしまいます。
まずTimedVelocity2D型をマーシャリングすると以下のようになります。
格納されている値は全て0に設定してあるため、全て0になるはずですが、13～16にかけて255という値が挿入されています。
位置 値
1 1
2 255
3 255
4 255
5 0
6 0
7 0
8 0
9 0
10 0
11 0
12 0
13 255
14 255
15 255
16 255
17 0
18 0
19 0
20 0
21 0
22 0
23 0
24 0
25 0
26 0
27 0
28 0
29 0
30 0
31 0
32 0
33 0
34 0
35 0
36 0
37 0
38 0
39 0
40 0
CameraImage型は以下のようになります。
これも全て0になるはずですが、255が挿入されています。
位置 値
CameraImage型は以下のようになります。
これも全て0になるはずですが、255が挿入されています。
位置 値
1 1
2 255
3 255
4 255
5 0
6 0
7 0
8 0
9 0
10 0
11 0
12 0
13 0
14 0
15 0
16 0
17 0
18 0
19 255
20 255
21 1
22 0
23 0
24 0
25 0
26 255
27 255
28 255
29 255
30 255
31 255
32 255
33 0
34 0
35 0
36 0
37 0
38 0
39 0
40 0
41 0
42 0
43 0
44 0
TimedVelocity2D型について推測すると、structの変数の前に255が挿入されると推測されます。
位置 値
------------------------
1 1
2 255
3 255
4 255
------------------------
Time(sec)：unsigned long
------------------------
Time(sec)：unsigned long
5 0
6 0
7 0
8 0
------------------------
Time(nsec)：unsigned long
------------------------
Time(nsec)：unsigned long
9 0
10 0
11 0
12 0
------------------------
------------------------
13 255
14 255
15 255
16 255
------------------------
Velocity2D(vx)：double
------------------------
Velocity2D(vx)：double
17 0
18 0
19 0
20 0
21 0
22 0
23 0
24 0
------------------------
Velocity2D(vy)：double
------------------------
Velocity2D(vy)：double
25 0
26 0
27 0
28 0
29 0
30 0
31 0
32 0
------------------------
Velocity2D(va)：double
------------------------
Velocity2D(va)：double
33 0
34 0
35 0
36 0
37 0
38 0
39 0
40 0
------------------------
------------------------
CameraImage型は以下のようになります。
位置 値
------------------------
なるほど。全く分かりません。アラインメントの問題なのでしょうか？
というわけで、OiLのalign関数をただ0を返す関数に置き換えました。
これで上記の255が消えて全て上手くいく・・・と思ったのですが、CameraImage型はomniORB等でマーシャリングするとアラインメントのためかbppとformatの間に0が2個入るため上手くいきません。この問題を解決するのは容易ではありません。
まあでも、これでとりあえずほとんどのデータ型で通信できるようになったはずなので、修正版0.2.1をリリースしました。
------------------------
1 1
2 255
3 255
4 255
------------------------
Time(sec)：unsigned long
------------------------
Time(sec)：unsigned long
5 0
6 0
7 0
8 0
------------------------
Time(nsec)：unsigned long
------------------------
Time(nsec)：unsigned long
9 0
10 0
11 0
12 0
------------------------
width：unsigned short
------------------------
width：unsigned short
13 0
14 0
------------------------
height：unsigned short
------------------------
height：unsigned short
15 0
16 0
------------------------
bpp：unsigned short
------------------------
bpp：unsigned short
17 0
18 0
------------------------
------------------------
19 255
20 255
------------------------
format：string
------------------------
format：string
21 1
22 0
23 0
24 0
25 0
------------------------
------------------------
26 255
27 255
28 255
29 255
30 255
31 255
32 255
------------------------
fDiv:：double
------------------------
fDiv:：double
33 0
34 0
35 0
36 0
37 0
38 0
39 0
40 0
------------------------
pixels：sequence<octet>
------------------------
pixels：sequence<octet>
41 0
42 0
43 0
44 0
なるほど。全く分かりません。アラインメントの問題なのでしょうか？
というわけで、OiLのalign関数をただ0を返す関数に置き換えました。
encoder.align = function(...)return 0 end
これで上記の255が消えて全て上手くいく・・・と思ったのですが、CameraImage型はomniORB等でマーシャリングするとアラインメントのためかbppとformatの間に0が2個入るため上手くいきません。この問題を解決するのは容易ではありません。
まあでも、これでとりあえずほとんどのデータ型で通信できるようになったはずなので、修正版0.2.1をリリースしました。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
