個人的な雑記やら感想やらなんやかんや

ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。

[1] [2] [3] [4] [5] [6] [7] [8] [9]

ロボット用ミドルウェア比較

以下は個人の感想であって、間違いや偏見に満ち溢れています。真に受けないでください。

OROCOS

一言コメント：ROSより流行っていてもおかしくないぐらい洗練はされている

OROCOSはRTT(リアルタイムツールキット)、KDL(キネマティクス・ダイナミクスライブラリ)、BFL(ベイジアンフィルタライブラリ)の3つの要素から構成されています。このうちミドルウェアに相当するのはRTT。

やたらとリアルタイム性を主張していますが、このリアルタイムが何を指しているのかがよく分からない。

2002年の時点でリリースされており歴史はかなり古い。

状態遷移マシン、1つのスレッドで複数のコンポーネントを実行するなどの機能があり洗練されている。

RTMに一部準拠という記述を他のサイトで見たのですけど、そうなのかどうか分かりません。

OS：Windows、Linux

言語：C++

CCA

一言コメント：今更感漂う

2011年ぐらいに初回リリースがあったみたいだけど、なんだかものすごく今更感が漂っています。

そのころになったらROSやOpenRTM-aistだってあったわけだし、どうして独自に作ろうと思ったのか。なんだか状態遷移がRTMとよく似ています。

実行コンテキストのような仕組みがあるあたり、ROS1より洗練されていると言えなくもないですが、車輪の再発名を無くそうというのがロボット用ミドルウェア利用の目的にあるはずなのに、ミドルウェアの再発名をしていたら本末転倒です。せめて他のミドルウェアと互換のものを作っていたらなあ。別にRTM準拠でも良かっただろうに。

OS：Linux

言語：C++

Orca

一言コメント：全体的にRTMっぽい

コンポーネントベースを開発コンセプトにしているあたり、RTMに近いのだろうとは思う。

通信にIceを利用した点もなんか似ている。

やたらと対応するOSが多いのも似ている。

標準規格を持っていないOpenRTM-aistなので、流行る理由も特になかったような気がする。

OS：Linux、QNX、Windows、Mac

言語：C++、Java、Python、PHP

Microsoft Robotics Developer Studio

一言コメント：ツールは非常に充実

VPL等のツールは非常に充実しているが、他のロボット用ミドルウェア上に作ればよかったのではないかという感じがします。ROSが普及したあたり、Windowsでの動作は必須ではなかったのも問題かもしれません。

まあでも、2006年ごろはまだこれといったミドルウェアが無かったかもしれません。当時のことは知りませんけど。

既に開発終了しているみたいです。

OS：Windows

言語：.NET、VPL(ビジュアルプログラミング言語)

RSNP

一言コメント：インターネットで接続するロボット用、そもそもロボットである必要はあるのか？

インターネットでサービスロボットを接続することを目的にしており、他とは毛色が違う。

サーバーとクライアント間の通信ライブラリを提供している。

最近の動向はよく分からない。WebSocketには対応したのだろうか？

ライブラリの入手のハードルは高い。一見さんが取っ付きやすいように、お試し用のRSNPサーバーをいくつか運用しないと普及はしない。というか、動かしてみようのページにあるRSiロボットマップにアクセスできないのだけど、やる気はあるのだろうか？

OS：Windows、Linux、Android

言語：Java

ORiN

一言コメント：産業機器用ミドルウェア、競合相手は別にいる

FA機器をターゲットにしているため、他のミドルウェアとは少し違う。

最初から研究や教育ではなく実用化を目的としており、ROSとは違う独自の立ち位置を築いている。逆に言えばFL-net等の別の競合相手がいる状態なので、今後生き残れるかはよく分かりません。

2001年にバージョン1.0が制定されており、歴史はかなり古い。

基本的には産業用ロボットとアプリケーションを連携させるミドルウェアであり、他のミドルウェアよりもモジュールの抽象度が高い部分を扱うのだとは思います。

ORiN2 SDKを購入する必要があるわけですが、逆に言えば金で解決できるのはいい点かもしれません。

OS：Windows、Linux

言語：C++、.NET※、Java※、VBScript※

※アプリケーション部のみ

RTミドルウェア

一言コメント：他の活用分野を見つける方が・・・

規格としては一番洗練されている。

ただコンポーネントベースの開発を念頭に置いたツールがロボット屋さんには取っ付きづらく、足を引っ張る結果になっている感は否めない。肝心のツールもなんだか中途半端で使いづらい部分がある。

大学の研究者や学生は全部main文に処理を記述してただ実験中だけ動くものを作れればいいと思っている連中なので、RTCを状態遷移などは煩わしいだけです。

