Approaches to using CORBA with Orocos

We have a working Orocos-based robot control application based, for the moment, around the Taskbrowser. It gets the job done, but now we need to add more user-interface capability. This brings up the question of how to structure communication between the GUI and robot control app. Our existing robot control app has a single user-interface component dealing with the user.

We see two approaches and wanted to get some feedback from users (particularly as we're having trouble with one of the approaches)

1) Leave the robot control app as is. Create a proxy task in the GUI app for the user-interface component that is in the robot control app. This runs but doesn't work completely: methods actually work despite getting errors ("Failing Corba::Any creation of type void"), however, data ports don't work at all (just get the same error).

2) Move the user-interface component from the robot control app into the GUI, and have it connect to its peers through Corba. We're not as comfortable with the structure of this approach, as one method call to the user-interface component may result in method calls to several other components. We'd rather push the single method call across the wire and have the resulting several calls all occur locally at the robot, rather than having the single call be local to the GUI and the several calls occur across IP latency/jitter to the components at the robot.

We did not find anything within the Orocos website/docs that mentions how you might go about structuring an application like this (though there are plenty of great examples demonstrating ways to structure the robot control app, thanks everyone!)

Any input appreciated.
S

Approaches to using CORBA with Orocos

On Wednesday 13 August 2008 23:07:42 snrkiwi wrote:
> runs but doesn't work completely: methods actually work despite getting
> errors ("Failing Corba::Any creation of type void"), however, data ports
> don't work at all (just get the same error).

- Could you show what client side code you wrote for both cases?

- Are you using the dataport interface using the Orocos C++ wrappers or the
native IDL interface ?

Peter

Approaches to using CORBA with Orocos

On Aug 14, 2008, at 04:46 , Peter Soetens wrote:

> On Wednesday 13 August 2008 23:07:42 snrkiwi wrote:
>> runs but doesn't work completely: methods actually work despite
>> getting
>> errors ("Failing Corba::Any creation of type void"), however, data
>> ports
>> don't work at all (just get the same error).
>
> - Could you show what client side code you wrote for both cases?
>
> - Are you using the dataport interface using the Orocos C++ wrappers
> or the
> native IDL interface ?

Data ports are working, though they still put out the errors. We had a
bug masking the change.

Playing with the scripting interface I see how to send methods or
write to remote data ports. But how you read from remote data ports?

Note that using the scripting interface on the proxy does not produce
the errors at the remote site that the taskbrowser does. Not sure if
that is of interest?

S

Approaches to using CORBA with Orocos

On Aug 14, 2008, at 04:46 , Peter Soetens wrote:

> On Wednesday 13 August 2008 23:07:42 snrkiwi wrote:
>> runs but doesn't work completely: methods actually work despite
>> getting
>> errors ("Failing Corba::Any creation of type void"), however, data
>> ports
>> don't work at all (just get the same error).
>
> - Could you show what client side code you wrote for both cases?

ctaskbrowser-gnulinux

port.Set(xxx)

or

methodname()

The server side code is almost identical to what we sent in for http://www.orocos.org/node/636
, except that we put the sender and receiver together into the
application, and then simply ControlTaskServer::RunOrb(). Can send
entire code if it would help?

> - Are you using the dataport interface using the Orocos C++ wrappers
> or the
> native IDL interface ?

We have tried using the C++ interface directly, instead of using
taskbrowser but it appears we have to anti-clone the port from the
Corba proxy, and then we still can't find the right approach to
actually changing this to some useful class that we could use
directly. This approach seems really messy, but we followed along what
the taskbrowser does.

Is there any simple way to turn a proxy back into an actual, useful
component object? Or do you really have to retrieve each of the
objects of interest (ie methods, ports) from the component proxy and
then turn them into useful Orocos objects?

Cheers
S

Approaches to using CORBA with Orocos

