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 client scp object 1 object 2 object 3 ? disc client scp object 1 object 2 object 3 Name Service Name 1, Name 2, Name 3, … disc client scp object 1 object 2 object 3 1.Ad hoc 2.Object Tree 3.Naming Service 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 –Notification Service -> reimplement a big spec? –AMI -> ???

Simple Client Example // simple IDL interface interface Foo { long bar(in long p); }; // simple c++ client void main (int argc, char * argv[]) { IRG::Client client(argc, argv); // client helper class // IOR resolution helper method (naming service) Foo_var foo = client.resolveName ("FooInstance1"); int rc = foo->bar(2); // method invocation }

Simple Server Example // servant implementation struct FooImpl : public virtual POA_Foo { virtual int bar (int p) { return 2 * p; } }; // server implementation void 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 Example void main (int argc, char * argv[]) { IRG::Server server(argc, argv); // helper class server.detach() // background thread for callback Foo_var foo = server.resolveName ("FooInstance1"); // AMI helper class IRG::Ami_Helper 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.