[Rock-dev] Discussion: Timestamped Commands in base/types
Steffen Planthaber
Steffen.Planthaber at dfki.de
Fri Nov 1 15:45:08 CET 2013
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
-----------------------------------------------------------------------
More information about the Rock-dev
mailing list