Re: Motion control stack

On Mon, 17 Dec 2012, Bert Willaert wrote:

> On Sun, Dec 16, 2012 at 6:38 PM, Herman Bruyninckx <[email protected]> wrote:
>       On Fri, 14 Dec 2012, Bert Willaert wrote:
>
>             Hey,
>
>             In attachment there is a patch that proposes some changes to the
>             motion_control stack. The
>             changes are:
>
>             1) namespace for all libraries is now MotionControl (for naxes it was
>             motion_control)
>
>             2) startHook of CartesianImpedanceController: same functionality but
>             more readable
>
>             3) both nAxes and Cartesian Generators now have an "events" port. While
>             moving an
>             "e_"+name+"_moving" event is sent continuously and when the motion is
>             finished an
>             "e_"+name+"_move_finished" event is sent once. This last change has been
>             verified only by using
>             the moveTo operation, but I assume it only affects that operation.
> 
> 
> I am against the use of an event that is sent out continuously! Events
> should be, well..., _events_, that is things that "happen" once in a while.

> True. I could change this to an "e_"+name+"_move_started" event that is send once. Is that more
> desirable?

It is more "event like" :-)

>       But your _intention_ is very good: while a motion is going in, there should
>       be a continuous "Quality of Service" data flow going on, which has the
>       information that you want to put in the "e_"+name+"_moving" event, and even
>       more.
> 
> Having the current implementation in mind, what can this QoS be?

The current implementation is, indeed, very poor in providing QoS data! But
that should be changed, in our more modern "constraint-based" motion
control :-) There, the obvious QoS measures are the ones that indicate how
much each constraint is violated; and a violation that exceeds a specified
threshold then gives rise to an event.

>       The name ""e_"+name+"_move_finished" is also not so good: the event should
>       indicate the _condition_ that caused the motion to stop, because there can
>       be many such causes.
> 
> Related to the question above: as far as I understand, there is at this moment only one
> condition that stops the motion, i.e. when the motion_profile has ended.
> Also, I see there is a pause() command, but there seems to be no way to restart the motion
> without doing a reset. Is that correct?

These remarks are most certainly very valid. Again, they have to be solved
by a paradigm shift, towards the above-mentioned "constraint-based" motion
control. In that context, "pause()" can also be a lot more clearly defined.

>             Please neglect the patch I send one/two weeks ago.
>
>             Bert

Herman
-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev