In the last few weeks I've been working with some second-year software engineering students on a design project. Their particular task is to build (with Lego – but the high-tech variety) a robot that can follow a white line on a bench. It's fun to watch them play with different ideas and concepts – there's the occasional disaster when the robot roars off at high speed in an unexpected direction and falls off the bench top.
To produce something that approximately works isn't that difficult. We can use a couple of lights and detectors, sitting either side of the white line. If the robot is going straight, neither gets much reflection. But if one records a high amount of reflected light (and so is on top of the line) we need to turn the robot – if it's the other that records a high amount, we ned to turn the other way. Indeed, many, many years ago I made something very similar using analogue electronics (a few LEDs, photocells, transistors etc and a couple of motors to turn the wheels). It approximately worked, but there were a lot of conditions that would fool it – give it shadows and sharp corners to deal with and it was lousy.
The lego robots that the students have can be programmed – and as such there is a huge array of different options for their control. The exercise is just as much in the development of the software as the hardware. Indeed, since these students are software engineering students, that is the bit they are most familiar with.
One thing we're trying to get them to think about are different concepts. It's easy to think of one solution and just go with that. But is that the best solution? In engineering we can't afford just to develop the first idea that comes into our heads. We don't really have much idea about what is 'best' until we think through other possibilities and assess them against relevant criteria. Too often we can be constrained by traditional thinking – "it has to be done that way" – without really considering novel options. Two light sensors might work. But would three (or even four) be better? How are they best placed? What about sensors that aren't rigidly mounted but can move (actively search for the line)? The possibilities are almost endless.
But the hardware is only half the problem. How should the robot best respond to the input signals? Simply turning one way or the other is easy to implement, but can lead to excessive oscillation. There are smarter control systems available (e.g. Proportional Integral-Differential control), but at a cost of increased complexity. Is it worth pursuing them?
These are questions that the students need to think about with their project. We can get them to do that (rather than just thinking up one solution that might work and considering nothing else) by setting the assessment tasks appropriately. So they are not just judged on how well their robots can follow the white line, but what concepts they thought about, and whether they selected one appropriately using reasonable specifications and design criteria (i.e. how well they followed the established process for engineering design). In fact, following the design process well should ensure that the end result actually does do a good job of following the line accurately, repeatedly and quickly .
There are still several weeks until the end of semester, when these line-following robots need to be perfected. They'll be tested at the Engineering Design Show where we'll find out how to build a good line-follower.