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

[Sylvain Joyeux]

On 11/05/2013 10:54 AM, Steffen Planthaber wrote:
>> 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?
What is equally important is to log the latency !

> 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.
I (again) don't see the need to make a difference. If one wants to use a 
"mirrored command" (telemetry command) as a command, *he can*. It would 
even work. I don't see a reason to limit that. In any case, port names 
(not the datatype) are usually what we use to give this kind of information.

Also: outputting timestamp pairs (instead of full commands) would 
actually make it extremely explicit, as well as allow for the 
development of more generic latency-monitoring tools (since the type 
that reports the latency would be datatype-independent)

And, FYI, typedefs get resolved to the types they point to, so the 
difference will actually not show up in the tooling (only in the oroGen 
file)

>> 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.
Fair enough. Did not think about the problem of assignation.

I do, however, have an issue with the way you did it. Why not use an 
implicit copy constructor ? You are basically assuming that your base 
class does not have a set() method ...

Also, the getBase method is unneeded. Downcasting is done automatically.

>> 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.
Yes, and it is wrong in the general case. I did not mean this as a 
personal attack, it is simply a comment that the final type should IMO 
have no such method.

>> 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().
???? In which world ?

Since when having a setter makes it less or more likely that one would 
override *the default* ? Or that he would not call a method called 
updateTimestamp() to ... update the timestamp ?

My point is: when one sets a timestamp field, he has to *think*. To me,

   bla.time = base::Time::now();

is good because it is explicit

   commandType bla;

is wrong because the programmer will not even give a thought. And

   bla.updateTime()

is wrong because it is implicitly setting the value to base::Time::now()
-- 
Sylvain Joyeux (Dr.Ing.)
Space & Security Robotics

!!! Achtung, neue Telefonnummer!!!

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 178-454136
Fax:   +49 (0)421 218-454150
E-Mail: robotik 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
-----------------------------------------------------------------------