I drew up an arbitration/subsumption architecture, on the train home, and then coded it tonight - so far is seems to work. I think it is more arbitration than subsumption though. The way it works is a bit of a publish and subscribe metaphor - in that each sensor has a supply vector, identifying what inputs it reports on (oublish: for example, the SRF reports range - theoretically, a sensor could report two or more measures), and it passes this supply vector to the arbiter () function during the ISR. The arbiter has a set of demand vectors that are associated with each action/behaviour (subscribe: for example, the avoid behaviour has a demand vector of range, but the general case would be that an action demands more than one input.)
So if the (supply_vector && demand_vector) == true, then the action is interested in the change in the environment reported by that sensor, and it gets called. If the action takes control of any outputs (eg motors, leds, etc) then it sets the corresponding bit in the output vector - but it first checks whether that output is available.
Then arbiter calls the next action on the list that is interested, etc. It sounds a bit convoluted, perhaps, but I'll type it up and put it on my new site once I've had some more time to tinker with it. But the nice thing about this is that the actions/behaviours can be programmed in isolation from each other.
This works with 3 behaviours (retreat, avoid, and roam), one sensor (the SRF04), and one output (the motors). We'll see how it scales in the coming weeks. I think that the arbiter my have to become a timed action queue manager once the number of inputs and outputs and behaviours increases.
Cheers for now, Marcin.