Ball and Beam Balance Final Report

Tom Trapp and Wil Selby

Department of Mechanical Engineering
Massachusetts Institute of Technology
2.151 Advanced System Dynamics & Control
Fall 2009

Abstract
The primary objective of this project was to create a control system that could effectively
balance a ball on a metal beam using a motor input to control the angle of the beam. This project
covered the full scope of design including creating a valid model of the system, identifying
numerical values for the model parameters, designing an effective control system, assembling the
system hardware, and implementing the control system using a microcontroller to interface with
the motor. The ball and beam balance problem is a classic open loop unstable system. For a
constant input there is a non-constant output. In this system, a constant beam angle causes the
ball to accelerate due to the force of gravity and the ball’s position increases non-linearly.
Investigating this system resulted in numerous insights of control design that can be applied to
multiple applications. Utilizing full state feedback, the controller was able to repeatedly and
effectively balance the ball at the given desired reference point with reasonable transient
performance. In the future, the addition of a Kalman filter for state estimation and a LQR based
controller could make the system even more effective.

I. Introduction
The ball and beam balance system is one of the most popular laboratory controls design
experiments because it is very simple to understand and can be used to study the implementation
of classical and modern control techniques. The system is fairly straightforward. A motor is
attached to the beam in a way that the shaft of the motor can control the angle of the beam. This
is usually done with the use of a lever arm attached to the end of the beam or with the motor
shaft connected directly to the center of the beam. For ease of assembly and troubleshooting, it
was decided to directly couple the motor shaft at the center of the beam. Once assembled, the
motor and beam angle are used to move a ball placed on the beam to a desired position.
Feedback usually comes in the form of an encoder to measure the motor position and a resistive
wire or acoustic sensor to detect the ball’s position on the beam.
While the system doesn’t require any complex assembly, the tools used to evaluate and
control the system can be advanced and applied to other more complex systems. The ball and
beam balance is a safe way to investigate control design for unstable systems. The ball and beam
system is open loop unstable since for a given constant angle of tilt on the beam, the ball’s
position changes without limit. Therefore, some form of feedback loop must be used to control
the ball’s position. While the ball and beam system is not a model of a real system, its dynamics
are similar to some of the most challenging areas of modern control. The dynamics of the ball
and beam system are specifically similar to aerospace systems such as the control of vertical
thrust in rockets or vertical take-off aircraft. The angle of the thrusters must be constantly
controlled in order to keep the rocket or aircraft moving in a constant direction. Unstable systems
are also seen in the chemical process industries in exothermic reactions. As the chemical reaction
 occurs, heat is produced. However, the heat also increases the rate of the reaction so some form
of control is needed to stabilize the reaction process. Many other areas of industry have similar
open loop unstable control problems, which makes the study of the ball and beam balance
relevant.

II. System Model

A simple depiction of the ball and beam balance system can be seen in Figure 1.

Figure 1: Ball and Beam System Model

The ball’s position is measured relative to the center of the beam with positive displacement to
the right of center. Therefore, when control was implemented, the final desired ball position was
at x=0. Also, beam angle (theta) was defined with positive theta being produced by a counter
clockwise displacement of the beam. Since the motor is directly coupled to the center of the
beam, the motor position angle and the beam position angle are identical. To make the system
easier to troubleshoot, a ball was replaced with a spool that matched the width of the beam. This
forced the spool to only move in the x direction.
For this system, the model was developed using two separate transfer functions and then
combining them for a full system transfer function. First, a transfer function for the ball and
beam was derived relating an input of theta to a ball position x. The complete derivation can be
seen in Appendix 1 and the final transfer function is shown in Equation 1 below. The ball and
beam dynamics are nonlinear in nature, however, using a small angle approximation, the
dynamics can be linearized and form the equations below.

X(s) msg
=
θ (s) ⎡ J s ⎤ 2
⎢⎣ms + l 2 ⎥⎦s
Equation 1: Ball and Beam Transfer Function

The variables are defined as:

ms = mass of the spool €
J s = inertia of the spool
l 2 = effective rolling radius (distance from the spool center to the point of contact with the beam)
g = gravity
€
€ This transfer function contains a double integrator which places two poles at 0. This is clearly an
€
unstable system. The transfer function is represented in state space form in Equation 2 below.
€

2/28
 ⎡ 0 ⎤
⎡x˙ ⎤ ⎡0 1⎤ ⎡x⎤ ⎢ msg ⎥
⎢ ⎥ = ⎢ ⎥ ⋅ ⎢ ⎥ + ⎢⎡ ⎤⎥θ
⎣x˙˙⎦ ⎣0 0⎦ ⎣x˙ ⎦ ⎢⎢ms + J s ⎥⎥
⎣⎣ l 2 ⎦⎦
⎡x⎤
Y = [1 0] ⋅ ⎢ ⎥
⎣x˙ ⎦
€ Equation 2: Ball and Beam State Space Model

Next, a transfer function relating a motor voltage input to motor/beam position theta was derived.
The full derivation can be referenced
€ in Appendix 2. The transfer function is reproduced below
in Equation 3.

θ ( s) Kt
= 2
V ( s) s J sysR + sK t 2
Equation 3: Motor System Transfer Function
The variables are defined as:
K t = motor torque constant
€ ball, beam, and motor system
J sys = moment of inertia of the
R = armature resistance
€ The transfer function was then rewritten in state space form as shown below in Equation 4.
€
€
⎡θ˙⎤ ⎡0 1 ⎤ ⎡ ⎤ ⎡ 0 ⎤
2 θ
⎢ ˙˙⎥ = ⎢0 −K t ⎥ ⋅ ⎢ ⎥ + ⎢ K t ⎥V
⎣θ ⎦ ⎢⎣ ⎥ ˙ ⎢ ⎥
J sysR ⎦ ⎣θ ⎦ ⎣ J sysR ⎦
⎡θ ⎤
Y = [1 0] ⋅ ⎢ ˙⎥
⎣θ ⎦
€ Equation 4: Motor System State Space Model

These two systems were combined to compute an overall transfer function that related a motor
€ position. The transfer function can be seen in Equation 5 as
voltage input to an output of ball
well as its state space representation in Equation 6.
X ( s) msgK t
=
V ( s) ⎡ J ⎤
[
s3 ⎢ms + 2s ⎥ sJ sysR + K t
⎣ l ⎦
2
]
Equation 5: Ball, Beam and Motor System Transfer Function

3/28
 ⎡0 1 0 0 ⎤
⎡ x˙ ⎤ ⎢0 msg ⎥ ⎡ 0 ⎤
0 0 ⎥ ⎡ x ⎤ ⎢ ⎥
⎢ ⎥ ⎢ ⎡ J s ⎤ ⎢ ⎥ 0 ⎥
⎢ x˙˙⎥ = ⎢ ⎢⎣ms + l 2 ⎥⎦⎥ ⎢ x˙ ⎥ ⎢
⎥ ⋅ + ⎢ 0 ⎥V
⎢θ˙⎥ ⎢0 0 0 1 ⎥ ⎢θ ⎥ ⎢ K t ⎥
⎢ ˙˙⎥ ⎢ −K t ⎥ ⎢⎣θ˙⎥⎦ ⎢ J R ⎥
2
⎣θ ⎦ ⎢0 0 0 ⎣ sys ⎦
⎢⎣ J sysR ⎥⎦
⎡ x ⎤
⎢ ⎥
x˙
Y = [1 0 0 0] ⋅ ⎢ ⎥
€ ⎢θ ⎥
⎢ ˙⎥
⎣θ ⎦
Equation 6: Ball, Beam and Motor System State Space Model

