Re: FK and Jacobian calculation in RTT

On Tuesday, January 21, 2014 08:48:44 AM Herman Bruyninckx wrote:
> Not agreed... It _is_ a generic rule that processes take up orders of
> magnitude more resources than function calls, so the obvious _first_ thing
> to think of is to reuse functionality as _functions_, not as
> processes/activities. 
1. You are equating component and process, which is obviously a 
misreprentation (would I want to start a flamewar, I would say FUD given that 
you KNOW how RTT is architectured).
2. You are assuming here that a function is cheap. It is obviously dependent 
on the function ! Path planning algorithms can take easily north of 100ms to 
run for *each run*. A ping-pong between two RTT components takes 25 
microseconds.

It is interesting to see this discussion pop up here, as we are considering 
using RTT as a form of plugin system and doing some serious benchmarking and 
optimization to the RTT channel implementation for this purpose.

The motivation in our case is to integrate *once* algorithms that are shared 
between planning and runtime (as e.g. IK) by being able to "hide" the 
component as a function call within the motion planning algorithm (which would 
only see a boost::function object, never an actual RTT component). So far, I 
am honestly leaning towards "it is doable".

> Assigning one single process to one single function
> should be a well-motivated _exception_, and any (even implicit) suggestion
> that "the context" is in general equally ready to accept either solution is
> hard to motivate.
Rock's development guidelines stresses strongly that most of the functionality 
should be put in libraries. In the end, some components *are* as few calls as 
possible to single functions *because of this process*.

> For example, in the context of IK/ID functionality: sharing the "costly"
> _code_ of such a function is simple when deploying it as a function where
> the different callers keep their own computational state of the function,
> but reuse the executable code by just pointing to it; such decoupling of
> computational state from the code of the algorithm does _in general_ not
> require deployment in different processes (if the code is re-entrant).
Again component != process.
-- 
 Dr. Ing. Sylvain Joyeux
 Space and Security Robotics
 
 Besuchsadresse der Nebengeschäftstelle:
 DFKI GmbH
 Robotics Innovation Center
 Robert-Hooke-Straße 5
 28359 Bremen, Germany
 
 Postadresse der Hauptgeschäftsstelle Standort Bremen:
 DFKI GmbH
 Robotics Innovation Center
 Robert-Hooke-Straße 1
 28359 Bremen, Germany 

 Phone:     +49 421 178 45-4136
 Zentrale: +49 421 178 45-0
 Fax:           +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
 E-Mail:     [email protected]
 
 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 
 ---------------------------------------------------------------------
-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev