Check out the datasheets for your motor to make sure that your motor driver can cope with the stall current. This is the amount of current the motor will consume when it is trying to rotate but cannot move – ie it is trying to go through a wall or up a very steep hill. If you suddenly change the direction of the motor then you may also experience spikes that are twice this amount. Failure to check this info will lead to your motor driver (the L293D in this example) to melt.

If you are running in an open loop system (see earlier) and are reliant on each step issued by software leading to the motor physically turning one step then you must be aware of the following situations:-

1. Clocking the motor at, or close to, its maximum speed – and the motor experiences a hindrance (ie a hill or some other external force/torque) then it may cause the motor to skip a step. Obviously: the closer you get to the stall torque then the more likely this is to occur
2. Momentum will also play its part. If you try to go from full speed ahead to full speed reverse then either the motor will skip some steps, or the wheels may skid. Either way you’ve lost your accurate positional accuracy.

Stepper motors are slow!! Since each software ‘step’ requires a physical movement before the next step can be issued then even the slowest microcontroller will twiddle its thumbs between issuing steps. In my example: the fastest possible step rate was every 3.3ms which, even for an ATMega8 running at 1MHz, is once every 3300 instructions. So this makes the software control a good candidate for being interrupt driven. A good example of daisy-chaining additional code to a hardware timer is given in this post:

http://www.societyofrobots.com/robotforum/index.php?topic=541.0

This allows you to schedule jobs. In my example: schedule a job to run in 4ms, when it happens then issue the next step and re-schedule yourself to happen in another 4ms. Obviously the 4ms could be longer if we want the motor to run slower.