prevent function from executing when other is executing

Submitted by Kurt Geebelen on Fri, 2011-07-29 14:16

Hi,

I have a component that is running a kalman filter, which has 2 main
functions: propagate and update. I periodically propagate my kalman
filter, and I update my kalman filter event-driven when data comes
available on a port.

I sometimes get a segmentation fault when running this component. I
noticed that this is due to the problem that sometimes, while my
component is performing the propagation, new data becomes available on a
port, and the component will attempt to update the kalman filter while
performing the propagation. I tried solving it by setting some booleans
while doing the propagate/update. So something like this:

For propagating:

while(updating){}
propagating=true;
propagate();
propagating=false;

And for updating:

while(propagating){}
updating=true;
update();
updating=false;

But this didn't completely solve the issue.
Is there a better solution to prevent one function from executing while
the other is executing, and vise versa?

Kurt

‹ Start of an "Orocos Control Box" project... Problem with orocos under xenomai ›
»

prevent function from executing when other is executing

Submitted by peter on Sun, 2011-07-31 10:08.

On Fri, Jul 29, 2011 at 4:15 PM, Kurt Geebelen
<kurt [dot] geebelen [..] ...> wrote:
>
> Hi,
>
> I have a component that is running a kalman filter, which has 2 main
> functions: propagate and update. I periodically propagate my kalman
> filter, and I update my kalman filter event-driven when data comes
> available on a port.
>
> I sometimes get a segmentation fault when running this component. I
> noticed that this is due to the problem that sometimes, while my
> component is performing the propagation, new data becomes available on a
> port, and the component will attempt to update the kalman filter while
> performing the propagation. I tried solving it by setting some booleans
> while doing the propagate/update. So something like this:
>
> For propagating:
>
> 

> while(updating){}
> propagating=true;
> propagate();
> propagating=false;
>

Change to:

{
   os::MutexLock lock(m);
   propagate();
} // note these curly braces, they must be here !

>
> And for updating:
>
> 

> while(propagating){}
> updating=true;
> update();
> updating=false;
>

change to:

{
   os::MutexLock lock(m);
   update();
} // note these curly braces, they must be here !

>
> But this didn't completely solve the issue.
> Is there a better solution to prevent one function from executing while
> the other is executing, and vise versa?

Add a 'os::Mutex m;' member variable in your component class header
and lock it each time (as shown above) you want to mutually exclude
execution of some code by different threads.

The curly braces limit the 'scope' where the protection starts: it
starts at the 'lock' statement and ends at the ending '}'.

Peter

»

prevent function from executing when other is executing

Submitted by bruyninc on Sun, 2011-07-31 11:48.

On Sun, 31 Jul 2011, Peter Soetens wrote:

> On Fri, Jul 29, 2011 at 4:15 PM, Kurt Geebelen
> <kurt [dot] geebelen [..] ...> wrote:
>>
>> Hi,
>>
>> I have a component that is running a kalman filter, which has 2 main
>> functions: propagate and update. I periodically propagate my kalman
>> filter, and I update my kalman filter event-driven when data comes
>> available on a port.
>>
>> I sometimes get a segmentation fault when running this component. I
>> noticed that this is due to the problem that sometimes, while my
>> component is performing the propagation, new data becomes available on a
>> port, and the component will attempt to update the kalman filter while
>> performing the propagation. I tried solving it by setting some booleans
>> while doing the propagate/update. So something like this:
>>
>> For propagating:
>>
>> 

>> while(updating){}
>> propagating=true;
>> propagate();
>> propagating=false;
>>

>
> Change to:
>
> 
> {
>   os::MutexLock lock(m);
>   propagate();
> } // note these curly braces, they must be here !
>

>
>>
>> And for updating:
>>
>> 
>> while(propagating){}
>> updating=true;
>> update();
>> updating=false;
>>

>
> change to:
>
> 
> {
>   os::MutexLock lock(m);
>   update();
> } // note these curly braces, they must be here !
>

>

Please, don't invite users to start introducing explicit locks in their
applications! This brings us back to the times _before_ Orocos/RTT existed,
and to the reasons _why_ it was developed: to shield users from these ugly,
low-level, error-prone OS primitives. It is obvious that locks have _no_
place in a real component based application, by definition almost.

I am 100% sure Kurt's problem can be neatly solved with appropriate design
of his application using the core primitives of RTT, namely Ports and
simple Coordination with a state machine.

In addition to providing good software, Orocos also has an educational
vocation, and that is to stimulate best practice software engineering into
the mechatronics and robotics communities...

>> But this didn't completely solve the issue.
>> Is there a better solution to prevent one function from executing while
>> the other is executing, and vise versa?
>
> Add a 'os::Mutex m;' member variable in your component class header
> and lock it each time (as shown above) you want to mutually exclude
> execution of some code by different threads.
>
> The curly braces limit the 'scope' where the protection starts: it
> starts at the 'lock' statement and ends at the ending '}'.
>
> Peter

Herman

»

prevent function from executing when other is executing

Submitted by snrkiwi on Sun, 2011-07-31 18:16.

On Jul 31, 2011, at 07:47 , Herman Bruyninckx wrote:

> On Sun, 31 Jul 2011, Peter Soetens wrote:
>
>> On Fri, Jul 29, 2011 at 4:15 PM, Kurt Geebelen
>> <kurt [dot] geebelen [..] ...> wrote:
>>>
>>> Hi,
>>>
>>> I have a component that is running a kalman filter, which has 2 main
>>> functions: propagate and update. I periodically propagate my kalman
>>> filter, and I update my kalman filter event-driven when data comes
>>> available on a port.
>>>
>>> I sometimes get a segmentation fault when running this component. I
>>> noticed that this is due to the problem that sometimes, while my
>>> component is performing the propagation, new data becomes available on a
>>> port, and the component will attempt to update the kalman filter while
>>> performing the propagation. I tried solving it by setting some booleans
>>> while doing the propagate/update. So something like this:
>>>
>>> For propagating:
>>>
>>> 

>>> while(updating){}
>>> propagating=true;
>>> propagate();
>>> propagating=false;
>>>

>>
>> Change to:
>>
>> 
>> {
>>  os::MutexLock lock(m);
>>  propagate();
>> } // note these curly braces, they must be here !
>>

>>
>>>
>>> And for updating:
>>>
>>> 
>>> while(propagating){}
>>> updating=true;
>>> update();
>>> updating=false;
>>>

>>
>> change to:
>>
>> 
>> {
>>  os::MutexLock lock(m);
>>  update();
>> } // note these curly braces, they must be here !
>>

>>
>
> Please, don't invite users to start introducing explicit locks in their
> applications! This brings us back to the times _before_ Orocos/RTT existed,
> and to the reasons _why_ it was developed: to shield users from these ugly,
> low-level, error-prone OS primitives. It is obvious that locks have _no_
> place in a real component based application, by definition almost.
>
> I am 100% sure Kurt's problem can be neatly solved with appropriate design
> of his application using the core primitives of RTT, namely Ports and
> simple Coordination with a state machine.
>
> In addition to providing good software, Orocos also has an educational
> vocation, and that is to stimulate best practice software engineering into
> the mechatronics and robotics communities...

True, but sometimes you need something to work first, before you make it correct. Peter's suggestion will fix his immediate needs _and_ we need to educate Kurt that this isn't the best approach and that he should consider doing it another way.
S

»

prevent function from executing when other is executing

Submitted by Kurt Geebelen on Mon, 2011-08-01 07:48.

Hi,

