RE: Suggestion for Version 1.0 motion application API...

On Mon, 10 May 2004, VERMEERSCH Hans wrote:

> I am interested in how the following situation can be handled: In our
> application (weaving loom control), the overall motion dictated by the
> weaving application can be seen as a composition of several motion
> phases, e.g. "Slow Motion", "Fast Motion", "Brake", ... Each motion
> phase is fairly stand-alone and represents one type of behaviour the
> machine can exhibit, depending on possible external events. Furthermore,
> each of the motion phases can again be made up of several sub-motions
> (e.g. "Before Brake", "During Brake", "After Brake", ... The overall
> motion is thus formed as a state machine that combines all these motions
> into one hierarchy of motions, with clear triggers to transfer from one
> type of motion to another.

Ok, is it a linear state machine? That is covered in the "Path"
primitive: a sequence of ViaPoints (= a sequence of different motion
parameters), possibly connected with events for asynchronous triggering
of the various parts of the "Path".
If it is a non-linear state machine, you have to encode it in our
scripting engine: this can build "any" state machine (including the
simplest Petri Nets, in the near future), and in any state a desired
Generator can be triggered to generate the instantaneous setpoints.

It seems that your kind of motion requirements are a nice example of
the "heavy" design specifications that we have put in the motion part of
the Orocos framework: every "transition" (e.g., going from "Before
Brake" to "During Brake") can generate an event (or a list of events),
such that other parts of the machine can synchronize their actions. For
example, a different control algorithm can be selected; or a PLC can be
instructed to perform some function blocks; or...

> My question is the following:
> With the information provided I would assume that a hierarchy of motions
> should be modelled as a MotionTask. 
Maybe in the simpler construct of a Path. One of the differences I see
between a Path and a MotionTask is that the former _could_ be executed
without changes in Generator or Controller.

> But a MotionTask is apparently a
> sequence of Paths. However in the above scenario, it would be more
> natural if a MotionTask could again consist of a series of MotionTasks,
> which on their turn might consist of a Path or a SynchronizedPath. 
> Is there a possibility to compose MotionTasks into such a hierarchy ?

There are multiple possibilities:
- MotionTasks are SEQ/PAR combinations of Paths, so this gives _some_
  hierarchy, but not any possible tree structure.
  (SEQ: sequential execution; PAR: parallel execution, with
   sychronization possibilities between the SEQ parts; the SEQ and PAR
   notions are borrowed from CSP (Concurrent Sequential Processes)
   programming).
- more general hierarchies can (must!) be constructed with the scripting
  engine.

The differences between a MotionTask/Path/... on the one hand, and the
scripting on the other hand is the traditional distinction: scripting is
_programming_, the MotionTask is a _file_. Hence, scripting can do
everything that a MotionTask can do, but not the other way around.

> Or would I have to call MyMotionApplication.Move ( MotionTask ) each
> time I want to switch from one type of motion to another ? Here my
> concern would be in the real-time behavior. If I need to switch quickly
> from one type of motion to the next, couldn't the parsing of the new
> MotionTask induce a delay ?

For real realtime behaviour, the scripting is most appropriate. _But_
the Generator and Controller (and possibly Estimator) of the application
must then be programmed in such a way that they can provide safe
transitions between different motion segments, in realtime. (That is what
we are aiming at in our own research too, by the way.)

So, the motion is not _completely_ or only determined by the
MotionTask/Path/..., but also by the functionality ("behaviour") inside
the application's Components.

Just to be sure that your expectations are not too high: the current API
is to a large extent still in the _design_ phase :-) The scripting is
operational, however. And it's realtime: the script is preprocessed into
a structure of objects that contain the state information, and hence
the corresponding state machine is realtime. (As long as the
functionalities executed in the states are realtime-safe, that is!)

Herman