The complete system allows us to combine the dynamics into one transfer function as
€ This is a four state system with the states being ball position and
well as one state space system.
velocity as well as beam angle and velocity. This model uses voltage as an input instead of
current because the microcontroller outputs a voltage command to the motor. This made it
straightforward to implement the controller later in the project. Using a voltage command input
to the system, the ball’s position could be controlled.
Before designing a controller, it was necessary to get numerical values for the parameters
of the model. As mentioned previously, a spool was used instead of the traditional ball in order
to ease troubleshooting of the system. For the model, it was necessary to find the inertia and
mass of the spool as well as the spool’s effective rolling radius. The complete derivation of these
numbers can be referenced in Appendix 3. The mass of the spool was 9.4 g, the inertia was 9.06
mg-m^2, and the effective rolling radius was 1.46 cm. Gravity was taken as 9.8 m/s^2. For the
motor system, the motor torque constant was listed in the motor data sheet (Appendix 4) as
.0332 N-m/A and the armature resistance was listed as 25 Ohms. Lastly, the inertia for the entire
system was calculated. The motor and gearbox inertias were listed on the data sheet in Appendix
4. The beam inertia as well as the tilt sensor inertias were calculated as can be seen in Appendix
3. The final system inertia was 3.7994e-07 kg-m^4. With these values calculated, the model was
complete and a controller was designed. The final open loop system had the transfer function and
state space values shown in Equation 7 below.

X ( s) 6207.0014
=
V ( s) s3 (s + 116)

⎡ x˙ ⎤ ⎡0 1 0 0 ⎤ ⎡ x ⎤ ⎡ 0 ⎤
⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ ⎥
⎢ x˙˙⎥ = ⎢0 €0 1.7758 0 ⎥ ⋅ ⎢ x˙ ⎥ + ⎢ 0 ⎥V
⎢θ˙⎥ ⎢0 0 0 1 ⎥ ⎢θ ⎥ ⎢ 0 ⎥
⎢ ˙˙⎥ ⎢ ⎥ ⎢ ˙⎥ ⎢ −3 ⎥
⎣θ ⎦ ⎣0 0 0 −116.0426⎦ ⎣θ ⎦ ⎣3.4953 ×10 ⎦

4/28
 ⎡ x ⎤
⎢ ⎥
x˙
Y = [1 0 0 0] ⋅ ⎢ ⎥
⎢θ ⎥
⎢ ˙⎥
⎣θ ⎦
Equation 7: Numerical Ball, Beam and Motor Model

After finalizing the model, the appropriate sensors and actuators were chosen in order to
provide the input to the system€ and measure the desired states for use in the control feedback.
The motor was chosen because it had ample torque to drive the system without limitation but yet
did not draw more load current than the motor control board could provide. To sense the ball’s
position a PING acoustic range finder was used. Specific details about this device can be seen in
Appendix 5. Lastly, a method to determine the beam angle was needed. Initially, the motor
encoder was used to determine the motor position. In order to measure the angle exactly, every
encoder count needed to be logged. Unfortunately, the microcontroller had problems reading in
the encoder data accurately so the motor encoder could not provide the accuracy needed for the
control loop. Instead, a tilt sensor was placed on the beam to accurately measure the angle. This
sensor provided a voltage from 0 to 5V that could be used to calculate the beam angle very
accurately. As seen in the data sheet in Appendix 6, the specific formula (Equation 8) was non
linear. The angle was in degrees and the offset was the motor voltage when the sensor was level.
This was experimentally determined to be 2.4V. This sensor supplied very accurate angle
measurements and the microcontroller resolved the signal to approximately .4% (1÷256).
⎛ V − Offset ⎞
angle = arcsin⎜ out ⎟
⎝ 2 ⎠
For design simplicity, our model assumed that both sensors had perfect dynamics and
responded instantly. In practice, our final sensor suite proved to be very reliable and accurate and
the control routine was limited by the microprocessor speed more than the sensor dynamics. The
derivative states were found€by taking the derivative of the sensor measurements of ball position
and beam angle respectively. Future work on this project could include an observer or estimator
system to provide more accurate values for these states.

