Connect two ports with Deployer

Submitted by ookki on Wed, 2010-11-17 18:53

Hello,

I have a ComponentA with a InputPort "manualCommandInput" and I have a ComponentB with the OutputPort "allSpaceNav".

I start the ComponentA with a deployer-corba. In the .xml of ComponentA I add these lines:

       12AUVManualCommand34

I got these errors when I start the deployer-corba for the ComponentA:

[ ERROR ][DeploymentComponent::configureComponents] Need a transport for creating streams.

[ Warning][DeploymentComponent::configureComponents] Creating stream with name AUVManualCommand with Port manualCommandInput from Controller failed.

For the ComponentB, I had these line to the .xml :

    78AUVManualCommand910

I got the same errors when I start the deployer-corba for the ComponentB. (The ComponentA is always running in another deployer)

Connect two ports with

Submitted by ookki on Thu, 2010-11-18 13:48.

I'm communicating a vector of double.

I had the lines into the ComponentA, I remove the ports line in the ComponentB and it's working if I start the ComponentA first.

Is there a way to connect two ports in two different deployer without wondering about the order of initialization?

Thanks

Connect two ports with

Submitted by ookki on Thu, 2010-11-18 13:20.

I'm communicating a vector of double.

I add the lines into the ComponentA, I remove the ports line in the ComponentB and it's working if I start the ComponentA first.

Is there a way to connect two ports in two different deployer without wondering about the order of initialization?

Thanks

Connect two ports with

Submitted by peter on Thu, 2010-11-18 16:28.

On Thu, Nov 18, 2010 at 2:14 PM, <ookki [..] ...> wrote:
> I'm communicating a vector of double.
>
> I had the lines into the ComponentA, I remove the ports line in the ComponentB and it's working if I start the ComponentA first.
>
> Is there a way to connect two ports in two different deployer without wondering about the order of initialization?

Only by doing it in a third, which is started after the first two. See
the new wiki page for an example:
http://orocos.org/wiki/orocos/toolchain/getting-started/toolchain-tutori...

The same can be done in scripting too, launching a supervisor that
runs a script that does all the setup using the deployment operations.

Peter

Thanks for your help.I try

Submitted by ookki on Mon, 2010-11-29 21:32.

Thanks for your help.

I try the tutorial with 3 deployers. One deployer for the ComponentA with inPort, One deployer for ComponentB with outPort and One deployer to connecte the inPort with the outPort.

I start the ComponentA, the ComponentB, and the deployer for the connection, I got :

[ Warning][ComponentA.CorbaDispatch] Lowering scheduler type to SCHED_OTHER for non-privileged users..
Segmentation fault

I use toolchain 2.1.1

Thanks!!

Thanks for your help.I try

Submitted by ookki on Mon, 2010-11-29 21:45.

There is the back traces.

Thanks!!

Thanks for your help.I

Submitted by peter on Tue, 2010-11-30 11:56.

On Monday 29 November 2010 22:45:03 ookki [..] ... wrote:
> There is the back traces.
>
> Thanks!!

Thanks for all the input and the test-case. I have pushed the fix to the
toolchain-2.1 branch on gitorious, or you can apply the patch in attachment to
your rtt sources (patch -p1 < 0001-corba-...)

You only need to recompile&install RTT to have this fix, your components and
OCL can remain as-is. I tested it with your testcase and now it works (I used
TAO).

Let us know if you have any (other) problems.

Peter

Thanks for your help.I

Submitted by phamelin on Tue, 2010-11-30 12:32.

Thank you very much Peter for this quick fix!

2010/11/30 Peter Soetens <peter [..] ...>

> On Monday 29 November 2010 22:45:03 ookki [..] ... wrote:
> > There is the back traces.
> >
> > Thanks!!
>
> Thanks for all the input and the test-case. I have pushed the fix to the
> toolchain-2.1 branch on gitorious, or you can apply the patch in attachment
> to
> your rtt sources (patch -p1 < 0001-corba-...)
>
> You only need to recompile&install RTT to have this fix, your components
> and
> OCL can remain as-is. I tested it with your testcase and now it works (I
> used
> TAO).
>
> Let us know if you have any (other) problems.
>
> Peter
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>

