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:
>
>

> 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) )
>        }
> };
> 

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 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
>

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:
>
>

> 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) )
>        }
> };
> 

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 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
>

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:
>
>

> 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) )
>        }
> };
> 

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

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:
>
>

> 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) )
>        }
> };
> 

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

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

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