[Rock-dev] Discussion: Timestamped Commands in base/types

[Matthias Goldhoorn]

On 05.11.2013 10:54, Steffen Planthaber wrote:
> Hello,
>
> My comments below.
>
> Am 04.11.2013 10:42, schrieb Sylvain Joyeux:
>> While you make an interesting case for the separation of command vs.
>> sample, I have an issue with that. Namely, "to me", an interesting
>> byproduct of timestamping commands is the ability to measure latency in
>> the control loop pipeline. To achieve this, we would need to have
>> timestamps in the control dataflow, instead of "mirroring it".
> Yes, I also think so, knowing the latency can be beneficial.

+1 for adding time to commands
>
>> If there is *also* a need to timestamp when the command got actually
>> sent by the component that processed it, then we either need two
>> timestamps (yuk), or a way to associate the two timestamps (maybe a
>> timestamp pair sent by the monitored component, which associates the
>> command timestamp with the reception timestamp ?)

-1 don't see it either
Normally the command depends on some ingoing sensor data, the delay for 
fusion could/should be calculated staticly.

> The question is: Is it important to know the latency after execution of
> a command?
> Currently I don't see a situation where this is necessary.
> The executing component can evaluate the latency and, if the command is
> executed, return the command with the timestamp of the execution time.
> In my opinion, there is no need for an second time field.


+1 returning with the updated-stamp if really needed
>
>
> When we can agree on having timestamps in the commands, we don't need to
> discuss the implementation questions below (Nevertheless I commented them).
> In case we decide to have Timestamps in the commands itself, I would
> propose to use typedefs to create base::samples::commands types in order
> to differentiate between commands to be executed and those in telemetry
> (i.e. port types, base::commands for commands being executed,
> base::samples::commands for telemetry). Even though they are compatible,
> at least the port definition tells the difference.
>
>
>
>> On 11/01/2013 03:45 PM, Steffen Planthaber wrote:
>>> What do you think?
>> Implementation-wise, you could have used a simple header class and
>> multiple inheritance, which is IMO a lot simpler than templating. No
>> need for any copy/pasting.
> I thought about that as well. When no initializations are used, this is
> true. With initialization the template increases the maintainability of
> timestamped classes.
>
>> What I am strongly against is the initialization of the timestamp with
>> Time::now(). Timestamps need to be carefully thought before they get
>> set, and Time::now() is usually *not* the right answer. This is
>> promoting bad habits.
> Well, the case i started with was the one of commands. When you want a
> timestamped command set the time there, it will definitely be
> Time::now(), when the timestamped data was created.
>
>> Moreover, since the time field is public, having a setter which just
>> sets the field is ... not really needed.
> Well the existence promotes the importance of setting the timestamp when
> a better source is available than Time::now().
>
>
> Best,
> Steffen
>
>


-- 
  Dipl.-Inf. Matthias Goldhoorn
  Space and Underwater Robotic

  Universität Bremen
  FB 3 - Mathematik und Informatik
  AG Robotik
  Robert-Hooke-Straße 5
  28359 Bremen, Germany

  Tel.:     +49 421 178 45-4193
  Zentrale: +49 421 178 45-6550
  Fax:      +49 421 178 45-4150
  E-Mail:   matthias.goldhoorn at uni-bremen.de

  Weitere Informationen: http://www.informatik.uni-bremen.de/robotik