I have written a C+-class for the kalman filter, which has the 2
functions propagate and update (I didn't use the ExtendedKalmanFilter
class of the BLF-library because this way it was more clear to me what
was happening). The variables that are changed in both functions are the
covariance matrix and the state of the kalman filter. They are of type
Matrix of the Newmat library I am using
(http://www.robertnz.net/nm10.htm). The elements of these matrices are
of type double.

My estimator component than creates an instance of this kalman filter
class, periodically propagates it (apply system model), and whenever a
measurement becomes available, updates the kalman filter with this
measurement. This is thus where it sometimes goes wrong, when these
functions coincide.

Kurt

Op 31/07/2011 20:13, S Roderick schreef:
> On Jul 31, 2011, at 07:47 , Herman Bruyninckx wrote:
>
>> On Sun, 31 Jul 2011, Peter Soetens wrote:
>>
>>> On Fri, Jul 29, 2011 at 4:15 PM, Kurt Geebelen
>>> <kurt [dot] geebelen [..] ...> wrote:
>>>> Hi,
>>>>
>>>> I have a component that is running a kalman filter, which has 2 main
>>>> functions: propagate and update. I periodically propagate my kalman
>>>> filter, and I update my kalman filter event-driven when data comes
>>>> available on a port.
>>>>
>>>> I sometimes get a segmentation fault when running this component. I
>>>> noticed that this is due to the problem that sometimes, while my
>>>> component is performing the propagation, new data becomes available on a
>>>> port, and the component will attempt to update the kalman filter while
>>>> performing the propagation. I tried solving it by setting some booleans
>>>> while doing the propagate/update. So something like this:
>>>>
>>>> For propagating:
>>>>
>>>> 

>>>> while(updating){}
>>>> propagating=true;
>>>> propagate();
>>>> propagating=false;
>>>>

>>> Change to:
>>>
>>> 
>>> {
>>>   os::MutexLock lock(m);
>>>   propagate();
>>> } // note these curly braces, they must be here !
>>>

>>>
>>>> And for updating:
>>>>
>>>> 
>>>> while(propagating){}
>>>> updating=true;
>>>> update();
>>>> updating=false;
>>>>

>>> change to:
>>>
>>> 
>>> {
>>>   os::MutexLock lock(m);
>>>   update();
>>> } // note these curly braces, they must be here !
>>>

>>>
>> Please, don't invite users to start introducing explicit locks in their
>> applications! This brings us back to the times _before_ Orocos/RTT existed,
>> and to the reasons _why_ it was developed: to shield users from these ugly,
>> low-level, error-prone OS primitives. It is obvious that locks have _no_
>> place in a real component based application, by definition almost.
>>
>> I am 100% sure Kurt's problem can be neatly solved with appropriate design
>> of his application using the core primitives of RTT, namely Ports and
>> simple Coordination with a state machine.
>>
>> In addition to providing good software, Orocos also has an educational
>> vocation, and that is to stimulate best practice software engineering into
>> the mechatronics and robotics communities...
> True, but sometimes you need something to work first, before you make it correct. Peter's suggestion will fix his immediate needs _and_ we need to educate Kurt that this isn't the best approach and that he should consider doing it another way.
> S
>

»

prevent function from executing when other is executing

Submitted by bruyninc on Mon, 2011-08-01 08:08.

On Mon, 1 Aug 2011, Kurt Geebelen wrote:

> Hi,
(Please do not top post <http://en.wikipedia.org/wiki/Top_posting>)

> I have written a C+-class for the kalman filter, which has the 2
> functions propagate and update (I didn't use the ExtendedKalmanFilter
> class of the BLF-library because this way it was more clear to me what
> was happening).

Oops... What is not clear with the way the BFL integrates an EKF into
Orocos?
E.g. <http://comments.gmane.org/gmane.science.robotics.orocos.devel/8457>

> The variables that are changed in both functions are the
> covariance matrix and the state of the kalman filter. They are of type
> Matrix of the Newmat library I am using
> (http://www.robertnz.net/nm10.htm). The elements of these matrices are
> of type double.
>
> My estimator component than creates an instance of this kalman filter
> class, periodically propagates it (apply system model), and whenever a
> measurement becomes available, updates the kalman filter with this
> measurement. This is thus where it sometimes goes wrong, when these
> functions coincide.

Exactly. But they should not "coincide" :-) I mean, the component that
contains the (E)KF code should run the process update and measurement
update 'atomically', which could be realised by letting it read from Data
ports (one for new timer data, one for new measurement data).

I have the impression you have another design, in which you call an
operation on the EKF component from two other components, and in this way
it becomes very difficult for the EKF component to guarantee data
consistency...

Is my assumption about your architecture correct or not?
In other words, what _is_ the architecture of your complete system?

> Kurt

Herman

> Op 31/07/2011 20:13, S Roderick schreef:
>> On Jul 31, 2011, at 07:47 , Herman Bruyninckx wrote:
>>
>>> On Sun, 31 Jul 2011, Peter Soetens wrote:
>>>
>>>> On Fri, Jul 29, 2011 at 4:15 PM, Kurt Geebelen
>>>> <kurt [dot] geebelen [..] ...> wrote:
>>>>> Hi,
>>>>>
>>>>> I have a component that is running a kalman filter, which has 2 main
>>>>> functions: propagate and update. I periodically propagate my kalman
>>>>> filter, and I update my kalman filter event-driven when data comes
>>>>> available on a port.
>>>>>
>>>>> I sometimes get a segmentation fault when running this component. I
>>>>> noticed that this is due to the problem that sometimes, while my
>>>>> component is performing the propagation, new data becomes available on a
>>>>> port, and the component will attempt to update the kalman filter while
>>>>> performing the propagation. I tried solving it by setting some booleans
>>>>> while doing the propagate/update. So something like this:
>>>>>
>>>>> For propagating:
>>>>>
>>>>> 

>>>>> while(updating){}
>>>>> propagating=true;
>>>>> propagate();
>>>>> propagating=false;
>>>>>

>>>> Change to:
>>>>
>>>> 
>>>> {
>>>>   os::MutexLock lock(m);
>>>>   propagate();
>>>> } // note these curly braces, they must be here !
>>>>

>>>>
>>>>> And for updating:
>>>>>
>>>>> 
>>>>> while(propagating){}
>>>>> updating=true;
>>>>> update();
>>>>> updating=false;
>>>>>

>>>> change to:
>>>>
>>>> 
>>>> {
>>>>   os::MutexLock lock(m);
>>>>   update();
>>>> } // note these curly braces, they must be here !
>>>>

>>>>
>>> Please, don't invite users to start introducing explicit locks in their
>>> applications! This brings us back to the times _before_ Orocos/RTT existed,
>>> and to the reasons _why_ it was developed: to shield users from these ugly,
>>> low-level, error-prone OS primitives. It is obvious that locks have _no_
>>> place in a real component based application, by definition almost.
>>>
>>> I am 100% sure Kurt's problem can be neatly solved with appropriate design
>>> of his application using the core primitives of RTT, namely Ports and
>>> simple Coordination with a state machine.
>>>
>>> In addition to providing good software, Orocos also has an educational
>>> vocation, and that is to stimulate best practice software engineering into
>>> the mechatronics and robotics communities...
>> True, but sometimes you need something to work first, before you make it correct. Peter's suggestion will fix his immediate needs _and_ we need to educate Kurt that this isn't the best approach and that he should consider doing it another way.
>> S
>>
>

--
K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
EURON Coordinator (European Robotics Research Network) <http://www.euron.org>
Open Realtime Control Services <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>

»

prevent function from executing when other is executing

Submitted by Kurt Geebelen on Mon, 2011-08-01 08:32.

Op 1/08/2011 10:00, Herman Bruyninckx schreef:
> On Mon, 1 Aug 2011, Kurt Geebelen wrote:
>
>> Hi,
> (Please do not top post<http://en.wikipedia.org/wiki/Top_posting>)

Sorry

>
>> I have written a C+-class for the kalman filter, which has the 2
>> functions propagate and update (I didn't use the ExtendedKalmanFilter
>> class of the BLF-library because this way it was more clear to me what
>> was happening).
> Oops... What is not clear with the way the BFL integrates an EKF into
> Orocos?
> E.g.<http://comments.gmane.org/gmane.science.robotics.orocos.devel/8457>

Nothing is wrong with it. I just thought it would be a better exercise
to implement it myself.

>
>> The variables that are changed in both functions are the
>> covariance matrix and the state of the kalman filter. They are of type
>> Matrix of the Newmat library I am using
>> (http://www.robertnz.net/nm10.htm). The elements of these matrices are
>> of type double.
>>
>> My estimator component than creates an instance of this kalman filter
>> class, periodically propagates it (apply system model), and whenever a
>> measurement becomes available, updates the kalman filter with this
>> measurement. This is thus where it sometimes goes wrong, when these
>> functions coincide.
> Exactly. But they should not "coincide" :-) I mean, the component that
> contains the (E)KF code should run the process update and measurement
> update 'atomically', which could be realised by letting it read from Data
> ports (one for new timer data, one for new measurement data).
>
> I have the impression you have another design, in which you call an
> operation on the EKF component from two other components, and in this way
> it becomes very difficult for the EKF component to guarantee data
> consistency...
>
> Is my assumption about your architecture correct or not?
> In other words, what _is_ the architecture of your complete system?

There is only one component communicating with the kalman filter, namely
the estimator component. Note that the EKF is not a orocos-component,
but just a C++ class, on which the estimator-component is calling
functions. I could integrate this code in the estimator component, but I
don't think this would change much?

In the estimator component, in the updateHook, I thus do the process
update. The measurements are coming from another component, which puts
them on a Data port. My estimator component connects with this port, and
I have coupled an event to this port, which performs the measurement
update with the data on this port.

>
>> Kurt
> Herman

Kurt

>
>> Op 31/07/2011 20:13, S Roderick schreef:
>>> On Jul 31, 2011, at 07:47 , Herman Bruyninckx wrote:
>>>
>>>> On Sun, 31 Jul 2011, Peter Soetens wrote:
>>>>
>>>>> On Fri, Jul 29, 2011 at 4:15 PM, Kurt Geebelen
>>>>> <kurt [dot] geebelen [..] ...> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I have a component that is running a kalman filter, which has 2 main
>>>>>> functions: propagate and update. I periodically propagate my kalman
>>>>>> filter, and I update my kalman filter event-driven when data comes
>>>>>> available on a port.
>>>>>>
>>>>>> I sometimes get a segmentation fault when running this component. I
>>>>>> noticed that this is due to the problem that sometimes, while my
>>>>>> component is performing the propagation, new data becomes available on a
>>>>>> port, and the component will attempt to update the kalman filter while
>>>>>> performing the propagation. I tried solving it by setting some booleans
>>>>>> while doing the propagate/update. So something like this:
>>>>>>
>>>>>> For propagating:
>>>>>>
>>>>>> 

>>>>>> while(updating){}
>>>>>> propagating=true;
>>>>>> propagate();
>>>>>> propagating=false;
>>>>>>

>>>>> Change to:
>>>>>
>>>>> 
>>>>> {
>>>>>    os::MutexLock lock(m);
>>>>>    propagate();
>>>>> } // note these curly braces, they must be here !
>>>>>

>>>>>
>>>>>> And for updating:
>>>>>>
>>>>>> 
>>>>>> while(propagating){}
>>>>>> updating=true;
>>>>>> update();
>>>>>> updating=false;
>>>>>>

>>>>> change to:
>>>>>
>>>>> 
>>>>> {
>>>>>    os::MutexLock lock(m);
>>>>>    update();
>>>>> } // note these curly braces, they must be here !
>>>>>

>>>>>
>>>> Please, don't invite users to start introducing explicit locks in their
>>>> applications! This brings us back to the times _before_ Orocos/RTT existed,
>>>> and to the reasons _why_ it was developed: to shield users from these ugly,
>>>> low-level, error-prone OS primitives. It is obvious that locks have _no_
>>>> place in a real component based application, by definition almost.
>>>>
>>>> I am 100% sure Kurt's problem can be neatly solved with appropriate design
>>>> of his application using the core primitives of RTT, namely Ports and
>>>> simple Coordination with a state machine.
>>>>
>>>> In addition to providing good software, Orocos also has an educational
>>>> vocation, and that is to stimulate best practice software engineering into
>>>> the mechatronics and robotics communities...
>>> True, but sometimes you need something to work first, before you make it correct. Peter's suggestion will fix his immediate needs _and_ we need to educate Kurt that this isn't the best approach and that he should consider doing it another way.
>>> S
>>>
> --
> K.U.Leuven, Mechanical Eng., Mechatronics& Robotics Research Group
> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> EURON Coordinator (European Robotics Research Network)<http://www.euron.org>
> Open Realtime Control Services<http://www.orocos.org>
> Associate Editor JOSER<http://www.joser.org>, IJRR<http://www.ijrr.org>

»

prevent function from executing when other is executing

Submitted by bruyninc on Mon, 2011-08-01 08:44.

On Mon, 1 Aug 2011, Kurt Geebelen wrote:

> Op 1/08/2011 10:00, Herman Bruyninckx schreef:
>> On Mon, 1 Aug 2011, Kurt Geebelen wrote:
>>
>>> Hi,
>> (Please do not top post<http://en.wikipedia.org/wiki/Top_posting>)
>
> Sorry
>
>>
>>> I have written a C+-class for the kalman filter, which has the 2
>>> functions propagate and update (I didn't use the ExtendedKalmanFilter
>>> class of the BLF-library because this way it was more clear to me what
>>> was happening).
>> Oops... What is not clear with the way the BFL integrates an EKF into
>> Orocos?
>> E.g.<http://comments.gmane.org/gmane.science.robotics.orocos.devel/8457>
>
> Nothing is wrong with it. I just thought it would be a better exercise
> to implement it myself.

That turns out to be true :-) There is no better schooling than to repeat
the errors one _has_ to make before being able to appreciate better
practice solutions :-)

>>> The variables that are changed in both functions are the
>>> covariance matrix and the state of the kalman filter. They are of type
>>> Matrix of the Newmat library I am using
>>> (http://www.robertnz.net/nm10.htm). The elements of these matrices are
>>> of type double.
>>>
>>> My estimator component than creates an instance of this kalman filter
>>> class, periodically propagates it (apply system model), and whenever a
>>> measurement becomes available, updates the kalman filter with this
>>> measurement. This is thus where it sometimes goes wrong, when these
>>> functions coincide.
>> Exactly. But they should not "coincide" :-) I mean, the component that
>> contains the (E)KF code should run the process update and measurement
>> update 'atomically', which could be realised by letting it read from Data
>> ports (one for new timer data, one for new measurement data).
>>
>> I have the impression you have another design, in which you call an
>> operation on the EKF component from two other components, and in this way
>> it becomes very difficult for the EKF component to guarantee data
>> consistency...
>>
>> Is my assumption about your architecture correct or not?
>> In other words, what _is_ the architecture of your complete system?
>
> There is only one component communicating with the kalman filter, namely
> the estimator component.

Strange, since the Kalman Filter _is_ an estimator...

> Note that the EKF is not a orocos-component,
> but just a C++ class, on which the estimator-component is calling
> functions.

And where does the EKF class resides? It must be in some "component", isn't
it?

> I could integrate this code in the estimator component, but I
> don't think this would change much?

I think it will change everything :-)

> In the estimator component, in the updateHook, I thus do the process
> update. The measurements are coming from another component, which puts
> them on a Data port. My estimator component connects with this port, and
> I have coupled an event to this port, which performs the measurement
> update with the data on this port.

Fine! And what about the process update? Can't you do that in the same way?
(That is, via a time-triggered data port.)
And isn't your KF C++ class then "running" de facto inside of the estimator
component?

Herman

>>> Op 31/07/2011 20:13, S Roderick schreef:
>>>> On Jul 31, 2011, at 07:47 , Herman Bruyninckx wrote:
>>>>
>>>>> On Sun, 31 Jul 2011, Peter Soetens wrote:
>>>>>
>>>>>> On Fri, Jul 29, 2011 at 4:15 PM, Kurt Geebelen
>>>>>> <kurt [dot] geebelen [..] ...> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have a component that is running a kalman filter, which has 2 main
>>>>>>> functions: propagate and update. I periodically propagate my kalman
>>>>>>> filter, and I update my kalman filter event-driven when data comes
>>>>>>> available on a port.
>>>>>>>
>>>>>>> I sometimes get a segmentation fault when running this component. I
>>>>>>> noticed that this is due to the problem that sometimes, while my
>>>>>>> component is performing the propagation, new data becomes available on a
>>>>>>> port, and the component will attempt to update the kalman filter while
>>>>>>> performing the propagation. I tried solving it by setting some booleans
>>>>>>> while doing the propagate/update. So something like this:
>>>>>>>
>>>>>>> For propagating:
>>>>>>>
>>>>>>> 

>>>>>>> while(updating){}
>>>>>>> propagating=true;
>>>>>>> propagate();
>>>>>>> propagating=false;
>>>>>>>

>>>>>> Change to:
>>>>>>
>>>>>> 
>>>>>> {
>>>>>>    os::MutexLock lock(m);
>>>>>>    propagate();
>>>>>> } // note these curly braces, they must be here !
>>>>>>

>>>>>>
>>>>>>> And for updating:
>>>>>>>
>>>>>>> 
>>>>>>> while(propagating){}
>>>>>>> updating=true;
>>>>>>> update();
>>>>>>> updating=false;
>>>>>>>

>>>>>> change to:
>>>>>>
>>>>>> 
>>>>>> {
>>>>>>    os::MutexLock lock(m);
>>>>>>    update();
>>>>>> } // note these curly braces, they must be here !
>>>>>>

>>>>>>
>>>>> Please, don't invite users to start introducing explicit locks in their
>>>>> applications! This brings us back to the times _before_ Orocos/RTT existed,
>>>>> and to the reasons _why_ it was developed: to shield users from these ugly,
>>>>> low-level, error-prone OS primitives. It is obvious that locks have _no_
>>>>> place in a real component based application, by definition almost.
>>>>>
>>>>> I am 100% sure Kurt's problem can be neatly solved with appropriate design
>>>>> of his application using the core primitives of RTT, namely Ports and
>>>>> simple Coordination with a state machine.
>>>>>
>>>>> In addition to providing good software, Orocos also has an educational
>>>>> vocation, and that is to stimulate best practice software engineering into
>>>>> the mechatronics and robotics communities...
>>>> True, but sometimes you need something to work first, before you make it correct. Peter's suggestion will fix his immediate needs _and_ we need to educate Kurt that this isn't the best approach and that he should consider doing it another way.
>>>> S
>>>>
>> --
>> K.U.Leuven, Mechanical Eng., Mechatronics& Robotics Research Group
>> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
>> EURON Coordinator (European Robotics Research Network)<http://www.euron.org>
>> Open Realtime Control Services<http://www.orocos.org>
>> Associate Editor JOSER<http://www.joser.org>, IJRR<http://www.ijrr.org>
>

--
K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
EURON Coordinator (European Robotics Research Network) <http://www.euron.org>
Open Realtime Control Services <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>

»

prevent function from executing when other is executing

Submitted by willy on Wed, 2011-08-10 09:16.

2011/8/1 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>

> On Mon, 1 Aug 2011, Kurt Geebelen wrote:
>
> > Op 1/08/2011 10:00, Herman Bruyninckx schreef:
> >> On Mon, 1 Aug 2011, Kurt Geebelen wrote:
> >>
> >>> Hi,
> >> (Please do not top post<http://en.wikipedia.org/wiki/Top_posting>)
> >
> > Sorry
> >
> >>
> >>> I have written a C+-class for the kalman filter, which has the 2
> >>> functions propagate and update (I didn't use the ExtendedKalmanFilter
> >>> class of the BLF-library because this way it was more clear to me what
> >>> was happening).
> >> Oops... What is not clear with the way the BFL integrates an EKF into
> >> Orocos?
> >> E.g.<http://comments.gmane.org/gmane.science.robotics.orocos.devel/8457
> >
> >
> > Nothing is wrong with it. I just thought it would be a better exercise
> > to implement it myself.
>
> That turns out to be true :-) There is no better schooling than to repeat
> the errors one _has_ to make before being able to appreciate better
> practice solutions :-)
>
> >>> The variables that are changed in both functions are the
> >>> covariance matrix and the state of the kalman filter. They are of type
> >>> Matrix of the Newmat library I am using
> >>> (http://www.robertnz.net/nm10.htm). The elements of these matrices are
> >>> of type double.
> >>>
> >>> My estimator component than creates an instance of this kalman filter
> >>> class, periodically propagates it (apply system model), and whenever a
> >>> measurement becomes available, updates the kalman filter with this
> >>> measurement. This is thus where it sometimes goes wrong, when these
> >>> functions coincide.
> >> Exactly. But they should not "coincide" :-) I mean, the component that
> >> contains the (E)KF code should run the process update and measurement
> >> update 'atomically', which could be realised by letting it read from
> Data
> >> ports (one for new timer data, one for new measurement data).
> >>
> >> I have the impression you have another design, in which you call an
> >> operation on the EKF component from two other components, and in this
> way
> >> it becomes very difficult for the EKF component to guarantee data
> >> consistency...
> >>
> >> Is my assumption about your architecture correct or not?
> >> In other words, what _is_ the architecture of your complete system?
> >
> > There is only one component communicating with the kalman filter, namely
> > the estimator component.
>
> Strange, since the Kalman Filter _is_ an estimator...
>
> > Note that the EKF is not a orocos-component,
> > but just a C++ class, on which the estimator-component is calling
> > functions.
>
> And where does the EKF class resides? It must be in some "component", isn't
> it?
>
> > I could integrate this code in the estimator component, but I
> > don't think this would change much?
>
> I think it will change everything :-)
>

