Use Eventport to trigger method

Hi,

I'm writing an EKF in rtt2.0 using BFL. The code needs to update the
system model every timestep (e.g. 0.01 s) and update the measurement
model every moment new data arrives. The first I can implement in a
simple UpdateHook(), for the latter I would like to use an EventPort.
The manual tells me adding the InputPort as ->addPort->addEventPort
will trigger updateHook() when new data arrives. However, in that way
the explicit distinction between measurement and system update is gone
because in both cases the same method gets called. I can check in the
updateHook() whether is was the arrival of new data that caused my
component to wake up, but if this moment accidently coincides with the
moment my system model needs an update, the last one won't get
executed. Is there any functionality left in rtt 2.0 to point my
eventPort to a custom method? If not, how can I make this distinction
explicit?

Steven

Use Eventport to trigger method

On Monday 27 September 2010 09:41:20 Steven Bellens wrote:
> Hi,
>
> I'm writing an EKF in rtt2.0 using BFL. The code needs to update the
> system model every timestep (e.g. 0.01 s) and update the measurement
> model every moment new data arrives. The first I can implement in a
> simple UpdateHook(), for the latter I would like to use an EventPort.
> The manual tells me adding the InputPort as ->addPort->addEventPort
> will trigger updateHook() when new data arrives. However, in that way
> the explicit distinction between measurement and system update is gone
> because in both cases the same method gets called. I can check in the
> updateHook() whether is was the arrival of new data that caused my
> component to wake up, but if this moment accidently coincides with the
> moment my system model needs an update, the last one won't get
> executed. Is there any functionality left in rtt 2.0 to point my
> eventPort to a custom method?

Yes, you can add and Input port just like in RTT 1.x as such:


class Component : public TaskContext {
        InputPort<Foo> input;
//...
      void newData(PortInterface*) {
             // being called when data arrives on 'input'
        }

        void updateHook() {
            // periodic measurement update
        }

        Component(...) {
               this->addEventPort("input",input, 
boost::bind(&Component::newData, this, _1) )
        }
};


So if only updateHook() is called, then it was a time trigger, if both
newData() and updateHook() were called (with newData first), there
was new data on the port.

We're not really happy with the current mechanism of 'newData', because we'd
like to have the data itself as an argument to newData instead of a pointer to
a port.

Peter

Use Eventport to trigger method

On Monday 27 September 2010 09:41:20 Steven Bellens wrote:
> Hi,
>
> I'm writing an EKF in rtt2.0 using BFL. The code needs to update the
> system model every timestep (e.g. 0.01 s) and update the measurement
> model every moment new data arrives. The first I can implement in a
> simple UpdateHook(), for the latter I would like to use an EventPort.
> The manual tells me adding the InputPort as ->addPort->addEventPort
> will trigger updateHook() when new data arrives. However, in that way
> the explicit distinction between measurement and system update is gone
> because in both cases the same method gets called. I can check in the
> updateHook() whether is was the arrival of new data that caused my
> component to wake up, but if this moment accidently coincides with the
> moment my system model needs an update, the last one won't get
> executed. Is there any functionality left in rtt 2.0 to point my
> eventPort to a custom method?

Yes, you can add and Input port just like in RTT 1.x as such:


class Component : public TaskContext {
        InputPort<Foo> input;
//...
      void newData(PortInterface*) {
             // being called when data arrives on 'input'
        }

        void updateHook() {
            // periodic measurement update
        }

        Component(...) {
               this->addEventPort("input",input, 
boost::bind(&Component::newData, this, _1) )
        }
};


So if only updateHook() is called, then it was a time trigger, if both
newData() and updateHook() were called (with newData first), there
was new data on the port.

We're not really happy with the current mechanism of 'newData', because we'd
like to have the data itself as an argument to newData instead of a pointer to
a port.

Peter

Use Eventport to trigger method

2010/9/27 Peter Soetens <peter [..] ...>:
> On Monday 27 September 2010 09:41:20 Steven Bellens wrote:
>> Hi,
>>
>> I'm writing an EKF in rtt2.0 using BFL. The code needs to update the
>> system model every timestep (e.g. 0.01 s) and update the measurement
>> model every moment new data arrives. The first I can implement in a
>> simple UpdateHook(), for the latter I would like to use an EventPort.
>> The manual tells me adding the InputPort as ->addPort->addEventPort
>> will trigger updateHook() when new data arrives. However, in that way
>> the explicit distinction between measurement and system update is gone
>> because in both cases the same method gets called. I can check in the
>> updateHook() whether is was the arrival of new data that caused my
>> component to wake up, but if this moment accidently coincides with the
>> moment my system model needs an update, the last one won't get
>> executed. Is there any functionality left in rtt 2.0 to point my
>> eventPort to a custom method?
>
> Yes, you can add and Input port just like in RTT 1.x as such:
>
> &#10;&gt; class Component : public TaskContext {&#10;&gt;        InputPort&lt;Foo&gt; input;&#10;&gt; //...&#10;&gt;        void newData(PortInterface*) {&#10;&gt;             // being called when data arrives on &#039;input&#039;&#10;&gt;        }&#10;&gt;&#10;&gt;        void updateHook() {&#10;&gt;            // periodic measurement update&#10;&gt;        }&#10;&gt;&#10;&gt;        Component(...) {&#10;&gt;               this-&gt;addEventPort(&quot;input&quot;,input,&#10;&gt; boost::bind(&amp;Component::newData, this, _1) )&#10;&gt;        }&#10;&gt; };&#10;&gt;
>
> So if only updateHook() is called, then it was a time trigger, if both
> newData() and updateHook() were called (with newData first), there
> was new data on the port.

