Dear Herman,
also in Vienna we have been following the interesting discussions following
your proposal.
From the meetings you know that our interest is in intelligent robotics
(using your definition of a workable approach from June 27). In particular
sensing for robotics.
From this perspectives let me add two comments.
1. Control.
Control can be reduced to collect and redistribute data/commands. When I see
the discussion about classical methods I have this view. For us it includes
the complete sensor/actor system. While the actor side got some attention
(robots, kinematics), I have not yet seen too much on the sensor side and
the specific requirements of sensors (not angular encoders, but rather laser
scanner or cameras). Our experience is that as soon as some more complex
sensors come into play (the most demanding being vision) several new
requirements are imposed on the framework, e.g., lot's of data in short time
(images) and the wish to process these on the same HW.
Maybe this is implicitly taken care of. If yes, see below item 2. If not, we
are interested to be a user and test/extend OROCOS in this dimension. In
particual the development of middleware and the service level, service
parameters is of interest to us. I cannot see intelligent robotics without
these sensors. I also see this as major exploitation factor: all machines
using these sensors will wait for a framework that makes it possible to put
sensors and machines together for new applicaitons without writting all
setup and interfaces anew.
To give you a little of our background, we are interested in OROCOS because
in the ActIPret EU project we develop a framework based on dynamic service
calls. The ActIPret task is to select sensor processing components for
interpreting activites of humans handling objects, e.g., interpreting a
person that takes a CD and puts it into the CD player. If you are interested
a high-level description, please see deliverable 1 on
http://actipret.infa.tuwien.ac.at/.
(http://actipret.infa.tuwien.ac.at/Sites/deliverables.htm).
2. User involvement.
I fully agree with your point to have a strong design team. I also think an
IP also needs to have a wide spread of interested users to have the impact
expected. Personally, I see two ways to do this: (1) to make perfect
finished tools that are easy to use, or (2) involve interested partners to
get to this stage.
From what I know of OROCOS I, (1) is not easy to reach, while (2) is an
option for an IP.
To be more concrete, and please do not take it as negative critique but as
feedback on how to make things used by others/us (maybe other teams had more
patience or skills than us). Presently there are 4 OROCOS versions. Since RT
is not interesting for us, Genom seems too far out of reach, we looked more
closely at SmartSoft and OROCOS@KTH. OROCOS@KTH seemed most fitting. On
testing there were several difficulties, the largest (in several senses) is
TAO, but also a problem is documentation. To reach option (1) it needs
substantially more work, expecting people want to download and work. And, to
have sufficient time for option (2) it is required to have some minimal
resources allocated.
SmartSoft is well developed, has a little better documentation. It seems
difficult to influence further developments and adaptations to our needs. It
also has the same problem of demanding huge resouces and long set-up times
(TAO). I remember Henrik stating at the very first meeting "TAO only over my
dead body" or something similar.
What we ended up with is to develop our own middleware (based on rtf, at the
moment purely for Linux but efficent and easy to use), which is at the
moment suited for ActIPret, but does not help to make many steps beyond.
Hence, our persistent interest in OROCOS.
In conclusion, what I wuold like to point out is that the result of OROCOS
is / could be great. I think design and development needs strong user
involvement. And I think users need resources to provide useful input and
not only such short and superficial comments/critique as I did above.
Finally, I'd love to see more sensing in control, since I do not believe
that intelligent robots (and future factory agents) will be able to be
useful without them. If we can help great. If we get a great middleware,
great, too.
Finally, I would like to express my gratitude for your great efforts, I
appriciate your initiative very much and enjoy following the discussions.
Best wishes
Markus
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]
> Sent: Saturday, June 21, 2003 10:44 AM
> To: Open RObot COntrol Software; LinuxInControl
> Subject: [Orocos] First draft of "OROCOS II" proposal...
>
>
> As promised on several occasions in the past, here is the first draft
> of what could possibly become a EU funded free software project in
> "control". Comments are very welcome, but please don't send private
> emails: use the mailinglists :-)
>
> Herman Bruyninckx
>
> --------------------------------------------------
>
> ==================================================================
>
> Orocos-II: Open contROl COmponentS: Infrastructure for Integration
>
> ==================================================================
>
> Orocos-II is a candidate "FP6 Integrated Project" with the following
> mission statement:
>
> "Design, implementation and integration of free software
> embedded infrastructure and software components to support
> the development and deployment of real-time and large-scale
> distributed feedback control systems."
>
>
> Explication of the various terms in this mission statement:
>
> - "Design, implementation and integration"
> The project has three levels of deliverables (for its
> software aspects):
> - Design: conceptual design, software patterns. These are
> application
> and implementation independent. The emphasis is on reuse of
> patterns at the various control levels.
> - Implementation: of the conceptual designs, with emphasis on
> reusability and quality of code.
> - Integration: (i) to make maximal use of existing FLOSS efforts;
> (ii) to maximally interface with (open) industrial standards.
>
> - "Free software"
> - contractually agreed Free Software results: LGPL license for
> libraries, GPL for applications, and relevant license for parts
> that are done together with existing FLOSS projects.
> - maximal reuse of existing FLOSS software: Linux, Gnome/KDE,
> RTAI/RTLinux/Ecos, Comedi, Coin3D/OpenCascade, ACE/TAO,
> CORBA Orbs, ...
> - pro-active clustering with other FLOSS projects:
> - integration: provide professional design support
> that can help
> promising existing projects to integrate and grow.
> - re-factoring of existing software, for improved software
> engineering quality.
> - application support: approach system integrators and application
> builders as a de facto "consortium" to do business with.
>
> - "Embedded"
> - focus on those parts of the control problem that
> run in the work floor machine controllers, not
> - focus on those design department's desktop functionality that
> support the above-mentioned embedded software.
>
> - "Infrastructure"
> - not applications in the first place, but everything
> needed to build
> applications
> - pre-competitive: majority of industrial users can use it as a base
> for their own products. Cf the status of the operating system and
> the internet, but now targeted to control applications.
> - middleware (interfaces and components, CORBA)
> - basic components in various control application domains.
> - platform independence.
> - bridges to existing protocols and standards (CIP, IEC...., field
> busses, ...)
>
> - "Software components"
> - modularize complex software systems according to the principles of
> software components (Szierpinski): lowest level are objects,
> offering method call interfaces in class libraries; around them,
> "service" components are built, that can operate as
> stand-alone agents
> in a distributed system
> - in practice: use the CORBA and Java approach, because these are
> platform-independent. CORBA has an extra advantage, in that it is
> also language independent, and much more independent from a single
> vendor.
> - .NET is not a priority option because of its "lock in" to one
> single vendor. Except maybe if there is enough demand to build
> Mono components (Mono is a FLOSS implementation of part of the
> .NET infrastructure).
>
> - "Support development and deployment"
> - big emphasis on software patterns:
> - software patterns have proven their value as a way to optimize
> the representation and the discussion about software designs:
> they provide standardized terminology and procedures to describe
> designs that have proven their validity in extended practice.
> - conceptual level documentation to spread "best practices" in
> easy to grasp way
> - implementations on which concrete applications can be built by
> "plugging in" functionality with well-defined interfaces.
> - provide efficient, platform and language independent
> implementations, where possible.
> - interact with other projects, in order to maximize portability and
> modularity (= let development take place where best critical mass
> is available)
> - applications built in the project are "tools": programming,
> visualisation, simulation, distribution, configuration,
> validation, etc.
>
> - "Real-time, large-scale, distributed"
> Industrial control applications can roughly be divided in three levels
> of "control":
>
> (1) Machine.
> Bandwidth: high.
> Latency: low. (Hard real-time.)
> Time horizon: short.
> Centralization: high.
>
> (2) Workcell.
> Bandwidth: medium.
> Latency: medium.
> Time horizon: medium.
> Centralization: medium.
>
> (3) Factory.
> Bandwidth: low.
> Latency: high.
> Time horizon: long.
> Centralization: low.
>
> These three levels require different implementations and support; but
> the feedback control concepts are very similar. So, the project tries
> to use the same software patterns (= conceptual models) in order to
> reduce the complexity to understand the whole software system.
> In addition, all the "overhead" software (configuration, packaging in
> components, user interfacing, etc.) is almost completely reusable.
>
> - "Feedback control systems"
> These are software-driven systems in which the actions and behaviour
> of the system is adapted on-line based on the measurements that are
> done on the system. Typically, a feedback control system has two
> "inputs":
> - "feedforward", coming from models of the system, and steering the
> system to the desired state under the conditions that the system
> behaves as modelled.
> - "feedback", which changes the system's behaviour based on on-line
> measurements that detect how and where the system deviates from its
> model.
> So, adaptability through feedback is the technological key of the
> functional software components, and the project provides the support
> and the tools to program and execute such adapative systems.
>
> ====================================================================
> Motivation
>
> Research aspects:
> - discovery and description of relevant software patterns.
> - high-quality implementation design, with an eye on: efficiency,
> portability, application-independence, decoupling.
>
> Application aspects:
> - to find the most appropriate interfaces:
> - places to "cut" the system in modules.
> - definition of the API with which these modules interact.
> - to find the most appropriate FLOSS components to reuse/adapt.
> - to find the appropriate boundary between application-independent
> components and application-dependent components.
>
>
> Economic aspects:
> - competitive advantages:
> - high potential for large-scale and long-lasting impact.
> - community building is much easier and cheaper than for closed
> source software.
> - large scope and application-independence: significantly reduces
> the risk to develop poorly reuseable designs and implementations.
> - can profit maximally from cost-reduction and co-development
> leverage of FLOSS community.
> - to make complex system infrastructure into "commodity", both with
> respect to the _software_ as with respect to the _documentation_.
> - to increase use and service potential of European SME industry:
> making ones own control system is a _very_ large task for small
> companies nowadays, because of the high dependence on single vendors
> in a very "balkanized" market. This project should drastically
> decrese this entry threshold to the control market.
>
>
> ====================================================================
>
> RTD Work plan
>
> WP1 Component support
> CORBA 3.0 interfaces for components developed in other WPs.
>
> The activities in this WP involve straightforward encoding of
> on the basis of well-defined interfaces and functionalities.
> However, this implementation takes significant time.
>
> The activities in the following WPs involve roughly equal efforts in
> design and in implementation. The design effort focuses on patterns
> and functionality; the implementation on reuse of, and integration
> with, other FLOSS projects.
>
> WP2 Modelling and simulation
> Machine: system dynamics, hybrid real-time control, program
> verification + execution.
> Workcell: synchronization over network, capacity and material
> transport simulation.
> Factory: effects of putting orders into the system, defects,
> cancellation of orders, etc.
>
> The emphasis is on structured descriptions of all "control objects".
> This modelling catalogue is central to all other activities.
>
> WP3 Control
> Machine: Real-time control; "reflex" estimation and decision making.
> Workcell: distributed control; "tactical" estimation and
> decision making.
> Factory: Agent systems; "strategic" estimation and decision making.
>
> The focus is on providing "control kernels", i.e.
> application-independent infrastructure that implements the
> fundamental
> architecture of feedback control:
> - optimal decoupling of functionality in appropriate components.
> - "correctness by construction"
> - highly structured designs, in order to facilitate analysis,
> verification, monitoring and code generation.
> - automatic reconfigurability, by "migrating components/agents" (=
> make knowledge available where it is needed, without hard
> programming).
> - the "hybrid" aspects of control, at all three levels.
> - distributed systems.
>
> WP4 User interfaces
> The design and implementation of interfaces with the following
> goals:
> - cross-platform, toolkit independent.
> - dynamic, i.e.. adaptable on-line to changes in interface demands
> or changes in "machine" configuration.
> - plotting, graphics, visualisation, signal processing components.
> - support for "on-line" programming by local operator.
> - support for the "control kernel" structures.
>
> WP5 Programming tools
> - support for building CORBA components around available
> functionality.
> - support to fill in application-dependent functionality in the
> application-independent "control kernels".
>
> WP6 Configuration and deployment tools
> - support for the "control kernels".
> - compatibility with relevant network and field bus standards.
> - integration on new relevant hardware and operating systems (RTAI,
> DSP, Ecos, Jaluna, TAO/ACE/CIAO, ...).
>
>
> Dissemination Work Plan
> (where possible in collaboration with cluster projects!)
> webbook of control, with fully citable and refereed contributions.
> RTOS documentation ...; Project Workshops;
> contribute to information about licensing issues for commercial use
> (in cooperation with clustered projects); development of
> free course material, ...
>
>
> Training Plan
> Project Workshops: include hands-on training.
> ...
>
>
> Management Work Plan
> ...
>
>
> Consortium Agreement:
> - simple "intellectual property" protection policy: every knowledge
> + software contributed is available under the project free
> software licenses, and possible patented technology can be used
> unconditionally in the software.
>
> ==============================================================
> ===========
>
> Consortium
>
> Partner structure:
> - Design Core: three academic partners, with critical-mass in control
> and software engineering.
> Responsibility: design and implementation; guarantee focus on
> integration; management.
> - Implementation Core: 1-2 SMEs with free software coding experience.
> Responsibility: high-quality FLOSS implementations of Design Core
> results.
> (This implementation Core is maybe too much; I would cut
> here first...)
> - Network of niche expertise partners:
> - short-term subcontracts, with very clear scope and results.
> - academic/industrial partners that use the project results in their
> applications.
> Responsibility: provide expertise in niche areas.
> - Three open workshops per year, with travel grants for non-partner
> participants with relevant expertise.
>
> ==============================================================
> ===========
>
> Budget:
> Design Core = 3 x 2 men x 4 year x 60KEURO
> = 1440KEURO
> Implementation Core = 12MY x 60KEURO
> = 720KEURO
> Short term contracts = 10 x 25KEURO
> = 250KEURO
> Meeting + dissemination = 4 x 3 meetings x 20 x 500EUR
> = 120KEURO
> Computing = (3 x 2 men) x 4KEURO
> = 24KEURO
> Travel + Subsistence = 6 x 4000 EURO + 4 x 2000 EURO
> = 32KEURO
> Consumables = 3 x 20KEURO
> = 60KEURO
> Management = 1 x 15KEURO x 4 years
> = 60KEURO
>
> _____________________________________________________________________
> TOTAL
> 2706KEURO
>
> ====================================================================
> Relevant EU FP6 calls:
> - Communication, computing and software technologies
> 2.3.2.5 Embedded systems
> Objective
> To develop the next generation of technologies and tools for
> modelling, design, implementation and operation of hardware/software
> systems embedded in intelligent devices. An end-to-end
> systems vision
> should allow to build cost-efficient systems with optimal
> performance,
> high confidence, reduced time to market and faster deployment.
> Call: 15 October 2003
> <http://www.cordis.lu/ist/so/embedded-systems/home.html>
>
> 2.3.2.3 Open development platforms for software and services
> Objective
> To build open development and run-time environments for software and
> services providing the next generation of methodologies,
> interoperable
> middleware and tools to support developers - through all
> phases of the
> software life-cycle, from requirements analysis until deployment and
> maintenance - in the production of networked and
> distributed software
> systems and services, embedded software and value-added
> user services.
> This will enable the development of future software engineering
> methods and tools.
> The "Focus" details talk explicitly about "Open source middleware
> layers can facilitate rapid and broad adoption."
> Call: 15 October 2003
> <http://www.cordis.lu/ist/so/sw-platforms/home.html>
>
> ====================================================================
>
> _______________________________________________
> Orocos mailing list
> [email protected]
> http://mail.mech.kuleuven.ac.be/mailman/listinfo/orocos
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.