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

Alexander Duda Alexander.Duda at dfki.de
Wed Nov 30 11:01:04 CET 2011


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

-- 
Dipl.-Ing. Alexander Duda 
Unterwasserrobotik

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

Phone: +49 (0)421 178-456620
Fax:   +49 (0)421 178-454150
E-Mail: alexander.duda 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