Ideas from ARC about the CORBA FL interface

Interface ideas learned from K9 and K10 (Lorenzo)

CORBA usage and wrapping ideas learned from MIRO (Hans)

Generic Robot Interfaces (GRI)• Object-Oriented to be modular and applied to

various scenarios• Comes with detailed documentation for

unambiguous usage by multiple users• End-User focused (“PanTilt” rather than

“CtrlMotor”, etc.)• Do not provide extra functions not supported

by represented objects (like “track object” in the camera interface)

• Close to CLARAty modules and capabilities• Supports functionalities of K9client, I_K10,

RoverCommander and scalable

GRI usage in IRG

Currently refining the interface, will submit soon proposition to JPL

Experiment on K10 and replace current ICE network link

Replace K9client with CORBA & GRI (CLARAty DL/FL compatible)

Use GRI inside the Rover Controller itself for better component approach

T

High Level Subsystems

Access to Devices

Data structures for Telemetry(Using Notification Service)

Supporting Types

Lessons from CORBA in other projects (MIRO)

• CORBA offers more than IPC.

• Valuable CORBA features:– Naming Service– Notification Service– Asynchronous Method Invocation

Naming Service

Getting a reference (IOR) to a remote object.• Ad hoc: store in file, exchange via scp.• Object tree: Top level object provides

accessors for child interfaces / objects.• Naming Service: provides a map of names to

object references– Makes “top-level” interface unnecessary.– Structuring of name space possible

(subdirectories).

disc disc

client

scp

object 1object 2

object 3

?

disc disc

client

scp

object 1

object 2

object 3

Name ServiceName 1,Name 2,Name 3,

…

disc disc

client

scp

object 1

object 2

object 3

1. Ad hoc

2. Object Tree

3. Naming Service

1.

2.

3.

Object Reference Acquisition

Rather than using a hierarchy of interfaces (with brittle IDL), extensively advertising objects through the Naming Service keeps interfaces independent.

But it does require documenting object names outside of IDL.

Notification Service

• Subscription management (header):– domain_name: robot name– type_name: event name

• Instance based event filtering (filterable_data):– Constraint language.

• Payload (remainder_of_body):– Telemetry

– Perception results …

Asynchronous Message Invocation (AMI)

Problem:• Many physical operations take time.• Clients (i.e. DL) mostly require non-blocking

semantics.• But not always.AMI Solution:• Allowing to call a blocking operation as a non-

blocking one.• No changes on the server side required.• Client can use both access methods.

Blocking Method Call(Direct CORBA)

Non-Blocking Method Call(Using AMI)

Client/Server Helper Classes

• Provide default configuration of the ORB• Generic helper methods

– Name Service operations– …

• Ease common operations– Object reference acquisition– Servant handling– AMI operations

Client Side Wrappers

Hiding CORBA• Development

overhead:– Coding overhead– Debugging overhead

• Usage overhead:– Runtime overhead– Another possible

place to look for errors

Keeping CORBA optional• Cumbersome for non-

trivial interfaces:– Data structures– Exceptions

• Difficult for many features:– Naming Service ->

map<string, IOR>– Notification Service ->

reimplement a big spec?– AMI -> ???

Simple Client Example// simple IDL interfaceinterface Foo{ long bar(in long p);};

// simple c++ clientvoid main (int argc, char * argv[]) { IRG::Client client(argc, argv); // client helper class // IOR resolution helper method (naming service) Foo_var foo = client.resolveName<Foo>("FooInstance1");

int rc = foo->bar(2); // method invocation}

Simple Server Example

// servant implementationstruct FooImpl : public virtual POA_Foo { virtual int bar (int p) { return 2 * p; }};

// server implementationvoid main (int argc, char * argv[]) { IRG::Server server(argc, argv); // helper class FooImpl * foo_servant = new FooImpl(); // servant instance

// servant activation server.activate_named_object("FooInstance1", foo_servant);

server.run(); // server loop}

AMI Client Examplevoid main (int argc, char * argv[]) { IRG::Server server(argc, argv); // helper class server.detach() // background thread for callback Foo_var foo = server.resolveName<Foo>("FooInstance1");

// AMI helper class IRG::Ami_Helper<IRG::AMI_Foo_bar> helper; // asynchoronous invocation // passing the callback as first parameter foo->sendc_bar(helper.handler()->_this(), 2); ... // do something else while (!helper.finished()); // busy wait till finished helper.wait(); // or wait till finished int rc = helper.result(); // retrieve return value}

Summary• Keep interfaces compact, user-focused, well-

mapped to FL capabilities.• Use Naming Service for interface

independence.• Use Notification Service for transport of

telemetry (including structs).• Use CORBA internally in FL.• Use AMI for non-blocking DL/FL calls.• Use wrappers sparingly.