I think that fits well given my premise.
I don't think so. So far I think "behavior" as a word is so overloaded in meaning, it obscures what's going on, and the subcomponents of behavior are thereby going unnamed. Basic action states (music analogy notes) are what I think of as the real behaviors or as I am now calling them, atomic behaviors. A short fixed sequence of atomic behaviors which might be called an escape behavior as example (trill, or stanza, or maybe even a chorus, perhaps in the music analogy) I have no good name for to distinguish between atomic behaviors and this level. Mode doesn't really fit. Then there are long and complex things called behaviors, like "search for food", or "throw a tantrum", or what-have-you on human levels of action (music analogy melody or even opus). All these are simply called behaviors, and as such it is much to broad to be useful for the layering in behavior based robots.
Well, don't expect a large argument from me. I like reductionism in state machines, and I like to split state machines into even smaller and more insultated machines.
I find often the problem when someone designs a state machine, they make it too complex. Often a few simple machines, with intermachine communications, will have less states, less transitions, and be more robust as you say.
I've told the story several times before, but when I worked on a traffic light system, they wanted a state diagram of its operation. No one had ever been able to do it. I finally solved it by separating what what going on into several simple machines that interacted.
From problem too complex for anyone to solve, to problem solved with several small machines. If you didn't factor the machines like that, the number and complexity of the states just exploded.
Did you see my suggestion, in another post, though, that a robot that does an occassional or random change of state to escape, even if done at the wrong time, in the end looks more intelligent than a robot that does not?
A robot that always cruises will get trapped forever. A robot that occassionally throws in an escape sequence does not.
I think this is an argument of scale. While I get your point, what a curb is to nBot, a telephone pole laying on the ground is to jBot. You can build your robot for the expected environment, but it will still have to deal with those things at another scale, or it will not be robust.
So a robot with 200 foot wheels would be more robut than jBot, because there aren't many manmade structures it couldn't just roll over? What about a skyscrapper? Oh. It's just a mater of scale, and the problem returns at some point.
This is a really interesting derivation, because as I mentioned in another post, it can be used to reduce the number of states or atomic behavior. They way it does it is quite surprizing. By my definition of an atomic behavior, we have two variables instead of one, each with a gain function, and they are linear. Yet the output is not linear. It is a challenge to me to sort out if I think it is an atomic behavior or not.
I've run into a very similar thing in my walking robot. The center of turn when going straight is out at infinity. As it moves in toward the robot, the outer legs take their normal strokes, and the inner legs take shorter ones... until the center of rotation is under one leg, and it just stops and pivots. As the center of rotation mover under that leg and toward the center, the stroke of the leg reverses, and when the center of rotation is directly under the bot, the leg described is now making a full backwards stroke, and the robot's body rotates about a point.
This is attractive, yet fanciful. There are state changes going on. They have just been extracted from the output machine, and moved elsewhere.
But there must have been a mechanism (or transfer function if you prefer) that determined forward progress had stopped, and so rotational progress must begin.
Not knowing how the 0 value in rotate went up when the forward value went down, I am not able to fully comment, but the important point is, there was some function that did that transfer.
I would suggest, what you've done here is factor and hide your state information. Like the traffic light problem, you have reduced the complexity of the output machine, by separating the control to some other simpler machine.
Are you sure you haven't just moved the decision elsewhere?
The output routine uses two vectors. The issue is what fills the two vectors and how it does it.
I don't disagree, and I don't think it is heretical. I actually think it is pivotal. (no pun deliberately intended, but there's certainly one there now I see it written).
Randy M. Dumse
Randy M. Dumse
Click to see the full signature.