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

Running a super-simple component Note: Reviewed for release 2.10.0. In the previous tutorial we described how to write a basic Orca component. Now we show how to run it. Starting Orca Start IceGrid Registry and IceStorm server as described in the Quick-Start Guide. Create a new system directory and copy Orca sample files. $ mkdir -p ~/sys/tutebrick; cd ~/sys/tutebrick $ cp [ORCA-INSTALL]/share/orca/cfg/brick.cfg . Starting Brick Component The brick.cfg file is already configured the way we want it here, so simply run the component: tutebrick$ brick You'll see a few lines of feedback in the terminal window. tutebrick$ brick orca: Versions: Ice=3.2.1 Orca=2.9.0 orca: Brick: Loaded command line properties orca: Brick: Loaded component properties from 'brick.cfg' orca: Brick: Loaded global properties from '/home/makara/.orcarc' orca: Brick: Loaded factory default properties orca: Brick: Created object adapter orca: Brick: Initialized trace handler. orca: Brick: Status connected to status/*@jamaica/brick orca: Brick: Initialized status handler orca: Set property to default value: Orca.PropertyServerProxyString= orca: Brick: Initialized Home interface orca: Brick: Application initialized [ 12/23/07 03:26:34.980 jamaica/brick: info: LocalStatus: MainThread is ok : 'Initialized' ] We'll go through them line-by-line and explain what they mean. tutebrick$ brick orca: Versions: Ice=3.2.1 Orca=2.9.0 With multiple versions of Ice and Orca installed on the same computer, it's hard sometimes to tell which version you are running. When debugging, always look at this first line to make sure you are not running code from a year ago. orca: Brick: Loaded command line properties In this case we did not provide any explicit command line options. But implicitly we specified component config file, i.e. --Orca.Config=brick.cfg. See the complete guide to Orca Configuration Files for more details. orca: Brick: Loaded component properties from 'brick.cfg' The component understood our intention and loaded the correct config file. orca: Brick: Loaded global properties from '/home/makara/.orcarc' The global config file was not specified explicitely, so the default value was used. orca: Brick: Loaded factory default properties Some properties have hardwired "factory" defaults. They are loaded last (previously loaded properties are not overwritten). orca: Brick: Created object adapter This is an important internal step in component initialization. It happens deep inside libOrcaIce before getting to the component code. orca: Brick: Initialized trace handler. Initialized Tracer. Local Tracer is always created. A networked Tracer is initialized only if the Tracer interface is enabled. This interface can be disabled with an appropriate value of the orcaice::ComponentInterfaceFlag passed to orcaice::Component. orca: Brick: Status connected to status/*@jamaica/brick Status messages will be published to an IceStorm topic with this name. Anybody can subscribe to them remotely. orca: Brick: Initialized status handler Initialized Status. Local Status is always created. A networked Status is initialized only if the Status interface is enabled. This interface can be disabled with an appropriate value of the orcaice::ComponentInterfaceFlag passed to orcaice::Component. orca: Set property to default value: Orca.PropertyServerProxyString= It is possible to configure the component to use a a remote property server. This is an advanced feature and we don't use it here. orca: Brick: Initialized Home interface Initialized Home interface. It is used for accessing various information remotely, e.g a list of provided interfaces, component properties. This interface can be disabled with an appropriate value of the orcaice::ComponentInterfaceFlag passed to orcaice::Component. orca: Brick: Application initialized The Component::start() function has returned the control to orcaice::Application. [ 12/23/07 03:26:34.980 jamaica/brick: info: LocalStatus: MainThread is ok : 'Initialized' ] This status call is made before entering the main loop. If you are using default configuration files, you don't see any more statements even though we are printing debug statements inside the main loop. This is because the debug statements are not displayed on the screen by default. Stopping Brick Component We'll modify this behaviour but first we'll stop the component by pressing Ctrl-C. Here's what gets printed out. orca: Brick: Communicator is destroyed. Stopping component orca: Brick: Component stopped orca: Brick: Adapter deactivated orca: Brick: Application quitting. Orca out. Let's look at it line-by-line. orca: Brick: Communicator is destroyed. Stopping Component When Component::start() returns, the orcaice::Application class blocks waiting for a Communicator shutdown. This can happen if we destroy the Communicator manually but usually it happens when an interrupt signal is received (e.g. after a Ctrl-C). This is what happened just now and the Application told the Component to stop(). orca: Brick: Component stopped Component told the thread to stop and waited for it to terminate. By now all threads have terminated. orca: Brick: Adapter deactivated orca: Brick: Application quitting. Orca out. All networking is deactivated and the application has exited cleanly. Modifying Tracing Let's add this line to the config file brick.cfg. (Remember that the debug level of the statements inside the main loop is 5). Orca.Tracer.DebugToDisplay=5 Run the component again tutebrick$ brick orca: Versions: Ice=3.2.1 Orca=2.7.0+ Project=2.7.0+ orca: Brick: Loaded command line properties orca: Brick: Loaded component properties from 'brick.cfg' orca: Brick: Loaded global properties from '/home/makara/.orcarc' orca: Brick: Loaded factory default properties orca: Brick: Created object adapter orca: Brick: Initialized trace handler. orca: Brick: Status connected to status/*@jamaica/brick orca: Brick: Initialized status handler orca: Brick: Initialized Home interface orca: Brick: Application initialized [ 12/23/07 03:33:16.818 jamaica/brick: debug: LocalStatus::setMaxHeartbeatInterval(): Adding new subsystem: 'MainThread' ] [ 12/02/07 01:13:51.429 jamaica/brick: debug: Adapter activated ] [ 12/23/07 03:33:16.887 jamaica/brick: info: LocalStatus: MainThread is ok : 'Initialized' ] [ 12/02/07 01:13:51.430 jamaica/brick: debug: Running main loop ] [ 12/02/07 01:13:52.430 jamaica/brick: debug: Running main loop ] [ 12/02/07 01:13:53.431 jamaica/brick: debug: Running main loop ] [ 12/02/07 01:13:54.431 jamaica/brick: debug: Running main loop ] In addition to the debug traces from the main loop we got a few more from the component initialization sequence. Notice that the time stamps of the main-loop traces correspond to the 1Hz frequency of the main loop. A bit more info is displayed on shutdown as well. Press Ctrl-C. orca: Brick: Communicator is destroyed. Stopping component [ 12/02/07 01:16:01.308 jamaica/brick: debug: orcaice::Component: stopping ComponentThread.... ] [ 12/23/07 03:33:22.889 jamaica/brick: debug: Running main loop ] [ 12/23/07 03:33:22.891 jamaica/brick: debug: dropping out from run() ] [ 12/02/07 01:16:01.452 jamaica/brick: debug: orcaice::Component: ComponentThread stopped. ] orca: Brick: Component stopped orca: Brick: Adapter deactivated orca: Brick: Application quitting. Orca out. Exercise for the User When the system is as simple as this one, it's easier to observe what happens when something goes wrong. So here are a few thing to try: Stop the Registry, try to start the component, look at the error message it spits out. Start the Registry and stop the IceBox/IceStorm, try to start the component. Stop the Registry, start the IceBox/IceStorm, try to start the component. After a while start the Registry. The component should continue happily. Start the Registry and the IceBox/IceStorm, start the component. Now kill the Registry. Nobody should be complaining. That's because the servers do not need the registry after they are registered. The clients, of course, would not be able to connect.

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

---