1. Department of Electronic & Computer
Engineering
Inverted Pendulum
Student Name: Barry Reidy
Student ID: 09006835
Supervisor: Edin Omerdic
Course: BEng/BSc in Robotic
Engineering
Academic Year: 2012/13
March 2013
2. Department of Electronic & Computer
Engineering
Inverted Pendulum
Student Name: Barry Reidy
Student ID: 09006835
Supervisor: Edin Omerdic
Course: BEng/BSc in Robotic
Engineering
Academic Year: 2012/13
“Submitted in partial fulfilment for the requirements of the Bachelor of Science
Degree in the University of Limerick”
March 2013
3. Table of Contents
Table of Figures:......................................................................................................................................2
Abstract:..................................................................................................................................................3
Section 1: Introduction.........................................................................................................................4
Project Desription:............................................................................................................................4
Introduction: ......................................................................................................................................4
Requirements of Facilities and Materials......................................................................................6
What are the learning objectives of the project? .........................................................................6
Section 2: Background Theory.........................................................................................................7
Control Algorithms:...............................................................................................................................7
PID Control Algorithm:.................................................................................................................7
Tuning the PID Controller: ........................................................................................................11
Linear Quadratic Regulator Controller (LQR) ........................................................................12
Fuzzy Logic: ................................................................................................................................14
Section 3: Background Research ....................................................................................................17
Summer: ..........................................................................................................................................17
LEGO MINDSTORMS Hardware:............................................................................................17
NXT-G Programming:................................................................................................................18
Concept Robots:................................................................................................................................19
Alpha- Rex Robot: .........................................................................................................................20
Section 4: Hardware/Software..............................................................................................................21
Hardware:........................................................................................................................................21
NXT Intelligent Brick ..................................................................................................................21
Servo Motors:..............................................................................................................................23
Gyro Sensor:...............................................................................................................................23
Software:..........................................................................................................................................25
LabVIEW:.....................................................................................................................................25
Finished design: .............................................................................................................................28
4. Section 5: Literary Survey.................................................................................................................29
LEGO NXT Alternatives:.....................................................................................................................29
Legway ..........................................................................................................................................29
NXTWay.........................................................................................................................................31
Segway with Rider.........................................................................................................................32
First Gyro Based NXT Segway........................................................................................................33
AnyWay LEGO Segway ..................................................................................................................33
Two Wheeled balancing LEGO Robot: ..........................................................................................34
NXTway-GS Model-Based Design - Control of self-balancing two................................................35
wheeled robot built with LEGO MINDSTORMS NXT –..................................................................35
Non-LEGO NXT Alteranative .............................................................................................................36
Inverted pendulum on belt/Pulley System...................................................................................36
FPGA and State-Space pole placement control............................................................................37
Section 6: Implementation....................................................................................................................38
Theory behind balancing program:...................................................................................................39
Main balancing program:..................................................................................................................41
3 Subset Vi’s......................................................................................................................................43
Buttons.VI......................................................................................................................................43
Gyro_Offset.VI ..............................................................................................................................45
BeepWarning.VI ............................................................................................................................46
Section 7: Results/Discussion................................................................................................................47
Robot Balancing:...............................................................................................................................47
Code Failure:.....................................................................................................................................47
Controller Design Implementation: ..................................................................................................49
PID Controller:...............................................................................................................................49
Fuzzy Controller: ...........................................................................................................................51
Linear Quadratic Controllers in LabView: .....................................................................................52
Section 8: Issues and Problems.............................................................................................................53
Hardware:....................................................................................................................................53
Software:......................................................................................................................................54
Section 9: Future Work.........................................................................................................................55
5. Section 10: Conclusion......................................................................................................................56
What was learnt?..............................................................................................................................56
Conclusion:........................................................................................................................................57
Section 11: Appendix ...........................................................................................................................58
Appendix A – Main Balancing ...........................................................................................................58
Appendix B – Gyro_Offset.................................................................................................................59
Appendix C - BeepWarning...............................................................................................................60
Appendix D - Buttons........................................................................................................................61
Appendix E – Labview Block Diagram ...............................................................................................62
Appendix F: LEGO MINDSTORMS Component list................................................................................63
Appendix F: Gantt Chart .......................................................................................................................64
Action Plan........................................................................................................................................64
References: ...........................................................................................................................................65
Bibliography ......................................................................................................................................65
7. 3 | P a g e
Abstract:
This is a self-balancing robot created using the MINDSTORMS NXT LEGO kit which
demonstrates the idea of the inverted pendulum. The objective of this project was to
create the inverted pendulum with the LEGO kit, and design multiple control theory
algorithms (PID, Fuzzy, LQR) to balance said pendulum. The software used for the
development of the algorithms was developed with LabVIEW by using the various
blocks and toolkits associated with it. The robot successfully balanced itself, staying
perfectly in the upright position, even when a force was applied to it. The robot still
remained upright when the surface which it was balancing on changed angle, as
long as the angle was no greater than 45 degrees on average. However, comparison
results of the controllers were unable to be collected due to the fact that the robot
unknowingly stopped working, meaning the stability controllers were unable to be
designed and put in place.
8. 4 | P a g e
Section 1: Introduction
Project Desription:
An inverted pendulum (also called a cart and pole) consists of a thin rod
attached at the bottom to a mobile cart. Unlike a normal pendulum, an
inverted pendulum is inherently unstable. Inverted pendulums must be
actively balanced to remain erect. The aim of the project is first to build an
inverted pendulum using Lego MINDSTORMS NXT and then test different
control algorithms (PID, LQ, Fuzzy) to keep a rod in vertical position.
Introduction:
When you were younger, did you ever try
balance a broom on your hand or even a pencil
on your index finger? Trying to keep them upright
involved you moving your hand constantly back
and forth and side to side to stop it from falling
over. This simple childhood activity is the basis of
what the principle of an inverted pendulum is. The
only difference being the inverted pendulum is
limited to moving in only one dimension, while
your hand can move in three (up, down, side to
side).
Like the broom-stick or the pencil, the inverted pendulum is a constantly unstable
system and always needs force acting on it to keep it upright. This is where control
theory is required.
Figure 1- Inverted Pendulum
analogy
9. 5 | P a g e
Through understanding control theory and implementing the different control
algorithms specified above, the pendulum will hopefully stabilize so its position is
controlled quickly and accurately. It should always maintain tightly in its inverted
position during such movements and should be susceptible to step disturbance,
meaning if someone was to give the pendulum a push, it would be able to correct
itself and not fall down. [1]
For the given FYP, the design decision was made to eliminate the “cart”, instead
having the wheels mounted directly to the bottom of the pendulum rod itself. This
was due to design constraints that arouse with the Lego MINDSTORMS during
development. The theory and principles remain the same for both designs as long as
the wheels don’t move independently of each other.
10. 6 | P a g e
Requirements of Facilities and Materials
All required materials have been provided these include:
o LEGO MINDSTORMS NXT 2.0
o External gyro sensor for LEGO MINDSTORMS
o LabVIEW
o Control and Simulation toolkit for LabVIEW
o Access to the projects and robotics lab to complete work
What are the learning objectives of the project?
To gain an in-depth understanding of the core concepts of control theory
The opportunity to apply my theoretical knowledge of the subject in a practical
environment.
Engineering design methodologies to apply decision‐making strategies when
developing solutions.
To gain knowledge of rotational dynamics, weight, friction, and traction factors
required for the operation of robotic and automated systems.
To gain a greater knowledge of the principles behind inverted pendulums,
their operation and implementation.
The chance of becoming more proficient in LabVIEW from the perspective of
system control design.
The ability to cope under pressure and work steadily and consistently when
given a deadline.
11. 7 | P a g e
Section 2: Background Theory
Control Algorithms:
For this project, three different control algorithms (PID tuning, LQ, and Fuzzy Logic)
are being incorporated to keep the inverted pendulum erect.
The theory behind each approach is described in the following pages
PID Control Algorithm:
[4] The PID control algorithm is a robust and simple algorithm that is widely used in
the industry. The algorithm has sufficient flexibility to yield excellent results in a wide
variety of applications and has been one of the main reasons for the continued use
over the years.
[4] The basic idea behind a PID controller is to read a sensor(for example, the gyro
sensor of the inverted pendulum), then compute the desired actuator output by
calculating proportional, integral, and derivative responses and summing those three
components to compute the output. A PID controller is an example of a closed loop
system, where the process of reading sensors to provide constant feedback and
calculating the desired output is repeated continuously and at a fixed loop rate.
Figure 2- Block diagram of basic closed loop system
12. 8 | P a g e
First, there’s a process variable that needs to be controlled, such as temperature in a
chamber, pressure, or in this case, motion. The set point is the desired value for the
process variable, such as a value that corresponds to the pendulums being perfectly
upright.
At any given time, the difference between these two values is fed into the
compensator (the control algorithm) and the new desired output is calculated, which
is then fed back into the system.
Therefore, calculating the error (e) would be:
e = SP – PV
For instance, using our inverted pendulum as an example, the process variable is
constantly giving feedback back to the system, taking its current value (amount the
pendulum is tilting) and comparing this value to the desired upright position.
This difference is then fed back into the system which then uses this information to
correct itself for that given moment. This process then loops continuously to keep the
pendulum balanced.
The PID controller calculates the controller action, u(t),where Kc is controller gain.
13. 9 | P a g e
[4]PID algorithms consist of three different coefficients, Proportional, Integral, and
Derivative. Each of these coefficients are tuned separately to achieve optimum
results and stability.
Proportional Response
The proportional component depends only on the difference between the set point
and the process variable. This difference is referred to as the Error term.
The proportional gain (Kc) determines the ratio of output response to the error signal.
The following formula represents the proportional action:
Integral Response:
The integral component sums the errors over time. This means that even a
small error will cause the integral component to slowly increase. The only way
to stop this happening is if the error is 0. Therefore the steady-state error
would preferably go towards 0. Steady-state error is the final difference
between the set point and the process variable.
14. 10 | P a g e
The following formula represents the integral action:
Where represents the integral time in minutes, which is also called the reset time.
Derivative Response:
The derivative component causes the output to decrease if the process variable
increases rapidly. The derivative response is proportional to the rate of change of the
process variable. Increasing the derivative time (Td) parameter will cause the control
system to react more strongly to changes in the error term and will increase the
speed of the overall control system response.
The following formula represents the derivative action:
Where represents the derivative action in minutes, also called the rate
time.
15. 11 | P a g e
Tuning the PID Controller:
[4]Tuning of the PID Controller involves finding the optimum values for the P,I,
and D variables to get a controlled system. There are many ways of
calculating what these optimum values. An example of one such method is
the Ziegler-Nichols method.
The table for such method is seen below.
First, both values of I and D are set to 0 so an optimum value of P can be found. P is
found by slowly increasing the proportional gain until the output of the loop oscillates.
Once this occurs, the values for I and D can be found by using the columns above
and also by using the values of Kc (critical gain) and Pc (Period of Oscillation) noted
from the output. Therefore, it can be seen that implementing a PID controller is
relatively simple and gives a robust, flexible and stable system. [4].
Figure 3- Ziegler-Nichols Tuning method table
16. 12 | P a g e
Linear Quadratic Regulator Controller (LQR)
[6] To put it simply, LQR control, also called Optimum control, is based around the
idea of operating a dynamic system with minimum cost, where the dynamics of the
system are described by differential linear equations and the cost is describes by a
quadratic function called the LQ problem. The solution to this problem is solvable
through the use of a Linear Quadratic Regulator.
LQR is a linear feedback controller that requires a linear system model around the
equilibrium point, in this case when the pendulum is standing perfectly upright.
The LQR is a controller for state-variable feedback where,
So that the value K can be obtained from a minimising problem of the functional cost,
[8]Matrixes Q and R are two weighted matrices which penalise the state error and
the control effort, respectively.
Q has the following form:
can be used as controller tuning parameters, while so can R:
Where R is
17. 13 | P a g e
[7] The main design philosophy of the optimal LQR controller is to find the control
gain K, which minimizes the performance index. The behaviour of this LQ controller
is determined by choices of the two weight matrices mentioned above (Q and R).
One way off determining the proper weight matrices is done through a trial-and-error
process, where weights would be used to normalize the variables with respect to the
largest permissible.
18. 14 | P a g e
Fuzzy Logic:
[3] Fuzzy Logic is a variation on set theory where a variable can partially be an
element of a set. Developed in the 1960’s, fuzzy Logic Controllers are intended to
“think” like humans do, emulating the rule-of-thumb thought process used by
humans. In this way they are helpful for problems that cannot easily be set up
mathematically, but can easily be expressed in words.
[2] In Traditional Boolean, set theory is two-valued in the sense that a member
belongs to a set or does not—represented by 1 or 0, respectively. But Fuzzy set
theory differs from traditional Boolean (or two-valued) set theory in that partial
membership in a set is allowed, which means it allows for partial membership, or a
degree of membership, which might be any value along the range of 0 to 1.
A type of fuzzy set called a membership function can be used to define a linguistic
term. A membership function specifically defines degrees of membership based on a
property such as temperature or pressure. With the membership functions defined
for controller or expert system inputs and outputs, a rule base of IF-THEN type
conditional rules can then be formulated. With fuzzy logic implication, it is then
possible to use that rule base and corresponding membership functions to determine
the controller outputs by examining the controller inputs.
19. 15 | P a g e
[3] The example below shows how partial membership works. Usually in traditional
set theory, we say that X is only in one of the sets, whereas in fuzzy logic, the X
value can be said to be partially in Set A, as well as Set B and Set C.
Example below shows how fuzzy logic can allow a degree of set membership.
Figure 4- partial membership in Fuzzy Logic
Figure 5- degree of set membership
20. 16 | P a g e
Say for instance, a feedback controller is designed which is based on the error of
control. It could be said that 8-9mm of an error value could partially be in all three
member sets (Close to target, Slightly over target, and Over target).
[2] By defining a fuzzy controller, process control can be implemented quickly and
easily. While some processes are too complex or non-linear to be controlled by
traditional means, fuzzy logic can be used to control a process that a human can
control manually.
A fuzzy logic controller gives out faster response, is more reliable and recovers
quickly from system upsets. It also works well to uncertainties in the process
variable. Fuzzy logic controller does not require mathematical modelling.
21. 17 | P a g e
Section 3: Background Research
Summer:
In preparation for this Final Year Project, familiarisation of the LEGO MINDSTORMS
kit began during the summer in hopes of understanding the hardware and software
to a greater degree. This was done by first building and programming basics robots,
concentrating on the building elements and sensors that would be incorporated into
the final FYP. This was accomplished by experimenting with the kit, following the
instructions to make basic programs that would hopefully introduce me to every
aspect of the LEGO MINDSTORMS.
LEGO MINDSTORMS Hardware:
The full LEGO MINDSTORMS kit comprises of hundreds of standard LEGO
pieces for creating several types of unique and varied robots – LEGO TECHNIC
building elements, gears, wheels, tracks and tires. It also comes with a handful of
different types of sensors; 2 touch sensors, a colour sensor and an ultra-sonic
sensor.
Figure 6- LEGO MINDSTORMS kit
22. 18 | P a g e
NXT-G Programming:
This is the main software used to program the LEGO MINDSTORMS kit, which is
included with the package. [11]NXT-G is an intuitive, icon-based drag-and-drop
programming language which is designed for an easy introduction to programming
whether the user is new to programming or an experienced user.
With careful construction of blocks and wires to eliminate complexity, NXT-G can be
used for real-world programming. Through the use of parallel beams known as
"sequence beams" which are actually parallel threads, this software is quite good for
running a handful of parallel sense/respond, or blending autonomous control with
bluetooth or other "remote control" devices such as gamepad.
The language supports virtual instruments for all LEGO branded and most 3rd party
sensors/components such as the Hitechnic Gyro sensor or IR Receiver.
While the NXT-G software wasn’t going to be used for this specific project, it was a
good way to introduce the basic concepts of how each of motors and sensors are
programmed. Since the software is based on National Instruments LabVIEW, which
is the program that is going to be used, it was worth the effort to learn the basics so
a certain familiarity could be obtained and a solid base could be formed.
RobotC: RobotC is a programming environment similar to programming in C and is
a more advanced way of coding for the LEGO MINDSTORMS. Very little time was
spent with this software as It would never be used properly, but it was useful for
research purposes to see different ways other inverted pendulums solutions were
programmed.
23. 19 | P a g e
Concept Robots:
Reiterating what was said before; designing basic robots concentrating on the
building elements and sensors that would be used during the final FYP was the first
prerogative in hopes of understanding the hardware and software to a greater
degree.
To do this two main robots were designed:
Object-detection Car:
The first of these two was a 4 wheeled car that drove in a straight line until it sensed
that it was coming too close to an object. It was able to detect this by using the ultra-
sonic sensor which detected an object when it was 5cm away. When this happened,
the car would reverse and rotate 90 degrees, then continue to move forward again.
While this may seem like a very simple robot, it helped create a basic understanding
of how the servo motors and sensors can be programmed as well as be used in
unison together.
Figure 7-Object-detection Car
24. 20 | P a g e
Alpha- Rex Robot:
The reason this robot was designed is due to the fact that it encompasses every
piece of the building elements and all the sensors in the kit. This humanoid robot can
walk turn, dance, talk, can see and avoid obstacles and can grab and distinguish
between different coloured objects.
How the program works is as follows:
The robot waits for the user to place their hand over the ultra-sonic sensor. When it
recognises an object, it begins to walk forward using the servo motors. After a given
amount of time, the robot will stop and ask for a green ball. When the green ball is
place in the hand of the robot, it will recognise the colour and say “green”. It will even
recognise if the ball is a different colour, instead saying the colour of the ball and
dropping it. It can be observed then that this is a far more complex system than the
previous automotive robot. It encompasses nearly every sensor and creates a
program that is impressive to see.
Creating this robot was the most beneficial
basic research because it gave the best
understanding of how the LEGO MINSTORMS
work together and showed how this seemingly
simple programming software could be used to
still create complicated and intricate programs.
Figure 8- Alpha-Rex Robot
25. 21 | P a g e
Section 4: Hardware/Software
Hardware:
The hardware that is being used for this project to develop the inverted pendulum is
based on the LEGO MINDSTORMS NXT. This is a programmable robotics kit that is
used by many engineers and universities because of its simplicity and ease of use.
The design is made up of multiple parts from the MINSTORMS NXT kit.
The NXT intelligent brick
Two servo motors
Gyroscopic sensor
NXT Intelligent Brick
The heart of the design comes from NXT intelligent Brick, which acts as the
microcontroller. [12] It can take input from up to four sensors and control up to
three motors and communicates with the computer through a USB 2.0
connection. The brick has a 100×60 pixel monochrome LCD display and four
buttons that can be used to navigate a user interface using hierarchical menus. It
has a 32-bit ARM7 processor, 256kb of FLASH memory, 64kb of RAM, an 8-bit AVR
microcontroller, and Bluetooth support. It also has a speaker and can play sound
files at sampling rates up to 8 kHz. Power is supplied by a Li-Ion rechargeable
battery and charger.[10]
26. 22 | P a g e
The microproccesor is very straight forward to navigate and is easily programmed in
LabVIEW through the use of a Lego toolkit which creates separate tools in LabVIEW
just for the MINDSTORMS NXT.
Execution of the code is very quick also with the program downloading on to the
microcontroller instantaneously when it is ran in LabVIEW. This allows for quick and
easy debugging of the programme as the code can be seen running immediately.
Figure 9- NXT Micro-processor
27. 23 | P a g e
Servo Motors:
[10]The two servo motors that are being used have built-in reduction
gear assemblies with internal optical rotary encoders that sense their rotations,
therefore measuring speed and distance, and reports back to the NXT
microcontroller. This allows for precise steps and completes motor control within only
one degree of accuracy.
Gyro Sensor:
[5] The NXT gyro sensor accurately detects rotation for the inverted pendulum. The
sensor returns a number of degrees per second of rotation as well as indicating the
direction of rotation. It can measure up to +/- 360 degrees per second of rotation.
The gyro connects to the Intelligent Brick using the standard NXT wire and utilizes
the analog sensor interface.
Figure 10- Servo-Motors
28. 24 | P a g e
The rotation rate can be read up to approximately 300 times a second.
The axis of measurement is in the vertical plane with the gyro sensor positioned with
the black end top facing up shown in Figure 11a.
This is an external sensor which doesn’t come packaged with the LEGO
MINDSTORMS kit, but there is still great support for this device with programmable
blocks released for NXT-G and LabVIEW.
Figure 11b- Gyro Sensor
Figure 11a- Gyro sensor
29. 25 | P a g e
Software:
LabVIEW:
The software side of the FYP was done solely in LabVIEW. LabVIEW which is short
for Laboratory Virtual Instrumentation Engineering Workbench is a platform and
development environment for a visual programming language from National
Instruments. [19] The purpose of such programming is automating the usage of
processing and measuring equipment in any laboratory setup. LabVIEW ties the
creation of user interfaces (called front panels) into the development cycle and these
programs/subroutines are called virtual instruments (Vis). Each VI has 2 sections: a
block diagram and a front panel. Controls and indicators on the front panel allow an
operator to input data or extract data from a running virtual instrument.
Figure 13- LabVIEW front panel Figure 12 – LabVIEW Block panel
30. 26 | P a g e
[19] However, the front panel can also serve as a programmatic interface. Therefore
a virtual instrument can either be run as a program, with the front panel serving as a
user interface, or, when dropped as a node onto the block diagram, the front panel
defines the inputs and outputs for the given node through the connector pane. This
means each VI can be easily tested before being embedded as a subroutine into a
larger program.
The graphical approach also allows non-programmers to build programs by dragging
and dropping virtual representations of lab equipment which they would already be
familiar with. The LabVIEW programming environment creates an ease of use that
makes it simple to create small applications quickly and efficiently, whether you are
an experienced programmer or not.
[19] This is a benefit on one side, but there is also a certain danger of
underestimating the expertise needed for high-quality G programming. For complex
algorithms or large-scale code, it is important that the programmer possesses an
extensive knowledge of the special LabVIEW syntax and the topology of its memory
management. The most advanced LabVIEW development systems offer the
possibility of building standalone applications. Furthermore, it is possible to create
distributed applications, which communicate by a client/server scheme, and are
therefore easier to implement due to the inherently parallel nature of G.
31. 27 | P a g e
LabVIEW software is ideal for any measurement or control system. It integrates
together all the tools that engineers and scientists need to build a wide range of
applications in dramatically less time. Therefore LabVIEW is a perfect development
environment for problem solving and accelerated productivity.
As a programming language, LabVIEW is far more powerful and versatile then NXT-
G. For basic programming on MINDSTORMS, NXT-G can at times be more user
friendly, but if the user has the proficient programming skills or experience in
LabVIEW, they will always get better results.
32. 28 | P a g e
Finished design:
Figure 14- Final Design of Robot
33. 29 | P a g e
Section 5: Literary Survey
Designing an inverted pendulum system with PID, LQ and Fuzzy Logic are among
the most popular and effective ways to control the pendulum problem. For the project
in hand, LEGO MINDSTORMS NXT is used with implementation of the control
algorithms through LabVIEW. This is a perfectly acceptable way of programming the
inverted pendulum, due to LabVIEW’s ease of use as most of the of the
computational mathematics are calculated internally in LabVIEW, but there are other
options that people in this field have taken.
LEGO NXT Alternatives:
Legway
The first example is from a man named Steve Hassenplug.
[14] The LEGO robot, called
the LegWay, was built to stand on
two wheels and balance, as well as
follow a black line and/or spin in
place. It was built using the RCX and
two EOPD sensors. These RCX
EOPD sensors were early HiTechnic
products that functioned essentially
the same as the current NXT EOPD
sensors.
Figure 15- Legway
34. 30 | P a g e
The EOPDs are based on the IRPD (Infrared Proximity Detector) circuit, but use
visible light to determine distance by checking the detector, sending a pulse of light,
and then checking the detector again to calculate how much of the light is
reflected. This value returned will change based on the distance to an object and the
colour of the object.
For this application, a small change in the value will usually indicate a change in the
distance to the surface, while a large change will represent a change in the surface
colour (white to black) The EOPDs usually do not return a usable distance to a black
surface, since the light is absorbed.
The program for LegWay was written inBrickOS (LegOS) and uses these EOPDs to
maintain a constant distance to the ground. As the distance decreases, LegWay
moves forward. As the distance increases, LegWay moves backward. Every 50 ms,
LegWay attempts to re-calculate the balance point by measuring the current distance
and motor speed. To move forward (for line following) LegWay actually sets the
motors to run backward, causing a tilt, which it automatically corrects, by moving
forward.
When one sensor is over the line, it stops that motor, and LegWay balances using
only the other motor, causing it to turn. To spin in place, both motors are shifted "off
centre" in opposite directions, the same amount, but they still correct for tilting.
The LegWay was built in the way that the main program will follow a line if two
sensors are attached (always moving forward) or attempt to stand still, if only one
sensor is attached.
35. 31 | P a g e
If the motors are set at full power (either direction) for more than 1 second, LegWay
assumes it has fallen over and the program ends.
NXTWay
This version, created by Philippe E. Hurbain, is very similar to Steve Hassenplug’s
LegWay, but instead of using the EOPD senors, it uses the standard LEGO Light
sensor that comes packed with the MINDSTORMS kit.
[15] This control program is much more
rudimentary that the LegWay, but is still sufficient
enough to keep the robot balancing for an amount
of time. Under controlled conditions, the LEGO
Light sensor can also be used to tell distance. The
robot is able to tell if it is leaning forwards or
backwards based on the light sensor value, as long
as lighting and surface are consistent.
Due to the poor resolution of the light sensor, there
were a few constraints to this approach. For
example, during the balancing of the robot, if lighting interferes with the light sensor,
this would give an inaccurate result. As the light levels measured at this time
determine the equilibrium position, this was an impressive accomplishment to get
working.
Figure 16 - NXTWay
36. 32 | P a g e
Segway with Rider
[16] This robot is very similar to the above NXTWay in that it takes advantage of the
packed- in standard colour sensor ( in light sensor mode) using it as a simple
proximity sensor to the ground to detect the approximate tilt angle of the robot.
This inverted pendulum robot used a second NXT brick to make the Segway rider on
this robot lean forward and backwards via Bluetooth remote control, which would
cause the robot to start rolling forward or back while staying balanced, mimicking the
movements of the real Segway.
[17] The Segway program is a basic PID controller that uses the colour sensor's
reading to determine an "error" in its position and then tries to correct for it. If the
robot starts not quite balanced, it will drive steadily in one direction, or perhaps even
accelerate in that direction and then fall. The Segway program does not consider
the robot's forward/backward position when determining the "error" for the PID
controller.
Figure 17- Segway with Rider
37. 33 | P a g e
First Gyro Based NXT Segway
The first gyro sensor based NXT Segway robot came from Ryo Watanabe at
Waseda Uniservity in Japan. The approach that was taken brought with it much
greater stability compared to previous examples. This was due to the previous
approaches not getting information from the wheels rotation angle so internal stability
couldn’t be achieved. His approach paved the way for further gyro sensor based
NXT LEGO segways, and continues to be a point of reference today.
AnyWay LEGO Segway
Laurens Valk created his own version of the NXT Segway using the gyro sensor,
similar to Ryo Watanabe’s attempt. Unlike the Ryo’s aprouch though, the AnyWay is
programmed solely in the LEGO MINDSTORMS programing language NXT-G. This
in itself is an accomplishment, considering how simple the interface of this program
initially seems. Instead of the gyroscopic sensor,
the Dexter Industries dIMU, or the Microinfinity
Cruizcore, can also be used to similar effect.
Figure 18 – Anyway Segway
38. 34 | P a g e
Two Wheeled balancing LEGO Robot:
[13] In 2009, Jonsson Per, Piltan Ali and Rosen Olov designed a different version of
the inverted pendulum problem using the LEGO MINDSTORMS NXT. Their
objective was to design controllers for both balancing as well as line tracking, making
it a more advanced implementation of the inverted pendulum problem seen in this
FYP.
While the physical design of the robot are very similar, their approach to controlling
the system is quite different. While my inverted pendulum was controlled using 3
separate means of control algorithms, their approach was to use two regulators, one
PID regulator and a LQG regulator in unison together.
Software for development and simulation of the regulators were created using
MabLab and its toolbox “control Toolbox”. These regulators were then implemented
and evaluated on the real system using RobotC.
[13] Both the PID and LQG regulators successfully balanced the robot and the LQG
regulator was also able to perform servo regulation, where the reference signals to
the robot were given using a gamepad. The algorithm for line tracking using the light
sensor attached to the front of the robot was implemented and tested. Using this
algorithm, the robot was able to follow an eight shaped track with good robust
performance.
These extra features such as the colour camera for line tracking and control of the
robot using a gamepad give control to the robot that my robot lacks. All these extra
features could theoretically be implemented to the existing model of the project,
given enough time.
39. 35 | P a g e
NXTway-GS Model-Based Design - Control of self-balancing two
wheeled robot built with LEGO MINDSTORMS NXT –
[19] NXTway-GS is a self-balancing two-wheeled robot created by Yorihisa
Yamamoto and built with LEGO MINDSTORMS NXT. It presents Model-Based
Design about balance and drive control of NXTway-GS by using MATALB / Simulink.
The controller of the NXTWay-GS is based on modern control theory, using Linear
Quadratic Regulators to accomplish this. It does this by calculating the feedback gain
and the integral gain.
Instead of using the LEGO steering pad for control of the Segway, he opts to use an
external gamepad to control the movement. Unlike the inverted pendulum LEGO
robot above, Yorihisa Yamamoto created a 3D simulation with the viewer provided
by the Virtual Reality Toolbox in MabLab. The simulation has 4 different camera
angles which can be switched to at any point, allowing the user to see the robot from
every angle and allows them to see if an object such as the wall is near.
Figure 19 - Views from the VR Toolbox
40. 36 | P a g e
Non-LEGO NXT Alteranative
Inverted pendulum on belt/Pulley System
[2] shows an alternative way of designing the inverted pendulum. The inverted
pendulum is mounted on a moving cart. A servomotor is controlling the translation
motion of the cart, through a belt/pulley mechanism. Therefore, the cart is coupled
with a servo dc-motor through pulley and belt mechanism. The motor is derived by
servo electronics, which also contains controller-circuits. A rotary-potentiometer is
used to feedback the angular motion of the pendulum to servo electronics to
generate actuating-signal. Controller circuits process the error signal, which then
drives the cart through the servomotor and driving pulley/belt mechanism. The back
and forth motion of the cart applies moments on the inverted pendulum and therefore
it keeps the pendulum standing upright.
The control system was also implemented in MabLab instead of LabVIEW. This is
usually a more difficult process, since a great advantage of LabVIEW is it does most
of the mathematical calculations internally, which has to be done manually in
MabLab.
Figure 20 - Belt/Pulley Mechanism
41. 37 | P a g e
FPGA and State-Space pole placement control
[9] shows many different approaches that can be used to control a system.
Examples of this are using Field Programmable Gate Array (FPGA), State-space
pole placement control as well as nonlinear techniques such as the energy and
passivity based control, position feedback and robust control. Each of these
approaches have their own advantages and disadvantages.
State space pole placement method gives dynamic behaviour with shorter rise time,
but with overshoot. The optimal state feedback control, results in variable behaviours
without an overshoot, but it takes a longer time to reach the set point. FPGA based
controller works without the support from PC; it also has the flexibility that the
function of the controller can be changed by easily re-downloading the desired new
program. The inverted pendulum dynamic behaviour under Real-Time controller
implemented using different software PC platforms and FPGA is the same. This
result shows that the new FPGA hardware and software technology is reliable.
42. 38 | P a g e
Section 6: Implementation
LabVIEW Code
The following LabVIEW code is modified code from an existing model created by a
team at Hitechnic.com [5]. They created a very robust and stable example of the
inverted pendulum, and the goal was to implement on this, modifying the code to
become more stable through the use of PID, Fuzzy and LQR control algorithms.
Below is a breakdown of the LabVIEW code and how it works.
The LabVIEW program consists of a main VI (Virtual Instrument):
- Balancing program.VI
With 3 subset VI’s.
- ButtonUI.VI
- Gyro_Offset.VI
-BeepWarning.VI
43. 39 | P a g e
Theory behind balancing program:
To fully understand the main balancing program and how it is designed, it is
important to look at the theory behind it. In plain English, the robot balances by going
through a control loop, taking four different types of information from the different
sensors and encodes and using that to determine how much power is needed to
keep the robot standing erect. It does this by using the simple equation:
This simple equation takes each variable and multiplies them by a coefficients and
the summing each product to get the power needed to balance the robot.
The values of these coefficients were found by using pole placement to find what
values gave the best stable response.
Using this method as well as some trial and error led to the values of:
A = 1.15
B = 8.1
C = 0.07
D = 0.1
44. 40 | P a g e
The variables of the power equation are described below:
The gyroSpeed variable is basically the raw output data from the gyro sensor. This is
the angular velocity of the robot. If this value is positive, then the robot is falling
forward and vice versa, if this value is negative the robot is falling backward. A zero
value means the robot is balancing upright. The value from the gyro sensor is
returned in degrees per second.
The gyroAngle is simply the angle of the robot. This is measures in degrees.
Therefore a value of five means the robot is tilted 5 degrees forward. Minus five
would indicate the same but tilted backwards.
The motorPos variable measures the distance the robot has travelled from the
starting position. It does by measuring the amount of degrees the motor has rotated
since the beginning. As the robot moves forward this value increases.
The motorSpeed is how fast the motors are turning. This is measured in degrees per
second also and keeps the robot from excessively oscillating back and forth,
effectively keeps slowing it down. [12]
45. 41 | P a g e
Main balancing program:
This VI is the main program for balancing the inverted pendulum robot, which can be
seen in Appendix E and the UML Diagram in Appendix A. It is also used to call on
each of the other subsets which have to be ran before the main while loop can start.
This program runs continuously until the robot falls over.
[12] The program starts with the first part of the loop measuring how fast the loop is
executed. This time measurement will later be used to calculate the motor speed and
the current tilt angle. This time measurement is able to be performed through the use
each successive time the loop is executed, the current timer value is read, and then
the difference between the previous time and the current time will equal how fast the
loop is executing.
After this has occurs, the program then calculates the variables for the balance
equation by reading the values from the gyro and motors in parallel. The gyro sensor
returns the raw gyro data and this is put through a low pass filter to alleviate any
spikes that may occur in the data, stopping them having a drastic impact
immediately. This raw gyro data is measured in degrees per second. [12] The filter
data is then multiplied by the loop interval rate to give the number of change in tilt
since the last loop execution.
46. 42 | P a g e
The opposite approach is taken for calculating the motor values. The raw data from
the encoders is the change in motor position from the last execution of the loop.
[12] This value is then added to the last motor position read which gives the new
updated motor position. This change in motor position in degrees in divided by the
loop interval time to give the motor speed in degrees per second.
These new variables are then inputted into the balance equation to calculate the
amount of power needed to apply to the motors. This output number for the power is
capped between values of 100 and -100. The equation can output values greater
than this spectrum but the motors will only accept values in between this gap. When
a value greater than this space of numbers it means the robot is too off balance to
correct itself. When this occurs the timer begins and if the timer goes over 1 second,
it means the robot has fallen over. If the robot is able to bring itself under control,
meaning the power value goes below 100, before the timer goes to 1 second, then
the robot will continue to balance and the timer will be reset.
This loop will continue to execute, reading the values and updating the power
equation with the new motor power values. When the robot determines that it has
fallen; when the timer has reached 1 second, the loop will stop executing and will
output text on screen saying the robot has fallen.
47. 43 | P a g e
3 Subset Vi’s
Buttons.VI
The LabVIEW program runs as follows.
First, the program asks the user to enter which wheel size they would like. This
message will always be displayed while this subVI runs. [12] What this does is it sets
a global variable called ratioWheel to either 0.8, 1.0, or 1.4 for respectively the small
NXT 2.0 wheels, the medium sized NXT 1.0 wheels and or the large RCX wheels. It
turns out that the wheel size only needs to play a role with the two gyro sensor terms
and not the motor terms.
The reason that wheel size is important is because bigger wheels need less power to
compensate for being out of balance. Since bigger wheels move further, given a
certain amount of input, less of it is needed to achieve the same amount of
movement.
Figure 21- Buttons.VI
48. 44 | P a g e
Once this occurs, the program enters the main whole loop. A rectangle is drawn on
the screen to clear the text, so the text for the wheel size can appear which was
determined by the use of a case structure box.
The three wheel size values are wired to the selector terminal and this determines
the size of the wheel to be displayed on screen.
[12] The program then successively checks to see if any button on the brick has
being pressed. If at any stage of this check a button is pressed, execution jumps to
the end of the checks. When the enter button is pressed, the entire subVI exits and
the current value is output to represent the wheel size. The UML Diagram can be
seen in Appendix D.
49. 45 | P a g e
Gyro_Offset.VI
Once the initial button.VI has executed and the wheel size has been determined, the
program needs to get an initial gyro offset. [12] This value is required for the gyro
sensor to function. The raw value from the gyro is usually a positive value greater
than zero, therefore to represent a zero value the program must get a value for the
gyro when it at rest and then make up for the offset.
The subVI works by calculating 100 samples of the gyro that are similar to one
another. The program then trys to find 100 roughly equal values, close enough that
they’ll fall within a certain valid range. This valid range is no greater than 2. The
average is then found by summing the 100 values sampled and dividing by 100. This
average value is used for the gyro offset which will represent the value the gyro
sensor outputs when stationary. The program now has the initial values needed for
the robot. The last thing to do is to create a simple program to tell the user to stand
the robot upright. The flow of this program can be seen in Appendix B.
Figure 22- Gyro_Offse.VI
50. 46 | P a g e
BeepWarning.VI
This is a simple program that uses a case structure inside a while loop to count down
from 5. The case structure works as follows. When it is false, it will sound a beep for
100 ms and beep every 0.9 of a second. Each beep is a new iteration and when the
iteration reaches 5, the case structure becomes true and it sounds a long beep for 1
whole second. The while loop then stops and the program continues back to the
main balancing program. The UML Diagram can be seen in Appendix C.
Figure 23 - BeepWarning.VI
51. 47 | P a g e
Section 7: Results/Discussion
Robot Balancing:
The robot successfully balanced with the code working as expected. The robot
balanced with good stable response, giving relatively good susceptibility to step
disturbance, so if the user applied a force to the robot, it would correct itself and stay
upright. The robot would even stay upright when the angle of the surface it was on
would change.
So theoretically, if the robot was further programmed to become drivable through the
use of a gamepad, it would be able to drive up and down relatively low angle slopes
while still staying erect. ;)
Video of the robot standing upright can be found at the link provided [20].
While the video shows the robot falling over when a force is applied, the robot was
more susceptible to disturbance than the video suggests.
Code Failure:
Unfortunately, issues arose with the code that was unforeseeable.
Due to reasons unknown, the code suddenly stopped working, without anything
being altered or changed in any way. This led to weeks of frustration as much time
was spent trying to troubleshoot and fix the unknown issue.
52. 48 | P a g e
Many reasons for this occurrence were discussed. One such reason was the idea
that the gyro sensor may have been damaged during the testing period of the
project, as the robot fell many times during testing. If the gyro sensor was damaged,
the values the program was reading from the gyro may have been wrong; causing
the program to believe the robot has fallen when it was actually still standing upright.
Unfortunately no concrete reason was found and the code was unable to be fixed.
Because of this, no control algorithms were able to be designed and tested. This is
due to the fact that the robot had to be programed to stand upright before any
controller could be used, as the purpose of the controllers was to improve
performance and stability.
Disappointingly, the program wasn’t working long enough to have designs in place
for the controllers. Therefore comparisons of the three controllers weren’t possible.
53. 49 | P a g e
Controller Design Implementation:
While the control algorithms weren’t able to be properly designed or tested, due to
the reasons above, implementation of these controllers ( PID, LQR and Fuzzy) would
have been relatively straight forward thanks to the ease of use of LabVIEW which
already has toolkits in place for each of these algorithms. These toolkits allow the
user to program and control NXT devices with the full power of LabVIEW, as well as
get real time updates from the NXT device during program operation with the
LabVIEW front panels.
An brief insight into how each of these controllers would have been implemented is
explained below.
PID Controller:
LabView PID toolset features a wide array of VIs that greatly help in the design of a
PID based control system.
[10] The PID VI has inputs for output range, setpoint, process variable, PID gains, dt,
and reinitialize? PID gains can be broken into three different input values;
Proportional gain, Integral time, and derivative time.
Figure 24 - PID Block
54. 50 | P a g e
Output range specifies the range of the controller output.. Dt specifies the control-
loop cycle time, with a default value of -1. The reinitialize? Input is used when the
application must be stopped or restarted, without having to shut down the whole
application.
[4] PID palette also features some advanced VIs like the PID Autotuning VI which
helps in refining the PID parameters of a control system. Once an educated guess
about the values of P, I and D have been made, the PID Autotuning VI helps in
refining the PID parameters to obtain better response from the control system.
Figure 25- Advanced PID Block
55. 51 | P a g e
Fuzzy Controller:
The fuzzy logic toolkit itself is very simple to use and in traditional LabVIEW fashion,
the toolkit is a GUI (graphical user interface).
Creating a Fuzzy Logic controller in LabVIEW is quiet straight forward.
[3] First thing to be done is determining the input and output variables. The input
variable is sometimes referred to as the “linguistic Term”, which describes the
variables.
From there, the rules are designated by which the Fuzzy Logic Controller would take
in inputs and “fuzzify” them. From there the set memberships are determined. Once
this is completed “defuzzification” can occur and the appropriate responses are
determined. Basically, a response is calculated for every combination of inputs.
Fuzzy logic is a much more effective controller than PID because it cuts down on
standard deviation of error, creating a more stable and precise system, which is vital
for the inverted pendulum.
Figure 26- Fuzzy Logic GUI
56. 52 | P a g e
Linear Quadratic Controllers in LabView:
[8] Linear quadratic controllers are designed for optimal performance on the system
based on design specification.
There exists a VI in LabVIEW for designing LQR’s and it is used for calculating the
optimal steady-state feedback gain matrix K that minimises a linerar quadratic cost
function that is specified by the user.
LabVIEW also has a built in toolkit that identifies dynamic system models directly
from real-world stimulus and response signals.
An Example of this would be the LabVIEW System Identification Toolkit, shown
below:
Figure 28- LabVIEW System Identification Toolkit
Figure 27 - LQR VI
57. 53 | P a g e
Section 8: Issues and Problems
Many problems and issues arouse throughout the length of this final year project,
both in terms of the hardware and the software.
Hardware:
1. NXT microprocessor freezing: The NXT microprocessor requires a firmware
update to be able to connect and run programs from LabVIEW. During this
firmware update, the NXT brick froze in a continuous loop, making it
unusable. Fortunately this is a known issue with the LEGO MINDSTORMS
and an answer was found relatively quickly and was easy to remedy. This
issue set the project back only a few days.
2. Gyro Sensor: The gyroscopic sensor, which is used to accurately detect
rotation for the inverted pendulum, didn’t come packaged with the LEGO
MINDSTORM kit. This had to be ordered separately. Unfortunately the order
got delayed, meaning it didn’t arrive for three weeks.
3. Re-design of inverted pendulum: The original design for the inverted
pendulum was a much taller robot. This extra height meant it also has a
higher centre of gravity. Through research, it was found that having the robot
that high created unwanted oscillation and instability. The redesign of the
robot is much smaller now, with a more square-like shape, making it more
robust and stable and therefore, balance better.
58. 54 | P a g e
Software:
1. Inconsistency with Software Programs:
During the development time of the project, several cases of inconsistency in
LabVIEW and MabLab were encountered.
i. When testing the balancing equation of the inverted pendulum in
LabVIEW, there would be instances where the program would
run and the robot would fall immediately. Trying this in a
different room would suddenly make the robot balance perfectly,
without any change to the code. This was a very annoying and
infuriating process, costing the project large amounts of time
trying to fix code that may actually have been working.
ii. A similar problem occurred when testing in MabLab. During the
research period of the project, testing of balancing systems on
other programs such as MabLab was taking place. The problem
that arose was also based on inconsistency. When running the
program, it may encounter an error, stopping the program from
executing. On several occasion if the program was run again,
that same error may not appear at all. Similarly, restarting
MabLab would also remove errors on certain occasions. This
trial and error process was also very frustrating.
59. 55 | P a g e
Section 9: Future Work
Working with the LEGO MINDSTORMS NXT is an enlightening experience because
it is such a versatile robotics kit that is a much more capable design platform than it
first seems. It has incredible potential, making it very possible to build upon this
existing project.
One possibility would be the addition of a gamepad or driving controller for movability
of the inverted pendulum robot. With this, the user would be able to control the robot,
driving it back and forth, while also giving it turning abilities. This implementation has
already been accomplished and can be seen in the Jonsson Per, Piltan Ali and
Rosen Olov design of the inverted pendulum.
Another possibility would be the addition of extra sensors to give the LEGO robot
extended knowledge of its surroundings. The addition of an ultra-sonic sensor, which
is supplied in the original Kit, could be implementing to allow the robot to sense when
it is near objects, similar to object-detection robot discussed in Section 3.
Further implementation could be accomplished by combining the two additions,
creating a balancing robot that can be completely controllable through the use of a
gamepad while also having a sensor to tell the user whether the robot is steering
close to an object. This could be accomplished through the use of a simple LabVIEW
beeping program to illustrate to the user an object is near.
60. 56 | P a g e
Section 10: Conclusion
What was learnt?
Throughout the period of this project, a lot of knowledge was gained, not just from
the successes of the project but also from the mistakes. The objectives that were
set at the beginning of this project were met, with an in-depth understanding of the
core concepts of control theory gained as well as a greater knowledge of the
requirements for the operation of robotic and automated systems. As well as this,
knowledge of LabVIEW and how it relates to the programming and automation of
robotics was greatly improved.
While all of these are important, most of the knowledge was gained from the
mistakes that were made. Looking back, time management and fore-sight would the
main things to take from the mistakes that were made.
During the period when the code wasn’t working, it may have been more beneficial
to put aside the balancing program, concentrating on designing the control solutions.
Unfortunately, this couldn’t really be done, as the amount that could be designed
was limited, as it hindered completely on the balancing program working.
Nevertheless, having the fore-sight to spend less time on the balancing program and
more time on the control algorithms may have benefited the project more.
61. 57 | P a g e
Conclusion:
In conclusion, the robot demonstrated the theory of the inverted pendulum
successfully, balancing the robot with good robustness against disturbance.
Reiterated what was said before, comparisons between the three control algorithms
wasn’t possible, due to the program not performing like expected.
While the robot may not have been able to be tested fully, it still shows and
represents the fundamentals and the principles that were in place.
62. 58 | P a g e
Section 11: Appendix
Appendix A – Main Balancing
ButtonsUI.vi
(Select Wheel)
Gyro_Offset.vi
BeepWarning.vi
Calculate Loop
Rate
Get Gyro Data
Calculate Power
With Balance equation
Reset Motor Encoders
Power Motors
Power between -
100 to 100
Display
“Lay Down Robot”
Get Gyro Data
Reset Timer
Timer<1 sec
Stop Motors
Display Fall Message
Figure 29- HTWay.vi UML
Diagram
63. 59 | P a g e
Appendix B – Gyro_Offset
Max = 500
Min = -500
Sum = 0
Count =0
gyroVal = ReadGyro()
Max = gyroVal
Count = 1
Max – Min > 2
gyroVal > Max
Max = Min Max = gyroVal
gyroVal < Min
Max = Min
Count = Count + 1
Sum = Sum + gyroVal
Count = 100?
Gyro Offset = sum/count - 1
Output Gyro Offset
True
False
Figure 30- Gyro_Offset.vi UML Diagram
False
64. 60 | P a g e
Appendix C - BeepWarning
Display
“Balance in
Seconds”
Count =5
Count = Count - 1
Display
Count
Count = 0?
Long Beep
Display
“Balancing”
Long Beep
True
False
Figure 31- BeepWarning.VI UML
Diagram
65. 61 | P a g e
Appendix D - Buttons
Select = 3
Erase rectangle
Erase wheel option
Screen value =
Large Wheels
Select =
Display
Screen value
Check to see if any buttons
are pressed
True or false
Screen value =
medium Wheels
Screen value =
Small Wheels
Right button
Left button
Enter button
Select = Select + Button
Button = 3
Output Wheelsize = Select
Select = 0 Select = 2
Select = 1
True
False
Button = 1
Button = 2
Button = 3
False
True
Figure 32 – Button.VI UML Diagram
Display
wheelsize”
[select]
66. 62 | P a g e
Appendix E – Labview Block Diagram
Figure 33 - LAbview Block Diagram
67. 63 | P a g e
Appendix F: LEGO MINDSTORMS Component list
Figure 34 - Component List
68. 64 | P a g e
Appendix F: Gantt Chart
Action Plan
Figure 35 - Gantt Chart
69. 65 | P a g e
References:
Bibliography
[1] National Instruments, “Fuzzy Logic G Toolkit,” March 1997. [Online]. Available:
http://www.ni.com/pdf/manuals/321511a.pdf.
[2] K. Sultan, “Inverted Pendulum,” 23 July 2003. [Online]. Available:
http://www.engr.usask.ca/classes/EE/480/Inverted%20Pendulum.pdf.
[3] W. Green, “Introduction to Fuzzy Logic,” Argonne National Laboratory, [Online]. Available:
http://users.sdsc.edu/~hubbard/neesgrid/fuzzy/.
[4] National Instruments, “PID Theory Explained,” NI Developer Zone, 29 March 2011. [Online].
Available: http://www.ni.com/white-paper/3782/en#toc4.
[5] N. G. Sensor, “HiTechnic NXT,” [Online]. Available: www.hitechnic.com/cgi-
bin/commerce.cgi?preadd=action&key=NGY1044.
[6] N. N. B. Awang, “Inverted Pendulum Systems,” Faculty of Electronic and Computer
Engineering , May 2008. [Online]. Available:
http://eprints2.utem.edu.my/2885/1/Nor_Najihah_Binti_Awang_TJ223.P55.N68_2008_-
_24_pages.pdf.
[7] National Instruments, “Improving PID Controller Performance,” NI Developer Zone, 03
December 2009. [Online]. Available: http://www.ni.com/white-paper/7438/en#toc6 .
[8] F. Haugen, “Mathematical Model of a Pendulum on a cart,” TechTeach, 11 July 2011. [Online].
Available: http://techteach.no/simview/pendulum/pendulum_model.pdf.
[9] R. T. m. I. a. S. B. m. I. Y. Han, “MATLAB, LabVIEW and FPGA Linear Control of an Inverted
Pendulum,” IEEE, [Online]. Available:
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4401454.
[10] LEGO, “LEGO MINDSTORMS,” LEGO, [Online]. Available: http://MINDSTORMS.lego.com/en-
us/history/default.asp.
[11] HiTechnic, “HTWay – A Segway type robot,” HiTechnic, 08 November 2010. [Online].
Available: http://www.hitechnic.com/blog/gyro-sensor/htway/.
[12] “Inverted Pendulum with LabVIEW”.
[13] P. A. R. O. Jonsson Per, “Two Wheeled Balancing LEGO robot,” 17 September 2009. [Online].
Available:
http://www.it.uu.se/edu/course/homepage/styrsystem/vt09/Nyheter/Grupper/Rapport_gro
70. 66 | P a g e
up6.pdf.
[14] Steve, “Steve's LegWay,” [Online]. Available:
http://www.teamhassenplug.org/robots/legway/.
[15] “NXTWay,” August 2007. [Online]. Available:
http://www.philohome.com/nxtway/nxtway.html.
[16] D. Parker, “NXT Segwat with rider,” [Online]. Available:
http://www.nxtprograms.com/NXT2/segway/index.html.
[17] D. Parker, “Building Instructions, Segway rider,” [Online]. Available:
http://www.nxtprograms.com/NXT2/segway/steps.html.
[18] Y. Yamamoto, “NXTway-GS Model-Based Design,” CYBERNET SYSTEMS CO., LTD, 03 March
2008. [Online]. Available:
http://www.pages.drexel.edu/~dml46/Tutorials/BalancingBot/files/NXTway-GS%20Model-
Based_Design.pdf.
[19] T. O'Shea, “Line Follower Robot,” 2012.
[20] B. Reidy, “Inverted Pendulum NXT,” 2012. [Online]. Available:
http://www.youtube.com/watch?v=eEAGL7SjNCs.
