On Fri, 29 Jul 2011, Alexander Duda wrote:

>
>> Message: 4
>> Date: Fri, 29 Jul 2011 15:53:12 +0200 (CEST)
>> From: Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
>> Subject: Re: [Orocos-users] [Orocos-Dev] Start of an "Orocos Control
>> Box" project...
>> To: Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>> Cc: Orocos Developers <orocos-dev [..] ...>, Orocos
>> Users <orocos-users [..] ...>
>> Message-ID: <alpine.DEB.2.02.1107291552390.27168@roble>
>> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>>
>> On Fri, 29 Jul 2011, Sylvain Joyeux wrote:
>>
>>> On 07/29/2011 01:48 PM, Herman Bruyninckx wrote:
>>>> On Fri, 29 Jul 2011, Sylvain Joyeux wrote:
>>>>
>>>>> On 07/29/2011 10:07 AM, Herman Bruyninckx wrote:
>>>>>
>>>>> For your information: I will be hiring a junior programming for the
>>>>> following project, based on Orocos/RTT:
>>>>> <http://people.mech.kuleuven.be/~bruyninc/controltoolbox />.
>>>>>
>>>>> Constructive inputs to the ideas, scope, description, objectives and
>>>>> related projects are very welcome, but don't forget that this project
>>>>> should stay focused on entry-level users :-)
>>>>>
>>>>> Only strong point (but as far as I know you, that's already part of your
>>>>> plan): the Systems & Control Library should be a library, i.e.
>>>>> independent of
>>>>> RTT.
>>>>
>>>> Indeed. (I added this comment to the webpage.)
>>>>
>>>>> Cough ... Cough...
>>>>>
>>>>> * Changing control parameters online, and immediately see their
>>>>> effects in
>>>>> the realtime plotted output signals of the control
>>>>> system.
>>>>> is something that is done in Rock already. The plotting widget would
>>>>> need
>>>>> some love, though (read "widget" as "completely independent of RTT /
>>>>> Rock).
>>>>
>>>> Give me pointers to webpages that our collaborator has to read, and I
>>>> will
>>>> be happy to add them! :-)
>>>>
>>>>> * (i) a graphical user interface (GUI) to launch, configure, log,
>>>>> plot, and
>>>>> coordinate Orocos control applications
>>>>> the configure, log and plot GUI is already done in rock. The launch and
>>>>> coordinate GUI is planned (we have for now a shell UI for our
>>>>> model-based
>>>>> coordination layer and a GUI for status display).
>>>>
>>>> Just one remark, that from experience holds very much for you, Sylvain:
>>>> I want to reuse as much as possible _large-scale_ projects, because of
>>>> the
>>>> higher chances of long-term sustainability. So, it's not enough to
>>>> tell me
>>>> that "that has been done already somewhere", but I have to be convinced
>>>> that the suggestion is sustainable and scalable :-) Of course, often some
>>>> small-scale projects bring very interesting innovation, that is worth
>>>> transfering to the large scale projects.
>>> Agreed. Now, this is a valid reason to start anew only if the
>>> development you want to do will -- in the long term -- become a much
>>> larger scale / sustainable project that what is already being offered.
>>>
>>> Moreover, working together is always larger scale and more sustainable
>>> than working alone. What I mean by that is, by reusing, you actually
>>> make the reused software more sustainable. Disregarding it can be done
>>> only if you have large-scale, sustained, long-term development
>>> resources. Something that -- correct me if I am wrong -- Orocos does not
>>> really have right now.
>>
>> Right! That's why insourcing of functionality beyond the real hard realtime
>> core is so essential.
>
> Maybe one small remark:
> Rock is doing the same. We are trying to reuse code from large scale projects as much as possible.

In my opinion, there is a huge difference between (i) using code from large
scale projects, and (ii) contributing your innovation to such large scale
projects. In the former case, the maintenance burden is on you.

> For displaying our live and log data we wrote some glue code for Qt4 but
> most of the code belongs to large scale projects.
>
> This means we are using Qt widgets which are compatible to the
> QDesignerCustomWidgetInterface and can be used by the QtDesigner.
> Thx to QtRuby Bindings we can load an ui file which was created by the
> QtDesigner right a way from ruby and can call all Slots without the need
> of writing one line of extra code.
>
> The data flow is something like:
> orocos task --> orocos.rb --> qtruby --> qt widget (c++; shared library)
>
> I looked into the possible candidates for the graphical user interface
> and QtPdWidgets would be 100% compatible to rock if all its setters and
> getters were declared as qt slots. Even kst could be integrated with the
> same technic.

Everything can be integrated with everything. :-) But I strive for keeping
the amount of projects to be integrated as small as possible.

> small rock example to get an idea:
>
> require 'vizkit'
> Orocos.initialize
>
> #load ui file (created with the help of the qtdesigner)
> window = Vizkit.load(File.join(File.dirname(__FILE__),"gui.ui"))
>
> #connect a signal with a code block (SpinBoxAngle is a QSpinBox object named SpinBoxAngle)
> window.SpinBoxAngle.connect(SIGNAL('valueChanged(double)')) do |value|
> window.MyLabel.setText('123')
> end
>
> #get handle to an orocos task
> camera = Orocos::TaskContext.get 'camera'
>
> #display images (Image is a rock c++ widget)
> camera.connect_to window.Image
>
> window.show
> Vizkit.exec
>
> Alex

Herman

