There are many ways to design software for controlling a robot. The focus is not on low-level coding issues, but on high level concepts about the speci`l situations robots will encounter and ways to address these peculiarities. The approach taken here proposes and examines some control software architectures that will comprise the brains of the robot.
Probably the biggest problem facing a robot is overall system reliability. A robot might face any combination of the following failure modes:
Mechanical Failures - These might range from temporarily jammed movements to wedged geartrains or a serious mechanical breakdown.
Electrical Failures - We hope it is safe to assume that the computer itself will not fail but loose connections of motors and sensors are a common problem.
Sensor Unreliability - Sensors will provide noisy data (data that is sometimes accurate, sometimes not) or data that is simply incorrect (touch sensor fails to be triggered).
The first two of the above problems can be minimized with careful design, but the third category, sensor unreliability, warrants a closer look. Before discussing control ideas further, here is a brief analysis of the sensor problem.
An example of robot control is when it interacts with a wall. In a worst-case scenario, what could happen while a robot was merrily running along, following a wall? Several possibilities:
1. The robot could run into an object or a corner, properly triggering a touch sensor.
2. The robot could run into an object or corner, not triggering a touch sensor.
3. The robot could wander off away from the wall.
4. The robot could slam into the wall, get stuck, and conditionally trigger a touch sensor.
5. The proximity sensor could fall off its mount, causing a series of incorrect sensor readings.
Ideally, control software should expect occurrences of cases like those numbered #1 through #4 and be able to detect case #5.
