[Rock-dev] Discussion: Timestamped Commands in base/types
Steffen Planthaber
Steffen.Planthaber at dfki.de
Tue Nov 5 10:54:24 CET 2013
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
-----------------------------------------------------------------------
More information about the Rock-dev
mailing list