Timing of different components that communicate

Submitted by b1willaert on Wed, 2010-12-01 00:40

Orocos-users

Hi,

I have the following two components communicating with each other:
- 'daq': speaks with daq-card (using Comedi) --> two orocos ports: output-port for encoders and input_port for force command.
- 'control' : calculates the desired force commands based on current position (using Eigen) --> two orocos ports: input_port for encoders and output_port for force commands.

I want the following sequence of events:
'daq' reads encoders from daq-card and sends this to 'control'
'control' reads encoder signals, calculates force commands and sends these to 'daq'
'daq' reads force commands and sends this to daq-card

Currently I am using "normal" ports and when I check the timing, it seems that the sequence of events is not always the desired one: e.g. updatehook 'control' is finished before updatehook 'daq' even started.

The Orocos Component builder's manual explains how to use an EventPort instead of a "normal" port to trigger the updatehook of a component based on receiving data at an input_port. But how can a loop be created as in my desired sequence of events? I.e. updatehook 'daq' is partially executed, after this updatehook 'control' is fully executed, and finally the remaing part of 'daq' is executed.

Thanks in advance,

Bert

Ps. The orocos search engine doesn't seem to react on any search term...

Timing of different components that communicate

Submitted by peter on Wed, 2010-12-01 09:08.

On Wednesday 01 December 2010 01:40:30 bert [dot] willaert [..] ... wrote:
> Hi,
>
> I have the following two components communicating with each other:

> - 'daq': speaks with daq-card (using Comedi) --> two orocos ports:
> output-port for encoders and input_port for force command.
-
> 'control' : calculates the desired force commands based on current
> position (using Eigen) --> two orocos ports: input_port for encoders and
> output_port for force commands.

>
> I want the following sequence of events:

> 'daq' reads encoders from daq-card and sends this to 'control'

> 'control' reads encoder signals, calculates force commands and sends these
> to 'daq'
'daq' reads force commands and sends this to daq-card

>
> Currently I am using "normal" ports and when I check the timing, it seems
> that the sequence of events is not always the desired one: e.g. updatehook
> 'control' is finished before updatehook 'daq' even started.

>
> The Orocos Component builder's manual explains how to use an EventPort
> instead of a "normal" port to trigger the updatehook of a component based
> on receiving data at an input_port. But how can a loop be created as in my
> desired sequence of events? I.e. updatehook 'daq' is partially executed,
> after this updatehook 'control' is fully executed, and finally the remaing
> part of 'daq' is executed.

This is rather easy. The only thing you need to take into account is the
return value of your read(). For example, when daq's update hook reads the
force command and the read returns 'NewData' you know a new sample arrived
and can pass it on to comedi. If it returns 'OldData'. You just return from
updateHook.

In pseudo code:

   // in daq:
  void updateHook() {
    comedi_read(data);
    outport.write(data);
    if ( inport.read( cfdata ) == NewData ) {
          comedi_write( cfdata )
    }
 }

You can make the controller component event driven and the daq component
periodic (or the other way around). The 'event driven' component must add his
port with 'addEventPort'. In your simple case, even both components could
register their input ports as event ports and you can decide during deployment
which one gets a periodic thread and which is reactive.

>
> Thanks in advance,
>
> Bert
>
> Ps. The orocos search engine doesn't seem to react on any search term...

We had again a crashed MySQL table. Our provider's machine must have some
issues.

Peter

Timing of different components that communicate

Submitted by b1willaert on Wed, 2010-12-01 23:28.

peter wrote:

In pseudo code:

   // in daq:
  void updateHook() {
    comedi_read(data);
    outport.write(data);
    if ( inport.read( cfdata ) == NewData ) {
          comedi_write( cfdata )
    }
 }

-----------------------------------------

Hmm, what approach is most easy yours or Tinne's? It seems to me that yours needs only very little adaptation, but I don't get the triggering working yet. So to make the 'controller' gets executed at the moment 'daq' sends new encoder signals, I did only the following two things:
1) I made the encoder input-port of 'control' an EventPort:

this->ports()->addEventPorts(Enc_inport);

