New library to control a robot with two stepper motors

Hi, I am developing a robot that uses two stepper motors in a differential configuration. I could not find a library that would meet my needs, so I decided to make one. This library implements a class that takes care to synchronize two motors to produce programmed motions. All methods are non-blocking and library works with unipolar or bipolar stepper motors. Advanced features were implemented for vibration reduction, energy saving and protection of control circuits.

Playground page: Google code: Video demo:

Please post any bugs or suggestions you have.

regards, Perrotti

I finally finished the basic library documentation in English. Can be accessed on the Google Code wiki:

I have had a quick look at your documentation. It seems to be necessary to define 4 Arduino pins for each motor. Am I correct to think that your software is not intended for stepper motor driver boards (such as the Pololu A4988) that just take step and direction signals?


hello Robin, you're right, I should have been more explicit in the documentation. This library intents to generate signals to uln2003/2803 based boards (unipolar motors) or boards with double h-bridge (bipolar motors). These boards do not have the advanced features that are typically found in ramp type boards. (this term is right? sorry my english). So, this lib try provide a better control with no hardware resources. I have no experience with these boards, but I imagine that some of the features offered by the lib would not be needed and others not be possible to implement. Recently I got some units of the Pololu board and I plan to do some testing. Perhaps it is possible to adapt the lib to work with these boards, but I think it would be better to make another version especially for these boards.

About the boards based on A4988, I’m not sure if just two pins would be enough to leverage all the features offered by the board. Some moves require a wheel is locked in the same position while the other keeps moving. I’m not sure how this could be achieved only with the step and dir pins, is this possible?

Just don't send it any step pulses?


I mean, it is possible keep the motor stopped with the coils energized? To lock one wheel at its position. Just stop one motor dont work in some cases.

I mean, it is possible keep the motor stopped with the coils energized?

That's the way a stepper motor works, when not stepping.

If yours aren't, there is something wrong with your wiring or power supply.

Thanks Paul, Like i said, i dont have experience with this boards, so, if i stop the pulses, coils remain energized. This means that if I want to really turn off the engine then I need use the enable pin. In this case I would need 3 pins for each motor, only two would not be enough. Or I can use same pin to both enables. 5 pins is lot better than 8. Micro stepping can be selected via hardware.

Perrotti: Thanks Paul, if I want to really turn off the engine then I need use the enable pin.

Yes, but why bother?


Hi Robin, Stepper motors are gluttonous little things and the robot needs to be powered with batteries. If the motors are turned on all the time, robot's autonomy will be very low. By default, the library turns off the motors when it has finished execute the requested movements. However, it is possible to keep the engines energized using mvBrake movement. This is useful if the robot has to stop on an incline.

Perrotti: Stepper motors are gluttonous little things

Agree completely.

However shutting them off runs the risk of outside interference causing a loss of position - the cat pushing the robot :)

This is the great advantage of a DC motor and worm gearing if precise positioning is not needed.


Well, in a not so far future I want my robot not only avoiding the cat, but also hunting him. :)

But seriously, the stepper motor has a small holding torque even with the coils off. So if there are no cats and in a flat floor, the robot can maintain its position. The library always stores the last pin configuration, so when the motors are turned on again, the cycle of steps continues where it left off.

But you're right, keep the engines running all the time makes more accurate movement and in some applications this may be necessary. On the other hand, a robot under development spends most of the time under test next to computer, so saving energy can be a welcome idea.

Perhaps there is a middle way, since I'm using chopper to lock the wheels, I can make a sort of fade, where the chopper begins with a long active period and slowly decreases along the time until it stabilizes in a short value and then eventually shuts down.