Re: FK and Jacobian calculation in RTT

2014/1/21 Herman Bruyninckx <[email protected]>

> On Tue, 21 Jan 2014, Sylvain Joyeux wrote:
>
>  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).
>>
>
> I know what the _intention_ was (and that correspond to what you have in
> mind) but unfortunately I also know how most newcomers are _using_ the RTT
> infrastructure, and that is almost invariably "the ROS way", that is, by
> assuming that each RTT component should be deployed in its own process or
> thread...


It's not because most people use badly the system that it becomes the rigth
way ;p.

Assembling librairies into components and affecting then to
machines/process/thread/slave activity is 2 different jobs.
The first one is a system job where you are mainly create functionnal
paths, the second one is a pure informatician problem.


>
>  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.
>>
>
> Depending on the _deployment_ of these components, and their current
> _execution state_... (That is, are the components currently _ready_ to
> engage
> in such a ping-pong or not, or are one or more context switches needed
> before that ping-pong can take place.)
>
> And your numbers do not invalidate my generic statements, nor do they
> corroborate them, since timing is one of the most variable and
> undeterministic aspects of any component-based system of any complexity.
>
>
>  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.
>>
>
> That is definitely a worthwhile effort to undertake! But both of us were
> present at a presentation at ICRA last year, where such "serious
> benchmarking" was also undertaken (and not by amateurs), but nevertheless
> many questions could be posed about the refutability of the benchmarks.
>
>
>  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".
>>
>
>  From your brief description, this looks the same motivation as what made
>> us
>>
> (Markus Klotzbücher and myself) decide to start the "microblx" library;
> pure C, no C++ or other dependencies there, because it should also work on
> all kinds of embedded hardware such as FPGAs.
> Also no "class APIs" either, so that "hiding" is not needed/possible, and
> executed code and computational state of that code are 100% separated.
>
>
>  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*.
>>
>
> Rock is, by far, the best development toolkit around, in my opinion.
> _Because_ its developer(s) are knowledgeable in the tricky stuff of
> multi-component system design :-)
>
>
>  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.
>>
>
> That is a rule that I am _trying_ to make people understand since about 5-6
> years, but the efficiency of that teaching invariably turns out to be close
> to zero, unfortunately... For one reason or another, the semantics of "!="
> seems difficult to convey in a ROS-dominated world :-(
>
> Of course, I support your continuing efforts to keep on repeating
> the message. But having a "Simulink"/"microblx"/"function blocks"
> alternative available (including lots of reference implementations with
> relevant functionality, sich as planning and IK/ID) would our teaching
> jobs _a lot_ easier :-)
>
> Off topic: would anyone care to speculate on the importance of the
> observation that Google bought more or less all robotics companies in the
> US, _except_ the ROS-driven ones...?
>
>  Dr. Ing. Sylvain Joyeux
>>
>
> Herman
>
> --
> Orocos-Dev mailing list
> [email protected]
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>

-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev