ANNOUNCE: Lua RTT plugin beta1 released

I'm pleased to announce a first beta of the Lua RTT bindings. This
code allows to use the powerful Lua scripting language to interact
with the RTT.

The main features are:

- usable as standalone interpreter (scriptable taskbrowser), Lua
Component or Lua service.

- implements a large part of the RTT API. The following entities are
supported: TaskContext, InputPort, OutputPort, Property, Service,
RTT Types (incl. user defined ones and Operators), Operation,
SendHandle, Logger. See the Manual for more information.

- No dependencies on external binding libraries

- Real-time: Lua comes with a real-time garbage collector. It can
also be used in hard-real settings taking some
precautions. Documentation on this will follow soon.

The API currently offers more or less what I needed myself and what
was easy to do. It is not set in stone (its a beta after all!) If
something is missing or should be different, let me know.

My main usecase is to build domain specific languages for different
purposes, mainly a new Coordination State Machine model which will be
released in the near future.

Working quite stable here but there will be bugs without doubt...

Peter, please consider merging into OCL. It is non-intrusive, generic,
small and disabled by default :-)

Code+docs are here:

http://gitorious.org/~markusk/orocos-toolchain/ocl-mk/commits/lua

Pull request follows.

Best regards
Markus

The following changes since commit da6e2fb82f80e8717c91b2674adf482772311882:

Merging fixes of 2.0.2 release. (2010-09-30 23:14:10 +0200)

are available in the git repository at:

git://gitorious.org/~markusk/orocos-toolchain/ocl-mk.git lua

Markus Klotzbuecher (75):
Lua: initial rev
Lua: add newindex metamethod for Variables
Lua: convert void type to lua-nil
add colors to rttlib
Lua: add send/collect support
Lua: some code cleanups
Lua: readd unit tests and some minor fixes.
add more testinfrastructure
Lua: add test to pinpoint multicall problem
lua: rename var:update to var:assign
lua: hackish fix for multicall issue
Lua: testing cleanups
lua: automatic conversion for basic types in TaskContext.call
lua: automatic conversion for basic types in TaskContext.send
lua: add basic tests for conversion and send
lua: some port improvements
lua: optional third argument to Port.new
lua: in/out port read/write lua types support
lua: TaskContext.addPort takes multiple args
lua: addEventPort and addProperty take multiple arguments
lua: make Variable.assign work with lua types
lua: extend Property.set to take lua values
lua: add support for ~/.rttlua init file
lua: cleanup wild west macros
lua: introduce gen_push_bxptr macro
lua: Variable.__newindex support for lua types
lua: create module-local environment
lua: failed attempt to fix the port/property issue.
lua: remove opDot
lua: small rttlib updates
lua: basic service support (incl. Operation type)
lua: add Operation.send()
lua: add service pretty printer
lua: added fist plugin code
Change FindRTT to look for 2.0.0
lua: fixes to lua plugin
lua: change 'plugin' to 'plugins'
lua: 'services', 'types' and 'typekits' bindings
lua: remove dead code
lua: started writing docs
lua: plugin: setglobal TC
lua: add documentation stylesheat
lua: doc updates
lua: commit html docs
Lua: use getService instead of provides()
lua: remove loglevel setting
lua: add loglevel
lua: add service requester
lua: add ServiceRequester_disconnect
add custom formatter support + docs updates
lua: catch exceptions in send and call
lua: remove unused deployment.lua module
lua: add variable fromtab func
lua: doc updates
documentation updates
lua: doc updates
lua: replace global TC with getTC() function
lua: doc improvements
lua: add license headers
lua: add simple producer-consumer example
renamed doc/README -> doc/MANUAL
lua: add port and property removal and destruction functions
lua: more doc updates
lua: make properties indexable and assignable
lua: cleanup cmake options and document
lua: cleanup setting context TC
lua: add trivial service unit test
lua: minor doc update
lua: add cleanup to prod/cons example. bugfix
lua: docs, finish quickstart example
lua: more doc updates
lua: add utils.lua
lua: doc updates
lua: disable Lua RTT by default
lua: final doc updates

CMakeLists.txt | 1 +
lua/CMakeLists.txt | 63 +
lua/LuaComponent.cpp | 191 +++
lua/README | 8 +
lua/deployer.cpp | 107 ++
lua/doc/MANUAL.html | 1185 +++++++++++++++
lua/doc/MANUAL.org | 540 +++++++
lua/doc/MANUAL.txt | 601 ++++++++
lua/doc/css/stylesheet.css | 67 +
lua/lua-repl.c | 399 +++++
lua/lua-repl.h | 392 +++++
lua/modules/rttlib.lua | 370 +++++
lua/modules/utils.lua | 220 +++
lua/modules/uunit.lua | 114 ++
lua/plugins/CMakeLists.txt | 3 +
lua/plugins/lua_plugin.cpp | 70 +
lua/rtt.cpp | 2185 ++++++++++++++++++++++++++++
lua/rtt.hpp | 53 +
lua/scripts/dot-rttlua | 5 +
lua/scripts/producer_consumer/README | 6 +
lua/scripts/producer_consumer/consumer.lua | 25 +
lua/scripts/producer_consumer/deploy.lua | 89 ++
lua/scripts/producer_consumer/producer.lua | 25 +
lua/scripts/rtt-test.lua | 182 +++
lua/testing/CMakeLists.txt | 11 +
lua/testing/test.lua | 218 +++
lua/testing/testcomp.cpp | 132 ++
27 files changed, 7262 insertions(+), 0 deletions(-)
create mode 100644 lua/CMakeLists.txt
create mode 100644 lua/LuaComponent.cpp
create mode 100644 lua/README
create mode 100644 lua/deployer.cpp
create mode 100644 lua/doc/MANUAL.html
create mode 100644 lua/doc/MANUAL.org
create mode 100644 lua/doc/MANUAL.txt
create mode 100644 lua/doc/css/stylesheet.css
create mode 100644 lua/lua-repl.c
create mode 100644 lua/lua-repl.h
create mode 100644 lua/modules/rttlib.lua
create mode 100644 lua/modules/utils.lua
create mode 100644 lua/modules/uunit.lua
create mode 100644 lua/plugins/CMakeLists.txt
create mode 100644 lua/plugins/lua_plugin.cpp
create mode 100644 lua/rtt.cpp
create mode 100644 lua/rtt.hpp
create mode 100644 lua/scripts/dot-rttlua
create mode 100644 lua/scripts/producer_consumer/README
create mode 100644 lua/scripts/producer_consumer/consumer.lua
create mode 100755 lua/scripts/producer_consumer/deploy.lua
create mode 100644 lua/scripts/producer_consumer/producer.lua
create mode 100644 lua/scripts/rtt-test.lua
create mode 100644 lua/testing/CMakeLists.txt
create mode 100755 lua/testing/test.lua
create mode 100644 lua/testing/testcomp.cpp

