The last post left off with me wondering why the Trapped behavior needed to be called even when a higher priority behavior was active. Here is why:
Remember I ported the code from the Command Module (CM) version to the Windows on the Fit PC Slim? In Windows there is a clock and in the CM there isn't. In the newer version I can setup a timeout by taking the current clock time and adding a delay. Then when the clock exceeds the timeout the timer has expired. For Trapped this meant the robot had not moved for over 10 seconds, despite other activities trying to make it move.
In the CM version, with no clock the Trapped needed to update the "clock" value to see if it exceeded the timeout value.
I'd say this falls under checking your assumptions. In the CM the assumption was that no clock existed so Trapped had to maintain its own. I didn't catch that the assumption was no longer valid in the Windows version.
I've been re-reading a lot of the papers on subsumption and the Jones book Robot Programming. I find that my implementation isn't really subsumption as it was originally presented by Rodney Brooks. Brooks is credited with the concept of programming robots by behaviors. His technique for implementing behaviors was subsumption.
My implementation is more in line with Jones, and also derives from David Anderson. David has an article about two of his robots, SR04 and jBot, which are accessible from the Dallas Personal Robotic Group .
I continue the discussion in a later post. I also want to take some time to reabsorb the subsumption and behavior programming concepts so I can elaborate on them.