Thanks for your help.I

Submitted by phamelin on Mon, 2010-11-29 22:04.

I'm also getting the same problem. I can't connect two external components
through CORBA. Here is my backtrace:

#0 RTT::base::ChannelElementBase::getOutputEndPoint (this=0x15) at
/home/hamelinp/orocos-toolchain-2.1.0/rtt/rtt/base/ChannelInterface.cpp:96
#1 0x00284710 in RTT::base::ChannelElementBase::getOutputEndPoint
(this=0x15) at
/home/hamelinp/orocos-toolchain-2.1.0/rtt/rtt/base/ChannelInterface.cpp:96
#2 0x00284710 in RTT::base::ChannelElementBase::getOutputEndPoint
(this=0x15) at
/home/hamelinp/orocos-toolchain-2.1.0/rtt/rtt/base/ChannelInterface.cpp:96
#3 0x003c93f6 in RTT::corba::CDataFlowInterface_i::buildChannelOutput
(this=0x809ac70, port_name=0xb6601c68 "inPort", corba_policy=...) at
/home/hamelinp/orocos-toolchain-2.1.0/rtt/rtt/transports/corba/DataFlowI.cpp:386
#4 0x003ed5c0 in
POA_RTT::corba::buildChannelOutput_CDataFlowInterface::execute() () from
/usr/local/lib/liborocos-rtt-corba-gnulinux.so.2.1
#5 0x007ccd5b in TAO::Upcall_Wrapper::upcall(TAO_ServerRequest&,
TAO::Argument* const*, unsigned int, TAO::Upcall_Command&, void*,
CORBA::TypeCode* const*, unsigned int) () from /usr/lib/
libTAO_PortableServer-1.6.3.so
#6 0x003e96c2 in
POA_RTT::corba::CDataFlowInterface::buildChannelOutput_skel
(server_request=..., servant_upcall=0xb6fddf78, servant=0x809ac70) at
/home/hamelinp/orocos-toolchain-2.1.0/rtt/build/rtt/transports/corba/DataFlowS.cpp:2708
#7 0x007c9b54 in
TAO_ServantBase::synchronous_upcall_dispatch(TAO_ServerRequest&, void*,
void*) () from /usr/lib/libTAO_PortableServer-1.6.3.so
#8 0x003e655b in POA_RTT::corba::CDataFlowInterface::_dispatch
(this=0x809ac70, req=..., servant_upcall=0xb6fddf78) at
/home/hamelinp/orocos-toolchain-2.1.0/rtt/build/rtt/transports/corba/DataFlowS.cpp:3785
#9 0x00795f0f in TAO_Object_Adapter::do_dispatch(TAO_ServerRequest&,
TAO::Portable_Server::Servant_Upcall&) () from /usr/lib/
libTAO_PortableServer-1.6.3.so
#10 0x0079693a in TAO_Object_Adapter::dispatch_servant(TAO::ObjectKey
const&, TAO_ServerRequest&, TAO_Pseudo_Out_T<CORBA::Object>) () from
/usr/lib/libTAO_PortableServer-1.6.3.so
#11 0x00797728 in TAO_Object_Adapter::dispatch(TAO::ObjectKey&,
TAO_ServerRequest&, TAO_Pseudo_Out_T<CORBA::Object>) () from /usr/lib/
libTAO_PortableServer-1.6.3.so
#12 0x0065d7e9 in TAO_Adapter_Registry::dispatch(TAO::ObjectKey&,
TAO_ServerRequest&, TAO_Pseudo_Out_T<CORBA::Object>) () from /usr/lib/
libTAO-1.6.3.so
#13 0x006bf51f in TAO_Request_Dispatcher::dispatch(TAO_ORB_Core*,
TAO_ServerRequest&, TAO_Pseudo_Out_T<CORBA::Object>) () from /usr/lib/
libTAO-1.6.3.so
#14 0x0066f4c4 in TAO_GIOP_Message_Base::process_request(TAO_Transport*,
TAO_InputCDR&, TAO_OutputCDR&, TAO_GIOP_Message_Generator_Parser*) () from
/usr/lib/libTAO-1.6.3.so
#15 0x0066ff09 in
TAO_GIOP_Message_Base::process_request_message(TAO_Transport*,
TAO_Queued_Data*) () from /usr/lib/libTAO-1.6.3.so
#16 0x006e0255 in TAO_Transport::process_parsed_messages(TAO_Queued_Data*,
TAO_Resume_Handle&) () from /usr/lib/libTAO-1.6.3.so
#17 0x006e16bc in TAO_Transport::handle_input_parse_data(TAO_Resume_Handle&,
ACE_Time_Value*) () from /usr/lib/libTAO-1.6.3.so
#18 0x006e18ab in TAO_Transport::handle_input(TAO_Resume_Handle&,
ACE_Time_Value*) () from /usr/lib/libTAO-1.6.3.so
#19 0x00666155 in TAO_Connection_Handler::handle_input_internal(int,
ACE_Event_Handler*) () from /usr/lib/libTAO-1.6.3.so
#20 0x00666316 in TAO_Connection_Handler::handle_input_eh(int,
ACE_Event_Handler*) () from /usr/lib/libTAO-1.6.3.so
#21 0x0067e42b in TAO_IIOP_Connection_Handler::handle_input(int) () from
/usr/lib/libTAO-1.6.3.so
#22 0x005acc35 in
ACE_TP_Reactor::dispatch_socket_event(ACE_EH_Dispatch_Info&) () from
/usr/lib/libACE-5.6.3.so
#23 0x005adc74 in ACE_TP_Reactor::handle_socket_events(int&,
ACE_TP_Token_Guard&) () from /usr/lib/libACE-5.6.3.so
#24 0x005add98 in ACE_TP_Reactor::dispatch_i(ACE_Time_Value*,
ACE_TP_Token_Guard&) () from /usr/lib/libACE-5.6.3.so
#25 0x005ade66 in ACE_TP_Reactor::handle_events(ACE_Time_Value*) () from
/usr/lib/libACE-5.6.3.so
#26 0x006a1b74 in TAO_ORB_Core::run(ACE_Time_Value*, int) () from /usr/lib/
libTAO-1.6.3.so
#27 0x0069d2bc in CORBA::ORB::run(ACE_Time_Value*) () from /usr/lib/
libTAO-1.6.3.so
#28 0x0069d325 in CORBA::ORB::run() () from /usr/lib/libTAO-1.6.3.so
#29 0x003a3ab0 in RTT::corba::TaskContextServer::RunOrb () at
/home/hamelinp/orocos-toolchain-2.1.0/rtt/rtt/transports/corba/TaskContextServer.cpp:299
#30 0x003a97c8 in RTT::corba::OrbRunner::loop (this=0x8094868) at
/home/hamelinp/orocos-toolchain-2.1.0/rtt/rtt/transports/corba/TaskContextServer.cpp:320
#31 0x0027c18b in RTT::os::thread_function (t=0x8094870) at
/home/hamelinp/orocos-toolchain-2.1.0/rtt/rtt/os/Thread.cpp:182
#32 0x00b8296e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#33 0x011f3a4e in clone () from /lib/tls/i686/cmov/libc.so.6