Keeping your logic out of components is a nice practice because it separates
your working code from the "glue code" that integrates it into your
framework (here in an Orocos Component). I think Herman wants to say that
your problem is where the object is instanciated from your class (expecting
you don't have static variables).

>
> > In the estimator component, in the updateHook, I thus do the process
> > update. The measurements are coming from another component, which puts
> > them on a Data port. My estimator component connects with this port, and
> > I have coupled an event to this port, which performs the measurement
> > update with the data on this port.
>
> Fine! And what about the process update? Can't you do that in the same way?
> (That is, via a time-triggered data port.)
> And isn't your KF C++ class then "running" de facto inside of the estimator
> component?
>
> Herman
>
> >>> Op 31/07/2011 20:13, S Roderick schreef:
> >>>> On Jul 31, 2011, at 07:47 , Herman Bruyninckx wrote:
> >>>>
> >>>>> On Sun, 31 Jul 2011, Peter Soetens wrote:
> >>>>>
> >>>>>> On Fri, Jul 29, 2011 at 4:15 PM, Kurt Geebelen
> >>>>>> <kurt [dot] geebelen [..] ...> wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> I have a component that is running a kalman filter, which has 2
> main
> >>>>>>> functions: propagate and update. I periodically propagate my kalman
> >>>>>>> filter, and I update my kalman filter event-driven when data comes
> >>>>>>> available on a port.
> >>>>>>>
> >>>>>>> I sometimes get a segmentation fault when running this component. I
> >>>>>>> noticed that this is due to the problem that sometimes, while my
> >>>>>>> component is performing the propagation, new data becomes available
> on a
> >>>>>>> port, and the component will attempt to update the kalman filter
> while
> >>>>>>> performing the propagation. I tried solving it by setting some
> booleans
> >>>>>>> while doing the propagate/update. So something like this:
> >>>>>>>
> >>>>>>> For propagating:
> >>>>>>>
> >>>>>>> 

> >>>>>>> while(updating){}
> >>>>>>> propagating=true;
> >>>>>>> propagate();
> >>>>>>> propagating=false;
> >>>>>>>

> >>>>>> Change to:
> >>>>>>
> >>>>>> 
> >>>>>> {
> >>>>>>    os::MutexLock lock(m);
> >>>>>>    propagate();
> >>>>>> } // note these curly braces, they must be here !
> >>>>>>

> >>>>>>
> >>>>>>> And for updating:
> >>>>>>>
> >>>>>>> 
> >>>>>>> while(propagating){}
> >>>>>>> updating=true;
> >>>>>>> update();
> >>>>>>> updating=false;
> >>>>>>>

> >>>>>> change to:
> >>>>>>
> >>>>>> 
> >>>>>> {
> >>>>>>    os::MutexLock lock(m);
> >>>>>>    update();
> >>>>>> } // note these curly braces, they must be here !
> >>>>>>

> >>>>>>
> >>>>> Please, don't invite users to start introducing explicit locks in
> their
> >>>>> applications! This brings us back to the times _before_ Orocos/RTT
> existed,
> >>>>> and to the reasons _why_ it was developed: to shield users from these
> ugly,
> >>>>> low-level, error-prone OS primitives. It is obvious that locks have
> _no_
> >>>>> place in a real component based application, by definition almost.
> >>>>>
> >>>>> I am 100% sure Kurt's problem can be neatly solved with appropriate
> design
> >>>>> of his application using the core primitives of RTT, namely Ports and
> >>>>> simple Coordination with a state machine.
> >>>>>
> >>>>> In addition to providing good software, Orocos also has an
> educational
> >>>>> vocation, and that is to stimulate best practice software engineering
> into
> >>>>> the mechatronics and robotics communities...
> >>>> True, but sometimes you need something to work first, before you make
> it correct. Peter's suggestion will fix his immediate needs _and_ we need to
> educate Kurt that this isn't the best approach and that he should consider
> doing it another way.
> >>>> S
> >>>>
> >> --
> >> K.U.Leuven, Mechanical Eng., Mechatronics& Robotics Research Group
> >> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> >> EURON Coordinator (European Robotics Research Network)<
> http://www.euron.org>
> >> Open Realtime Control Services<http://www.orocos.org>
> >> Associate Editor JOSER<http://www.joser.org>, IJRR<
> http://www.ijrr.org>
> >
>
> --
> K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> EURON Coordinator (European Robotics Research Network) <
> http://www.euron.org>
> Open Realtime Control Services <http://www.orocos.org>
> Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org
> >
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

»

prevent function from executing when other is executing

Submitted by Kurt Geebelen on Mon, 2011-08-01 09:04.

Op 1/08/2011 10:37, Herman Bruyninckx schreef:
> On Mon, 1 Aug 2011, Kurt Geebelen wrote:
>
>> Op 1/08/2011 10:00, Herman Bruyninckx schreef:
>>> On Mon, 1 Aug 2011, Kurt Geebelen wrote:
>>>
>>>> Hi,
>>> (Please do not top post<http://en.wikipedia.org/wiki/Top_posting>)
>> Sorry
>>
>>>> I have written a C+-class for the kalman filter, which has the 2
>>>> functions propagate and update (I didn't use the ExtendedKalmanFilter
>>>> class of the BLF-library because this way it was more clear to me what
>>>> was happening).
>>> Oops... What is not clear with the way the BFL integrates an EKF into
>>> Orocos?
>>> E.g.<http://comments.gmane.org/gmane.science.robotics.orocos.devel/8457>
>> Nothing is wrong with it. I just thought it would be a better exercise
>> to implement it myself.
> That turns out to be true :-) There is no better schooling than to repeat
> the errors one _has_ to make before being able to appreciate better
> practice solutions :-)
>
>>>> The variables that are changed in both functions are the
>>>> covariance matrix and the state of the kalman filter. They are of type
>>>> Matrix of the Newmat library I am using
>>>> (http://www.robertnz.net/nm10.htm). The elements of these matrices are
>>>> of type double.
>>>>
>>>> My estimator component than creates an instance of this kalman filter
>>>> class, periodically propagates it (apply system model), and whenever a
>>>> measurement becomes available, updates the kalman filter with this
>>>> measurement. This is thus where it sometimes goes wrong, when these
>>>> functions coincide.
>>> Exactly. But they should not "coincide" :-) I mean, the component that
>>> contains the (E)KF code should run the process update and measurement
>>> update 'atomically', which could be realised by letting it read from Data
>>> ports (one for new timer data, one for new measurement data).
>>>
>>> I have the impression you have another design, in which you call an
>>> operation on the EKF component from two other components, and in this way
>>> it becomes very difficult for the EKF component to guarantee data
>>> consistency...
>>>
>>> Is my assumption about your architecture correct or not?
>>> In other words, what _is_ the architecture of your complete system?
>> There is only one component communicating with the kalman filter, namely
>> the estimator component.
> Strange, since the Kalman Filter _is_ an estimator...
>
>> Note that the EKF is not a orocos-component,
>> but just a C++ class, on which the estimator-component is calling
>> functions.
> And where does the EKF class resides? It must be in some "component", isn't
> it?
>
>> I could integrate this code in the estimator component, but I
>> don't think this would change much?
> I think it will change everything :-)
>
>> In the estimator component, in the updateHook, I thus do the process
>> update. The measurements are coming from another component, which puts
>> them on a Data port. My estimator component connects with this port, and
>> I have coupled an event to this port, which performs the measurement
>> update with the data on this port.
> Fine! And what about the process update? Can't you do that in the same way?
> (That is, via a time-triggered data port.)

I can do that. But won't this still give the same problems when this
coincides with the measurement update?

> And isn't your KF C++ class then "running" de facto inside of the estimator
> component?

Yes it is. That's why I thought moving it directly in the estimator
component wouldn't change that much.

>
> Herman

Kurt

>
>>>> Op 31/07/2011 20:13, S Roderick schreef:
>>>>> On Jul 31, 2011, at 07:47 , Herman Bruyninckx wrote:
>>>>>
>>>>>> On Sun, 31 Jul 2011, Peter Soetens wrote:
>>>>>>
>>>>>>> On Fri, Jul 29, 2011 at 4:15 PM, Kurt Geebelen
>>>>>>> <kurt [dot] geebelen [..] ...> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I have a component that is running a kalman filter, which has 2 main
>>>>>>>> functions: propagate and update. I periodically propagate my kalman
>>>>>>>> filter, and I update my kalman filter event-driven when data comes
>>>>>>>> available on a port.
>>>>>>>>
>>>>>>>> I sometimes get a segmentation fault when running this component. I
>>>>>>>> noticed that this is due to the problem that sometimes, while my
>>>>>>>> component is performing the propagation, new data becomes available on a
>>>>>>>> port, and the component will attempt to update the kalman filter while
>>>>>>>> performing the propagation. I tried solving it by setting some booleans
>>>>>>>> while doing the propagate/update. So something like this:
>>>>>>>>
>>>>>>>> For propagating:
>>>>>>>>
>>>>>>>> 

>>>>>>>> while(updating){}
>>>>>>>> propagating=true;
>>>>>>>> propagate();
>>>>>>>> propagating=false;
>>>>>>>>

>>>>>>> Change to:
>>>>>>>
>>>>>>> 
>>>>>>> {
>>>>>>>     os::MutexLock lock(m);
>>>>>>>     propagate();
>>>>>>> } // note these curly braces, they must be here !
>>>>>>>

>>>>>>>
>>>>>>>> And for updating:
>>>>>>>>
>>>>>>>> 
>>>>>>>> while(propagating){}
>>>>>>>> updating=true;
>>>>>>>> update();
>>>>>>>> updating=false;
>>>>>>>>

>>>>>>> change to:
>>>>>>>
>>>>>>> 
>>>>>>> {
>>>>>>>     os::MutexLock lock(m);
>>>>>>>     update();
>>>>>>> } // note these curly braces, they must be here !
>>>>>>>

>>>>>>>
>>>>>> Please, don't invite users to start introducing explicit locks in their
>>>>>> applications! This brings us back to the times _before_ Orocos/RTT existed,
>>>>>> and to the reasons _why_ it was developed: to shield users from these ugly,
>>>>>> low-level, error-prone OS primitives. It is obvious that locks have _no_
>>>>>> place in a real component based application, by definition almost.
>>>>>>
>>>>>> I am 100% sure Kurt's problem can be neatly solved with appropriate design
>>>>>> of his application using the core primitives of RTT, namely Ports and
>>>>>> simple Coordination with a state machine.
>>>>>>
>>>>>> In addition to providing good software, Orocos also has an educational
>>>>>> vocation, and that is to stimulate best practice software engineering into
>>>>>> the mechatronics and robotics communities...
>>>>> True, but sometimes you need something to work first, before you make it correct. Peter's suggestion will fix his immediate needs _and_ we need to educate Kurt that this isn't the best approach and that he should consider doing it another way.
>>>>> S
>>>>>
>>> --
>>> K.U.Leuven, Mechanical Eng., Mechatronics& Robotics Research Group
>>> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
>>> EURON Coordinator (European Robotics Research Network)<http://www.euron.org>
>>> Open Realtime Control Services<http://www.orocos.org>
>>> Associate Editor JOSER<http://www.joser.org>, IJRR<http://www.ijrr.org>
> --
> K.U.Leuven, Mechanical Eng., Mechatronics& Robotics Research Group
> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> EURON Coordinator (European Robotics Research Network)<http://www.euron.org>
> Open Realtime Control Services<http://www.orocos.org>
> Associate Editor JOSER<http://www.joser.org>, IJRR<http://www.ijrr.org>

»

prevent function from executing when other is executing

Submitted by bruyninc on Mon, 2011-08-01 09:28.

On Mon, 1 Aug 2011, Kurt Geebelen wrote:

> Op 1/08/2011 10:37, Herman Bruyninckx schreef:
>> On Mon, 1 Aug 2011, Kurt Geebelen wrote:
>>
>>> Op 1/08/2011 10:00, Herman Bruyninckx schreef:
>>>> On Mon, 1 Aug 2011, Kurt Geebelen wrote:
>>>>
>>>>> Hi,
>>>> (Please do not top post<http://en.wikipedia.org/wiki/Top_posting>)
>>> Sorry
>>>
>>>>> I have written a C+-class for the kalman filter, which has the 2
>>>>> functions propagate and update (I didn't use the ExtendedKalmanFilter
>>>>> class of the BLF-library because this way it was more clear to me what
>>>>> was happening).
>>>> Oops... What is not clear with the way the BFL integrates an EKF into
>>>> Orocos?
>>>> E.g.<http://comments.gmane.org/gmane.science.robotics.orocos.devel/8457>
>>> Nothing is wrong with it. I just thought it would be a better exercise
>>> to implement it myself.
>> That turns out to be true :-) There is no better schooling than to repeat
>> the errors one _has_ to make before being able to appreciate better
>> practice solutions :-)
>>
>>>>> The variables that are changed in both functions are the
>>>>> covariance matrix and the state of the kalman filter. They are of type
>>>>> Matrix of the Newmat library I am using
>>>>> (http://www.robertnz.net/nm10.htm). The elements of these matrices are
>>>>> of type double.
>>>>>
>>>>> My estimator component than creates an instance of this kalman filter
>>>>> class, periodically propagates it (apply system model), and whenever a
>>>>> measurement becomes available, updates the kalman filter with this
>>>>> measurement. This is thus where it sometimes goes wrong, when these
>>>>> functions coincide.
>>>> Exactly. But they should not "coincide" :-) I mean, the component that
>>>> contains the (E)KF code should run the process update and measurement
>>>> update 'atomically', which could be realised by letting it read from Data
>>>> ports (one for new timer data, one for new measurement data).
>>>>
>>>> I have the impression you have another design, in which you call an
>>>> operation on the EKF component from two other components, and in this way
>>>> it becomes very difficult for the EKF component to guarantee data
>>>> consistency...
>>>>
>>>> Is my assumption about your architecture correct or not?
>>>> In other words, what _is_ the architecture of your complete system?
>>> There is only one component communicating with the kalman filter, namely
>>> the estimator component.
>> Strange, since the Kalman Filter _is_ an estimator...
>>
>>> Note that the EKF is not a orocos-component,
>>> but just a C++ class, on which the estimator-component is calling
>>> functions.
>> And where does the EKF class resides? It must be in some "component", isn't
>> it?
>>
>>> I could integrate this code in the estimator component, but I
>>> don't think this would change much?
>> I think it will change everything :-)
>>
>>> In the estimator component, in the updateHook, I thus do the process
>>> update. The measurements are coming from another component, which puts
>>> them on a Data port. My estimator component connects with this port, and
>>> I have coupled an event to this port, which performs the measurement
>>> update with the data on this port.
>> Fine! And what about the process update? Can't you do that in the same way?
>> (That is, via a time-triggered data port.)
>
> I can do that. But won't this still give the same problems when this
> coincides with the measurement update?

The component's TaskContext will 'serialize' the handling of the arrival of
data on the Ports. That's a major feature of RTT: no need to do locking
yourself anymore :-) The design problems are hence moved towards finding
the "best" component architecture and configuration of the individual
components.

>> And isn't your KF C++ class then "running" de facto inside of the estimator
>> component?
>
> Yes it is. That's why I thought moving it directly in the estimator
> component wouldn't change that much.

You are not "moving" anything :-) The compiler links your library to the
code that is being deployed inside your estimator component, so it _is_
already there :-)

Herman

>>>>> Op 31/07/2011 20:13, S Roderick schreef:
>>>>>> On Jul 31, 2011, at 07:47 , Herman Bruyninckx wrote:
>>>>>>
>>>>>>> On Sun, 31 Jul 2011, Peter Soetens wrote:
>>>>>>>
>>>>>>>> On Fri, Jul 29, 2011 at 4:15 PM, Kurt Geebelen
>>>>>>>> <kurt [dot] geebelen [..] ...> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I have a component that is running a kalman filter, which has 2 main
>>>>>>>>> functions: propagate and update. I periodically propagate my kalman
>>>>>>>>> filter, and I update my kalman filter event-driven when data comes
>>>>>>>>> available on a port.
>>>>>>>>>
>>>>>>>>> I sometimes get a segmentation fault when running this component. I
>>>>>>>>> noticed that this is due to the problem that sometimes, while my
>>>>>>>>> component is performing the propagation, new data becomes available on a
>>>>>>>>> port, and the component will attempt to update the kalman filter while
>>>>>>>>> performing the propagation. I tried solving it by setting some booleans
>>>>>>>>> while doing the propagate/update. So something like this:
>>>>>>>>>
>>>>>>>>> For propagating:
>>>>>>>>>
>>>>>>>>> 

>>>>>>>>> while(updating){}
>>>>>>>>> propagating=true;
>>>>>>>>> propagate();
>>>>>>>>> propagating=false;
>>>>>>>>>

>>>>>>>> Change to:
>>>>>>>>
>>>>>>>> 
>>>>>>>> {
>>>>>>>>     os::MutexLock lock(m);
>>>>>>>>     propagate();
>>>>>>>> } // note these curly braces, they must be here !
>>>>>>>>

>>>>>>>>
>>>>>>>>> And for updating:
>>>>>>>>>
>>>>>>>>> 
>>>>>>>>> while(propagating){}
>>>>>>>>> updating=true;
>>>>>>>>> update();
>>>>>>>>> updating=false;
>>>>>>>>>

>>>>>>>> change to:
>>>>>>>>
>>>>>>>> 
>>>>>>>> {
>>>>>>>>     os::MutexLock lock(m);
>>>>>>>>     update();
>>>>>>>> } // note these curly braces, they must be here !
>>>>>>>>

>>>>>>>>
>>>>>>> Please, don't invite users to start introducing explicit locks in their
>>>>>>> applications! This brings us back to the times _before_ Orocos/RTT existed,
>>>>>>> and to the reasons _why_ it was developed: to shield users from these ugly,
>>>>>>> low-level, error-prone OS primitives. It is obvious that locks have _no_
>>>>>>> place in a real component based application, by definition almost.
>>>>>>>
>>>>>>> I am 100% sure Kurt's problem can be neatly solved with appropriate design
>>>>>>> of his application using the core primitives of RTT, namely Ports and
>>>>>>> simple Coordination with a state machine.
>>>>>>>
>>>>>>> In addition to providing good software, Orocos also has an educational
>>>>>>> vocation, and that is to stimulate best practice software engineering into
>>>>>>> the mechatronics and robotics communities...
>>>>>> True, but sometimes you need something to work first, before you make it correct. Peter's suggestion will fix his immediate needs _and_ we need to educate Kurt that this isn't the best approach and that he should consider doing it another way.
>>>>>> S
>>>>>>
>>>> --
>>>> K.U.Leuven, Mechanical Eng., Mechatronics& Robotics Research Group
>>>> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
>>>> EURON Coordinator (European Robotics Research Network)<http://www.euron.org>
>>>> Open Realtime Control Services<http://www.orocos.org>
>>>> Associate Editor JOSER<http://www.joser.org>, IJRR<http://www.ijrr.org>
>> --
>> K.U.Leuven, Mechanical Eng., Mechatronics& Robotics Research Group
>> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
>> EURON Coordinator (European Robotics Research Network)<http://www.euron.org>
>> Open Realtime Control Services<http://www.orocos.org>
>> Associate Editor JOSER<http://www.joser.org>, IJRR<http://www.ijrr.org>
>

--
K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
EURON Coordinator (European Robotics Research Network) <http://www.euron.org>
Open Realtime Control Services <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>

»

prevent function from executing when other is executing

Submitted by Tinne De Laet on Tue, 2011-08-16 09:12.

--Boundary-01=_xgQROL2C+9IVlJ2
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

On Monday 01 August 2011 11:26:28 Herman Bruyninckx wrote:
> On Mon, 1 Aug 2011, Kurt Geebelen wrote:
> > Op 1/08/2011 10:37, Herman Bruyninckx schreef:
> >> On Mon, 1 Aug 2011, Kurt Geebelen wrote:
> >>> Op 1/08/2011 10:00, Herman Bruyninckx schreef:
> >>>> On Mon, 1 Aug 2011, Kurt Geebelen wrote:
> >>>>> Hi,
> >>>>
> >>>> (Please do not top post<http://en.wikipedia.org/wiki/Top_posting>)
> >>>
> >>> Sorry
> >>>
> >>>>> I have written a C+-class for the kalman filter, which has the 2
> >>>>> functions propagate and update (I didn't use the ExtendedKalmanFilter
> >>>>> class of the BLF-library because this way it was more clear to me
> >>>>> what was happening).
> >>>>
> >>>> Oops... What is not clear with the way the BFL integrates an EKF into
> >>>> Orocos?
> >>>> E.g.<http://comments.gmane.org/gmane.science.robotics.orocos.devel/845
> >>>> 7>
> >>>
> >>> Nothing is wrong with it. I just thought it would be a better exercise
> >>> to implement it myself.
> >>
> >> That turns out to be true :-) There is no better schooling than to
> >> repeat the errors one _has_ to make before being able to appreciate
> >> better practice solutions :-)
> >>
> >>>>> The variables that are changed in both functions are the
> >>>>> covariance matrix and the state of the kalman filter. They are of
> >>>>> type Matrix of the Newmat library I am using
> >>>>> (http://www.robertnz.net/nm10.htm). The elements of these matrices
> >>>>> are of type double.
> >>>>>
> >>>>> My estimator component than creates an instance of this kalman filter
> >>>>> class, periodically propagates it (apply system model), and whenever
> >>>>> a measurement becomes available, updates the kalman filter with this
> >>>>> measurement. This is thus where it sometimes goes wrong, when these
> >>>>> functions coincide.
> >>>>
> >>>> Exactly. But they should not "coincide" :-) I mean, the component that
> >>>> contains the (E)KF code should run the process update and measurement
> >>>> update 'atomically', which could be realised by letting it read from
> >>>> Data ports (one for new timer data, one for new measurement data).
> >>>>
> >>>> I have the impression you have another design, in which you call an
> >>>> operation on the EKF component from two other components, and in this
> >>>> way it becomes very difficult for the EKF component to guarantee data
> >>>> consistency...
> >>>>
> >>>> Is my assumption about your architecture correct or not?
> >>>> In other words, what _is_ the architecture of your complete system?
> >>>
> >>> There is only one component communicating with the kalman filter,
> >>> namely the estimator component.
> >>
> >> Strange, since the Kalman Filter _is_ an estimator...
> >>
> >>> Note that the EKF is not a orocos-component,
> >>> but just a C++ class, on which the estimator-component is calling
> >>> functions.
> >>
> >> And where does the EKF class resides? It must be in some "component",
> >> isn't it?
> >>
> >>> I could integrate this code in the estimator component, but I
> >>> don't think this would change much?
> >>
> >> I think it will change everything :-)
> >>
> >>> In the estimator component, in the updateHook, I thus do the process
> >>> update. The measurements are coming from another component, which puts
> >>> them on a Data port. My estimator component connects with this port,
> >>> and I have coupled an event to this port, which performs the
> >>> measurement update with the data on this port.
> >>
> >> Fine! And what about the process update? Can't you do that in the same
> >> way? (That is, via a time-triggered data port.)
> >
> > I can do that. But won't this still give the same problems when this
> > coincides with the measurement update?
>
> The component's TaskContext will 'serialize' the handling of the arrival of
> data on the Ports. That's a major feature of RTT: no need to do locking
> yourself anymore :-) The design problems are hence moved towards finding
> the "best" component architecture and configuration of the individual
> components.

Indeed!

I have been working with filter-components for a long time and I suggest the
following construction
* create an sysUpdate function and a measUpdate function
* run your component non periodically
* have the sysUpdate triggered periodically trough an eventPort triggered by a
timer component
* have the measUpdate triggered by the measurement port.

You can find an example of such a component at
http://git.mech.kuleuven.be/?p=robotics/camera_pose_estimation.git;a=sum...

If you need any extra explanation I will be glad to help you.

Tinne

>
> >> And isn't your KF C++ class then "running" de facto inside of the
> >> estimator component?
> >
> > Yes it is. That's why I thought moving it directly in the estimator
> > component wouldn't change that much.
>
> You are not "moving" anything :-) The compiler links your library to the
> code that is being deployed inside your estimator component, so it _is_
> already there :-)
>
> Herman
>
> >>>>> Op 31/07/2011 20:13, S Roderick schreef:
> >>>>>> On Jul 31, 2011, at 07:47 , Herman Bruyninckx wrote:
> >>>>>>> On Sun, 31 Jul 2011, Peter Soetens wrote:
> >>>>>>>> On Fri, Jul 29, 2011 at 4:15 PM, Kurt Geebelen
> >>>>>>>>
> >>>>>>>> <kurt [dot] geebelen [..] ...> wrote:
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> I have a component that is running a kalman filter, which has 2
> >>>>>>>>> main functions: propagate and update. I periodically propagate
> >>>>>>>>> my kalman filter, and I update my kalman filter event-driven
> >>>>>>>>> when data comes available on a port.
> >>>>>>>>>
> >>>>>>>>> I sometimes get a segmentation fault when running this component.
> >>>>>>>>> I noticed that this is due to the problem that sometimes, while
> >>>>>>>>> my component is performing the propagation, new data becomes
> >>>>>>>>> available on a port, and the component will attempt to update
> >>>>>>>>> the kalman filter while performing the propagation. I tried
> >>>>>>>>> solving it by setting some booleans while doing the
> >>>>>>>>> propagate/update. So something like this:
> >>>>>>>>>
> >>>>>>>>> For propagating:
> >>>>>>>>>
> >>>>>>>>> 

> >>>>>>>>> while(updating){}
> >>>>>>>>> propagating=true;
> >>>>>>>>> propagate();
> >>>>>>>>> propagating=false;
> >>>>>>>>>

> >>>>>>>>
> >>>>>>>> Change to:
> >>>>>>>>
> >>>>>>>> 
> >>>>>>>> {
> >>>>>>>> 
> >>>>>>>>     os::MutexLock lock(m);
> >>>>>>>>     propagate();
> >>>>>>>> 
> >>>>>>>> } // note these curly braces, they must be here !
> >>>>>>>>

> >>>>>>>>
> >>>>>>>>> And for updating:
> >>>>>>>>>
> >>>>>>>>> 
> >>>>>>>>> while(propagating){}
> >>>>>>>>> updating=true;
> >>>>>>>>> update();
> >>>>>>>>> updating=false;
> >>>>>>>>>

