So does that mean he played with systems that queued messages? Otherwise I don't understand how they could time out. A queue of course if a big time state/memory device.
Yeah, you can always think of a clock as an external part of the environment and the system them has the ability to sense this aspect of the environment (time passing). From that type of view, you can implement timers in many different ways.
Are the FSM's arbitrary complex FSMs with as many states and transition rules you care to put in them, or are they limited in some way? Such in how they change state?
Sure, I understand that.
Well, my guess is that they are not trying to hide state as much as they are advocating splintering the state machine up into small distributed pieces each which are triggered by environmental events instead of internal events.
Yeah, I'm understanding it a little better. But of course I really need to read the books to get a real understanding. The idea of a "servo" behavior from Jones is still not clear but I understand the ballistic concept so I can guess what he's thinking about for servo behavior and I'm probably not too far off.
Are you familiar with OO programing? What you are talking about reminds me a lot about the differences between structured programming and OO programing. And your objections remind me of the type of things some people complain about when trying to learn OO programing but still thinking in structured programing terms. I think there's some important parallels here.
The point of OO programing is that you have to learn to look at the software very differently. Instead of thinking of it as sequential programs that manipulate data structures, you learn to think of it as collections of data structures (objects) that each have large collections of simple functions. You think of the objects as "doing" things instead of your code doing things. The entire view of the program changes from a collections of code (aka algorithms) to a collections of objects.
In structured programming, it's easy to understand the program flow, but hard to see the data. In OO programming, it's easy to understand the data, but almost impossible to understand the program flow. You can write any program using either paradigm, but some applications are far easily to write using OO (complex data structures with no real performance issues), and some are better as structured code (complex performance intensive algorithms with simple data structures).
With subsumption, and these other behavior based robotics approaches, I see it being the OO approach to bot programing. Except the focus is on behaviors, instead of objects. But it's similar to OO programing because the idea is to fracture your code into lots of little independent functions (aka behaviors) and create simple rules (environmental triggers and priorities) to define when each behavior should be used.
Now, a state machine, is very much the same. Every state in effect is a behavior, and you slice the behavior of the robot into lots of little pieces, where each piece is one state. But state machines general include code in each state, that determines when it should change to another state.
The problem with the state machine approach is that every time you add a new behavior, (aka a new state), you have to go back and think about all the other states the machine can be in, and think about when it might make sense to abort those old states, and switch to his new state. And of course, when the state machines get large, we seldom do this as much as we should, or worse we try to do it, but fail to test the code, in all possible states, and think our code is working well when it's still got some bad bug in it.
It also means that when you write code to add a new behavior, you end up having to add code to some old behaviors (states) that make reference to the new behavior. So the code connected with the new behavior (aka state) gets scatter all over the state machine.
The intent with using environmental triggers and arbitration systems (like behavior priorities), is that for a lot of stuff, you don't have to spend any time thinking about the other states and hand coding a lot of new automatic state transitions. All you have to do is think about where to insert the new behavior in the priority list. And all the code for each new behavior gets put together in one place.
So, without being an expert on the subsumption terminology, I think the idea is not as much to stay away from internal state (even though that might get pushed at times), but instead, to try and fracture the behaviors into as many micro behaviors as possible, and to try and trigger each from environmental conditions instead of triggering them internal state.
The advantage to this is that the micro behaviors end up being used in conditions you never thought about, and which they would not have been used if you had used more traditional FSMs to drive behavior.
For example, if you want to back up and turn when you hit a wall, you could write this as one ballistic behavior driven by an FSM that carries out a fixed sequence of behaviors once it's triggered. But if you break it up into a backup behavior triggered by being too close to obstacles (measured by two sonar sensors), and a left turn behavior triggered by a backup condition with the right sonar registering a close object, and right turn triggered by a backup with the left sonar closer.
But then when you add a reverse cruse behavior later, you find the turn behaviors you wrote to get out of a trap work nicely to make you turn away from walls as you back up without you ever having to steal code from your backup and turn behavior. So you get automatic sharing of behaviors you never would have gotten had you scripted all the behaviors with state machines.
I think the general idea is simply that you should try to trigger all your actions based on what is happening in the environment instead of based on internal state machines, because the more you do that, the more likely the behavior will be put to good use in situations you never thought about. And even if the trigger is based on self awareness (aka what your were just recently doing - like backing up) that's better than just triggering it because of the last state we were in.
Another way to look at this, is that as programmers, we are very invested in the idea of producing a sequence of instructions to follow.
- back up 2. turn right 3. cruse forward again
We learn to think about programing as lists of instructions, so we naturally learn to think about programing a bot as lists of instructions. W think that step three comes after step 2.
State machines, are just complex lists of instructions where we specify a more complex flow of control. We specify that we go to step 2 after we finish step 12. We are used to hand specifying all the sequence and all the rules for changing sequence.
The ideas like subsumption that has been developed is just the idea that when we program an interactive agent, we need to break out of this mode of thinking that we as the programmer need to specify the sequence, and instead, specify the environmental conditions which should trigger each possible action, instead of specifying the sequence.
So we replace the above sequence with:
Trigger Action
Bump switch Back up
backup & no bump switch Turn right
when nothing else to do go forward
We give up most our control of sequence, and turn the control of sequence over to the environment as much as possible. But when we have to, we still use small state machines to control sequence within a behavior.
Now, I don't know if any of the above perspective gives you any new insight into your thoughts about subsumption and it's use of state, but I think the above ideas are the prime motivations behind paradigms like subsumption. The more you stay away from state machines, and the more you are able to specify action based on environmental triggers, the more likely the bot will produce useful behaviors in environments you never thought about. The more you use state machines to hand-code the action sequences, the more likely the bot will do something stupid like drive itself off a cliff.