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

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

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

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