コボッタ制御の基本概要

少し話がいい加減で正確性に欠くと思いますが、おおむね以下のような感じです

コボッタ(デンソーウェーブ) の基本

cobotta には基本３つの制御経路がある

  1. b-CAP 経由での直接制御

  2. PacScript 経由での制御

  3. ORiN2 経由での制御

1,2,3 経由の制御は cobotta 内のコントラーラーにより cobotta 内の motion generator によりmotion が作れ、そしてコボッタが動作する。

問題は PacScript は デンソー独自の VB っぽいスクリプトであり、基本的に cobotta 上でしか動かすことが出ない。そして、この独自のスクリプトは コボッタ専用の実行環境で動かすだけであり一般的な意味でプログラム言語ではない。 いうなればコボッタというアプリ上で動かすだけのマクロ・スクリプトである。

そのため、他の言語との連携も基本的にはできない（実はやりようはないわけではない）。 申し訳ないが、複数機器との連携ではかなり使いにくく。コボッタ以外のロボットにスクリプトを移植するなどの 作業はほぼ現実的ではない。

(とb-capをdisることが、デンソーウェーブまわりではよく言われるので、 後述するORiN2ベースで展開した。しかしこれは失敗だった。 あとで高速通信用に、b-cap で実装し直したが、 ぶっちゃけ、ORiN2 より b-cap の方がマシだと思う。 ORiN2 が普及しないのは、よく理解できて、b-cap が普及しないのも理解できる。 デンソーのコボッタ制御システムは最初から最後まで失敗で、ORiN3 が後発すぎて、しかも情報が非公開(ORiN2を知っている人向け)なので、 DDSとの差別化で、gRPC というまともな通信プロトコルを採用したのに、 ほぼ腐っているマニア向けのシステムになっている。 結局はORiN3もただのORiNなのだ。)

それに対して、b-CAP は一般的な low-level 制御である(いうほど low-level ではなく割と使えるがここでは割愛)ために、 一応ソケット通信さえ使えればコボッタの制御は外部から可能であり、 つまりなんらかのプログラム言語で統括して制御可能である。 ただし、low-level コマンドのみデンソーウェーブから公開されている だけである点から、一般には使いにくいし開発労力がかかると言われる （情報提供がデンソーウェーブからないだけで、割とまともである。ただ、とにかくデンソーウェーブは情報を提供しない）

つまり、一般には、デンソーウェーブでコボッタを制御する場合は、デンソーウェーブが 開発と展開を進める。ORiN を使うことになる。

ORiN2 SDK は 売り物なので買わなくてはならない。 ORiN3 オープンソースなのだが、ORiN2を知ってないとおそらく 使い物にならないほどの情報しか提供してないので、ほぼ ただのゴミだ。ドキュメントやサポートなどを含めて、 ORiN2 よりお金もかかる。一般的ではない。

ORiN2 は COM ベースである

純粋にプログラム実装としてみると、ORiN2 は widnwos の COM ととして作られている。 windows は linux のようにオブジェクトを静的/動的に リンクする以外に、COM として提供する仕組みがある。 COM として提供されるとそれは実態としてはプロセスになる。 つまりプロセス間通信がある。

Windows というプログラムの処方箋で全てのプログラムを COM の処方箋で書けば問題がない。ところが、python の ような、linux からの unix 文化圏から移植したような 世界とは合わない。すべてのCOMで書いて、通信する ことで機能を実現する文化と。ライブラリとしてリンクする 文化の違いだ。

python プログラムないでCOMインスタンス呼び出しを 一つのCOMが動くプロセス内に押し込めて、サバーループ的に うまく呼び出すなど工夫がないと。使い方次第だが、 割と普通に動かすことができない。何も考えずに gRPC に COM を載せようとしたりしたら破綻する。

コボッタというよりは、COM を win32 で適当に ラップしただけの python モジュールあるあるの アホな現象がおきる。ORiN2 の python 対応が 非公式な点はこれが理由の一つである。windows で制御を行うときの典型的な落とし穴である。

ORiN2 で書いても b-CAP で書いても RC8 プロバイダーを使う

つまるところ、ORiN2 で書いたとしても、b-CAP で書いたとしてもそれぞれ 低次元のハードウエアドライバとしては RC8 というプロバイダー経由の操作になる。 つまり枠組みとしては ORiN の位置であると言い換えた方がいいかもしれない。 ともかく、RC8 デバイスである以上操作は同じであり、突き詰めると ORiN2 もb-CAPも ほぼ同じメソッドが存在する。

メソッド/クラス構成としてORiN2 は構造化されてそれぞれ権限がある。たいして、b-CAP が 非常にシンプルである。基本的にこれらは直接使うことはなく、上位系のクラスライブラリを 作りそのメソッドを使うことで動かすことになる。

スサノオにおけるコボッタ制御の基本構造

プログラムの構造としては簡略化して記述すると、下記になる。 だいぶ簡略化してあるので正確性はほぼないのでなんとなくのイメージと思っていただければと思う。

(1) ユーザーの機器制御プログラム
↓
------- コボッタクライアント
python class library: DeviceProxy()
↓
<<BL774互換通信>>   <<gRPC高速通信>
------- コボッタサーバー
ESE774 Framerok
↓
-------- コボッタの基本制御 --------
python class library (制御クラス)
↓                          ↓
COM (windows object 通信) or  <<TCP通信>>
ORiN2オブジェクトモデル      or  b-cap プロトコル
↓
-------- コボッタハードウエア -------
RC8デバイス (cobotta)

となる。ロボットを使う人は(1)だけプログラムをすれば良い。

作者

  • Kengo NAKADA