eduMIP Report
eduMIP Report
eduMIP Report
Robert Ketchum
1
Abstract
The equations of motions of an eduMIP inverted pendulum were derived, and its system
equations linearized. MATLAB was used to derive the two transfer functions from the input
torque to the output pitch body angle and the pitch body angle to the output wheel angular
velocity, respectively. To have the eduMIP robot balance itself using only its motors, two
lead-lag compensators were designed with MATLAB utilizing the theory of successive loop
closure. These two controllers were converted to discrete-time and implemented in the system
using C-Programming Language. A video of the balancing robot can be viewed at:
https://tinyurl.com/eduMIP .
2
Table of Contents
Abstract ………………………………………………………………………………….……….1
Introduction ………………………………………………………………………………..…….4
The BeagleBone Blue eduMIP ………………………………………………………….………4
System Variables …………………………………………………………………....…….……..5
Engineering Assumptions ………………………………………………………….…………...6
Derivation of the Equations of Motion……………………………………….………………...7
Lagrangian Mechanics ……………………………………….……………...…..………..7
Newtonian Mechanics ……………………………………….…………..………………..9
Linearization of the Equations of Motion……………………….………..……………...10
Motor Characteristics and Control Inputs……………………….………..……….……..11
Controllable Linearized Equations of Motion …………………….…..………………...12
Single Input, Single Output Plant Equation Derivations………….……...……………...12
Linearized Continuous-Time Controller Design………………………………..…..………..14
Subsequent Loop Closure……………………………………………....………………..14
Inner Loop Overview………………………………………………………………….....14
Inner Loop Stability…………………………………………………………....….……..15
Inner Loop Controller Design ……………………………………....…………………...16
Outer Loop Overview……………………………………………………….…………...19
Outer Loop Stability…………………………………………………………...….……..20
Outer Loop Controller Design ……………………………………………...…………...21
Discrete-Time Controller Implementation………………………………..…………...……...25
Continuous to Discrete-Time--Tustin’s Approximation with Prescaling……………..…25
eduMIP Controller Implementation…………………………………………….………..26
BeagleBone Blue Software……………………………………………………………...……...27
Low-Level Software: C-Code Framework………………………………….…………...27
High-Level Software: State Machine………………………………….………………...28
Conclusion………………………………………………………………….…………………...29
Appendix A: References………………………………………...……………………………...30
Appendix B: MATLAB Code………………………………………..….……………………...31
Appendix C: BeagleBone Blue C-Code………………………………...……………………...42
3
Introduction
The system under study is an inverted pendulum robot. At first glance, this genre of robots are
not inherently useful due to their natural instability, and as such are not the most practical vehicle
design for fuel efficiency, stability, nor carrying capacity. Despite all of these obvious flaws, they
are a classic hardware choice for the study of control systems engineering. To be able to use
programming and math to keep the bot upright is to fly in the face of nature and stabilize a
system which by all intuition should topple over. In this sense, inverted pendulum robots are
proof of the importance of control system engineering and its use in understanding and
harnessing the power of the world around us.
𝐼
Figure 1: Coordinate axes of the eduMIP. The inertial frame is given by 𝑒 = and the body
𝑀
coordinate axes are: 𝑒 = [2]
5
System Variables
The variables used in the system are listed as follows [3]:
Variable Name
Symbol
θ Body pitch angle. 0° defines the body upright and perpendicular to the ground
φ Average wheel rotation angle. 0° defines the initial average wheel angles
𝑥 Translation in x-direction
𝑢 Ratio from the motor output torque and the stall torque. Also the controller output
𝑘 τ −6 𝑁𝑚
Motor constant ( ω 𝑠𝑡𝑎𝑙𝑙 ) 1. 7045 × 10 𝑠𝑒𝑐
𝑛𝑜 𝑙𝑜𝑎𝑑
𝑙 Length from the wheel center to the center of mass of the body 4.77 cm
𝑔 Gravity 9.81 𝑚
2
𝑠
Engineering Assumptions
In analyzing the system, we may make the following assumptions:
1) The two wheels spin at the same angular velocity
' ' '
2) The pitch angle is small, such that 𝑠𝑖𝑛(θ ) ≃ θ , 𝑐𝑜𝑠(θ ) ≃ 1
3) There are no forces in the lateral direction and no torques about the yaw or roll axis, so
the system is only in 2 dimensions
7
'
𝑑θ 2
4) The pitch angle deviation is not changing rapidly with respect to time, so ( 𝑑𝑡
) ≃0
5) The robot wheels do not slip and are instead stuck to the ground, so 𝐹𝑓𝑟𝑖𝑐𝑡𝑖𝑜𝑛= 𝐹𝑥
Lagrangian Mechanics
For systems where it is difficult to visualize all forces acting on bodies, one may find it easier to
use Lagrangian mechanics to derive the equations of motion. The process for deriving the
equations of motion for the eduMIP is given below [4] [5].
Note that there are two orthogonal components of 𝑣𝑏, decomposed in the inertial reference frame,
𝐼
𝑒 , as:
For our purposes, we only care about the magnitude squared of the body velocity:
𝑑𝑥 2 2 𝑑θ 2
||𝑣𝑏||2 = [ 𝑑𝑥𝑑𝑡 + 𝑙
𝑑θ
𝑑𝑡
2
𝑐𝑜𝑠(θ)] + [𝑙
𝑑θ
𝑑𝑡
𝑠𝑖𝑛(θ)]
2
= ( 𝑑𝑡 ) + 𝑙 ( 𝑑𝑡
) + 2𝑙
𝑑𝑥 𝑑θ
𝑑𝑡 𝑑𝑡
𝑐𝑜𝑠(θ)
The only potential energy in the system is the gravitational potential energy of the inverted
pendulum body:
𝑃𝐸 = 𝑙 𝑚𝑏 𝑔(1 − 𝑐𝑜𝑠(θ))
𝑑
𝑑𝑡 ( ) ∂(
∂𝐿
𝑑θ
𝑑𝑡
)
−
∂𝐿
∂θ
= − τ
Where 𝐹𝑥and T are the nonconservative through-variables representing the force on the wheels
by the ground and the torque on the body by the wheels, respectively.
The bot does not have sensors to determine its x-position. Rather, it uses motor encoders to
determine the wheel angle. We therefore must use the following relationship to convert the linear
position to the wheel angle: 𝑥 = 𝑟φ. Continuing the derivation:
2 2 2
𝑑φ 𝑑φ 𝑑θ 𝑑θ 2
𝑚𝑤𝑟 2 + 𝑚𝑏𝑟 2 + 𝑚𝑏𝑙 2 𝑐𝑜𝑠(θ) − 𝑚𝑏𝑙( 𝑑𝑡
) 𝑠𝑖𝑛(θ) = 𝐹𝑥
𝑑𝑡 𝑑𝑡 𝑑𝑡
The torque on the bot provided by the wheel motors is used to both spin the wheels and move the
2
𝑑φ
bot forward: τ = 𝐼𝑤 2 + 𝐹𝑥𝑟. Using this relationship, we obtain our first equation of motion:
𝑑𝑡
9
( )
2 2
2 𝑑θ 𝑑𝑥 𝑑𝑥 𝑑θ 𝑑𝑥 𝑑θ
𝐼𝑏 + 𝑚𝑏𝑙 2 + 𝑚𝑏 2 𝑙𝑐𝑜𝑠(θ) − 𝑚𝑏𝑙 𝑑𝑡 𝑑𝑡
𝑠𝑖𝑛(θ) + 𝑚𝑏𝑙 𝑑𝑡 𝑑𝑡
𝑠𝑖𝑛(θ) − 𝑚𝑏𝑙𝑔𝑠𝑖𝑛(θ)) = − τ
𝑑𝑡 𝑑𝑡
Again, using the wheel angle and linear motion relationship, we obtain our second equation of
motion:
Newtonian Mechanics
The Lagrangian derived equations of motion may be verified using Newtonian mechanics. These
derivations and the following linearizations are done in Examples 17.9 and 17.10 of Numerical
Renaissance, by Thomas Bewley [2].
The Kinematics equations of the body in the inertial frame are given by:
Rotating the reference frame by θ so that the reference frame is attached to the eduMIP body
yields:
Combining equations (1), (5), (7), and (9) yields the simplified equation for torque about the
wheels of the bot, which is our first nonlinear system equation:
Our second nonlinear system equation, the torque about the body of the bot, is obtained by
combining equations (3), (6), and (9):
Setting the average pitch angle, wheel angle, and torque as zero (θ = τ = φ = 0), the system
equations can then be written as follows:
11
Also, assuming that the pitch angle deviation is not changing rapidly with respect to time,
'
𝑑θ 2
( 𝑑𝑡
) ≃0
The general equation for a linear DC motor is: τ𝑚𝑜𝑡𝑜𝑟 = τ𝑠𝑡𝑎𝑙𝑙 − 𝑘 ω. This relationship is most
commonly displayed as a graph, as seen below in Figure 3.
The control input for the system, 𝑢, is the normalized ratio of maximum torque to each motor. As
1
such, it is bound by: − 1 ≤ 𝑢 ≤ 1, and takes the form of: τ𝑚𝑜𝑡𝑜𝑟 = 𝑢τ𝑠𝑡𝑎𝑙𝑙 − 𝑘 ω .
Accounting for both wheels and the gear ratio, the total torque on the robot by the motors is:
τ = 2α(𝑢τ𝑠𝑡𝑎𝑙𝑙 − 𝑘 ω).
________________________
1
It may seem that this motor command should account for the motor torque output rather than just the
stall torque, resulting in the incorrect control input equation: τ𝑚𝑜𝑡𝑜𝑟 =𝑢(τ𝑠𝑡𝑎𝑙𝑙 − 𝑘 ω). There are a few
reasons why this is not the case. For one, if the motor is operating at the no-load speed, such that
τ𝑠𝑡𝑎𝑙𝑙 = 𝑘 ω, a command may be sent to stop the wheels. The incorrect derivation does not allow for any
command in such a case. From a controller design perspective, a normalized command also allows for
easy controller design, as the same command tells the ratio of maximum motor torque, angular velocity,
voltage, and current.
13
The translation of the motor angular velocity to motion of the wheel and body angle is given by:
𝑑φ 𝑑θ
ω = α( 𝑑𝑡
− 𝑑𝑡
). The subtraction of the body angle accounts for the conservation of angular
momentum in the system, and is the key to why the system may be controlled at all.
Combining the two above motor equations gives an equation relating the wheel torque with the
𝑑θ 𝑑φ
dynamics of the body and the wheels: τ = 2α(𝑢τ𝑠𝑡𝑎𝑙𝑙 + 𝑘α 𝑑𝑡
− 𝑘α 𝑑𝑡
).
We must now take turns cancelling the body angle and wheel angle,Θ and Φ, respectively. To
simplify the algebra, the following variables will be used:
2 2 2
𝐴 = ⎡⎢𝐼𝑤 + (𝑚𝑏 + 𝑚𝑤)𝑟 ⎤⎥𝑆 + 2α 𝑘𝑆
⎣ ⎦
2 2
𝐵 = 𝑚𝑏𝑟𝑙𝑆 − 2α 𝑘𝑆
𝐶 = 2ατ𝑠𝑡𝑎𝑙𝑙
2 2
𝐸 = 𝑚𝑏𝑟𝑙𝑆 + 2α 𝑘𝑆
2 2 2
𝐷 = ⎡⎢𝐼𝑏 + 𝑚𝑏𝑙 ⎤⎥𝑆 − 2α 𝑘𝑆 − 𝑚𝑏𝑔𝑙
⎣ ⎦
𝐹 = − 2ατ𝑠𝑡𝑎𝑙𝑙
Solving for the body angle and the torque duty cycle:
𝐶𝑈−𝐵Θ 𝐹𝑈−𝐸Θ
Φ= 𝐴
= 𝐷
𝐴Φ +𝐵Θ 𝐷Φ +𝐸Θ
𝑈= 𝐶
= 𝐹
𝐶 𝐹
Θ ⎡ ⎤ 𝐴
−𝐷 𝐵𝑜𝑑𝑦 𝐴𝑛𝑔𝑙𝑒
𝐺1(𝑠) = 𝑈
=⎢ ⎥ = 𝑁𝑜𝑟𝑚𝑎𝑙𝑖𝑧𝑒𝑑 𝑀𝑜𝑡𝑜𝑟 𝐷𝑢𝑡𝑦 𝐶𝑦𝑐𝑙𝑒
𝐵 𝐸
−
⎣ ⎦ 𝐴 𝐷
𝐸 𝐵
Φ ⎡ 𝐹 − 𝐶 ⎤ 𝑊ℎ𝑒𝑒𝑙 𝐴𝑛𝑔𝑙𝑒
𝐺2(𝑠) = Θ = ⎢ 𝐴 𝐷 ⎥ = 𝐵𝑜𝑑𝑦 𝐴𝑛𝑔𝑙𝑒
⎣ 𝐶−𝐹 ⎦
15
𝐺1(𝑠)is our SISO plant equation relating the normalized torque of the motor to the body angle of
the eduMIP. 𝐺2(𝑠)is the plant equation relating the body angle to the wheel angle. Plugging in
the known values for our robot from Table 2, we obtain our final SISO transfer equations:
−882.7 𝑠
𝐺1(𝑠) = 3 2
𝑠 +44.15𝑠 −192.8𝑠−2299
2
−1.476𝑠 +128.9
𝐺2(𝑠) = 2
𝑠
Note that these values were computed in MATLAB. The code for these transfer functions, as
well as the full design of the controllers, including plots, is given in Appendix B.
Linearized Continuous-Time Controller Design
1 -47.206 0
2 -5.617 None
3 8.670 None
These poles and zeros are better visualized on a Root Locus plot, seen below in Figure 5. The
three poles are shown as crosses, and the single zero is shown as a circle. A simple positive
increase in feedback to the system will not improve stability, as shown by the green line
diverging positively from the unstable pole. As the system’s zero is on the imaginary axis, a
simple negative gain will still result in the system still having a positive pole. Additional poles
and zeros are therefore needed to stabilize the system.
17
Figure 4: Root Locus Plot of Inner Loop Plant 𝐺1, where the crosses represent poles and the
circle represents the single zero. The system is clearly unstable.
A generalized Lead-Lag compensator uses two zeros and two poles and takes the form:
(𝑠+𝑧𝑙𝑒𝑎𝑑) (𝑠+𝑧𝑙𝑎𝑔)
𝐷𝑙𝑒𝑎𝑑−𝑙𝑎𝑔(𝑠) = 𝐾 (𝑠+𝑝𝑙𝑒𝑎𝑑) (𝑠+𝑝𝑙𝑎𝑔)
Where 𝑧𝑙𝑒𝑎𝑑<𝑝𝑙𝑒𝑎𝑑 and 𝑧𝑙𝑎𝑔>𝑝𝑙𝑎𝑔 [7]. The poles and zeros were designed first, followed by the
gain 𝐾.
The following relationships were used to find the Lead Compensator pole and zero locations:
ω𝑐
𝑧𝑙𝑒𝑎𝑑 = , 𝑝𝑙𝑒𝑎𝑑 = ω𝑐 σ.
σ
𝑝𝑙𝑒𝑎𝑑
The ratio of the magnitude of the pole to that of the zero, σ = 𝑧 , was chosen to be 4. This
𝑙𝑒𝑎𝑑
provided a large frequency range over which the Lead Compensator was in effect, but was small
enough so that the Lead zero was spaced far from the Lag zero [7] .
18
The gain crossover frequency, ω𝑐, is the frequency at which the magnitude of the open loop gain
𝑟𝑎𝑑
of the system is 0 𝑑𝐵. This was chosen to be 10 𝐻𝑧 = 20π 𝑠𝑒𝑐
, as it was sufficiently slower
than the inner loop speed of 200 𝐻𝑧 such that the control system would not amplify high
frequency noise in the system.
The Lag Compensator utilized pole-zero cancellation to “replace” the zero at the origin with one
with a larger magnitude, thereby speeding up the system [7].
The chosen poles and zeros of the system are shown in Table 4 below:
The resultant system was able to be stabilized using the correct negative gain. A Root Locus plot,
seen in Figure 6, demonstrates that a gain of larger than 𝐾 = − 0. 6 will make all poles
negative, stabilizing the system.
Figure 5: Root Locus Plot of the Inner Loop System. Note that the Root Locus branches
demonstrated are those for negative feedback gain.
19
As our system utilized closed-loop feedback, the phase and magnitude of the gain may be used to
◦
check stability using Bode Plots. Of especial importance is ensuring that the phase is not 180
when the magnitude is at 0 𝑑𝐵, as this corresponds to an open loop gain of -1, or an undefined
closed loop gain [7].
The Bode Plot of the controlled inner loop system is given below in Figure 7. The gain of the
system was chosen to be 𝐾 = − 10. 5, as it provided a gain crossover frequency of
𝑟𝑎𝑑
ω𝑐 = 10 𝐻𝑧 = 20π 𝑠𝑒𝑐
. The resultant system was very robust, as it had a phase margin of
◦
47 and a gain margin of 24. 8 𝑑𝐵. This means that the gain could be decreased by 24. 8 𝑑𝐵 or
◦
the phase could be decreased by 47 before instability of the system.
With the chosen lead and lag poles and zeros, we may compute the full Lead-Lag compensator
𝐺1𝐷
transfer function, 𝐷1, and the closed loop system,𝑇1 = 𝐺1𝐷 +1
1
:
1
2
𝐷1(𝑠) = − 10. 5 ( 𝑠+31.4
𝑠+125.7 )( 𝑠+20
𝑠 ) =
−10.5𝑠 − 539.9𝑠 − 6597
2
𝑠 + 125.7𝑠
20
5 6
9268 + 4.765×10 𝑠 + 5.824×10
𝑇1(𝑠) = 4 3 4 2 5 6
𝑠 + 169.8𝑠 + 1.462×10 𝑠 + 4.5×10 𝑠 + 5.535×10
The stability of the controller may be further verified by taking the step response of the closed
loop system, 𝑇1, as shown in Figure 8. The system does not oscillate after reaching the peak
value 0. 05 𝑠𝑒𝑐 after the initial step. It also has a maximum overshoot of 21% above its settled
amplitude of 1.05 . The rise time and settling time of the system are 0. 02 𝑠𝑒𝑐 and0. 17 𝑠𝑒𝑐,
respectively.
Figure 7: Step Response of the Inner Loop System. The system is stable.
1 0 9.345
2 0 -9.345
These Poles and zeros are graphed on a Root Locus plot in Figure 10. Simple positive or
negative gain will not stabilize the system, as one of the poles at the origin will be attracted to the
positive zero, destabilizing the system.
22
Figure 9: Root Locus of Outer Loop Plant 𝐺2. The branches show simple positive gain. A simple
negative gain will attract the two poles at the origin to the zeros along the real axis.
The Bode Plot of 𝐺2, as shown in Figure 11, demonstrates that the phase of the plant is fully
◦
inverted at a constant 180 .
23
Finally, the gain 𝐾 of the controller was adjusted for a gain crossover frequency of
𝑟𝑎𝑑
ω𝑐 = 1 𝐻𝑧 = 2 π 𝑠𝑒𝑐
. This value was chosen to be a factor of 20 lower than the 20 𝐻𝑧
sampling frequency of the outer loop. It was found that a gain of 𝐾 = 7 met this specification.
The robustness of the system may be checked using the gain and phase margin, or the value of
◦
the magnitude when the phase crossed 180 and the phase when the gain was 0 𝑑𝐵,
◦
respectively. A gain of 𝐾 = 7 led to a 25 phase margin and a − 4. 2 𝑑𝐵 gain margin, more
than enough to stabilize the system. The results are reflected in the Bode plots of Figure 12.
24
The final chosen Pole and Zero locations are displayed in Table 6:
Lag Compensator -8 -1
With the chosen lead and lag poles and zeros, we may compute the full controller transfer
𝐺2𝐷
function,𝐷2, and the closed loop system,𝑇2 = 𝐺2𝐷 +1
2
:
2
𝐷2(𝑠) = 7 ( 1
𝑠+20 )( ) =
𝑠+1
𝑠+8 2
7𝑠 + 7
𝑠 + 28𝑠 + 160
3 2
−10.33𝑠 − 10.33𝑠 + 902.3𝑠 + 902.3
𝑇2(𝑠) = 4 3 2
𝑠 + 17.67𝑠 + 149.7𝑠 + 902.3𝑠 + 902.3
25
The Root Locus plot of the system, seen below in Figure 13, verifies that the closed loop system
is stable, as suggested by the Bode plots.
Figure 12: Root Locus of the Controlled Outer Loop System. Note that any positive gain will
yield a stable system.
The stability of the outer loop may be further verified by step response of the closed loop system,
as seen in Figure 14. Note that the system is of non-minimum phase. That is to say that a positive
step input causes an initial decrease in amplitude of the system. This intuitively makes sense due
to the conservation of angular momentum in our system--if the body falls over at a positive
angle, the wheels must spin to a negative angle to “catch” the body.
The system does appear to be underdamped, as the step response oscillates after reaching its
69% overshoot 0. 45 𝑠𝑒𝑐 after the initial step. The rise time, settling time, and settling amplitude
of the system are 0. 10 𝑠𝑒𝑐,2. 06 𝑠𝑒𝑐, and 1.00, respectively.
26
Figure 13: Step Response of the Outer Loop System with Unity Inner Loop Gain.
While the outer loop controller design ignored the inner control loop, the actual system must
consider its dynamics. The full cascaded system transfer function is as follows:
𝐺2𝑇1𝐷2 4 6 6 5 8 4 8 3 10 2 11 11
−9.58×10 𝑠 −6.94×10 𝑠 − 1.57×10 𝑠 − 7.56×10 𝑠 + 1.33×10 𝑠 + 1.19×10 𝑠 + 1.05×10
𝑇𝑓𝑢𝑙𝑙 = 𝐺2𝑇1𝐷2 + 1
= 9 8 4 7 6 6 7 5 8 4 9 3 10 2 11 1
𝑠 + 218𝑠 +2.35×10 𝑠 + 1.18×10 𝑠 + 3.13×10 𝑠 + 4.79×10 𝑠 + 4.67×10 𝑠 +3.10×10 𝑠 +1.19×10 𝑠+1.05×10
This full system is stable, as displayed by the step response in Figure 15 below. Similar to the
outer loop step response, the full system is underdamped, as the step response oscillates after
reaching its 95% overshoot 0. 43 𝑠𝑒𝑐 after the initial step. The rise time, settling time, and
settling amplitude of the system are 0. 075 𝑠𝑒𝑐,2. 01 𝑠𝑒𝑐, and 1.01, respectively. Note that the
inclusion of the inner loop transfer function caused more overshoot and oscillations in the full
system step response as compared to only the outer loop 𝑇2.
27
2
𝑢 −9.048𝑧 +15.92𝑧−6.994
𝐷1(𝑧) = θ𝑒
= 2
𝑧 −1.522𝑧+0.5219
28
θ𝑟 2
0.09966𝑧 +0.004863𝑧−0.0948
𝐷2(𝑧) = φ𝑒
= 2
𝑧 −𝑧+0.2221
To implement these controllers in software, we must rearrange the above equations. Recalling
that the Z-Transform product corresponds to a discretized time step, we may shift the equations
back in time and solve for our current time outputs to the equations. We obtain the following,
which may be directly implemented into a software of our system for the inner and outer loop
controller, respectively:
𝑢(𝑛) = − 9. 048 θ𝑒(𝑛) + 15. 92 θ𝑒(𝑛−1) − 6. 994 θ𝑒(𝑛−2) + 1. 522 𝑢(𝑛−1) − 0. 5219 𝑢(𝑛−2)
θ𝑟(𝑛) = 0. 09966 φ𝑒(𝑛) + 0. 004863 φ𝑒(𝑛−1) − 0. 0948 φ𝑒(𝑛−2) + θ𝑟(𝑛−1) − 0. 2221 θ𝑟(𝑛−2
Note that the subscript 𝑛 represents the time step associated with each variable.
2
𝐷1 = − 3. 15 ( 𝑠+31.4
𝑠+125.7 )( 𝑠+20
𝑠 ) =
−3.15𝑠 − 162𝑠 − 1979
2
𝑠 + 125.7𝑠
𝐷2 = 0. 7 ( 1
𝑠+20 )( ) =
𝑠+1
𝑠+8 2
0.7𝑠 + 0.7
𝑠 + 28𝑠 + 160
𝑢(𝑛) = 0. 3 (− 9. 048 θ𝑒(𝑛) + 15. 92 θ𝑒(𝑛−1) − 6. 994 θ𝑒(𝑛−2)) + 1. 522 𝑢(𝑛−1) − 0. 5219 𝑢
θ𝑟(𝑛) = 0. 1 (0. 09966 φ𝑒(𝑛) + 0. 004863 φ𝑒(𝑛−1) − 0. 0948 φ𝑒(𝑛−2)) + θ𝑟(𝑛−1) − 0. 2221
29
It would seem that the lower gains slowed down the time response of the system, allowing the
motors to more smoothly catch the falling body. As the only modification required to stabilize
the system was the constant gain 𝐾, it is clear that the designed Lead-Lag Compensators worked
as intended. What is less clear is why the modification was required. It is possible that the
assumptions and simplifications used to derive the system model, such as linearization, affected
the model’s accuracy. It is also possible that the chosen crossover frequencies were too high,
which may have been fixed by lowering the gain of the systems.
The outer loop was executed by a thread which ran at a constant 20 𝐻𝑧. The thread read each
wheel encoder value, averaged the values for use in the controller, and executed the outer loop
controller, thereby updating the reference angle for the inner loop controller.
30
Conclusion
The eduMIP was the perfect introduction to mechatronics. Other systems usually require fighting
with software, hardware, and control theory simultaneously. This system has the advantage of
eliminating, or at least minimizing, the many issues that hardware inevitably causes.
While Newtonian Mechanics are useful for many derivations, for this system Lagrangian
Mechanics were found to be much more straightforward. In some cases, the Lagrangian
derivation also helped with comprehension of the sources of the many forces in the multiple
reference frames of the Newtonian derivation.
It is also important to stress how powerful of a tool Bode, Root Locus, and Step Input Plots are
for SISO control system design. For this project, Root Locus Plots served as the primary control
tool for the inner loop, while Bode Plots aided in design of the outer loop. The Step Input Plots
were always useful for checking stability of the systems.
Due to inherent disparities between the derived model and the actual physical system due to
engineering assumptions and linearization of the derived equations, practical implementation of
the controller in software required some final tweaking. This is not to say that modelling systems
is not a useful tool. Rather, the model of the system is just that: a model.
I believe that I will return to this project in the future. The next step will likely be to implement
an LQR controller utilizing state space. I would also like to utilize state feedback linearization to
attempt a nonlinear controller. The fact that we may balance a physical object with some
software never ceases to amaze me.
32
Appendix A: References
[1] “EduMIP Kits - AVAILABLE NOW.” UCSD Robotics, UCSD Flow Control &
Coordinated Robotics Labs, www.ucsdrobotics.org/edumip.
[2] Bewley, Thomas. “Chapter 17 Kinematics and Dynamics.” Numerical Renaissance, First
ed., Renaissance Press, 2018, pp. 477–520. http://numerical-renaissance.com/NR.pdf
[3] Strawson, James “Balancing eduMIP”.
https://www.coursehero.com/file/27260354/Balancing-EduMiPpdf/
[4] “Equations of Motion for the Inverted Pendulum (2DOF) Using Lagrange's Equations”.
https://www.youtube.com/watch?v=Fo7kuUAHj3s
[5] “2.003SCRecitation 8 Notes: Cart and Pendulum (Lagrange)”. Michigan Institute of
Technology.
https://ocw.mit.edu/courses/mechanical-engineering/2-003sc-engineering-dynamics-fall-2
011/lagrange-equations/MIT2_003SCF11_rec8notes1.pdf
[6] The Torque Equation and the Relationship with DC Motors.
https://www.motioncontroltips.com/torque-equation/
[7] Bewley, Thomas. “Chapter 19: Classical Control Systems.” Numerical Renaissance, First
ed., Renaissance Press, 2018, pp. 586-588. http://numerical-renaissance.com/NR.pdf
[8] https://www.mathworks.com/help/control/ug/continuous-discrete-conversion-methods.ht
ml
[9] “Robot Control Library Documentation”. Strawson Design.
http://strawsondesign.com/docs/librobotcontrol/
31
% . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
% .
% . eduMIP BeagleBone Blue Controller Design 3.0
% .
% . Title: edupMIP_Controller_Design_v3
% . Description: Designs two controllers to balance an inverted pendulum
% . Author: Robert Ketchum
% . Date Created: April 7, 2021
% . Last Modified: April 11, 2021
% . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%PART 1: Characterize the robot's equations of motion
% and find the inner and outer loop plants: G1 and G2
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
G1=PolyDiv(CA-FD,BA-ED);
32
G1=minreal(G1);
pole1=pole(G1); % poles of G1
zero1=zero(G1); % zeros of G1
G2=PolyDiv(EF-BC,AC-DF);
G2=minreal(G2);
pole2=pole(G2); % poles of G2
zero2=zero(G2); % zeros of G2
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%PART 2: Design the inner loop controller: D1
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%PART 3: Design the outer loop controller, D2
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%PART 4: Full System Cascaded Transfer Function
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
L2=G2*T1*D2;
T2f=L2/(1+L2);
T2f=minreal(T2f); % Full system transfer function
T2f_step_info = stepinfo(T2f);
%%%%%%%%%%%%%%%%%%
%PART 4: Plotting
%%%%%%%%%%%%%%%%%%
figure(2)
bode(G1);
title("Bode of G1")
grid on
saveas(2,'G1_Bode.png')
35
figure(3)
rlocus(G1D1/-k1);
grid on
title("Root Locus of -1*G1D1")
axis([-150 20 -100 100])
saveas(3,"G1D1_RL.png")
figure(4)
bode(G1D1)
grid on
title("Bode of Open Loop G1D1")
saveas(4,"G1D1_Bode.png")
36
figure(5)
step(T1);
grid on
axis([0 0.3 0 1.4])
title("Step Response of T1")
saveas(5,"T1_Step.png")
37
figure(7)
bode(G2);
title("Bode of G2")
grid on
saveas(7,"G2_Bode.png")
38
figure(8)
rlocus(G2D2/k2);
grid on
title("Root Locus of -1*G2D2")
axis([-50 20 -2 2])
saveas(8,"G2D2_RL.png")
39
figure(9)
bode(G2D2)
grid on
title("Bode of G2*D2")
saveas(9,"G2D2_Bode.png")
figure(10)
step(T2);
title("Step Response of T2")
axis([0 2.5 -1 2])
grid on
saveas(10,"T2_Step.png")
40
%%%%%%%%%%%%%%%%%%%%%%%%%
%PART 5: Function PolyDiv
%%%%%%%%%%%%%%%%%%%%%%%%%
function [d,b]=PolyDiv(b,a)
% function [d,b]=PolyDiv(b,a)
% Perform polynomial division of a into b, resulting in d with remainder in the
modified b.
% See <a href="matlab:NRweb">Numerical Renaissance</a>, Appendix A, for further
discussion.
% Part of <a href="matlab:help NRC">Numerical Renaissance Codebase 1.0</a>, <a
href="matlab:help NRchapAA">Appendix A</a>; see webpage for <a href="matlab:help
NRcopyleft">copyleft info</a>.
//Libraries to Include
#include <stdio.h>
#include <math.h>
#include <robotcontrol.h>
// function declarations
void on_pause_press();
void on_pause_release();
static void imu_interupt_function(void); //mpu interrupt routine
static void* my_outer_loop_thread(void* unused); //background outer loop thread
//variable declerations
static rc_mpu_data_t mpu_data; //mpu data
//Constant declarations
const double PI = 3.1415926;
const double WC = 157.9; //complimentary filter cutoff fz [rad/sec]
const double K1 = 0.3; //inner loop scaling factor
const double K2 = 0.1; //outer loop scaling factor
const double REV = 341.8648; //encoder value for 1 wheel revolution [ticks/rev]
const double INNER_LOOP_DT = 0.005; //inner loop step size [seconds]
const double OUTER_LOOP_DT = 50000; //outer loop step size [microseconds]
const double OFFSET = 0.3457; //balanced robot angle offset from vertical [rad]
int main()
{
// create our thread for the outer loop controller
pthread_t thread_outer_loop = 0;
43
//initialize encoder
if(rc_encoder_eqep_init()){
fprintf(stderr,"ERROR: failed to run rc_encoder_eqep_init\n");
return -1;
}
//initialize motor
if(rc_motor_init_freq(freq_hz)) return -1;
if(rc_get_state()==RUNNING){
//Only run controller if state is RUNNING
//outer loop controller--updates robot reference angle for use in inner loop
ref_pitch_angle[0] = K2*(outer_num[0]*wheel_error[0] + outer_num[1]*wheel_error[1] + ...
t outer_num[2]*wheel_error[2]) + outer_den[0]*ref_pitch_angle[1] + ...
t outer_den[1]*ref_pitch_angle[2];
}
if(rc_get_state()==PAUSED){
//If the state is PAUSED, store the encoder values so that
//the outer loop controller is not messed up if the wheels are spun
encoder_offset[0] = rc_encoder_read(2);
encoder_offset[1] = rc_encoder_read(3);
}
//update steps
ref_pitch_angle[2] = ref_pitch_angle[1];
ref_pitch_angle[1] = ref_pitch_angle[0];
wheel_error[2] = wheel_error[1];
wheel_error[1] = wheel_error[0];
printf("wheel error: %6.2f Pitch Angle: %6.2f pitch error: %6.2f duty cycle: %6.2f \n ",...
w wheel_error[0]*RAD_TO_DEG, current_angle, pitch_err[0]*RAD_TO_DEG, uk[0]);
rc_usleep(OUTER_LOOP_DT);
}
return NULL;
}
void imu_interupt_function(void){
//Find orientation of robot from accelerometer+gyro data.
//Then calculate the motor duty cycle from the inner loop control system.
//Finally, apply duty cycle to motors.
//accelerometer data
raw_accel = atan2(mpu_data.accel[1],mpu_data.accel[2]); //accelerometer data [rad]
//gyro data
raw_gyro = mpu_data.gyro[0] * DEG_TO_RAD;
gyro_angle[0] = gyro_angle[1] + INNER_LOOP_DT * raw_gyro; //find angle using euler's integration method
//update steps
pitch_err[2] = pitch_err[1];
pitch_err[1] = pitch_err[0];
uk[2] = uk[1];
uk[1] = uk[0];
void on_pause_release()
{
//Make the Pause button toggle between paused and running states. Only works for short (< 0.5s) toggles
if(rc_get_state()==RUNNING) rc_set_state(PAUSED);
else if(rc_get_state()==PAUSED) rc_set_state(RUNNING);
return;
}
void on_pause_press()
{
/**
* If the user holds the pause button for 0.5 seconds, set state to EXITING which
* triggers the rest of the program to exit cleanly.
**/
const int samples = 100; // check for release 100 times in this period
const int us_wait = 500000; // total time to hold down button: 0.5 seconds
for(int i=0; i<samples; i++){
// keep checking to see if the button is still held down
rc_usleep(us_wait/samples);
if(rc_button_get_state(RC_BTN_PIN_PAUSE)==RC_BTN_STATE_RELEASED){
// If the button is released in this time, set state to PAUSED or RUNNING
return;
}
}
printf("long press detected, shutting down\n");
rc_set_state(EXITING); // exit program
return;
}