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

[Steffen Planthaber]

Hello,

My project has a need to monitor the execution times of commands.
I think having this feature has some advanteges:

1. Manual evaluation of behaviors becomes easier (one can evaluate 
whether a sensor value peak was recorded before or after execution of 
the command)

2. In our project, we are creating an automated monitoring of sensor 
values, which is natuarally dependent on the commands executed by the 
robot (e.g. when sending a turn command, the direction values will 
change). Out monitoring compares the expectation of sensor values with 
the recorded ones for the active command. For this to work best, the 
hardware driver should create and send a timestamped command back 
directly after the commands were sent to the driver.

I already pushed a proposal to base/types:master because the driver we 
need to provide the execution time is the public aria driver of rock, so 
there was no other choice than putting the new class there, in order to 
prevent the aria driver to stop working for externals.

Nevertheless we have two things to discuss:

1. Is there a public need for timestamped command feedback or should 
thes be removed again? I my opinion there is reason to have them (see avove)

2. If we want to keep timestamped commands, do we also keep the actual 
implementation?

My solution uses a template class to inherit from the actual command 
class, so there are two types for each command: the command and a 
command sample (or, i.e. commands::Motion2D and samples::Motion2D)

I chose this way to let the samples and commands be clearly seperable. 
Nobody whould want to execute a command sample already executed (having 
two types, it can't happen by accident because the port types are 
different). Also the timstamped command is not really a command anymore, 
it is part of the telemetry and as such shouldn't be executed by any 
hardware.

Another solution whould be to add timestamps globally to commands, but 
this I think is more error prone because it is easier to mix up actual 
commands and telemetry comamnds, as their ports are compatible.

I chose to use a template class for the implementation because it makes 
it very easy to build a timestamped class from its original type.

Another solution whould be to use "normal" class inheritance. But new 
features would have to be implemented for one class first and then 
copy/pasted to all existing timestamped classes, so i prefered the 
solution above using the template, which prevents errors from copy/pasting.

Currently the creation of samples::Motion2D (timestamped version) is 
simple as this:
namespace samples{
   class Motion2D : public TimeStamped< commands::Motion2D >{}
}


What do you think?


Kind regards,
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
  -----------------------------------------------------------------------