III. Controller Design

The first step in designing an effective control system for this system was to analyze the
open loop response. The complete MatLab code can be seen in Appendix 7. As described
previously, the system is open loop unstable and for our model, the root locus of the system is
shown below in Figure 2.

5/28
 Figure 2: Ball and Beam Balance Open Loop System

This system is clearly unstable as two poles move from 0 to the right half plane as K is
increased. Feedback control is necessary to place all poles in the left half plane of the root locus
plot. Two separate control strategies were investigated for this project. A full state feedback
controller using state space design methods was utilized for this project. For the transient
performance, the system was desired to have a response of 0.8 seconds settling time, less than
4.33% overshoot, and 0% steady state error. The controllability and observability matrices were
also calculated and both had full rank as well. This proves that the system is completely state
controllable and state observable.
By examining the root locus, it is evident that a pure proportional controller will not be
able to control the system. Instead, a full state feedback controller was utilized. This had several
advantages over classical control techniques. Primarily, state space design allows for specific
pole placement which makes designing a controller for specific transient response much easier.
Also, with the knowledge that this controller would be implemented utilizing a microcontroller,
using full state feedback allowed for easier implementation as well as tuning of the specific
gains. Lastly, given the fact that our sensors could read ball position and beam angle accurately,
it was thought that computing the translational and angular velocities derivatively would be
reliable in the absence of an observer or estimator. Using state space methods also allowed for
the investigation of optimal control methods to determine the gain matrix, however this approach
was not utilized in this project.
Using the A,B,C, matrices listed in Equation 7 as well as 0 for the D matrix, the ‘place’
command in MatLab calculated the gains of the K matrix. With the design requirements listed
above, the dominant poles were calculated to be −5 ± 5 j . Since the system is fourth order, two
other poles had to be specified. These were chosen as -20 and -60 so that these poles would have
little effect on the overall system response. With these desired poles, the K matrix was [9.6665
2.5777 0.5865 -0.0075]. These poles were checked by finding the eigenvalues of the closed
loop A matrix, A-B*K. The eigenvalues € matched the desired pole locations, so the gains were
validated.
Next, the closed system was simulated with a step response to determine the transient
response. For this system, a step response physically would be to place the ball at the center of
the beam with no control being applied to the motor. The step input would be forced by changing
the desired ball position from 0 to 1 unit away. For simulation purposes, a step of .05m was

6/28
applied to the system. A plot of the step response is shown below in Figure 3 as well as the block
diagram used for simulation in Figure 4.

Figure 3: Full State Feedback Step Response

Figure 4: Ball and Beam System Simulink Diagram

As evident by the response in Figure 3, the design meets the overshoot requirement, but
the settling time is about 0.1 seconds too slow and there is significant steady state error. While
we did place the dominant poles to match our desired response, the other two poles placed
farther down the real axis do have a slight effect on the system response. Therefore, the dominant
poles were moved to −6 ± 6 j to compensate for the effect of the other poles and to reach the
original design specs. When this system is simulated, there is still extensive steady state error,
but the overshoot is 3.73% and the settling time is 0.769 seconds, both within the original design
specifications.
€ For this set of desired closed loop poles, the K values were [13.9198 3.2479
0.6386 -0.0069]. The combination of these gain and the previous set created a window of

7/28
performance that was useful when the controller was tuned later in the project. To validate the K
values, a quick LQR command was done in MatLab which produced K values very close to the
ones found with the ‘place’ command.
Next, it was necessary to implement a reference input gain to eliminate the steady state
error of the system. In classical control, the output is compared to the reference input in a
summing junction to compute an error signal that is then fed into the compensator. However, as
evident by the block diagram in Figure 4, full state feedback multiplies each of the states by a
gain value which can’t be compared to the reference input. To solve this, a reference input gain
called the feedforward gain (Nbar) is calculated to scale the reference input and make it equal to
K*x_steadysate. For this model of the system, the value of the feedforward gain is always the
value of the position state gain. With the feedforward gain placed in the model, as seen in the
Simulink diagram in Figure 4, the step response (Figure 5) has a steady state value of .05 and the
steady state error has been eliminated.

Figure 5: Step Response With Feedforward Gain

Once satisfied with the step response transient response, the control output was plotted to
make sure that the motor would not be saturated. The maximum motor voltage is 12V and as
evident by the plot below, the maximum voltage required by the control system is around 1V,
well under the motor limits.

Figure 6: Control Output to Step Response

8/28
IV. Results from Simulations and Experiments
With the controller effectively designed in simulation, it was necessary to implement the
gain values found into the physical system. To do this, the Arduino microcontroller board was
used with a motor shield. Pictures of these devices can be seen in Appendix 9. Using a
microcontroller allowed for easy tuning of the gain values and offered more flexibility compared
to an analog controller. The Arduino was also interfaced with the tilt sensor and the PING
rangefinder to read in the state values of ball and beam position. The final code used to run the
controller can be seen in Appendix 8 and a simplified schematic shown below in Figure 7.

Figure 7: Hardware Schematic

There were several issues that had to be overcome when implementing the controller.
Primarily, the motor encoder would not give reliable motor position measurements. The encoder
was a quadrature encoder which outputs two out-of-phase square waves. By reading the values
of the two waves when one wave went from high to low, it was possible to tell the direction that
the motor was spinning and how many revolutions the motor had completed. In order to be
accurate, every change from high to low had to be counted. Traditionally, this is done in software
using an interrupt which monitors the signal and runs user specified code when a change is
detected in the encoder output. When implemented, it appeared that the interrupt was being
triggered at various times, seriously degrading the accuracy of the encoder measurement. This
also proved to be more inconsistent as the motor speed was varied. Since the control output
would command the motor to operate at various speeds, the encoder data could not be reliable.
After further investigation, it was believed that it was necessary to debounce the signal or that
the encoder itself was malfunctioning. The concept behind debouncing is simple. When the state
of each signal changes from high to low, it does not do so instantaneously. Instead, there is some
time constant where the voltage ramps from low to high voltage or vice versa. Digitally, a value
below a certain voltage is interpreted as a 0 and a voltage above a certain threshold is given a
value of 1. However, when the voltage is in the area between those thresholds, the computer
can’t decide if the value is a 1 or 0. The solution is to wait some small amount of time from the
instant the change is detected to confirm that, for example, the change from low to high did
result in a high value and wasn’t just noise in the signal. This strategy was attempted, but since
every change had to be detected, a delay in the reading of the signal caused changes to be missed
and accuracy sacrificed. The solution was to use a tilt sensor to measure the beam angle which
performed very well.

9/28
 To measure the ball’s position, the PING rangefinder was used as mentioned previously.