I've implemented this in the code, however I get a segmentation fault
when I deploy the component:

6.805 [ Info ][DeploymentComponent::loadComponent] Ekf will be
triggered when new data is available on InputPort PoseWithCovEstIn
deployer-gnulinux: /usr/include/boost/smart_ptr/shared_ptr.hpp:418: T*
boost::shared_ptr< <template-parameter-1-1> >::operator->() const
[with T = RTT::internal::Signal<void(RTT::base::PortInterface*),
boost::function<void(RTT::base::PortInterface*)> >]: Assertion `px !=
0' failed.
/home/steven/src/svn/cturtle/install/ros/bin/rosrun: line 35: 19284
Aborted (core dumped) $exepath "$@"

It happens with whatever eventPort I declare in this way. Backtrace in appendix.

Steven

>
> We're not really happy with the current mechanism of 'newData', because we'd
> like to have the data itself as an argument to newData instead of a pointer to
> a port.
>
> Peter
>

Use Eventport to trigger method

2010/9/27 Peter Soetens <peter [..] ...>:
> On Monday 27 September 2010 09:41:20 Steven Bellens wrote:
>> Hi,
>>
>> I'm writing an EKF in rtt2.0 using BFL. The code needs to update the
>> system model every timestep (e.g. 0.01 s) and update the measurement
>> model every moment new data arrives. The first I can implement in a
>> simple UpdateHook(), for the latter I would like to use an EventPort.
>> The manual tells me adding the InputPort as ->addPort->addEventPort
>> will trigger updateHook() when new data arrives. However, in that way
>> the explicit distinction between measurement and system update is gone
>> because in both cases the same method gets called. I can check in the
>> updateHook() whether is was the arrival of new data that caused my
>> component to wake up, but if this moment accidently coincides with the
>> moment my system model needs an update, the last one won't get
>> executed. Is there any functionality left in rtt 2.0 to point my
>> eventPort to a custom method?
>
> Yes, you can add and Input port just like in RTT 1.x as such:
>
> &#10;&gt; class Component : public TaskContext {&#10;&gt;        InputPort&lt;Foo&gt; input;&#10;&gt; //...&#10;&gt;        void newData(PortInterface*) {&#10;&gt;             // being called when data arrives on &#039;input&#039;&#10;&gt;        }&#10;&gt;&#10;&gt;        void updateHook() {&#10;&gt;            // periodic measurement update&#10;&gt;        }&#10;&gt;&#10;&gt;        Component(...) {&#10;&gt;               this-&gt;addEventPort(&quot;input&quot;,input,&#10;&gt; boost::bind(&amp;Component::newData, this, _1) )&#10;&gt;        }&#10;&gt; };&#10;&gt;
>
> So if only updateHook() is called, then it was a time trigger, if both
> newData() and updateHook() were called (with newData first), there
> was new data on the port.

I've implemented this in the code, however I get a segmentation fault
when I deploy the component:

6.805 [ Info ][DeploymentComponent::loadComponent] Ekf will be
triggered when new data is available on InputPort PoseWithCovEstIn
deployer-gnulinux: /usr/include/boost/smart_ptr/shared_ptr.hpp:418: T*
boost::shared_ptr< <template-parameter-1-1> >::operator->() const
[with T = RTT::internal::Signal<void(RTT::base::PortInterface*),
boost::function<void(RTT::base::PortInterface*)> >]: Assertion `px !=
0' failed.
/home/steven/src/svn/cturtle/install/ros/bin/rosrun: line 35: 19284
Aborted (core dumped) $exepath "$@"

It happens with whatever eventPort I declare in this way. Backtrace in appendix.

Steven

>
> We're not really happy with the current mechanism of 'newData', because we'd
> like to have the data itself as an argument to newData instead of a pointer to
> a port.
>
> Peter
>

Use Eventport to trigger method

On Monday 27 September 2010 13:43:42 Steven Bellens wrote:
> 2010/9/27 Peter Soetens <peter [..] ...>:
> > On Monday 27 September 2010 09:41:20 Steven Bellens wrote:
> >> Hi,
> >>
> >> I'm writing an EKF in rtt2.0 using BFL. The code needs to update the
> >> system model every timestep (e.g. 0.01 s) and update the measurement
> >> model every moment new data arrives. The first I can implement in a
> >> simple UpdateHook(), for the latter I would like to use an EventPort.
> >> The manual tells me adding the InputPort as ->addPort->addEventPort
> >> will trigger updateHook() when new data arrives. However, in that way
> >> the explicit distinction between measurement and system update is gone
> >> because in both cases the same method gets called. I can check in the
> >> updateHook() whether is was the arrival of new data that caused my
> >> component to wake up, but if this moment accidently coincides with the
> >> moment my system model needs an update, the last one won't get
> >> executed. Is there any functionality left in rtt 2.0 to point my
> >> eventPort to a custom method?
> >
> > Yes, you can add and Input port just like in RTT 1.x as such:
> >
> > &#10;&gt; &gt; class Component : public TaskContext {&#10;&gt; &gt;        InputPort&lt;Foo&gt; input;&#10;&gt; &gt; //...&#10;&gt; &gt;        void newData(PortInterface*) {&#10;&gt; &gt;             // being called when data arrives on &#039;input&#039;&#10;&gt; &gt;        }&#10;&gt; &gt; &#10;&gt; &gt;        void updateHook() {&#10;&gt; &gt;            // periodic measurement update&#10;&gt; &gt;        }&#10;&gt; &gt; &#10;&gt; &gt;        Component(...) {&#10;&gt; &gt;               this-&gt;addEventPort(&quot;input&quot;,input,&#10;&gt; &gt; boost::bind(&amp;Component::newData, this, _1) )&#10;&gt; &gt;        }&#10;&gt; &gt; };&#10;&gt; &gt;
> >
> > So if only updateHook() is called, then it was a time trigger, if both
> > newData() and updateHook() were called (with newData first), there
> > was new data on the port.
>
> I've implemented this in the code, however I get a segmentation fault
> when I deploy the component:
>
> 6.805 [ Info ][DeploymentComponent::loadComponent] Ekf will be
> triggered when new data is available on InputPort PoseWithCovEstIn
> deployer-gnulinux: /usr/include/boost/smart_ptr/shared_ptr.hpp:418: T*
> boost::shared_ptr< <template-parameter-1-1> >::operator->() const
> [with T = RTT::internal::Signal<void(RTT::base::PortInterface*),
> boost::function<void(RTT::base::PortInterface*)> >]: Assertion `px !=
> 0' failed.
> /home/steven/src/svn/cturtle/install/ros/bin/rosrun: line 35: 19284
> Aborted (core dumped) $exepath "$@"
>
> It happens with whatever eventPort I declare in this way. Backtrace in
> appendix.

Fixed on gitorious/toolchain-2.0 branch.

I'll try to figure out why the unit tests did not catch this...

Peter

Use Eventport to trigger method

On Monday 27 September 2010 13:43:42 Steven Bellens wrote:
> 2010/9/27 Peter Soetens <peter [..] ...>:
> > On Monday 27 September 2010 09:41:20 Steven Bellens wrote:
> >> Hi,
> >>
> >> I'm writing an EKF in rtt2.0 using BFL. The code needs to update the
> >> system model every timestep (e.g. 0.01 s) and update the measurement
> >> model every moment new data arrives. The first I can implement in a
> >> simple UpdateHook(), for the latter I would like to use an EventPort.
> >> The manual tells me adding the InputPort as ->addPort->addEventPort
> >> will trigger updateHook() when new data arrives. However, in that way
> >> the explicit distinction between measurement and system update is gone
> >> because in both cases the same method gets called. I can check in the
> >> updateHook() whether is was the arrival of new data that caused my
> >> component to wake up, but if this moment accidently coincides with the
> >> moment my system model needs an update, the last one won't get
> >> executed. Is there any functionality left in rtt 2.0 to point my
> >> eventPort to a custom method?
> >
> > Yes, you can add and Input port just like in RTT 1.x as such:
> >
> > &#10;&gt; &gt; class Component : public TaskContext {&#10;&gt; &gt;        InputPort&lt;Foo&gt; input;&#10;&gt; &gt; //...&#10;&gt; &gt;        void newData(PortInterface*) {&#10;&gt; &gt;             // being called when data arrives on &#039;input&#039;&#10;&gt; &gt;        }&#10;&gt; &gt; &#10;&gt; &gt;        void updateHook() {&#10;&gt; &gt;            // periodic measurement update&#10;&gt; &gt;        }&#10;&gt; &gt; &#10;&gt; &gt;        Component(...) {&#10;&gt; &gt;               this-&gt;addEventPort(&quot;input&quot;,input,&#10;&gt; &gt; boost::bind(&amp;Component::newData, this, _1) )&#10;&gt; &gt;        }&#10;&gt; &gt; };&#10;&gt; &gt;
> >
> > So if only updateHook() is called, then it was a time trigger, if both
> > newData() and updateHook() were called (with newData first), there
> > was new data on the port.
>
> I've implemented this in the code, however I get a segmentation fault
> when I deploy the component:
>
> 6.805 [ Info ][DeploymentComponent::loadComponent] Ekf will be
> triggered when new data is available on InputPort PoseWithCovEstIn
> deployer-gnulinux: /usr/include/boost/smart_ptr/shared_ptr.hpp:418: T*
> boost::shared_ptr< <template-parameter-1-1> >::operator->() const
> [with T = RTT::internal::Signal<void(RTT::base::PortInterface*),
> boost::function<void(RTT::base::PortInterface*)> >]: Assertion `px !=
> 0' failed.
> /home/steven/src/svn/cturtle/install/ros/bin/rosrun: line 35: 19284
> Aborted (core dumped) $exepath "$@"
>
> It happens with whatever eventPort I declare in this way. Backtrace in
> appendix.

