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

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

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

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