2) In the XML file I have now:

  <struct name="control" type="Example::control">
 
    <struct name="Activity" type="NonPeriodicActivity">
      <!--simple name="Period" type="double"><value>0.0002</value></simple-->
      <simple name="Priority" type="short"><value>0</value></simple>
      <simple name="Scheduler" type="string"><value>ORO_SCHED_RT</value></simple>
    </struct>
 
    <simple name="AutoConf" type="boolean"><value>1</value></simple>
    <simple name="AutoStart" type="boolean"><value>1</value></simple>
    <simple name="AutoConnect" type="boolean"><value>1</value></simple>
 
    <struct name="Ports" type="PropertyBag">
      <simple name="control_Torque_port" type="string"><value>Comm_Torque</value></simple>
      <simple name="control_Enc_port" type="string"><value>Comm_Enc</value></simple>
    </struct>
 
    <struct name="Peers" type="PropertyBag">
      <simple type="string"><value>daq</value></simple>
    </struct>
 
 
  </struct>

However, the updateHook of 'control' never gets executed... Should this work?
Note that I have 'daq' as a peer of 'control' and 'control' as a peer of 'daq' in the XML file.

Any advice? thanks!

Bert

>
> Thanks in advance,
>
> Bert
>
> Ps. The orocos search engine doesn't seem to react on any search term...

We had again a crashed MySQL table. Our provider's machine must have some
issues.

Peter

Re: Timing of different components that communicate

Submitted by b1willaert on Wed, 2010-12-01 23:26.

peter wrote:

On Wednesday 01 December 2010 01:40:30 bert [dot] willaert [..] ... wrote: > Hi, > > I have the following two components communicating with each other:
> - 'daq': speaks with daq-card (using Comedi) --> two orocos ports: > output-port for encoders and input_port for force command.
- > 'control' : calculates the desired force commands based on current > position (using Eigen) --> two orocos ports: input_port for encoders and > output_port for force commands.
> > I want the following sequence of events:
> 'daq' reads encoders from daq-card and sends this to 'control'
> 'control' reads encoder signals, calculates force commands and sends these > to 'daq'
'daq' reads force commands and sends this to daq-card
> > Currently I am using "normal" ports and when I check the timing, it seems > that the sequence of events is not always the desired one: e.g. updatehook > 'control' is finished before updatehook 'daq' even started.
> > The Orocos Component builder's manual explains how to use an EventPort > instead of a "normal" port to trigger the updatehook of a component based > on receiving data at an input_port. But how can a loop be created as in my > desired sequence of events? I.e. updatehook 'daq' is partially executed, > after this updatehook 'control' is fully executed, and finally the remaing > part of 'daq' is executed.

This is rather easy. The only thing you need to take into account is the return value of your read(). For example, when daq's update hook reads the force command and the read returns 'NewData' you know a new sample arrived and can pass it on to comedi. If it returns 'OldData'. You just return from updateHook.

In pseudo code:

   // in daq:
  void updateHook() {
    comedi_read(data);
    outport.write(data);
    if ( inport.read( cfdata ) == NewData ) {
          comedi_write( cfdata )
    }
 }

You can make the controller component event driven and the daq component periodic (or the other way around). The 'event driven' component must add his port with 'addEventPort'. In your simple case, even both components could register their input ports as event ports and you can decide during deployment which one gets a periodic thread and which is reactive.

-----------------------------------------
Hmm, what approach is most easy yours or Tinne's? It seems to me that yours needs only very little adaptation, but I don't get the triggering working yet. So to make the 'controller' gets executed at the moment 'daq' sends new encoder signals, I did only the following two things: 1) I made the encoder input-port of 'control' an EventPort:

this->ports()->addEventPorts(Enc_inport);