> >>>>>>>>
> >>>>>>>> change to:
> >>>>>>>>
> >>>>>>>> 
> >>>>>>>> {
> >>>>>>>> 
> >>>>>>>>     os::MutexLock lock(m);
> >>>>>>>>     update();
> >>>>>>>> 
> >>>>>>>> } // note these curly braces, they must be here !
> >>>>>>>>

> >>>>>>>
> >>>>>>> Please, don't invite users to start introducing explicit locks in
> >>>>>>> their applications! This brings us back to the times _before_
> >>>>>>> Orocos/RTT existed, and to the reasons _why_ it was developed: to
> >>>>>>> shield users from these ugly, low-level, error-prone OS
> >>>>>>> primitives. It is obvious that locks have _no_ place in a real
> >>>>>>> component based application, by definition almost.
> >>>>>>>
> >>>>>>> I am 100% sure Kurt's problem can be neatly solved with appropriate
> >>>>>>> design of his application using the core primitives of RTT, namely
> >>>>>>> Ports and simple Coordination with a state machine.
> >>>>>>>
> >>>>>>> In addition to providing good software, Orocos also has an
> >>>>>>> educational vocation, and that is to stimulate best practice
> >>>>>>> software engineering into the mechatronics and robotics
> >>>>>>> communities...
> >>>>>>
> >>>>>> True, but sometimes you need something to work first, before you
> >>>>>> make it correct. Peter's suggestion will fix his immediate needs
> >>>>>> _and_ we need to educate Kurt that this isn't the best approach and
> >>>>>> that he should consider doing it another way. S
> >>>>
> >>>> --
> >>>>
> >>>> K.U.Leuven, Mechanical Eng., Mechatronics& Robotics Research
> >>>> Group
> >>>>
> >>>> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> >>>>
> >>>> EURON Coordinator (European Robotics Research
> >>>> Network)<http://www.euron.org> Open Realtime Control
> >>>> Services<http://www.orocos.org>
> >>>> Associate Editor JOSER<http://www.joser.org>,
> >>>> IJRR<http://www.ijrr.org>
> >>
> >> --
> >>
> >> K.U.Leuven, Mechanical Eng., Mechatronics& Robotics Research Group
> >>
> >> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> >>
> >> EURON Coordinator (European Robotics Research
> >> Network)<http://www.euron.org> Open Realtime Control
> >> Services<http://www.orocos.org>
> >> Associate Editor JOSER<http://www.joser.org>,
> >> IJRR<http://www.ijrr.org>
>
> --
> K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> EURON Coordinator (European Robotics Research Network)
> <http://www.euron.org> Open Realtime Control Services
> <http://www.orocos.org>
> Associate Editor JOSER <http://www.joser.org>, IJRR
> <http://www.ijrr.org>

--Boundary-01=_xgQROL2C+9IVlJ2
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

&lt;!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"&gt;
<html><head><meta name="qrichtext" content="1" /><style type="text/css">
p, li { white-space: pre-wrap; }
<style><head><body style=" font-family:'Monospace'; font-size:9pt; font-weight:400; font-style:normal;">

On Monday 01 August 2011 11:26:28 Herman Bruyninckx wrote:

> On Mon, 1 Aug 2011, Kurt Geebelen wrote:

> > Op 1/08/2011 10:37, Herman Bruyninckx schreef:

> >> On Mon, 1 Aug 2011, Kurt Geebelen wrote:

> >>> Op 1/08/2011 10:00, Herman Bruyninckx schreef:

> >>>> On Mon, 1 Aug 2011, Kurt Geebelen wrote:

> >>>>> Hi,

> >>>>

> >>>> (Please do not top post<http://en.wikipedia.org/wiki/Top_posting>)

> >>>

> >>> Sorry

> >>>

> >>>>> I have written a C+-class for the kalman filter, which has the 2

> >>>>> functions propagate and update (I didn't use the ExtendedKalmanFilter

> >>>>> class of the BLF-library because this way it was more clear to me

> >>>>> what was happening).

> >>>>

> >>>> Oops... What is not clear with the way the BFL integrates an EKF into

> >>>> Orocos?

> >>>> E.g.<http://comments.gmane.org/gmane.science.robotics.orocos.devel/845

> >>>> 7>

> >>>

> >>> Nothing is wrong with it. I just thought it would be a better exercise

> >>> to implement it myself.

> >>

> >> That turns out to be true :-) There is no better schooling than to

> >> repeat the errors one _has_ to make before being able to appreciate

> >> better practice solutions :-)

> >>

> >>>>> The variables that are changed in both functions are the

> >>>>> covariance matrix and the state of the kalman filter. They are of

> >>>>> type Matrix of the Newmat library I am using

> >>>>> (http://www.robertnz.net/nm10.htm). The elements of these matrices

> >>>>> are of type double.

> >>>>>

> >>>>> My estimator component than creates an instance of this kalman filter

> >>>>> class, periodically propagates it (apply system model), and whenever

> >>>>> a measurement becomes available, updates the kalman filter with this

> >>>>> measurement. This is thus where it sometimes goes wrong, when these

> >>>>> functions coincide.

> >>>>

> >>>> Exactly. But they should not "coincide" :-) I mean, the component that

> >>>> contains the (E)KF code should run the process update and measurement

> >>>> update 'atomically', which could be realised by letting it read from

> >>>> Data ports (one for new timer data, one for new measurement data).

> >>>>

> >>>> I have the impression you have another design, in which you call an

> >>>> operation on the EKF component from two other components, and in this

> >>>> way it becomes very difficult for the EKF component to guarantee data

> >>>> consistency...

> >>>>

> >>>> Is my assumption about your architecture correct or not?

> >>>> In other words, what _is_ the architecture of your complete system?

> >>>

> >>> There is only one component communicating with the kalman filter,

> >>> namely the estimator component.

> >>

> >> Strange, since the Kalman Filter _is_ an estimator...

> >>

> >>> Note that the EKF is not a orocos-component,

> >>> but just a C++ class, on which the estimator-component is calling

> >>> functions.

> >>

> >> And where does the EKF class resides? It must be in some "component",

> >> isn't it?

> >>

> >>> I could integrate this code in the estimator component, but I

> >>> don't think this would change much?

> >>

> >> I think it will change everything :-)

> >>

> >>> In the estimator component, in the updateHook, I thus do the process

> >>> update. The measurements are coming from another component, which puts

> >>> them on a Data port. My estimator component connects with this port,

> >>> and I have coupled an event to this port, which performs the

> >>> measurement update with the data on this port.

> >>

> >> Fine! And what about the process update? Can't you do that in the same

> >> way? (That is, via a time-triggered data port.)

> >

> > I can do that. But won't this still give the same problems when this

> > coincides with the measurement update?

>

> The component's TaskContext will 'serialize' the handling of the arrival of

> data on the Ports. That's a major feature of RTT: no need to do locking

> yourself anymore :-) The design problems are hence moved towards finding

> the "best" component architecture and configuration of the individual

> components.

Indeed!

I have been working with filter-components for a long time and I suggest the following construction

* create an sysUpdate function and a measUpdate function

* run your component non periodically

* have the sysUpdate triggered periodically trough an eventPort triggered by a timer component

* have the measUpdate triggered by the measurement port.

You can find an example of such a component at http://git.mech.kuleuven.be/?p=robotics/camera_pose_estimation.git;a=sum...

If you need any extra explanation I will be glad to help you.

Tinne

>

> >> And isn't your KF C++ class then "running" de facto inside of the

> >> estimator component?

> >

> > Yes it is. That's why I thought moving it directly in the estimator

> > component wouldn't change that much.

>

> You are not "moving" anything :-) The compiler links your library to the

> code that is being deployed inside your estimator component, so it _is_

> already there :-)

>

> Herman

>

> >>>>> Op 31/07/2011 20:13, S Roderick schreef:

> >>>>>> On Jul 31, 2011, at 07:47 , Herman Bruyninckx wrote:

> >>>>>>> On Sun, 31 Jul 2011, Peter Soetens wrote:

> >>>>>>>> On Fri, Jul 29, 2011 at 4:15 PM, Kurt Geebelen

> >>>>>>>>

> >>>>>>>> <kurt [dot] geebelen [..] ...> wrote:

> >>>>>>>>> Hi,

> >>>>>>>>>

> >>>>>>>>> I have a component that is running a kalman filter, which has 2

> >>>>>>>>> main functions: propagate and update. I periodically propagate

> >>>>>>>>> my kalman filter, and I update my kalman filter event-driven

> >>>>>>>>> when data comes available on a port.

> >>>>>>>>>

> >>>>>>>>> I sometimes get a segmentation fault when running this component.

> >>>>>>>>> I noticed that this is due to the problem that sometimes, while

> >>>>>>>>> my component is performing the propagation, new data becomes

> >>>>>>>>> available on a port, and the component will attempt to update

> >>>>>>>>> the kalman filter while performing the propagation. I tried

> >>>>>>>>> solving it by setting some booleans while doing the

> >>>>>>>>> propagate/update. So something like this:

> >>>>>>>>>

> >>>>>>>>> For propagating:

> >>>>>>>>>

> >>>>>>>>> <code>

> >>>>>>>>> while(updating){}

> >>>>>>>>> propagating=true;

> >>>>>>>>> propagate();

> >>>>>>>>> propagating=false;

> >>>>>>>>> </code>

> >>>>>>>>

> >>>>>>>> Change to:

> >>>>>>>>

> >>>>>>>> <code>

> >>>>>>>> {

> >>>>>>>>

> >>>>>>>> os::MutexLock lock(m);

> >>>>>>>> propagate();

> >>>>>>>>

> >>>>>>>> } // note these curly braces, they must be here !

> >>>>>>>> </code>

> >>>>>>>>

> >>>>>>>>> And for updating:

> >>>>>>>>>

> >>>>>>>>> <code>

> >>>>>>>>> while(propagating){}

> >>>>>>>>> updating=true;

> >>>>>>>>> update();

> >>>>>>>>> updating=false;

> >>>>>>>>> </code>

> >>>>>>>>

> >>>>>>>> change to:

> >>>>>>>>

> >>>>>>>> <code>

> >>>>>>>> {

> >>>>>>>>

> >>>>>>>> os::MutexLock lock(m);

> >>>>>>>> update();

> >>>>>>>>

> >>>>>>>> } // note these curly braces, they must be here !

> >>>>>>>> </code>

> >>>>>>>

> >>>>>>> Please, don't invite users to start introducing explicit locks in

> >>>>>>> their applications! This brings us back to the times _before_

> >>>>>>> Orocos/RTT existed, and to the reasons _why_ it was developed: to

> >>>>>>> shield users from these ugly, low-level, error-prone OS

> >>>>>>> primitives. It is obvious that locks have _no_ place in a real

> >>>>>>> component based application, by definition almost.

> >>>>>>>

> >>>>>>> I am 100% sure Kurt's problem can be neatly solved with appropriate

> >>>>>>> design of his application using the core primitives of RTT, namely

> >>>>>>> Ports and simple Coordination with a state machine.

> >>>>>>>

> >>>>>>> In addition to providing good software, Orocos also has an

> >>>>>>> educational vocation, and that is to stimulate best practice

> >>>>>>> software engineering into the mechatronics and robotics

> >>>>>>> communities...

> >>>>>>

> >>>>>> True, but sometimes you need something to work first, before you

> >>>>>> make it correct. Peter's suggestion will fix his immediate needs

> >>>>>> _and_ we need to educate Kurt that this isn't the best approach and

> >>>>>> that he should consider doing it another way. S

> >>>>

> >>>> --

> >>>>

> >>>> K.U.Leuven, Mechanical Eng., Mechatronics& Robotics Research

> >>>> Group

> >>>>

> >>>> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056

> >>>>

> >>>> EURON Coordinator (European Robotics Research

> >>>> Network)<http://www.euron.org> Open Realtime Control

> >>>> Services<http://www.orocos.org>

> >>>> Associate Editor JOSER<http://www.joser.org>,

> >>>> IJRR<http://www.ijrr.org>

> >>

> >> --

> >>

> >> K.U.Leuven, Mechanical Eng., Mechatronics& Robotics Research Group

> >>

> >> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056

> >>

> >> EURON Coordinator (European Robotics Research

> >> Network)<http://www.euron.org> Open Realtime Control

> >> Services<http://www.orocos.org>

> >> Associate Editor JOSER<http://www.joser.org>,

> >> IJRR<http://www.ijrr.org>

>

> --

> K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group

> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056

> EURON Coordinator (European Robotics Research Network)

> <http://www.euron.org> Open Realtime Control Services

> <http://www.orocos.org>

> Associate Editor JOSER <http://www.joser.org>, IJRR

> <http://www.ijrr.org>

<body><html>
--Boundary-01=_xgQROL2C+9IVlJ2--

»

prevent function from executing when other is executing

Submitted by Tinne De Laet on Tue, 2011-08-16 09:12.

On Monday 01 August 2011 11:26:28 Herman Bruyninckx wrote:
> On Mon, 1 Aug 2011, Kurt Geebelen wrote:
> > Op 1/08/2011 10:37, Herman Bruyninckx schreef:
> >> On Mon, 1 Aug 2011, Kurt Geebelen wrote:
> >>> Op 1/08/2011 10:00, Herman Bruyninckx schreef:
> >>>> On Mon, 1 Aug 2011, Kurt Geebelen wrote:
> >>>>> Hi,
> >>>>
> >>>> (Please do not top post<http://en.wikipedia.org/wiki/Top_posting>)
> >>>
> >>> Sorry
> >>>
> >>>>> I have written a C+-class for the kalman filter, which has the 2
> >>>>> functions propagate and update (I didn't use the ExtendedKalmanFilter
> >>>>> class of the BLF-library because this way it was more clear to me
> >>>>> what was happening).
> >>>>
> >>>> Oops... What is not clear with the way the BFL integrates an EKF into
> >>>> Orocos?
> >>>> E.g.<http://comments.gmane.org/gmane.science.robotics.orocos.devel/845
> >>>> 7>
> >>>
> >>> Nothing is wrong with it. I just thought it would be a better exercise
> >>> to implement it myself.
> >>
> >> That turns out to be true :-) There is no better schooling than to
> >> repeat the errors one _has_ to make before being able to appreciate
> >> better practice solutions :-)
> >>
> >>>>> The variables that are changed in both functions are the
> >>>>> covariance matrix and the state of the kalman filter. They are of
> >>>>> type Matrix of the Newmat library I am using
> >>>>> (http://www.robertnz.net/nm10.htm). The elements of these matrices
> >>>>> are of type double.
> >>>>>
> >>>>> My estimator component than creates an instance of this kalman filter
> >>>>> class, periodically propagates it (apply system model), and whenever
> >>>>> a measurement becomes available, updates the kalman filter with this
> >>>>> measurement. This is thus where it sometimes goes wrong, when these
> >>>>> functions coincide.
> >>>>
> >>>> Exactly. But they should not "coincide" :-) I mean, the component that
> >>>> contains the (E)KF code should run the process update and measurement
> >>>> update 'atomically', which could be realised by letting it read from
> >>>> Data ports (one for new timer data, one for new measurement data).
> >>>>
> >>>> I have the impression you have another design, in which you call an
> >>>> operation on the EKF component from two other components, and in this
> >>>> way it becomes very difficult for the EKF component to guarantee data
> >>>> consistency...
> >>>>
> >>>> Is my assumption about your architecture correct or not?
> >>>> In other words, what _is_ the architecture of your complete system?
> >>>
> >>> There is only one component communicating with the kalman filter,
> >>> namely the estimator component.
> >>
> >> Strange, since the Kalman Filter _is_ an estimator...
> >>
> >>> Note that the EKF is not a orocos-component,
> >>> but just a C++ class, on which the estimator-component is calling
> >>> functions.
> >>
> >> And where does the EKF class resides? It must be in some "component",
> >> isn't it?
> >>
> >>> I could integrate this code in the estimator component, but I
> >>> don't think this would change much?
> >>
> >> I think it will change everything :-)
> >>
> >>> In the estimator component, in the updateHook, I thus do the process
> >>> update. The measurements are coming from another component, which puts
> >>> them on a Data port. My estimator component connects with this port,
> >>> and I have coupled an event to this port, which performs the
> >>> measurement update with the data on this port.
> >>
> >> Fine! And what about the process update? Can't you do that in the same
> >> way? (That is, via a time-triggered data port.)
> >
> > I can do that. But won't this still give the same problems when this
> > coincides with the measurement update?
>
> The component's TaskContext will 'serialize' the handling of the arrival of
> data on the Ports. That's a major feature of RTT: no need to do locking
> yourself anymore :-) The design problems are hence moved towards finding
> the "best" component architecture and configuration of the individual
> components.

Indeed!

I have been working with filter-components for a long time and I suggest the
following construction
* create an sysUpdate function and a measUpdate function
* run your component non periodically
* have the sysUpdate triggered periodically trough an eventPort triggered by a
timer component
* have the measUpdate triggered by the measurement port.

You can find an example of such a component at
http://git.mech.kuleuven.be/?p=robotics/camera_pose_estimation.git;a=sum...

If you need any extra explanation I will be glad to help you.

Tinne

>
> >> And isn't your KF C++ class then "running" de facto inside of the
> >> estimator component?
> >
> > Yes it is. That's why I thought moving it directly in the estimator
> > component wouldn't change that much.
>
> You are not "moving" anything :-) The compiler links your library to the
> code that is being deployed inside your estimator component, so it _is_
> already there :-)
>
> Herman
>
> >>>>> Op 31/07/2011 20:13, S Roderick schreef:
> >>>>>> On Jul 31, 2011, at 07:47 , Herman Bruyninckx wrote:
> >>>>>>> On Sun, 31 Jul 2011, Peter Soetens wrote:
> >>>>>>>> On Fri, Jul 29, 2011 at 4:15 PM, Kurt Geebelen
> >>>>>>>>
> >>>>>>>> <kurt [dot] geebelen [..] ...> wrote:
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> I have a component that is running a kalman filter, which has 2
> >>>>>>>>> main functions: propagate and update. I periodically propagate
> >>>>>>>>> my kalman filter, and I update my kalman filter event-driven
> >>>>>>>>> when data comes available on a port.
> >>>>>>>>>
> >>>>>>>>> I sometimes get a segmentation fault when running this component.
> >>>>>>>>> I noticed that this is due to the problem that sometimes, while
> >>>>>>>>> my component is performing the propagation, new data becomes
> >>>>>>>>> available on a port, and the component will attempt to update
> >>>>>>>>> the kalman filter while performing the propagation. I tried
> >>>>>>>>> solving it by setting some booleans while doing the
> >>>>>>>>> propagate/update. So something like this:
> >>>>>>>>>
> >>>>>>>>> For propagating:
> >>>>>>>>>
> >>>>>>>>> 

> >>>>>>>>> while(updating){}
> >>>>>>>>> propagating=true;
> >>>>>>>>> propagate();
> >>>>>>>>> propagating=false;
> >>>>>>>>>

> >>>>>>>>
> >>>>>>>> Change to:
> >>>>>>>>
> >>>>>>>> 
> >>>>>>>> {
> >>>>>>>> 
> >>>>>>>>     os::MutexLock lock(m);
> >>>>>>>>     propagate();
> >>>>>>>> 
> >>>>>>>> } // note these curly braces, they must be here !
> >>>>>>>>

> >>>>>>>>
> >>>>>>>>> And for updating:
> >>>>>>>>>
> >>>>>>>>> 
> >>>>>>>>> while(propagating){}
> >>>>>>>>> updating=true;
> >>>>>>>>> update();
> >>>>>>>>> updating=false;
> >>>>>>>>>

> >>>>>>>>
> >>>>>>>> change to:
> >>>>>>>>
> >>>>>>>> 
> >>>>>>>> {
> >>>>>>>> 
> >>>>>>>>     os::MutexLock lock(m);
> >>>>>>>>     update();
> >>>>>>>> 
> >>>>>>>> } // note these curly braces, they must be here !
> >>>>>>>>

> >>>>>>>
> >>>>>>> Please, don't invite users to start introducing explicit locks in
> >>>>>>> their applications! This brings us back to the times _before_
> >>>>>>> Orocos/RTT existed, and to the reasons _why_ it was developed: to
> >>>>>>> shield users from these ugly, low-level, error-prone OS
> >>>>>>> primitives. It is obvious that locks have _no_ place in a real
> >>>>>>> component based application, by definition almost.
> >>>>>>>
> >>>>>>> I am 100% sure Kurt's problem can be neatly solved with appropriate
> >>>>>>> design of his application using the core primitives of RTT, namely
> >>>>>>> Ports and simple Coordination with a state machine.
> >>>>>>>
> >>>>>>> In addition to providing good software, Orocos also has an
> >>>>>>> educational vocation, and that is to stimulate best practice
> >>>>>>> software engineering into the mechatronics and robotics
> >>>>>>> communities...
> >>>>>>
> >>>>>> True, but sometimes you need something to work first, before you
> >>>>>> make it correct. Peter's suggestion will fix his immediate needs
> >>>>>> _and_ we need to educate Kurt that this isn't the best approach and
> >>>>>> that he should consider doing it another way. S
> >>>>
> >>>> --
> >>>>
> >>>> K.U.Leuven, Mechanical Eng., Mechatronics& Robotics Research
> >>>> Group
> >>>>
> >>>> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> >>>>
> >>>> EURON Coordinator (European Robotics Research
> >>>> Network)<http://www.euron.org> Open Realtime Control
> >>>> Services<http://www.orocos.org>
> >>>> Associate Editor JOSER<http://www.joser.org>,
> >>>> IJRR<http://www.ijrr.org>
> >>
> >> --
> >>
> >> K.U.Leuven, Mechanical Eng., Mechatronics& Robotics Research Group
> >>
> >> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> >>
> >> EURON Coordinator (European Robotics Research
> >> Network)<http://www.euron.org> Open Realtime Control
> >> Services<http://www.orocos.org>
> >> Associate Editor JOSER<http://www.joser.org>,
> >> IJRR<http://www.ijrr.org>
>
> --
> K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> EURON Coordinator (European Robotics Research Network)
> <http://www.euron.org> Open Realtime Control Services
> <http://www.orocos.org>
> Associate Editor JOSER <http://www.joser.org>, IJRR
> <http://www.ijrr.org>

»

prevent function from executing when other is executing

Submitted by Tinne De Laet on Tue, 2011-08-16 09:12.

On Monday 01 August 2011 11:26:28 Herman Bruyninckx wrote:
> On Mon, 1 Aug 2011, Kurt Geebelen wrote:
> > Op 1/08/2011 10:37, Herman Bruyninckx schreef:
> >> On Mon, 1 Aug 2011, Kurt Geebelen wrote:
> >>> Op 1/08/2011 10:00, Herman Bruyninckx schreef:
> >>>> On Mon, 1 Aug 2011, Kurt Geebelen wrote:
> >>>>> Hi,
> >>>>
> >>>> (Please do not top post<http://en.wikipedia.org/wiki/Top_posting>)
> >>>
> >>> Sorry
> >>>
> >>>>> I have written a C+-class for the kalman filter, which has the 2
> >>>>> functions propagate and update (I didn't use the ExtendedKalmanFilter
> >>>>> class of the BLF-library because this way it was more clear to me
> >>>>> what was happening).
> >>>>
> >>>> Oops... What is not clear with the way the BFL integrates an EKF into
> >>>> Orocos?
> >>>> E.g.<http://comments.gmane.org/gmane.science.robotics.orocos.devel/845
> >>>> 7>
> >>>
> >>> Nothing is wrong with it. I just thought it would be a better exercise
> >>> to implement it myself.
> >>
> >> That turns out to be true :-) There is no better schooling than to
> >> repeat the errors one _has_ to make before being able to appreciate
> >> better practice solutions :-)
> >>
> >>>>> The variables that are changed in both functions are the
> >>>>> covariance matrix and the state of the kalman filter. They are of
> >>>>> type Matrix of the Newmat library I am using
> >>>>> (http://www.robertnz.net/nm10.htm). The elements of these matrices
> >>>>> are of type double.
> >>>>>
> >>>>> My estimator component than creates an instance of this kalman filter
> >>>>> class, periodically propagates it (apply system model), and whenever
> >>>>> a measurement becomes available, updates the kalman filter with this
> >>>>> measurement. This is thus where it sometimes goes wrong, when these
> >>>>> functions coincide.
> >>>>
> >>>> Exactly. But they should not "coincide" :-) I mean, the component that
> >>>> contains the (E)KF code should run the process update and measurement
> >>>> update 'atomically', which could be realised by letting it read from
> >>>> Data ports (one for new timer data, one for new measurement data).
> >>>>
> >>>> I have the impression you have another design, in which you call an
> >>>> operation on the EKF component from two other components, and in this
> >>>> way it becomes very difficult for the EKF component to guarantee data
> >>>> consistency...
> >>>>
> >>>> Is my assumption about your architecture correct or not?
> >>>> In other words, what _is_ the architecture of your complete system?
> >>>
> >>> There is only one component communicating with the kalman filter,
> >>> namely the estimator component.
> >>
> >> Strange, since the Kalman Filter _is_ an estimator...
> >>
> >>> Note that the EKF is not a orocos-component,
> >>> but just a C++ class, on which the estimator-component is calling
> >>> functions.
> >>
> >> And where does the EKF class resides? It must be in some "component",
> >> isn't it?
> >>
> >>> I could integrate this code in the estimator component, but I
> >>> don't think this would change much?
> >>
> >> I think it will change everything :-)
> >>
> >>> In the estimator component, in the updateHook, I thus do the process
> >>> update. The measurements are coming from another component, which puts
> >>> them on a Data port. My estimator component connects with this port,
> >>> and I have coupled an event to this port, which performs the
> >>> measurement update with the data on this port.
> >>
> >> Fine! And what about the process update? Can't you do that in the same
> >> way? (That is, via a time-triggered data port.)
> >
> > I can do that. But won't this still give the same problems when this
> > coincides with the measurement update?
>
> The component's TaskContext will 'serialize' the handling of the arrival of
> data on the Ports. That's a major feature of RTT: no need to do locking
> yourself anymore :-) The design problems are hence moved towards finding
> the "best" component architecture and configuration of the individual
> components.

Indeed!

I have been working with filter-components for a long time and I suggest the
following construction
* create an sysUpdate function and a measUpdate function
* run your component non periodically
* have the sysUpdate triggered periodically trough an eventPort triggered by a
timer component
* have the measUpdate triggered by the measurement port.

You can find an example of such a component at
http://git.mech.kuleuven.be/?p=robotics/camera_pose_estimation.git;a=sum...

If you need any extra explanation I will be glad to help you.

Tinne

>
> >> And isn't your KF C++ class then "running" de facto inside of the
> >> estimator component?
> >
> > Yes it is. That's why I thought moving it directly in the estimator
> > component wouldn't change that much.
>
> You are not "moving" anything :-) The compiler links your library to the
> code that is being deployed inside your estimator component, so it _is_
> already there :-)
>
> Herman
>
> >>>>> Op 31/07/2011 20:13, S Roderick schreef:
> >>>>>> On Jul 31, 2011, at 07:47 , Herman Bruyninckx wrote:
> >>>>>>> On Sun, 31 Jul 2011, Peter Soetens wrote:
> >>>>>>>> On Fri, Jul 29, 2011 at 4:15 PM, Kurt Geebelen
> >>>>>>>>
> >>>>>>>> <kurt [dot] geebelen [..] ...> wrote:
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> I have a component that is running a kalman filter, which has 2
> >>>>>>>>> main functions: propagate and update. I periodically propagate
> >>>>>>>>> my kalman filter, and I update my kalman filter event-driven
> >>>>>>>>> when data comes available on a port.
> >>>>>>>>>
> >>>>>>>>> I sometimes get a segmentation fault when running this component.
> >>>>>>>>> I noticed that this is due to the problem that sometimes, while
> >>>>>>>>> my component is performing the propagation, new data becomes
> >>>>>>>>> available on a port, and the component will attempt to update
> >>>>>>>>> the kalman filter while performing the propagation. I tried
> >>>>>>>>> solving it by setting some booleans while doing the
> >>>>>>>>> propagate/update. So something like this:
> >>>>>>>>>
> >>>>>>>>> For propagating:
> >>>>>>>>>
> >>>>>>>>> 

