Re: Draft of motion programming interface...

I made some remarks in the text.

On Saturday 14 December 2002 11:49, [email protected] 
wrote:
> This text is a draft for the robot motion programming interface of
> Orocos.
...
>
> 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. To be concreate, a 

bool getNext(T& setpoint); //T is a structure containing setpoint data

function might be the only common interface of all generators in a pull model 
( receiver knows generator ) and

bool setNext(const T& setpoint); 

is for a push model (generator knows receiver)

>
> 1. Configuration
> ================
> The configuration step is only meant for the Application Builder, or
> the advanced End User. The API used for configuration is quite uniform
> for all components. Or rather, "will be", because we have not decided
> yet about an API. For a generic "Component" it could be something
> like this:
> - Component.setPlugin("pluginName", pluginObject).
> - Component.setProperties("pluginName", parameters).

the corresponding get* functions should be there too of course. I don't see 
how well we can use generic plugins, since sooner or later, one has to
call the plugin and hence, know its task specific interface.

> Each component can get more than one plug-in for one single motion.
> For example, the Generator gets a first plug-in (called, for example,
> "robotGen") that generates the setpoints for a robot, and a second
> plug-in (called, for example, "toolGen") that generates the setpoints
> for an actuated tool attached to the robot. Configuration commands for
> both plug-ins are kept apart, thanks to the nameserving that is
> available in the Orocos core.
> If the motion generated by the two plug-ins above really have to be
> synchronized, it could be better to have them generated by the same
> plug-in function.
>
> 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.

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

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

> 2. Construction of the next motion
> ==================================
> When the user sends a motion command to the control core, this
> commands needs time to be parsed, interpreted and executed. Since a
> full specification of a complex motion could require several commands,
> and some motion commands must be executed back to back in a
> controlled, smooth way, it is in general impossible to do this in
> realtime. Therefore the construction of motion commands can be done in
> two modes:
> - "batch" : several commands are parsed and the corresponding motion
>   objects are filled in, and only then the whole thing is started.
> - "online": the new motion command is immediately given to the
>   controller. With the risk of non-smooth execution.
> 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.

>
>
> 3. Start the motion
> ===================
> In the simplest case, only two motion commands are available after
> configuration:
>
>   move (motionObject)
>   moveTo (motionObject, destinationObject)
>
> Both commands provide the last data needed before a motion can start,
> and they also start the motion.
>
> 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.

Well it is possible at some degree, but it will require heavy templating of 
the code (like the Standard Template Library for example).

>
> The "destinationObject" decribes a desired destination, which can be
> much more than just a target frame: the end-effector frame of a robot
> arm; the two hands and the head of a humanoid robot; a docking
> position annex arm configuration for a mobile manipulator.
> A "destinationObject" can also be more than position/orientation:
> contains velocity, acceleration, ...
> All these particular destination types are encoded in objects that
> inherit from the parent class "destinationObject".

same remark here...


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.

Peter