2) In the XML file I have now:

  <struct name="control" type="Example::control">
 
    <struct name="Activity" type="NonPeriodicActivity">
      <!--simple name="Period" type="double"><value>0.0002</value></simple-->
      <simple name="Priority" type="short"><value>0</value></simple>
      <simple name="Scheduler" type="string"><value>ORO_SCHED_RT</value></simple>
    </struct>
 
    <simple name="AutoConf" type="boolean"><value>1</value></simple>
    <simple name="AutoStart" type="boolean"><value>1</value></simple>
    <simple name="AutoConnect" type="boolean"><value>1</value></simple>
 
    <struct name="Ports" type="PropertyBag">
      <simple name="control_Torque_port" type="string"><value>Comm_Torque</value></simple>
      <simple name="control_Enc_port" type="string"><value>Comm_Enc</value></simple>
    </struct>
 
    <struct name="Peers" type="PropertyBag">
      <simple type="string"><value>daq</value></simple>
    </struct>
 
 
  </struct>

However, the updateHook of 'control' never gets executed... Should this work? Note that I have 'daq' as a peer of 'control' and 'control' as a peer of 'daq' in the XML file.

Any advice? thanks!

Bert

> > Thanks in advance, > > Bert > > Ps. The orocos search engine doesn't seem to react on any search term...

We had again a crashed MySQL table. Our provider's machine must have some issues.

Peter

Timing of different components that communicate

Submitted by Tinne De Laet on Thu, 2010-12-02 08:40.

On Thursday 02 December 2010 00:26:57 bert [dot] willaert [..] ... wrote:
>

peter wrote:

On Wednesday 01 December 2010 01:40:30
bert [dot] willaert [..] ... wrote:
> > Hi,
> >
> > I have the following two components communicating with each other:

> > - 'daq': speaks with daq-card (using Comedi) --> two orocos ports:
> > output-port for encoders and input_port for force command.
-
> > 'control' : calculates the desired force commands based on current
> > position (using Eigen) --> two orocos ports: input_port for encoders and
> > output_port for force commands.

> >
> > I want the following sequence of events:

> > 'daq' reads encoders from daq-card and sends this to 'control'

> > 'control' reads encoder signals, calculates force commands and sends
> > these to 'daq'
'daq' reads force commands and sends this to
> > daq-card

> >
> > Currently I am using "normal" ports and when I check the timing, it seems
> > that the sequence of events is not always the desired one: e.g.
> > updatehook 'control' is finished before updatehook 'daq' even
> > started.

> >
> > The Orocos Component builder's manual explains how to use an EventPort
> > instead of a "normal" port to trigger the updatehook of a component based
> > on receiving data at an input_port. But how can a loop be created as in
> > my desired sequence of events? I.e. updatehook 'daq' is partially
> > executed, after this updatehook 'control' is fully executed, and finally
> > the remaing part of 'daq' is executed.
>
> This is rather easy. The only thing you need to take into account is the
> return value of your read(). For example, when daq's update hook reads the
> force command and the read returns 'NewData' you know a new sample arrived
> and can pass it on to comedi. If it returns 'OldData'. You just return from
> updateHook.
>
> In pseudo code:
>

>    // in daq:
>   void updateHook() {
>     comedi_read(data);
>     outport.write(data);
>     if ( inport.read( cfdata ) == NewData ) {
>           comedi_write( cfdata )
>     }
>  }
>

>
> You can make the controller component event driven and the daq component
> periodic (or the other way around). The 'event driven' component must add
> his port with 'addEventPort'. In your simple case, even both components
> could register their input ports as event ports and you can decide during
> deployment which one gets a periodic thread and which is reactive.
>
> -----------------------------------------

> Hmm, what approach is most easy yours or Tinne's? It seems to me that yours
> needs only very little adaptation, but I don't get the triggering working
> yet. So to make the 'controller' gets executed at the moment 'daq' sends
> new encoder signals, I did only the following two things: 1) I made the
> encoder input-port of 'control' an EventPort:
>

> this->ports()->addEventPorts(Enc_inport);
>

This should be add EventPort in stead of addEventPorts.

> 2) In the XML file I have now:
>

>   <struct name="control" type="Example::control">
> 
>     <struct name="Activity" type="NonPeriodicActivity">
>       <!--simple name="Period"
> type="double"><value>0.0002</value></simple--> <simple name="Priority"
> type="short"><value>0</value></simple> <simple name="Scheduler"
> type="string"><value>ORO_SCHED_RT</value></simple> </struct>
> 
>     <simple name="AutoConf" type="boolean"><value>1</value></simple>
>     <simple name="AutoStart" type="boolean"><value>1</value></simple>
>     <simple name="AutoConnect" type="boolean"><value>1</value></simple>
> 
>     <struct name="Ports" type="PropertyBag">
>       <simple name="control_Torque_port"
> type="string"><value>Comm_Torque</value></simple> <simple
> name="control_Enc_port" type="string"><value>Comm_Enc</value></simple>
> </struct>
> 
>     <struct name="Peers" type="PropertyBag">
>       <simple type="string"><value>daq</value></simple>
>     </struct>
> 
> 
>   </struct>
>

> However, the updateHook of 'control' never gets executed... Should this
> work? Note that I have 'daq' as a peer of 'control' and 'control' as a
> peer of 'daq' in the XML file.
>
> Any advice? thanks!

The only thing I can come up with is that your components are not properly
connected.
Could you post your entire xml or even better: is your code on svn or so such
that we can check it?

Tinne

>
> Bert
>
> > Thanks in advance,
> >
> > Bert
> >
> > Ps. The orocos search engine doesn't seem to react on any search term...
>
> We had again a crashed MySQL table. Our provider's machine must have some
> issues.
>
> Peter
>

Timing of different components that communicate

Submitted by Tinne De Laet on Wed, 2010-12-01 08:36.

Hi Bert,

> I have the following two components communicating with each other:

> - 'daq': speaks with daq-card (using Comedi) --> two orocos ports:
> output-port for encoders and input_port for force command.
-
> 'control' : calculates the desired force commands based on current
> position (using Eigen) --> two orocos ports: input_port for encoders and
> output_port for force commands.

>
> I want the following sequence of events:

> 'daq' reads encoders from daq-card and sends this to 'control'

> 'control' reads encoder signals, calculates force commands and sends these
> to 'daq'
'daq' reads force commands and sends this to daq-card

>
> Currently I am using "normal" ports and when I check the timing, it seems
> that the sequence of events is not always the desired one: e.g. updatehook
> 'control' is finished before updatehook 'daq' even started.

>
> The Orocos Component builder's manual explains how to use an EventPort
> instead of a "normal" port to trigger the updatehook of a component based
> on receiving data at an input_port. But how can a loop be created as in my
> desired sequence of events? I.e. updatehook 'daq' is partially executed,
> after this updatehook 'control' is fully executed, and finally the remaing
> part of 'daq' is executed.

We have applications with quite similar needs.

If I understand your usecase I would propose the following solution:

* Dag has a first method (readDag) that reads the data from the dag-card using
Comedi and puts the encoder signals on the outputPort of the Dag component.
* This method (readDag) is triggered by an EventPort (timerPort)
periodically triggered by a Timer Component
* Dag has a second method (sendForceCommands) that sends the force commands to
the dag-card
* This method (sendForceCommands) is triggered by an EventPort
(forceCommandsPort) triggered as soon as new data arrives on the
forceCommandsPort.

* Control has a method (caculateForceCommands) that calculate the force
commands and puts it to the outputPort of the Control component.
* This method (calculateForceCommands) is triggered by an EventPort
(encoderInputPort) that is triggered when new data arrives on the
encoderInputport.

It is important that both the Dag and the Control should be non-periodic
components and their updateHook is empty. All their functionality is in
methods that are triggered by data arrival on their ports.

Most convenient is to have a look at one of our examples
(http://svn.mech.kuleuven.be/repos/orocos/trunk/kul-ros-
pkg/stacks/camera_pose_estimation/ar_pose_ekf). ekf is a component whose
sysUpdate method is triggered periodically by a Timer component (through the
timerIdPort) and whose measUpdate method is triggered by data arrival on one
of its inputPorts.

Hope this helps, and please keep us informed about your progress!

Good luck!

Tinne

>
> Thanks in advance,
>
> Bert
>
> Ps. The orocos search engine doesn't seem to react on any search term...

Timing of different components that communicate

Submitted by bruyninc on Wed, 2010-12-01 07:40.

On Wed, 1 Dec 2010, bert [dot] willaert [..] ... wrote:

> Hi,
>
> I have the following two components communicating with each other:

> - 'daq': speaks with daq-card (using Comedi) --> two orocos ports: output-port for encoders and input_port for force command.

> - 'control' : calculates the desired force commands based on current position (using Eigen) --> two orocos ports: input_port for encoders and output_port for force commands.

>
> I want the following sequence of events:

> 'daq' reads encoders from daq-card and sends this to 'control'

> 'control' reads encoder signals, calculates force commands and sends these to 'daq'

> 'daq' reads force commands and sends this to daq-card

>
> Currently I am using "normal" ports and when I check the timing, it seems
> that the sequence of events is not always the desired one: e.g.
> updatehook 'control' is finished before updatehook 'daq' even
> started.

>
> The Orocos Component builder's manual explains how to use an EventPort
> instead of a "normal" port to trigger the updatehook of a component based
> on receiving data at an input_port. But how can a loop be created as in
> my desired sequence of events? I.e. updatehook 'daq' is partially
> executed, after this updatehook 'control' is fully executed, and finally
> the remaing part of 'daq' is executed.

If you need such 100% deterministic coordination, than you should make a
separate component that takes care of this coordination. The simplest one
is one that just calls the functionalities you describe above, in the
appropriate order; this is possible if all the devices are "passive", that
is, they do not need their own thread of execution. If they are "active",
coordination is just a lot less deterministic, by nature. This is
definitely so whenever hardware is in the loop, providing one or more
"threads" that your software cannot fully control anyway.

But I don't know whether you really need that hard coordination! Your
controller should just be able to work with the latest data it gets from the
hardware. "Missing" one sample should not make a difference.

In summary, it seems to me that you are struggling with the distinctions
between (i) synchronized, single-thread control (a la Simulink), and (ii)
asynchronous, distributed control (a la Orocos). Both have their role, and
neither of them can serve both purposes.

> Thanks in advance,
>
> Bert

Herman

>
> Ps. The orocos search engine doesn't seem to react on any search term...
>
>

Timing of different components that communicate

Submitted by b1willaert on Wed, 2010-12-01 22:52.

bruyninc wrote:

On Wed, 1 Dec 2010, bert [dot] willaert [..] ... wrote:

>> Hi,
>>
>.> I have the following two components communicating with each other:

>> - 'daq': speaks with daq-card (using Comedi) --> two orocos ports: output-port for encoders and input_port for force command.

> - 'control' : calculates the desired force commands based on current position (using Eigen) --> two orocos ports: input_port for encoders and output_port for force commands.

>
> I want the following sequence of events:

> 'daq' reads encoders from daq-card and sends this to 'control'

> 'control' reads encoder signals, calculates force commands and sends these to 'daq'

> 'daq' reads force commands and sends this to daq-card

>
> Currently I am using "normal" ports and when I check the timing, it seems
> that the sequence of events is not always the desired one: e.g.
> updatehook 'control' is finished before updatehook 'daq' even
>> started.

>>
>> The Orocos Component builder's manual explains how to use an EventPort
>> instead of a "normal" port to trigger the updatehook of a component based
>> on receiving data at an input_port. But how can a loop be created as in
>> my desired sequence of events? I.e. updatehook 'daq' is partially
>> executed, after this updatehook 'control' is fully executed, and finally
>> the remaing part of 'daq' is executed.

>If you need such 100% deterministic coordination, than you should make a
separate component that takes care of this coordination. The simplest one
is one that just calls the functionalities you describe above, in the
appropriate order; this is possible if all the devices are "passive", that
is, they do not need their own thread of execution. If they are "active",
coordination is just a lot less deterministic, by nature. This is
definitely so whenever hardware is in the loop, providing one or more
"threads" that your software cannot fully control anyway.

--------------------------------------------------

First of all, the controller works fine like it is now, i.e. not having my proposed sequence of events, but I would like to understand the timing stuff better... now I am a little confused ;)