> >>>>>>>>> while(updating){}
> >>>>>>>>> propagating=true;
> >>>>>>>>> propagate();
> >>>>>>>>> propagating=false;
> >>>>>>>>>

> >>>>>>>>
> >>>>>>>> Change to:
> >>>>>>>>
> >>>>>>>> 
> >>>>>>>> {
> >>>>>>>> 
> >>>>>>>>     os::MutexLock lock(m);
> >>>>>>>>     propagate();
> >>>>>>>> 
> >>>>>>>> } // note these curly braces, they must be here !
> >>>>>>>>

> >>>>>>>>
> >>>>>>>>> And for updating:
> >>>>>>>>>
> >>>>>>>>> 
> >>>>>>>>> while(propagating){}
> >>>>>>>>> updating=true;
> >>>>>>>>> update();
> >>>>>>>>> updating=false;
> >>>>>>>>>

> >>>>>>>>
> >>>>>>>> change to:
> >>>>>>>>
> >>>>>>>> 
> >>>>>>>> {
> >>>>>>>> 
> >>>>>>>>     os::MutexLock lock(m);
> >>>>>>>>     update();
> >>>>>>>> 
> >>>>>>>> } // note these curly braces, they must be here !
> >>>>>>>>

> >>>>>>>
> >>>>>>> Please, don't invite users to start introducing explicit locks in
> >>>>>>> their applications! This brings us back to the times _before_
> >>>>>>> Orocos/RTT existed, and to the reasons _why_ it was developed: to
> >>>>>>> shield users from these ugly, low-level, error-prone OS
> >>>>>>> primitives. It is obvious that locks have _no_ place in a real
> >>>>>>> component based application, by definition almost.
> >>>>>>>
> >>>>>>> I am 100% sure Kurt's problem can be neatly solved with appropriate
> >>>>>>> design of his application using the core primitives of RTT, namely
> >>>>>>> Ports and simple Coordination with a state machine.
> >>>>>>>
> >>>>>>> In addition to providing good software, Orocos also has an
> >>>>>>> educational vocation, and that is to stimulate best practice
> >>>>>>> software engineering into the mechatronics and robotics
> >>>>>>> communities...
> >>>>>>
> >>>>>> True, but sometimes you need something to work first, before you
> >>>>>> make it correct. Peter's suggestion will fix his immediate needs
> >>>>>> _and_ we need to educate Kurt that this isn't the best approach and
> >>>>>> that he should consider doing it another way. S
> >>>>
> >>>> --
> >>>>
> >>>> K.U.Leuven, Mechanical Eng., Mechatronics& Robotics Research
> >>>> Group
> >>>>
> >>>> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> >>>>
> >>>> EURON Coordinator (European Robotics Research
> >>>> Network)<http://www.euron.org> Open Realtime Control
> >>>> Services<http://www.orocos.org>
> >>>> Associate Editor JOSER<http://www.joser.org>,
> >>>> IJRR<http://www.ijrr.org>
> >>
> >> --
> >>
> >> K.U.Leuven, Mechanical Eng., Mechatronics& Robotics Research Group
> >>
> >> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> >>
> >> EURON Coordinator (European Robotics Research
> >> Network)<http://www.euron.org> Open Realtime Control
> >> Services<http://www.orocos.org>
> >> Associate Editor JOSER<http://www.joser.org>,
> >> IJRR<http://www.ijrr.org>
>
> --
> K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> EURON Coordinator (European Robotics Research Network)
> <http://www.euron.org> Open Realtime Control Services
> <http://www.orocos.org>
> Associate Editor JOSER <http://www.joser.org>, IJRR
> <http://www.ijrr.org>

»

prevent function from executing when other is executing

Submitted by Kurt Geebelen on Mon, 2011-08-01 09:44.

Op 1/08/2011 11:26, Herman Bruyninckx schreef:
> On Mon, 1 Aug 2011, Kurt Geebelen wrote:
>
>> Op 1/08/2011 10:37, Herman Bruyninckx schreef:
>>> On Mon, 1 Aug 2011, Kurt Geebelen wrote:
>>>
>>>> Op 1/08/2011 10:00, Herman Bruyninckx schreef:
>>>>> On Mon, 1 Aug 2011, Kurt Geebelen wrote:
>>>>>
>>>>>> Hi,
>>>>> (Please do not top post<http://en.wikipedia.org/wiki/Top_posting>)
>>>> Sorry
>>>>
>>>>>> I have written a C+-class for the kalman filter, which has the 2
>>>>>> functions propagate and update (I didn't use the ExtendedKalmanFilter
>>>>>> class of the BLF-library because this way it was more clear to me what
>>>>>> was happening).
>>>>> Oops... What is not clear with the way the BFL integrates an EKF into
>>>>> Orocos?
>>>>> E.g.<http://comments.gmane.org/gmane.science.robotics.orocos.devel/8457>
>>>> Nothing is wrong with it. I just thought it would be a better exercise
>>>> to implement it myself.
>>> That turns out to be true :-) There is no better schooling than to repeat
>>> the errors one _has_ to make before being able to appreciate better
>>> practice solutions :-)
>>>
>>>>>> The variables that are changed in both functions are the
>>>>>> covariance matrix and the state of the kalman filter. They are of type
>>>>>> Matrix of the Newmat library I am using
>>>>>> (http://www.robertnz.net/nm10.htm). The elements of these matrices are
>>>>>> of type double.
>>>>>>
>>>>>> My estimator component than creates an instance of this kalman filter
>>>>>> class, periodically propagates it (apply system model), and whenever a
>>>>>> measurement becomes available, updates the kalman filter with this
>>>>>> measurement. This is thus where it sometimes goes wrong, when these
>>>>>> functions coincide.
>>>>> Exactly. But they should not "coincide" :-) I mean, the component that
>>>>> contains the (E)KF code should run the process update and measurement
>>>>> update 'atomically', which could be realised by letting it read from Data
>>>>> ports (one for new timer data, one for new measurement data).
>>>>>
>>>>> I have the impression you have another design, in which you call an
>>>>> operation on the EKF component from two other components, and in this way
>>>>> it becomes very difficult for the EKF component to guarantee data
>>>>> consistency...
>>>>>
>>>>> Is my assumption about your architecture correct or not?
>>>>> In other words, what _is_ the architecture of your complete system?
>>>> There is only one component communicating with the kalman filter, namely
>>>> the estimator component.
>>> Strange, since the Kalman Filter _is_ an estimator...
>>>
>>>> Note that the EKF is not a orocos-component,
>>>> but just a C++ class, on which the estimator-component is calling
>>>> functions.
>>> And where does the EKF class resides? It must be in some "component", isn't
>>> it?
>>>
>>>> I could integrate this code in the estimator component, but I
>>>> don't think this would change much?
>>> I think it will change everything :-)
>>>
>>>> In the estimator component, in the updateHook, I thus do the process
>>>> update. The measurements are coming from another component, which puts
>>>> them on a Data port. My estimator component connects with this port, and
>>>> I have coupled an event to this port, which performs the measurement
>>>> update with the data on this port.
>>> Fine! And what about the process update? Can't you do that in the same way?
>>> (That is, via a time-triggered data port.)
>> I can do that. But won't this still give the same problems when this
>> coincides with the measurement update?
> The component's TaskContext will 'serialize' the handling of the arrival of
> data on the Ports. That's a major feature of RTT: no need to do locking
> yourself anymore :-) The design problems are hence moved towards finding
> the "best" component architecture and configuration of the individual
> components.

Ok, I will try that than.

Thanks!
Kurt

>
>>> And isn't your KF C++ class then "running" de facto inside of the estimator
>>> component?
>> Yes it is. That's why I thought moving it directly in the estimator
>> component wouldn't change that much.
> You are not "moving" anything :-) The compiler links your library to the
> code that is being deployed inside your estimator component, so it _is_
> already there :-)
>
> Herman
>
>>>>>> Op 31/07/2011 20:13, S Roderick schreef:
>>>>>>> On Jul 31, 2011, at 07:47 , Herman Bruyninckx wrote:
>>>>>>>
>>>>>>>> On Sun, 31 Jul 2011, Peter Soetens wrote:
>>>>>>>>
>>>>>>>>> On Fri, Jul 29, 2011 at 4:15 PM, Kurt Geebelen
>>>>>>>>> <kurt [dot] geebelen [..] ...> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I have a component that is running a kalman filter, which has 2 main
>>>>>>>>>> functions: propagate and update. I periodically propagate my kalman
>>>>>>>>>> filter, and I update my kalman filter event-driven when data comes
>>>>>>>>>> available on a port.
>>>>>>>>>>
>>>>>>>>>> I sometimes get a segmentation fault when running this component. I
>>>>>>>>>> noticed that this is due to the problem that sometimes, while my
>>>>>>>>>> component is performing the propagation, new data becomes available on a
>>>>>>>>>> port, and the component will attempt to update the kalman filter while
>>>>>>>>>> performing the propagation. I tried solving it by setting some booleans
>>>>>>>>>> while doing the propagate/update. So something like this:
>>>>>>>>>>
>>>>>>>>>> For propagating:
>>>>>>>>>>
>>>>>>>>>> 

>>>>>>>>>> while(updating){}
>>>>>>>>>> propagating=true;
>>>>>>>>>> propagate();
>>>>>>>>>> propagating=false;
>>>>>>>>>>

>>>>>>>>> Change to:
>>>>>>>>>
>>>>>>>>> 
>>>>>>>>> {
>>>>>>>>>      os::MutexLock lock(m);
>>>>>>>>>      propagate();
>>>>>>>>> } // note these curly braces, they must be here !
>>>>>>>>>

>>>>>>>>>
>>>>>>>>>> And for updating:
>>>>>>>>>>
>>>>>>>>>> 
>>>>>>>>>> while(propagating){}
>>>>>>>>>> updating=true;
>>>>>>>>>> update();
>>>>>>>>>> updating=false;
>>>>>>>>>>

>>>>>>>>> change to:
>>>>>>>>>
>>>>>>>>> 
>>>>>>>>> {
>>>>>>>>>      os::MutexLock lock(m);
>>>>>>>>>      update();
>>>>>>>>> } // note these curly braces, they must be here !
>>>>>>>>>

>>>>>>>>>
>>>>>>>> Please, don't invite users to start introducing explicit locks in their
>>>>>>>> applications! This brings us back to the times _before_ Orocos/RTT existed,
>>>>>>>> and to the reasons _why_ it was developed: to shield users from these ugly,
>>>>>>>> low-level, error-prone OS primitives. It is obvious that locks have _no_
>>>>>>>> place in a real component based application, by definition almost.
>>>>>>>>
>>>>>>>> I am 100% sure Kurt's problem can be neatly solved with appropriate design
>>>>>>>> of his application using the core primitives of RTT, namely Ports and
>>>>>>>> simple Coordination with a state machine.
>>>>>>>>
>>>>>>>> In addition to providing good software, Orocos also has an educational
>>>>>>>> vocation, and that is to stimulate best practice software engineering into
>>>>>>>> the mechatronics and robotics communities...
>>>>>>> True, but sometimes you need something to work first, before you make it correct. Peter's suggestion will fix his immediate needs _and_ we need to educate Kurt that this isn't the best approach and that he should consider doing it another way.
>>>>>>> S
>>>>>>>
>>>>> --
>>>>> K.U.Leuven, Mechanical Eng., Mechatronics& Robotics Research Group
>>>>> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
>>>>> EURON Coordinator (European Robotics Research Network)<http://www.euron.org>
>>>>> Open Realtime Control Services<http://www.orocos.org>
>>>>> Associate Editor JOSER<http://www.joser.org>, IJRR<http://www.ijrr.org>
>>> --
>>> K.U.Leuven, Mechanical Eng., Mechatronics& Robotics Research Group
>>> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
>>> EURON Coordinator (European Robotics Research Network)<http://www.euron.org>
>>> Open Realtime Control Services<http://www.orocos.org>
>>> Associate Editor JOSER<http://www.joser.org>, IJRR<http://www.ijrr.org>
> --
> K.U.Leuven, Mechanical Eng., Mechatronics& Robotics Research Group
> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> EURON Coordinator (European Robotics Research Network)<http://www.euron.org>
> Open Realtime Control Services<http://www.orocos.org>
> Associate Editor JOSER<http://www.joser.org>, IJRR<http://www.ijrr.org>

»

prevent function from executing when other is executing

Submitted by bruyninc on Mon, 2011-08-01 10:24.

On Mon, 1 Aug 2011, Kurt Geebelen wrote:

