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

[Chris Müller]

On 08.11.2011 11:07, Matthias Goldhoorn wrote:
> On 08.11.2011 10:27, Sylvain Joyeux wrote:
>> On 11/07/2011 03:36 PM, Matthias Goldhoorn wrote:
>>> Please add (if not availible) an constructor and set the time to zero on
>>> the initialization.
>> No need since Time initializes itself to a null time by default.
>>
>>> What's with the other motion commands like AUVPositionCommand and
>>> MotionCommand2D, from my point of view there should be also an
>>> timestamp.
>>>
>>> Should it be added to all MotionCommands to be consistent?
>> I agree in principle. However, these types are very widely used and we
>> are in a release process, so do NOT change things unless it is
>> absolutely required. Which might be the case for AUVMotionCommand.
>>
>> In any case, I'd like you to wait for Alex to come back so that he can
>> give his opinion. Or (even better) a more in-depth discussion on the
>> long-term future of these types which are completely ad-hoc right now.
>>
> Okay, we wait for alex for furthur discussions...
>
> Background info: the change for the AUVMotionCommand is now needed to
> calculate the delta-movement for an simple motion estimation.
> For this the time is definetly needed.
> All controlloops should also check if the last sample is not too old.
> I'm not sure how this is done currently...
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.

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).

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. Calculating a time difference between the first samples is 
simple impossible with that approach. I know we could also throw away 
the samples which are concerned with that problem, but i would be 
interested to keep any single sample as possible for my prediction.

For each kind of application using a recursive bayes filtering you 
probably need the real time a motion command is related to.
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.

Alex is not available this week, is it? But no need to hurry.

Greetings
Chris