Hello,
If a TaskContext reads a data item from a dataport, is there any way it
can check _when_ that data item was put into the port?
In the past, I exchanged data in a struct, like
struct my_type {
timestamp_t timestamp;
other data;
};
then the sender TC set the timestamp before sending out the struct.
but this timestamping should ideally be something that the
infrastructure (orocos) handles, so I am wondering if it is already
there. A quick look at
http://www.orocos.org/stable/documentation/rtt/v2.x/api/html/classRTT_1_...
doesn't reveal anything.
Regards,
Sagar
Timestamps for port data
Hi Sagar,
There have been many long discussions about this already in the past.
The consensus was that a timestamp is part of the data, since some
components merely route data, and then you don't want the timestamp to
be updated. The timestamp should reflect the time of measurement, not
the time of processing.
Rock has a system to allign data with different timestams for
algorithms which require alligned data, but then all your data must be
known to typegen/orogen, and you'll have to use the CORBA transport to
communicate this data between processes.
Peter
On Fri, Oct 12, 2012 at 3:23 PM, Sagar Behere <sagar [dot] behere [..] ...> wrote:
> Hello,
>
> If a TaskContext reads a data item from a dataport, is there any way it
> can check _when_ that data item was put into the port?
>
> In the past, I exchanged data in a struct, like
>
> struct my_type {
> timestamp_t timestamp;
> other data;
> };
>
> then the sender TC set the timestamp before sending out the struct.
>
> but this timestamping should ideally be something that the
> infrastructure (orocos) handles, so I am wondering if it is already
> there. A quick look at
>
> http://www.orocos.org/stable/documentation/rtt/v2.x/api/html/classRTT_1_...
>
> doesn't reveal anything.
>
> Regards,
> Sagar
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
Timestamps for port data
On 10/12/2012 04:22 PM, Peter Soetens wrote:
> and you'll have to use the CORBA transport to
> communicate this data between processes.
I would also be interested to know what part of the Rock documentation /
rock-related discussions made you believe that ? I would very much like
to fix this...
Sylvain
Timestamps for port data
On Mon, Oct 15, 2012 at 10:23 AM, Sylvain Joyeux
<sylvain [dot] joyeux [..] ...
> On 10/12/2012 04:22 PM, Peter Soetens wrote:
>>
>> There have been many long discussions about this already in the past.
>> The consensus was that a timestamp is part of the data, since some
>> components merely route data, and then you don't want the timestamp to
>> be updated. The timestamp should reflect the time of measurement, not
>> the time of processing.
>
> Yes and no. The most important timestamp should reflect the time of
> measurement. Now, having the time of processing also allows you to have a
> detailed measure of the processing latency.
>
>> Rock has a system to allign data with different timestams for
>> algorithms which require alligned data, but then all your data must be
>> known to typegen/orogen, and you'll have to use the CORBA transport to
>> communicate this data between processes.
correction: between <<distributed>> processes
>
> OMG. I really have to dispel some myths about RTT and Rock
>
> There is NOTHING in Rock that requires that you use the CORBA transport
for
> data flow. NOTHING. All of Rock can work on MQ or other transports, as
soon
> as these transports are integrated in orogen/typegen.
I'm aware of this disclaimer, I was just reflecting on the current state of
supported
transports in Rock’s component development tool, oroGen.
>
> MOST of the algorithmic parts in Rock are RTT-independent. Therefore, they
> are also orogen independent. The stream aligner is no different from that.
> This is even said at the bottom of
>
http://www.rock-robotics.org/stable/documentation/data_processing/stream...
.
> The code is at
> http://www.rock-robotics.org/stable/pkg/drivers/aggregator/index.html.
What
> oroGen provides is an easy-to-use, model-based interface to the stream
> aligner.
Ack. I was cutting some corners. The rock libraries can indeed be used by
Sagar to allign his data streams, but only in a component out of the box
when using orogen. Correct ?
Peter
Timestamps for port data
On 10/17/2012 12:29 PM, Peter Soetens wrote:
> On Mon, Oct 15, 2012 at 10:23 AM, Sylvain Joyeux
> <sylvain [dot] joyeux [..] ...
> >>
> >> There have been many long discussions about this already in the past.
> >> The consensus was that a timestamp is part of the data, since some
> >> components merely route data, and then you don't want the timestamp to
> >> be updated. The timestamp should reflect the time of measurement, not
> >> the time of processing.
> >
> > Yes and no. The most important timestamp should reflect the time of
> > measurement. Now, having the time of processing also allows you to
> have a
> > detailed measure of the processing latency.
> >
> >> Rock has a system to allign data with different timestams for
> >> algorithms which require alligned data, but then all your data must be
> >> known to typegen/orogen, and you'll have to use the CORBA transport to
> >> communicate this data between processes.
>
> correction: between <<distributed>> processes
>
> >
> > OMG. I really have to dispel some myths about RTT and Rock
> >
> > There is NOTHING in Rock that requires that you use the CORBA
> transport for
> > data flow. NOTHING. All of Rock can work on MQ or other transports,
> as soon
> > as these transports are integrated in orogen/typegen.
>
> I'm aware of this disclaimer, I was just reflecting on the current
> state of supported
> transports in Rock’s component development tool, oroGen.
Which is also the state of transports in the orocos toolchain's typegen
tool. You indeed *are cutting corner, and I am starting to wonder
> > MOST of the algorithmic parts in Rock are RTT-independent.
> Therefore, they
> > are also orogen independent. The stream aligner is no different from
> that.
> > This is even said at the bottom of
> >
> http://www.rock-robotics.org/stable/documentation/data_processing/stream....
> > The code is at
> >
> http://www.rock-robotics.org/stable/pkg/drivers/aggregator/index.html.
> What
> > oroGen provides is an easy-to-use, model-based interface to the stream
> > aligner.
>
> Ack. I was cutting some corners. The rock libraries can indeed be used
> by Sagar to allign his data streams, but only in a component out of
> the box when using orogen. Correct ?
That depends on what you mean by "out of the box" part. If it is
"without knowing the stream aligner API", then yes.
Sylvain
Timestamps for port data
On 10/18/2012 09:48 AM, Sylvain Joyeux wrote:
>> >
>> > OMG. I really have to dispel some myths about RTT and Rock
>> >
>> > There is NOTHING in Rock that requires that you use the CORBA
>> transport for
>> > data flow. NOTHING. All of Rock can work on MQ or other transports,
>> as soon
>> > as these transports are integrated in orogen/typegen.
>>
>> I'm aware of this disclaimer, I was just reflecting on the current
>> state of supported
>> transports in Rock’s component development tool, oroGen.
> Which is also the state of transports in the orocos toolchain's
> typegen tool. You indeed *are cutting corner, and I am starting to wonder
>
Hit CTRL+Enter while writing the mail ... Grmbl. Forget about the last
part of the sentence ... Just random thoughts.
Timestamps for port data
Op donderdag 18 oktober 2012 schreef Sylvain Joyeux (sylvain [dot] joyeux [..] ...)
het volgende:
> On 10/18/2012 09:48 AM, Sylvain Joyeux wrote:
>
>> >
>>> > OMG. I really have to dispel some myths about RTT and Rock
>>> >
>>> > There is NOTHING in Rock that requires that you use the CORBA
>>> transport for
>>> > data flow. NOTHING. All of Rock can work on MQ or other transports, as
>>> soon
>>> > as these transports are integrated in orogen/typegen.
>>>
>>> I'm aware of this disclaimer, I was just reflecting on the current state
>>> of supported
>>> transports in Rock’s component development tool, oroGen.
>>>
>> Which is also the state of transports in the orocos toolchain's typegen
>> tool. You indeed *are cutting corner, and I am starting to wonder
>>
>> Hit CTRL+Enter while writing the mail ... Grmbl. Forget about the last
> part of the sentence ... Just random thoughts.
Yes, I understand, but now you've got me starting to wonder too of course :)
Peter
Timestamps for port data
On 10/12/2012 04:22 PM, Peter Soetens wrote:
> There have been many long discussions about this already in the past.
> The consensus was that a timestamp is part of the data, since some
> components merely route data, and then you don't want the timestamp to
> be updated. The timestamp should reflect the time of measurement, not
> the time of processing.
Yes and no. The most important timestamp should reflect the time of
measurement. Now, having the time of processing also allows you to have
a detailed measure of the processing latency.
> Rock has a system to allign data with different timestams for
> algorithms which require alligned data, but then all your data must be
> known to typegen/orogen, and you'll have to use the CORBA transport to
> communicate this data between processes.
OMG. I really have to dispel some myths about RTT and Rock
There is NOTHING in Rock that requires that you use the CORBA transport
for data flow. NOTHING. All of Rock can work on MQ or other transports,
as soon as these transports are integrated in orogen/typegen.
MOST of the algorithmic parts in Rock are RTT-independent. Therefore,
they are also orogen independent. The stream aligner is no different
from that. This is even said at the bottom of
http://www.rock-robotics.org/stable/documentation/data_processing/stream....
The code is at
http://www.rock-robotics.org/stable/pkg/drivers/aggregator/index.html.
What oroGen provides is an easy-to-use, model-based interface to the
stream aligner.