Several limitations of this sensor had to be overcome as well. Initially, the plan was to use the
full length of the beam, about a meter. Unfortunately, the geometry of a spherical object resulted
in a range of about half that distance. Attempts to use a golf ball or other objects did not improve
the sensor range dramatically. Therefore, the rangefinder was moved to a position halfway
between the beam end and beam center. The PING could identify objects this distance with no
obstructions. However, when the ball passed the center of the beam, the rangefinder would lose
the ball. Instead, the PING was focusing on the coupling that connected the motor shaft to the
beam. The PING was then moved back to the end of the beam and the ball was prevented from
moving past the center of the beam. This was the final configuration of our set-up and once this
was implemented, the PING had no trouble identifying the ball on the beam.
Once the hardware issues were overcome, code had to be written in the Arduino syntax to
read in the sensor signals, compute the control output, and send it to the motor. Interpreting the
Arduino syntax and unique functions created a small learning curve, but implementing the code
in a modular fashion helped the debugging process. The tilt sensor was read in as an analog
voltage which the Arduino converted to a number from 1 to 256. This then had to be converted
back into a voltage and converted to an angle using the previously mentioned formula. The PING
rangefinder sent back a digital pulse whose width corresponded to the distance to the target. That
time duration along with the speed of sound was used to compute the range in centimeters.
Specific details can be seen in the datasheet in Appendix 5.
The next issue that had to be addressed for the use of full state feedback was state
estimation. Instead of designing an observer, it was decided to compute the time derivative of the
positions to find the state velocities. This was much easier to implement while learning how to
effectively code in the Arduino environment, however, accuracy was probably sacrificed. As
evident in the code, the position outputs from the sensors were filtered and then divided by the
control sample time to determine velocities.
Once all states were measured, the control calculation could be computed. One advantage
of full state feedback is the ease of implementation in software. For classical control, the
compensator must be converted to the z domain and then a difference equation would need to be
computed to compute the motor input. Any change in the compensator results in rederiving the
difference equation. Full state feedback allows simple edits since only the gain values themselves
are changed. Each gain is multiplied by its specific state and the sum is the motor control value.
In the Arduino environment, the motor is controlled by a pulse width modulated signal. Thus, the
control output had to be converted to a PWM signal by the conversion 255/12 (counts/volts)
which gives the PWM controller a duty cycle percentage.
Lastly, timing issues had to be sorted out to get the code to run effectively. Initially, the
code was designed to run at 100Hz. Using the onboard timer, the time to run the code was
calculated and then a delay was used to hold the routine until the desired sample time was
reached. Initially, serial communications were used to print the values of the states and the
control commands to a console. This caused the control routine to run much slower, about 10 Hz.
The control routine could not respond fast enough to the system and the system was unstable.
When the output commands were deleted, the control routine ran at the desired frequency and the
control routine was able to stabilize the system.
As mentioned previously, the additional closed loop poles resulted in less than desired
transient performance. The dominant gains were modified to create a K matrix that performed to
specifications in simulation. Using the two pairs of K values as guidelines, the controller was

10/28
tuned until a desired stable response was achieved. Using the initial state of K values resulted in
an unstable closed loop system. The main reason for this inaccuracy was probably due to
modeling errors. While our model included numerical values, the values from the data sheets
were not experimentally measured. Probably the largest error of the model was due to the
backlash in the motor gear head. However, slightly tuning the gains made a responsive closed
loop system. In the end, the final K values were [10.7 3.5 5 -.1]. The only major modification
was the value of the beam angle gain. Again, backlash in the gears likely caused some errors.
These were reflected as a discrepancy between the simulated K value for beam angle and the
final effective value.
Observing the system as it responded to various disturbances or step responses, it was
clear that while the system was very sensitive to slight changes in the K values, the system
performed well once tuned. While the initial design specifications were overly optimistic for a
system with no observer and only basic pole placement control techniques, the system performed
well. Figure 8 shows the results of an experimental step response.

Figure 8: Experimental Step Response

The desired reference position was 18 cm away from the ping sensor. Starting the spool
at .22 cm resulted in the same step input as the .05 cm step applied in simulation. In this specific
example, the transient performance had 2.9 seconds settling time, 40% overshoot and -16%
steady state error. Clearly this does not meet our design requirements, but the system does
balance the ball around the reference point and forms a stable closed loop system. Specifically,
the steady state error is most likely due to unmodeled friction in the system. There is friction
between the spool and the rail which was not modeled in the system and prevents the ball from
moving at very small beam angles. Also, there is internal friction in the motor and gear head
which was not modeled. The motor requires a certain minimum voltage in order to turn the shaft.
To fix these errors, the model could be improved. Additionally, an integral term that continually
sums the ball position and beam angle error could be used to eliminate some steady state error.
Our model also has been linearized around small angles of theta. For some observed responses,
the beam angle reached 30 degrees which could invalidate the small angle approximation made
in the model and make the control scheme less effective. To view the relative robustness of the
controller, please view the attached videos which show a step response (BBB_step.mov) as well
as disturbance rejection performance of the control system (BBB_distrurbance.mov). During all
of our experiments with the system, the motor voltage never exceeded 8V. This means that our

