R: (no subject)

Dear Peter
in order to control a Comau robot
I need to use the RTnet and RTAI libraries for the
real time communication with the robot controller.
The functioning is the following:
1) the external pc performs a blocking receiving on a previously opened socket
2) the robot controller sends a packet to the external pc
3) the pc receives the packet, performs proper calculations of the new command
references and send bck the data to the controller
4) goto point 1.

It is important to highlight that the timing is decided by the robot
controller. In particular, the controller
sent the data to the pc every 2ms, and the pc has to answer after 1.4ms after
having received the packet.
In the case packet is lost, or the pc does not answer back in the proper time,
the robot controller enters in a faulty state (it has to be restarted).

My idea is to implement in a Orocos component the thread which performs
the send and receive functionalities and writes on a "Data Flow Port" the
received information
for the other components. In your opinion, is it possible to realize this
kind of architecture?
Have you better ideas?

Thanks in advance for your help
Diego

>----Messaggio originale----
>Da: peter [..] ...
>Data: 14/01/2013 23.38
>A: "dgerb [..] ..."<dgerb [..] ...>
>Cc: "Orocos Developers"<orocos-dev [..] ...>
>Ogg: Re: Re: [Orocos-Dev] (no subject)
>
>On Mon, Jan 14, 2013 at 12:13 PM, dgerb [..] ... <dgerb [..] ...> wrote:
>> the output of gdb ./main-test
>>
>> Reading symbols from
>> /home/laboratorio/orocos/orocos-toolchain/rtt/build/tests/main-test...done.
>>
>> (gdb) run
>>
>> Starting program:
>> /home/laboratorio/orocos/orocos-toolchain/rtt/build/tests/main-test
>>
>> [Thread debugging using libthread_db enabled]
>>
>>
>> Program terminated with signal SIGKILL, Killed.
>
>Hmm, that's right, you can't debug a kernel oops with GDB.
>
>I can't provide further help in debugging this without having an RTAI
>system of my own.
>
>It's likely that there has been a change in RTAI how it handles the
>LXRT calls, and that we still rely on older data structures.
>
>You could test this with turning the cmake option OS_AGNOSTIC off:
>
>cd rtt/build
>cmake .. -DOS_AGNOSTIC=OFF
>make check
>
>It's worth a try...although I can't predict how well all will build,
>it could be that you have to add extra RTAI include paths here and
>there in order to find the rtai_[...].h header files, especially when
>building components.
>
>Peter
>

(no subject)

On Mar 4, 2013, at 12:33 , dgerb [..] ... wrote:

> Dear Peter
> in order to control a Comau robot
> I need to use the RTnet and RTAI libraries for the
> real time communication with the robot controller.
> The functioning is the following:
> 1) the external pc performs a blocking receiving on a previously opened socket
> 2) the robot controller sends a packet to the external pc
> 3) the pc receives the packet, performs proper calculations of the new command
> references and send bck the data to the controller
> 4) goto point 1.
>
> It is important to highlight that the timing is decided by the robot
> controller. In particular, the controller
> sent the data to the pc every 2ms, and the pc has to answer after 1.4ms after
> having received the packet.
> In the case packet is lost, or the pc does not answer back in the proper time,
> the robot controller enters in a faulty state (it has to be restarted).
>
>
> My idea is to implement in a Orocos component the thread which performs
> the send and receive functionalities and writes on a "Data Flow Port" the
> received information
> for the other components. In your opinion, is it possible to realize this
> kind of architecture?
> Have you better ideas?
>
> Thanks in advance for your help
> Diego

We do something very similar, and here's how we architected it ...

We can use two different industrial controllers to control one of our robots; one version of the controller uses ethernet, the other a PCI-based mesh fabric. In both cases we structure the solution like this:

- A robot telemetry component blocks on a "socket" waiting for data. When data arrives the component does some basic processing, presents the data on ports, signals on an FD (that is part of a signal pipe), and goes back to sleep.

- The Robot coordinator component manages the actual robot state, and is the front end to the user space components. It uses an FDActivity on the other end of the signal pipe, waiting for the telemetry component to signal it. When telemetry arrives, telemetry data is further processed, state changes possibly occur, application data/requests are honored, and commands are sent. We use a signal pipe to decouple a potentially blocked telemetry component form stalling this component. We also use a timeout on the telemetry FDActivity.

- A robot commands component accepts a signal from the Robot coordinator, takes input data on ports, processes it, sends it out, and goes back to sleep. We sometimes use an FDactivity and signal pipe to decouple it from the Robot coordinator, or sometimes it's a more direct connection (it is implementation dependant).

We run this at 500 Hz, and return data to the industrial controller on the order of a couple of hundred microseconds after telemetry arrives.

Of interest, we also have a "simulated" robot coordinator that just internally loops back data. The other two components aren't deployed in this situation. This is great for system testing when a hardware robot isn't actually needed.

HTH
S

(no subject)

great solution! Where can I find a working example of this architecture?

Ruben Smits's picture

(no subject)

Op woensdag 26 juni 2013 schreef (niccolo [dot] tosi [..] ...) het volgende:

> I did some trials:
>
> - Orocos version:
> OROCOS Toolchain version '2.6.0' ( GCC 4.6.3 ) -- GNU/Linux.
>
> - KDL version:
> 1.1.99 (pulled commit 2013-05-03 10:27 by Ruben Smits)
>
> - When I try to load a KDL::Frame property
> &#10;&gt; 0.208 [ ERROR  ][PropertyLoader:configure] Could not compose unknown type&#10;&gt; &#039;KDL.Frame&#039;.&#10;&gt;
>
> - When I try to write a KDL::Frame property to a file using marshalling
> service no frame is written to the file, and I receive the following
> message:
>
> &#10;&gt; 0.213 [ ERROR  ][PropertyLoader::save] Couldn&#039;t write tableFrame to XML&#10;&gt; file&#10;&gt; because the unknown_t type is not supported by the CPF format.&#10;&gt; 0.213 [ ERROR  ][PropertyLoader::save] If your type is a C++ struct or&#10;&gt; sequence, you can register it with a type info object.&#10;&gt; 0.213 [ ERROR  ][PropertyLoader::save] We only support these primitive&#10;&gt; types:&#10;&gt; boolean|char|double|float|long|octet|string|ulong.&#10;&gt;
>
>
If you want to use the marshallers on KDL types you will need to import the
kdl_typekit which is part of the rtt_geometry repository, located at
http://git.mech.kuleuven.be/robotics/rtt_geometry.git

Ruben

>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ... <javascript:;>
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

Ruben Smits's picture

(No subject)

Hi Diego,

On Thu, Jun 26, 2014 at 6:36 PM, <dgerb [..] ...> wrote:

> Hi,
> I am using orocos toolchain 2.6 under gnulinux. I am using also the
> import
> function from deployer to import an installed component package.
> The package is correctly imported and the relative component loaded (by
> loadComponent).
> Then, if I modify, re-build and install the component without restart
> the
> deployer, a new import simply has no effect: the old component is loaded.
>

What you are trying here is highly experimental and AFAIK untested. I don't
even know if it is really supported.

Can you run your deployment with ORO_LOGLEVEL set to Debug (6), and post
the output, maybe we can see some stuff in the Debug output that would
clarify what's going on.

Have you tried the reloadLibrary function of the deployer (I'm looking at
toolchain-2.7/master)?:

reloadLibrary( string const& FilePath ) : bool
Reload a new component library into memory.
FilePath : The absolute file name of the to be reloaded library.
Warning: this is a low-level function only to be used during
development/testing.

Ruben

I need to quit and restart the deployer to have the modifications be
> effective.
> This problem seems to me related to bug:
>
> http://www.orocos.org/forum/rtt/rtt-dev/bug-1001-new-deployer-claims-ove...
> relative to toolchain 2.5.
> However, file ComponentLoader.cpp file is correct in my case.
>
> Thanks in advance.
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

Ruben Smits's picture

(no subject)

Hi MDC,

On Wed, Jul 17, 2013 at 3:59 PM, <mirkodaniele [dot] comparetti [..] ...> wrote:

> Dear all,
> I'm facing a problem with the OROCOS operations. Here is what I'm doing in
> the component called componentNew
>
> this-&gt;task_name = &quot;componentPeer&quot;;&#10;&gt; this-&gt;task_ptr = this-&gt;getPeer(this-&gt;task_name);&#10;&gt;&#10;&gt; if (!this-&gt;task_ptr) {&#10;&gt;         return false;&#10;&gt; }&#10;&gt; if (this-&gt;task_ptr-&gt;isActive()) {&#10;&gt;         this-&gt;task_oper = this-&gt;task_ptr-&gt;getOperation(&quot;operationName&quot;);&#10;&gt; }&#10;&gt;
> where in the hpp file I defined
> std::string task_name;&#10;&gt; TaskContext* task_ptr;&#10;&gt; RTT::OperationCaller task_oper;&#10;&gt;
>
>
As far as I can see you forgot to provide the signature for the
OperationCaller:

(Taken from the manual at the link that you provided): Section 3.4.1
...
Next we move on to methods with arguments and return values by using the
getName and changeParameter operations:

// hold return value of changeParameter:
double oldvalue;
OperationCaller<double(double)> mychange =
a_task_ptr->getOperation("changeParameter"); // double
changeParameter(double)

...

The code compiles but I verified that the task_ptr is NULL. I followed the
> instruction in from
> [
> http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-compo...
> 3.4.1], but it seems that I'm I suppose that I'm trying to get the
> reference
> of the peer in the wrong way. In my xml schema I'm importing and loading
> the
> component componentPeer and the current component
> componentNew
>
> Do I need to add something in the xml deployment schema? Or is there any
> other solution?
>
>
You have to make sure both components are connected as explained in
http://people.mech.kuleuven.be/~orocos/pub/stable/documentation/ocl/v2.x/doc-xml/orocos-deployment.html#idp33098864(Section
2.4.6)

2.4.6. Setting up peer-to-peer relations

The last section of the Reporter component lists its peers.

<struct name="Peers" type="PropertyBag">
<simple type="string"><value>Controller</value></simple>
</struct>

The Reporter has one peer, the Controller, which allows the Reporter
component to scan and use the interface of the Controller component. For
example, it will discover which ports Controller exposes and be able to
create connections to them, without the need of a supervisor to do so.

The Controller component has the Plant as peer, which means it can query
and control it. For example, use its services, start and stop it etc.

> Thank you for your help,
>
>
Ruben

> Best regards,
>
> Mirko
>
>

mastermirko wrote:
Dear peter,
> Ok, I'll use quote also when I'm adding new information to the post.
>
> I was looking to the wrong manual but later on I realized which one is the
> correct one to use (at least this is what I think), explained
> [
> http://www.orocos.org/forum/orocos/orocos-users/using-operations-un-comp...
> here] maybe due to the fact that I'm using std::vectors and std::deque as
> in
> and out parameter of the operation.
>
> Thank you for your help,
>
> Best regards,
>
> MDC
>
>
peter wrote:
Dear Mirko,
>
> On Fri, Jan 4, 2013 at 4:04 PM, wrote:
>
> > I just did a git pull in [..]/ros_workspace/orocos/orocos_toolchain but
> > still
> > the file rtt/Method.hpp is missing in my installation. Where can I get
> it?
> >
>
> When writing on the forum, could you please use the 'quote' link instead ?
>
> rtt/Method.hpp is an Orocos 1.x class, while rtt/Operation.hpp replaces it
> in Orocos 2.x.
>
> Are you reading the correct manuals ? See:
> http://www.orocos.org/wiki/main-page/toolchain/toolchain-reference-manuals
>
> Peter

> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

(no subject)

The "getPeer(this->task_name)" will only returns something if your current
component has a peer registered with the expected name.

If you use the deployer you may check the list of registered peers doing ls
on your current component.

You probably need to do something like
"addPeer("ComponentNew","ComponentPeer")" in your deployer code (this is
pseudo code, check the syntax, espacially the order) or :

a_task.addPeer( &c_task );

If you have hard coded the deployment.

cf:
http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-compo...

2013/7/17 <mirkodaniele [dot] comparetti [..] ...>

> Dear all,
> I'm facing a problem with the OROCOS operations. Here is what I'm doing in
> the component called componentNew
>
> this-&gt;task_name = &quot;componentPeer&quot;;&#10;&gt; this-&gt;task_ptr = this-&gt;getPeer(this-&gt;task_name);&#10;&gt;&#10;&gt; if (!this-&gt;task_ptr) {&#10;&gt;         return false;&#10;&gt; }&#10;&gt; if (this-&gt;task_ptr-&gt;isActive()) {&#10;&gt;         this-&gt;task_oper = this-&gt;task_ptr-&gt;getOperation(&quot;operationName&quot;);&#10;&gt; }&#10;&gt;
> where in the hpp file I defined
> std::string task_name;&#10;&gt; TaskContext* task_ptr;&#10;&gt; RTT::OperationCaller task_oper;&#10;&gt;
>
> The code compiles but I verified that the task_ptr is NULL. I followed the
> instruction in from
> [
> http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-compo...
> 3.4.1], but it seems that I'm I suppose that I'm trying to get the
> reference
> of the peer in the wrong way. In my xml schema I'm importing and loading
> the
> component componentPeer and the current component
> componentNew
>
> Do I need to add something in the xml deployment schema? Or is there any
> other solution?
>
> Thank you for your help,
>
> Best regards,
>
> Mirko
>
>

mastermirko wrote:
Dear peter,
> Ok, I'll use quote also when I'm adding new information to the post.
>
> I was looking to the wrong manual but later on I realized which one is the
> correct one to use (at least this is what I think), explained
> [
> http://www.orocos.org/forum/orocos/orocos-users/using-operations-un-comp...
> here] maybe due to the fact that I'm using std::vectors and std::deque as
> in
> and out parameter of the operation.
>
> Thank you for your help,
>
> Best regards,
>
> MDC
>
>
peter wrote:
Dear Mirko,
>
> On Fri, Jan 4, 2013 at 4:04 PM, wrote:
>
> > I just did a git pull in [..]/ros_workspace/orocos/orocos_toolchain but
> > still
> > the file rtt/Method.hpp is missing in my installation. Where can I get
> it?
> >
>
> When writing on the forum, could you please use the 'quote' link instead ?
>
> rtt/Method.hpp is an Orocos 1.x class, while rtt/Operation.hpp replaces it
> in Orocos 2.x.
>
> Are you reading the correct manuals ? See:
> http://www.orocos.org/wiki/main-page/toolchain/toolchain-reference-manuals
>
> Peter

> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

(no subject)

 Regards,
Darshan Doria
Embedded System
GCET (Anand)

(no subject)

Hello Orocos Folks,

We are compiling our components with clang++. In the components for
which we (Milan) have written nice typekits, we are getting the
following compiler warning:

14) [6.395s] components/main/LEDTracker/types: clang++ -Wall -O3
-march=native -mtune=native -fPIC -fno-strict-l1
-I../../../../components/carousel2 `pkg-config --cflags
orocos-rtt-gnulinux orocos-ocl-gnulinux` -c LEDTracke
LEDTrackerTypekit.cpp:25:1: warning: 'getRTTPluginName' has C-linkage
specified, but returns user-defined type '
ORO_TYPEKIT_PLUGIN( LEDTrackerTypekit )
^
/home/awagner/planepower/extern/orocos/install/include/rtt/types/TypekitPlugin.hpp:138:32:
note: expanded from m
RTT_EXPORT std::string getRTTPluginName(); \
^
LEDTrackerTypekit.cpp:25:1: warning: 'getRTTTargetName' has C-linkage
specified, but returns user-defined type '
/home/awagner/planepower/extern/orocos/install/include/rtt/types/TypekitPlugin.hpp:143:32:
note: expanded from m
RTT_EXPORT std::string getRTTTargetName(); \

This error comes from this macro definition in Orocos:

#define ORO_TYPEKIT_PLUGIN ( TYPEKIT
)

namespace RTT { class TaskContext; } \
extern "C" { \
RTT_EXPORT bool loadRTTPlugin(RTT::TaskContext* tc); \
bool loadRTTPlugin(RTT::TaskContext* tc) { \
if (tc == 0) { \
RTT::types::TypekitRepository::Import( new TYPEKIT() ); \
return true; \
} \
return false; \
} \
RTT_EXPORT std::string getRTTPluginName(); \
std::string getRTTPluginName() { \
TYPEKIT tk; \
return tk.getName(); \
} \
RTT_EXPORT std::string getRTTTargetName(); \
std::string getRTTTargetName() { \
return OROCOS_TARGET_NAME; \
} \
}

As you can see, several functions with C linkage are indeed returning
C++ strings. I suppose this is benign? I assume this stuff is never
compiled in a C compiler, and the extern "C" is just to turn off name
mangling for some reason, but perhaps there's another compiler
directive that can achieve the same thing without generating warnings?

Cheers,
Andrew

(no subject)

On Oct 15, 2013, at 12:09 , Andrew Wagner <andrew [dot] wagner [..] ...> wrote:

> Hello Orocos Folks,
>
> We are compiling our components with clang++. In the components for
> which we (Milan) have written nice typekits, we are getting the
> following compiler warning:
>
> 14) [6.395s] components/main/LEDTracker/types: clang++ -Wall -O3
> -march=native -mtune=native -fPIC -fno-strict-l1
> -I../../../../components/carousel2 `pkg-config --cflags
> orocos-rtt-gnulinux orocos-ocl-gnulinux` -c LEDTracke
> LEDTrackerTypekit.cpp:25:1: warning: 'getRTTPluginName' has C-linkage
> specified, but returns user-defined type '
> ORO_TYPEKIT_PLUGIN( LEDTrackerTypekit )
> ^
> /home/awagner/planepower/extern/orocos/install/include/rtt/types/TypekitPlugin.hpp:138:32:
> note: expanded from m
> RTT_EXPORT std::string getRTTPluginName(); \
> ^
> LEDTrackerTypekit.cpp:25:1: warning: 'getRTTTargetName' has C-linkage
> specified, but returns user-defined type '
> /home/awagner/planepower/extern/orocos/install/include/rtt/types/TypekitPlugin.hpp:143:32:
> note: expanded from m
> RTT_EXPORT std::string getRTTTargetName(); \
>
> This error comes from this macro definition in Orocos:
>
> #define ORO_TYPEKIT_PLUGIN ( TYPEKIT
> )
>
> namespace RTT { class TaskContext; } \
> extern "C" { \
> RTT_EXPORT bool loadRTTPlugin(RTT::TaskContext* tc); \
> bool loadRTTPlugin(RTT::TaskContext* tc) { \
> if (tc == 0) { \
> RTT::types::TypekitRepository::Import( new TYPEKIT() ); \
> return true; \
> } \
> return false; \
> } \
> RTT_EXPORT std::string getRTTPluginName(); \
> std::string getRTTPluginName() { \
> TYPEKIT tk; \
> return tk.getName(); \
> } \
> RTT_EXPORT std::string getRTTTargetName(); \
> std::string getRTTTargetName() { \
> return OROCOS_TARGET_NAME; \
> } \
> }
>
> As you can see, several functions with C linkage are indeed returning
> C++ strings. I suppose this is benign? I assume this stuff is never
> compiled in a C compiler, and the extern "C" is just to turn off name
> mangling for some reason, but perhaps there's another compiler
> directive that can achieve the same thing without generating warnings?
>
> Cheers,
> Andrew