On Thursday 14 August 2008 15:15:01 S Roderick wrote:
>
> > [...sorry for the orocos-dev talk below...]
> > A 'simple' solution to this port problem is to add the
> > buildDataPort(std::string name)/buildBufferPort methods to the
> > CorbaTemplateProtocol.hpp class. Then the proxy can create these
> > ports right
> > away and they will be 'strong'.
> >
> > Maybe the latter solution is what you hoped would be present in the
> > ControlTaskProxy ?
>
> Yes, I think this is what I had in mind! This was also brought up in
> the other post I did several weeks back, but we never resolved it.
>
> Simply put, I want to access a proxy's data ports without having to
> connect another port to it. This is the weak vs strong bit above I
> think.

Exactly. Today, It only works like in the example of my other mail. In order
to write something like

PortInterface* the_port = proxy->ports()->getPort("the_port");
DataPort data_port = dynamic_cast >(the_port);
data_port->Set( 3.0 ); // write directly, bypassing the connection object

...we'd need to change the .idl interface, because today we only allow access
over connection objects (using 'createDataChannel'), which guard
thread-safeness for remote calls.

Why don't want you to connect using a connection object to the port from the
GUI ?

[...]
>
> At the moment, it appears to me that the GUI app will have to write
> code to individually pull out each method/port/etc from the proxy
> object that it needs (with calls like proxy->ports()->getPort("data")
> or proxy->methods->getMethod<>(), etc). This is workable, but it
> essentially means you are reproducing the individual items from the
> remote component's interface (ie you are manually reproducing the
> interface). Slightly painful.

However painful, it is the 'recommended' way of communicating between any 2
components in Orocos, such that network distribution is completely
transparant. It doesn't scale 'very' well, but it is the only option we have
in C++ (other than using code generation, which is what CORBA does),
otherwise, we'd need to revisit Objective-C, which has all these features as
a part of the language :-]

>
> Hence the overall question of "structure" that prompted this thread. I
> can't find any example code anywhere, except buried in taskbrowser, of
> how to do this in a real situation.

The taskbrowser is the worst teacher you could find :-) I now realise that
this kind of 'application building' howto should contain such examples,
especially when CORBA gets involved.

Peter

Approaches to using CORBA with Orocos

On Thursday, August 14, 2008, at 09:34AM, "Peter Soetens"

<peter [dot] soetens [..] ...> wrote:
>On Thursday 14 August 2008 15:15:01 S Roderick wrote:
>>
>> > [...sorry for the orocos-dev talk below...]
>> > A 'simple' solution to this port problem is to add the
>> > buildDataPort(std::string name)/buildBufferPort methods to the
>> > CorbaTemplateProtocol.hpp class. Then the proxy can create these
>> > ports right
>> > away and they will be 'strong'.

I am fairly sure I won't like the answer to this .... but what would be involved with doing the above?

>> > Maybe the latter solution is what you hoped would be present in the
>> > ControlTaskProxy ?
>>
>> Yes, I think this is what I had in mind! This was also brought up in
>> the other post I did several weeks back, but we never resolved it.
>>
>> Simply put, I want to access a proxy's data ports without having to
>> connect another port to it. This is the weak vs strong bit above I
>> think.
>
>Exactly. Today, It only works like in the example of my other mail. In order
>to write something like
>
> PortInterface* the_port = proxy->ports()->getPort("the_port");
> DataPort data_port = dynamic_cast >(the_port);
> data_port->Set( 3.0 ); // write directly, bypassing the connection object
>
>...we'd need to change the .idl interface, because today we only allow access
>over connection objects (using 'createDataChannel'), which guard
>thread-safeness for remote calls.

As a matter of interest, the above code works correctly even it not called from within a task context, right?

>Why don't want you to connect using a connection object to the port from the
>GUI ?

Huh? What do you mean? So, what is the relationship between connection objects and data ports?