On Fri, 29 Jul 2011, Sylvain Joyeux wrote:

> On 07/29/2011 01:48 PM, Herman Bruyninckx wrote:
>> On Fri, 29 Jul 2011, Sylvain Joyeux wrote:
>>
>>> On 07/29/2011 10:07 AM, Herman Bruyninckx wrote:
>>>
>>> For your information: I will be hiring a junior programming for the
>>> following project, based on Orocos/RTT:
>>> <http://people.mech.kuleuven.be/~bruyninc/controltoolbox />.
>>>
>>> Constructive inputs to the ideas, scope, description, objectives and
>>> related projects are very welcome, but don't forget that this project
>>> should stay focused on entry-level users :-)
>>>
>>> Only strong point (but as far as I know you, that's already part of your
>>> plan): the Systems & Control Library should be a library, i.e.
>>> independent of
>>> RTT.
>>
>> Indeed. (I added this comment to the webpage.)
>>
>>> Cough ... Cough...
>>>
>>> * Changing control parameters online, and immediately see their
>>> effects in
>>> the realtime plotted output signals of the control
>>> system.
>>> is something that is done in Rock already. The plotting widget would
>>> need
>>> some love, though (read "widget" as "completely independent of RTT /
>>> Rock).
>>
>> Give me pointers to webpages that our collaborator has to read, and I
>> will
>> be happy to add them! :-)
>>
>>> * (i) a graphical user interface (GUI) to launch, configure, log,
>>> plot, and
>>> coordinate Orocos control applications
>>> the configure, log and plot GUI is already done in rock. The launch and
>>> coordinate GUI is planned (we have for now a shell UI for our
>>> model-based
>>> coordination layer and a GUI for status display).
>>
>> Just one remark, that from experience holds very much for you, Sylvain:
>> I want to reuse as much as possible _large-scale_ projects, because of
>> the
>> higher chances of long-term sustainability. So, it's not enough to
>> tell me
>> that "that has been done already somewhere", but I have to be convinced
>> that the suggestion is sustainable and scalable :-) Of course, often some
>> small-scale projects bring very interesting innovation, that is worth
>> transfering to the large scale projects.
> Agreed. Now, this is a valid reason to start anew only if the
> development you want to do will -- in the long term -- become a much
> larger scale / sustainable project that what is already being offered.
>
> Moreover, working together is always larger scale and more sustainable
> than working alone. What I mean by that is, by reusing, you actually
> make the reused software more sustainable. Disregarding it can be done
> only if you have large-scale, sustained, long-term development
> resources. Something that -- correct me if I am wrong -- Orocos does not
> really have right now.

Right! That's why insourcing of functionality beyond the real hard realtime
core is so essential.

> Sylvain Joyeux

Herman

On Fri, 29 Jul 2011, Sylvain Joyeux wrote:

> On 07/29/2011 01:48 PM, Herman Bruyninckx wrote:
>> On Fri, 29 Jul 2011, Sylvain Joyeux wrote:
>>
>>> On 07/29/2011 10:07 AM, Herman Bruyninckx wrote:
>>>
>>> For your information: I will be hiring a junior programming for the
>>> following project, based on Orocos/RTT:
>>> <http://people.mech.kuleuven.be/~bruyninc/controltoolbox />.
>>>
>>> Constructive inputs to the ideas, scope, description, objectives and
>>> related projects are very welcome, but don't forget that this project
>>> should stay focused on entry-level users :-)
>>>
>>> Only strong point (but as far as I know you, that's already part of your
>>> plan): the Systems & Control Library should be a library, i.e.
>>> independent of
>>> RTT.
>>
>> Indeed. (I added this comment to the webpage.)
>>
>>> Cough ... Cough...
>>>
>>> * Changing control parameters online, and immediately see their
>>> effects in
>>> the realtime plotted output signals of the control
>>> system.
>>> is something that is done in Rock already. The plotting widget would
>>> need
>>> some love, though (read "widget" as "completely independent of RTT /
>>> Rock).
>>
>> Give me pointers to webpages that our collaborator has to read, and I
>> will
>> be happy to add them! :-)
>>
>>> * (i) a graphical user interface (GUI) to launch, configure, log,
>>> plot, and
>>> coordinate Orocos control applications
>>> the configure, log and plot GUI is already done in rock. The launch and
>>> coordinate GUI is planned (we have for now a shell UI for our
>>> model-based
>>> coordination layer and a GUI for status display).
>>
>> Just one remark, that from experience holds very much for you, Sylvain:
>> I want to reuse as much as possible _large-scale_ projects, because of
>> the
>> higher chances of long-term sustainability. So, it's not enough to
>> tell me
>> that "that has been done already somewhere", but I have to be convinced
>> that the suggestion is sustainable and scalable :-) Of course, often some
>> small-scale projects bring very interesting innovation, that is worth
>> transfering to the large scale projects.
> Agreed. Now, this is a valid reason to start anew only if the
> development you want to do will -- in the long term -- become a much
> larger scale / sustainable project that what is already being offered.
>
> Moreover, working together is always larger scale and more sustainable
> than working alone. What I mean by that is, by reusing, you actually
> make the reused software more sustainable. Disregarding it can be done
> only if you have large-scale, sustained, long-term development
> resources. Something that -- correct me if I am wrong -- Orocos does not
> really have right now.

Right! That's why insourcing of functionality beyond the real hard realtime
core is so essential.

> Sylvain Joyeux

Herman