I was reading the chapter about statemachines in the Components builder manual
and i think the example:
is very outdated, it is still working with the very old KernelComponents.
Maybe it can be updated to a more recent type of application?
Ruben
![]() The Orocos ProjectSmarter control in robotics & automation! |
|
Outdated example in Components builder manual?
I was reading the chapter about statemachines in the Components builder manual is very outdated, it is still working with the very old KernelComponents. Ruben |
Outdated example in Components builder manual?
On Monday 06 October 2008 11:04:57 Ruben Smits wrote:
>/doc- xml/orocos-components-manual.html#id2641630>
> I was reading the chapter about statemachines in the Components builder
> manual and i think the example:
>
>
> is very outdated, it is still working with the very old KernelComponents.
> Maybe it can be updated to a more recent type of application?
Yep, it's dirty. Could you provide an example 'what it looks like' script ?
Peter
Outdated example in Components builder manual?
On Monday 06 October 2008 14:58:48 Peter Soetens wrote:
> >.x /doc- xml/orocos-components-manual.html#id2641630>
> On Monday 06 October 2008 11:04:57 Ruben Smits wrote:
> > I was reading the chapter about statemachines in the Components builder
> > manual and i think the example:
> >
> >
> > is very outdated, it is still working with the very old KernelComponents.
> > Maybe it can be updated to a more recent type of application?
>
> Yep, it's dirty. Could you provide an example 'what it looks like' script ?
In the attachment you can find a small example of a state-machine we use for
joint space control of our robots.
Ruben
Outdated example in Components builder manual?
On Oct 6, 2008, at 09:06 , Ruben Smits wrote:
> On Monday 06 October 2008 14:58:48 Peter Soetens wrote:
>>> .x /doc- xml/orocos-components-manual.html#id2641630>
>> On Monday 06 October 2008 11:04:57 Ruben Smits wrote:
>>> I was reading the chapter about statemachines in the Components
>>> builder
>>> manual and i think the example:
>>>
>>>
>>> is very outdated, it is still working with the very old
>>> KernelComponents.
>>> Maybe it can be updated to a more recent type of application?
>>
>> Yep, it's dirty. Could you provide an example 'what it looks like'
>> script ?
>
> In the attachment you can find a small example of a state-machine we
> use for
> joint space control of our robots.
Looking at the example, the following questions arise
- the CalibrateOffsetsProg stops itself apparently? This then ends the
CalibrateOffsetsState state. This probably won't be clear to a new user.
- the user has to manually set "stop" to get the MoveToState state to
end?
- why the double call to nAxesGeneratorPos.moveTo() in MoveToState?
These are two different moves, right. The first to the zero-pose, and
the second to some other pose. Perhaps we should comment this if this
is going to be an example to new users?
On a slightly different note, I believe that the default
implementation of nAxesGeneratorPos.moveTo() is a command, and so the
moveTo()'s don't return until the move actually completes. Because
this is done in the entry() program of the state, it means that you
can not transition during the move(s). This prevents transitions based
on say, user input or safety-related events, from changing states
using transitions within the state machine. We found this severly
limiting, and actually modified the implementation of
nAxesGeneratorPos (and the equivalent cartesian generator) to not use
commands and to issue an event upon move completion. This allows the
entry() program to complete and hence enables transitions again within
the run/handle state (which can open up other possible issues, I
agree). What are people's thoughts on these two approaches?
Cheers
S
Outdated example in Components builder manual?
On Monday 06 October 2008 15:43:49 S Roderick wrote:
> >>>.6 .x /doc- xml/orocos-components-manual.html#id2641630>
> On Oct 6, 2008, at 09:06 , Ruben Smits wrote:
> > On Monday 06 October 2008 14:58:48 Peter Soetens wrote:
> >> On Monday 06 October 2008 11:04:57 Ruben Smits wrote:
> >>> I was reading the chapter about statemachines in the Components
> >>> builder
> >>> manual and i think the example:
> >>>
> >>>
> >>> is very outdated, it is still working with the very old
> >>> KernelComponents.
> >>> Maybe it can be updated to a more recent type of application?
> >>
> >> Yep, it's dirty. Could you provide an example 'what it looks like'
> >> script ?
> >
> > In the attachment you can find a small example of a state-machine we
> > use for
> > joint space control of our robots.
>
> Looking at the example, the following questions arise
> - the CalibrateOffsetsProg stops itself apparently? This then ends the
> CalibrateOffsetsState state. This probably won't be clear to a new user.
The program stops itself. But to make the example more simple i removed it in
the attached version
> - the user has to manually set "stop" to get the MoveToState state to
> end?
Yes, because if the user likes he can issue new moveTo() commands using the
taskbrowser while the statemachine is in this state.
> - why the double call to nAxesGeneratorPos.moveTo() in MoveToState?
> These are two different moves, right. The first to the zero-pose, and
> the second to some other pose. Perhaps we should comment this if this
> is going to be an example to new users?
Or remove one :)
> On a slightly different note, I believe that the default
> implementation of nAxesGeneratorPos.moveTo() is a command, and so the
> moveTo()'s don't return until the move actually completes. Because
> this is done in the entry() program of the state, it means that you
> can not transition during the move(s). This prevents transitions based
> on say, user input or safety-related events, from changing states
> using transitions within the state machine. We found this severly
> limiting, and actually modified the implementation of
> nAxesGeneratorPos (and the equivalent cartesian generator) to not use
> commands and to issue an event upon move completion. This allows the
> entry() program to complete and hence enables transitions again within
> the run/handle state (which can open up other possible issues, I
> agree). What are people's thoughts on these two approaches?
Does this behaviour changes if i but the moveTo command in the run program??
Or is it still impossible to transition on events in this case?
Because if so, this is IMO a big bug in the state machine handling
Ruben
Outdated example in Components builder manual?
On Oct 7, 2008, at 02:50 , Ruben Smits wrote:
> On Monday 06 October 2008 15:43:49 S Roderick wrote:
>>>>> .6 .x /doc- xml/orocos-components-manual.html#id2641630>
>> On Oct 6, 2008, at 09:06 , Ruben Smits wrote:
>>> On Monday 06 October 2008 14:58:48 Peter Soetens wrote:
>>>> On Monday 06 October 2008 11:04:57 Ruben Smits wrote:
>>>>> I was reading the chapter about statemachines in the Components
>>>>> builder
>>>>> manual and i think the example:
>>>>>
>>>>>
>>>>> is very outdated, it is still working with the very old
>>>>> KernelComponents.
>>>>> Maybe it can be updated to a more recent type of application?
>>>>
>>>> Yep, it's dirty. Could you provide an example 'what it looks like'
>>>> script ?
>>>
>>> In the attachment you can find a small example of a state-machine we
>>> use for
>>> joint space control of our robots.
>>
>> Looking at the example, the following questions arise
>> - the CalibrateOffsetsProg stops itself apparently? This then ends
>> the
>> CalibrateOffsetsState state. This probably won't be clear to a new
>> user.
> The program stops itself. But to make the example more simple i
> removed it in
> the attached version
>
>> - the user has to manually set "stop" to get the MoveToState state to
>> end?
> Yes, because if the user likes he can issue new moveTo() commands
> using the
> taskbrowser while the statemachine is in this state.
IIRC (and I could be wrong here), moveTo() is a command and so you
can't interrupt the state machine during the move. This was what I was
trying to say below, and was the behaviour we couldn't live with.
>> - why the double call to nAxesGeneratorPos.moveTo() in MoveToState?
>> These are two different moves, right. The first to the zero-pose, and
>> the second to some other pose. Perhaps we should comment this if this
>> is going to be an example to new users?
> Or remove one :)
Having two maybe shows something to a new user also ... ?
>> On a slightly different note, I believe that the default
>> implementation of nAxesGeneratorPos.moveTo() is a command, and so the
>> moveTo()'s don't return until the move actually completes. Because
>> this is done in the entry() program of the state, it means that you
>> can not transition during the move(s). This prevents transitions
>> based
>> on say, user input or safety-related events, from changing states
>> using transitions within the state machine. We found this severly
>> limiting, and actually modified the implementation of
>> nAxesGeneratorPos (and the equivalent cartesian generator) to not use
>> commands and to issue an event upon move completion. This allows the
>> entry() program to complete and hence enables transitions again
>> within
>> the run/handle state (which can open up other possible issues, I
>> agree). What are people's thoughts on these two approaches?
>
> Does this behaviour changes if i but the moveTo command in the run
> program??
> Or is it still impossible to transition on events in this case?
> Because if so, this is IMO a big bug in the state machine handling
If I truly am recalling things correctly, this isn't a bug but a
feature of the implementation. As moveTo() is a command it is
synchronous, and hence won't "return" to the state machine processor
until the move completes. During this time, no event processing will
occur and hence no transitions. That is well defined behaviour, we
just felt it wasn't what we wanted and changed things. The flip side
of this, though, is that your double move in my 3rd question above,
isn't possible with the implementation we use. As the first move
"completes asynchronously" and then you rather quickly request a
second move while the first is still occurring. So the 2nd move
doesn't occur. Well ... there's always tradeoffs somewhere .... :-) A
fully featured implementation would probably provide both ways of
doing things - synchronous via command to allow sequencing of
(uninterruptible) moves, and asychronous via method with an event
emitted upon move completion.
S
Outdated example in Components builder manual?
On Tuesday 07 October 2008 13:52:54 S Roderick wrote:
> >>>>>v1 .6 .x /doc- xml/orocos-components-manual.html#id2641630>
> On Oct 7, 2008, at 02:50 , Ruben Smits wrote:
> > On Monday 06 October 2008 15:43:49 S Roderick wrote:
> >> On Oct 6, 2008, at 09:06 , Ruben Smits wrote:
> >>> On Monday 06 October 2008 14:58:48 Peter Soetens wrote:
> >>>> On Monday 06 October 2008 11:04:57 Ruben Smits wrote:
> >>>>> I was reading the chapter about statemachines in the Components
> >>>>> builder
> >>>>> manual and i think the example:
> >>>>>
> >>>>>
> >>>>> is very outdated, it is still working with the very old
> >>>>> KernelComponents.
> >>>>> Maybe it can be updated to a more recent type of application?
> >>>>
> >>>> Yep, it's dirty. Could you provide an example 'what it looks like'
> >>>> script ?
> >>>
> >>> In the attachment you can find a small example of a state-machine we
> >>> use for
> >>> joint space control of our robots.
> >>
> >> Looking at the example, the following questions arise
> >> - the CalibrateOffsetsProg stops itself apparently? This then ends
> >> the
> >> CalibrateOffsetsState state. This probably won't be clear to a new
> >> user.
> >
> > The program stops itself. But to make the example more simple i
> > removed it in
> > the attached version
> >
> >> - the user has to manually set "stop" to get the MoveToState state to
> >> end?
> >
> > Yes, because if the user likes he can issue new moveTo() commands
> > using the
> > taskbrowser while the statemachine is in this state.
>
> IIRC (and I could be wrong here), moveTo() is a command and so you
> can't interrupt the state machine during the move. This was what I was
> trying to say below, and was the behaviour we couldn't live with.
Have you tried the following syntax:
put this in your run program:
do comp.action(arg) until{
if comp.evaluate() then continue
}
This makes the statemachine go on if the command was called correctly
And then you can create a transition like this:
transition if comp.done() then select next_state
But this won't fix the two successive moveTo's i think.
> >> - why the double call to nAxesGeneratorPos.moveTo() in MoveToState?
> >> These are two different moves, right. The first to the zero-pose, and
> >> the second to some other pose. Perhaps we should comment this if this
> >> is going to be an example to new users?
> >
> > Or remove one :)
>
> Having two maybe shows something to a new user also ... ?
>
> >> On a slightly different note, I believe that the default
> >> implementation of nAxesGeneratorPos.moveTo() is a command, and so the
> >> moveTo()'s don't return until the move actually completes. Because
> >> this is done in the entry() program of the state, it means that you
> >> can not transition during the move(s). This prevents transitions
> >> based
> >> on say, user input or safety-related events, from changing states
> >> using transitions within the state machine. We found this severly
> >> limiting, and actually modified the implementation of
> >> nAxesGeneratorPos (and the equivalent cartesian generator) to not use
> >> commands and to issue an event upon move completion. This allows the
> >> entry() program to complete and hence enables transitions again
> >> within
> >> the run/handle state (which can open up other possible issues, I
> >> agree). What are people's thoughts on these two approaches?
> >
> > Does this behaviour changes if i but the moveTo command in the run
> > program??
> > Or is it still impossible to transition on events in this case?
> > Because if so, this is IMO a big bug in the state machine handling
>
> If I truly am recalling things correctly, this isn't a bug but a
> feature of the implementation. As moveTo() is a command it is
> synchronous, and hence won't "return" to the state machine processor
> until the move completes. During this time, no event processing will
> occur and hence no transitions. That is well defined behaviour, we
> just felt it wasn't what we wanted and changed things. The flip side
> of this, though, is that your double move in my 3rd question above,
> isn't possible with the implementation we use. As the first move
> "completes asynchronously" and then you rather quickly request a
> second move while the first is still occurring. So the 2nd move
> doesn't occur. Well ... there's always tradeoffs somewhere .... :-) A
> fully featured implementation would probably provide both ways of
> doing things - synchronous via command to allow sequencing of
> (uninterruptible) moves, and asychronous via method with an event
> emitted upon move completion.
I think you can get the exact same behaviour with only using the existing
moverTo-command. (Correct me if I'm wrong, i didn't actually tested it yet)
But i think with a smart combination of programs and statemachines we should
be able to fix this problems, using the current functionality of the RTT
scripting.
Ruben
Outdated example in Components builder manual?
On Tue, Oct 07, 2008 at 07:52:54AM -0400, S Roderick wrote:
...
> If I truly am recalling things correctly, this isn't a bug but a feature
> of the implementation. As moveTo() is a command it is synchronous, and
> hence won't "return" to the state machine processor until the move
Is this true? I was under the impression that commands are executed
asynchronously in the thread of the called TaskContext and would
therefore not block?
> completes. During this time, no event processing will occur and hence no
> transitions. That is well defined behaviour, we just felt it wasn't what
> we wanted and changed things. The flip side of this, though, is that your
> double move in my 3rd question above, isn't possible with the
> implementation we use. As the first move "completes asynchronously" and
> then you rather quickly request a second move while the first is still
> occurring. So the 2nd move doesn't occur. Well ... there's always
> tradeoffs somewhere .... :-) A fully featured implementation would
> probably provide both ways of doing things - synchronous via command to
> allow sequencing of (uninterruptible) moves, and asychronous via method
> with an event emitted upon move completion.
Aren't methods executed synchronously?
I'm surely missing something?
Best regards
Markus
Outdated example in Components builder manual?
On Tuesday 07 October 2008 14:42:52 Markus Klotzbücher wrote:
> On Tue, Oct 07, 2008 at 07:52:54AM -0400, S Roderick wrote:
> ...
>
> > If I truly am recalling things correctly, this isn't a bug but a feature
> > of the implementation. As moveTo() is a command it is synchronous, and
> > hence won't "return" to the state machine processor until the move
>
> Is this true? I was under the impression that commands are executed
> asynchronously in the thread of the called TaskContext and would
> therefore not block?
The TC nor state machine processor block. They 'wait' in a polling way. What
happens is that the execution of the next statement is delayed until the
command reports it is done. The 'current' command is polled in each 'step()'.
What Stephen meant with 'synchronous' is that the state machine does not
progress as long as the command has not completed (ie it is synchronising on
the command's completion). Of course, the command's function itself is
executed asynchronously in the other task.
When a command is put in the entry{} state, no transitions and no events are
processed when the SM is waiting. So indeed you can not interrupt it. The run
{} state does allow interruption of events. This allowed to have while(true)
loops in the run {} program for example.
>
> > completes. During this time, no event processing will occur and hence no
> > transitions. That is well defined behaviour, we just felt it wasn't what
> > we wanted and changed things. The flip side of this, though, is that your
> > double move in my 3rd question above, isn't possible with the
> > implementation we use. As the first move "completes asynchronously" and
> > then you rather quickly request a second move while the first is still
> > occurring. So the 2nd move doesn't occur. Well ... there's always
> > tradeoffs somewhere .... :-) A fully featured implementation would
> > probably provide both ways of doing things - synchronous via command to
> > allow sequencing of (uninterruptible) moves, and asychronous via method
> > with an event emitted upon move completion.
>
> Aren't methods executed synchronously?
Indeed, the method function is executed synhronously in the thread of the
caller. With respect to a move-to function, where you "don't wait for the
move to complete" you are de facto working asynchronously. It all depends on
the pov. If Stephen wanted a truely asynchronous function + asynchronous
calling, he would still use a moveTo command and write:
// does not wait for command's completion:
do nAxesGeneratorPos.moveTo() until { if true then continue; }
Thus it was technically not necessary to rewrite moveTo as a method, however
it removed the until {...} syntactic clutter.
Peter
Outdated example in Components builder manual?
Hi Peter,
On Wed, Oct 08, 2008 at 10:22:54AM +0200, Peter Soetens wrote:
> On Tuesday 07 October 2008 14:42:52 Markus Klotzbücher wrote:
> > On Tue, Oct 07, 2008 at 07:52:54AM -0400, S Roderick wrote:
> > ...
> >
> > > If I truly am recalling things correctly, this isn't a bug but a feature
> > > of the implementation. As moveTo() is a command it is synchronous, and
> > > hence won't "return" to the state machine processor until the move
> >
> > Is this true? I was under the impression that commands are executed
> > asynchronously in the thread of the called TaskContext and would
> > therefore not block?
>
> The TC nor state machine processor block. They 'wait' in a polling way. What
> happens is that the execution of the next statement is delayed until the
> command reports it is done. The 'current' command is polled in each 'step()'.
>
> What Stephen meant with 'synchronous' is that the state machine does not
> progress as long as the command has not completed (ie it is synchronising on
> the command's completion). Of course, the command's function itself is
> executed asynchronously in the other task.
>
> When a command is put in the entry{} state, no transitions and no events are
> processed when the SM is waiting. So indeed you can not interrupt it. The run
> {} state does allow interruption of events. This allowed to have while(true)
> loops in the run {} program for example.
Now I understand :-). Can you point me to where this is implemented? I
just can't find it (I looked in StateMachine.cpp,
StateMachineProcessor.cpp and got lost in FunctionGraph.cpp...
...
> > Aren't methods executed synchronously?
>
> Indeed, the method function is executed synhronously in the thread of the
> caller. With respect to a move-to function, where you "don't wait for the
> move to complete" you are de facto working asynchronously. It all depends on
> the pov. If Stephen wanted a truely asynchronous function + asynchronous
> calling, he would still use a moveTo command and write:
>
> // does not wait for command's completion:
> do nAxesGeneratorPos.moveTo() until { if true then continue; }
>
> Thus it was technically not necessary to rewrite moveTo as a method, however
> it removed the until {...} syntactic clutter.
Ah I see. Thanks for explaining.
Best regards
Markus
Outdated example in Components builder manual?
On Wednesday 08 October 2008 10:22:54 Peter Soetens wrote:
> On Tuesday 07 October 2008 14:42:52 Markus Klotzbücher wrote:
> > On Tue, Oct 07, 2008 at 07:52:54AM -0400, S Roderick wrote:
> > ...
> >
> > > If I truly am recalling things correctly, this isn't a bug but a
> > > feature of the implementation. As moveTo() is a command it is
> > > synchronous, and hence won't "return" to the state machine processor
> > > until the move
> >
> > Is this true? I was under the impression that commands are executed
> > asynchronously in the thread of the called TaskContext and would
> > therefore not block?
>
> The TC nor state machine processor block. They 'wait' in a polling way.
> What happens is that the execution of the next statement is delayed until
> the command reports it is done. The 'current' command is polled in each
> 'step()'.
>
> What Stephen meant with 'synchronous' is that the state machine does not
> progress as long as the command has not completed (ie it is synchronising
> on the command's completion). Of course, the command's function itself is
> executed asynchronously in the other task.
>
> When a command is put in the entry{} state, no transitions and no events
> are processed when the SM is waiting. So indeed you can not interrupt it.
> The run {} state does allow interruption of events. This allowed to have
> while(true) loops in the run {} program for example.
>
> > > completes. During this time, no event processing will occur and hence
> > > no transitions. That is well defined behaviour, we just felt it wasn't
> > > what we wanted and changed things. The flip side of this, though, is
> > > that your double move in my 3rd question above, isn't possible with the
> > > implementation we use. As the first move "completes asynchronously" and
> > > then you rather quickly request a second move while the first is still
> > > occurring. So the 2nd move doesn't occur. Well ... there's always
> > > tradeoffs somewhere .... :-) A fully featured implementation would
> > > probably provide both ways of doing things - synchronous via command to
> > > allow sequencing of (uninterruptible) moves, and asychronous via method
> > > with an event emitted upon move completion.
> >
> > Aren't methods executed synchronously?
>
> Indeed, the method function is executed synhronously in the thread of the
> caller. With respect to a move-to function, where you "don't wait for the
> move to complete" you are de facto working asynchronously. It all depends
> on the pov. If Stephen wanted a truely asynchronous function + asynchronous
> calling, he would still use a moveTo command and write:
>
> // does not wait for command's completion:
> do nAxesGeneratorPos.moveTo() until { if true then continue; }
>
> Thus it was technically not necessary to rewrite moveTo as a method,
> however it removed the until {...} syntactic clutter.
This is not entirely true since there is no way to detect the completion of
the command afterwards without adding an event to the nAxesGeneratorPos
Ruben
Outdated example in Components builder manual?
On Tuesday 07 October 2008 14:42:52 Markus Klotzbücher wrote:
> On Tue, Oct 07, 2008 at 07:52:54AM -0400, S Roderick wrote:
> ...
>
> > If I truly am recalling things correctly, this isn't a bug but a feature
> > of the implementation. As moveTo() is a command it is synchronous, and
> > hence won't "return" to the state machine processor until the move
>
> Is this true? I was under the impression that commands are executed
> asynchronously in the thread of the called TaskContext and would
> therefore not block?
But i think the statemachine has the nice "feature" to block on it.
> > completes. During this time, no event processing will occur and hence no
> > transitions. That is well defined behaviour, we just felt it wasn't what
> > we wanted and changed things. The flip side of this, though, is that your
> > double move in my 3rd question above, isn't possible with the
> > implementation we use. As the first move "completes asynchronously" and
> > then you rather quickly request a second move while the first is still
> > occurring. So the 2nd move doesn't occur. Well ... there's always
> > tradeoffs somewhere .... :-) A fully featured implementation would
> > probably provide both ways of doing things - synchronous via command to
> > allow sequencing of (uninterruptible) moves, and asychronous via method
> > with an event emitted upon move completion.
>
> Aren't methods executed synchronously?
>
> I'm surely missing something?
see:
xml/orocos-components-manual.html#program-syntax-specifics>
section 3.2.8:
[...]
If a completion list is left out, then an implicit one is generated. This
means that the two following statements are equivalent:
do comp.action( args )
// the implicitly generated completion list always looks like
// "if done then continue"
do comp.action( args ) until { if done then continue }
[...]
Since i didn't include a completion list the statemachine is waiting until the
command is done.
i think if i write this:
do nAxesGenerator.moveTo(pos,time) until {
if nAxesGenerator.evaluate() then continue
}
the statemachine will continue without waiting, except when something was
wrong in the arguments of the command
I don't know if this fixes the problem with the event-processing though.
Ruben
Outdated example in Components builder manual?
On Tuesday 07 October 2008 14:56:48 Ruben Smits wrote:
[...]
> see:
> xml/orocos-components-manual.html#program-syntax-specifics>
>
> section 3.2.8:
>
> [...]
> If a completion list is left out, then an implicit one is generated. This
> means that the two following statements are equivalent:
> do comp.action( args )
> // the implicitly generated completion list always looks like
> // "if done then continue"
> do comp.action( args ) until { if done then continue }
> [...]
>
> Since i didn't include a completion list the statemachine is waiting until
> the command is done.
>
> i think if i write this:
>
> do nAxesGenerator.moveTo(pos,time) until {
> if nAxesGenerator.evaluate() then continue
> }
I did some tests and these are my comments:
I tried the following according to the components builder manual:
try nAxesGeneratorPos.moveTo(pos,0.0) until{
if nAxesGeneratorPos.evaluate() then continue
}catch{}
but i get the following parsing error:
No method "evaluate" registered for the object or task
"DataCall::nAxesGeneratorPos"
I don't know if this is a bug in the documentation or the statemachine
functionality?
If i change it to the following:
try nAxesGeneratorPos.moveTo(pos,0.0) until{
if true then continue
}catch{}
i can do transitions based on conditions and events during the execution of
the command but since i am in automatic mode the run program is re-executed
every timestep until i transition out of the state.
i can get rid of this behaviour by putting the code in the entry program, this
gives me the exact behaviour i want if i could check when the command is done,
but the "done"-identifier doesn't work in a transition statement :(
then it looks like this:
entry {
do nAxesGeneratorPos.start()
do nAxesControllerPosVel.start()
set pos = array(6,0.0)
do nAxesGeneratorPos.moveTo(pos,10.0) until{if true then continue}
}
// transition if done then select StopRobotState
transition if(stop == true) then select StopRobotState
unfortunately the un-commented line does not work but maybe there is another
way to check the execution of a command in the scripting that i don't know.
If stop is set to true the transition is made also when the execution of the
command is not done yet.
To conclude: if the .evaluate() and done() statements would work you can
deside yourself in the statemachine if you want to wait or not for the
completion of the command.
Ruben
Outdated example in Components builder manual?
On Tue, Oct 07, 2008 at 04:58:47PM +0200, Ruben Smits wrote:
> > xml/orocos-components-manual.html#program-syntax-specifics>
> On Tuesday 07 October 2008 14:56:48 Ruben Smits wrote:
> [...]
>
> > see:
> >
> > section 3.2.8:
> >
> > [...]
> > If a completion list is left out, then an implicit one is generated. This
> > means that the two following statements are equivalent:
> > do comp.action( args )
> > // the implicitly generated completion list always looks like
> > // "if done then continue"
> > do comp.action( args ) until { if done then continue }
> > [...]
> >
> > Since i didn't include a completion list the statemachine is waiting until
> > the command is done.
Ah, I see. I somehow missed this. Thanks for pointing out.
> > i think if i write this:
> >
> > do nAxesGenerator.moveTo(pos,time) until {
> > if nAxesGenerator.evaluate() then continue
> > }
> I did some tests and these are my comments:
>
>
> I tried the following according to the components builder manual:
>
> try nAxesGeneratorPos.moveTo(pos,0.0) until{
> if nAxesGeneratorPos.evaluate() then continue
> }catch{}
>
> but i get the following parsing error:
> No method "evaluate" registered for the object or task
> "DataCall::nAxesGeneratorPos"
Where does this "evaluate" come from? The only place i can find this
in the docs is in that section (3.2.8. Invoking Task
Commands). Reading the archives I stumbled upon this:
http://thread.gmane.org/gmane.science.robotics.orocos.devel/2206
Maybe it's gone?
> I don't know if this is a bug in the documentation or the statemachine
> functionality?
>
> If i change it to the following:
>
> try nAxesGeneratorPos.moveTo(pos,0.0) until{
> if true then continue
> }catch{}
>
> i can do transitions based on conditions and events during the execution of
> the command but since i am in automatic mode the run program is re-executed
> every timestep until i transition out of the state.
Yes, this will change with the revised state machines...
> i can get rid of this behaviour by putting the code in the entry program, this
> gives me the exact behaviour i want if i could check when the command is done,
> but the "done"-identifier doesn't work in a transition statement :(
>
> then it looks like this:
>
> entry {
> do nAxesGeneratorPos.start()
> do nAxesControllerPosVel.start()
> set pos = array(6,0.0)
> do nAxesGeneratorPos.moveTo(pos,10.0) until{if true then continue}
> }
> // transition if done then select StopRobotState
> transition if(stop == true) then select StopRobotState
>
> unfortunately the un-commented line does not work but maybe there is another
> way to check the execution of a command in the scripting that i don't know.
Not sure why this is the case.
Regards
Markus
Outdated example in Components builder manual?
On Tuesday 07 October 2008 18:05:15 Markus Klotzbücher wrote:
> > > i think if i write this:
> > >
> > > do nAxesGenerator.moveTo(pos,time) until {
> > > if nAxesGenerator.evaluate() then continue
> > > }
> >
> > I did some tests and these are my comments:
> >
> >
> > I tried the following according to the components builder manual:
> >
> > try nAxesGeneratorPos.moveTo(pos,0.0) until{
> > if nAxesGeneratorPos.evaluate() then continue
> > }catch{}
> >
> > but i get the following parsing error:
> > No method "evaluate" registered for the object or task
> > "DataCall::nAxesGeneratorPos"
This is indeed wrong syntax. It should say 'if done then continue'. In
scripts, you can't use the command's name to evaluate its state. This is only
possible in C++...
>
> Where does this "evaluate" come from? The only place i can find this
> in the docs is in that section (3.2.8. Invoking Task
> Commands). Reading the archives I stumbled upon this:
>
> http://thread.gmane.org/gmane.science.robotics.orocos.devel/2206
>
> Maybe it's gone?
We renamed evaluate() to done() in C++ for clarity.
>
> > I don't know if this is a bug in the documentation or the statemachine
> > functionality?
> >
> > If i change it to the following:
> >
> > try nAxesGeneratorPos.moveTo(pos,0.0) until{
> > if true then continue
> > }catch{}
> >
> > i can do transitions based on conditions and events during the execution
> > of the command but since i am in automatic mode the run program is
> > re-executed every timestep until i transition out of the state.
>
> Yes, this will change with the revised state machines...
>
> > i can get rid of this behaviour by putting the code in the entry program,
> > this gives me the exact behaviour i want if i could check when the
> > command is done, but the "done"-identifier doesn't work in a transition
> > statement :(
> >
> > then it looks like this:
> >
> > entry {
> > do nAxesGeneratorPos.start()
> > do nAxesControllerPosVel.start()
> > set pos = array(6,0.0)
> > do nAxesGeneratorPos.moveTo(pos,10.0) until{if true then continue}
> > }
> > // transition if done then select StopRobotState
> > transition if(stop == true) then select StopRobotState
> >
> > unfortunately the un-commented line does not work but maybe there is
> > another way to check the execution of a command in the scripting that i
> > don't know.
'done' only has meaning in 'until' clauses and only reflects the current
command.
Peter
Outdated example in Components builder manual?
On Tue, 7 Oct 2008, S Roderick wrote:
> On Oct 7, 2008, at 02:50 , Ruben Smits wrote:
>>>>>> .6 .x /doc- xml/orocos-components-manual.html#id2641630>
>
>> On Monday 06 October 2008 15:43:49 S Roderick wrote:
>>> On Oct 6, 2008, at 09:06 , Ruben Smits wrote:
>>>> On Monday 06 October 2008 14:58:48 Peter Soetens wrote:
>>>>> On Monday 06 October 2008 11:04:57 Ruben Smits wrote:
>>>>>> I was reading the chapter about statemachines in the Components
>>>>>> builder
>>>>>> manual and i think the example:
>>>>>>
>>>>>>
>>>>>> is very outdated, it is still working with the very old
>>>>>> KernelComponents.
>>>>>> Maybe it can be updated to a more recent type of application?
>>>>>
>>>>> Yep, it's dirty. Could you provide an example 'what it looks like'
>>>>> script ?
>>>>
>>>> In the attachment you can find a small example of a state-machine we
>>>> use for
>>>> joint space control of our robots.
>>>
>>> Looking at the example, the following questions arise
>>> - the CalibrateOffsetsProg stops itself apparently? This then ends the
>>> CalibrateOffsetsState state. This probably won't be clear to a new user.
>> The program stops itself. But to make the example more simple i removed it
>> in
>> the attached version
>>
>>> - the user has to manually set "stop" to get the MoveToState state to
>>> end?
>> Yes, because if the user likes he can issue new moveTo() commands using the
>> taskbrowser while the statemachine is in this state.
>
> IIRC (and I could be wrong here), moveTo() is a command and so you can't
> interrupt the state machine during the move. This was what I was trying to
> say below, and was the behaviour we couldn't live with.
>
>>> - why the double call to nAxesGeneratorPos.moveTo() in MoveToState?
>>> These are two different moves, right. The first to the zero-pose, and
>>> the second to some other pose. Perhaps we should comment this if this
>>> is going to be an example to new users?
>> Or remove one :)
>
> Having two maybe shows something to a new user also ... ?
>
>>> On a slightly different note, I believe that the default
>>> implementation of nAxesGeneratorPos.moveTo() is a command, and so the
>>> moveTo()'s don't return until the move actually completes. Because
>>> this is done in the entry() program of the state, it means that you
>>> can not transition during the move(s). This prevents transitions based
>>> on say, user input or safety-related events, from changing states
>>> using transitions within the state machine. We found this severly
>>> limiting, and actually modified the implementation of
>>> nAxesGeneratorPos (and the equivalent cartesian generator) to not use
>>> commands and to issue an event upon move completion. This allows the
>>> entry() program to complete and hence enables transitions again within
>>> the run/handle state (which can open up other possible issues, I
>>> agree). What are people's thoughts on these two approaches?
>>
>> Does this behaviour changes if i but the moveTo command in the run
>> program??
>> Or is it still impossible to transition on events in this case?
>> Because if so, this is IMO a big bug in the state machine handling
>
> If I truly am recalling things correctly, this isn't a bug but a feature of
> the implementation. As moveTo() is a command it is synchronous, and hence
> won't "return" to the state machine processor until the move completes.
> During this time, no event processing will occur and hence no transitions.
> That is well defined behaviour, we just felt it wasn't what we wanted and
> changed things. The flip side of this, though, is that your double move in my
> 3rd question above, isn't possible with the implementation we use. As the
> first move "completes asynchronously" and then you rather quickly request a
> second move while the first is still occurring. So the 2nd move doesn't
> occur. Well ... there's always tradeoffs somewhere .... :-) A fully featured
> implementation would probably provide both ways of doing things - synchronous
> via command to allow sequencing of (uninterruptible) moves, and asychronous
> via method with an event emitted upon move completion.
Let me add my 2 cents to this discussion:
- I agree that moveTo()'s should be interruptible, at a certain level.
- a first, easy level is the level of the _controller_: the next setpoint
should be updatable immediately by another one, which remains "safe" for
the robot. So the controller's state machine must react to such an
interrupt event. (See below.)
- to interrupt an ongoing moveTo() requires the following functionalities
(that are not yet there, but I do not think it needs new infrastructure
development):
- the introduction of an explicit _trajectory generator_, that is, a
component that calculates a set of next setpoints, in the near future,
for the controller to execute;
- a 'soft interrupt' to a moveTo() should consist of having the
trajectory generator calculate a new trajectory, which is a smooth
continuation of what is already in the (short!) queue to the
controller, and which brings the motion to a fast stop that is still
"smooth enough".
(The latter quality feature, as well as the depth of the motion queue
between generator and controller are configurable properties.)
- a 'hard interrupt' is an event that both the generator and
the controller handle: the latter one stops the motors as quickly as
possible; the former makes sure he updates any motion requests that it
still has in order to be ready to restart from the position where the
controller stopped the robot.
So, I think our current state machine infrastructure can cope with this,
it's the _architecture_ of the Naxes that is not rich enough for the
semantics of the interrupted moveTo(). The additional semantics is not in
the kinematics, nor in the control, but in the (to be designed) trajectory
generator.
Fortunately, one of our PhD students, Diederik Verschuere, has already a
working prototype of this "advanced" Naxes design up and running. I guess
we will be able to add it in the coming weeks, after some critical scrutiny
of his code.
So, in summary:
- it would be much better if you tell us when and why you are not happy
with what Orocos provides at this moment;
- I prefer designs that solve the problem in the correct way, that is with
the right number of components and interconnected data ports, such that
the semantics of the design correspond completely to the semantics of
what the developer has in mind.
Herman
Outdated example in Components builder manual?
On Oct 7, 2008, at 08:06 , Herman Bruyninckx wrote:
> On Tue, 7 Oct 2008, S Roderick wrote:
>
>> On Oct 7, 2008, at 02:50 , Ruben Smits wrote:
>>
>>> On Monday 06 October 2008 15:43:49 S Roderick wrote:
>>>> On Oct 6, 2008, at 09:06 , Ruben Smits wrote:
>>>>> On Monday 06 October 2008 14:58:48 Peter Soetens wrote:
>>>>>> On Monday 06 October 2008 11:04:57 Ruben Smits wrote:
>>>>>>>
>>>> On a slightly different note, I believe that the default
>>>> implementation of nAxesGeneratorPos.moveTo() is a command, and so
>>>> the
>>>> moveTo()'s don't return until the move actually completes. Because
>>>> this is done in the entry() program of the state, it means that you
>>>> can not transition during the move(s). This prevents transitions
>>>> based
>>>> on say, user input or safety-related events, from changing states
>>>> using transitions within the state machine. We found this severly
>>>> limiting, and actually modified the implementation of
>>>> nAxesGeneratorPos (and the equivalent cartesian generator) to not
>>>> use
>>>> commands and to issue an event upon move completion. This allows
>>>> the
>>>> entry() program to complete and hence enables transitions again
>>>> within
>>>> the run/handle state (which can open up other possible issues, I
>>>> agree). What are people's thoughts on these two approaches?
>>> Does this behaviour changes if i but the moveTo command in the run
>>> program??
>>> Or is it still impossible to transition on events in this case?
>>> Because if so, this is IMO a big bug in the state machine handling
>>
>> If I truly am recalling things correctly, this isn't a bug but a
>> feature of the implementation. As moveTo() is a command it is
>> synchronous, and hence won't "return" to the state machine
>> processor until the move completes. During this time, no event
>> processing will occur and hence no transitions. That is well
>> defined behaviour, we just felt it wasn't what we wanted and
>> changed things. The flip side of this, though, is that your double
>> move in my 3rd question above, isn't possible with the
>> implementation we use. As the first move "completes asynchronously"
>> and then you rather quickly request a second move while the first
>> is still occurring. So the 2nd move doesn't occur. Well ... there's
>> always tradeoffs somewhere .... :-) A fully featured implementation
>> would probably provide both ways of doing things - synchronous via
>> command to allow sequencing of (uninterruptible) moves, and
>> asychronous via method with an event emitted upon move completion.
>
> Let me add my 2 cents to this discussion: - I agree that moveTo()'s
> should be interruptible, at a certain level.
> - a first, easy level is the level of the _controller_: the next
> setpoint
> should be updatable immediately by another one, which remains
> "safe" for
> the robot. So the controller's state machine must react to such an
> interrupt event. (See below.)
> - to interrupt an ongoing moveTo() requires the following
> functionalities
> (that are not yet there, but I do not think it needs new
> infrastructure
> development):
> - the introduction of an explicit _trajectory generator_, that is, a
> component that calculates a set of next setpoints, in the near
> future,
> for the controller to execute;
> - a 'soft interrupt' to a moveTo() should consist of having the
> trajectory generator calculate a new trajectory, which is a smooth
> continuation of what is already in the (short!) queue to the
> controller, and which brings the motion to a fast stop that is
> still
> "smooth enough".
> (The latter quality feature, as well as the depth of the motion
> queue
> between generator and controller are configurable properties.)
You are talking about a more advanced concept than we needed (see
below). I do like the sound of this though ...
> - a 'hard interrupt' is an event that both the generator and
> the controller handle: the latter one stops the motors as quickly as
> possible; the former makes sure he updates any motion requests
> that it
> still has in order to be ready to restart from the position where
> the
> controller stopped the robot.
I think this is the type of interrupt we implemented, except we don't
necessarily go to a motor-stop state. We can go to a position hold, or
change from joint space point-to-point to cartesian space point-to-
point, etc. Same thing though.
> So, I think our current state machine infrastructure can cope with
> this,
> it's the _architecture_ of the Naxes that is not rich enough for the
> semantics of the interrupted moveTo(). The additional semantics is
> not in
> the kinematics, nor in the control, but in the (to be designed)
> trajectory
> generator.
Agreed. _But_ I don't think we should replace the existing one, it is
a good small useful component, and is instructive for new users (and
useful to some of us ... with mod's).
> Fortunately, one of our PhD students, Diederik Verschuere, has
> already a
> working prototype of this "advanced" Naxes design up and running. I
> guess
> we will be able to add it in the coming weeks, after some critical
> scrutiny
> of his code.
Looking forward to seeing this ...
> So, in summary:
> - it would be much better if you tell us when and why you are not
> happy
> with what Orocos provides at this moment;
> - I prefer designs that solve the problem in the correct way, that
> is with
> the right number of components and interconnected data ports, such
> that
> the semantics of the design correspond completely to the semantics of
> what the developer has in mind.
Our implementation does satisfy the last, it satisfies us! :-) We
wanted a single point-to-point move that was interruptible by user
(think "stop" button in GUI), or by other components via events (eg
sensing some out of range problem). We changed moveTo() to a method,
added an event to the component, made the component emit the event
upon motion completion, and tied the event into the state machine. End
of story. Oh and we also added a "% complete" output so that the GUI
can tell the user how far through the move it is. A small but useful
detail for user-oriented control ...
My 2c
S
Outdated example in Components builder manual?
On Tue, 7 Oct 2008, S Roderick wrote:
> On Oct 7, 2008, at 08:06 , Herman Bruyninckx wrote:
>
>> On Tue, 7 Oct 2008, S Roderick wrote:
>>
>>> On Oct 7, 2008, at 02:50 , Ruben Smits wrote:
>>>
>>>> On Monday 06 October 2008 15:43:49 S Roderick wrote:
>>>>> On Oct 6, 2008, at 09:06 , Ruben Smits wrote:
>>>>>> On Monday 06 October 2008 14:58:48 Peter Soetens wrote:
>>>>>>> On Monday 06 October 2008 11:04:57 Ruben Smits wrote:
>>>>>>>>
>
>
>>>>> On a slightly different note, I believe that the default
>>>>> implementation of nAxesGeneratorPos.moveTo() is a command, and so the
>>>>> moveTo()'s don't return until the move actually completes. Because
>>>>> this is done in the entry() program of the state, it means that you
>>>>> can not transition during the move(s). This prevents transitions based
>>>>> on say, user input or safety-related events, from changing states
>>>>> using transitions within the state machine. We found this severly
>>>>> limiting, and actually modified the implementation of
>>>>> nAxesGeneratorPos (and the equivalent cartesian generator) to not use
>>>>> commands and to issue an event upon move completion. This allows the
>>>>> entry() program to complete and hence enables transitions again within
>>>>> the run/handle state (which can open up other possible issues, I
>>>>> agree). What are people's thoughts on these two approaches?
>>>> Does this behaviour changes if i but the moveTo command in the run
>>>> program??
>>>> Or is it still impossible to transition on events in this case?
>>>> Because if so, this is IMO a big bug in the state machine handling
>>>
>>> If I truly am recalling things correctly, this isn't a bug but a feature
>>> of the implementation. As moveTo() is a command it is synchronous, and
>>> hence won't "return" to the state machine processor until the move
>>> completes. During this time, no event processing will occur and hence no
>>> transitions. That is well defined behaviour, we just felt it wasn't what
>>> we wanted and changed things. The flip side of this, though, is that your
>>> double move in my 3rd question above, isn't possible with the
>>> implementation we use. As the first move "completes asynchronously" and
>>> then you rather quickly request a second move while the first is still
>>> occurring. So the 2nd move doesn't occur. Well ... there's always
>>> tradeoffs somewhere .... :-) A fully featured implementation would
>>> probably provide both ways of doing things - synchronous via command to
>>> allow sequencing of (uninterruptible) moves, and asychronous via method
>>> with an event emitted upon move completion.
>>
>> Let me add my 2 cents to this discussion: - I agree that moveTo()'s should
>> be interruptible, at a certain level.
>> - a first, easy level is the level of the _controller_: the next setpoint
>> should be updatable immediately by another one, which remains "safe" for
>> the robot. So the controller's state machine must react to such an
>> interrupt event. (See below.)
>> - to interrupt an ongoing moveTo() requires the following functionalities
>> (that are not yet there, but I do not think it needs new infrastructure
>> development):
>> - the introduction of an explicit _trajectory generator_, that is, a
>> component that calculates a set of next setpoints, in the near future,
>> for the controller to execute;
>> - a 'soft interrupt' to a moveTo() should consist of having the
>> trajectory generator calculate a new trajectory, which is a smooth
>> continuation of what is already in the (short!) queue to the
>> controller, and which brings the motion to a fast stop that is still
>> "smooth enough".
>> (The latter quality feature, as well as the depth of the motion queue
>> between generator and controller are configurable properties.)
>
> You are talking about a more advanced concept than we needed (see below). I
> do like the sound of this though ...
>
>> - a 'hard interrupt' is an event that both the generator and
>> the controller handle: the latter one stops the motors as quickly as
>> possible; the former makes sure he updates any motion requests that it
>> still has in order to be ready to restart from the position where the
>> controller stopped the robot.
>
> I think this is the type of interrupt we implemented, except we don't
> necessarily go to a motor-stop state. We can go to a position hold, or change
> from joint space point-to-point to cartesian space point-to-point, etc. Same
> thing though.
yes, it's just the (local!) policy of how the controller handles the 'hard
interrupt'. Making this policy configurable is certainly "nice to have".
>> So, I think our current state machine infrastructure can cope with this,
>> it's the _architecture_ of the Naxes that is not rich enough for the
>> semantics of the interrupted moveTo(). The additional semantics is not in
>> the kinematics, nor in the control, but in the (to be designed) trajectory
>> generator.
>
> Agreed. _But_ I don't think we should replace the existing one, it is a good
> small useful component, and is instructive for new users (and useful to some
> of us ... with mod's).
yes, simple introductory examples certainly have their legitimate place.
But one might add some comments about where there limits are, and where to
look for more powerful examples if one's application requires more than the
limited semantics of the simple examples.
After all, _the_ motivation behind Orocos was to make the most complex
applications possible. Which does not (at all) mean that even the simplest
application will necessarily have a complex Orocos solution! :-)
>> Fortunately, one of our PhD students, Diederik Verschuere, has already a
>> working prototype of this "advanced" Naxes design up and running. I guess
>> we will be able to add it in the coming weeks, after some critical scrutiny
>> of his code.
>
> Looking forward to seeing this ...
>
>> So, in summary:
>> - it would be much better if you tell us when and why you are not happy
>> with what Orocos provides at this moment;
>> - I prefer designs that solve the problem in the correct way, that is with
>> the right number of components and interconnected data ports, such that
>> the semantics of the design correspond completely to the semantics of
>> what the developer has in mind.
>
> Our implementation does satisfy the last, it satisfies us! :-) We wanted a
> single point-to-point move that was interruptible by user (think "stop"
> button in GUI), or by other components via events (eg sensing some out of
> range problem). We changed moveTo() to a method, added an event to the
> component, made the component emit the event upon motion completion, and tied
> the event into the state machine. End of story. Oh and we also added a "%
> complete" output so that the GUI can tell the user how far through the move
> it is. A small but useful detail for user-oriented control ...
Good!
Herman