問題タブ [boost-statechart]

ステート マシンに基づくロボット制御プログラムに取り組んでいます。このプログラムは Qt State Machine Framework を使用していますが、理論的な演習とライブラリの学習/評価の方法として、Boost.statechart (BS) を使用して実装を試みました。

Qt バージョンでは、いくつかの場所で次のパターンを使用しました。複合状態には、ネストされた並列サブグラフがあり、それぞれが最終状態に到達します。すべての並列サブステートが終了すると、親ステートは「finished()」シグナルを発行し、これによりマシンは次の最上位ステートに遷移します。例 (注意: 疑似図):

そして状態は、最終状態がどこにあるかのcalibrate_*ように、その内部にネストされた状態を持ちます。両方の状態がそれぞれの状態信号に達すると、状態マシンが に遷移します。S -trigger[calibrated?]-> FFcalibrate_*FfinishedIdle

Qt の並列子状態は、BS の直交ネスト状態に類似しています。最初は、「終了」は BS の最終状態に類似したものだと思っていましたが、実際はそうではありません。それは、「直交するものがどこかにまだ進行していない限り、ステートマシンを終了する」ようなものです。すべての直交状態を終了すると、遷移する機会がなく、親状態も終了します。これらのイベントを配信できる状態がないため、終了時にイベントを投稿しても役に立ちません。

私は最終的に到達したときに通知イベントを投稿し、親状態でこのイベントに反応する「最終状態」を実装しました-すべての直交状態が最終イベントに到達してから遷移するかどうかを確認します。これは基本的に Qt State Machine のアプローチの再実装ですが、このパターンが必要になるたびにやり直す必要があります。しかし、私はこの効果を達成するための 1 つの方法に慣れすぎて、別の方法が見つからないのではないでしょうか?

Boost.Statechartを使用してステートマシンを実装する際にsimple_state、コンストラクターからの外部コンテキストにアクセスしようとすると問題が発生しました。のコメントは私にsimple_state.hpp教えてくれます：

コンストラクターから外部コンテキストにアクセスできることは別として、私の状態の基本クラスとしてではstate<>なく、使用することにはどのような違いや影響がありますか？simple_state<>

boost::statechart を学習しようとしています。

ファイルをロードする小さなアプリを作りたいです。

しかし、ファイル名などの引数を状態に転送するにはどうすればよいですか? ファイル名を EvLoad 内に保存すると、状態反応のために簡単にアクセスできます

しかし、Unloaded 状態のときは、Loaded のコンストラクターを呼び出しており、それに引数を渡すことができません。私が思いついた唯一の回避策は、移行を行う前にイベントを再投稿することですが、これは少し汚いように見えます。

より良い代替手段はありますか？

コンストラクターが完了すると、無条件にA次の状態に遷移したい状態があります。これは可能ですか？BA

コンパイルしても機能しないコンストラクターからイベントを投稿しようとしました。ありがとう。

編集：これが私がこれまでに試したことです：

これにより、次のランタイム アサーション エラーが発生します。

から派生した基本クラスを定義したいと思いますstatechart::simple_state。これには、仮想関数を呼び出す「定義済み」の反応があります（派生クラスで実装する必要があります）。私が望んでいるのは、いくつかの状態が、特定のイベントが私の基底クラスから派生した場合に自動的に反応することです。

このように (scですboost::statechart)​​:

次に、派生クラスで:

派生クラスのtypedefは、私が想定している基本クラスのものを「上書き」するのでcuston_reaction、ハートビートイベントに を派生クラスのリストとして定義する必要があるかもしれません。しかし、このデザインは、このライブラリの設計者がそうあるべきだと考えていたようなものではないかもしれません。

編集

その間、私はいくつかの追加の知識を得ました。の回避策typedefは、基本クラスではなく派生クラスで定義することです。しかし、その後、奇妙な問題が発生します。基本クラスで定義されているにもかかわらず、コンパイラーはメソッドを見つけられません。他の反応 ( )react (const EvHeartBeat& )を削除すると、機能します。もちろん、それは私が望んでいることではありません。複数のイベントに反応できるようにしたいのです。react (const OtherEvent& )

私はC++とBoostステートチャートにかなり慣れていないことを認めなければなりません。Statechartライブラリで少し遊んで、「より大きな」ステートマシンを構築したいと思いました。

私の問題の非常に簡単な例を挙げます。状態が1つだけで、自己遷移が多いステートマシンを想定します。そのようなものを構築する方法は？20を超える遷移はすべて、gcc（4.5.2）コンパイラによって拒否されます（「テンプレート引数の数が間違っています（21、20である必要があります）」）

サンプルコードは次のとおりです。

誰かがこの問題で私を助けてくれることを願っています、または少なくとも私のやり方の誤りを指摘してください...

私の問題の簡単な例として、「機能モード」の動作状態に入ることができるアプリケーションの一部を考えてみましょう。次に、ユーザーが押すファンクション キー F1 ～ F4 に応じて、4 つのサブモードを使用できます。デフォルトでは、F1 モードに入ります。状態図は次のように始まります。

ユーザーはいつでも F1 ～ F4 を押して、対応するモードに切り替えることができます。これらの遷移を内部状態に追加すると、次のようになります。

明らかに、これは (a) 混乱しており、(b) 定義する遷移が多数あります。ある時点で F5Mode を追加したい場合は... まあ、あなたは写真を手に入れます。これを回避するために、次のことを行いたいと思います。

Boost Statechart を使用すると、FunctionMode から任意の内部状態への遷移を定義できますが、結果は期待したものではありません。実際の結果は次のとおりです。

つまり、F1-F4 を押してモードを切り替えると、外側の FunctionMode 状態が終了し、不要な終了アクションと開始アクションがトリガーされて再入力されます。

2006 年にさかのぼると、ライブラリの作成者とユーザーの間のこのスレッドは、同じ問題を説明しているようです。著者は、回避策として次のことを提案していると思います。

ただし、その回避策は私にはあまり魅力的ではないようです。コンパイルする余分な状態レベルが追加され、コードが読みにくくなり、関数モード サブのいずれかに戻るには深い履歴を使用する必要があります。 -状態と中間状態オブジェクトが不必要に破棄され、再構築されています。

だから...どこが間違っているのですか？または、代替手段は何ですか？Boost Meta State Machine (msm) について簡単に説明しましたが、これまで見てきたことから、Statechart の外観の方がはるかに好みです。

多くのユーザーが同じ問題に直面していないことに驚いています...おそらく私のアプローチは完全に間違っていると思います!

ステートチャートから継承するいくつかの個別のFSMクラスを作成したとしましょう。次に、それらのオブジェクトをインスタンス化し、それらが相互にイベントをトリガーできるようにします。たとえば、最初のFSMは「オン」状態になり、2番目のFSMでイベントをトリガーします（process_event（EvSomething（））など）。

それを行うための最良の方法は何でしょうか？

どうもありがとうございます、

ファブリツィオ

複雑な状態マシンの一部のみを (単体テストの目的で) 実行する方法を探しています。そのために、boost::statechart フレームワークを評価しています。

私が考えた方法の 1 つは、階層的なステート マシンを設計することでした。この場合、各ステートはネストされたステート マシンとして定義され、個別にテストする必要があります。

次のコード スニペットの FSM 定義を検討してください。

内部A1およびA2状態を含む状態Aに対して定義されたロジックを実行またはコンパイルせずに、状態B内で定義されたロジック、つまりB1およびB2内部状態を単体テストすることは可能ですか?

前もってありがとう、AmirH