[Rock-dev] <base/motion_command.h>

[Sylvain Joyeux]

On 11/08/2011 11:56 AM, Chris Müller wrote:
> Adding a timestamp would be in my opinion the best practical way to
> achieve this. Someone mention we also have a timestamp estimator or
> something like that. But that feels only like a hack and i guess it
> results only in unnecessary overhead or estimation failures in which the
> accuracy of predictions only suffers more.
The timestamp estimator needs periodic inputs and does not provide you 
with a latency measurement.
> I have currently a naive implementation where i setup a timestamp in my
> own module, when a motion command is received on a port. But thats
> currently pretty bad, because the time is depending on the frequency of
> my own update hook (if its slower then motion commands arrives, its
> already a mess).
Why are you periodic and not port-triggered ? If your estimator is 
deployed in the RT scheduler, does not do any memory allocation, and is 
using a suitable priority, then you could neglect the latency and create 
the timestamp on input.
> Its even getting worse when to replay log-data e.g. with vizkit. The
> update hook is already called one time though you haven't started the
> log stream.
So what ? You don't get any input data, so you actually know what's 
happening.
> Calculating a time difference between the first samples is
> simple impossible with that approach.
True, but not for the reasons you mention. The issue is that vizkit does 
*not* replay in a realtime fashion, as the timestamping on the logfile 
does not allow it to do so (yet).
> For each kind of application using a recursive bayes filtering you
> probably need the real time a motion command is related to.
You need the time at which the actual motors are actuated according to 
your motion command. Which is not what the motion command will provide 
you. That was the general idea about not timestamping those: these 
timestamps are not strictly usable for estimation.
> For that issue we could also work on a lower level of the
> base/actuator/commands which provides already timestamps.
> But i'm currently lacking some experience to decide if it makes
> implementations only unnecessary complex for a better accuracy.
>
> Only want to give more background informations in detail about my issue.
Don't get me wrong: I *do* believe that timestamping the motion commands 
is not  such a bad idea anyway, as it would allow the measurement of 
control loop latencies.

However, for the purpose of a motion model, I am wondering why you don't 
use the motors reported PWM (since you are using the hbridges, you can 
do that). That would remove the controller => actuator driver => 
actuator latency, and work regardless of the controller / control method 
being used (and, for instance, of the presence of ramping).
> Alex is not available this week, is it? But no need to hurry.
He's coming back next week.

-- 
Sylvain Joyeux
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
-----------------------------------------------------------------------