Fixed on gitorious/toolchain-2.0 branch.

I'll try to figure out why the unit tests did not catch this...

Peter

Use Eventport to trigger method

Hi all,

On Mon, Sep 27, 2010 at 10:03, Peter Soetens <peter [..] ...> wrote:
> On Monday 27 September 2010 09:41:20 Steven Bellens wrote:
>> Hi,
>>
>> I'm writing an EKF in rtt2.0 using BFL. The code needs to update the
>> system model every timestep (e.g. 0.01 s) and update the measurement
>> model every moment new data arrives. The first I can implement in a
>> simple UpdateHook(), for the latter I would like to use an EventPort.
>> The manual tells me adding the InputPort as ->addPort->addEventPort
>> will trigger updateHook() when new data arrives. However, in that way
>> the explicit distinction between measurement and system update is gone
>> because in both cases the same method gets called. I can check in the
>> updateHook() whether is was the arrival of new data that caused my
>> component to wake up, but if this moment accidently coincides with the
>> moment my system model needs an update, the last one won't get
>> executed. Is there any functionality left in rtt 2.0 to point my
>> eventPort to a custom method?
>
> Yes, you can add and Input port just like in RTT 1.x as such:
>
> &#10;&gt; class Component : public TaskContext {&#10;&gt;        InputPort&lt;Foo&gt; input;&#10;&gt; //...&#10;&gt;        void newData(PortInterface*) {&#10;&gt;             // being called when data arrives on &#039;input&#039;&#10;&gt;        }&#10;&gt;&#10;&gt;        void updateHook() {&#10;&gt;            // periodic measurement update&#10;&gt;        }&#10;&gt;&#10;&gt;        Component(...) {&#10;&gt;               this-&gt;addEventPort(&quot;input&quot;,input,&#10;&gt; boost::bind(&amp;Component::newData, this, _1) )&#10;&gt;        }&#10;&gt; };&#10;&gt;
>
> So if only updateHook() is called, then it was a time trigger, if both
> newData() and updateHook() were called (with newData first), there
> was new data on the port.
>
> We're not really happy with the current mechanism of 'newData', because we'd
> like to have the data itself as an argument to newData instead of a pointer to
> a port.

I'm helping Steven in designing our new estimation component.
For our estimation component it is important to now that the component
already running periodically (at each update we are doing a system
update implemented in the UpdateHook).
Before, in RTT 1.10, we had a Method that was executed as soon as new
measurementdata arrived on our inputport.
In RTT 2.0 however, the EventPort will trigger the UpdateHook and not
a user specified Method ...
So in our case, this will mean that the UpdateHook is triggered when
new data is arrived.
Since the UpdateHook was actually meant to do a system update, we have
to add a number of tests to the UpdateHook to check if the UpdateHook
was just being executed periodically or if it was triggered by new
data ...
I agree this is possible, but this requires extra tests to be
implemented. So we liked the 1.10 solution better (where we could
attach a self-chosen Method to our EventPort).

Could you also clarify the behavior that has to be expected when new
data arrives while the UpdateHook is being executed in a period way?
Will the call be discarded? Will it be executed as soon as the
UpdateHook (periodic call) finishes?

Tinne

Use Eventport to trigger method

Hi all,