What is strange is that the "output" pointer equals 0x15 ? This looks like a
non-initialized poniter.

Philippe

2010/11/29 <ookki [..] ...>

> There is the back traces.
>
> Thanks!!
>
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>

Thanks for your help.I

Submitted by peter on Tue, 2010-11-30 09:16.

On Monday 29 November 2010 23:03:30 Philippe Hamelin wrote:
> I'm also getting the same problem. I can't connect two external components
> through CORBA. Here is my backtrace:

...

I'll try to fix this today. I'll keep you posted.

Peter

Thanks for your help.I try

Submitted by ookki on Mon, 2010-11-29 21:27.

Thanks for your help.

I try the tutorial with 3 deployers. One deployer for the ComponentA with inPort, One deployer for ComponentB with outPort and One deployer to connecte the inPort with the outPort.

I start the ComponentA, the ComponentB, and the deployer for the connection, I got :

[ Warning][ComponentA.CorbaDispatch] Lowering scheduler type to SCHED_OTHER for non-privileged users.. Segmentation fault

I use toolchain 2.1.1

Thanks!!

Thanks for your help.I

Submitted by ookki on Mon, 2010-11-29 21:48.

There is the back traces.

Thanks!!

Connect two ports with Deployer

Submitted by peter on Wed, 2010-11-17 22:00.