>
>
> Op 1/08/2011 11:26, Herman Bruyninckx schreef:
>> On Mon, 1 Aug 2011, Kurt Geebelen wrote:
>>
>>> Op 1/08/2011 10:37, Herman Bruyninckx schreef:
>>>> On Mon, 1 Aug 2011, Kurt Geebelen wrote:
>>>>
>>>>> Op 1/08/2011 10:00, Herman Bruyninckx schreef:
>>>>>> On Mon, 1 Aug 2011, Kurt Geebelen wrote:
>>>>>>
>>>>>>> Hi,
>>>>>> (Please do not top post<http://en.wikipedia.org/wiki/Top_posting>)
>>>>> Sorry
>>>>>
>>>>>>> I have written a C+-class for the kalman filter, which has the 2
>>>>>>> functions propagate and update (I didn't use the ExtendedKalmanFilter
>>>>>>> class of the BLF-library because this way it was more clear to me what
>>>>>>> was happening).
>>>>>> Oops... What is not clear with the way the BFL integrates an EKF into
>>>>>> Orocos?
>>>>>> E.g.<http://comments.gmane.org/gmane.science.robotics.orocos.devel/8457>
>>>>> Nothing is wrong with it. I just thought it would be a better exercise
>>>>> to implement it myself.
>>>> That turns out to be true :-) There is no better schooling than to repeat
>>>> the errors one _has_ to make before being able to appreciate better
>>>> practice solutions :-)
>>>>
>>>>>>> The variables that are changed in both functions are the
>>>>>>> covariance matrix and the state of the kalman filter. They are of type
>>>>>>> Matrix of the Newmat library I am using
>>>>>>> (http://www.robertnz.net/nm10.htm). The elements of these matrices are
>>>>>>> of type double.
>>>>>>>
>>>>>>> My estimator component than creates an instance of this kalman filter
>>>>>>> class, periodically propagates it (apply system model), and whenever a
>>>>>>> measurement becomes available, updates the kalman filter with this
>>>>>>> measurement. This is thus where it sometimes goes wrong, when these
>>>>>>> functions coincide.
>>>>>> Exactly. But they should not "coincide" :-) I mean, the component that
>>>>>> contains the (E)KF code should run the process update and measurement
>>>>>> update 'atomically', which could be realised by letting it read from Data
>>>>>> ports (one for new timer data, one for new measurement data).
>>>>>>
>>>>>> I have the impression you have another design, in which you call an
>>>>>> operation on the EKF component from two other components, and in this way
>>>>>> it becomes very difficult for the EKF component to guarantee data
>>>>>> consistency...
>>>>>>
>>>>>> Is my assumption about your architecture correct or not?
>>>>>> In other words, what _is_ the architecture of your complete system?
>>>>> There is only one component communicating with the kalman filter, namely
>>>>> the estimator component.
>>>> Strange, since the Kalman Filter _is_ an estimator...
>>>>
>>>>> Note that the EKF is not a orocos-component,
>>>>> but just a C++ class, on which the estimator-component is calling
>>>>> functions.
>>>> And where does the EKF class resides? It must be in some "component", isn't
>>>> it?
>>>>
>>>>> I could integrate this code in the estimator component, but I
>>>>> don't think this would change much?
>>>> I think it will change everything :-)
>>>>
>>>>> In the estimator component, in the updateHook, I thus do the process
>>>>> update. The measurements are coming from another component, which puts
>>>>> them on a Data port. My estimator component connects with this port, and
>>>>> I have coupled an event to this port, which performs the measurement
>>>>> update with the data on this port.
>>>> Fine! And what about the process update? Can't you do that in the same way?
>>>> (That is, via a time-triggered data port.)
>>> I can do that. But won't this still give the same problems when this
>>> coincides with the measurement update?
>> The component's TaskContext will 'serialize' the handling of the arrival of
>> data on the Ports. That's a major feature of RTT: no need to do locking
>> yourself anymore :-) The design problems are hence moved towards finding
>> the "best" component architecture and configuration of the individual
>> components.
>
> Ok, I will try that than.

Good! Keep the list informed, since your use case fits perfectly in the
scope of the newly started "Orocos Conrol Box"
<http://people.mech.kuleuven.be/~bruyninc/controltoolbox />
Dirk Pirard started on the project today. Since both of you are rather
closely stationed together (the same building :-)) please feel free to
discuss the matter with him, and to "outsource" some coding maybe...

> Thanks!
You're welcome!

> Kurt

Herman

>>>> And isn't your KF C++ class then "running" de facto inside of the estimator
>>>> component?
>>> Yes it is. That's why I thought moving it directly in the estimator
>>> component wouldn't change that much.
>> You are not "moving" anything :-) The compiler links your library to the
>> code that is being deployed inside your estimator component, so it _is_
>> already there :-)
>>
>> Herman
>>
>>>>>>> Op 31/07/2011 20:13, S Roderick schreef:
>>>>>>>> On Jul 31, 2011, at 07:47 , Herman Bruyninckx wrote:
>>>>>>>>
>>>>>>>>> On Sun, 31 Jul 2011, Peter Soetens wrote:
>>>>>>>>>
>>>>>>>>>> On Fri, Jul 29, 2011 at 4:15 PM, Kurt Geebelen
>>>>>>>>>> <kurt [dot] geebelen [..] ...> wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I have a component that is running a kalman filter, which has 2 main
>>>>>>>>>>> functions: propagate and update. I periodically propagate my kalman
>>>>>>>>>>> filter, and I update my kalman filter event-driven when data comes
>>>>>>>>>>> available on a port.
>>>>>>>>>>>
>>>>>>>>>>> I sometimes get a segmentation fault when running this component. I
>>>>>>>>>>> noticed that this is due to the problem that sometimes, while my
>>>>>>>>>>> component is performing the propagation, new data becomes available on a
>>>>>>>>>>> port, and the component will attempt to update the kalman filter while
>>>>>>>>>>> performing the propagation. I tried solving it by setting some booleans
>>>>>>>>>>> while doing the propagate/update. So something like this:
>>>>>>>>>>>
>>>>>>>>>>> For propagating:
>>>>>>>>>>>
>>>>>>>>>>> 

>>>>>>>>>>> while(updating){}
>>>>>>>>>>> propagating=true;
>>>>>>>>>>> propagate();
>>>>>>>>>>> propagating=false;
>>>>>>>>>>>

>>>>>>>>>> Change to:
>>>>>>>>>>
>>>>>>>>>> 
>>>>>>>>>> {
>>>>>>>>>>      os::MutexLock lock(m);
>>>>>>>>>>      propagate();
>>>>>>>>>> } // note these curly braces, they must be here !
>>>>>>>>>>

>>>>>>>>>>
>>>>>>>>>>> And for updating:
>>>>>>>>>>>
>>>>>>>>>>> 
>>>>>>>>>>> while(propagating){}
>>>>>>>>>>> updating=true;
>>>>>>>>>>> update();
>>>>>>>>>>> updating=false;
>>>>>>>>>>>

>>>>>>>>>> change to:
>>>>>>>>>>
>>>>>>>>>> 
>>>>>>>>>> {
>>>>>>>>>>      os::MutexLock lock(m);
>>>>>>>>>>      update();
>>>>>>>>>> } // note these curly braces, they must be here !
>>>>>>>>>>

>>>>>>>>>>
>>>>>>>>> Please, don't invite users to start introducing explicit locks in their
>>>>>>>>> applications! This brings us back to the times _before_ Orocos/RTT existed,
>>>>>>>>> and to the reasons _why_ it was developed: to shield users from these ugly,
>>>>>>>>> low-level, error-prone OS primitives. It is obvious that locks have _no_
>>>>>>>>> place in a real component based application, by definition almost.
>>>>>>>>>
>>>>>>>>> I am 100% sure Kurt's problem can be neatly solved with appropriate design
>>>>>>>>> of his application using the core primitives of RTT, namely Ports and
>>>>>>>>> simple Coordination with a state machine.
>>>>>>>>>
>>>>>>>>> In addition to providing good software, Orocos also has an educational
>>>>>>>>> vocation, and that is to stimulate best practice software engineering into
>>>>>>>>> the mechatronics and robotics communities...
>>>>>>>> True, but sometimes you need something to work first, before you make it correct. Peter's suggestion will fix his immediate needs _and_ we need to educate Kurt that this isn't the best approach and that he should consider doing it another way.
>>>>>>>> S
>>>>>>>>
>>>>>> --
>>>>>> K.U.Leuven, Mechanical Eng., Mechatronics& Robotics Research Group
>>>>>> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
>>>>>> EURON Coordinator (European Robotics Research Network)<http://www.euron.org>
>>>>>> Open Realtime Control Services<http://www.orocos.org>
>>>>>> Associate Editor JOSER<http://www.joser.org>, IJRR<http://www.ijrr.org>
>>>> --
>>>> K.U.Leuven, Mechanical Eng., Mechatronics& Robotics Research Group
>>>> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
>>>> EURON Coordinator (European Robotics Research Network)<http://www.euron.org>
>>>> Open Realtime Control Services<http://www.orocos.org>
>>>> Associate Editor JOSER<http://www.joser.org>, IJRR<http://www.ijrr.org>
>> --
>> K.U.Leuven, Mechanical Eng., Mechatronics& Robotics Research Group
>> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
>> EURON Coordinator (European Robotics Research Network)<http://www.euron.org>
>> Open Realtime Control Services<http://www.orocos.org>
>> Associate Editor JOSER<http://www.joser.org>, IJRR<http://www.ijrr.org>
>

»

prevent function from executing when other is executing

Submitted by bruyninc on Mon, 2011-08-01 05:16.

On Sun, 31 Jul 2011, S Roderick wrote:

> On Jul 31, 2011, at 07:47 , Herman Bruyninckx wrote:
>
>> On Sun, 31 Jul 2011, Peter Soetens wrote:
>>
>>> On Fri, Jul 29, 2011 at 4:15 PM, Kurt Geebelen
>>> <kurt [dot] geebelen [..] ...> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I have a component that is running a kalman filter, which has 2 main
>>>> functions: propagate and update. I periodically propagate my kalman
>>>> filter, and I update my kalman filter event-driven when data comes
>>>> available on a port.
>>>>
>>>> I sometimes get a segmentation fault when running this component. I
>>>> noticed that this is due to the problem that sometimes, while my
>>>> component is performing the propagation, new data becomes available on a
>>>> port, and the component will attempt to update the kalman filter while
>>>> performing the propagation. I tried solving it by setting some booleans
>>>> while doing the propagate/update. So something like this:
>>>>
>>>> For propagating:
>>>>
>>>> 

>>>> while(updating){}
>>>> propagating=true;
>>>> propagate();
>>>> propagating=false;
>>>>

>>>
>>> Change to:
>>>
>>> 
>>> {
>>>  os::MutexLock lock(m);
>>>  propagate();
>>> } // note these curly braces, they must be here !
>>>

>>>
>>>>
>>>> And for updating:
>>>>
>>>> 
>>>> while(propagating){}
>>>> updating=true;
>>>> update();
>>>> updating=false;
>>>>

>>>
>>> change to:
>>>
>>> 
>>> {
>>>  os::MutexLock lock(m);
>>>  update();
>>> } // note these curly braces, they must be here !
>>>

>>>
>>
>> Please, don't invite users to start introducing explicit locks in their
>> applications! This brings us back to the times _before_ Orocos/RTT existed,
>> and to the reasons _why_ it was developed: to shield users from these ugly,
>> low-level, error-prone OS primitives. It is obvious that locks have _no_
>> place in a real component based application, by definition almost.
>>
>> I am 100% sure Kurt's problem can be neatly solved with appropriate design
>> of his application using the core primitives of RTT, namely Ports and
>> simple Coordination with a state machine.
>>
>> In addition to providing good software, Orocos also has an educational
>> vocation, and that is to stimulate best practice software engineering into
>> the mechatronics and robotics communities...
>
> True, but sometimes you need something to work first, before you make it correct. Peter's suggestion will fix his immediate needs _and_ we need to educate Kurt that this isn't the best approach and that he should consider doing it another way.

You've become too compassionate! :-) But of course you are right. Good
textbook like documentation about how to best develop component-based
applications is very much needed. It's on the agenda of the BRICS project
for the coming year, so please hold your breath :-)

> S

Herman

»

prevent function from executing when other is executing

Submitted by bruyninc on Sat, 2011-07-30 13:00.

On Fri, 29 Jul 2011, Kurt Geebelen wrote:

> Hi,
>
> I have a component that is running a kalman filter, which has 2 main
> functions: propagate and update. I periodically propagate my kalman
> filter, and I update my kalman filter event-driven when data comes
> available on a port.
>
> I sometimes get a segmentation fault when running this component. I
> noticed that this is due to the problem that sometimes, while my
> component is performing the propagation, new data becomes available on a
> port, and the component will attempt to update the kalman filter while
> performing the propagation. I tried solving it by setting some booleans
> while doing the propagate/update. So something like this:
>
> For propagating:
>
> 

> while(updating){}
> propagating=true;
> propagate();
> propagating=false;
>

>
> And for updating:
>
> 
> while(propagating){}
> updating=true;
> update();
> updating=false;
>

>
> But this didn't completely solve the issue.
> Is there a better solution to prevent one function from executing while
> the other is executing, and vise versa?

Oops! This is _definitely_ not the way to go! I mean, you are reinventing
bad practice of low level "locking" between different activities in which
each activity uses knowledge about what the other is doing; and that is
"Bad" :-)

In order to be able to explain a "better" practice, you should give a bit
more information about the overall structure of our application: what
activities do you _have_ to run concurrently? which data do you _have_ to
exchange between concurrent activities?

Herman

»

prevent function from executing when other is executing

Submitted by willy on Fri, 2011-07-29 14:28.

Isn't it a mutex job ? If think both event are trigger simustaneously while
they are sharing a common ressource.

If think a nice solution in Orocos is to register the updatingRequest or the
propagatingRequest during the event handler (in a attribute for example ?),
and then in the updateHook do the stuff you have to do relating to the
attributes value. You still have a priority to choose between the 2, but you
are sure they won't be executed at the same time. It's a matter of
decoupling between event trigeers and event managing but others will explain
it by far better than I could :)

2011/7/29 Kurt Geebelen <kurt [dot] geebelen [..] ...>

> Hi,
>
> I have a component that is running a kalman filter, which has 2 main
> functions: propagate and update. I periodically propagate my kalman
> filter, and I update my kalman filter event-driven when data comes
> available on a port.
>
> I sometimes get a segmentation fault when running this component. I
> noticed that this is due to the problem that sometimes, while my
> component is performing the propagation, new data becomes available on a
> port, and the component will attempt to update the kalman filter while
> performing the propagation. I tried solving it by setting some booleans
> while doing the propagate/update. So something like this:
>
> For propagating:
>
> 

> while(updating){}
> propagating=true;
> propagate();
> propagating=false;
>

>
> And for updating:
>
> 
> while(propagating){}
> updating=true;
> update();
> updating=false;
>

>
> But this didn't completely solve the issue.
> Is there a better solution to prevent one function from executing while
> the other is executing, and vise versa?
>
> Kurt
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

»