Differential Drive Mobile Robot

From Mech
Revision as of 15:53, 15 March 2010 by JakeWare (talk | contribs)
Jump to navigationJump to search


The goal of this project was to create a low cost replacement for the popular E-Puck robot that was better suited to the needs of the current research projects here at Northwestern. The project also entailed developing a control library that would allow future users to easily interface with the robot and integrate it into their research. Specifically, the robot was to meet the following criteria:

Mechanical Goals:

-Be of a similar size to the E-Puck

-Be significantly less expensive than the E-Puck

-Use stepper motors

-Be easy to manufacture

-Have an approximate run time of 1 hour

Software Goals:

-Use the NU32 board for control logic

-Support wireless communication

-Develop a control library that can easily be included in a users code

-Allow the user to specify a velocity vector for the robot to follow

-Allow the user to specify the robot's position, (x,y,theta), in a global frame

-Allow the user to directly control the robot's wheel speeds


As previously stated, the robot needed to be easy to manufacture, inexpensive to make, and relatively small. These three goals guided each decision made in the mechanical design. The following sections will outline the design process for each mechanical component.


The motor choice was the most significant design decision in this project. Accordingly, much thought and research went into picking the hybrid stepper motors we ended up with. The stepper motor used in this project is a NEMA 17, bipolar (4 wire), hybrid stepper [link].

Mobile Robot - Stepper Motor.jpg

Standard Size:

Very early in the motor search, it was decided that because this project was to be the foundation of future work, finding a motor that was readily available was a top priority. It quickly became clear that using a stepper motor that followed NEMA's motor standards would accomplish this. In doing so, any future project or research group that decides to use this project as a starting point will not need to locate the exact motor used here, but only a size 17 NEMA stepper motor.

Hybrid Stepper:

Although there are many types of stepper motors, we decided to use the hybrid stepper motor for this project. Aside from the fact that hybrid stepper motors are the most common type, they also have a higher resolution compared to a standard permanent magnet stepper motor. Both wikipedia and NMB's website have some good resources on stepper motor theory and operation.


Although there are several possible winding configurations stepper motors can take, we chose a bipolar motor. This configuration demands the use of an H-bridge in the driving circuit, but allows for higher torque than a unipolar configuration.

No Gearhead:

The decision not to use a gearhead was a significant departure from the design of the E-puck. Although a gearhead allows for lower current draw, smaller motors (lighter robot) for any given torque, the gearheads themselves are often composed of fragile plastic components that break easily. Another drawback of geared stepper motors is their higher cost. The benefits and drawbacks of our decision are evident in the final design through its significantly higher weight and improved top speed.


An average hybrid stepper motor from an established supplier like NMB, Lin Engineering, or Annaheim Automation costs around $40. Although the motors purchased from these companies may provide superior performance, the motors used in this project were purchased from SparkFun for $13 each and provide enough torque to propel our hefty robot at four times the speed of an E-Puck.


The focus of the chassis design was ease of manufacture. In order to achieve this, the chassis (and wheels) was designed so that it could be cut out of a single sheet of acrylic and simply glued together. The acrylic used came from McMaster-Carr and can be found here. In order to minimize the amount of acrylic needed, it was assumed that the circuit board would act as the top of the robot and the front and back were left as short as possible without compromising strength. The final chassis dimensions are W:90mm, L:90mm, H:75mm. As can be seen below, the batteries rest on the motors themselves, and, therefore, do not require any additional mounting structure.

The following is an image of the SolidWorks assembly of the robot:

Mobile Robot - CAD.jpg


In order to allow for wheel size adjustments throughout the design and development process, the robot's wheels were made out of acrylic and cut on the laser cutter. The center hole was cut to have a 0.005" clearance so that the motor shaft would fit snugly and act to center the wheel. These shaft collars were super glued to the acrylic wheel and used to fix the wheel to the shaft.

Note: If you are going to cut your own wheels on the laser cutter be mindful that the laser has a tendency to taper the edges of the wheels and does not cut a perfectly round circle due to the resolution of the carriage.


Because the robot has two wheels, it needed supports on both the front and back to prevent it from rocking back and forth or scraping the chassis on the floor. These casters were used in order to reduce friction and allow for simple shim height adjustment.

Note: Although the stainless steel ball in these casters will last longer, they make quite a bit of noise rattling around in their cage. The solution to this would be either to have them perfectly shimmed so they no longer are able to move, or order the equivalent caster with a plastic bearing.

The SolidWorks CAD files can be found here.


circuit diagram

NU32 board

H-bridges L293D




code and description

Graphical User Interface

A GUI was created in processing in order to demonstrate the functionality of the control software and facilitate testing.

The following is an image of the GUI as it appears when it is first opened:

Mobile Robot - Processing GUI.jpg

Modes of Operation:

The program has two modes of operation that can be selected with the "mode" button.

Note: The current mode can be discerned by looking at the white/black box next to the mode button and comparing with the legend at the bottom of the GUI

First, there is a position control mode that allows the user to send the robot to a point in a global frame. This is done by clicking in the white box that takes up the majority of the screen space. Once designated, the new position will appear with a number above it which marks its order relative to all the other requested positions. The white area maps to the surface that the robot is sitting on, and the x-axis, which the robot is aligned with, goes to the right of the screen from the origin at the center. The y-axis originates from the same location and goes upward. Both the location of the origin on the screen and the physical dimensions of the space that the screen area maps to are easily adjustable in the code.

Second, there is a velocity control mode that allows you to specify a velocity vector that the center of the front face of the robot must follow. As before, this vector is created by clicking in the white box at the center of the GUI. The robot is, once again aligned along the x-axis, and the magnitude of the velocity vector is specified by the distance from the origin to the point clicked.

Some other features include the ability to:

-stop the robot with the "stop" button

-move the origin to the robot's current position with the "reset" button

-send the robot back to its starting position with the "home" button

-specify the robot's wheel speed with the "speed" textbox


You can download the processing project here.

Parts List

Insert List here

Future Work

new wheels


1 timer motor control

forward, reverse, rotate functions

other functions to shorten code


This project was created by John (Jake) Ware and Jarvis Shultz. Both are mechanical engineering PhD students at Northwestern University.


"Jarvis Schultz" <jarvisschultz2012@u.northwestern.edu>

"John Ware" <johnware2015@u.northwestern.edu>