On Mon, Sep 27, 2010 at 10:03, Peter Soetens <peter [..] ...> wrote:
> On Monday 27 September 2010 09:41:20 Steven Bellens wrote:
>> Hi,
>>
>> I'm writing an EKF in rtt2.0 using BFL. The code needs to update the
>> system model every timestep (e.g. 0.01 s) and update the measurement
>> model every moment new data arrives. The first I can implement in a
>> simple UpdateHook(), for the latter I would like to use an EventPort.
>> The manual tells me adding the InputPort as ->addPort->addEventPort
>> will trigger updateHook() when new data arrives. However, in that way
>> the explicit distinction between measurement and system update is gone
>> because in both cases the same method gets called. I can check in the
>> updateHook() whether is was the arrival of new data that caused my
>> component to wake up, but if this moment accidently coincides with the
>> moment my system model needs an update, the last one won't get
>> executed. Is there any functionality left in rtt 2.0 to point my
>> eventPort to a custom method?
>
> Yes, you can add and Input port just like in RTT 1.x as such:
>
> &#10;&gt; class Component : public TaskContext {&#10;&gt;        InputPort&lt;Foo&gt; input;&#10;&gt; //...&#10;&gt;        void newData(PortInterface*) {&#10;&gt;             // being called when data arrives on &#039;input&#039;&#10;&gt;        }&#10;&gt;&#10;&gt;        void updateHook() {&#10;&gt;            // periodic measurement update&#10;&gt;        }&#10;&gt;&#10;&gt;        Component(...) {&#10;&gt;               this-&gt;addEventPort(&quot;input&quot;,input,&#10;&gt; boost::bind(&amp;Component::newData, this, _1) )&#10;&gt;        }&#10;&gt; };&#10;&gt;
>
> So if only updateHook() is called, then it was a time trigger, if both
> newData() and updateHook() were called (with newData first), there
> was new data on the port.
>
> We're not really happy with the current mechanism of 'newData', because we'd
> like to have the data itself as an argument to newData instead of a pointer to
> a port.

I'm helping Steven in designing our new estimation component.
For our estimation component it is important to now that the component
already running periodically (at each update we are doing a system
update implemented in the UpdateHook).
Before, in RTT 1.10, we had a Method that was executed as soon as new
measurementdata arrived on our inputport.
In RTT 2.0 however, the EventPort will trigger the UpdateHook and not
a user specified Method ...
So in our case, this will mean that the UpdateHook is triggered when
new data is arrived.
Since the UpdateHook was actually meant to do a system update, we have
to add a number of tests to the UpdateHook to check if the UpdateHook
was just being executed periodically or if it was triggered by new
data ...
I agree this is possible, but this requires extra tests to be
implemented. So we liked the 1.10 solution better (where we could
attach a self-chosen Method to our EventPort).

Could you also clarify the behavior that has to be expected when new
data arrives while the UpdateHook is being executed in a period way?
Will the call be discarded? Will it be executed as soon as the
UpdateHook (periodic call) finishes?

Tinne

Use Eventport to trigger method

On Mon, 27 Sep 2010, Tinne De Laet wrote:

> Hi all,
>
> On Mon, Sep 27, 2010 at 10:03, Peter Soetens <peter [..] ...> wrote:
>> On Monday 27 September 2010 09:41:20 Steven Bellens wrote:
>>> Hi,
>>>
>>> I'm writing an EKF in rtt2.0 using BFL. The code needs to update the
>>> system model every timestep (e.g. 0.01 s) and update the measurement
>>> model every moment new data arrives. The first I can implement in a
>>> simple UpdateHook(), for the latter I would like to use an EventPort.
>>> The manual tells me adding the InputPort as ->addPort->addEventPort
>>> will trigger updateHook() when new data arrives. However, in that way
>>> the explicit distinction between measurement and system update is gone
>>> because in both cases the same method gets called. I can check in the
>>> updateHook() whether is was the arrival of new data that caused my
>>> component to wake up, but if this moment accidently coincides with the
>>> moment my system model needs an update, the last one won't get
>>> executed. Is there any functionality left in rtt 2.0 to point my
>>> eventPort to a custom method?
>>
>> Yes, you can add and Input port just like in RTT 1.x as such:
>>
>> &#10;&gt;&gt; class Component : public TaskContext {&#10;&gt;&gt;        InputPort&lt;Foo&gt; input;&#10;&gt;&gt; //...&#10;&gt;&gt;        void newData(PortInterface*) {&#10;&gt;&gt;             // being called when data arrives on &#039;input&#039;&#10;&gt;&gt;        }&#10;&gt;&gt;&#10;&gt;&gt;        void updateHook() {&#10;&gt;&gt;            // periodic measurement update&#10;&gt;&gt;        }&#10;&gt;&gt;&#10;&gt;&gt;        Component(...) {&#10;&gt;&gt;               this-&gt;addEventPort(&quot;input&quot;,input,&#10;&gt;&gt; boost::bind(&amp;Component::newData, this, _1) )&#10;&gt;&gt;        }&#10;&gt;&gt; };&#10;&gt;&gt;
>>
>> So if only updateHook() is called, then it was a time trigger, if both
>> newData() and updateHook() were called (with newData first), there
>> was new data on the port.
>>
>> We're not really happy with the current mechanism of 'newData', because we'd
>> like to have the data itself as an argument to newData instead of a pointer to
>> a port.
>
>
> I'm helping Steven in designing our new estimation component.
> For our estimation component it is important to now that the component
> already running periodically (at each update we are doing a system
> update implemented in the UpdateHook).
> Before, in RTT 1.10, we had a Method that was executed as soon as new
> measurementdata arrived on our inputport.
> In RTT 2.0 however, the EventPort will trigger the UpdateHook and not
> a user specified Method ...
> So in our case, this will mean that the UpdateHook is triggered when
> new data is arrived.
> Since the UpdateHook was actually meant to do a system update, we have
> to add a number of tests to the UpdateHook to check if the UpdateHook
> was just being executed periodically or if it was triggered by new
> data ...
> I agree this is possible, but this requires extra tests to be
> implemented. So we liked the 1.10 solution better (where we could
> attach a self-chosen Method to our EventPort).
>
One advantage of the 2.0 method is that the checking is done
_synchronously_ with the Computation in the component...

