openrtm-usersの皆様、
産総研の末廣です。
FedraのVMWareImageでいろいろ試しているのですが
onActivatedでのerrorに対する状態遷移について疑問があります。
onActivatedの内部でエラーを発生させても、
onActivatedをRTC::RTC_ERRORで終了させても、
必ず1回onExecuteが走った後に、onErrorに移ります。
onExecuteに対するガードとしての役割を考えるとバグっぽいのですが、
それともこれは仕様でしょうか。
RTCのspecificationの遷移図を見ても、
私には良く分かりませんでした。
よろしくお願いします。
p.s.
これに関してソースをチェックするとしたらどの
ファイルを見たらよいのでしょうか？
末廣様
安藤です
> 産総研の末廣です。
> FedraのVMWareImageでいろいろ試しているのですが
> onActivatedでのerrorに対する状態遷移について疑問があります。
>
> onActivatedの内部でエラーを発生させても、
> onActivatedをRTC::RTC_ERRORで終了させても、
> 必ず1回onExecuteが走った後に、onErrorに移ります。
ご指摘の通り、onActivatedがエラーの場合、onExecuteを通らないで、
ただちに、onDeactivatedおよびonAbortingが実行されるべきだと思います。
OMGのRTC Specificationのステートマシン図でも、
ACTIVE状態からERROR状態への遷移のガード条件が、
[ReturnCode_t==ERROR]となっているので、
on_activated が ERROR のとき、直ちに遷移のトリガーがかかり
on_deactivated、on_abortingの順で実行されるものと思います。
ステートマシンの解釈として、これで正しいでしょうか？＞坂本様
> onExecuteに対するガードとしての役割を考えるとバグっぽいのですが、
> それともこれは仕様でしょうか。
>
> RTCのspecificationの遷移図を見ても、
> 私には良く分かりませんでした。
>
> よろしくお願いします。
>
> p.s.
> これに関してソースをチェックするとしたらどの
> ファイルを見たらよいのでしょうか？
StateMachine.hおよびPeriodicExecutionContext.[h|cpp]が
該当のファイルになると思います。
安藤様
いつもお世話になっております．
テクノロジックアートの坂本です．
> OMGのRTC Specificationのステートマシン図でも、
> ACTIVE状態からERROR状態への遷移のガード条件が、
> [ReturnCode_t==ERROR]となっているので、
> on_activated が ERROR のとき、直ちに遷移のトリガーがかかり
> on_deactivated、on_abortingの順で実行されるものと思います。
>
> ステートマシンの解釈として、これで正しいでしょうか？＞坂本様
ご指摘のとおりです．
OMG RTC Specificationのステートマシン図では，
Active状態のentryアクションであるon_activateの返り値がOKではない場合，
on_deactivateを実行してActive状態から抜け，
on_abortingを実行後，Error状態に入るという仕様となっております．
(上記の振る舞いがLightweight RTCの仕様となっております)
また，仕様上はon_executeを実行するのは，
Execution SemanticsがPeriodic Sampled Data Processingの場合となっております．
そのため，こちらの振る舞いにつきましては，後半部分に記述しております．
(こちらはステートマシン図は記述しておりません．
替わりにシーケンス図のサンプルを記述しております)
よろしくお願いいたします．
坂本様
安藤です
お世話になっております。
> > OMGのRTC Specificationのステートマシン図でも、
> > ACTIVE状態からERROR状態への遷移のガード条件が、
> > [ReturnCode_t==ERROR]となっているので、
> > on_activated が ERROR のとき、直ちに遷移のトリガーがかかり
> > on_deactivated、on_abortingの順で実行されるものと思います。
> >
> > ステートマシンの解釈として、これで正しいでしょうか？＞坂本様
> ご指摘のとおりです．
> OMG RTC Specificationのステートマシン図では，
> Active状態のentryアクションであるon_activateの返り値がOKではない場合，
> on_deactivateを実行してActive状態から抜け，
> on_abortingを実行後，Error状態に入るという仕様となっております．
> (上記の振る舞いがLightweight RTCの仕様となっております)
ありがとうございます。
on_activated がエラーで戻った場合、on_execute ではなく
on_deactivated、on_aborting の順に実行されるというのは
仕様にも則っているということですね。
では、その方向でソースは修正したいと思います。
ありがとうございました。
皆様
産総研の清水です．
状態遷移について不明な点があったので教えて下さい．
> OMGのRTC Specificationのステートマシン図でも、
> ACTIVE状態からERROR状態への遷移のガード条件が、
> [ReturnCode_t==ERROR]となっているので、
> on_activated が ERROR のとき、直ちに遷移のトリガーがかかり
> on_deactivated、on_abortingの順で実行されるものと思います。
この説明によると，ACTIVE状態からERROR状態に遷移するときは，
ERROR状態のentry関数の前にACTIVE状態のexit関数が呼ばれ
なければいけないということでしょうか？
それならば，onDeactivatedでエラーが起こった場合でも，
onDeactivatedがまた呼ばれなければいけないということに
なってしまい，なんかおかしな感じがします．
RTMのHPの状態遷移図
http://www.is.aist.go.jp/rt/OpenRTM-aist/html/E3839EE3838BE383A5E382A2E383AB/RTCE38397E383ADE382B0E383A9E3839FE383B3E382B0E585A5E99680.html
では，それぞれの状態にentry, do, exitの関数が存在し，
そのうちのどれかがRTC_OK以外を返した場合に，
即座に状態遷移が起こるように見えます．
ということは，ACTIVE状態のentry, do, exit
のどれかがエラーとなった場合，
onDeactivated（ACTIVE状態のexit関数）は呼ばれずに，
onAborting（ERROR状態のentry関数）が呼ばれるような
気がするのですがどうでしょうか？
解説よろしくお願いします．
清水
On Thu, 6 Sep 2007 17:41:58 +0900
"Ando Noriaki" wrote:
> 坂本様
>
> 安藤です
>
> お世話になっております。
>
> > > OMGのRTC Specificationのステートマシン図でも、
> > > ACTIVE状態からERROR状態への遷移のガード条件が、
> > > [ReturnCode_t==ERROR]となっているので、
> > > on_activated が ERROR のとき、直ちに遷移のトリガーがかかり
> > > on_deactivated、on_abortingの順で実行されるものと思います。
> > >
> > > ステートマシンの解釈として、これで正しいでしょうか？＞坂本様
> > ご指摘のとおりです．
> > OMG RTC Specificationのステートマシン図では，
> > Active状態のentryアクションであるon_activateの返り値がOKではない場合，
> > on_deactivateを実行してActive状態から抜け，
> > on_abortingを実行後，Error状態に入るという仕様となっております．
> > (上記の振る舞いがLightweight RTCの仕様となっております)
>
> ありがとうございます。
> on_activated がエラーで戻った場合、on_execute ではなく
> on_deactivated、on_aborting の順に実行されるというのは
> 仕様にも則っているということですね。
>
> では、その方向でソースは修正したいと思います。
> ありがとうございました。
清水様
安藤です
今手元にUML2.0の仕様しかない(最新は2．1.1？)ので申し訳ないですが。。。
UML Superstructure Specification, v2.0, p.555より
まずは遷移条件ですが、
A transition is enabled if and only if:
• All of its source states are in the active state configuration.
• One of the triggers of the transition is satisfied by the event
(type) of the current
occurrence. An event satisfies a trigger if it matches the event
specified by the
trigger. In case of signal events, since signals are generalized
concepts, a signal
event satisfies a signal event associated with the same signal or a
generalization
thereof.
• If there exists at least one full path from the source state
configuration to either
the target state configuration or to a dynamic choice point in which all guard
conditions are true (transitions without guards are treated as if
their guards are
always true).
最後の項目にもあるように、guardがtrueの場合に遷移が有効になります。
次にガードについてですが、p.556に次のように書いています。
Guards
In a simple transition with a guard, the guard is evaluated before the
transition is
triggered.
In compound transitions involving multiple guards, all guards are
evaluated before a
transition is triggered, unless there are choice points along one or
more of the
paths. The order in which the guards are evaluated is not defined.
ガードの評価は常に遷移の前に行われます。
p.557より
Once a transition is enabled and is selected to fire, the following
steps are carried
out in order:
• The main source state is properly exited.
• Behaviors are executed in sequence following their linear order along the
segments of the transition: The closer the behavior to the source
state, the earlier
it is executed.
• If a choice point is encountered, the guards following that choice point are
evaluated dynamically and a path whose guards are true is selected.
• The main target state is properly entered.
> 状態遷移について不明な点があったので教えて下さい．
>
> > OMGのRTC Specificationのステートマシン図でも、
> > ACTIVE状態からERROR状態への遷移のガード条件が、
> > [ReturnCode_t==ERROR]となっているので、
> > on_activated が ERROR のとき、直ちに遷移のトリガーがかかり
> > on_deactivated、on_abortingの順で実行されるものと思います。
>
> この説明によると，ACTIVE状態からERROR状態に遷移するときは，
> ERROR状態のentry関数の前にACTIVE状態のexit関数が呼ばれ
> なければいけないということでしょうか？
> それならば，onDeactivatedでエラーが起こった場合でも，
> onDeactivatedがまた呼ばれなければいけないということに
> なってしまい，なんかおかしな感じがします．
3つの場合に分けて考えてみます。
1. on_activatedがエラーの場合
a) 遷移のガード条件が評価される
b) ERRORへのガード条件がtrueであるので遷移する
c) ACTIVE状態から出る。すなわち、on_deactivatedが実行される
d) 遷移のアクション on_abortingが実行される
e) ERRORへの遷移を完了する
※on_activatedが実行された時点では、状態はACTIVEなので、出るときには
必ずon_deactivatedが実行されるはず。
2. on_executeがエラーの場合
a) 遷移のガード条件が評価される
b) ERRORへのガード条件がtrueであるので遷移する
c) ACTIVE状態から出る。すなわち、on_deactivatedが実行される
d) 遷移のアクション on_abortingが実行される
e) ERRORへの遷移を完了する
3. on_deactivatedがエラーの場合
すなわち、deactivateがコールされ、遷移のトリガがかかる。
ガードはトリガの前に評価されており、on_deactivatedの戻り値は
対象にならない。したがって、
a) ACTIVE状態から出る。すなわち、on_deactivatedが実行される
b) 遷移のアクションはないのでなにもしない
c) INACTIVEへの遷移を完了する
以上、UMLの解釈に従えば、このような動作になるように思います。
ただし、現在の実装ではon_deactivatedの戻り値をチェックして、
OKでなければERRORへ遷移するようになっていますが、
上の解釈が正しいとすれば、これはバグになりますね。
> RTMのHPの状態遷移図
> http://www.is.aist.go.jp/rt/OpenRTM-aist/html/E3839EE3838BE383A5E382A2E383AB/RTCE38397E383ADE382B0E383A9E3839FE383B3E382B0E585A5E99680.html
> では，それぞれの状態にentry, do, exitの関数が存在し，
> そのうちのどれかがRTC_OK以外を返した場合に，
> 即座に状態遷移が起こるように見えます．
> ということは，ACTIVE状態のentry, do, exit
> のどれかがエラーとなった場合，
> onDeactivated（ACTIVE状態のexit関数）は呼ばれずに，
> onAborting（ERROR状態のentry関数）が呼ばれるような
> 気がするのですがどうでしょうか？
少なくとも、exitのアクションが記述されている限りは、
その状態から出るときはexitアクションが必ず呼ばれるはずです。
p.533にこう書いてあります。
exit: Behavior[0..1]
An optional behavior that is executed whenever this state is exited
regardless of
which transition was taken out of the state. If defined, exit actions
are always
executed to completion only after all internal activities and
transition actions have
completed execution.
ただし、これらはあくまでUMLの解釈の話なので、この遷移で問題がある場合は、
ステートマシン図を書きなおす必要があります。
ただ、私としてはACTIVE状態から出るとき必ずon_deactivatedが実行されるのは
自然だと思います。
ちなみに、0.2.0でもACTIVE状態から出るときは必ず、
rtc_active_exitが呼ばれるような実装になっていたと思います。
清水様
いつもお世話になっております．
テクノロジックアートの坂本です．
> > OMGのRTC Specificationのステートマシン図でも、
> > ACTIVE状態からERROR状態への遷移のガード条件が、
> > [ReturnCode_t==ERROR]となっているので、
> > on_activated が ERROR のとき、直ちに遷移のトリガーがかかり
> > on_deactivated、on_abortingの順で実行されるものと思います。
>
> この説明によると，ACTIVE状態からERROR状態に遷移するときは，
> ERROR状態のentry関数の前にACTIVE状態のexit関数が呼ばれ
> なければいけないということでしょうか？
> それならば，onDeactivatedでエラーが起こった場合でも，
> onDeactivatedがまた呼ばれなければいけないということに
> なってしまい，なんかおかしな感じがします．
まず，Stateのexitアクションが呼ばれる条件に関してなのですが，
こちらは，
「状態からどのような遷移が行われるかに関わらず，
この状態から出た時に必ず実行」となります．
従いまして，ACTIVE状態から抜ける時には
(INACTIVE状態に遷移する場合でも，ERROR状態に遷移する場合でも)
必ずon_deactivatedが呼ばれます．
また，安藤様からもご説明がございましたが，
ガード条件は遷移が発生する前に評価されます．
このため，厳密にはon_deactivatedの返値は
Error状態へ遷移するかどうかの評価対象外となります．
よろしくお願いいたします．
神徳＠産総研です RTミドルウエアユーザメーリングリストの皆さま
いつも、RTミドルウエアに関して、技術的なフィードバックをいただき、ありが
とうございます。今日は、ひとつ皆さんにご相談があり、連絡させていただきした。
このたび、経済産業省さんの「次世代ロボット知能化技術開発プロジェクト」
(2007-2011)への提案が採択され、このプロジェクトの中でRTミドルウエアの完
成度を高め、さらに本格的な開発環境を構築する予定です。
http://www.meti.go.jp/information/data/c70904bj.html
つきましては、産総研で一緒に開発に加わっていただける方を探しております。
ポスドク、または、企業さんからの期限付き出向という形での参加にご興味のあ
る方は、まずは神徳まで連絡いただくようお願いいたします。
開始時期は、経済産業省さんとの契約ができ次第なので不確定なところがありま
すが、今年度の10月〜12月頃から開始を見込んでおります。仕事的にはソフトウ
エア開発が中心になります。
プロジェクト終了後にベンチャーを起業する意欲のある方は大歓迎です。いろい
ろ条件次第だとおもいますので、まずは、ご相談させていただきたいと思います。
＃近くのお知り合いにも情報をお伝えください。
今後とも、RTミドルウエアのご支援・ご協力お願いいたします。