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

[Janosch Machowinski]

On 30.11.2011 11:01, Alexander Duda wrote:
> On Wed, 2011-11-30 at 10:46 +0100, Janosch Machowinski wrote:
>> On 29.11.2011 19:26, Sylvain Joyeux wrote:
>>> On 11/29/2011 02:20 PM, Matthias Goldhoorn wrote:
>>>> I currently cleaning up some "controllers" for this i would like to
>>>> check how old the last message really is.
>>>> I would prevent something like:
>>>>
>>>> if(last_message_time - base::Time::now()).toSeconds()>    foo) throw_error;
>>>>
>>>> do something....
>>>>
>>>> last_message_time = base::Time:now();
>>>>
>>>>
>>>> instead i would like to use
>>>>
>>>>
>>>> if(current_message.time - base::Time::now()).toSeconds()>    foo) throw_error;
>>>>
>>>> What make more sense from my point of view, all old controller dosn't
>>>> need to change, but i don't want to create and "not so good written"
>>>> controller only because, "yeah we think it make sense, but no we dont'
>>>> want to change because we dont't want changes in base stuff even it make
>>>> sense"
>>> Well.. Life is hard.
>>>
>>> I do find your attitude commendable. Now here are the hard facts: not
>>> everyone has a lot of time on their hand to update log files and make
>>> sure that everything is fine with the proposed change. So, unless there
>>> is a very important and good reason, changing base types should not be
>>> done whenever someone feels like it. Which is why we discuss and vote on
>>> this mailing list.
>>>
>>> Using base::Time::now() as the "last message timestamp" is suboptimal,
>>> agreed. Now:
>>>
>>> * if you make sure that you don't introduce latencies (i.e. know what
>>>      you are doing with the stream aligner, or even better not use it in
>>>      control loop), and introduce proper priorities and realtime tasks,
>>>      the latency that you are trying to measure here won't be a problem.
>>> * in general, if you are trying to implement timeout, well, the
>>>      difference between the "wakeup time" and "data time" are low enough
>>>      that you can still do timeouting.
>> For me this change looks reasonable.
>> As we do not (as far as I know) replay motion command,
>> I also don't see any problems with updating logs.
>> And it is bad practice to 'grave types into stone'. If there is
>> a good reason to change them do it. We introduced stable and
>> master for this reason !
>> Also I remember a rule that any type in base should have a
>> timestamp anyway...
>>
>> +1 change it, makes sense
>>
> rock-replay will complain about incompatible types if someone is loading
> the hole folder which is a common practice in the lab
>
> Alex
>
Didn't jakob add a patch,  that removes the incompatible stream,
but still playes back the rest ?

-- 
  Dipl. Inf. Janosch Machowinski
  SAR-&  Sicherheitsrobotik

  DFKI Bremen
  Robotics Innovation Center
  Robert-Hooke-Straße 5
  28359 Bremen, Germany

  Phone: +49 (0)421 178 45-6614
  Fax:   +49 (0)421 178 45-4150
  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
  -----------------------------------------------------------------------