>> At the moment, it appears to me that the GUI app will have to write
>> code to individually pull out each method/port/etc from the proxy
>> object that it needs (with calls like proxy->ports()->getPort("data")
>> or proxy->methods->getMethod<>(), etc). This is workable, but it
>> essentially means you are reproducing the individual items from the
>> remote component's interface (ie you are manually reproducing the
>> interface). Slightly painful.
>
>However painful, it is the 'recommended' way of communicating between any 2
>components in Orocos, such that network distribution is completely
>transparant. It doesn't scale 'very' well, but it is the only option we have
>in C++ (other than using code generation, which is what CORBA does),
>otherwise, we'd need to revisit Objective-C, which has all these features as
>a part of the language :-]

Understood. IDL's are usually not fun to deal with ...

>> Hence the overall question of "structure" that prompted this thread. I
>> can't find any example code anywhere, except buried in taskbrowser, of
>> how to do this in a real situation.
>
>The taskbrowser is the worst teacher you could find :-) I now realise that
>this kind of 'application building' howto should contain such examples,
>especially when CORBA gets involved.

Actually, I did want to bring that up. I think we (the project) should consider adding some more application-centered examples. These should be complete examples, more like tutorials, of some of these concepts that are very common and every newcomer ends up trying to figure out. The existing example code is decent, however, it doesn't get you to the level of a fully integrated application. Also, unfortunately, some of the code is obsolete or doesn't compile.

S

Approaches to using CORBA with Orocos

On Thursday 14 August 2008 17:57:57 S Roderick wrote:
> On Thursday, August 14, 2008, at 09:34AM, "Peter Soetens"

<peter [dot] soetens [..] ...> wrote:
> >On Thursday 14 August 2008 15:15:01 S Roderick wrote:
> >> > [...sorry for the orocos-dev talk below...]
> >> > A 'simple' solution to this port problem is to add the
> >> > buildDataPort(std::string name)/buildBufferPort methods to the
> >> > CorbaTemplateProtocol.hpp class. Then the proxy can create these
> >> > ports right
> >> > away and they will be 'strong'.
>
> I am fairly sure I won't like the answer to this .... but what would be
> involved with doing the above?

Create two classes CorbaDataPortProxy and CorbaBufferPortProxy which inherit
from DataPort and BufferPort and in these classes, most functions must become
virtual. They use an extended DataFlow.idl interface which allows direct
access to the Port's interface, mainly the set/get methods and for buffers,
the whole push/pop/size/capacity/... interface. Next the buildDataPort() and
buildBufferPort() functions would create the above xProxy objects. The
ControlTaskProxy uses the latter two to fill in the ports() interface.

Not that 'simple' now I'm thinking about it...

> >
> >Exactly. Today, It only works like in the example of my other mail. In
> > order to write something like
> >
> > PortInterface* the_port = proxy->ports()->getPort("the_port");
> > DataPort data_port = dynamic_cast >(the_port);
> > data_port->Set( 3.0 ); // write directly, bypassing the connection object
> >
> >...we'd need to change the .idl interface, because today we only allow
> > access over connection objects (using 'createDataChannel'), which guard
> >thread-safeness for remote calls.
>
> As a matter of interest, the above code works correctly even it not called
> from within a task context, right?

Yes, of course, nowhere is a pointer to a TaskContext used nor required.

>
> >Why don't want you to connect using a connection object to the port from
> > the GUI ?
>
> Huh? What do you mean? So, what is the relationship between connection
> objects and data ports?

The IDL interface allows to create connections, to which you can write (or
read) data. You don't write the data directly to the C++ DataPort object.
(This allows them to make the read/writes thread-safe). The practical
consequence of this indirection is that you must 'connect' the DataPort (ie
craete a connection object and attach the port to it) before you can use it
from the IDL layer. This is done in 'createDataChannel' in the DataFlow.idl.
Using a connection is strictly speaking not required in pure C++, although it
is discouraged for thread-safety reasons.

> >The taskbrowser is the worst teacher you could find :-) I now realise that
> >this kind of 'application building' howto should contain such examples,
> >especially when CORBA gets involved.
>
> Actually, I did want to bring that up. I think we (the project) should
> consider adding some more application-centered examples. These should be
> complete examples, more like tutorials, of some of these concepts that are
> very common and every newcomer ends up trying to figure out. The existing
> example code is decent, however, it doesn't get you to the level of a fully
> integrated application. Also, unfortunately, some of the code is obsolete
> or doesn't compile.

I think most of our users are at a level now where we could write such a
document. Hopefully the Drupal 5 upgrade of Orocos.org can help setting up a
wiki portal with 'code snippets' and 'code templates'. Although that
shouldn't stop us from comming up with such stuff right now.

Peter

Approaches to using CORBA with Orocos

On Thursday 14 August 2008 13:41:40 S Roderick wrote:
> On Aug 14, 2008, at 04:46 , Peter Soetens wrote:
> > On Wednesday 13 August 2008 23:07:42 snrkiwi wrote:
> >> runs but doesn't work completely: methods actually work despite
> >> getting
> >> errors ("Failing Corba::Any creation of type void"), however, data
> >> ports
> >> don't work at all (just get the same error).
> >
> > - Could you show what client side code you wrote for both cases?
>
> ctaskbrowser-gnulinux
>
> port.Set(xxx)
>
> or
>
> methodname()
>
> The server side code is almost identical to what we sent in for
> http://www.orocos.org/node/636 , except that we put the sender and receiver
> together into the
> application, and then simply ControlTaskServer::RunOrb(). Can send
> entire code if it would help?
>
> > - Are you using the dataport interface using the Orocos C++ wrappers
> > or the
> > native IDL interface ?
>
> We have tried using the C++ interface directly, instead of using
> taskbrowser but it appears we have to anti-clone the port from the
> Corba proxy, and then we still can't find the right approach to
> actually changing this to some useful class that we could use
> directly. This approach seems really messy, but we followed along what
> the taskbrowser does.
>
> Is there any simple way to turn a proxy back into an actual, useful
> component object? Or do you really have to retrieve each of the
> objects of interest (ie methods, ports) from the component proxy and
> then turn them into useful Orocos objects?

As I said in my previous mail, I don't understand the exact problem you're
having. Data Ports are the only 'weak' elements in the ControlTaskProxy in
the sense that they can not accept/return data until they are connected with
a local data port.Also, getting an 'anticlone()' of a CorbaPort just returns
the same weak object. The other parts (methods, properties, commands) of the
ControlTaskProxy work fine, except events, which are not supported in CORBA.

[...sorry for the orocos-dev talk below...]
A 'simple' solution to this port problem is to add the
buildDataPort(std::string name)/buildBufferPort methods to the
CorbaTemplateProtocol.hpp class. Then the proxy can create these ports right
away and they will be 'strong'.

Maybe the latter solution is what you hoped would be present in the
ControlTaskProxy ?

Peter

Approaches to using CORBA with Orocos

> As I said in my previous mail, I don't understand the exact problem
> you're
> having. Data Ports are the only 'weak' elements in the
> ControlTaskProxy in
> the sense that they can not accept/return data until they are
> connected with
> a local data port.Also, getting an 'anticlone()' of a CorbaPort just
> returns
> the same weak object. The other parts (methods, properties,
> commands) of the
> ControlTaskProxy work fine, except events, which are not supported
> in CORBA.

So for a method call, is it something like this?

m = proxy->methods()->getMethod<...>("somemethod")
m(...)

Ports is what I'm struggling with ...

> [...sorry for the orocos-dev talk below...]
> A 'simple' solution to this port problem is to add the
> buildDataPort(std::string name)/buildBufferPort methods to the
> CorbaTemplateProtocol.hpp class. Then the proxy can create these
> ports right
> away and they will be 'strong'.
>
> Maybe the latter solution is what you hoped would be present in the
> ControlTaskProxy ?

Yes, I think this is what I had in mind! This was also brought up in
the other post I did several weeks back, but we never resolved it.

Simply put, I want to access a proxy's data ports without having to
connect another port to it. This is the weak vs strong bit above I
think.

Given these components at the remote end

CORBA - user-interace - multiple control components - robot component

I want at the GUI

