Re: FK and Jacobian calculation in RTT

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

> 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