> Could you also clarify the behavior that has to be expected when new
> data arrives while the UpdateHook is being executed in a period way?
> Will the call be discarded? Will it be executed as soon as the
> UpdateHook (periodic call) finishes?
>
> Tinne

Herman

Use Eventport to trigger method

On Mon, 27 Sep 2010, Tinne De Laet wrote:

> Hi all,
>
> On Mon, Sep 27, 2010 at 10:03, Peter Soetens <peter [..] ...> wrote:
>> On Monday 27 September 2010 09:41:20 Steven Bellens wrote:
>>> Hi,
>>>
>>> I'm writing an EKF in rtt2.0 using BFL. The code needs to update the
>>> system model every timestep (e.g. 0.01 s) and update the measurement
>>> model every moment new data arrives. The first I can implement in a
>>> simple UpdateHook(), for the latter I would like to use an EventPort.
>>> The manual tells me adding the InputPort as ->addPort->addEventPort
>>> will trigger updateHook() when new data arrives. However, in that way
>>> the explicit distinction between measurement and system update is gone
>>> because in both cases the same method gets called. I can check in the
>>> updateHook() whether is was the arrival of new data that caused my
>>> component to wake up, but if this moment accidently coincides with the
>>> moment my system model needs an update, the last one won't get
>>> executed. Is there any functionality left in rtt 2.0 to point my
>>> eventPort to a custom method?
>>
>> Yes, you can add and Input port just like in RTT 1.x as such:
>>
>> &#10;&gt;&gt; class Component : public TaskContext {&#10;&gt;&gt;        InputPort&lt;Foo&gt; input;&#10;&gt;&gt; //...&#10;&gt;&gt;        void newData(PortInterface*) {&#10;&gt;&gt;             // being called when data arrives on &#039;input&#039;&#10;&gt;&gt;        }&#10;&gt;&gt;&#10;&gt;&gt;        void updateHook() {&#10;&gt;&gt;            // periodic measurement update&#10;&gt;&gt;        }&#10;&gt;&gt;&#10;&gt;&gt;        Component(...) {&#10;&gt;&gt;               this-&gt;addEventPort(&quot;input&quot;,input,&#10;&gt;&gt; boost::bind(&amp;Component::newData, this, _1) )&#10;&gt;&gt;        }&#10;&gt;&gt; };&#10;&gt;&gt;
>>
>> So if only updateHook() is called, then it was a time trigger, if both
>> newData() and updateHook() were called (with newData first), there
>> was new data on the port.
>>
>> We're not really happy with the current mechanism of 'newData', because we'd
>> like to have the data itself as an argument to newData instead of a pointer to
>> a port.
>
>
> I'm helping Steven in designing our new estimation component.
> For our estimation component it is important to now that the component
> already running periodically (at each update we are doing a system
> update implemented in the UpdateHook).
> Before, in RTT 1.10, we had a Method that was executed as soon as new
> measurementdata arrived on our inputport.
> In RTT 2.0 however, the EventPort will trigger the UpdateHook and not
> a user specified Method ...
> So in our case, this will mean that the UpdateHook is triggered when
> new data is arrived.
> Since the UpdateHook was actually meant to do a system update, we have
> to add a number of tests to the UpdateHook to check if the UpdateHook
> was just being executed periodically or if it was triggered by new
> data ...
> I agree this is possible, but this requires extra tests to be
> implemented. So we liked the 1.10 solution better (where we could
> attach a self-chosen Method to our EventPort).
>
One advantage of the 2.0 method is that the checking is done
_synchronously_ with the Computation in the component...

> Could you also clarify the behavior that has to be expected when new
> data arrives while the UpdateHook is being executed in a period way?
> Will the call be discarded? Will it be executed as soon as the
> UpdateHook (periodic call) finishes?
>
> Tinne

Herman

Use Eventport to trigger method

Hi Steven,

You can attach a callback to the EventPort, quite similar to what was
possible in the 1.x. You can see the doc of this at:
http://www.orocos.org/stable/documentation/rtt/v2.0.x/api/html/classRTT_...

You could also check both ports on the updateHook method, verifying that
a new data has arrived (read returns NewData).

You could also use the special updataHook function (from the Component's
Builder manual):
" If you want to know which port caused the wake-up, do not implement
|updateHook()| (ie remove this function from your component) and use
|updateHook(const std::vector<PortInterface*>& updatedPorts)| which
provides you a list of all ports having received new data. If your task
woke up for another reason, updatedPorts will be empty."

Regards,

Charles.

On 27/09/2010 09:41, Steven Bellens wrote:
> Hi,
>
> I'm writing an EKF in rtt2.0 using BFL. The code needs to update the
> system model every timestep (e.g. 0.01 s) and update the measurement
> model every moment new data arrives. The first I can implement in a
> simple UpdateHook(), for the latter I would like to use an EventPort.
> The manual tells me adding the InputPort as ->addPort->addEventPort
> will trigger updateHook() when new data arrives. However, in that way
> the explicit distinction between measurement and system update is gone
> because in both cases the same method gets called. I can check in the
> updateHook() whether is was the arrival of new data that caused my
> component to wake up, but if this moment accidently coincides with the
> moment my system model needs an update, the last one won't get
> executed. Is there any functionality left in rtt 2.0 to point my
> eventPort to a custom method? If not, how can I make this distinction
> explicit?
>
> Steven
>

Use Eventport to trigger method

On Monday 27 September 2010 09:55:53 Charles Lesire-Cabaniols wrote:
> Hi Steven,
>
> You can attach a callback to the EventPort, quite similar to what was
> possible in the 1.x. You can see the doc of this at:
> http://www.orocos.org/stable/documentation/rtt/v2.0.x/api/html/classRTT_1_1
> TaskContext.html#af5b63a9afc03ca89a4f884c7cc3048e8
>
> You could also check both ports on the updateHook method, verifying that
> a new data has arrived (read returns NewData).

What Steven says is that this can trigger a 'race' (being triggered by a
periodic update, while also data arrives on the port). It just occurs to me
that the event port will not cause updateHook to be called immediately because
we're running in periodic mode. The trigger will actually be ignored by the
component, and it will execute updateHook() + any event port callbacks when
the periodic timer expired.

If you want periodicity + aperiodicity in one component, you'll have to use
event ports for both modes. So, an OCL::TimerComponent that fires periodically
a port and your component (with non periodic Activity) that connects to that
port and connects its data port as you did before.

>
> You could also use the special updataHook function (from the Component's
> Builder manual):
> " If you want to know which port caused the wake-up, do not implement
>
> |updateHook()| (ie remove this function from your component) and use
> |updateHook(const std::vector<PortInterface*>& updatedPorts)| which
>
> provides you a list of all ports having received new data. If your task
> woke up for another reason, updatedPorts will be empty."

