Re: Draft of motion programming interface...

On Mon, 16 Dec 2002 [email protected] wrote:

> ...
> > The programming interface for the Application Builder relies on the
> > fact that the robot controller is designed according to the Orocos
> > Software Pattern for control; i.e., it knows that the following
> > components exist, and that it has to plug-in their functionalities:
> > - Generator (generates motion setpoints),
> > - Scanner (collects sensor inputs),
> > - Observer (makes estimates),
> > - Actuator (puts the outputs on the motors),
> > - Reporter (collects data from all other components and returns
> >   them to the user), and
> > - Controller (reads in motion setpoints, sensor inputs and
> >   observer estimates, and sends out outputs).
>
> As these are the conceptual names for what is in there, I am not sure if they
> map 1 to 1 on the interface/component level. Many (different) interfaces
> might be needed to define a generator and i can imagine a lot of generators
> with only a minimal common interface.

That's right, and that's exactly what is aimed at: the interface at the
framework level is minimalistic; each application adds its own
interfaces, when needed.

[...]
> > The different plug-ins are accessed by their registered names. For
> > example, the setpoints for the tool are generated by a call
> > "getSetpoints("toolGen", setpoints)".
>
> This is not the best way. It is better to resolve "toolGen" once (at
> construction time), getting a reference and pulling from the object you get.
> Because if "toolGen" is not known, your program is in big trouble.

Of course, all traditional ways to make indirections more efficient can
(and will) be used here.  (I hope :-)

[...]
> > During configuration, also the information for the user interfacing is
> > collected, and sent to the user at the moment the motion starts. All
> > this is the job of the configurator component, i.e., the
> > ExecutionEngine. The reason for this is that the user interface
> > should be a faithful representation of what is running in the
> > controller, so the data should be filled in by the same component that
> > decides on what is configured in the controller.
>
> which data ? This part is not clear to me.

The data about what has been configured in the application: the
user interface should know this, before it can give a reliable interface
that is consistent with the real system.


> > In this draft, we do not go into the details of how the
> > ExecutionEngine does the configuration. But in general it will be
> > impossible to do a full configuration in real-time, and in a way that
> > is guaranteed to be consistent. Therefore, a two-step procedure (with
> > corresponding two-phase commit) seems natural: first collect all
> > configuration commands, and configure a "shadow" controller (possibly
> > while the current controller is still working); only after the
> > configuration is complete, the shadow controller replaces the current
> > controller. The configuration is a low-priority job, the switching can
> > be done in real-time, because it basically not more than switching a
> > set of pointers.
>
> The question rises if you want to force the programmer to use this,
> and if so, how. Well anyway, this behaviour should be shielded from
> the application programmer and be ExecutionEngine specific.

That depends: an application programmer can, in my opinion, have the
need to replace the ExecutionEngine's functionality with something
else...

[...]
> > Of course, it's the ExecutionEngine's task to decide when exactly the
> > prepared commands are executed.
>
> I still feel that the ExecutionEngine we are talking about now should be
> another component than the one that does configuration. There is a difference
> between processing/executing and configuring. Both are complex enough to
> motivate separation, conceptually and in implementation.

Ok, suggestions are welcome :-) But both things require about the same
functionality in the execution engine, isn't it?
I have, in principle, no problems with introducing a Configurator; but I
think this is already covered (implicitly) by the Command processing:
setting up a new configuration can be considered as a processing of
configuration commands; and then it's up to the ExecutionEngine to
decide when this `command' is executed; ie., when the  new configuration
is done.
But anyway, this part of the framework still needs lots of work and
discussion :-)

[...]
> > The "motionObject" is the name of a motion whose configuration has
> > been done before (as default by the Application Builder, or explicitly
> > by the advanced End User), through commands that will be discussed later.
> > "motionObjects" can come in a large variety: the G-code of CNC machine
> > tools; the programming primitives of commercial robot controllers; a
> > force-controlled compliant motion specification; a visual tracking
> > specification; an "elastic strip" motion; etc. All these particular
> > motion types are encoded in objects that inherit from the parent class
> > "motionObject".
>
> But these objects have such different functionalities and will be
> addressed so differently that the motionObject interface will be most
> likely completely empty. I think it is wiser to actually define
> explicitly all these variants as different interfaces instead of
> forcing all in a parent class.

Almost nothing is forced in one parent class... Just the fact to start
(and interrupt) a motion.
What would be your suggestion about "explicitly defining all these
variants"?
I would have to do that also, anyway, but as specialisations of the
parent class.

[...]
> As a global remark, i'd like to point out that generalisation on a
> conceptual level is nice, but it will fail on an implementation level.
> You have to specialise concepts so that an implementation becomes
> trivial instead of general (thus non trivial). Interfaces are meant
> for specialisation, not for generalisation.
> So i'd expect more something like a
>
> move(Trajectory2D t) & move(Trajectory3D t)
>
> instead. We can refactor later on.
>
What you do is what I (thought I) said: your Trajectory2D and
Trajectory3D are specialisations of destinationObjects...

I definitely need to describe things more precisely... And I see that
complete on-line reconfiguration is probably a bit too ambituous.
Re-_compilation_ might be the way out we _have_ to choose.

Herman

-- 
  K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480