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

[Steffen Planthaber]

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.

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

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.


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


-- 
  Steffen Planthaber
  Weltraumrobotik

  ###############################################
  #### Neue Anschrift und neue Kontaktdaten! ####
  ###############################################

  DFKI Bremen
  Robotics Innovation Center
  Robert-Hooke-Str.5
  28359 Bremen, Germany

  Phone: +49 (0)421 178 45 - 4125
  Fax:   +49 (0)421 218 - 64150
  E-Mail: steffen.planthaber at dfki.de

  Weitere Informationen: http://www.dfki.de/robotik
  -----------------------------------------------------------------------
  Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
  Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
  Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
  (Vorsitzender) Dr. Walter Olthoff
  Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
  Amtsgericht Kaiserslautern, HRB 2313
  Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
  USt-Id.Nr.:    DE 148646973
  Steuernummer:  19/673/0060/3
  -----------------------------------------------------------------------