That functionality has been removed just before the release, because it forced
us to start/stop a component when addEventPort was called (this is still
documented as such, I'll update the docs to remove that).

Peter

Use Eventport to trigger method

On Monday 27 September 2010 09:55:53 Charles Lesire-Cabaniols wrote:
> Hi Steven,
>
> You can attach a callback to the EventPort, quite similar to what was
> possible in the 1.x. You can see the doc of this at:
> http://www.orocos.org/stable/documentation/rtt/v2.0.x/api/html/classRTT_1_1
> TaskContext.html#af5b63a9afc03ca89a4f884c7cc3048e8
>
> You could also check both ports on the updateHook method, verifying that
> a new data has arrived (read returns NewData).

What Steven says is that this can trigger a 'race' (being triggered by a
periodic update, while also data arrives on the port). It just occurs to me
that the event port will not cause updateHook to be called immediately because
we're running in periodic mode. The trigger will actually be ignored by the
component, and it will execute updateHook() + any event port callbacks when
the periodic timer expired.

If you want periodicity + aperiodicity in one component, you'll have to use
event ports for both modes. So, an OCL::TimerComponent that fires periodically
a port and your component (with non periodic Activity) that connects to that
port and connects its data port as you did before.

>
> You could also use the special updataHook function (from the Component's
> Builder manual):
> " If you want to know which port caused the wake-up, do not implement
>
> |updateHook()| (ie remove this function from your component) and use
> |updateHook(const std::vector<PortInterface*>& updatedPorts)| which
>
> provides you a list of all ports having received new data. If your task
> woke up for another reason, updatedPorts will be empty."

That functionality has been removed just before the release, because it forced
us to start/stop a component when addEventPort was called (this is still
documented as such, I'll update the docs to remove that).

Peter

Use Eventport to trigger method

On Mon, Sep 27, 2010 at 10:13, Peter Soetens <peter [..] ...> wrote:
> On Monday 27 September 2010 09:55:53 Charles Lesire-Cabaniols wrote:
>> Hi Steven,
>>
>> You can attach a callback to the EventPort, quite similar to what was
>> possible in the 1.x. You can see the doc of this at:
>> http://www.orocos.org/stable/documentation/rtt/v2.0.x/api/html/classRTT_1_1
>> TaskContext.html#af5b63a9afc03ca89a4f884c7cc3048e8
>>
>> You could also check both ports on the updateHook method, verifying that
>> a new data has arrived (read returns NewData).
>
> What Steven says is that this can trigger a 'race' (being triggered by a
> periodic update, while also data arrives on the port). It just occurs to me
> that the event port will not cause updateHook to be called immediately because
> we're running in periodic mode. The trigger will actually be ignored by the
> component, and it will execute updateHook() + any event port callbacks when
> the periodic timer expired.
>
> If you want periodicity + aperiodicity in one component, you'll have to use
> event ports for both modes. So, an OCL::TimerComponent that fires periodically
> a port and your component (with non periodic Activity) that connects to that
> port and connects its data port as you did before.

Clarfiying! Thanks.
So just to be sure: we use the OutputPort< RTT::os::Timer::TimerId >
mtimeoutEvent of the TimerComponent.
We connect it to one of our InputEventPorts which we bind with our own
SystemUpdate function.

>>
>> You could also use the special updataHook function (from the Component's
>> Builder manual):
>> " If you want to know which port caused the wake-up, do not implement
>>
>> |updateHook()| (ie remove this function from your component) and use
>> |updateHook(const std::vector<PortInterface*>& updatedPorts)| which
>>
>> provides you a list of all ports having received new data. If your task
>> woke up for another reason, updatedPorts will be empty."
>
> That functionality has been removed just before the release, because it forced
> us to start/stop a component when addEventPort was called (this is still
> documented as such, I'll update the docs to remove that).

Ok. Could you also add a section on coupling an EventPort with
self-chosen function?
That's is functionality I would use a lot.

Tinne

Use Eventport to trigger method

On Mon, Sep 27, 2010 at 10:13, Peter Soetens <peter [..] ...> wrote:
> On Monday 27 September 2010 09:55:53 Charles Lesire-Cabaniols wrote:
>> Hi Steven,
>>
>> You can attach a callback to the EventPort, quite similar to what was
>> possible in the 1.x. You can see the doc of this at:
>> http://www.orocos.org/stable/documentation/rtt/v2.0.x/api/html/classRTT_1_1
>> TaskContext.html#af5b63a9afc03ca89a4f884c7cc3048e8
>>
>> You could also check both ports on the updateHook method, verifying that
>> a new data has arrived (read returns NewData).
>
> What Steven says is that this can trigger a 'race' (being triggered by a
> periodic update, while also data arrives on the port). It just occurs to me
> that the event port will not cause updateHook to be called immediately because
> we're running in periodic mode. The trigger will actually be ignored by the
> component, and it will execute updateHook() + any event port callbacks when
> the periodic timer expired.
>
> If you want periodicity + aperiodicity in one component, you'll have to use
> event ports for both modes. So, an OCL::TimerComponent that fires periodically
> a port and your component (with non periodic Activity) that connects to that
> port and connects its data port as you did before.

Clarfiying! Thanks.
So just to be sure: we use the OutputPort< RTT::os::Timer::TimerId >
mtimeoutEvent of the TimerComponent.
We connect it to one of our InputEventPorts which we bind with our own
SystemUpdate function.

>>
>> You could also use the special updataHook function (from the Component's
>> Builder manual):
>> " If you want to know which port caused the wake-up, do not implement
>>
>> |updateHook()| (ie remove this function from your component) and use
>> |updateHook(const std::vector<PortInterface*>& updatedPorts)| which
>>
>> provides you a list of all ports having received new data. If your task
>> woke up for another reason, updatedPorts will be empty."
>
> That functionality has been removed just before the release, because it forced
> us to start/stop a component when addEventPort was called (this is still
> documented as such, I'll update the docs to remove that).

Ok. Could you also add a section on coupling an EventPort with
self-chosen function?
That's is functionality I would use a lot.

Tinne