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.
Top Related