ANNOUNCE: Lua RTT plugin beta1 released

On Friday 08 October 2010 14:03:03 Markus Klotzbuecher wrote:
> Dear All,
>
> I'm pleased to announce a first beta of the Lua RTT bindings. This
> code allows to use the powerful Lua scripting language to interact
> with the RTT.
>
> The main features are:
>
> - usable as standalone interpreter (scriptable taskbrowser), Lua
> Component or Lua service.
>
> - implements a large part of the RTT API. The following entities are
> supported: TaskContext, InputPort, OutputPort, Property, Service,
> RTT Types (incl. user defined ones and Operators), Operation,
> SendHandle, Logger. See the Manual for more information.
>
> - No dependencies on external binding libraries
>
> - Real-time: Lua comes with a real-time garbage collector. It can
> also be used in hard-real settings taking some
> precautions. Documentation on this will follow soon.
>
> The API currently offers more or less what I needed myself and what
> was easy to do. It is not set in stone (its a beta after all!) If
> something is missing or should be different, let me know.
>
> My main usecase is to build domain specific languages for different
> purposes, mainly a new Coordination State Machine model which will be
> released in the near future.
>
> Working quite stable here but there will be bugs without doubt...
>
> Peter, please consider merging into OCL. It is non-intrusive, generic,
> small and disabled by default :-)

I think disabling by default is a bad policy. Everything should be enabled by
default, except if some dependency is not found, then it might be disabled
with a warning ('Install libxyz in order to have access to this feature').

Things that were disabled by default in OCL led to lesser maintained or tested
code.

I couldn't find the docs at http://gitorious.org/~markusk/orocos-toolchain/ocl-
mk/commits/lua . Am I missing something ?

Peter

ANNOUNCE: Lua RTT plugin beta1 released

On Mon, Oct 11, 2010 at 11:10:32AM +0200, Peter Soetens wrote:
> On Friday 08 October 2010 14:03:03 Markus Klotzbuecher wrote:
> > Dear All,
> >
> > I'm pleased to announce a first beta of the Lua RTT bindings. This
> > code allows to use the powerful Lua scripting language to interact
> > with the RTT.
> >
> > The main features are:
> >
> > - usable as standalone interpreter (scriptable taskbrowser), Lua
> > Component or Lua service.
> >
> > - implements a large part of the RTT API. The following entities are
> > supported: TaskContext, InputPort, OutputPort, Property, Service,
> > RTT Types (incl. user defined ones and Operators), Operation,
> > SendHandle, Logger. See the Manual for more information.
> >
> > - No dependencies on external binding libraries
> >
> > - Real-time: Lua comes with a real-time garbage collector. It can
> > also be used in hard-real settings taking some
> > precautions. Documentation on this will follow soon.
> >
> > The API currently offers more or less what I needed myself and what
> > was easy to do. It is not set in stone (its a beta after all!) If
> > something is missing or should be different, let me know.
> >
> > My main usecase is to build domain specific languages for different
> > purposes, mainly a new Coordination State Machine model which will be
> > released in the near future.
> >
> > Working quite stable here but there will be bugs without doubt...
> >
> > Peter, please consider merging into OCL. It is non-intrusive, generic,
> > small and disabled by default :-)
>
> I think disabling by default is a bad policy. Everything should be enabled by
> default, except if some dependency is not found, then it might be disabled
> with a warning ('Install libxyz in order to have access to this feature').

Ok, disabling if the dependencies are not found is fine for me. I just
didn't want to break people builds.

> Things that were disabled by default in OCL led to lesser maintained or tested
> code.

Agreed.

> I couldn't find the docs at http://gitorious.org/~markusk/orocos-toolchain/ocl-
> mk/commits/lua . Am I missing something ?

It can be found under lua/README

Markus

ANNOUNCE: Lua RTT plugin beta1 released

Instead of making OCL a big thing again, would you consider releasing
it as a separate package ?

IMO, this is way too big to be in an "integrated package" ...

Sylvain

ANNOUNCE: Lua RTT plugin beta1 released

On Fri, 8 Oct 2010, Markus Klotzbuecher wrote:

> I'm pleased to announce a first beta of the Lua RTT bindings. This
> code allows to use the powerful Lua scripting language to interact
> with the RTT.
[...]
> Peter, please consider merging into OCL. It is non-intrusive, generic,
> small and disabled by default :-)

I think Orocos has to come up with an updated strategy with respect to the
growing number of useful tooling around RTT and other Orocos libraries...

This strategy could roughly follow a layered approach such as this one:

- the core developers decide whether a specific tool is important/generic
enough to become part of RTT; if so, the developers commit to maintaining
the tool, and upgrading it together with RTT upgrades. For all practical
matters, the tool has become a part of RTT.

- the tool is not considered "RTT worthy" (yet), but still "most useful to
have". In this case, the tool ends up in a "connected project interface"
branch, where the tool--RTT bindings (or whatever "glue code" is needed to
make the tool work with RTT...) is kept, documented and versioned in a
systematic and professionally tested way, but not necessarily synchronized
with the RTT releases.

- the third level, of "nice to have" tools, end up with no source code
branch in Orocos or RTT, but with a dedicated Wiki page containing all
information how to connect RTT and the tool (whose code resides elsewhere).

This strategy does not only serve the goal of making the life of core
developers, tool developers and users more easy, but it is also a strong
statement (to the external world of interested users and contributors)
about the vision and long-term strategy of the Orocos project. For example,
if full integration in Eclipse is a such a long term goal, no small scale
tool projects should be promoted to RTT level if there is an Eclipse
alternative (even if the latter is not yet tested or supported in Orocos).

Comments welcome.

Herman

ANNOUNCE: Lua RTT plugin beta1 released

On Saturday 09 October 2010 14:46:31 Herman Bruyninckx wrote:
> On Fri, 8 Oct 2010, Markus Klotzbuecher wrote:
> > I'm pleased to announce a first beta of the Lua RTT bindings. This
> > code allows to use the powerful Lua scripting language to interact
> > with the RTT.
>
> [...]
>
> > Peter, please consider merging into OCL. It is non-intrusive, generic,
> > small and disabled by default :-)
>
> I think Orocos has to come up with an updated strategy with respect to the
> growing number of useful tooling around RTT and other Orocos libraries...
>
> This strategy could roughly follow a layered approach such as this one:
>
> - the core developers decide whether a specific tool is important/generic
> enough to become part of RTT; if so, the developers commit to
> maintaining the tool, and upgrading it together with RTT upgrades. For all
> practical matters, the tool has become a part of RTT.

AKA "Orocos Toolchain". We've always been balancing between putting something
'in' the RTT or aside it. That's the historical reason for the separation of
the RTT vs OCL sources. We have now solved that by defining a toolchain, where
RTT is 'just' a run-time library, and the other packages build on it. They are
always in sync and released together.

>
> - the tool is not considered "RTT worthy" (yet), but still "most useful to
> have". In this case, the tool ends up in a "connected project interface"
> branch, where the tool--RTT bindings (or whatever "glue code" is needed
> to make the tool work with RTT...) is kept, documented and versioned in a
> systematic and professionally tested way, but not necessarily synchronized
> with the RTT releases.

Here you're introducing the purgatory, which should lead to heaven (RTT) but
is often confused with hell (third party). I don't like it, since it is much
like hell anyway. No user or developer is helped with non-synchronized code.
Even if this situation exists in practice, it should be resolved asap. Things
I'm thinking about that are now in this situation but belong in the toolchain:

- ros-transport
- ktaskbrowser or a successor
- simulink bindings (or can we scrap this?)
- real-time logging service
- yarp transport

>
> - the third level, of "nice to have" tools, end up with no source code
> branch in Orocos or RTT, but with a dedicated Wiki page containing all
> information how to connect RTT and the tool (whose code resides
> elsewhere).

We can't do much about this, it's in the hands of the third party. The people
at willow garage solved this by offering these people some webspace and tools
such that they become more visible, something for which we don't have the
resources.

>
> This strategy does not only serve the goal of making the life of core
> developers, tool developers and users more easy, but it is also a strong
> statement (to the external world of interested users and contributors)
> about the vision and long-term strategy of the Orocos project. For example,
> if full integration in Eclipse is a such a long term goal, no small scale
> tool projects should be promoted to RTT level if there is an Eclipse
> alternative (even if the latter is not yet tested or supported in Orocos).

When packaging, the only code I'll consider in my equations is the code that
works now. I'm all for coordinated work on one topic instead of dispersed
actions, but don't ask me to make a judgement based on a tool of which I have
never seen a line of code. If people want their stuff in the equation, they'll
have to use this list, just like Markus did right now.

Peter

ANNOUNCE: Lua RTT plugin beta1 released

On Mon, 11 Oct 2010, Peter Soetens wrote:

> On Saturday 09 October 2010 14:46:31 Herman Bruyninckx wrote:
>> On Fri, 8 Oct 2010, Markus Klotzbuecher wrote:
>>> I'm pleased to announce a first beta of the Lua RTT bindings. This
>>> code allows to use the powerful Lua scripting language to interact
>>> with the RTT.
>>
>> [...]
>>
>>> Peter, please consider merging into OCL. It is non-intrusive, generic,
>>> small and disabled by default :-)
>>
>> I think Orocos has to come up with an updated strategy with respect to the
>> growing number of useful tooling around RTT and other Orocos libraries...
>>
>> This strategy could roughly follow a layered approach such as this one:
>>
>> - the core developers decide whether a specific tool is important/generic
>> enough to become part of RTT; if so, the developers commit to
>> maintaining the tool, and upgrading it together with RTT upgrades. For all
>> practical matters, the tool has become a part of RTT.
>
> AKA "Orocos Toolchain". We've always been balancing between putting something
> 'in' the RTT or aside it. That's the historical reason for the separation of
> the RTT vs OCL sources. We have now solved that by defining a toolchain, where
> RTT is 'just' a run-time library, and the other packages build on it. They are
> always in sync and released together.
>
>>
>> - the tool is not considered "RTT worthy" (yet), but still "most useful to
>> have". In this case, the tool ends up in a "connected project interface"
>> branch, where the tool--RTT bindings (or whatever "glue code" is needed
>> to make the tool work with RTT...) is kept, documented and versioned in a
>> systematic and professionally tested way, but not necessarily synchronized
>> with the RTT releases.
>
> Here you're introducing the purgatory, which should lead to heaven (RTT) but
> is often confused with hell (third party). I don't like it, since it is much
> like hell anyway. No user or developer is helped with non-synchronized code.
> Even if this situation exists in practice, it should be resolved asap. Things
> I'm thinking about that are now in this situation but belong in the toolchain:
>
> - ros-transport
> - ktaskbrowser or a successor
> - simulink bindings (or can we scrap this?)
> - real-time logging service
> - yarp transport
>
>>
>> - the third level, of "nice to have" tools, end up with no source code
>> branch in Orocos or RTT, but with a dedicated Wiki page containing all
>> information how to connect RTT and the tool (whose code resides
>> elsewhere).
>
> We can't do much about this, it's in the hands of the third party. The people
> at willow garage solved this by offering these people some webspace and tools
> such that they become more visible, something for which we don't have the
> resources.
>
>>
>> This strategy does not only serve the goal of making the life of core
>> developers, tool developers and users more easy, but it is also a strong
>> statement (to the external world of interested users and contributors)
>> about the vision and long-term strategy of the Orocos project. For example,
>> if full integration in Eclipse is a such a long term goal, no small scale
>> tool projects should be promoted to RTT level if there is an Eclipse
>> alternative (even if the latter is not yet tested or supported in Orocos).
>
> When packaging, the only code I'll consider in my equations is the code that
> works now. I'm all for coordinated work on one topic instead of dispersed
> actions, but don't ask me to make a judgement based on a tool of which I have
> never seen a line of code. If people want their stuff in the equation, they'll
> have to use this list, just like Markus did right now.
>
> Peter

So, I summarize your message: you are in favour of only having "really
integrated" projects, and all the rest is not visible from within the
Orocos eco-system? This is a pragmatic approach, to which I have no
objections. But let's them make it a clear _policy_ :-)

Herman

ANNOUNCE: Lua RTT plugin beta1 released

On Sat, Oct 09, 2010 at 02:46:31PM +0200, Herman Bruyninckx wrote:
> On Fri, 8 Oct 2010, Markus Klotzbuecher wrote:
>
> > I'm pleased to announce a first beta of the Lua RTT bindings. This
> > code allows to use the powerful Lua scripting language to interact
> > with the RTT.
> [...]
> > Peter, please consider merging into OCL. It is non-intrusive, generic,
> > small and disabled by default :-)
>
> I think Orocos has to come up with an updated strategy with respect to the
> growing number of useful tooling around RTT and other Orocos libraries...
>
> This strategy could roughly follow a layered approach such as this one:
>
> - the core developers decide whether a specific tool is important/generic
> enough to become part of RTT; if so, the developers commit to maintaining
> the tool, and upgrading it together with RTT upgrades. For all practical
> matters, the tool has become a part of RTT.
>
> - the tool is not considered "RTT worthy" (yet), but still "most useful to
> have". In this case, the tool ends up in a "connected project interface"
> branch, where the tool--RTT bindings (or whatever "glue code" is needed to
> make the tool work with RTT...) is kept, documented and versioned in a
> systematic and professionally tested way, but not necessarily synchronized
> with the RTT releases.
>
> - the third level, of "nice to have" tools, end up with no source code
> branch in Orocos or RTT, but with a dedicated Wiki page containing all
> information how to connect RTT and the tool (whose code resides elsewhere).

Sounds reasonable. Some further aspects which should play a role:

- cost to maintain
- intrusiveness of code
- who will maintain

One issue of maintaining stuff ouside of RTT/OCL is that we have not
standardized on a package format yet and there are multiple management
tools out in the wild.

> This strategy does not only serve the goal of making the life of core
> developers, tool developers and users more easy, but it is also a strong
> statement (to the external world of interested users and contributors)
> about the vision and long-term strategy of the Orocos project. For example,

Ok.

> if full integration in Eclipse is a such a long term goal, no small scale
> tool projects should be promoted to RTT level if there is an Eclipse
> alternative (even if the latter is not yet tested or supported in Orocos).

I might or might not agree with this statement :-) If a basic
tool/feature is only accessable from within Eclipse I think we are
doing a suboptimal job in terms of decoupling.

Markus

ANNOUNCE: Lua RTT plugin beta1 released

On Mon, 11 Oct 2010, Markus Klotzbuecher wrote:

> On Sat, Oct 09, 2010 at 02:46:31PM +0200, Herman Bruyninckx wrote:
>> On Fri, 8 Oct 2010, Markus Klotzbuecher wrote:
>>
>>> I'm pleased to announce a first beta of the Lua RTT bindings. This
>>> code allows to use the powerful Lua scripting language to interact
>>> with the RTT.
>> [...]
>>> Peter, please consider merging into OCL. It is non-intrusive, generic,
>>> small and disabled by default :-)
>>
>> I think Orocos has to come up with an updated strategy with respect to the
>> growing number of useful tooling around RTT and other Orocos libraries...
>>
>> This strategy could roughly follow a layered approach such as this one:
>>
>> - the core developers decide whether a specific tool is important/generic
>> enough to become part of RTT; if so, the developers commit to maintaining
>> the tool, and upgrading it together with RTT upgrades. For all practical
>> matters, the tool has become a part of RTT.
>>
>> - the tool is not considered "RTT worthy" (yet), but still "most useful to
>> have". In this case, the tool ends up in a "connected project interface"
>> branch, where the tool--RTT bindings (or whatever "glue code" is needed to
>> make the tool work with RTT...) is kept, documented and versioned in a
>> systematic and professionally tested way, but not necessarily synchronized
>> with the RTT releases.
>>
>> - the third level, of "nice to have" tools, end up with no source code
>> branch in Orocos or RTT, but with a dedicated Wiki page containing all
>> information how to connect RTT and the tool (whose code resides elsewhere).
>
> Sounds reasonable. Some further aspects which should play a role:
>
> - cost to maintain
> - intrusiveness of code
> - who will maintain
The latter is _the_ crucial aspect.

> One issue of maintaining stuff ouside of RTT/OCL is that we have not
> standardized on a package format yet and there are multiple management
> tools out in the wild.
>
>> This strategy does not only serve the goal of making the life of core
>> developers, tool developers and users more easy, but it is also a strong
>> statement (to the external world of interested users and contributors)
>> about the vision and long-term strategy of the Orocos project. For example,
>
> Ok.
>
>> if full integration in Eclipse is a such a long term goal, no small scale
>> tool projects should be promoted to RTT level if there is an Eclipse
>> alternative (even if the latter is not yet tested or supported in Orocos).
>
> I might or might not agree with this statement :-) If a basic
> tool/feature is only accessable from within Eclipse I think we are
> doing a suboptimal job in terms of decoupling.

Yes. The "perfect" tools are (i) not coupled to the Eclipse IDE (so they
can be used "stand alone", but (ii) very well integrated into it.

>
> Markus

Herman

ANNOUNCE: Lua RTT plugin beta1 released

On Oct 9, 2010, at 08:46 , Herman Bruyninckx wrote:

> On Fri, 8 Oct 2010, Markus Klotzbuecher wrote:
>
>> I'm pleased to announce a first beta of the Lua RTT bindings. This
>> code allows to use the powerful Lua scripting language to interact
>> with the RTT.
> [...]
>> Peter, please consider merging into OCL. It is non-intrusive, generic,
>> small and disabled by default :-)
>
> I think Orocos has to come up with an updated strategy with respect to the
> growing number of useful tooling around RTT and other Orocos libraries...
>
> This strategy could roughly follow a layered approach such as this one:
>
> - the core developers decide whether a specific tool is important/generic
> enough to become part of RTT; if so, the developers commit to maintaining
> the tool, and upgrading it together with RTT upgrades. For all practical
> matters, the tool has become a part of RTT.
>
> - the tool is not considered "RTT worthy" (yet), but still "most useful to
> have". In this case, the tool ends up in a "connected project interface"
> branch, where the tool--RTT bindings (or whatever "glue code" is needed to
> make the tool work with RTT...) is kept, documented and versioned in a
> systematic and professionally tested way, but not necessarily synchronized
> with the RTT releases.
>
> - the third level, of "nice to have" tools, end up with no source code
> branch in Orocos or RTT, but with a dedicated Wiki page containing all
> information how to connect RTT and the tool (whose code resides elsewhere).
>
> This strategy does not only serve the goal of making the life of core
> developers, tool developers and users more easy, but it is also a strong
> statement (to the external world of interested users and contributors)
> about the vision and long-term strategy of the Orocos project. For example,
> if full integration in Eclipse is a such a long term goal, no small scale
> tool projects should be promoted to RTT level if there is an Eclipse
> alternative (even if the latter is not yet tested or supported in Orocos).
>
> Comments welcome.
>
> Herman

Seems quite reasonable. This strategy and a roadmap (ie the project's combined long term vision/plan) need to be documented somewhere on the wiki. We are currently missing this.

I know that Herman (and undoubtedly others) have long term Orocos projects already going on, or in mind. Is their value to the community to have at least some idea of what is going on, so we can either work collaboratively, or at least not repeat ongoing work? This would be a part of the roadmap IMHO.
S

ANNOUNCE: Lua RTT plugin beta1 released

On Sat, 9 Oct 2010, S Roderick wrote:

> On Oct 9, 2010, at 08:46 , Herman Bruyninckx wrote:
>
>> On Fri, 8 Oct 2010, Markus Klotzbuecher wrote:
>>
>>> I'm pleased to announce a first beta of the Lua RTT bindings. This
>>> code allows to use the powerful Lua scripting language to interact
>>> with the RTT.
>> [...]
>>> Peter, please consider merging into OCL. It is non-intrusive, generic,
>>> small and disabled by default :-)
>>
>> I think Orocos has to come up with an updated strategy with respect to the
>> growing number of useful tooling around RTT and other Orocos libraries...
>>
>> This strategy could roughly follow a layered approach such as this one:
>>
>> - the core developers decide whether a specific tool is important/generic
>> enough to become part of RTT; if so, the developers commit to maintaining
>> the tool, and upgrading it together with RTT upgrades. For all practical
>> matters, the tool has become a part of RTT.
>>
>> - the tool is not considered "RTT worthy" (yet), but still "most useful to
>> have". In this case, the tool ends up in a "connected project interface"
>> branch, where the tool--RTT bindings (or whatever "glue code" is needed to
>> make the tool work with RTT...) is kept, documented and versioned in a
>> systematic and professionally tested way, but not necessarily synchronized
>> with the RTT releases.
>>
>> - the third level, of "nice to have" tools, end up with no source code
>> branch in Orocos or RTT, but with a dedicated Wiki page containing all
>> information how to connect RTT and the tool (whose code resides elsewhere).
>>
>> This strategy does not only serve the goal of making the life of core
>> developers, tool developers and users more easy, but it is also a strong
>> statement (to the external world of interested users and contributors)
>> about the vision and long-term strategy of the Orocos project. For example,
>> if full integration in Eclipse is a such a long term goal, no small scale
>> tool projects should be promoted to RTT level if there is an Eclipse
>> alternative (even if the latter is not yet tested or supported in Orocos).
>>
>> Comments welcome.
>>
>> Herman
>
> Seems quite reasonable. This strategy and a roadmap (ie the project's combined long term vision/plan) need to be documented somewhere on the wiki. We are currently missing this.
>
> I know that Herman (and undoubtedly others) have long term Orocos
> projects already going on, or in mind. Is their value to the community to
> have at least some idea of what is going on, so we can either work
> collaboratively, or at least not repeat ongoing work? This would be a
> part of the roadmap IMHO.

You're right! I should give more information myself in the first place,
around ongoing or planned (research) projects that (could) have an
influence on the future of Orocos! Here we go:

- BRICS (Best Practices in RObotics) <http://www.best-of-robotics.org/>
runs for 2.5 more years, and provides funds for Markus, Hugo and Ruben.
(Peter has been partime collaborator, until he started on his own last May.)
So, the expected influence from BRICS is:
- a better FSM support: clearer semantics, LUA scripting, integration
into Eclipse, a possible way to bring "dynamic behaviour" into deployment
- Eclipse as "model-driven design" toolchain around RTT components:
- Hugo is now working on the "structural model" support, that is,
making composite components by glueing primitive components together
with "wires", and writing everything out to deployable files
- next 6 months: support for choosing middleware implementations for
the various ways in which Communication over the ports can be done;
support for FSM programming within a component
- other partners in BRICS are preparing ZeroMQ support
<http://www.zeromq.org/>
- Rosetta <http://www.fp7rosetta.org/>, runs for 2.5 more years, and
provides funds for Ruben. Hence, expected influence:
- better integration with ROS, and a better ("model-driven") solution to
define the data structures to be used in Ports
- KDL 2.0, with COLLADA support, more solvers, standardization of some
lower level data structures
- a refactoring of the (robot) control stack: nAxesControl,
CartesianControl,...
- better integration with Blender, to use that program as an "emulator"
for real machines.

All these developments can be categorized under the single "vision" of
trying to make Orocos/RTT a _professionally_ supported, _model-driven_
development tool, with a high focus on "4C separation of concerns"[1].

Currently, I am putting efforts in establishing cooperations towards a
better large scale integration and deployment support, in the context of
the OSGi ecosystem. I have found already some interested parties, but no
concrete vision or development roadmaps exist yet.

Finally, I am going to put some effort in finding cooperations to improve
the "GUI" support around Orocos. Again, motivated by the "4C" and "model
driven" goals; no information about potential partnerships available yet...

Another strategic issue, not so much with a direct influence on code, but
rather on user awareness and acceptance: EtherCat is booming as a
technology in robotics and machine tools, and Orocos is very ready for that
evolution, via the _huge_ work that was done this Summer (by students,
under supervision of Ruben and Koen), to extend the SOEM master
<http://soem.berlios.de/>, <http://www.ros.org/wiki/soem_ethercat_drivers>
with lots of 'module services' for signal IO.

So, that's a 'quick and dirty' overview. I hope I _do_ have forgotten some more
things :-)

Herman

[1] "4C": Computation, Communication, Configuration, Coordination
@InCollection{
author = {Radestock, Matthias and Eisenbach, Susan},
title = {Coordination in evolving systems},
booktitle = {Trends in Distributed Systems.\ {CORBA} and Beyond},
publisher = {Springer-Verlag},
pages = {162--176},
year = {1996}
}

ANNOUNCE: Lua RTT plugin beta1 released

On Oct 9, 2010, at 09:32 , Herman Bruyninckx wrote:

> On Sat, 9 Oct 2010, S Roderick wrote:
>
>> On Oct 9, 2010, at 08:46 , Herman Bruyninckx wrote:
>>
>>> On Fri, 8 Oct 2010, Markus Klotzbuecher wrote:
>>>
>>>> I'm pleased to announce a first beta of the Lua RTT bindings. This
>>>> code allows to use the powerful Lua scripting language to interact
>>>> with the RTT.
>>> [...]
>>>> Peter, please consider merging into OCL. It is non-intrusive, generic,
>>>> small and disabled by default :-)
>>>
>>> I think Orocos has to come up with an updated strategy with respect to the
>>> growing number of useful tooling around RTT and other Orocos libraries...
>>>
>>> This strategy could roughly follow a layered approach such as this one:
>>>
>>> - the core developers decide whether a specific tool is important/generic
>>> enough to become part of RTT; if so, the developers commit to maintaining
>>> the tool, and upgrading it together with RTT upgrades. For all practical
>>> matters, the tool has become a part of RTT.
>>>
>>> - the tool is not considered "RTT worthy" (yet), but still "most useful to
>>> have". In this case, the tool ends up in a "connected project interface"
>>> branch, where the tool--RTT bindings (or whatever "glue code" is needed to
>>> make the tool work with RTT...) is kept, documented and versioned in a
>>> systematic and professionally tested way, but not necessarily synchronized
>>> with the RTT releases.
>>>
>>> - the third level, of "nice to have" tools, end up with no source code
>>> branch in Orocos or RTT, but with a dedicated Wiki page containing all
>>> information how to connect RTT and the tool (whose code resides elsewhere).
>>>
>>> This strategy does not only serve the goal of making the life of core
>>> developers, tool developers and users more easy, but it is also a strong
>>> statement (to the external world of interested users and contributors)
>>> about the vision and long-term strategy of the Orocos project. For example,
>>> if full integration in Eclipse is a such a long term goal, no small scale
>>> tool projects should be promoted to RTT level if there is an Eclipse
>>> alternative (even if the latter is not yet tested or supported in Orocos).
>>>
>>> Comments welcome.
>>>
>>> Herman
>>
>> Seems quite reasonable. This strategy and a roadmap (ie the project's combined long term vision/plan) need to be documented somewhere on the wiki. We are currently missing this.
>>
>> I know that Herman (and undoubtedly others) have long term Orocos
>> projects already going on, or in mind. Is their value to the community to
>> have at least some idea of what is going on, so we can either work
>> collaboratively, or at least not repeat ongoing work? This would be a
>> part of the roadmap IMHO.
>
> You're right! I should give more information myself in the first place,
> around ongoing or planned (research) projects that (could) have an
> influence on the future of Orocos! Here we go:
>
> - BRICS (Best Practices in RObotics) <http://www.best-of-robotics.org/>
> runs for 2.5 more years, and provides funds for Markus, Hugo and Ruben.
> (Peter has been partime collaborator, until he started on his own last May.)
> So, the expected influence from BRICS is:
> - a better FSM support: clearer semantics, LUA scripting, integration
> into Eclipse, a possible way to bring "dynamic behaviour" into deployment
> - Eclipse as "model-driven design" toolchain around RTT components:
> - Hugo is now working on the "structural model" support, that is,
> making composite components by glueing primitive components together
> with "wires", and writing everything out to deployable files
> - next 6 months: support for choosing middleware implementations for
> the various ways in which Communication over the ports can be done;
> support for FSM programming within a component
> - other partners in BRICS are preparing ZeroMQ support
> <http://www.zeromq.org/>
> - Rosetta <http://www.fp7rosetta.org/>, runs for 2.5 more years, and
> provides funds for Ruben. Hence, expected influence:
> - better integration with ROS, and a better ("model-driven") solution to
> define the data structures to be used in Ports
> - KDL 2.0, with COLLADA support, more solvers, standardization of some
> lower level data structures
> - a refactoring of the (robot) control stack: nAxesControl,
> CartesianControl,...
> - better integration with Blender, to use that program as an "emulator"
> for real machines.
>
> All these developments can be categorized under the single "vision" of
> trying to make Orocos/RTT a _professionally_ supported, _model-driven_
> development tool, with a high focus on "4C separation of concerns"[1].
>
> Currently, I am putting efforts in establishing cooperations towards a
> better large scale integration and deployment support, in the context of
> the OSGi ecosystem. I have found already some interested parties, but no
> concrete vision or development roadmaps exist yet.
>
> Finally, I am going to put some effort in finding cooperations to improve
> the "GUI" support around Orocos. Again, motivated by the "4C" and "model
> driven" goals; no information about potential partnerships available yet...
>
> Another strategic issue, not so much with a direct influence on code, but
> rather on user awareness and acceptance: EtherCat is booming as a
> technology in robotics and machine tools, and Orocos is very ready for that
> evolution, via the _huge_ work that was done this Summer (by students,
> under supervision of Ruben and Koen), to extend the SOEM master
> <http://soem.berlios.de/>, <http://www.ros.org/wiki/soem_ethercat_drivers>
> with lots of 'module services' for signal IO.
>
> So, that's a 'quick and dirty' overview. I hope I _do_ have forgotten some more
> things :-)
>
> Herman
>
> [1] "4C": Computation, Communication, Configuration, Coordination
> @InCollection{
> author = {Radestock, Matthias and Eisenbach, Susan},
> title = {Coordination in evolving systems},
> booktitle = {Trends in Distributed Systems.\ {CORBA} and Beyond},
> publisher = {Springer-Verlag},
> pages = {162--176},
> year = {1996}
> }
>

The above looks like a damn fine addition to a "Roadmap" wiki page ... you have rights to edit, correct, Herman? :-)
S

ANNOUNCE: Lua RTT plugin beta1 released

On Sat, 9 Oct 2010, S Roderick wrote:

> On Oct 9, 2010, at 09:32 , Herman Bruyninckx wrote:
>
>> On Sat, 9 Oct 2010, S Roderick wrote:
>>
>>> On Oct 9, 2010, at 08:46 , Herman Bruyninckx wrote:
>>>
>>>> On Fri, 8 Oct 2010, Markus Klotzbuecher wrote:
>>>>
>>>>> I'm pleased to announce a first beta of the Lua RTT bindings. This
>>>>> code allows to use the powerful Lua scripting language to interact
>>>>> with the RTT.
>>>> [...]
>>>>> Peter, please consider merging into OCL. It is non-intrusive, generic,
>>>>> small and disabled by default :-)
>>>>
>>>> I think Orocos has to come up with an updated strategy with respect to the
>>>> growing number of useful tooling around RTT and other Orocos libraries...
>>>>
>>>> This strategy could roughly follow a layered approach such as this one:
>>>>
>>>> - the core developers decide whether a specific tool is important/generic
>>>> enough to become part of RTT; if so, the developers commit to maintaining
>>>> the tool, and upgrading it together with RTT upgrades. For all practical
>>>> matters, the tool has become a part of RTT.
>>>>
>>>> - the tool is not considered "RTT worthy" (yet), but still "most useful to
>>>> have". In this case, the tool ends up in a "connected project interface"
>>>> branch, where the tool--RTT bindings (or whatever "glue code" is needed to
>>>> make the tool work with RTT...) is kept, documented and versioned in a
>>>> systematic and professionally tested way, but not necessarily synchronized
>>>> with the RTT releases.
>>>>
>>>> - the third level, of "nice to have" tools, end up with no source code
>>>> branch in Orocos or RTT, but with a dedicated Wiki page containing all
>>>> information how to connect RTT and the tool (whose code resides elsewhere).
>>>>
>>>> This strategy does not only serve the goal of making the life of core
>>>> developers, tool developers and users more easy, but it is also a strong
>>>> statement (to the external world of interested users and contributors)
>>>> about the vision and long-term strategy of the Orocos project. For example,
>>>> if full integration in Eclipse is a such a long term goal, no small scale
>>>> tool projects should be promoted to RTT level if there is an Eclipse
>>>> alternative (even if the latter is not yet tested or supported in Orocos).
>>>>
>>>> Comments welcome.
>>>>
>>>> Herman
>>>
>>> Seems quite reasonable. This strategy and a roadmap (ie the project's combined long term vision/plan) need to be documented somewhere on the wiki. We are currently missing this.
>>>
>>> I know that Herman (and undoubtedly others) have long term Orocos
>>> projects already going on, or in mind. Is their value to the community to
>>> have at least some idea of what is going on, so we can either work
>>> collaboratively, or at least not repeat ongoing work? This would be a
>>> part of the roadmap IMHO.
>>
>> You're right! I should give more information myself in the first place,
>> around ongoing or planned (research) projects that (could) have an
>> influence on the future of Orocos! Here we go:
>>
>> - BRICS (Best Practices in RObotics) <http://www.best-of-robotics.org/>
>> runs for 2.5 more years, and provides funds for Markus, Hugo and Ruben.
>> (Peter has been partime collaborator, until he started on his own last May.)
>> So, the expected influence from BRICS is:
>> - a better FSM support: clearer semantics, LUA scripting, integration
>> into Eclipse, a possible way to bring "dynamic behaviour" into deployment
>> - Eclipse as "model-driven design" toolchain around RTT components:
>> - Hugo is now working on the "structural model" support, that is,
>> making composite components by glueing primitive components together
>> with "wires", and writing everything out to deployable files
>> - next 6 months: support for choosing middleware implementations for
>> the various ways in which Communication over the ports can be done;
>> support for FSM programming within a component
>> - other partners in BRICS are preparing ZeroMQ support
>> <http://www.zeromq.org/>
>> - Rosetta <http://www.fp7rosetta.org/>, runs for 2.5 more years, and
>> provides funds for Ruben. Hence, expected influence:
>> - better integration with ROS, and a better ("model-driven") solution to
>> define the data structures to be used in Ports
>> - KDL 2.0, with COLLADA support, more solvers, standardization of some
>> lower level data structures
>> - a refactoring of the (robot) control stack: nAxesControl,
>> CartesianControl,...
>> - better integration with Blender, to use that program as an "emulator"
>> for real machines.
>>
>> All these developments can be categorized under the single "vision" of
>> trying to make Orocos/RTT a _professionally_ supported, _model-driven_
>> development tool, with a high focus on "4C separation of concerns"[1].
>>
>> Currently, I am putting efforts in establishing cooperations towards a
>> better large scale integration and deployment support, in the context of
>> the OSGi ecosystem. I have found already some interested parties, but no
>> concrete vision or development roadmaps exist yet.
>>
>> Finally, I am going to put some effort in finding cooperations to improve
>> the "GUI" support around Orocos. Again, motivated by the "4C" and "model
>> driven" goals; no information about potential partnerships available yet...
>>
>> Another strategic issue, not so much with a direct influence on code, but
>> rather on user awareness and acceptance: EtherCat is booming as a
>> technology in robotics and machine tools, and Orocos is very ready for that
>> evolution, via the _huge_ work that was done this Summer (by students,
>> under supervision of Ruben and Koen), to extend the SOEM master
>> <http://soem.berlios.de/>, <http://www.ros.org/wiki/soem_ethercat_drivers>
>> with lots of 'module services' for signal IO.
>>
>> So, that's a 'quick and dirty' overview. I hope I _do_ have forgotten some more
>> things :-)
>>
>> Herman
>>
>> [1] "4C": Computation, Communication, Configuration, Coordination
>> @InCollection{
>> author = {Radestock, Matthias and Eisenbach, Susan},
>> title = {Coordination in evolving systems},
>> booktitle = {Trends in Distributed Systems.\ {CORBA} and Beyond},
>> publisher = {Springer-Verlag},
>> pages = {162--176},
>> year = {1996}
>> }
>>
>
> The above looks like a damn fine addition to a "Roadmap" wiki page ... you have rights to edit, correct, Herman? :-)

Do I? :-)

Let's first await the reactions of others, before we make this into the
"official" Orocos roadmap...

Herman

Dynamic deployment discussion: "systemd inspiration"...

A "random thought" in the context of (dynamic) deployment via scripts: in
the Linux world, the concept of "on demand deployment" is getting more and
more popular, as proven by projects such as "systemd"
<http://www.freedesktop.org/wiki/Software/systemd>
<http://lwn.net/Articles/389149/>
Two interesting features here:
- parallelization of deployment;
- on-demand deployment.
Are such features useful for Orocos...?

Technically speaking, systemd can also provide us with some good "best
practice": it works on top of "d-bus", which in RTT's component-based terms
could be rephrased as follows: "Let's first deploy all "Container"
Components, that provide an application independent "event service", which
is then available for the deployment of application Components. The
on-demand feature also follows rather straightforward once that event
infrastructure is on-line.

Herman