A few weeks ago I commented on a task our second year software-engineering students are doing: building robots to follow a white line with the Lego 'Mindstorm' kit. It's been entertaining watching their various attempts and their design selections. Most groups have pretty-well optimized their robot now, and there's some final tweaking going on, ahead of our Engineering Design Show at the end of semester.
There's a fine line between an excellently-performing robot and a disaster. To be fair to the students, they haven't come across control theory yet, so for them to identify what's going on when the robot veers off sideways and accelerates into the wall is often not easy. There's been one common problem that the groups have been tackling, namely instability in their tracking.
Most groups are using two sensors to look for the white line. Crudely speaking, if the robot veers off to the right, the left-hand sensor will cross the line, the robot will 'realize' this, and turn to the left. Conversely, if it goes too far to the left, the right-hand sensor crosses the line and the robot will respond by turning right. But getting the control system stable isn't as straightforward as that.
If the robot doesn't turn hard enough, what happens is that it fails to get round corners. It goes off the line completely, so that neither sensor now sees the line, and then it's doomed. However, if it turns too hard, it can over-adjust, so that it now veers off the line on the other side. What can happen now is an oscillation: the robot drifts off to the left - so it then corrects and moves hard to the right - but it goes too far right and now it needs to turn hard back left, and so on.
We can end up with the robot either wiggling along a perfectly straight line, or worse, having it progressively over-correct until the corrections become so large it loses the line completely. The former is an example of a 'limit cycle, or attractor' - a systems-theory term for a stable but possibly rather complicated oscillation.
More amusing this morning was the poor robot that ended up going in every-decreasing circles. Just what was happening with it I'm not sure, but it veered off the line, did a large diameter circle, and continued in a circlular orbing, but gradually speeding up and reducing its diameter. It ended up spinning on the spot with the left-wheel on maximum forward speed and the right-wheel on maximum reverse speed. This is another (and more entertaining) example of a limit cycle - once it had got into the spinning state, that was where it was going to end up.
Preventing these things is a bit easier when you know some control theory (see here for example) and can apply the negative feedback in a sensible manner - but we teach them that later. For now, it's about the design process (and the entertainment value).