So what is OPEN-R after all? OPEN-R is a framework made by Sony to allow programmers to interact with their robots (namely the AIBO). openSDK implements the full OPEN-R API, so that the code designed to run on the AIBO robot can be run on a standard PC, allowing faster debug times.
An OPEN-R object has nothing to do with what we usually call objects. An OPEN-R object is basically a thread. Those objects are run in a pseudo-concurrent way, but without parallel execution inside of them (which can make the code simpler, as you don't need to worry with Thread Safety most of the time). These objects are usually a single C++ class (derived from the OPEN-R's OObject class).
The objects are then connected to each other, so that they can exchange messages. The architecture is event driven and it relies on the Observer pattern as the flow controller. After the Object Manager connects the objects, the observer sends an Assert-Ready message to its subjects (that receive it in its Ready() method) and then they can start sending messages (that are received by the Observer in its Notify() method).
openSDK is run from a regular text console, by issuing the following command:
./OPENRloader <MS dir>If you want to run the ObjectComm example, you would type:
./OPENRloader samples/common/ObjectComm
The first thing openSDK does is to load the OBJECT.CFG file, to know which modules it should load. Then it loads the modules, which one on its thread. After loading the thread, the loader runs a function (__start_module) that is "secretly" bundled with each module (it is inserted in the object stub).
To stop openSDK, just hit CTRL-C and it will start the shutdown produces immediately.
Here we present an image that shows how an object is usually built:
All the code is in C++ (excluding some Perl scripts) and it is (or should be) documented with doxygen tags, so that we can generate automatic documentation. Below we present the contents of each directory in the source tree:
Below we list the implementation details of openSDK and some problems we may have currently.
Each object is gzip'ed in its own file, as with OPEN-R, and they are extracted on-the-fly. Inside each object it is also injected (automatically) some code, called the stub. This code is generated by the stubgen2 script. The stub contains the message handlers (control, ready, etc..) and a table that is indexed by a Selector. A magic function (__start_module) is also bundled and it is responsible for running the DoInit, DoStop, etc.. methods and also for delivering messages to the right handler (by indexing the handlers table).
All code is thread safe as the objects can run concurrently. However, as it is guaranteed that there is no parallel execution inside an object, some parts of the code don't need any special care.
We also redirect some unsafe libc functions to our own implementation (using ld's --wrap "hack"). For example, we "capture" the strtok() calls from modules and redirect them internally to strtok_r(), which is thread safe.
The message queue is implemented with a simple STL queue. Each item holds a Selector (the message handler table index) plus a message pointer (void*). When sending a message to an object, the system simply inject a new item in this queue (thus it is protected with a mutex).
Here there are some questions that are still lacking good and portable solutions:
Currently the code has only been tested on linux, but it should work on any standard Unix system. The low-level internals of openSDK are quite hardcore and the old linux Pthreads implementation (linuxthreads) isn't able to run openSDK correctly. So, you need the NPTL implementation to run openSDK on linux (it is the default since glibc 2.4)
A port to Windows might be available in the future, but there isn't an estimated time yet, since it will require quite a big effort to do that. The current openSDK implementation heavily relies on Unix specific features that aren't available on Windows. For example, we would need to port the DSO handling to DLLs. Cygwin doesn't work at this moment.
openSDK supports running multiple robots on the same computer (provided you have enough memory and enough CPU power - a multi-core CPU is recommended). However, you need to pay attention to some details that can create incompatibilities between robots, like the TCP/UDP port binding (different robots should bind to different ports).
Our USARSim connector still doesn't support multiple robots though, because we cannot launch multiple image servers on the same computer. The solution is to grab a MultiView image and split it into robot views (one per robot). More information in the USARSim forum.
AIBO and OPEN-R are a trademark or a registered trademark of Sony Corporation.