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