On Wednesday 17 November 2010 19:53:14 ookki [..] ... wrote:
> Hello,
>
> I have a ComponentA with a InputPort "manualCommandInput" and I have a
> ComponentB with the OutputPort "allSpaceNav".
>
> I start the ComponentA with a deployer-corba. In the .xml of ComponentA I
> add these lines:
>
> <struct name="Ports" type="PropertyBag">
> <simple name="manualCommandInput"
> type="string"><value>AUVManualCommand<value><simple> <struct>
>
> I got these errors when I start the deployer-corba for the ComponentA:
>
> [ ERROR ][DeploymentComponent::configureComponents] Need a transport for
> creating streams.
>
> [ Warning][DeploymentComponent::configureComponents] Creating stream with
> name AUVManualCommand with Port manualCommandInput from Controller failed.
>
>
>
> For the ComponentB, I had these line to the .xml :
>
> <struct name="Ports" type="PropertyBag">
> <simple name="allSpaceNav"
> type="string"><value>AUVManualCommand<value><simple> <struct>
>
> I got the same errors when I start the deployer-corba for the ComponentB.
> (The ComponentA is always running in another deployer)

Which struct are you communicating through the manualCommandInput ?

I admit this is a counterintuitive, but here's what you need to do:

In the file for ComponentA, add this struct as well:

<struct name="ComponentB" type="CORBA">
<struct name="Ports" type="PropertyBag">
<simple name="allSpaceNav" type="string">
<value>AUVManualCommand<value><simple>
<struct>
<struct>

In the file for ComponentB, you can remove the 'Ports' <struct>.

If you want to set-up stream-like connections (as the error message suggests)
you'll have to use the ROS or mqueue protocols (not CORBA). In order to setup
such connections, your original files can be used, but you need to add on top
of *both* files:

<simple name="transport" type="short"><value>3<value><simple>
<simple name="name_id" type="string"><value>/topicname<value><simple>
<struct>

I must admit that I had to look it up myself and it's lacking documentation.

I'll start adding this in a wiki page.

Peter

Connect two ports with

Submitted by ookki on Wed, 2010-11-17 19:36.

I forgot to mention that when I use the deployer to connect the port's component it's work.

connectTwoPorts("ComoponentA", "manualCommandInput", "ComponentB", "allSpaceNav")

Connect two ports with

Submitted by ookki on Wed, 2010-11-17 19:32.

I forgot to mention that when I use the deployer to connect the port's component it's work.

connectTwoPorts("ComoponentA", "manualCommandInput", "ComponentB", "allSpaceNav")

Connect two ports with Deployer

Submitted by ookki on Wed, 2010-11-17 18:56.

Hello,

I have a ComponentA with a InputPort "manualCommandInput" and I have a ComponentB with the OutputPort "allSpaceNav".

I start the ComponentA with a deployer-corba. In the .xml of ComponentA I add these lines:

<struct name="Ports" type="PropertyBag">
<simple name="manualCommandInput" type="string"><value>AUVManualCommand<value><simple>
<struct>

I got these errors when I start the deployer-corba for the ComponentA:

[ ERROR ][DeploymentComponent::configureComponents] Need a transport for creating streams.

[ Warning][DeploymentComponent::configureComponents] Creating stream with name AUVManualCommand with Port manualCommandInput from Controller failed.

For the ComponentB, I had these line to the .xml :

<struct name="Ports" type="PropertyBag">
<simple name="allSpaceNav" type="string"><value>AUVManualCommand<value><simple>
<struct>

I got the same errors when I start the deployer-corba for the ComponentB. (The ComponentA is always running in another deployer)