[Rock-dev] Discussion: Timestamped Commands in base/types
Sylvain Joyeux
sylvain.joyeux at dfki.de
Tue Nov 5 11:14:43 CET 2013
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
-----------------------------------------------------------------------
More information about the Rock-dev
mailing list