I was indeed not aware of this single versus multiple thread thing, based on your explanation I understand now that (1) 'daq' and 'control' are two independent processes and (2) coordinating their relative timing is not trivial/not needed.

However, if 'control' is executed "just" before 'daq', then the time between reading the new position and sending the corresponding force command becomes at least large than Ts, while with my proposed sequence of events this time is maximum Ts, right? And the less delay the better, now?

Moreover, Tinne and Peter seem to suggest that my proposed sequence of events makes sense, but they both seem to propose a different approach to achieve this sequence of events...

Another question:

I put start_time = TimeService::Instance()->secondsSince(timestamp) as the first line of both the updateHooks and stop_time = TimeService::Instance()->secondsSince(timestamp) as the last line of both updateHooks. Here is a result of that (Ts = 0.0002 s):

 TimeStamp     daq.start_time control.start_time control.stop_time daq.stop_time
 
 0.0104646        0.0102412        0.0102207       0.0102402       0.0102664 
 0.0106646        0.0104198        0.0103992       0.0104187       0.0104450 
 0.0108747        0.0106114        0.0105833       0.0105932       0.0106297 
 0.0110643        0.0108298        0.0108092       0.0108459       0.0108549 
 0.0112850        0.0110199        0.0109995       0.0110191       0.0110453 
 0.0114645        0.0112404        0.0112199       0.0112394       0.0112657 
 0.0116645        0.0114196        0.0113990       0.0114186       0.0114448 
 0.0118746        0.0116114        0.0115833       0.0115931       0.0116297 
 0.0120644        0.0118296        0.0118091       0.0118559       0.0118548 
 0.0122850        0.0120199        0.0119997       0.0120194       0.0120455 
 0.0124645        0.0122405        0.0122200       0.0122395       0.0122658

You can see here, that 'control' is always executed before 'daq' but the question is about the second column. That should be the time just before the encoders are read. The time difference however seems to vary up to 10% of Ts. Theoretically, that influences velocity calculation, filtering, ... But maybe that's practically not a problem? (no idea what this is with NI/Dspace as I never looks into such details before ;))

Thanks!
--------------------------------------------------

>> Thanks in advance,
>>
>> Bert

>Herman

>>
>> Ps. The orocos search engine doesn't seem to react on any search term...
>>
>>

Re: Timing of different components that communicate

Submitted by b1willaert on Wed, 2010-12-01 22:50.

bruyninc wrote:

On Wed, 1 Dec 2010, bert [dot] willaert [..] ... wrote:

> Currently I am using "normal" ports and when I check the timing, it seems > that the sequence of events is not always the desired one: e.g. > updatehook 'control' is finished before updatehook 'daq' even >> started.
>> >> The Orocos Component builder's manual explains how to use an EventPort >> instead of a "normal" port to trigger the updatehook of a component based >> on receiving data at an input_port. But how can a loop be created as in >> my desired sequence of events? I.e. updatehook 'daq' is partially >> executed, after this updatehook 'control' is fully executed, and finally >> the remaing part of 'daq' is executed.

>If you need such 100% deterministic coordination, than you should make a separate component that takes care of this coordination. The simplest one is one that just calls the functionalities you describe above, in the appropriate order; this is possible if all the devices are "passive", that is, they do not need their own thread of execution. If they are "active", coordination is just a lot less deterministic, by nature. This is definitely so whenever hardware is in the loop, providing one or more "threads" that your software cannot fully control anyway.

But I don't know whether you really need that hard coordination! Your controller should just be able to work with the latest data it gets from the hardware. "Missing" one sample should not make a difference.

In summary, it seems to me that you are struggling with the distinctions between (i) synchronized, single-thread control (a la Simulink), and (ii) asynchronous, distributed control (a la Orocos). Both have their role, and neither of them can serve both purposes.