例えば、サービスポートは非アクティブ状態の時に呼び出しができないようになっているわけですが、これはただ使いたいだけの人には理解不能です。大学の研究者と企業のシステムエンジニアとの考え方の乖離が大きすぎる。

前から言っているが、ロボット以外の活用分野を見出す方が現実的だと思う。

RTMには一応、RTMSafetyという有料で購入できるミドルウェア実装があるので、金で解決することもできます。
標準規格を持っているのはかなり優位になる点になる可能性はあります。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、ORiNは金でサポートを受けられる製品もありますが、それだけの見返りがあるかは不明。RTMSafetyは使ったことないです。
CCAがなぜ今更独自のミドルウェアを作ったのか意味不明と言ったが、ROSも出てきたときには既にRTMやOROCOSがあったので意図が不明ではある。
Microsoft Robotics Developer Studioはいろいろと惜しい
RSNPは存在感が(僕の中で)年々薄れている。

(追記)
ここで取り上げなかったロボット用ミドルウェアについては次の記事で取り上げます。

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

2018/05/16 (Wed) RTミドルウェア Comment(0)

ファイアウォールを切りたくない場合にデータポートの通信を行う

なんだか最近、いろんなサイト上にペーパークラフトの兜を作ってサッカー日本代表を応援しようとか言う広告が出てくるのですが、流行らないものを無理やり流行らせようとしているごり押し感しかしないため非常に不快です。

それはさておき、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型通信を駆使することで通信できます。理論上はですが。

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

2018/05/07 (Mon) RTミドルウェア Comment(0)

こっそり差し替え

昨日、OiLのマーシャリング、アンマーシャリングの話をしましたが、あの問題は解決しました。

やはりアラインメントの問題だったのですが、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をリリースするのは面倒なので、こっそりファイルだけ差し替えます。どうせ誰もダウンロードしていないだろうと思います。というかいたら気持ち悪い

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

2018/04/27 (Fri) RTミドルウェア Comment(0)

OiLのマーシャリング、アンマーシャリング

以前の記事でUSBラズパイとかいう製品の存在価値が分からないと言いましたが、案の定叩かれているようです。そりゃそうだよなあ。買うことを検討している人は考え直したほうがいいと思う。

それはさておき。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が挿入されています。

位置値

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

5 0

6 0

7 0

8 0
------------------------
Time(nsec)：unsigned long

9 0

10 0

11 0

12 0
------------------------

13 255

14 255

15 255

16 255
------------------------
Velocity2D(vx)：double

17 0

18 0

19 0

20 0

21 0

22 0

23 0

24 0
------------------------
Velocity2D(vy)：double

25 0

26 0

27 0

28 0

29 0

30 0

31 0

32 0
------------------------
Velocity2D(va)：double

33 0

34 0

35 0

36 0

37 0

38 0

39 0

40 0
------------------------

CameraImage型は以下のようになります。

位置値
------------------------

1 1

2 255

3 255

4 255
------------------------
Time(sec)：unsigned long

5 0

6 0

7 0

8 0
------------------------
Time(nsec)：unsigned long

9 0

10 0

11 0

12 0
------------------------
width：unsigned short

13 0

14 0
------------------------
height：unsigned short

15 0

16 0
------------------------
bpp：unsigned short

17 0

18 0
------------------------

19 255

20 255
------------------------
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

33 0

34 0

35 0

36 0

37 0

38 0

39 0

40 0
------------------------
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をリリースしました。

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

2018/04/26 (Thu) RTミドルウェア Comment(0)

Dynamixelモーター＋OpenCM9.04-Cの動作確認手順

USBラズパイなるものが発売されるらしいけど、一体ラズパイエミュレータと比べて何の利点があるのだろう・・・
一本9800円も払うんだったら普通にラズパイ買うだろうし、謎です。この製品を貶したいのではなく、ただ純粋に疑問です。

それはさておき、Dynamixel XM430-W350-RをOpenCM9.04-C+OpenCM 485拡張ボードに接続して動作確認しようとしたのですが、かなり詰まる部分があったのでメモしておきます。

まず、OpenCM9.04を使うにあたりOpenCM IDEを使って動作確認しようとしたのですが、これが何故か上手くいきませんでした。サンプルコードのDXL_BUS_SERIAL1を拡張ボード用にDXL_BUS_SERIAL3に変更してもピクリとも動きません。ボーレートを変更しても関係ないようです。Dynamixel 2.0のプロトコルに対応していないのか、XMシリーズが駄目なのかは謎です。

一旦RoboPlusでOpenCM9.04のファームウェアを修復後、RoboPlus 2.0 Managerで確認してみました。

まず、Dynamixel XM430-W350-R、OpenCM9.04-C、OpenCM 485拡張ボードを以下のように接続します。USBケーブルはPCと接続してください。

