Using Stepper Motors

Stepper Motors


However, if you would like to build a neat little vehicular robot then you can do so by connecting up a pair of cheap Stepper Motors through a couple of very cheap ULN2003s.

The cheap 5V steppers that are widely available (BY28) don’t turn very fast (maximum about 12 RPM) which actually makes them idea as beginners motors as your vehicle won’t run away during testing 🙂

These motors have 5 connections, 1 for power and the rest to control the stepping. (Their technical name is 5 Wire Unipolar Stepper Motor)

To use them in Scratch, you need to connect them up as follows

Stepper Motors Battery_bb

StepperA should end up (via the ULN2003 buffer of course) being controlled by pins 11,12,13 and 15 – Stepper B is via pins 16,18,22 and 7.

Pin 9 of the ULN2003s should be connected to +ve on the motor battery pack.

(The battery +ve MUST NOT be connected to any pins on the Pi)

stepperIn your Scratch program, you need to say that you are using Stepper motors instead of ordinary motors this is simply done by broadcasting Stepper in your Green Flag code block.

You can then simply using variables MotorA and MotorB as before with simple DC motors but this time they will each control 4 pins at a time.


The advantage of using stepper motors is that they can be just as easily stepped backwards as forwards. So to make MotorA go backwards at full speed simply use set MotorA to -100

Position Control
As well as treating the stepper as a continuously rotating motor, you can simply tell the stepper to change its “position” by a number of steps.

e.g. To turn 500 steps (approx 180 degrees on my motors) use posa

Note the use of change and not set

Advanced Stepper Control

Stepper motors need a delay between each step – this is currently set to 0.003 secs. You can control this value by using a variable called StepDelay.

You can also change the type of stepping mode from 2Coil (default value that gives maximum turning force) to 1Coil or HalfStep

20 thoughts on “Using Stepper Motors

  1. Hi Simon. I designed some stepper robots a while back with GPIO V2 to teach programming. Ive been meaning to update for long time but ive learnt that you update a working system with great care. I got a test bed set up with GPIO V4 and found that only one of the stepper motors were working. Thinking it was a hardware fault i went down that avenue first but it turns out the problem lies with your updated Scratch handler. MotorB is always OK its MotorA that has the problem. I removed the robot and attached a series of 4 LEDs so see what outputs were being sent to via MotorA. After I issue the broadcast of “Stepper” It turns out that pin 12 is the culprit, it turns on only for the briefest of times and then goes out again. The other pins are all OK and in the correct sequence. Pin 12 is in the correct sequence it just gets turned off the instant it is turned on. Interestingly if i do a separate command broadcast “pin12on” it turns on but instead of staying on it is quickly turned off. There is a work around I have found that may give you a clue as to where to look for this bug. If I do broadcast “allon”, wait for 1 second then do broadcast “alloff” and then do broadcast “stepper” it all works. I think this would also work if i did broadcast “pin12on”, “pin12off” then “Stepper”. Nothing wrong with any of my wiring, its all been tested. I just downloaded GPIO V5 and it has the same bug. On rare occasions I have also seen pin11 flicker on and off. Since pins11 and pin12 are also your motor pwm pins I wondered if some part of your handler is getting confused between stepper operation and motor operation, only a thought.

    As I said I have after many hours and by lucky accident found a workround that seems to get my robots working again. I just thought I would report my findings. Any chance of a fix ?

    • Interersting.
      There have been a few Stepper faults recently and I’d thought I’d nailed all of them but seemingly not.
      There won’t be a fix for the next week as I’m not available to work on ScratchGPIO (just put a load of time into getting V5 docs/site out of the door!!!) but at least you have a workaround 🙂


    • Hi
      I’ve just powered up my Stepper bot , loaded ScratchGPIO5 and typed
      On GreenFlag
      broadcast stepper
      set motora to 0
      set motorb to 0

      On Spacebar
      set motora to 100
      set motorb to 100

      and my both my steppers move fine when I press the spacebar and stop when I press the green flag.
      So lets just check a few things – how recent/uptodate is your copy of Raspbian -if its a old version of Raspbian (and maybe it is since you said you used V2 with it)that you’ve updated (but not re-downlaoded recently) then there is a bug in that your copy of RPi.GPIO may not be up to date and requires a bit of geek surgery to fix.

    • Sorry to bother again, just encountered another thing im having a problem with. Its the Position changes with the stepper motors. In Scratch I say ‘change PositionA by 20’ and ‘change PositionB by 20’. Both stepper motors turn but they keep on turning and dont stop. Im running 0.5.4 RPi GPIO. Any idea what I may be doing wrong ? Anything that I could try ? Thanks.

      • Sorry for delay – been tied up with other stuff.

        Just tried this out on my stepper bot and using change PositionA by 512 and the change PositionA by -512 makes my stepper fo 360 one way and then 360 the other (Well – in fact about 340 +/- 20 deg to be honest – something wrong somewhere) but basic turn one way – turn the other way seems to work


  2. No pgio, no servod or wiringpi, just Rpi.GPIO and your Scratch GPIO. Just updated my Raspbian. Your version 5 was downloaded yesterday. One further thing ive just found, if it is of any help to you, is that even with my work round when I use change PositionA it works but is very sluggish. When I use change PositionB it works very fine, just as I would expect. This lack of working on the the MotorA side of things but being perfectly OK on the MotorB side of things might point to the bug being in your handler. My thinking is that anything external would have the same effect on both side. They clue might be that MotorA uses pins 12 and 11, your pwm pins, could there be scope for conflict here ? Just a thought.

    I face this kind of thing all the time. Things always work perfectly for me every time when I do them myself but then when someone else does it, in a classroom for example, it fails 🙂 I know what you’re facing. Thanks for all your hard work. If it wasnt for you none of what I am currently doing would have even got off the ground.

    • Could you switch off and on and just type the simple script from the previous post. Dont load an existing script. Just that nothing else. And then run it to see what happens please.

  3. Just followed the instructions in the link to the post above. I was previously on 0.5.0, or something, now I am on 0.5.3a. It all works now. Thank you very much. I wouldnt have had a clue how to solve this problem on my own. I dont know what drives you to do this but i am grateful for it.

  4. Just as an aside while I am here. I am thinking about using pigiop, have you heard of it ?, for my python programming. I would love to keep using RPi.GPIO but am starting to run into all sorts of problems now because RPi.GPIO needs to be run as root and when I do this I run into problems with the VNC terminal emulator I use when running a Pi remotely. Also when I map a Pi directory to our server the contents of the folder disappear when IDLE is run as root. There are many great things I am reading about pigpio but one that has caught my attention is that it runs as a daemon. The daemon has to run as root but every connection to it, ie any Python program that wants to control the pins, can run as a normal user through function calls. The daemon just starts at boot up like all the other Pi daemons. This may or may not be of interest to you but just wondered if you had an idea of whether it might conflict with your scratch handler in any way.

  5. Sorry about this Simon but im having problems again with steppers. Ive just built a new SD image from the latest Wheezy and stripped down list of essential utilities, yours of course being one of them. MotorA & MotorB work fine on the stepper. The problem always seems to be with the position. Change poisitionA or change positionB just results in the motors going round for ages before stopping no matter what value is used to change them by. Also change positionA by -10 only sends the motor in reverse once the overall value of the variable positionA goes to negative. If positionA equals 50 then a repeated change positionA by -10 sends the motor forward until positionA eventually hits zero, then the motor goes backwards. In GPIO2 i didnt have any problems with Stepper motors at all. Is there any suggestions you can make this time ? Ive checked my rpi.gpio verion, its 0.5.5

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s