--------------------------------------------------
First of all, the controller works fine like it is now, i.e. not having my proposed sequence of events, but I would like to understand the timing stuff better... now I am a little confused ;)
I was indeed not aware of this single versus multiple thread thing, based on your explanation I understand now that (1) 'daq' and 'control' are two independent processes and (2) coordinating their relative timing is not trivial/not needed.
However, if 'control' is executed "just" before 'daq', then the time between reading the new position and sending the corresponding force command becomes at least large than Ts, while with my proposed sequence of events this time is maximum Ts, right? And the less delay the better, now?
Moreover, Tinne and Peter seem to suggest that my proposed sequence of events makes sense, but they both seem to propose a different approach to achieve this sequence of events...

Another question:
I put start_time = TimeService::Instance()->secondsSince(timestamp) as the first line of both the updateHooks and stop_time = TimeService::Instance()->secondsSince(timestamp) as the last line of both updateHooks. Here is a result of that (Ts = 0.0002 s):

 TimeStamp     daq.start_time control.start_time control.stop_time daq.stop_time
 
 0.0104646        0.0102412        0.0102207       0.0102402       0.0102664 
 0.0106646        0.0104198        0.0103992       0.0104187       0.0104450 
 0.0108747        0.0106114        0.0105833       0.0105932       0.0106297 
 0.0110643        0.0108298        0.0108092       0.0108459       0.0108549 
 0.0112850        0.0110199        0.0109995       0.0110191       0.0110453 
 0.0114645        0.0112404        0.0112199       0.0112394       0.0112657 
 0.0116645        0.0114196        0.0113990       0.0114186       0.0114448 
 0.0118746        0.0116114        0.0115833       0.0115931       0.0116297 
 0.0120644        0.0118296        0.0118091       0.0118559       0.0118548 
 0.0122850        0.0120199        0.0119997       0.0120194       0.0120455 
 0.0124645        0.0122405        0.0122200       0.0122395       0.0122658

Thanks! --------------------------------------------------

>> Thanks in advance, >> >> Bert

>Herman

>> >> Ps. The orocos search engine doesn't seem to react on any search term... >> >>

Timing of different components that communicate

Submitted by bruyninc on Thu, 2010-12-02 08:12.

On Wed, 1 Dec 2010, bert [dot] willaert [..] ... wrote:

bruyninc wrote:

On Wed, 1 Dec 2010, bert [dot] willaert [..] ... wrote:
>
>>> Hi,
>>>
>> .> I have the following two components communicating with each other:

>>> - 'daq': speaks with daq-card (using Comedi) --> two orocos ports: output-port for encoders and input_port for force command.

>> - 'control' : calculates the desired force commands based on current position (using Eigen) --> two orocos ports: input_port for encoders and output_port for force commands.

>>
>> I want the following sequence of events:

>> 'daq' reads encoders from daq-card and sends this to 'control'

>> 'control' reads encoder signals, calculates force commands and sends these to 'daq'

>> 'daq' reads force commands and sends this to daq-card

>>
>> Currently I am using "normal" ports and when I check the timing, it seems
>> that the sequence of events is not always the desired one: e.g.
>> updatehook 'control' is finished before updatehook 'daq' even
>>> started.

>>>
>>> The Orocos Component builder's manual explains how to use an EventPort
>>> instead of a "normal" port to trigger the updatehook of a component based
>>> on receiving data at an input_port. But how can a loop be created as in
>>> my desired sequence of events? I.e. updatehook 'daq' is partially
>>> executed, after this updatehook 'control' is fully executed, and finally
>>> the remaing part of 'daq' is executed.
>
>> If you need such 100% deterministic coordination, than you should make a
> separate component that takes care of this coordination. The simplest one
> is one that just calls the functionalities you describe above, in the
> appropriate order; this is possible if all the devices are "passive", that
> is, they do not need their own thread of execution. If they are "active",
> coordination is just a lot less deterministic, by nature. This is
> definitely so whenever hardware is in the loop, providing one or more
> "threads" that your software cannot fully control anyway.
>
> But I don't know whether you really need that hard coordination! Your
> controller should just be able to work with the latest data it gets from the
> hardware. "Missing" one sample should not make a difference.
>
> In summary, it seems to me that you are struggling with the distinctions
> between (i) synchronized, single-thread control (a la Simulink), and (ii)
> asynchronous, distributed control (a la Orocos). Both have their role, and
> neither of them can serve both purposes.
>
> --------------------------------------------------