11/28
controller was never saturating the motor and that it would be possible to increase the gains for
increased performance in the future.

V. Conclusions and Recommendations

The ball and beam balance system is a very interesting one to study. The indirect control
of ball position through control of the beam angle is fascinating to implement. Although
constructing and troubleshooting the prototype was very time-consuming and we were unable
due to time constraints to explore more advanced control algorithms, the project gave us great
experience in hardware implementation of digital control. There is a very clear distinction from a
simulation being successful and the physical system being successful. It was very beneficial to
go through the entire design process from modeling to simulation and implementation. This gave
us a greater understanding of what was happening physically in the system and aided the
debugging process. Also, the more advanced control concepts are much easier to envision after
successfully implementing full-state space control on this system. Adding gains calculated
through LQR or other optimal control methods would be straightforward. Implementing an
observer using the Arduino would require more software engineering research but is feasible.
The main problem that lingers is the inability to use the installed motor encoder. We suspect that
the problem is not with the encoder but the incorrect use of the microcontroller interrupts or
possibly an issue of signal conditioning. Due to the requirement to detect every signal change, it
was difficult to diagnose the specific issue with the encoder. For future study, this should be
resolved. Also, although the gains we used for the final trial worked very well, the system does
not seem to have the robustness or the repeatability expected from full-state space control.
Perhaps there are significant unmodeled system or sensor dynamics that need to be explored.
Overall, it was a very rewarding project and definitely adds intuition to the concepts learned in
the course and launches us into more advanced areas of control systems design.

12/28
References
“Control Tutorials for MatLab and Simulink.” University of Michigan Engineering. Nov.
2009. < http://www.engin.umich.edu/class/ctms/>.

Evanko,David, Arend Dorsett and Chiu Choi, Ph.D., P.E., “A Ball-on-Beam System with
an Embedded Controller.”American Society for Engineering Education. University of North
Florida, Department of Electrical Engineering. Mar. 2008
<http://www.loyola.edu/betasites/cas/midatlanticasee/publications/march2008/documents/ASEE
12008_0012_paper.pdf>.

Lieberman, Jeff. “A Robotic Ball Balancing Beam.” 10 Feb. 2004. <

bea.st/sight/rbbb/rbbb.pdf>,

Rosales, Evencio A. “A Ball-on-Beam Project Kit.” Undergraduate Thesis,

Massachusetts Institute of Technology, June 2004.

List of Project Tasks

System modeling and simulation – Wil 80%, Tom 20%
Prototype construction and troubleshooting – Tom 80% Wil 20%
Controller implementation and troubleshooting – Wil 50% Tom 50%
Report and presentation Wil 50% Tom 50%

13/28
 Appendicies
1. Ball and Beam Transfer Function and State Space Derivation

∑ F = m gsin(θ ) − F
s s r = ms x˙˙ where x = al
∑τ = F l = J a˙˙
s r s

J a˙˙
msgsin(θ ) − s = ms x˙˙ €
€ l
J s x˙˙
€ msgsin(θ ) − ⋅ = ms ˙x˙
l l
⎡ J ⎤
€ msgsin(θ ) = x˙˙⎢ms + 2s ⎥
⎣ l ⎦
msgθ
€ Using small angle approximation where sin g(θ ) = gθ leads to the equation = x˙˙
⎡ J s ⎤
⎢⎣ms + l 2 ⎥⎦
€
Then the transfer function relating ball position X ( s) to an input beam angle θ ( s) is
X(s) msg €
=
θ (s) ⎡ J s ⎤ 2
€
⎢⎣ms + l 2 ⎥⎦s
€ €
⎡ 0 ⎤
⎡x˙ ⎤ ⎡0 1⎤⎡ x⎤ ⎢ msg ⎥
Represented in state space as ⎢ ⎥ = ⎢ ⎥⎢ ⎥ + ⎢⎡ ⎤⎥θ
€ ⎣x˙˙⎦ ⎣0 0⎦⎣ x˙ ⎦ ⎢⎢ms + J s ⎥⎥
⎣⎣ l 2 ⎦⎦
Variables:
Fs = Force on the spool
ms= spool mass
g = gravity €
Fr = rolling force constraint on the spool
€ x = spool position on the beam
€ τ s = torque on the spool
€ l = distance from ball center axis to rail
€ a = angular displacement of spool
€
J s = moment of inertia of the spool
€
€
€
€

14/28
 2. Motor System Transfer Function and State Space Derivation

Vm − Vemf Vm − K w
Im = and Vemf = K w so Im =
R R

Using the block diagram:

€ K t Im K w
€ Vm − Vemf Vm − J € = Vm − K Im when K = K
2
Im = = w t
R R R JRs
K 2 Im
sIm R = sVm −
J
2
€ K €
Im (sR + ) = sVm
J
Im (s) s θ (s) K θ (s) K
€ = 2 and = 2 then = 2 and in state space form as
Vm (s) K Im (s) Js Vm (s) s JR + K 2
sR +
€ J

⎡θ˙⎤ ⎡0 1 ⎤ ⎡ ⎤ ⎡ 0 ⎤
€2 θ €
⎢ ˙˙⎥ = 0 −K t ⎥ ⋅ ⎢ ˙⎥ + ⎢ K t ⎥V
⎢
€ ⎢ ⎥
⎣θ ⎦ ⎣ J sysR ⎦ ⎣θ ⎦ ⎢⎣ J sysR ⎥⎦
⎡θ ⎤
Y = [1 0] ⋅ ⎢ ˙⎥
⎣θ ⎦
€
Variables:
K t /K w = motor constants
€ J sys = moment of inertia of the ball, beam, and motor system
R = armature resistance
Im = motor current
€
Vm = motor voltage
€
Vemf = back emf voltage
€
€
€
€

15/28
 3. Model Numerical Values

Specific values and the implementation of these formulas can be found in the MatLab simulation
code below in Appendix 7.

The spool was divided into 2 pieces, the web and the center cylinder. Using the following
equations, the numerical values for spool mass and intertia were calculated. Rrot is the distance
from the center of the spool to the point of rotation of the spool when it is on the beam. This is
used for the parallel axis theorem. The density of the plastic was 1.2 g/mL (PVC plastic)
1
(4
2
) 2
Volume = π dout − din ⋅ thickness €
Mass = ρ ⋅ Volume
1
( )
πρ ⋅ thickness dout 2 − din 2
€ J disk = 2
24
€ 2
J spool = J web + J hub + Massspool ⋅ Rrot

€ The beam was treated as 3 individual solid cuboids to find the moment of inertia
1
€ J = m( l 2 + w 2 ) and J beam = 2J side + J bottom
12

The inertia of the tilt sensor was also calculated:

1
€ J spool = m( l 2€+ w 2 ) + md 2
2
where l is the length, w is the width, m is the mass of the tilt sensor calculated from density and
volume as shown for the spool inertia equation above.
€ Finally, the system inertia was calculated
€ € €
J sys =
( J beam + J ts )
+ Jg + Jm
gear 2
where gear is the motor gear ratio and J g and J m are the motor and gear inertias listed in the
motor data sheet.
€
€ € €

16/28
4. Motor Datasheet

17/28
5. Ping Rangefinder Datasheet

18/28
19/28
20/28
21/28
22/28
6. Tilt Sensor Datasheet

23/28
24/28
25/28
26/28
7. MatLab Simulation Code

-Please see file BallandBeamSimulation.m submitted with the report.

8. Arduino Control Code

-Please see file Arduino_code.pdf submitted with the report.

9. Arduino and Motor Shield Pictures

27/28
28/28