Related State Machines Question...

[danieljlevine]

I currently have a nice state machine defined using transitions-gui for objects detected whether they are moving straight, turning left, and right and it seems to be working nicely using multiple models.

But now I want to use that information to attempt to identify higher level behavior for maneuvers. So I want a second state machine to be in charge of determining what maneuver has been executed. So, for example, a track that say in the Straight state would send a "straight" transition to the the maneuver state machine to set the maneuver to "none". Based on state changes from the turning state machine, I'd like the maneuver sate machine to transition to other states that i define, like Nominal Left Turn, Nominal Right Turn, CW/CCW Circle, etc.

Would this be a good example of a parallel state machine?

[aleneum]

Hello again, @danieljlevine.

And also again this is probably not that interesting for you any longer but here is my opinion about this.

I'd say this question can be answered with the most popular and topic-independent answer there is: It depends!

If one action triggers an action for another state machine in a "fire and forget" manner I'd keep things simple and use a couple of independent FSMs without the added complexity of HSMs and parallel states. Let's say you have three state machines: One is detecting the road, one is responsible for steering and one for the breaks. When road turns right steering will also steer the vehicle. Let's say steering is not possible (turn_right condition is 'speed below x') it will then send an event to break with a target speed and steering will periodically try to steer until steering is successful and road returns straight again. This is rather straight forward and every machine operates more or less on its own. If the coupling becomes an issue this can be tackled by dispatching strategies like PubSub (Observer Pattern) or inversion of control.

Imho, parallel and HSM states become interesting when a) nested behavior changes based and/or hierarchical 'higher' states or b) complex state configurations need to be considered to determine next actions. For instance a complex state like: [road_left, steering_none, breaks_no_response] should trigger some specific behavior that requires a 'meta/management' view on all states as a prerequisite.

In short: While FSMs are easier to maintain and operate, complex behavior may require a set of states to be considered for appropriate actions. This is when HSMs can come in handy.