ORIX: Open Robot Interface (eXtensible)Edit

The Extensible Open Robot Interface (ORIX) is intended to be a protocol that all designers of products meant to be installed in, components of, or used with Second Life robot avatars can share. Products that implement ORIX will be able to work together to some extent, such that one might be able to use a remote control by one maker to control an android using a control system designed by another maker, using a power system designed by yet a third maker.

There are two classes of ORIX compatible items: ORIX Cores, and ORIX Devices. An ORIX Core is the main control system for a robot. It provides information about the robot's state, and accepts commands intended for the robot. An ORIX Device, on the other hand, is something that will use information about the robot's state as provided by an ORIX Core, and/or send commands to an ORIX Core. Examples of possible ORIX Devices include batteries, indicator lights, control panels, remote controls, robot detectors, interference generators, and so on.

ORIX itself consists of a specification for sending messages between ORIX Cores and ORIX Devices. A Core or Device only needs to support a few things in order to call itself an ORIX Core or an ORIX Device. However, most will go well beyond this and offer other features in addition. Some of these features will take advantage of optional ORIX messages. Others may use unique messages not specified by ORIX in order to take advantage of the unique features of a particular Core or Device.

Look at:


ORIX was originally conceived after a number of conversations between JulieDoll (designer of the Autonomy Control Systems line of robot control products) and others in which we bemoaned the fact that it was difficult if not impossible for an Cinis Charging system to charge an ACS Core, or an ACS Remote Control to control a robot with a Kittybot core, and so on. But JulieDoll wondered, what if we could make that possible? ACS had always intended to allow others to make devices to interact with a CCU. But why stop there? ORIX is the beginning of an attempt to produce an interface that can be used not only by ACS products, but by anyone else who wants to.

ACS intends to use ORIX in its Version 2 product line, allowing others to design Devices to interact with a CCU (which may be renamed an ACS Core), and to allow their Cores to respond to commands from ACS Devices. ORIX is initially being designed with the needs of the ACS Core in mind, but with a strong interest in the feedback of other product developers. It is hoped that the open and extensible nature of ORIX will make it suitable for use in their products as well.

As of this writing (July 10, 2014), the Wiki is fairly sparse, and definitely not ready for real use. Hopefully there is enough here to give a good sense of what I have in mind. If you're a product developer, does this seem like an interface you would feel comfortable using? (Note that LSL now has built-in functions for working with [ JSON ] strings.)

Although JulieDoll has started this initiative, don't think she's the only one who can contribute to it. If you have ideas or other ways you want to be a part of ORIX development, please share them!

Community content is available under CC-BY-SA unless otherwise noted.