Hi,
I noticed that the event port from the nAxisGenerator is actually not
implemented. In attachment you can find a patch with an implementation for
the port. The events I added are:
configured_event, moving_event and move_finished_event.
Especially the last one was what I needed.
Kind regards,
Bert
| Attachment | Size |
|---|---|
| 0001-sending-events-functionality-updated.patch | 3.71 KB |
Motion control stack
On Tue, Nov 27, 2012 at 1:54 PM, Bert Willaert
<bert [dot] willaert [..] ...> wrote:
> Hi,
>
> I noticed that the event port from the nAxisGenerator is actually not
> implemented. In attachment you can find a patch with an implementation for
> the port. The events I added are:
>
> configured_event, moving_event and move_finished_event.
>
> Especially the last one was what I needed.
Thanks for the improvement. Who's picking up this patch and merging it in ?
Peter
Motion control stack
In the meantime, i have some minor extra changes. I ' ll send a new patch
later today.
bert
On Thursday, December 13, 2012, Peter Soetens <peter [..] ...>
wrote:
> On Tue, Nov 27, 2012 at 1:54 PM, Bert Willaert
> <bert [dot] willaert [..] ...> wrote:
>> Hi,
>>
>> I noticed that the event port from the nAxisGenerator is actually not
>> implemented. In attachment you can find a patch with an implementation
for
>> the port. The events I added are:
>>
>> configured_event, moving_event and move_finished_event.
>>
>> Especially the last one was what I needed.
>
> Thanks for the improvement. Who's picking up this patch and merging it in
?
>
> Peter
>
Motion control stack
Hey,
In attachment there is a patch that makes 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:
On Fri, Dec 14, 2012 at 9:14 AM, Bert Willaert <
bert [dot] willaert [..] ...> wrote:
> In the meantime, i have some minor extra changes. I ' ll send a new patch
> later today.
>
> bert
>
>
> On Thursday, December 13, 2012, Peter Soetens <peter [..] ...>
> wrote:
> > On Tue, Nov 27, 2012 at 1:54 PM, Bert Willaert
> > <bert [dot] willaert [..] ...> wrote:
> >> Hi,
> >>
> >> I noticed that the event port from the nAxisGenerator is actually not
> >> implemented. In attachment you can find a patch with an implementation
> for
> >> the port. The events I added are:
> >>
> >> configured_event, moving_event and move_finished_event.
> >>
> >> Especially the last one was what I needed.
> >
> > Thanks for the improvement. Who's picking up this patch and merging it
> in ?
> >
> > Peter
> >
>
Motion control stack
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.
Please neglect the patch I send one/two weeks ago.
Bert
>
> On Fri, Dec 14, 2012 at 9:14 AM, Bert Willaert <
> bert [dot] willaert [..] ...> wrote:
>
>> In the meantime, i have some minor extra changes. I ' ll send a new patch
>> later today.
>>
>> bert
>>
>>
>> On Thursday, December 13, 2012, Peter Soetens <peter [..] ...>
>> wrote:
>> > On Tue, Nov 27, 2012 at 1:54 PM, Bert Willaert
>> > <bert [dot] willaert [..] ...> wrote:
>> >> Hi,
>> >>
>> >> I noticed that the event port from the nAxisGenerator is actually not
>> >> implemented. In attachment you can find a patch with an implementation
>> for
>> >> the port. The events I added are:
>> >>
>> >> configured_event, moving_event and move_finished_event.
>> >>
>> >> Especially the last one was what I needed.
>> >
>> > Thanks for the improvement. Who's picking up this patch and merging it
>> in ?
>> >
>> > Peter
>> >
>>
>
>
Motion control stack
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.
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.
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.
> Please neglect the patch I send one/two weeks ago.
>
> Bert
Herman
>
>
> On Fri, Dec 14, 2012 at 9:14 AM, Bert Willaert <bert [dot] willaert [..] ...>
> wrote:
> In the meantime, i have some minor extra changes. I ' ll send a new
> patch later today.
>
> bert
>
> On Thursday, December 13, 2012, Peter Soetens <peter [..] ...>
> wrote:
> > On Tue, Nov 27, 2012 at 1:54 PM, Bert Willaert
> > <bert [dot] willaert [..] ...> wrote:
> >> Hi,
> >>
> >> I noticed that the event port from the nAxisGenerator is actually not
> >> implemented. In attachment you can find a patch with an
> implementation for
> >> the port. The events I added are:
> >>
> >> configured_event, moving_event and move_finished_event.
> >>
> >> Especially the last one was what I needed.
> >
> > Thanks for the improvement. Who's picking up this patch and merging it
> in ?
> >
> > Peter
> >
>
>
>
>
>
--
KU Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
Vice-President Research euRobotics <http://www.eu-robotics.net>
Open RObot COntrol Software <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
Motion control stack
On Sun, Dec 16, 2012 at 6:38 PM, Herman Bruyninckx <
Herman [dot] Bruyninckx [..] ...> 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?
>
> 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 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?
>
> Please neglect the patch I send one/two weeks ago.
>>
>> Bert
>>
>
> Herman
>
>
>
>>
>> On Fri, Dec 14, 2012 at 9:14 AM, Bert Willaert <
>> bert [dot] willaert [..] ...en.**be <bert [dot] willaert [..] ...>>
>> wrote:
>> In the meantime, i have some minor extra changes. I ' ll send
>> a new
>> patch later today.
>>
>> bert
>>
>> On Thursday, December 13, 2012, Peter Soetens <
>> peter [..] ...>
>> wrote:
>> > On Tue, Nov 27, 2012 at 1:54 PM, Bert Willaert
>> > <bert [dot] willaert [..] ...en.**be<bert [dot] willaert [..] ...>>
>> wrote:
>> >> Hi,
>> >>
>> >> I noticed that the event port from the nAxisGenerator is
>> actually not
>> >> implemented. In attachment you can find a patch with an
>> implementation for
>> >> the port. The events I added are:
>> >>
>> >> configured_event, moving_event and move_finished_event.
>> >>
>> >> Especially the last one was what I needed.
>> >
>> > Thanks for the improvement. Who's picking up this patch and
>> merging it
>> in ?
>> >
>> > Peter
>> >
>>
>>
>>
>>
>>
>>
> --
> KU Leuven, Mechanical Engineering, Robotics Research Group
> <http://people.mech.kuleuven.**be/~bruyninc
> Vice-President Research euRobotics <http://www.eu-robotics.net>
> Open RObot COntrol Software <http://www.orocos.org>
> Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org
> >
>
Motion control stack
On Mon, 17 Dec 2012, Bert Willaert wrote:
> On Sun, Dec 16, 2012 at 6:38 PM, Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...> 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
Motion control stack
On Mon, Dec 17, 2012 at 1:37 PM, Herman Bruyninckx <
Herman [dot] Bruyninckx [..] ...> wrote:
> On Mon, 17 Dec 2012, Bert Willaert wrote:
>
> On Sun, Dec 16, 2012 at 6:38 PM, Herman Bruyninckx <
>> Herman.Bruyninckx@mech.**kuleuven.be <Herman [dot] Bruyninckx [..] ...>>
>> 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" :-)
There is a new patch in attachment (that contains all the changes, so again
neglect the previous one).
The 'e_name_moving' event has been changed to an 'e_name_move_started'
event that is send each time the moveTo command is called succesfully.
>
>
> 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
>
Motion control stack
On Tue, Dec 18, 2012 at 03:55:08PM +0100, Bert Willaert wrote:
...
> There is a new patch in attachment (that contains all the changes, so again
> neglect the previous one).
> The 'e_name_moving' event has been changed to an 'e_name_move_started' event
> that is send each time the moveTo command is called succesfully.
Applied, thanks!
Markus
Motion control stack
On Thu, Dec 13, 2012 at 10:30:16PM +0100, Peter Soetens wrote:
> On Tue, Nov 27, 2012 at 1:54 PM, Bert Willaert
> <bert [dot] willaert [..] ...> wrote:
> > Hi,
> >
> > I noticed that the event port from the nAxisGenerator is actually not
> > implemented. In attachment you can find a patch with an implementation for
> > the port. The events I added are:
> >
> > configured_event, moving_event and move_finished_event.
> >
> > Especially the last one was what I needed.
>
> Thanks for the improvement. Who's picking up this patch and merging it in ?
I am!
M