Command and Control

Any project like micromouse is a tradeoff between hardware and software. One thing seems to be universally true however: No matter how easy you think the software design is going to be, you won’t have enough time to do it right. From reading around, it would seem that most constructors leave too little time for software development. No amount of work in a simulation environment can guarantee success in the finished platform.

From the outset, you will probably have some ideas about what will be the most difficult part of the control task. Chances are, it will be the basic motor control. Perhaps the most difficult task that your micromouse faces is just running down a corridor in a straight line. The faster you want to do it, the harder it is. Oh, and you had better be able to stop where you want to as well. The maze solving and navigation may seem more difficult but turns out to have some well-known solutions which can be tested on a simulation. I have dealt with maze solving elsewhere.

Bart Provo suggested a development sequence in a newsleter article in 1990:

• Motor control and speed sensing
• Control of distance moved
• Turning control and keeping track of heading
• Basic movement from cell to cell
• Open-loop running at speed
• Wall sensing for steering control
• Unit-square wall and exit sensing and reporting
• Close the motor-sensor loop and check wall following, turning and dead end behaviour

At the end of this you should have a beast that can be made into a wall-following mouse relatively easily.

If you remember to develop your software in a suitably modular fashion, all the above will form a neat layer (or set of layers) that can be called from higher level maze-related routines. This will also make it easier for the maze-related code to be developed on a simulator relatively independent of the low-level control routines.