For more infomation about this bug, visit
Summary: Unable to do self-transition in state machine
Product: RTT
Version: rtt-trunk
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Real-Time Toolkit (RTT)
AssignedTo: orocos-dev [..] ...
ReportedBy: kiwi [dot] net [..] ...
CC: orocos-dev [..] ...
Estimated Hours: 0.0
The following doesn't do the self transition, or is it that state machines
don't exit and then re-enter the state on a self-transition?
{{{
state JJ_POINT2POINT
{
entry
{
do nAxesGeneratorPos.start()
do Robot.requestPositionControl()
do nAxesGeneratorPos.moveTo(jjPoint2Point_pose,
jjPoint2Point_time)
}
exit
{
do nAxesGeneratorPos.stop()
}
transition requestSafe() select SAFE
// can run PTP's back to back
transition requestJJPoint2Point(
jjPoint2Point_pose, jjPoint2Point_time) select JJ_POINT2POINT
}
}}}
[Bug 543] Unable to do self-transition in state machine
For more infomation about this bug, visit
--- Comment #2 from Peter Soetens
<peter [dot] soetens [..] ...> 2008-05-09 23:43:15 ---
(In reply to comment #1)
> (In reply to comment #0)
> > The following doesn't do the self transition, or is it that state machines
> > don't exit and then re-enter the state on a self-transition?
>
> They don't, and it's documented as such. Still I wonder if UML/Standards-wise,
> it makes more sense to execute exit and entry upon a self transition. That's
> because a self transition otherwise doesn't do much, if it wasn't for executing
> the associated transition program, which might rely on the fact that exit and
> entry are not executed.
It seems UML-wise, exit and entry are executed upon 'recursive' (i.e. self)
transitions.
So Orocos is 'wrong'. I should have looked this up when I coded it...
Peter
[Bug 543] Unable to do self-transition in state machine
For more infomation about this bug, visit
Peter Soetens
<peter [dot] soetens [..] ...> changed:
What |Removed |Added
--------------------------------------------------------------------------
CC| |peter [dot] soetens [..] ...
--- Comment #1 from Peter Soetens
<peter [dot] soetens [..] ...> 2008-05-09 23:30:21 ---
(In reply to comment #0)
> The following doesn't do the self transition, or is it that state machines
> don't exit and then re-enter the state on a self-transition?
They don't, and it's documented as such. Still I wonder if UML/Standards-wise,
it makes more sense to execute exit and entry upon a self transition. That's
because a self transition otherwise doesn't do much, if it wasn't for executing
the associated transition program, which might rely on the fact that exit and
entry are not executed.
I've once had this discussion with another SW engineer, and their solution was
eventually to distinguish between both cases using a special notation.
In UML this can be easily solved by writing entry and exit programs in a parent
state and the self transition in a child state. As the child re-enters, the
parent's exit and entry programs remain untouched, and the child's transition
program is solely executed. In the other case, if the event transition is
notated on the parent, entry and exit are executed, together with the
transition program...
Any remarks ?
Peter
[Bug 543] Unable to do self-transition in state machine
> --- Comment #1 from Peter Soetens
<peter [dot] soetens [..] ...> > 2008-05-09 23:30:21 ---
> (In reply to comment #0)
>> The following doesn't do the self transition, or is it that state
>> machines
>> don't exit and then re-enter the state on a self-transition?
>
> They don't, and it's documented as such. Still I wonder if UML/
> Standards-wise,
I suspected as much, but where is it documented? I looked before
emailing the forum, and couldn't find it. I'd rather RTFM than bother
people ... :-(
> it makes more sense to execute exit and entry upon a self
> transition. That's
> because a self transition otherwise doesn't do much, if it wasn't
> for executing
> the associated transition program, which might rely on the fact that
> exit and
> entry are not executed.
>
> I've once had this discussion with another SW engineer, and their
> solution was
> eventually to distinguish between both cases using a special notation.
>
> In UML this can be easily solved by writing entry and exit programs
> in a parent
> state and the self transition in a child state. As the child re-
> enters, the
> parent's exit and entry programs remain untouched, and the child's
> transition
> program is solely executed. In the other case, if the event
> transition is
> notated on the parent, entry and exit are executed, together with the
> transition program...
I was contemplating something similar too.
For a robot it might just make sense to distinguish certain states as
essentially being transitions that do work (eg point to point moves)
and those that continue to do work (eg using streamed cartesian
poses). Essentially, Mealy vs Moore state diagrams. I'll probably just
make these point to point states automatically drop back to a position
hold state when they complete, bypassing this issue all together.
Thanks
S
[Bug 543] Unable to do self-transition in state machine
On Friday 09 May 2008 23:45:41 S Roderick wrote:
> > --- Comment #1 from Peter Soetens
<peter [dot] soetens [..] ...> > > 2008-05-09 23:30:21 ---
> > (In reply to comment #0)
> >
> >> The following doesn't do the self transition, or is it that state
> >> machines
> >> don't exit and then re-enter the state on a self-transition?
> >
> > They don't, and it's documented as such. Still I wonder if UML/
> > Standards-wise,
>
> I suspected as much, but where is it documented? I looked before
> emailing the forum, and couldn't find it. I'd rather RTFM than bother
> people ... :-(
Chapter 3. Orocos Scripting Reference, Section 4.4.4 in 'Defining State
Machines' in the component builder's manual
http://www.orocos.org/stable/documentation/rtt/v1.4.x/doc-xml/orocos-components-manual.html#id2679876
>
> > it makes more sense to execute exit and entry upon a self
> > transition. That's
> > because a self transition otherwise doesn't do much, if it wasn't
> > for executing
> > the associated transition program, which might rely on the fact that
> > exit and
> > entry are not executed.
> >
> > I've once had this discussion with another SW engineer, and their
> > solution was
> > eventually to distinguish between both cases using a special notation.
> >
> > In UML this can be easily solved by writing entry and exit programs
> > in a parent
> > state and the self transition in a child state. As the child re-
> > enters, the
> > parent's exit and entry programs remain untouched, and the child's
> > transition
> > program is solely executed. In the other case, if the event
> > transition is
> > notated on the parent, entry and exit are executed, together with the
> > transition program...
>
> I was contemplating something similar too.
>
> For a robot it might just make sense to distinguish certain states as
> essentially being transitions that do work (eg point to point moves)
> and those that continue to do work (eg using streamed cartesian
> poses). Essentially, Mealy vs Moore state diagrams. I'll probably just
> make these point to point states automatically drop back to a position
> hold state when they complete, bypassing this issue all together.
That's another way of controlling it. A serious shortcomming in the Orocos
design is that it is not so easy to define substates as is with 'drawn' state
machines. We can 'emulate it' with SubMachines, but I'm afraid this is
already to complex and hardly an attractive solution...
Peter