Overview of COBOTTA Control
The following is a simplified overview. Some details are intentionally approximate.
Fundamentals of COBOTTA (DENSO WAVE)
There are three basic control routes for COBOTTA:
Direct control through b-CAP.
Control through PacScript.
Control through ORiN2.
In each case, the controller inside COBOTTA produces motion through its motion generator, and the robot executes that motion.
PacScript is a proprietary, VB-like scripting language developed by DENSO. It runs essentially only on COBOTTA and its dedicated execution environment. Rather than being a general-purpose programming language, it resembles a macro language embedded in the COBOTTA application.
Consequently, integration with other programming languages is difficult, although workarounds exist. It is especially inconvenient for coordinating multiple instruments, and porting scripts to robots other than COBOTTA is generally impractical.
(There is a tendency around DENSO WAVE to criticize b-CAP, which initially motivated the ORiN2-based implementation described below. In retrospect, this was a mistake. The implementation was later rewritten using b-CAP for high-speed communication; in my view, b-CAP is preferable to ORiN2. It is understandable why neither ORiN2 nor b-CAP has become widely adopted. In my assessment, DENSO’s COBOTTA control ecosystem has been unsuccessful throughout. ORiN3 appeared too late, and much of its information remains unavailable to people unfamiliar with ORiN2. Although it adopted gRPC, a reasonable communication protocol, partly to differentiate itself from DDS, the surrounding system remains niche and difficult to use. In the end, ORiN3 is still ORiN.)
By contrast, b-CAP offers a comparatively low-level interface (although it is more usable than that label might suggest). If socket communication is available, an external program can control COBOTTA. This allows coordination through a general-purpose programming language.
However, DENSO WAVE publishes mainly the lower-level commands, making the interface appear difficult to use and costly to develop against. In my experience, the protocol itself is reasonably sound; the more serious problem is the lack of information provided by DENSO WAVE.
In practice, users who follow DENSO WAVE’s recommended control architecture will generally use ORiN, which the company develops and promotes.
The ORiN2 SDK is commercial and must be purchased. ORiN3 is open source, but the documentation and other information are, in my assessment, inadequate unless the user already understands ORiN2. The resulting support and development costs can exceed those of ORiN2, and it is not a general-purpose solution.
ORiN2 is based on COM
From an implementation standpoint, ORiN2 is built on Windows COM. In addition to linking objects statically or dynamically, Windows provides COM as a component mechanism. COM components can involve separate processes and interprocess communication.
If every component of a Windows application follows the COM model, this can be coherent. Problems arise when integrating software from the Unix-style library ecosystem, such as Python, because the design assumptions differ: one approach relies on communication among COM components, while the other typically links libraries into the application.
To use COM reliably from Python, it may be necessary to marshal calls to a single process or thread that owns the COM instance, for example through a server loop. Without such care, otherwise ordinary applications can fail. Simply placing COM calls behind gRPC without considering this model is likely to cause problems.
These are common pitfalls when Python wrappers expose COM objects through win32 interfaces. This is one reason Python support for ORiN2 is unofficial, and a typical trap in Windows-based device control.
Both ORiN2 and b-CAP use the RC8 provider
Whether the application uses ORiN2 or b-CAP, the underlying hardware access ultimately goes through the RC8 provider. In that sense, both routes operate within the broader ORiN ecosystem. Because the target is the same RC8 device, the underlying operations are similar, and ORiN2 and b-CAP expose largely corresponding methods.
ORiN2 organizes methods and classes into a structured model with different access rights, whereas b-CAP is much simpler. Applications normally use neither interface directly: instead, a higher-level class library encapsulates the operations.
Basic structure of COBOTTA control in SUSANOO
The following diagram is highly simplified and intended only to convey the overall architecture.
(1) User's device-control program
↓
------- COBOTTA client -------
Python class library: DeviceProxy()
↓
<<BL774-compatible communication>> <<High-speed gRPC communication>>
------- COBOTTA server -------
ESE774 Framework
↓
------- Basic COBOTTA control -------
Python class library (control class)
↓ ↓
COM (Windows object communication) or <<TCP communication>>
ORiN2 object model or b-CAP protocol
↓
------- COBOTTA hardware -------
RC8 device (COBOTTA)
Users who operate the robot only need to write the program at level (1).