Minutes of mini-meeting at KTH, Feb 28 - March 1st 2002

Herman Bruyninckx <[email protected]>
Newsgroups gmane.science.robotics.orocos.user
Message-ID <Pine.LNX.4.44.0203041008520.6279-100000@pc25-213.mech.kuleuven.ac.be>
Minutes of the mini Orocos meeting at KTH, Stockholm
February 28th -- March 1st, 2002

Attendees:
Henrik Christensen, Anders Oreback, Peter Soetens, Herman Bruyninckx

Agenda:
1. Communication Patterns
2. Orocos Object Hierarchy (OOH)
3. Anders Oreback will work in Leuven for two weeks
4. PhD Lars Petersson


1. Communication Patterns
=========================
- The basic software patterns presented previously by Christian Schlegel 
  are a good basis to start from. Anders will produce a short document that
  summarizes these patterns.

- The suggestion is not to take the Configuration Pattern into
  consideration at this moment, because it's like the many ``ultimate
  escape'' patterns that tend to make software systems prone to bad use:
  it's the kind of thing that people will start to use as soon as they
  don't find what they need in the available API.
  Therefore, if such a non-covered need arises, it will be better to
  design and implement a new specific communication pattern, instead of
  delegating the solution of the missing feature to the Configuration
  Pattern.

- The suggestion is to use the IDL (Interface Definition Language) of
  CORBA as the language with which to _specify_ the API of the
  communication service, irrespective of what programming language
  will be used in the implementation. The motivation is that it's
  difficult to motivate why to use something else.

- All people should investigate whether their communication needs are
  covered by the presented Patterns. If not, please report that fact
  on the mailinglist. If the Patterns do suffice, start using
  them, and using them exclusively, in all Orocos work.

- The communication patterns are inherently independent of the types and
  the content of the information that they communicate. Hence, there
  should ideally be no dependence on the rest of the Orocos project, and
  the implementation could be an independent package. In addition,
  we might find already existing implementations of the communication
  patterns (such as in GNOME or KDE). The Orocos implementation should
  preferably be light-weight; (i) Orocos probably doesn't need
  much feature bloat, and (ii) it would be extremely nice if we could use
  the same code in different levels of the software (e.g., in real-time,
  as well as in widely distributed systems).

- The communication patterns will/should work with any object, and
  explicit object serialization should be kept out of the API.

2. Orocos Object Hierarchy (OOH)
================================
Orocos must come up with object descriptions in all robotics-related areas.
Maybe the result will be one single object hierarchy, maybe more than
one, but the important thing is to find a balance between useability of
this object hierarchy on the one hand, and completeness on the other
hand. 

The suggestion is to go for a first version of the OOH without striving
for completeness. However, the minimum is that all systems currently used
by project partners should be covered.

Herman is working on the kinematics and manipulator part, Peter on the
motion control part, and Anders on the mobile platform part.

3. Anders Oreback will work in Leuven for a week or two
=======================================================
Anders expressed his interest in spending a week or two in K.U.Leuven in
the near future, in order to work together in more detail on the topics
of the previous points. More in particular, we will investigate together
what are the exact needs for the communication interface and
communication patterns at the lowest control levels.

4. PhD Lars Petersson
=====================
The meeting took place at the occasion of Lars Petersson's PhD thesis
on ``A framework for integration of processes in autonomous systems''
<http://www.nada.kth.se/~larsp/>.
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.