拡張ボードの電源は以下のスイッチでオンオフができます。
オンにするとXM430-W350-RのLEDが一回点滅します。
点滅しなかった場合はバッテリーが壊れている可能性があります。ちなみに画像に映っているバッテリーですが、一度も使っていないのに既に壊れています。

R+ Manager 2.0を起動後、アップデートするかどうか聞かれた場合はアップデートしてください。

アップデート後は、R+ Manager 2.0起動後に以下の画面が表示されます。

ProductからDYNAMIXEL Xを選んで○を押してください。

次に以下の画面でUpdate & Testを選んでください。

Nextを選んでいくとポート番号の選択画面に移行するため、適切なポートを選択してください。
OpenCM9.04-Cを直接接続した場合はROBOTIS Virtual COM Portと表示されるのでわかるとは思いますが、USBダウンローダーLN-101で接続するとUSB Serial Port(1.0)としか表示されないので分かり辛いかもしれません。

その後Nextを押していくとOpenCM9.04-Cと接続します。
本来であればXM-430-W350も表示されるはずですが、設定を変更しないと表示されません。

Control Tableで、Dynamixel ChannelをEXP Board(XH/XM)に変更してください。

それからBand Rate (Bus)を57600bpsに変更してください。

この後に、一旦Update & Testを×ボタンで終了後、OpenCM9.04-Cをリセット、OpenCM 485拡張ボードの電源を落として再起動、再度Update & TestによりOpenCM9.04-Cと接続すると、Device一覧にXM430-W350が表示されます。

表示されない場合はOpenCM9.04-cのリセットボタンを押して再起動、拡張ボードの電源を入れ直すなどで接続できるかもしれません。

Control Table画面でXM430-W350-Rの状態を確認できます。
Torque EnableをONにした後、Goal Positionの値を操作することでモーターが動作します。

独自のプログラムでXM430-W350-Rを操作する場合は、Dynamixel Protocol 2 Libraryというライブラリがあるようなのでこれを使います。Dynamixel SDKというライブラリもあるようなのですが、XMシリーズが動くかどうかは不明です。libdynamixelは大丈夫みたいです。と言うかなんでこんなに乱立しているんだ。

とりあえず、CMake設定ファイルを以下のように作成します。ファイル名は適当に変更してください。


cmake_minimum_required(VERSION 2.8)


set(DX2LIB_ROOT ${DX2LIB_ROOT} CACHE PATH "set DX2LIB_ROOT ")

if(NOT DX2LIB_ROOT)
	message(FATAL_ERROR "Please set DX2LIB_ROOT.")
endif()





project (DXLTest)

include_directories(${DX2LIB_ROOT})
link_directories(${DX2LIB_ROOT})

add_executable(DXLTest DXLTest.cpp)
target_link_libraries(DXLTest dx2lib_x32.lib)cmake_minimum_required(VERSION 2.8)


set(DX2LIB_ROOT ${DX2LIB_ROOT} CACHE PATH "set DX2LIB_ROOT ")

if(NOT DX2LIB_ROOT)
	message(FATAL_ERROR "Please set DX2LIB_ROOT.")
endif()





project (DXLTest)

include_directories(${DX2LIB_ROOT})
link_directories(${DX2LIB_ROOT})

add_executable(DXLTest DXLTest.cpp)
target_link_libraries(DXLTest dx2lib_x32.lib)

DXLTest.cppには、とりあえずライブラリを展開したフォルダのSampleCode\VC\smpl1(template).cの中身をコピーします。

ただ何故かエラーが出るので、DXDEVICEIDをTDeviceIDに変更します。


DXDEVICEID  dev;
⇒
TDeviceID  dev;

後は適当にモーターを操作するコードを追加します。


		TErrorCode err;

		//トルクをオンにする
		DX2_WriteByteData(dev, 1, 64, 1, &err);
		Sleep(1000);
		//90度の位置に回転
		DX2_WriteLongData(dev, 1, 116, 3072, &err);
		Sleep(1000);
		//-90度の位置に回転
		DX2_WriteLongData(dev, 1, 116, 1024, &err);
		Sleep(1000);
		//トルクをオフにする
		DX2_WriteByteData(dev, 1, 64, 0, &err);

詳細については仕様を見ながら試すしかなさそうです。
そう考えるとlibdynamixel使った方が良かったかもしれません。
libdynamixelだと以下のようになります。


	DynamixelV2 m("\\\\.\\COM3", 1000000));
	m.TorqueEnable(1);
	Sleep(1000);
	m.MovePosition(1, 1024);
	Sleep(1000);
	m.MovePosition(1, 3072);
	Sleep(1000);
	m.TorqueDisable(1);