RE: Orocos digest, Vol 1 #211 - 7 msgs

Dear Herman,

as you know I have been overwelmed with Geoplex (Summer School) preparation
so far, but if you consider that an input from my side on the GeoplexII
proposal would be useful, just let me know and I will download the proposal
(from the WWW ??) and comment on that.

Ciao !

- Stefano
 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
Prof. Stefano Stramigioli, (M.Sc., Ph.D.)
Associate Professor
 
Control Engineering Laboratory
Department of Electrical Engineering
Faculty of EEMCS
Drebbel Institute on Mechatronics
 
P.O. Box 217
NL-7500 AE Enschede
The Netherlands
 
Tel. +31 (53) 4892794/4892606 
Fax. +31 (53) 4894830/4892223 
 
Email [email protected]
WWW: http://www.ce.utwente.nl/smi

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] 
> Sent: zondag 22 juni 2003 20:56
> To: [email protected]
> Subject: Orocos digest, Vol 1 #211 - 7 msgs
> 
> 
> Send Orocos mailing list submissions to
> 	[email protected]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://mail.mech.kuleuven.ac.be/mailman/listinfo/orocos
> or, via email, send a message with subject or body 'help' to
> 	[email protected]
> 
> You can reach the person managing the list at
> 	[email protected]
> 
> When replying, please edit your Subject line so it is more 
> specific than "Re: Contents of Orocos digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Dead Image on Vision ([email protected])
>    2. Re: First draft of "OROCOS II" proposal... 
> ([email protected])
>    3. Re: Re: [List]First draft of "OROCOS II" proposal... 
> ([email protected])
>    4. Re: First draft of "OROCOS II" proposal... 
> ([email protected])
>    5. Re: First draft of "OROCOS II" proposal... 
> ([email protected])
>    6. Re: First draft of "OROCOS II" proposal... 
> ([email protected])
>    7. Re: First draft of "OROCOS II" proposal... 
> ([email protected])
> 
> --__--__--
> 
> Message: 1
> Date: Sun, 22 Jun 2003 16:55:46 +0200 (CEST)
> To: [email protected]
> Subject: Re: [Orocos] Dead Image on Vision
> From: [email protected]
> Reply-To: [email protected]
> 
> On Sun, 22 Jun 2003 [email protected] wrote:
> 
> > This -> http://www.orocos.org/pictures/core-comp-arch.png image is 
> > dead, it is on this -> http://www.orocos.org/vision.html page.
> 
> Ok, thanks for pointing this out!
> 
> > I am looking at using OROCOS on my robotics project 
> > www.experimentsindigital.com, this robot is a 6' 5'' tall humanoid 
> > robot and from what I have read so far OROCOS might be a 
> good fit for the project.
> It's still a bit too early: Orocos is not yet plug-and-play...
> 
> For example, we don't have any humanoid kinematics code yet, 
> although that's not very difficult to add. It's just never been done.
> 
> Herman
> 
> -- 
>   K.U.Leuven, Mechanical Engineering, Robotics Research Group 
> <http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480
> 
> 
> --__--__--
> 
> Message: 2
> Date: Sun, 22 Jun 2003 17:03:21 +0200 (CEST)
> To: [email protected]
> Subject: Re: [Orocos] First draft of "OROCOS II" proposal...
> From: [email protected]
> Reply-To: [email protected]
> 
> On Sat, 21 Jun 2003 [email protected] wrote:
> 
> > are planning to submit a possible proposal to next call?
> > 
> Indeed. Deadline of 15 oct. Probably in the "Open development 
> platforms", although "Emedded systems" could be an alternative.
> 
> Herman
> 
> -- 
>   K.U.Leuven, Mechanical Engineering, Robotics Research Group 
> <http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480
> 
> 
> --__--__--
> 
> Message: 3
> Date: Sun, 22 Jun 2003 17:18:34 +0200 (CEST)
> To: Open RObot COntrol Software <[email protected]>
> Cc: LinuxInControl <[email protected]>
> Subject: Re: [Orocos] Re: [List]First draft of "OROCOS II" proposal...
> From: [email protected]
> Reply-To: [email protected]
> 
> On Sat, 21 Jun 2003 [email protected] wrote:
> 
> [...]
> > >   - Integration: (i) to make maximal use of existing 
> FLOSS efforts;
> > 
> > FLOSS ??
> 
> Free/Libre/Open Source Software :-) This term (or FOSS) is 
> often used in EU documents...
> 
> > > - "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.
> > 
> > what happens to non-lib/non-app i.e. kernel-modules,code-generator 
> > output (GPL ?)
> As I said: comply to the licenses of the relevant project. 
> For the kernel this would be GPL. But there would not be much 
> kernel-related work in this project :-)
> 
> [...]
> > > - "Infrastructure"
> > >   - not applications in the first place, but everything 
> needed to build
> > >     applications
> > 
> > toolchains/Linux-control-distribution ?
> 
> What do you eman with this remark?
> 
> > >   - 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.
> > 
> > don't get the second sentence ?
> Ok, should be more verbose: I mean that at this moment, many 
> businesses consider the OS and the operating system as a 
> commodity, that is "just there" for everybody to use. In the 
> area of control, there is no such common commodity infrastructure yet.
> 
> [...]
> > >   - platform independence.
> > 
> > for low end archs like SH4 I belive platform independance could be 
> > very hard to achive - platform independance easaly ends up 
> requiring 
> > inacceptably strong platforms - I wonder if platform 
> independance is 
> > such a key issue for some parts (i.e. kernel modules)
> 
> Keep in mind that this project is for the largest part _very_ 
> far from the hardware platform and the kernel. So, low end 
> archs are not a focus point.
> 
> [...]
> > >   - 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.
> > 
> > I belive that corba/java will exclude a large number of industrial 
> > target platforms as it will be too heavy waighted...
> 
> Most industries I know that are active in the scope of the 
> proposal use Java or Corba or .NET...
> 
> [...]
> > what I belive is missing, as in many projects, is a systematic path 
> > for technology transfere - what I mean is that such a complex 
> > conceptual approach would need to include something like 
> > tutorials/seminars or what ever technology migration path 
> one preferes 
> > to get the entire framwork into industrial R&D .
> 
> I included this in the relevant section, in the form of about 
> 3 workshops a year. But I have to flesh out that 
> dissemination section some more, of course :-)
> 
> [...]
> > > Research aspects:
> > > - discovery and description of relevant software patterns.
> > > - high-quality implementation design, with an eye on: efficiency,
> > >   portability, application-independence, decoupling.
> > 
> > decoupling what ?
> 
> Software components. Coupling is the largest source of 
> non-scalability, complexity, and non-distributability. 
> (Coupling means that one component's implementation makes use 
> of knowledge about other components' internals, in order to 
> be "more efficient"...)
> 
> > >   - definition of the API with which these modules interact.
> > 
> > new API ? no attempt to use the interface capabilities that POSIX 
> > provides and integrate the interfaces via POSIX coplient API ? what 
> > would be the advantage of a new-home-brew API here - 
> especially with 
> > respect to the anticipated integration of external software 
> projects 
> > that might allready exist ....
> 
> We are _not at all_ talking about OS interfaces! But of 
> interfaces of the control infrastructure, which is quite far 
> away from the OS :-) POSIX is completely irrelevant in this scope.
> 
> [...]
> > > 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, ...).
> > 
> > If this should make it into industry easy then an 
> integrated something 
> > like a distribution will be needed - just providing a kernel and 
> > compatibility with standards I don't think will do it.
> 
> Yes, but achieving this is left to cooperation with others. 
> Yet-another-distribution would not be a smart way to go, I 
> guess. Anyway, towards the end of the project, one of the 
> "outsourced subcontracts" could be in this area.
> 
> [...]
> > with configurability and on-line adaptation/programing and 
> distributed
> > systems being on the agenda I'm supprised not to find security as a 
> > seperate KEY issue.
> 
> Good point! But there are much efforts in thsi direction 
> going on already, that allow security as "plug in" to a large 
> extent. For example, <http://shibboleth.internet2.edu/index.html>.
> 
> [...]
> > > 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.
> > 
> > I'm interested in seeing what trees legal departments will start 
> > klimbing with statements like this ... will be interesting 
> to see what 
> > such a license would realy look like - this sounds like a 
> > patent-prevention patent :)
> 
> Not much different from GPL version 3 I guess :-) And mind 
> you, the project is about the _infrastructure_ not about the 
> _applications_ that people will want to run on top of it. The 
> recent SCO story has probably made lots of companies more 
> aware that patents could stand in between a good and free 
> software infrastructure and using it...
> 
> Herman Bruyninckx
> 
> -- 
>   K.U.Leuven, Mechanical Engineering, Robotics Research Group 
> <http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480
> 
> 
> --__--__--
> 
> Message: 4
> Date: Sun, 22 Jun 2003 17:37:34 +0200 (CEST)
> To: [email protected]
> Subject: Re: [Orocos] First draft of "OROCOS II" proposal...
> From: [email protected]
> Reply-To: [email protected]
> 
> On Sat, 21 Jun 2003 [email protected] wrote:
> 
> [...]
> > a) The proposal seems to be primarily targeted to factory 
> automation and
> >    manipulation type robotics. Is this the direction you want to 
> > emphasize?
> Not at all! It should be completely application independent. 
> But I do realise that it's awefully difficult to consistently 
> use fully neutral terminology :-(
> 
> >    Robotics today is much more than that. It might be 
> sensible to divide
> >    the work into
> > 
> >    i)   factory automation (intg with PLC, NC control...)
> >    ii)  manipulation systems
> >    iii) mobile systems
> 
> My subdivision was orthogonal to this: "real-time", "small 
> distributed system", "large distributed system". Whatever 
> these systems might be. Your suggestion is too much 
> application oriented, IMHO, and the project should not be 
> guided by applications. 
> Not immediately at least; of course, the applications should 
> be known to the designers, but these should be sufficiently 
> strong in software engineering in order to find the 
> appropriate decouplings between infrastructure and applications.
> 
> > b) it might also be useful to divide the effort into 
> seperate tracks 
> > for
> > 
> >    i)   application domain specific code
> >    ii)  Process oriented components
> >    		I)   Sensory components
> > 		II)  Std control models
> > 		III) Std libraries for estimation ...
> > 		IV)  User interfaces
> >    iii) Frameworks
> >         I)   hard-real time mechanisms
> > 		II)  soft real-time mechanisms
> > 		III) Non-real time mechanisms
> 
> This is _very_ much what I had in mind. (But apparently 
> wasn't able to describe clearly enough :-) The "frameworks" 
> are what I called "infrastructure"; the process oriented 
> components are "functionality libraries".
> 
> > As an example Corba is good for soft real-time but so far there is 
> > only liimited support for hard real-time and TAO is one 
> option, but on 
> > the other hand do you want to be tied into a single 
> software provider, 
> > I guess not.
> No, but this is basically a matter of time: the CORBA specs 
> are the only ones that are vendor-neutral. But, as in the 
> current Orocos project, CORBA should not be the norm but 
> rather an option. I mean, all functionality should be 
> available and useable without having to use CORBA.
> 
> > Another topic is user interfaces, where QT and similar 
> libraries are 
> > excellent for general graphics and Java is also an 
> excellent choice. 
> > For hard real-time both of them are however inadequate. All 
> X derived 
> > components have the problem that X relies on a queuing model for 
> > graphics, while in hard real-time you want the graphics system to 
> > discard output if it is too old and you want a system that 
> is scalable 
> > with respect to load. This is not true for X based graphics today.
> GUIs is an important topic, indeed. And the problems you 
> describe are quite well known too.(At least, nobody in the 
> Orocos GUI workshop of yesterday was surprised by these facts 
> :-) "The" answer is: to provide neutral stuff as far as we 
> can, with event-driven and polling client-server 
> communication policies. Anyway, there will be _many_ client 
> toolkits. Many. But that's an unavoidable fact, that also 
> doesn't compromise the whole project.
> 
> > in user interfaces one also needs to consider the diverse needs of 
> > user interfaces. Most systems will be used for a variety of 
> different 
> > users with differing requirements: floor operator, system repair 
> > person, System installer, plant operator, unit manager ... Module 
> > programmer, ...
> 
> Absolutely! So the project is not focussing on the HMI 
> clients! (HMI = Human Machine Interface). It's providing 
> "everything" below the HMI. (And probably also some HMI 
> clients, for demonstration purposes.) Again, this is what I 
> mean when I talk about "infrastructure" :-)
> 
> > The use of patterns is excellent to capture process models, but it 
> > does not capture standard models for data.
> Agreed!
> 
> > It might be useful to consider if
> > something can be done to standardise data / representation 
> models as 
> > well. Woudl it be possible to standardise data models across
> > 
> > a) basic geometry
> >    i)  point, lines, planes, vectors, matrices, ....
> >    ii) std operations on data points
> > b) geometry with uncertainty
> >    i)  points lines, ... with associated uncertainty
> >    ii) std estimators for operations on data types
> 
> Well, this is certainly needed, but this is quite 
> robotics-centered. WHile Orocos-II would consider robotics 
> _only_ as one of the many application domains. The things you 
> mention above should be done by the current Orocos community, 
> i.e., the robotics people. 
> (And two people in KUL are working towards these things... We 
> _must_ start discussing these issues on the mailinglist _very_ soon!)
> 
> [...]
> > Thus it might be good to consider how the development 
> process can be 
> > divided to ensure assembly of key people across a 
> particular topic and 
> > how how it can be programmed with enough independence while at the 
> > same time ensuring compatibility across the system.
> 
> Absolutely. So, my concrete suggestion in this area is the 
> following: the core group should be good enough to cope with 
> the independence and compatibility issues, and sufficiently 
> expert in "control" in order to work together with the "key 
> area expertise" groups that have to fill in the 
> subcontracting projects.
> 
> > As I said in the beginning: good start, but it might be useful to 
> > consider
> > 
> > I) what are the application domains
> "Everything" in feedback control! At all levels of real-time, 
> and all levels of complexity.
> 
> > II) How can the different parts be organised to provide
> >     -- progress
> > 	-- independence in design ...
> > 	-- compatibility
> My (current) answer to this: the people of the core group of 
> three partners. So, this group will not be easy to find :-)
> 
> Thanks for the useful criticism! My impression was that we 
> are thinking along the same lines, but the current text does 
> not convey the ideas clearly enough.
> 
> Herman Bruyninckx
> -- 
>   K.U.Leuven, Mechanical Engineering, Robotics Research Group 
> <http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480
> 
> 
> --__--__--
> 
> Message: 5
> Date: Sun, 22 Jun 2003 20:03:46 +0200
> Subject: Re: [Orocos] First draft of "OROCOS II" proposal...
> Cc: "Henrik I. Christensen" <[email protected]>
> To: [email protected]
> From: [email protected]
> Reply-To: [email protected]
> 
> Hi!
> 
> Thank you for your response. I think it is important to 
> clearly define 
> the scope and task of a new project. If you make it too 
> general then it 
> will automatically "compete" with other projects on 
> distributed systems 
> and at the same time it is difficult to achieve the cohesion 
> across the 
> involved partners.
> 
> I agree that tying it to close to application is a dead-end, but they 
> might been seen as "examples" that at least must be possible with the 
> infrastructure. At the same time the division into
> 
> a) real real-time, soft real-time and non-realtime is import as the 
> requirements are radically different.
> 
> What are the target areas to be covered:
> 
> I would consider a system to be composed of four parts:
> 
> a) Hardware abstraction / interfaces
> b) Operating system services (scheduling, communication, 
> mutex, ...) -- 
> incl architecture
>     think of it as an abstract engine/architecture for tying 
> components 
> together and offer
>     default services for process handling and integration
> c) Toolkits (libraries).... toolkits to enable / support applications.
> d) User interfaces
> 
> Does your text imply that you primarily will focus on a) and b)? I.e. 
> you mentioned that user interfaces are
> needed but it is not a core focus. What about toolkits? Where 
> does the 
> project end and where do other take over? Would you want standard 
> toolkits for estimation, control design, process modelling (a la UML, 
> Process algebra, ...) ...
> 
> On söndag, jun 22, 2003, at 17:37 Europe/Stockholm, 
> [email protected] wrote:
> 
> > On Sat, 21 Jun 2003 [email protected] wrote:
> >
> > [...]
> >> a) The proposal seems to be primarily targeted to factory 
> automation
> >> and
> >>    manipulation type robotics. Is this the direction you want to 
> >> emphasize?
> > Not at all! It should be completely application 
> independent. But I do 
> > realise that it's awefully difficult to consistently use 
> fully neutral 
> > terminology :-(
> >
> 
> Ok that clarifies things a bit for me.
> 
> >>    Robotics today is much more than that. It might be sensible to
> >> divide
> >>    the work into
> >>
> >>    i)   factory automation (intg with PLC, NC control...)
> >>    ii)  manipulation systems
> >>    iii) mobile systems
> >
> > My subdivision was orthogonal to this: "real-time", "small 
> distributed 
> > system", "large distributed system". Whatever these systems 
> might be. 
> > Your suggestion is too much application oriented, IMHO, and the 
> > project should not be guided by applications.
> 
> 
> See above
> >
> >> b) it might also be useful to divide the effort into 
> seperate tracks
> >> for
> >>
> >>    i)   application domain specific code
> >>    ii)  Process oriented components
> >>    		I)   Sensory components
> >> 		II)  Std control models
> >> 		III) Std libraries for estimation ...
> >> 		IV)  User interfaces
> >>    iii) Frameworks
> >>         I)   hard-real time mechanisms
> >> 		II)  soft real-time mechanisms
> >> 		III) Non-real time mechanisms
> >
> > This is _very_ much what I had in mind. (But apparently 
> wasn't able to 
> > describe clearly enough :-) The "frameworks" are what I called 
> > "infrastructure"; the process oriented components are 
> "functionality 
> > libraries".
> >
> 
> See above
> 
> >> As an example Corba is good for soft real-time but so far there is 
> >> only liimited support for hard real-time and TAO is one 
> option, but 
> >> on the other hand do you want to be tied into a single software 
> >> provider, I guess not.
> > No, but this is basically a matter of time: the CORBA specs are the 
> > only ones that are vendor-neutral. But, as in the current Orocos 
> > project, CORBA should not be the norm but rather an option. I mean, 
> > all functionality should be available and useable without having to 
> > use CORBA.
> >
> 
> 
> I agree 100% you want "patterns" (and interfaces / abstractions) that 
> allow use of (in principle) any communication mechanism.
> 
> >> Another topic is user interfaces, where QT and similar 
> libraries are 
> >> excellent for general graphics and Java is also an 
> excellent choice. 
> >> For hard real-time both of them are however inadequate. 
> All X derived
> >> components
> >> have the problem that X relies on a queuing model for 
> graphics, while
> >> in hard real-time you want the graphics system to discard 
> output if 
> >> it is
> >> too old and you want a system that is scalable with 
> respect to load. 
> >> This
> >> is not true for X based graphics today.
> > GUIs is an important topic, indeed. And the problems you 
> describe are 
> > quite well known too.(At least, nobody in the Orocos GUI 
> workshop of 
> > yesterday was surprised by these facts :-) "The" answer is: 
> to provide 
> > neutral stuff as far as we can, with event-driven and polling 
> > client-server communication policies. Anyway, there will be _many_ 
> > client toolkits. Many. But that's an unavoidable fact, that also 
> > doesn't compromise the whole project.
> >
> 
> But it might be important in particular to consider how HARD 
> real-time 
> graphics can be handled in a fashion similar to what is done for 
> example in QNX where the graphics is supposed to be real-time.
> 
> >> in user interfaces one also needs to consider the diverse needs of 
> >> user interfaces. Most systems will be used for a variety 
> of different 
> >> users with differing requirements: floor operator, system repair 
> >> person, System installer, plant operator, unit manager ... Module 
> >> programmer, ...
> >
> > Absolutely! So the project is not focussing on the HMI 
> clients! (HMI = 
> > Human Machine Interface). It's providing "everything" below 
> the HMI. 
> > (And probably also some HMI clients, for demonstration purposes.) 
> > Again, this is what I mean when I talk about "infrastructure" :-)
> >
> 
> I still like the idea of toolkits as used in java, where a 
> reasonable OO model for grahics has been achieved, even if 
> the speed is a problem 
> for
> some applications.
> 
> >> The use of patterns is excellent to capture process models, but it
> >> does
> >> not capture standard models for data.
> > Agreed!
> >
> >> It might be useful to consider if
> >> something can be done to standardise data / representation 
> models as
> >> well.
> >> Woudl it be possible to standardise data models across
> >>
> >> a) basic geometry
> >>    i)  point, lines, planes, vectors, matrices, ....
> >>    ii) std operations on data points
> >> b) geometry with uncertainty
> >>    i)  points lines, ... with associated uncertainty
> >>    ii) std estimators for operations on data types
> >
> > Well, this is certainly needed, but this is quite robotics-centered.
> 
> fair enough, but where do you want to draw the line, if you make the 
> focus too wide then it will be close to impossible to design data 
> representations that are actually useful. For control it 
> might still be 
> useful to use the representations above as it woudl allow handling of 
> SISO systems, State space models and with an addition of discrete 
> mathematic models (as done in LEDA) you can handle DES and in some 
> cases HDS systems.
> 
> > WHile Orocos-II would consider robotics _only_ as one of the many 
> > application domains. The things you mention above should be done by 
> > the current Orocos community, i.e., the robotics people. (And two 
> > people in KUL are working towards these things... We _must_ start 
> > discussing these issues on the mailinglist _very_ soon!)
> >
> 
> Agreed, can we start now? What is needed in top of the model 
> above for 
> represnetation?
> 
> > [...]
> >> Thus it might be good to consider how the development 
> process can be 
> >> divided to ensure assembly of key people across a particular topic 
> >> and how how it can be programmed with enough independence while at 
> >> the same time ensuring compatibility across the system.
> >
> > Absolutely. So, my concrete suggestion in this area is the 
> following: 
> > the core group should be good enough to cope with the 
> independence and 
> > compatibility issues, and sufficiently expert in "control" 
> in order to 
> > work together with the "key area expertise" groups that 
> have to fill 
> > in the subcontracting projects.
> >
> 
> OK, but I woudl still like to see a further subdivision to make it 
> manageable. I.e. you/we need to devide the problem space to attract 
> "domain" experts to each of the areas. Then the core group has to try 
> to harmonize agrees the areas.
> > My (current) answer to this: the people of the core group of three 
> > partners. So, this group will not be easy to find :-)
> >
> 
> Yes you have made a challenge for yourself.
> 
> Henrik
> 
> ---------------------------------------------------------
> Centre for Autonomous Systems   E-mail: [email protected]
> CVAP/NADA                       GSM:   +46 70 670 6240
> Kungliga Tekniska Hoegskolan    URL: www.nada.kth.se/~hic
> SE-100 44 Stockholm, Sweden
> ---------------------------------------------------------
> Delivery address. Fiskartorpsvägen 15A, 10044 Stockholm
> ---------------------------------------------------------
> 
> 
> --__--__--
> 
> Message: 6
> Date: Sun, 22 Jun 2003 20:49:18 +0200
> To: [email protected]
> Subject: Re: [Orocos] First draft of "OROCOS II" proposal...
> From: [email protected]
> Reply-To: [email protected]
> 
> On Sun, Jun 22, 2003 at 08:03:46PM +0200, 
> [email protected] wrote:
> > But it might be important in particular to consider how 
> HARD real-time
> > graphics can be handled in a fashion similar to what is done for 
> > example in QNX where the graphics is supposed to be real-time.
> 
> May I ask what hard realtime graphics should be good for? I 
> mean, the human looking at the screen is not hard realtime in 
> terms of machine response times, so I don't see any 
> application for such a beast. 
> 
> Robert 
> -- 
>  Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de  
> Pengutronix - Linux Solutions for Science and Industry
>    Braunschweiger Str. 79,  31134 Hildesheim, Germany
>    Handelsregister:  Amtsgericht Hildesheim, HRA 2686
>     Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4
> 
> --__--__--
> 
> Message: 7
> Date: Sun, 22 Jun 2003 20:55:22 +0200 (CEST)
> To: [email protected]
> Subject: Re: [Orocos] First draft of "OROCOS II" proposal...
> From: [email protected]
> Reply-To: [email protected]
> 
> On Sun, 22 Jun 2003 [email protected] wrote:
> 
> > Thank you for your response. I think it is important to 
> clearly define
> > the scope and task of a new project. If you make it too 
> general then it 
> > will automatically "compete" with other projects on 
> distributed systems 
> > and at the same time it is difficult to achieve the 
> cohesion across the 
> > involved partners.
> 
> The opposite approach (focussing, again, on robotics) will 
> have the same risk, I guess.
> 
> > I agree that tying it to close to application is a 
> dead-end, but they
> > might been seen as "examples" that at least must be 
> possible with the 
> > infrastructure. 
> I agree. I guess the concrete applications will follow from 
> the partners' interests...
> 
> > At the same time the division into
> > 
> > a) real real-time, soft real-time and non-realtime is import as the
> > requirements are radically different.
> I agree too. (And I thought I made this clear in my first draft :-)
> 
> > a) Hardware abstraction / interfaces
> I don't think this is valid in this project: the way I see it, the
> project's focus is far away form the hardware. Except maybe for some
> smaller parts.
> 
> > b) Operating system services (scheduling, communication, 
> mutex, ...) -- 
> > incl architecture think of it as an abstract engine/architecture for
> > tying components together and offer default services for process
> > handling and integration
> 
> I would phrase it differently: the goal is to give 
> application builders
> tools and interfaces that are "optimally" suited for control. And that
> means that they are quite far from the traditional OS primitive.
> The project would result in an "control-oriented operating system".
> 
> > c) Toolkits (libraries).... toolkits to enable / support 
> applications.
> > d) User interfaces
> Yes.
> 
> > Does your text imply that you primarily will focus on a) and b)? 
> No, b,c and e.
> 
> > needed but it is not a core focus. What about toolkits? 
> Where does the 
> > project end and where do other take over? Would you want standard 
> > toolkits for estimation, control design, process modelling 
> (a la UML, 
> > Process algebra, ...) ...
> 
> "Standard" is a dangerous thing to talk about... I want software that
> every control project can use.
> 
> [...]
> > I agree 100% you want "patterns" (and interfaces / 
> abstractions) that 
> > allow use of (in principle) any communication mechanism.
> 
> Indeed: the infrastructure provides useful "mechanism", while the
> concrete application builder chooses his favorite "policy".
> 
> [...]
> > But it might be important in particular to consider how 
> HARD real-time 
> > graphics can be handled in a fashion similar to what is done for 
> > example in QNX where the graphics is supposed to be real-time.
> 
> With the emphasis on "supposed" :-) I indeed want a
> as-fast-as-possible plotting library, but this would be a rather
> simple and focussed subset of the whole UI effort.
> 
> [...]
> > > Well, this is certainly needed, but this is quite 
> robotics-centered.
> > 
> > fair enough, but where do you want to draw the line, if you 
> make the 
> > focus too wide then it will be close to impossible to design data 
> > representations that are actually useful. 
> 
> Finding the most appropriate "line" is indeed an important topic of
> discussion within the project...
> 
> > For control it might still be 
> > useful to use the representations above as it woudl allow 
> handling of 
> > SISO systems, State space models and with an addition of discrete 
> > mathematic models (as done in LEDA) you can handle DES and in some 
> > cases HDS systems.
> 
> Okay, but this is "systems and control theory", and the "objects"
> there are sufficiently mature and agreed upon such that they indeed
> belong in the project. In the draft, I somewhere talk about
> "simulation of control systems"; the things you mention (and some
> more) are part of that WP.
> 
> [...]
> > OK, but I woudl still like to see a further subdivision to make it 
> > manageable. I.e. you/we need to devide the problem space to attract 
> > "domain" experts to each of the areas. 
> 
> I agree. That's what I hope this open discussion can lead to.
> 
> > > My (current) answer to this: the people of the core group of three
> > > partners. So, this group will not be easy to find :-)
> > 
> > Yes you have made a challenge for yourself.
> > 
> The EU wants challenging project...
> 
> Herman
> 
> PS The suggestions I made are "far away" from robotics, with the
>    express purpose of not to compete with possible robotics STREPS.
> -- 
>   K.U.Leuven, Mechanical Engineering, Robotics Research Group
> <http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480
> 
> 
> 
> --__--__--
> 
> _______________________________________________
> Orocos mailing list
> [email protected]
> http://mail.mech.kuleuven.ac.be/mailman/listinfo/orocos
> 
> 
> End of Orocos Digest
>