Dear List,
I'm a student working on a project with the goal of refactoring the
OROCOS state machines in order to bring them more in line with the
well know semantics of UML2 and its relevant profiles.
Up to now I have put together
- a list of deviations between OROCOS and UML2 state machines
- a list of semantic variation points in UML2 which are relevant
for state machines.
which can be found here[1]. Of course this is work in progress.
It turned out quickly that "blindly" implementing the UML2
specification in OROCOS will not work: firstly it must be investigated
which parts of the UML2 state machines actually would be (practically)
useful for the robotics domain. Secondly, for each semantic variation
point left open in the standard a subset of relevant, valid and robust
implementations must be identified.
As I'm currently investigating above points, I would be very
interested to hear about previous experience with (OROCOS) state
machines in robotic software architectures, e.g.
* which OROCOS execution modes are used (automatic vs. reactive) ?
* which feature(s) of the current OROCOS state machine
implementation are most useful and why?
* which unavailable UML2 state machine feature is most lacking in
the current implementation and why?
* are there any state machine features outside of the scope of UML2
that could be useful?
Thanks in advance for any feedback.
Best regards
Markus Klotzbücher
[1] http://people.mech.kuleuven.be/~s0202242/
Project: OROCOS State Machines and UML2
On Tuesday 23 September 2008 10:15:06 Markus Klotzbücher wrote:
> Dear List,
>
> I'm a student working on a project with the goal of refactoring the
> OROCOS state machines in order to bring them more in line with the
> well know semantics of UML2 and its relevant profiles.
>
> Up to now I have put together
>
> - a list of deviations between OROCOS and UML2 state machines
>
> - a list of semantic variation points in UML2 which are relevant
> for state machines.
>
> which can be found here[1]. Of course this is work in progress.
>
> It turned out quickly that "blindly" implementing the UML2
> specification in OROCOS will not work: firstly it must be investigated
> which parts of the UML2 state machines actually would be (practically)
> useful for the robotics domain. Secondly, for each semantic variation
> point left open in the standard a subset of relevant, valid and robust
> implementations must be identified.
I agree. However, take note that lots of features in the Orocos SM were
implemented blindly, just for 'seeing if this could work', not as a proven
solution. So keep that in mind when looking at the code.
>
> As I'm currently investigating above points, I would be very
> interested to hear about previous experience with (OROCOS) state
> machines in robotic software architectures, e.g.
>
> * which OROCOS execution modes are used (automatic vs. reactive) ?
I believe[*] the automatic mode is used most. I don't consider having these
two modes as an advantage. It just make matters more complex. Once it was
proposed to make the SM mode equivalent to the TaskContext execution modes,
having a configureHook() etc. It would be nice if this could be unified such
that something written in a script could equivalently be written in the C++
*Hook() functions and vice versa.
>
> * which feature(s) of the current OROCOS state machine
> implementation are most useful and why?
What people certainly need is both 'condition' and 'event based' transition
evaluation + transition programs, entry and exit programs and (an equivalent
of) the run program. On the other side of the balance, I wonder if we need
the handle program, separate intial/final states with the complex
activate/start/stop/reset/deactivate protocol (it only looked nice in theory)
>
> * which unavailable UML2 state machine feature is most lacking in
> the current implementation and why?
True hierarchical state machines (defining substates in a state, AND and OR
states) and possibly history support.
>
> * are there any state machine features outside of the scope of UML2
> that could be useful?
There must be 'some' protocol to start/stop/pause etc a state machine's
execution. However, maybe most of this could be managed at the component's
level, with the 'disadvantage' that you loose granularity.
Peter
[*] I am not Joe average user so take my comments as the low priority ones...
> Thanks in advance for any feedback.
>
> Best regards
> Markus Klotzbücher
>
> [1] http://people.mech.kuleuven.be/~s0202242/
Project: OROCOS State Machines and UML2
On Sep 29, 2008, at 11:22 , Peter Soetens wrote:
> On Tuesday 23 September 2008 10:15:06 Markus Klotzbücher wrote:
>> Dear List,
>> As I'm currently investigating above points, I would be very
>> interested to hear about previous experience with (OROCOS) state
>> machines in robotic software architectures, e.g.
>>
>> * which OROCOS execution modes are used (automatic vs. reactive) ?
>
> I believe[*] the automatic mode is used most. I don't consider
> having these
> two modes as an advantage. It just make matters more complex. Once
> it was
> proposed to make the SM mode equivalent to the TaskContext execution
> modes,
> having a configureHook() etc. It would be nice if this could be
> unified such
> that something written in a script could equivalently be written in
> the C++
> *Hook() functions and vice versa.
The difference between automatic and reactive mode is _very_ unclear
to me. None of the documentation resolves this for me. All of our C++
state machines are in automatic mode. One of our state machine scripts
calls into C++ code in what might be more of a "reactive" manner, but
it's hard to say. And when recently looking at that reactive SM, I
realised it could be reformulated into an automatic C++ SM. So I would
say "automatic only".
>> * which feature(s) of the current OROCOS state machine
>> implementation are most useful and why?
>
> What people certainly need is both 'condition' and 'event based'
> transition
> evaluation + transition programs, entry and exit programs and (an
> equivalent
> of) the run program. On the other side of the balance, I wonder if
> we need
> the handle program, separate intial/final states with the complex
> activate/start/stop/reset/deactivate protocol (it only looked nice
> in theory)
Agreed on people's requirements. We don't use the handle program at
all (IIRC). Also, the separate initial state is mostly useless as it
is best kept empty anyway, to allow an atomic first transition
(IIRC ... Peter?). The final state does come in useful some times to
ensure a critical shutdown activity occurs.
Definitely need global transitions, which Peter kindly added a couple
of months ago. You could almost rephrase these as transitions between
nested states though, which plays into the hierarchical SM question.
>> * which unavailable UML2 state machine feature is most lacking in
>> the current implementation and why?
>
> True hierarchical state machines (defining substates in a state, AND
> and OR
> states) and possibly history support.
Yes on hierarchical, though we've (currently) no use for history.
>> * are there any state machine features outside of the scope of UML2
>> that could be useful?
>
> There must be 'some' protocol to start/stop/pause etc a state
> machine's
> execution. However, maybe most of this could be managed at the
> component's
> level, with the 'disadvantage' that you loose granularity.
Agreed. This facility is also very useful in automated unit tests.
> [*] I am not Joe average user so take my comments as the low
> priority ones...
I probably am a "Joe Average User" so take my comments any way you
like ... ;-)
Cheers
S
Project: OROCOS State Machines and UML2
Hi Peter,
Thank you for commenting!
On Mon, Sep 29, 2008 at 05:22:32PM +0200, Peter Soetens wrote:
> On Tuesday 23 September 2008 10:15:06 Markus Klotzbücher wrote:
...
> > It turned out quickly that "blindly" implementing the UML2
> > specification in OROCOS will not work: firstly it must be investigated
> > which parts of the UML2 state machines actually would be (practically)
> > useful for the robotics domain. Secondly, for each semantic variation
> > point left open in the standard a subset of relevant, valid and robust
> > implementations must be identified.
>
> I agree. However, take note that lots of features in the Orocos SM were
> implemented blindly, just for 'seeing if this could work', not as a proven
> solution. So keep that in mind when looking at the code.
Ok.
> > As I'm currently investigating above points, I would be very
> > interested to hear about previous experience with (OROCOS) state
> > machines in robotic software architectures, e.g.
> >
> > * which OROCOS execution modes are used (automatic vs. reactive) ?
>
> I believe[*] the automatic mode is used most. I don't consider having these
> two modes as an advantage. It just make matters more complex. Once it was
Ok.
> proposed to make the SM mode equivalent to the TaskContext execution modes,
> having a configureHook() etc. It would be nice if this could be unified such
> that something written in a script could equivalently be written in the C++
> *Hook() functions and vice versa.
I'm not quite sure I understand this. You mean a state machine should
itself have states such as preoperational, running, stopped and
respective hooks?
> > * which feature(s) of the current OROCOS state machine
> > implementation are most useful and why?
>
> What people certainly need is both 'condition' and 'event based' transition
> evaluation + transition programs, entry and exit programs and (an equivalent
> of) the run program. On the other side of the balance, I wonder if we need
Yes, I agree.
> the handle program, separate intial/final states with the complex
> activate/start/stop/reset/deactivate protocol (it only looked nice in theory)
Agreed, though I think inital and final states are useful for making a
state machine (at least graphically) more concise (especially when it
comes to composite states).
> > * which unavailable UML2 state machine feature is most lacking in
> > the current implementation and why?
>
> True hierarchical state machines (defining substates in a state, AND and OR
> states) and possibly history support.
Yes agreed!
> > * are there any state machine features outside of the scope of UML2
> > that could be useful?
>
> There must be 'some' protocol to start/stop/pause etc a state machine's
> execution. However, maybe most of this could be managed at the component's
> level, with the 'disadvantage' that you loose granularity.
Hmm, naive comment without knowing the internals: wouldn't it make
sense the other way round, namely that a components default behaviour
is itself an instance of a state machine, that could possibly be
replaced by a different one if required? This would be mechanism
vs. policy...
Thanks Peter!
Best regards
Markus
Project: OROCOS State Machines and UML2
On Mon, 29 Sep 2008, Peter Soetens wrote:
> On Tuesday 23 September 2008 10:15:06 Markus Klotzbücher wrote:
[...]
>> As I'm currently investigating above points, I would be very
>> interested to hear about previous experience with (OROCOS) state
>> machines in robotic software architectures, e.g.
>>
>> * which OROCOS execution modes are used (automatic vs. reactive) ?
>
> I believe[*] the automatic mode is used most. I don't consider having these
> two modes as an advantage. It just make matters more complex. Once it was
> proposed to make the SM mode equivalent to the TaskContext execution modes,
> having a configureHook() etc. It would be nice if this could be unified such
> that something written in a script could equivalently be written in the C++
> *Hook() functions and vice versa.
The only time I personally used a *scripting* state machine for a real problem (apart from playing/fooling around) was in reactive mode.
[...]
>> * which unavailable UML2 state machine feature is most lacking in
>> the current implementation and why?
I have encountered situations in which I had to implement a statemachine in C++ in the update() step of the taskcontext instead of in the scripting language, due to the absence of "time events" (after 3 seconds, switch to state b).
Best regards,
Joe average user.
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Project: OROCOS State Machines and UML2
On Sep 30, 2008, at 05:08 , Klaas Gadeyne wrote:
> On Mon, 29 Sep 2008, Peter Soetens wrote:
>> On Tuesday 23 September 2008 10:15:06 Markus Klotzbücher wrote:
> [...]
>>> As I'm currently investigating above points, I would be very
>>> interested to hear about previous experience with (OROCOS) state
>>> machines in robotic software architectures, e.g.
>>>
>>> * which OROCOS execution modes are used (automatic vs. reactive) ?
>>
>> I believe[*] the automatic mode is used most. I don't consider
>> having these
>> two modes as an advantage. It just make matters more complex. Once
>> it was
>> proposed to make the SM mode equivalent to the TaskContext
>> execution modes,
>> having a configureHook() etc. It would be nice if this could be
>> unified such
>> that something written in a script could equivalently be written in
>> the C++
>> *Hook() functions and vice versa.
>
> The only time I personally used a *scripting* state machine for a
> real problem (apart from playing/fooling around) was in reactive mode.
We use scripting machines all over the place, I would say about half
of our components, and as I mentioned in my other email they're all in
automatic mode.
> [...]
>>> * which unavailable UML2 state machine feature is most lacking in
>>> the current implementation and why?
>
> I have encountered situations in which I had to implement a
> statemachine in C++ in the update() step of the taskcontext instead
> of in the scripting language, due to the absence of "time
> events" (after 3 seconds, switch to state b).
This would be very useful.
Another Joe Average User
Project: OROCOS State Machines and UML2
On Tue, Sep 30, 2008 at 11:08:54AM +0200, Klaas Gadeyne wrote:
> On Mon, 29 Sep 2008, Peter Soetens wrote:
>> On Tuesday 23 September 2008 10:15:06 Markus Klotzbücher wrote:
> [...]
>>> As I'm currently investigating above points, I would be very
>>> interested to hear about previous experience with (OROCOS) state
>>> machines in robotic software architectures, e.g.
>>>
>>> * which OROCOS execution modes are used (automatic vs. reactive) ?
>>
>> I believe[*] the automatic mode is used most. I don't consider having these
>> two modes as an advantage. It just make matters more complex. Once it was
>> proposed to make the SM mode equivalent to the TaskContext execution modes,
>> having a configureHook() etc. It would be nice if this could be unified such
>> that something written in a script could equivalently be written in the C++
>> *Hook() functions and vice versa.
>
> The only time I personally used a *scripting* state machine for a
> real problem (apart from playing/fooling around) was in reactive
> mode.
Ok, but probably because you just wanted to react to events and didn't
care about any conditions causing transitions? If so, the automatic
mode wouldn't have done any harm, it would have simply provided a
feature you didn't have use for.
> [...]
>>> * which unavailable UML2 state machine feature is most lacking in
>>> the current implementation and why?
>
> I have encountered situations in which I had to implement a
> statemachine in C++ in the update() step of the taskcontext instead
> of in the scripting language, due to the absence of "time events"
> (after 3 seconds, switch to state b).
Ok, this is definitely a feature we need...
> Joe average user.
;-)
Best regards
Markus
Project: OROCOS State Machines and UML2
On Tue, 30 Sep 2008, Markus Klotzbücher wrote:
> On Tue, Sep 30, 2008 at 11:08:54AM +0200, Klaas Gadeyne wrote:
>> On Mon, 29 Sep 2008, Peter Soetens wrote:
>>> On Tuesday 23 September 2008 10:15:06 Markus Klotzbücher wrote:
>> [...]
>>>> As I'm currently investigating above points, I would be very
>>>> interested to hear about previous experience with (OROCOS) state
>>>> machines in robotic software architectures, e.g.
>>>>
>>>> * which OROCOS execution modes are used (automatic vs. reactive) ?
>>>
>>> I believe[*] the automatic mode is used most. I don't consider having these
>>> two modes as an advantage. It just make matters more complex. Once it was
>>> proposed to make the SM mode equivalent to the TaskContext execution modes,
>>> having a configureHook() etc. It would be nice if this could be unified such
>>> that something written in a script could equivalently be written in the C++
>>> *Hook() functions and vice versa.
>>
>> The only time I personally used a *scripting* state machine for a
>> real problem (apart from playing/fooling around) was in reactive
>> mode.
>
> Ok, but probably because you just wanted to react to events and didn't
> care about any conditions causing transitions? If so, the automatic
> mode wouldn't have done any harm, it would have simply provided a
> feature you didn't have use for.
Indeed.
Just as S. reported, I also recall having to study the docs 2 weeks or more before (somewhat) understanding the difference between those too, so I'm in favour of throwing one mode away (and don't give a name to the remaining one).
One other thing I do recall from playing around with the scripting state machines and which hasn't been mentioned yet in this thread, is the fact that debugging them can be a real PITA. Maybe simulation could solve some of this and could be a most useful feature.
Klaas
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Project: OROCOS State Machines and UML2
On Tuesday 30 September 2008 11:08:54 Klaas Gadeyne wrote:
> On Mon, 29 Sep 2008, Peter Soetens wrote:
> > On Tuesday 23 September 2008 10:15:06 Markus Klotzbücher wrote:
>
> [...]
>
> >> As I'm currently investigating above points, I would be very
> >> interested to hear about previous experience with (OROCOS) state
> >> machines in robotic software architectures, e.g.
> >>
> >> * which OROCOS execution modes are used (automatic vs. reactive) ?
> >
> > I believe[*] the automatic mode is used most. I don't consider having
> > these two modes as an advantage. It just make matters more complex. Once
> > it was proposed to make the SM mode equivalent to the TaskContext
> > execution modes, having a configureHook() etc. It would be nice if this
> > could be unified such that something written in a script could
> > equivalently be written in the C++ *Hook() functions and vice versa.
>
> The only time I personally used a *scripting* state machine for a real
> problem (apart from playing/fooling around) was in reactive mode.
I always use the automatic mode for all my applications. But maybe that's
because I'm not familiar with the benefits of the reactive mode :)
> [...]
>
> >> * which unavailable UML2 state machine feature is most lacking in
> >> the current implementation and why?
>
> I have encountered situations in which I had to implement a statemachine in
> C++ in the update() step of the taskcontext instead of in the scripting
> language, due to the absence of "time events" (after 3 seconds, switch to
> state b).
I miss these time events too, but if I'm not mistaken, one can use the
TimerComponent for these kinds of things now.
Ruben
Project: OROCOS State Machines and UML2
Hi Ruben,
On Tue, Sep 30, 2008 at 11:51:41AM +0200, Ruben Smits wrote:
> On Tuesday 30 September 2008 11:08:54 Klaas Gadeyne wrote:
> > On Mon, 29 Sep 2008, Peter Soetens wrote:
> > > On Tuesday 23 September 2008 10:15:06 Markus Klotzbücher wrote:
> >
> > [...]
> >
> > >> As I'm currently investigating above points, I would be very
> > >> interested to hear about previous experience with (OROCOS) state
> > >> machines in robotic software architectures, e.g.
> > >>
> > >> * which OROCOS execution modes are used (automatic vs. reactive) ?
> > >
> > > I believe[*] the automatic mode is used most. I don't consider having
> > > these two modes as an advantage. It just make matters more complex. Once
> > > it was proposed to make the SM mode equivalent to the TaskContext
> > > execution modes, having a configureHook() etc. It would be nice if this
> > > could be unified such that something written in a script could
> > > equivalently be written in the C++ *Hook() functions and vice versa.
> >
> > The only time I personally used a *scripting* state machine for a real
> > problem (apart from playing/fooling around) was in reactive mode.
>
> I always use the automatic mode for all my applications. But maybe that's
> because I'm not familiar with the benefits of the reactive mode :)
As Peter mentioned I don't think there is any real benefit, it just
allows you to transitions only on events opposed to events and
conditions. So if you use automatic mode and don't use Conditions you
basically end up in reactive mode.
Best regards
Markus
Project: OROCOS State Machines and UML2
On Tue, 30 Sep 2008, Ruben Smits wrote:
> On Tuesday 30 September 2008 11:08:54 Klaas Gadeyne wrote:
>> On Mon, 29 Sep 2008, Peter Soetens wrote:
>>> On Tuesday 23 September 2008 10:15:06 Markus Klotzbücher wrote:
>> [...]
>>>> As I'm currently investigating above points, I would be very
>>>> interested to hear about previous experience with (OROCOS) state
>>>> machines in robotic software architectures, e.g.
>>>>
>>>> * which OROCOS execution modes are used (automatic vs. reactive) ?
>>>
>>> I believe[*] the automatic mode is used most. I don't consider having
>>> these two modes as an advantage. It just make matters more complex. Once
>>> it was proposed to make the SM mode equivalent to the TaskContext
>>> execution modes, having a configureHook() etc. It would be nice if this
>>> could be unified such that something written in a script could
>>> equivalently be written in the C++ *Hook() functions and vice versa.
>>
>> The only time I personally used a *scripting* state machine for a real
>> problem (apart from playing/fooling around) was in reactive mode.
>
> I always use the automatic mode for all my applications. But maybe that's
> because I'm not familiar with the benefits of the reactive mode :)
What I get from these answers is that the "best practices" about both modes
should be made explicit, and be discussed in more detail...
>> [...]
>>>> * which unavailable UML2 state machine feature is most lacking in
>>>> the current implementation and why?
>>
>> I have encountered situations in which I had to implement a statemachine in
>> C++ in the update() step of the taskcontext instead of in the scripting
>> language, due to the absence of "time events" (after 3 seconds, switch to
>> state b).
>
> I miss these time events too, but if I'm not mistaken, one can use the
> TimerComponent for these kinds of things now.
I also think that Orocos components should only deal with time via
TimerComponent events, in order to facilitate (guarantee?) independence
from the (OS, hardware) platform.
Herman
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Project: OROCOS State Machines and UML2
On Tue, Sep 30, 2008 at 11:51 AM, Ruben Smits
<ruben [dot] smits [..] ...> wrote:
> On Tuesday 30 September 2008 11:08:54 Klaas Gadeyne wrote:
>> On Mon, 29 Sep 2008, Peter Soetens wrote:
>> > On Tuesday 23 September 2008 10:15:06 Markus Klotzbücher wrote:
>> [...]
>>
>> >> * which unavailable UML2 state machine feature is most lacking in
>> >> the current implementation and why?
>>
>> I have encountered situations in which I had to implement a statemachine in
>> C++ in the update() step of the taskcontext instead of in the scripting
>> language, due to the absence of "time events" (after 3 seconds, switch to
>> state b).
>
> I miss these time events too, but if I'm not mistaken, one can use the
> TimerComponent for these kinds of things now.
Indeed (at that time the timerComponent did not exist yet), but we're
not yet at a point where we can write something like
after (300 ms)
in the OSD file. [*]
[*] which might remain impossible, since the scripting language is
defined in RTT, whereas the timercomponent belongs to OCL.
Klaas
Project: OROCOS State Machines and UML2
On Tue, 30 Sep 2008, Klaas Gadeyne wrote:
> On Tue, Sep 30, 2008 at 11:51 AM, Ruben Smits
> <ruben [dot] smits [..] ...> wrote:
>> On Tuesday 30 September 2008 11:08:54 Klaas Gadeyne wrote:
>>> On Mon, 29 Sep 2008, Peter Soetens wrote:
>>>> On Tuesday 23 September 2008 10:15:06 Markus Klotzbücher wrote:
>>> [...]
>>>
>>>>> * which unavailable UML2 state machine feature is most lacking in
>>>>> the current implementation and why?
>>>
>>> I have encountered situations in which I had to implement a statemachine in
>>> C++ in the update() step of the taskcontext instead of in the scripting
>>> language, due to the absence of "time events" (after 3 seconds, switch to
>>> state b).
>>
>> I miss these time events too, but if I'm not mistaken, one can use the
>> TimerComponent for these kinds of things now.
>
> Indeed (at that time the timerComponent did not exist yet), but we're
> not yet at a point where we can write something like
>
> after (300 ms)
>
> in the OSD file. [*]
Are there fudamental issues to be solved in order to reach this goal, or is
it "just" a matter of finding the implementation efforts?
>
> [*] which might remain impossible, since the scripting language is
> defined in RTT, whereas the timercomponent belongs to OCL.
>
Isn't that a fundamental mistake...? Or is it indeed better to put a timer
_component_ into OCL, but a time _API_ into the RTT...?
Herman
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Project: OROCOS State Machines and UML2
On Tuesday 30 September 2008 12:18:44 Herman Bruyninckx wrote:
> On Tue, 30 Sep 2008, Klaas Gadeyne wrote:
> > On Tue, Sep 30, 2008 at 11:51 AM, Ruben Smits
> >
> > <ruben [dot] smits [..] ...> wrote:
> >>
> >> I miss these time events too, but if I'm not mistaken, one can use the
> >> TimerComponent for these kinds of things now.
> >
> > Indeed (at that time the timerComponent did not exist yet), but we're
> > not yet at a point where we can write something like
> >
> > after (300 ms)
> >
> > in the OSD file. [*]
>
> Are there fudamental issues to be solved in order to reach this goal, or is
> it "just" a matter of finding the implementation efforts?
Ok, before everyone starts phantasising about the implementation. There is
definately a timer API in RTT in the (admit you didn't look it
up!) 'RTT::Timer' class. It contains all functionality of the TimerComponent,
except that the TimerComponent is a TaskContext, while the Timer class is
just a plain class, managing timers and timeouts.
Scripting could use this to register a timer and implement the after(300ms)
function.
>
> > [*] which might remain impossible, since the scripting language is
> > defined in RTT, whereas the timercomponent belongs to OCL.
>
> Isn't that a fundamental mistake...? Or is it indeed better to put a timer
> _component_ into OCL, but a time _API_ into the RTT...?
That's indeed the plan/reality.
Peter
Project: OROCOS State Machines and UML2
On Tue, 30 Sep 2008, Peter Soetens wrote:
> On Tuesday 30 September 2008 12:18:44 Herman Bruyninckx wrote:
>> On Tue, 30 Sep 2008, Klaas Gadeyne wrote:
>>> On Tue, Sep 30, 2008 at 11:51 AM, Ruben Smits
>>>
>>> <ruben [dot] smits [..] ...> wrote:
>>>>
>>>> I miss these time events too, but if I'm not mistaken, one can use the
>>>> TimerComponent for these kinds of things now.
>>>
>>> Indeed (at that time the timerComponent did not exist yet), but we're
>>> not yet at a point where we can write something like
>>>
>>> after (300 ms)
>>>
>>> in the OSD file. [*]
>>
>> Are there fudamental issues to be solved in order to reach this goal, or is
>> it "just" a matter of finding the implementation efforts?
>
> Ok, before everyone starts phantasising about the implementation. There is
> definately a timer API in RTT in the (admit you didn't look it
> up!)
I admit!!!
> 'RTT::Timer' class. It contains all functionality of the TimerComponent,
> except that the TimerComponent is a TaskContext, while the Timer class is
> just a plain class, managing timers and timeouts.
>
> Scripting could use this to register a timer and implement the after(300ms)
> function.
Ok, so, the problem with timeouts in Orocos state machines is solved?
>>> [*] which might remain impossible, since the scripting language is
>>> defined in RTT, whereas the timercomponent belongs to OCL.
>>
>> Isn't that a fundamental mistake...? Or is it indeed better to put a timer
>> _component_ into OCL, but a time _API_ into the RTT...?
>
> That's indeed the plan/reality.
Fine!
Herman
Project: OROCOS State Machines and UML2
On Tue, 30 Sep 2008, Herman Bruyninckx wrote:
> On Tue, 30 Sep 2008, Klaas Gadeyne wrote:
>
>> On Tue, Sep 30, 2008 at 11:51 AM, Ruben Smits
>> <ruben [dot] smits [..] ...> wrote:
>>> On Tuesday 30 September 2008 11:08:54 Klaas Gadeyne wrote:
>>>> On Mon, 29 Sep 2008, Peter Soetens wrote:
>>>>> On Tuesday 23 September 2008 10:15:06 Markus Klotzbücher wrote:
>>>> [...]
>>>>
>>>>>> * which unavailable UML2 state machine feature is most lacking in
>>>>>> the current implementation and why?
>>>>
>>>> I have encountered situations in which I had to implement a statemachine
>>>> in
>>>> C++ in the update() step of the taskcontext instead of in the scripting
>>>> language, due to the absence of "time events" (after 3 seconds, switch to
>>>> state b).
>>>
>>> I miss these time events too, but if I'm not mistaken, one can use the
>>> TimerComponent for these kinds of things now.
>>
>> Indeed (at that time the timerComponent did not exist yet), but we're
>> not yet at a point where we can write something like
>>
>> after (300 ms)
>>
>> in the OSD file. [*]
> Are there fudamental issues to be solved in order to reach this goal, or is
> it "just" a matter of finding the implementation efforts?
See below.
>> [*] which might remain impossible, since the scripting language is
>> defined in RTT, whereas the timercomponent belongs to OCL.
>>
> Isn't that a fundamental mistake...? Or is it indeed better to put a timer
> _component_ into OCL, but a time _API_ into the RTT...?
That won't solve the problem (I think). You can add the appropriate syntax into the scripting language, but you will have to setup the TimerComponent in order to implement it (ie. subscribe to Event(s) from the TimerComponent), hence you will need the API of a component which is not in RTT.
>From the top of my head [*], I see 2 "solutions" to this:
-> Put the TimerComponent in RTT anyway
-> Let the TimeService infrastructure from RTT handle this instead of using a dedicated component (the TimerComponent uses this) for this.
Klaas
[*] So there will probably be more or less :-)
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Project: OROCOS State Machines and UML2
On Tue, 30 Sep 2008, Klaas Gadeyne wrote:
> On Tue, 30 Sep 2008, Herman Bruyninckx wrote:
>> On Tue, 30 Sep 2008, Klaas Gadeyne wrote:
>>
>>> On Tue, Sep 30, 2008 at 11:51 AM, Ruben Smits
>>> <ruben [dot] smits [..] ...> wrote:
>>>> On Tuesday 30 September 2008 11:08:54 Klaas Gadeyne wrote:
>>>>> On Mon, 29 Sep 2008, Peter Soetens wrote:
>>>>>> On Tuesday 23 September 2008 10:15:06 Markus Klotzbücher wrote:
>>>>> [...]
>>>>>
>>>>>>> * which unavailable UML2 state machine feature is most lacking in
>>>>>>> the current implementation and why?
>>>>>
>>>>> I have encountered situations in which I had to implement a statemachine
>>>>> in
>>>>> C++ in the update() step of the taskcontext instead of in the scripting
>>>>> language, due to the absence of "time events" (after 3 seconds, switch
>>>>> to
>>>>> state b).
>>>>
>>>> I miss these time events too, but if I'm not mistaken, one can use the
>>>> TimerComponent for these kinds of things now.
>>>
>>> Indeed (at that time the timerComponent did not exist yet), but we're
>>> not yet at a point where we can write something like
>>>
>>> after (300 ms)
>>>
>>> in the OSD file. [*]
>> Are there fudamental issues to be solved in order to reach this goal, or is
>> it "just" a matter of finding the implementation efforts?
>
> See below.
>
>>> [*] which might remain impossible, since the scripting language is
>>> defined in RTT, whereas the timercomponent belongs to OCL.
>>>
>> Isn't that a fundamental mistake...? Or is it indeed better to put a timer
>> _component_ into OCL, but a time _API_ into the RTT...?
>
> That won't solve the problem (I think). You can add the appropriate syntax
> into the scripting language, but you will have to setup the TimerComponent in
> order to implement it (ie. subscribe to Event(s) from the TimerComponent),
> hence you will need the API of a component which is not in RTT.
>
>> From the top of my head [*], I see 2 "solutions" to this:
> -> Put the TimerComponent in RTT anyway
> -> Let the TimeService infrastructure from RTT handle this instead of using a
> dedicated component (the TimerComponent uses this) for this.
Without too much thinking about it, I would go for the latter suggestion...
But I must confess I do not have enough insight in both alternatives to
make an authorative statement :-)
Herman
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm