Start of an "Orocos Control Box" project...

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 :-)

Best regards,

Herman Bruyninckx

Start of an "Orocos Control Box" project...

Hello,

we are just developing a component based GUI for some OROCOS based controllers.
We write this specially for kite power system control, but I think, some (or many?) of
the components might be reusable in a more general context, e.g. an oscilloscope,
a function generator, filters, joystick drivers, loggers, the simulink interface etc.

These GUI components use UDP packages, to communicate with each other and with
OROCOS. They are meant to be used in a distributed control environment.

We are also still looking for another software developer:
http://www.kitepower.eu/newsevents/6-news/82-job-vacancy.html

If people are interested, we could publish the generally usable components under
an open source license.

Regards:

Uwe Fechner

On 29.07.2011 10:07, 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 :-)
>
> Best regards,
>
> Herman Bruyninckx
>

Start of an "Orocos Control Box" project...

Hello,

we are just developing a component based GUI for some OROCOS based controllers.
We write this specially for kite power system control, but I think, some (or many?) of
the components might be reusable in a more general context, e.g. an oscilloscope,
a function generator, filters, joystick drivers, loggers, the simulink interface etc.

These GUI components use UDP packages, to communicate with each other and with
OROCOS. They are meant to be used in a distributed control environment.

We are also still looking for another software developer:
http://www.kitepower.eu/newsevents/6-news/82-job-vacancy.html

If people are interested, we could publish the generally usable components under
an open source license.

Regards:

Uwe Fechner

On 29.07.2011 10:07, 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 :-)
>
> Best regards,
>
> Herman Bruyninckx
>

Start of an "Orocos Control Box" project...

On Tue, 16 Aug 2011, Uwe Fechner wrote:

> Hello,
>
> we are just developing a component based GUI for some OROCOS based controllers.
> We write this specially for kite power system control, but I think, some (or many?) of
> the components might be reusable in a more general context, e.g. an oscilloscope,
> a function generator, filters, joystick drivers, loggers, the simulink interface etc.

Absolutely :-)

> These GUI components use UDP packages, to communicate with each other and with
> OROCOS. They are meant to be used in a distributed control environment.

It should be best practice to decouple the means of communication (UDP in
your case) from the rest of the component stuff. So, how difficult is it
for you to make the components "middleware agnostic"?

> We are also still looking for another software developer:
> http://www.kitepower.eu/newsevents/6-news/82-job-vacancy.html
>
> If people are interested, we could publish the generally usable components under
> an open source license.

Of course we are interested! :-) But before you go through the effort of
releasing code, it makes sense to discuss the design and implementation
issues of the components you think of releasing.

> Regards:
>
> Uwe Fechner

Herman

> On 29.07.2011 10:07, 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 :-)
>>
>> Best regards,
>>
>> Herman Bruyninckx
>>
>

Start of an "Orocos Control Box" project...

On Tue, 16 Aug 2011, Uwe Fechner wrote:

> Hello,
>
> we are just developing a component based GUI for some OROCOS based controllers.
> We write this specially for kite power system control, but I think, some (or many?) of
> the components might be reusable in a more general context, e.g. an oscilloscope,
> a function generator, filters, joystick drivers, loggers, the simulink interface etc.

Absolutely :-)

> These GUI components use UDP packages, to communicate with each other and with
> OROCOS. They are meant to be used in a distributed control environment.

It should be best practice to decouple the means of communication (UDP in
your case) from the rest of the component stuff. So, how difficult is it
for you to make the components "middleware agnostic"?

> We are also still looking for another software developer:
> http://www.kitepower.eu/newsevents/6-news/82-job-vacancy.html
>
> If people are interested, we could publish the generally usable components under
> an open source license.

Of course we are interested! :-) But before you go through the effort of
releasing code, it makes sense to discuss the design and implementation
issues of the components you think of releasing.

> Regards:
>
> Uwe Fechner

Herman

> On 29.07.2011 10:07, 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 :-)
>>
>> Best regards,
>>
>> Herman Bruyninckx
>>
>

Start of an "Orocos Control Box" project...

Hi Herman

I saw the project description and wanted to inform you that we have developed an OROCOS Component generator template for 20-sim. Not fully tested for nested and complex controller designs but first prototype ready. Will share the template soon after talking with the 20-sim guys :)

Tadele

On Jul 29, 2011, at 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 :-)
>
> Best regards,
>
> Herman Bruyninckx
>

Start of an "Orocos Control Box" project...

Hi Herman

I saw the project description and wanted to inform you that we have developed an OROCOS Component generator template for 20-sim. Not fully tested for nested and complex controller designs but first prototype ready. Will share the template soon after talking with the 20-sim guys :)

Tadele

On Jul 29, 2011, at 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 :-)
>
> Best regards,
>
> Herman Bruyninckx
>

Start of an "Orocos Control Box" project...

On Mon, 15 Aug 2011, Tadele Shiferaw Tadele wrote:

> I saw the project description and wanted to inform you that we have
> developed an OROCOS Component generator template for 20-sim. Not fully
> tested for nested and complex controller designs but first prototype
> ready. Will share the template soon after talking with the 20-sim guys :)

Thanks for the information! Please, make sure that the template is as
generic as possible, that is, works with all "code generator products" and
not just 20Sim :-)

> Tadele

Herman

>
> On Jul 29, 2011, at 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 :-)
>>
>> Best regards,
>>
>> Herman Bruyninckx

Start of an "Orocos Control Box" project...

On Mon, 15 Aug 2011, Tadele Shiferaw Tadele wrote:

> I saw the project description and wanted to inform you that we have
> developed an OROCOS Component generator template for 20-sim. Not fully
> tested for nested and complex controller designs but first prototype
> ready. Will share the template soon after talking with the 20-sim guys :)

Thanks for the information! Please, make sure that the template is as
generic as possible, that is, works with all "code generator products" and
not just 20Sim :-)

> Tadele

Herman

>
> On Jul 29, 2011, at 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 :-)
>>
>> Best regards,
>>
>> Herman Bruyninckx

Start of an "Orocos Control Box" project...

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

* (i) a *graphical user interface* (GUI) to launch, configure, log,
plot, and coordinate Orocos <http://www.orocos.org> 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).

Start of an "Orocos Control Box" project...

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

* (i) a *graphical user interface* (GUI) to launch, configure, log,
plot, and coordinate Orocos <http://www.orocos.org> 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).

Start of an "Orocos Control Box" project...

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.
Don't take this remark personally!

Herman

Start of an "Orocos Control Box" project...

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.
Don't take this remark personally!

Herman

Start of an "Orocos Control Box" project...

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

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

Start of an "Orocos Control Box" project...

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

Start of an "Orocos Control Box" project...

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.

Start of an "Orocos Control Box" project...

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.

Start of an "Orocos Control Box" project...

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

Start of an "Orocos Control Box" project...

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

Start of an "Orocos Control Box" project...

> -----Original Message-----
> From: orocos-users-bounces [..] ... [mailto:orocos-users-
> bounces [..] ...] On Behalf Of Herman Bruyninckx
> Sent: vrijdag 29 juli 2011 10:07
> To: Orocos Developers; Orocos Users
> Subject: [Orocos-users] Start of an "Orocos Control Box" project...
>
> 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 :-)

A possibly interesting related project: http://www.cds.caltech.edu/~murray/wiki/index.php/Control_Systems_Librar...

Wilm

>
> Best regards,
>
> Herman Bruyninckx
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users

Start of an "Orocos Control Box" project...

> -----Original Message-----
> From: orocos-users-bounces [..] ... [mailto:orocos-users-
> bounces [..] ...] On Behalf Of Herman Bruyninckx
> Sent: vrijdag 29 juli 2011 10:07
> To: Orocos Developers; Orocos Users
> Subject: [Orocos-users] Start of an "Orocos Control Box" project...
>
> 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 :-)

A possibly interesting related project: http://www.cds.caltech.edu/~murray/wiki/index.php/Control_Systems_Librar...

Wilm

>
> Best regards,
>
> Herman Bruyninckx
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users

Start of an "Orocos Control Box" project...

On Fri, 29 Jul 2011, Wilm Decré wrote:

>> -----Original Message-----
>> From: orocos-users-bounces [..] ... [mailto:orocos-users-
>> bounces [..] ...] On Behalf Of Herman Bruyninckx
>> Sent: vrijdag 29 juli 2011 10:07
>> To: Orocos Developers; Orocos Users
>> Subject: [Orocos-users] Start of an "Orocos Control Box" project...
>>
>> 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 :-)
>
> A possibly interesting related project: http://www.cds.caltech.edu/~murray/wiki/index.php/Control_Systems_Librar...
>
Thanks for this information!

That project does not produce executable code, but provides a controls
toolbox in Python. Is useful probably, but not in the short term.
I've added it to the web page.

> Wilm

Herman

Start of an "Orocos Control Box" project...

On Fri, 29 Jul 2011, Wilm Decré wrote:

>> -----Original Message-----
>> From: orocos-users-bounces [..] ... [mailto:orocos-users-
>> bounces [..] ...] On Behalf Of Herman Bruyninckx
>> Sent: vrijdag 29 juli 2011 10:07
>> To: Orocos Developers; Orocos Users
>> Subject: [Orocos-users] Start of an "Orocos Control Box" project...
>>
>> 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 :-)
>
> A possibly interesting related project: http://www.cds.caltech.edu/~murray/wiki/index.php/Control_Systems_Librar...
>
Thanks for this information!

That project does not produce executable code, but provides a controls
toolbox in Python. Is useful probably, but not in the short term.
I've added it to the web page.

> Wilm

Herman