orca-robotics INTRODUCTION Overview Download and Install Quick Start Documentation Publications REPOSITORY Interfaces Components Libraries Utilities Software Map DEVELOPER Tutorials Examples Dev Guide Dashboard Wiki login/pass: orca/orca PEOPLE Contributors Users Project Download Mailing lists

Suggestions on the Internal Component Structure Note: Reviewed for release 2.0.0. To reiterate, components can be developed in any way you choose. So long as they implement their interfaces, other components will be able to interoperate with them. This page contains suggestions for how to think about components, and how to write them using libOrcaIce. Several of the components in the repository are designed in this way. A basic component template looks like this: The main pieces are: Component Derives from orcaice::Component. This the main class which instantiates and contains the other pieces. Deriving from orcaice::Component makes it easy to place it within either a stand-alone application or an IceBox Service. To implement an orcaice::Component, the 'start()' and 'stop()' functions must be implemented. Interface Implementation This class implements the methods defined in the Slice interface definition, ie it does the talking to the outside world. By convention, the implementation of interface MyInterface is called MyInterfaceI. The files are named myinterface.h and myinterface.cpp. Remote Method Invocations arrive asynchronously from the outside world or from the Main Loop. Requests from the outside world can be answered using the information in the thread-safe buffers. Buffers The buffers are instantiations of orcaice::PtrBuffer. They're thread-safe (to handle the concurrency issues presented by simultaneous access from MainLoop and the outside world), and specially designed for Ice classes. Main Loop Most (but not all) components need to do some work continuously. MainLoop is the class that holds the thread of execution (it derives from orcaice::Thread). MainLoop's job is to be an intermediary between Hardware/Algorithm and Interface_Implementation (via the Buffers). A loop might look somthing like this (going vaguely clockwise in the figure): Check if new requests have arrived at the Buffers Hand the request(s) to the Hardware/Algorithm Read the data information generated by the Hardware/Algorithm (a blocking call) Send that data to the world via IceStorm Hand the data to the Buffers so the world can query it directly Goto step 1 Hardware/Algorithm This is the part that actually does the work. It may have its own internal threads. The purpose of this design is try to separate (a) network communication, (b) sequence of control (including setup/shutdown, component life-cycle), and (c) the algorithm or hardware driver itself.

Webmaster: Tobias Kaupp (tobasco at users.sourceforge.net)

---