Questions:
The basic idea behind subsumption is to break up the robot's behaviors into basic modules. Collections of modules are organized in layers, where the lowest layers perform the most basic tasks, and the higher levels the most complicated ones.
One important property of layers is that they be developed to be "self-sufficient". This means that if all the modules for higher layers are turned off, the robot will still exhibit some reasonable behavior.
Higher levels can make use of modules in lower levels by choosing to inhibit or subsume the output of these modules, providing alternate information instead. Look at the subsumption figures in Brooks' paper or the "Mobile Robots" handout if this seems unclear.
For this assignment, you will need to program the first three levels of a subsumption model. Level 0 will react to basic impulses, like backing away from an object if the touch sensors detect it. Level 1 will make the robot wander around randomly, and modify the behavior when the touch sensor is activated. Level 2 will give the robot a sense of purpose; it must move toward light, when there is a bright light source detected.
We will talk more about this in class, including what modules you should include and what they should do. Make sure you understand the readings!
You will write the controller so that we can use the buttons on the RCX to select which layers (layer 0 only, layers 0 and 1, or layers 0 through 2) will be active. We will discuss a programming style for enabling this flexibility (hopefully soon to be described in the notes section below).
This figure gives an overview of the architecture of the program.
We'll have demos of your robots on Thursday, September 16th.
Announcement: There is a cabinet in the robot lab where the robots can be stored.
Subsumption controller Issues:
{sensors} ---> [bump] [motion] ---> {robot}sensors provide two light source readings and a touch sensor reading. How do we connect the two together so that the robot behaves rationally?
How would we implement object avoidance?
[motion] needs to take something in and give commands to the robot.
do we want to send the motion module a script with commands?
What should we send? Something like go forward 3 seconds, then turn 90 degrees to the right?
a heading perhaps. [turn] [move] [turn]
For object avoidance, the robot must be able to back off. This would require two adjacent calls with [turn] [move] [turn]. This might also work: [move] [turn] [move]
We decide that the motion module should provide a heading to the robot.
But what should the values look like?
time? degrees? It would probably be best to use some sort of absolute conversion system so that each module that wants to send heads doesn't have to do any scaling itself.
One problem that seems to present itself in our system is that we must communicate with the motors using two different programming methodologies. Backing off wants pure headings, whereas light-following needs a Braitenburg type approach.
who speaks to the motor?
Possible organization of priorities:
1. [bump]
2. [wander]
3. [light]
A lengthy debate demonstrates that any ordering of the three levels makes some amount of sense. They are not all Brooksian, however. His stuff is more of a design paradigm. Every level should be robust, i.e. once object avoidance has been implemented, the robot should not keep running into objects as more levels are added.
bump should be at level 0.
Level 0 Diagram:
{sensors} --(heading)-->[motion]--->{Robot}
[wander]--(heading)-+->[avoid]---+
{sensors]-----------+->[BUMP]----s-->[motion]--->{robot}
n.b. Brooks's robot was different. It could actually avoid things without running into them first thanks to spacial awareness provided by sonic proximity sensors.
The question d'jour to ponder: how do you add Braitenberg?