Re: Configuration: a service needed in OROCOS

On Fri, 6 Apr 2001, Christian Schlegel wrote:

> > In order to prepare the meeting and the project, I now officially
> > invite everybody to start thinking about the strategic parts of the
> > project. I have some designs I would like to launch during the
> > following weeks; other people who have a broad and detailed vision on
> > some aspects of the software should also take the opportunity to
> > present them for open discussion on the mailinglist.
>
>
> Dear all,
>
> Just to pick up that call I would like to draw attention to the
> important aspect of the interaction of software frameworks and
> system architectures.
[...]
> I do not believe that it makes sense to state a system
> architecture as guideline for a software framework. Rather
> I hold the view that there are many patterns needed all
> the time in all kinds of architectures. A flexible framework
> should support particularly suitable and often needed
> patterns.

If I may translate this into my words: Orocos should provide modules,
with which one can construct any architecture one likes? This is
indeed what I think the project should be. Nevertheless, I am
interested in talking about what architectures to build and how to
build them from the blocks :-)

> An often neglected aspect in many frameworks for example
> concerns module configuration and I would like to stress its
> importance. A configuration class for examples allows to
> select different activity states based on a finite state automaton.
> This automaton can be extended but has to provide a
> minimum set of states like error, deactivated etc.
> When one wants to deactivate a module at run time,
> it is the job of the configuration class within
> a module to reach the desired state in an ordered
> and safe way. This for example includes cancelling
> pending queries of the module etc. Therefore there
> is an interference between the configuration class
> and other communication mechanisms.

I completely follow your reasoning ! However, in the past I have tried
and sat down with a couple of people in our lab to come up with this
configuration specification for the motion control part of a general
robot controller; we didn't succeed in obtaining a concrete
specification.... Do you have more concrete suggestions in this
particular area? Or, in another relevant area of robotics: the task
execution?

Or do you have a design document draft you would like to post for
discussion? (I can put it on the WWW, or just provide a link.)

My rough ideas:
- a motion controller has different subtasks (`threads''), such as:
  user command interpretation, trajectory generation, servo control,
  signal filtering, etc. Modelling this by means of a FSM is not so
  easy, except for the most trivial cases such as for single axis
  CNC machining.
- there is an existing analogous world which has already 50 years of
  experience with similar problems: the operating system of a computer.
  However, I fear the analogy doesn't run deep enough in order to be
  really useful...

Herman

-- 
[email protected]
 <http://www.mech.kuleuven.ac.be/~bruyninc/>