[ros-users] [Orocos-users] Joint controller manager

[Herman Bruyninckx]

On Mon, 28 Jan 2013, Peter Soetens wrote:

> On Mon, Jan 28, 2013 at 8:05 PM, Herman Bruyninckx
> <Herman.Bruyninckx at 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 at 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
> :-)

Rock is one of the most rock-solid tool chains for _component_ based
programming but not for _computational_ models. In other words, I do not
see it play in the league of the tools I mentioned. And that is not a
criticism, because it is not designed to be a computational toolchain that
optimizes efficiency and code generation to the "bare metal". :-)

[...]

> Peter

Herman