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