GUI code - user-interface-proxy - CORBA

and be able to write code to use the user-interface-proxy exactly like
I would if the GUI code was connected directly to the user-interface
component (ie they were in the same application). Now I completely
understand that this is an ideal concept, and most likely won't work
like that in reality, but I'm trying to find the most straight forward
way to do this.

At the moment, it appears to me that the GUI app will have to write
code to individually pull out each method/port/etc from the proxy
object that it needs (with calls like proxy->ports()->getPort("data")
or proxy->methods->getMethod<>(), etc). This is workable, but it
essentially means you are reproducing the individual items from the
remote component's interface (ie you are manually reproducing the
interface). Slightly painful.

Hence the overall question of "structure" that prompted this thread. I
can't find any example code anywhere, except buried in taskbrowser, of
how to do this in a real situation.

HTH
S

PS: I do realise I'm not suggesting any solutions here. I'm still
trying to understand the structure of the underlying problem. :-(

Approaches to using CORBA with Orocos

On Thursday 14 August 2008 14:14:09 S Roderick wrote:
> On Aug 14, 2008, at 04:46 , Peter Soetens wrote:
> > On Wednesday 13 August 2008 23:07:42 snrkiwi wrote:
> >> runs but doesn't work completely: methods actually work despite
> >> getting
> >> errors ("Failing Corba::Any creation of type void"), however, data
> >> ports
> >> don't work at all (just get the same error).
> >
> > - Could you show what client side code you wrote for both cases?
> >
> > - Are you using the dataport interface using the Orocos C++ wrappers
> > or the
> > native IDL interface ?
>
> Data ports are working, though they still put out the errors. We had a
> bug masking the change.
>
> Playing with the scripting interface I see how to send methods or
> write to remote data ports. But how you read from remote data ports?

That's why it only works for 'simple' script statements. There are no return
values in this interface. In some applications (like Blender) we're reading
ports using the Python language and the CORBA layer. If you have an example
of how other frameworks organise networked communication (in a better way)
I'd be glad to hear about it.

>
> Note that using the scripting interface on the proxy does not produce
> the errors at the remote site that the taskbrowser does. Not sure if
> that is of interest?

The reason is that the script statement in execute() is sent over to the other
side and processed overthere, while the ctaskbrowser parses the script
statement locally and must query the remote interface using CORBA.

Peter

Approaches to using CORBA with Orocos

On Thursday 14 August 2008 13:44:22 S Roderick wrote:
> >
> > This approach is what I would choose for as well. For calling simple
> > methods
> > and commands, you can even use the ScriptingAccess.idl interface and
> > call the
> > the execute( code ) function. This is easier than going through the
> > native
> > Method/Data Flow CORBA interface. It can only execute one statement
> > at a time
> > though.
>
> Ahhhh ... that makes sense. Using the native method/data-flow calls on
> the corba interface is nothing but ugly, unfortunately. :-( The
> scripting interface part might make life easier, we'll check it out.
> Thanks!

If you could write down a scenario (ie code) which you'd like to use client
side to read/write ports. That could help as well to quickly find a better
solution.

>
> So, is there no way to get a proxy of a component that has the same C+
> + interface as the remote component? This would allow you to directly
> access the C++ ports, methods, etc of the component (proxy) directly?

You mean, another one than ControlTaskProxy ? I don't understand this
question.

Peter

Approaches to using CORBA with Orocos

>> Ahhhh ... that makes sense. Using the native method/data-flow calls
>> on
>> the corba interface is nothing but ugly, unfortunately. :-( The
>> scripting interface part might make life easier, we'll check it out.
>> Thanks!
>
> If you could write down a scenario (ie code) which you'd like to use
> client
> side to read/write ports. That could help as well to quickly find a
> better
> solution.
>
>>
>> So, is there no way to get a proxy of a component that has the same
>> C+
>> + interface as the remote component? This would allow you to directly
>> access the C++ ports, methods, etc of the component (proxy) directly?
>
> You mean, another one than ControlTaskProxy ? I don't understand this
> question.

Here's what I've got in my mind ....

At the remote end:

class MyTask : public RTT::TaskContext
{
RTT::Method<...> reset_mtd;
RTT::ReadDataPort<...> data_port;
...
}

and remote code that can do

mytask_ptr->reset_mtd()
x = mytask_ptr->data_port.Get()

I ideally want to do exactly that at the local (GUI) end, starting
from a proxy TaskContext.

proxy = Corba:ControlTaskProxy::Create("MyTask")
proxy->reset_mtd()
x = proxy->data_port.Get()

The problem is that proxy is a TaskContext* and not a MyTask*, so it
is a generic object with no idea of the additional methods/data in the
MyTask object at the remote end. So question is, how do I either cast
proxy to a MyTask*, or access the ports and methods of MyTask from the
"TaskContext* proxy".

So far, I'm monkeying with something like

proxy = Corba:ControlTaskProxy::Create("MyTask")
PortInterface* data_port = proxy->ports()->getPort("data");
CorbaPort* r = dynamic_cast(data_port);
AssignableExpression_ptr a = r->getDataChannel();
... and trying to figure out here how to use "a" to do the equivalent
of "proxy->data.Get()" ...

I can't find an example of how to actually use the proxy object to
gain access to the remote's methods/commands/properties/ports/etc. So
far, the above rather ugly code is the only viable path I can find.

Where am I going wrong?

TIA
S

Approaches to using CORBA with Orocos

On Thursday 14 August 2008 15:02:03 S Roderick wrote:
> > You mean, another one than ControlTaskProxy ? I don't understand this
> > question.
>
> Here's what I've got in my mind ....
>
> At the remote end:
>
> class MyTask : public RTT::TaskContext
> {
> RTT::Method<...> reset_mtd;
> RTT::ReadDataPort<...> data_port;
> ...
> }
>
> and remote code that can do
>
> mytask_ptr->reset_mtd()
> x = mytask_ptr->data_port.Get()
>
> I ideally want to do exactly that at the local (GUI) end, starting
> from a proxy TaskContext.
>
> proxy = Corba:ControlTaskProxy::Create("MyTask")
> proxy->reset_mtd()
> x = proxy->data_port.Get()
>
> The problem is that proxy is a TaskContext* and not a MyTask*, so it
> is a generic object with no idea of the additional methods/data in the
> MyTask object at the remote end. So question is, how do I either cast
> proxy to a MyTask*, or access the ports and methods of MyTask from the
> "TaskContext* proxy".

This is how for methods:
// use exactly the same as for plain C++ objects:
Method<...> the_meth = proxy->methods()->getMethod<...>("reset_meth");

// calls reset_meth:
the_meth();

Commands, properties and attributes work like-wise.

This is how for ports:

// create a local port
DataPort the_port;
// get the remote port
PortInterface* remote_port = proxy->ports()->getPort("data_port");

// Connect them. the connection direction (R<->W) is figured out by Orocos
the_port.connectTo( remote_port);

// Send over data to remote side
the_port.Set( 3.0 );

// Read data from remote side
d = the_port.Get();

Simple enough ?

Peter

Approaches to using CORBA with Orocos

On Aug 14, 2008, at 09:14 , Peter Soetens wrote:

> On Thursday 14 August 2008 15:02:03 S Roderick wrote:
>>> You mean, another one than ControlTaskProxy ? I don't understand
>>> this
>>> question.
>>
>> Here's what I've got in my mind ....
>>
>> At the remote end:
>>
>> class MyTask : public RTT::TaskContext
>> {
>> RTT::Method<...> reset_mtd;
>> RTT::ReadDataPort<...> data_port;
>> ...
>> }
>>
>> and remote code that can do
>>
>> mytask_ptr->reset_mtd()
>> x = mytask_ptr->data_port.Get()
>>
>> I ideally want to do exactly that at the local (GUI) end, starting
>> from a proxy TaskContext.
>>
>> proxy = Corba:ControlTaskProxy::Create("MyTask")
>> proxy->reset_mtd()
>> x = proxy->data_port.Get()
>>
>> The problem is that proxy is a TaskContext* and not a MyTask*, so it
>> is a generic object with no idea of the additional methods/data in
>> the
>> MyTask object at the remote end. So question is, how do I either cast
>> proxy to a MyTask*, or access the ports and methods of MyTask from
>> the
>> "TaskContext* proxy".
>
> This is how for methods:
> // use exactly the same as for plain C++ objects:
> Method<...> the_meth = proxy->methods()->getMethod<...>("reset_meth");
>
> // calls reset_meth:
> the_meth();
>
> Commands, properties and attributes work like-wise.
>
> This is how for ports:
>
> // create a local port
> DataPort the_port;
> // get the remote port
> PortInterface* remote_port = proxy->ports()->getPort("data_port");
>
> // Connect them. the connection direction (R<->W) is figured out by
> Orocos
> the_port.connectTo( remote_port);
>
> // Send over data to remote side
> the_port.Set( 3.0 );
>
> // Read data from remote side
> d = the_port.Get();
>
> Simple enough ?

For the methods, definitely. For the ports, not what I was hoping for.
Sigh ... and I do realise how much work has gone into getting this all
to work, so don't take that as a criticism!

Let me digest this a little bit ...
S

Approaches to using CORBA with Orocos

On Wednesday 13 August 2008 23:07:42 snrkiwi wrote:
> We have a working Orocos-based robot control application based, for the
> moment, around the Taskbrowser. It gets the job done, but now we need to
> add more user-interface capability. This brings up the question of how to
> structure communication between the GUI and robot control app. Our existing
> robot control app has a single user-interface component dealing with the
> user.
>
> We see two approaches and wanted to get some feedback from users
> (particularly as we're having trouble with one of the approaches)
>
> 1) Leave the robot control app as is. Create a proxy task in the GUI app
> for the user-interface component that is in the robot control app. This
> runs but doesn't work completely: methods actually work despite getting
> errors ("Failing Corba::Any creation of type void"), however, data ports
> don't work at all (just get the same error).

This approach is what I would choose for as well. For calling simple methods
and commands, you can even use the ScriptingAccess.idl interface and call the
the execute( code ) function. This is easier than going through the native
Method/Data Flow CORBA interface. It can only execute one statement at a time
though.

Peter

Approaches to using CORBA with Orocos

On Aug 14, 2008, at 04:40 , Peter Soetens wrote:

> On Wednesday 13 August 2008 23:07:42 snrkiwi wrote:
>> We have a working Orocos-based robot control application based, for
>> the
>> moment, around the Taskbrowser. It gets the job done, but now we
>> need to
>> add more user-interface capability. This brings up the question of
>> how to
>> structure communication between the GUI and robot control app. Our
>> existing
>> robot control app has a single user-interface component dealing
>> with the
>> user.
>>
>> We see two approaches and wanted to get some feedback from users
>> (particularly as we're having trouble with one of the approaches)
>>
>> 1) Leave the robot control app as is. Create a proxy task in the
>> GUI app
>> for the user-interface component that is in the robot control app.
>> This
>> runs but doesn't work completely: methods actually work despite
>> getting
>> errors ("Failing Corba::Any creation of type void"), however, data
>> ports
>> don't work at all (just get the same error).
>
> This approach is what I would choose for as well. For calling simple
> methods
> and commands, you can even use the ScriptingAccess.idl interface and
> call the
> the execute( code ) function. This is easier than going through the
> native
> Method/Data Flow CORBA interface. It can only execute one statement
> at a time
> though.

Ahhhh ... that makes sense. Using the native method/data-flow calls on
the corba interface is nothing but ugly, unfortunately. :-( The
scripting interface part might make life easier, we'll check it out.
Thanks!

So, is there no way to get a proxy of a component that has the same C+
+ interface as the remote component? This would allow you to directly
access the C++ ports, methods, etc of the component (proxy) directly?

Cheers
S