On Mon, Jan 28, 2013 at 8:05 PM, Herman Bruyninckx
<Herman.Bruyninckx@mech.kuleuven.be> wrote:
> On Mon, 28 Jan 2013, Jonathan Bohren wrote:
>
>> On Mon, Jan 28, 2013 at 11:41 AM, Herman Bruyninckx
>> <Herman.Bruyninckx@mech.kuleuven.be> wrote:
...
>> In many orocos applications that support motion control, people have made
>> the error to deploy the kind of architecture that you have in your drawing
>> ("sinks" and "sources" connected via "topic" data flows) one on one on an
>> Orocos "TaskContext" component design, which is _very_ inefficient.
>> Since ages already, industry deploys such architectures into one single
>> thread or process, as different functions that access the "topics" as
>> shared memory; this is alot more efficient, especially since the
>> computations in the "components" are very simple, but a lot of data has to
>> be streamed around all the time. In addition, the Simulink, Modelica or
>> 20Sim tools do the code generation from your kind of "model" to such
>> single-thread computations for you.
>>
>>
>> Herman,
>>
>> Is there any sort of happy medium you know of between the current
>> component-based
>> C++-code-writing and having to learn either a new declarative modeling
>> language or own
>> a piece of proprietary software for visual block-diagram design? Maybe
>> some balance
>> where the functional interfaces of a given block are associated with more
>> semantic
>> information than just a data type, but the actual computation is still
>> written out in
>> an imperative language like c++?
>
>
> I don't know what exactly your definition of "happy" is, but there is
> already a lot out there in open source: OpenModelica, Scilab/Scicos, BRIDE,
> RODIN, etc.;

Rock - www.rock-robotics.org

> they all do modelling and code generation, to different
> extends. Are this kind of projects really completely unknown in the ROS
> universe...?

Ironically, you skipped the one closest to your habitat and closest to
robotics, although this might have been due to an implicit meta-model
:-)

>
> But we _will_ have to learn "new declarative modeling languages", because
> that's the only way to standardize, on semantics and syntax; the advantage
> of such languages is that one is not bound by one particular syntax, or
> rather, two implementations with different syntax can still communicate
> with each other via "model-to-model" transformations.
>
> Side note: as soon as one accepts such a MDE approach, C++ all of a sudden
> becomes a much less attractive language, while languages such as (System)C
> come into the picture because of their appropriateness for code generation
> to _all_ hardware (also the ones not supporting C++ runtimes): indeed, the
> code
> generation ("model-to-text compilation") does not much more than filling in
> plain computational functions and generated data structs.
>
>> -j
>
>
> Herman

Peter