> First of all, the controller works fine like it is now, i.e. not having my proposed sequence of events, but I would like to understand the timing stuff better... now I am a little confused ;)

> I was indeed not aware of this single versus multiple thread thing, based
> on your explanation I understand now that (1) 'daq' and 'control' are two
> independent processes and (2) coordinating their relative timing is not
> trivial/not needed.

It is your choice to put your components in the same thread or process, but
this has repercussions on with what performance you can synchronize them.
My suggestion would be: put them all in the same thread, if there is no
reason not to do so.

> However, if 'control' is executed "just" before 'daq', then the time
> between reading the new position and sending the corresponding force
> command becomes at least large than Ts, while with my proposed sequence
> of events this time is maximum Ts, right? And the less delay the better,
> now?

In principle yes. But in practice, most systems can easily deal with a
delay or two :-)

> Moreover, Tinne and Peter seem to suggest that my proposed sequence of
> events makes sense, but they both seem to propose a different approach to
> achieve this sequence of events...

All the replies make sense! That's the "disadvantage" of a flexible open
source framework: it gives you _choice_. But I understand very well that
you are confused by this choice.

> Another question:

> I put start_time = TimeService::Instance()->secondsSince(timestamp) as
> the first line of both the updateHooks and stop_time =
> TimeService::Instance()->secondsSince(timestamp) as the last line of both
> updateHooks.

Good! :-)

> Here is a result of that (Ts = 0.0002 s):
>

> TimeStamp     daq.start_time control.start_time control.stop_time daq.stop_time
>
> 0.0104646        0.0102412        0.0102207       0.0102402       0.0102664
> 0.0106646        0.0104198        0.0103992       0.0104187       0.0104450
> 0.0108747        0.0106114        0.0105833       0.0105932       0.0106297
> 0.0110643        0.0108298        0.0108092       0.0108459       0.0108549
> 0.0112850        0.0110199        0.0109995       0.0110191       0.0110453
> 0.0114645        0.0112404        0.0112199       0.0112394       0.0112657
> 0.0116645        0.0114196        0.0113990       0.0114186       0.0114448
> 0.0118746        0.0116114        0.0115833       0.0115931       0.0116297
> 0.0120644        0.0118296        0.0118091       0.0118559       0.0118548
> 0.0122850        0.0120199        0.0119997       0.0120194       0.0120455
> 0.0124645        0.0122405        0.0122200       0.0122395       0.0122658
>

>
>
> You can see here, that 'control' is always executed before 'daq' but the
> question is about the second column. That should be the time just before
> the encoders are read. The time difference however seems to vary up to
> 10% of Ts.

Don't forget that the other components need time to run too... The control
component for example takes about 0.00002 s, which is this 10% of Ts...
Depending on your hardware, there can still be other "invisible"
activities that take time on your computer: the PCI bus with its DMA, all
interrupt routines, etc.

> Theoretically, that influences velocity calculation,
> filtering, ... But maybe that's practically not a problem? (no idea what
> this is with NI/Dspace as I never looks into such details before ;))

Indeed! :-)

Herman

>
> Thanks!
> --------------------------------------------------

>
>>> Thanks in advance,
>>>
>>> Bert
>
>> Herman
>
>>>
>>> Ps. The orocos search engine doesn't seem to react on any search term...
>>>
>>>
>

>
>

Timing of different components that communicate

Submitted by b1willaert on Wed, 2010-12-01 00:44.

Hi,

I have the following two components communicating with each other:

- 'daq': speaks with daq-card (using Comedi) --> two orocos ports: output-port for encoders and input_port for force command.

- 'control' : calculates the desired force commands based on current position (using Eigen) --> two orocos ports: input_port for encoders and output_port for force commands.

I want the following sequence of events:

'daq' reads encoders from daq-card and sends this to 'control'

'control' reads encoder signals, calculates force commands and sends these to 'daq'

'daq' reads force commands and sends this to daq-card

Thanks in advance,

Bert

Ps. The orocos search engine doesn't seem to react on any search term...