Reverse Motorized Pendulum

Daniel Hurwit, Brad Fiore and Sam Green

The reverse motorized pendulum is the principle concept behind a working Segway. A gyroscope
coupled with unique software, allows a reversed motorized pendulum to remain constantly vertical. Any
change in angle of the body causes a signal to be sent to each of the wheels (controlled individually) to
roll either forward and backward to re-balance the model. By pushing the top of the device forward it
will cause the wheels to spin forward as well, to keep the body from tipping over. This project aims to
create a scaled model of the balancing components of a Segway.
The first step to the project's physical construction was to design the body of the model and have it 3D

CAD DRAWING

Printed. Figure 1 is the rendering of the body, wheels, and motor assembly. The motor assembly was
screwed into the body of the pendulum and the wheels were mounted on the hexagonal axles protruding

from the gearbox.

bands were glued around the wheels, in order to increase traction and prevent
1:1Rubber
SCALE

3D
MODEL

slipping. As shown in Figure 2, a 9V and 3 AAA batteries will be connected to the Arduino and circuit
board respectively.

Figure 1: 3D rendering of the model

EECE 2210 Final Project

April 18, 2014

The next step involved building the circuit. The main electronic components were the gyroscope, the
Arduino, the motor drivers, and the motors. After the circuit had been completed, the code for the
Arduino was written. The Arduino code involved extracting the angular velocity from the gyroscope and
determining the amount of power needed to push the pendulum back into the upright position. First, the
angular velocity was pulled in, in DPS (degrees per second). This, along with a time step of 50 ms, was
used to calculate the angular distance traveled over that time period. It was then added to the previous
angular position to find the new angle. This was the first variable used to find the power sent to the
motors. The second variable was the amount of power based of the angular velocity already calculated.
The third and fourth terms of the total power involved conversion into linear velocity of the axle, along
with the distance traveled by the gyroscope. This code was not robust enough to finely balance the
robot.

Figure 2: Circuit diagram with batteries

However, in addition to the code, there are other aspects of the project that resulted in this imbalance.
First, the center of gravity was too low. The chassis was designed so all the weight would be low down.
This causes the robot to react violently to changes in power, and switch directions quickly, resulting in
EECE 2210 Final Project
April 18, 2014

the robot's aggressive over-correction of position. Secondly, the Arduino maxes out at 20 calculations
per second, and that combined with our basic integration method resulted in a delayed calculation of
position causing constant over-correction and increased imbalance. The large loop time caused
integration drift thus shifting the reference point of zero degrees. This causes a degradation of balance
over time. Finally, the gyroscope produced a considerable amount of noise. To correct this, a noise
reduction factor was written into the code. While this increased the accuracy of the gyroscope, it
decreased the sensitivity to small angle changes.
For future improvements, the first step would be to make a more accurate software algorithm. This could
be done using a PID (proportional-integral-derivative) algorithm. This is essentially an error calculation.
Using the past and present input values from the gyroscope, this algorithm can calculate the future
position of the robot. This is called predictive correction, and would make the robot much more
balanced. It would eliminate the teetering that happens when the robot is very close to the zero point,
and would also eliminate the over-correction, which causes the robot to fall. The next improvement that
could be made would be to swap the current motors with stepper motors. Since the stepper motor acts in
degrees per step, the movement would be much more accurate. Additionally, an encoder could be
attached to the stepper motor. This would count the steps the motor has taken, and can account for
slippage in the motor. This would eliminate almost any error coming from the motor. Finally, a
bluetooth module could be attached to the Arduino board. Then, a user interface could be written and the
robot could be controlled via a computer or smartphone, like a radio-controlled car.

EECE 2210 Final Project

April 18, 2014