Chapter 1

Introduction
1.1 Overview

To make a self-balancing robot, it is essential to solve the inverted pendulum

problem or an inverted pendulum on cart. Inverted pendulum applications are
plenty; for example, the human body is an inverted pendulum balancing the
upper body around our ankle joints in every step. In the recent decade Segway,
making use of bodily movements for steering, have emerged on the market. In
common, these applications share that their centre of mass is located above their
pivot points, thus requiring active control in order to balance. [9]

The platform will not remain stable itself. Our job will be to balance the
platform using distance sensors and to maintain it horizontal. At first, we have
decided to just balance the robot on its two wheels. If the platform inclines then
microcontroller (in this case it is Arduino) will send signals to motors such that
motors would move forward or backward depending on the inclination direction
and extent. So, if the platform tilts forward then motors will run forward and
vice-versa to keep the platform horizontal. A PID-controller is able to control
the pendulum angle, since it is a SISO - Single Input Single-Output system. If
the robot should be able to be controlled in regard to position, x, as well as the
angle, it is a MIMO Multiple-Input Multiple-Output system and one PID-
controller is not enough. Controlling multiple states is conveniently made
through a state space controller.

For this we will need to code the Arduino in order to perform job according to
this. The open source community is full of instructions and code snippets, many
making use of the open source micro controller Arduino for control algorithms.

1
 Figure 1.1 Self Balancing Robot

1.2 Two Wheeled Balancing Robots

A robot that is capable of balancing upright on its two wheels is known as a two
wheeled balancing robot. The following figure contains the physical view for
the robot designed as part of this project. The process of balancing is typically
referred to as stability control. The two wheels are situated below the base and
allow the robot chassis to maintain an upright position by moving in the
direction of tilt, either forward or backward, in an attempt to keep the centre of
the mass above the wheel axles. The wheels also provide the locomotion thus
allowing the robot to transverse across various terrains and environments.

This type of robot provides a challenging problem and has resulted in many
useful and interesting designs being developed. One such two wheeled robot
that has become a commercial success is the Segway by Segway Inc. The
immediate impact has been within the personal transportation area where an
alternative to cumbersome wheelchairs is now available. Segway proves a
comfortable mobility opportunity for the elderly or people with disability thus
improving their individual sense of independence at the same time.

2
 Figure 1.2 Views of the
two wheeled balancing robots

Figure 1.3 Displacement, velocity and acceleration parameters

3
 Figure 1.4 Inverted pendulum parameters

The following equations will provide a reliable and accurate model for
developing and implementing a suitable non-linear control system for the two
wheeled balancing robots.

Angular acceleration

Horizontal acceleration

4
 Chapter 2
Discussion
2.1 Model definition

The physical problem of the balancing robot is well described by the widely
analysed inverted pendulum. It is commonly modelled as a rigid rod fastened by
a frictionless joint to a rigid cart moving in one direction. The simplification
that the wheel base can be seen as a cart sliding on a frictionless surface was
made.

Figure 2.1: The 3 degrees of freedom of the system (source: Anderson, 2003)

The robot has the ability to rotate around the z-axis (pitch) by an angle θp with a
corresponding angular velocity ωp. The linear movement of the robot is
characterized by the position xRM and the velocity vRM. Furthermore, the robot
can rotate about the vertical axis (yaw) by an angle δ with a corresponding
angular velocity δ ̇.

5
The control system of the robot would be based on two state controls
implemented through software: one controlling the stability around the lateral
axis (pitch) and a second one about the vertical axis (yaw). Both state controls’
outputs would then be combined and the robot’s motion would be controlled by
applying torques CL and CR to the corresponding wheels. Equations R1 and R2
can be used to calculate the individual torques required for the robot’s motion.

……. 1

……. 2

Where R1 models the robot when it is balanced at a stationary position and R2

models the robot when it is turning about its y-axis while maintaining a
balanced posture (see Appendix A. for the derivation and the coefficient
values).

Figure 2.2. Simplification steps of the inverted pendulum

2.2 Control Algorithm Design

Since calculating the pitch angle θp accurately is crucial for the self-balancing
apparatus, a few methods were considered in order to measure the pitch angle
and its rate of change.

2.2.1 Using an IR Tilt Sensor

A method that is very popular with hobbyists is to use two infra-red sensors
(as a future scope) placed on either side of the robot. The control algorithm uses
the sensors to measure the distance to the ground on either side of the robot. By
comparing the values from the two sides, it is able to determine the pitch angle
accurately.

6
This method uses very little hardware and requires a very simple control
algorithm.

2.2.2 Using the Accelerometer

A Freescale Semiconductor MPU6050 three-axis accelerometer located on the

cricket board can be used to get acceleration values in three-dimensions.
Accelerations oriented in the y (upwards) and x (forward) directions would
provide a way to measure the direction of gravity and subsequently calculate the
pitch angle as per Equation (3). This system is illustrated in Figure 2.3

θp = arctan ax/ay …………. 3

However, when the robot is on the move, the horizontal acceleration would be
added to the accelerometer readings. Due to this, the pitch angle can no longer
be determined accurately. Hence this method, used alone, will not be ideal.

Accelero
Gyroscope
-meter

Calculate
Pitch
Angle
Control
Algorithm
PID
Controller

Motor

Figure 2.3: control system for accelerometer only algorithm

2.2.3 Using a Gyroscope

The MPU6050 is also equipped with three rate gyroscopes. A rate gyroscope
measures the angular velocity and the signal can be integrated numerically (by

7
using a simplified Runga-Kutta method) as in equation (4) to obtain the pitch
angle.
θp (i) = θp (i-1) + 1 ⁄ 6 (vali-3 + 2 vali-2 + 2 vali-1 + vali) ……. 4

An illustration of this system is shown in Figure 2.4.

Accelero
Gyroscope
-meter

Calculate
Pitch
Angle
Control
Algorithm
PID
Controller

Motor

Figure 2.4: control system for the gyroscope only algorithm

A common drawback of gyroscopes is that there exists a small DC bias which,

upon integration, would cause the zero point to drift overtime. Hence, a
balancing robot based solely on a gyroscope would be vertical for a few seconds
and eventually fall over due to the drift of the zero point

8
 Chapter 3
Demonstration
3.1 Hardware

To construct an ordinary self-balancing robot, we need following instruments:

i. Arduino ATmega 2560
ii. MPU6050
iii. L293D
iv. Li-ion battery
v. 2 Wheels
vi. 120 rpm 12 V motors
vii. And other necessary stuffs (acrylic sheets, connecting wires, PCB,
Glue Gun, Double sided tape, etc)

3.1.1 Arduino ATmega 2560

Arduino is an open-source electronics platform based on easy-to-use hardware

and software. Arduino boards are able to read inputs - light on a sensor, a finger
on a button, or a Twitter message - and turn it into an output - activating a
motor, turning on an LED, publishing something online. You can tell your
board what to do by sending a set of instructions to the microcontroller on the
board. To do so you use the Arduino programming language (based on Wiring),
and the Arduino Software (IDE), based on Processing.

All Arduino boards are completely open-source, empowering users to build

them independently and eventually adapt them to their particular needs.
The software, too, is open-source, and it is growing through the contributions of
users worldwide.

Why Arduino?
The Arduino software is easy-to-use for beginners, yet flexible enough for
advanced users. It runs on Mac, Windows, and Linux. Teachers and students
use it to build low cost scientific instruments, to prove chemistry and physics
principles, or to get started with programming and robotics. Designers and
9
 architects build interactive prototypes, musicians and artists use it for
installations and to experiment with new musical instruments.

Arduino also simplifies the process of working with microcontrollers, but it

offers some advantage for teachers, students, and interested amateurs over other
systems:

 Inexpensive - Arduino boards are relatively inexpensive compared to other

microcontroller platforms.
 Cross-platform - The Arduino Software (IDE) runs on Windows, Macintosh
OSX, and Linux operating systems. Most microcontroller systems are limited to
Windows.
 Simple, clear programming environment - The Arduino Software (IDE) is easy-
to-use for beginners, yet flexible enough for advanced users to take advantage
of as well.

Open source and extensible software - The Arduino software is published as

open source tools, available for extension by experienced programmers. The
language can be expanded through C++ libraries, and people wanting to
understand the technical details can make the leap from Arduino to the AVR C
programming language on which it's based.

Features of the Arduino UNO:

 Microcontroller: ATmega328
 Operating Voltage: 5V
 Input Voltage (recommended): 7-12V
 Input Voltage (limits): 6-20V
 Digital I/O Pins: 14 (of which 6 provide PWM output)
 Analog Input Pins: 6
 DC Current per I/O Pin: 40 mA
 DC Current for 3.3V Pin: 50 mA
 Flash Memory: 32 KB of which 0.5 KB used by bootloader
 SRAM: 2 KB (ATmega328)
 EEPROM: 1 KB (ATmega328)
 Clock Speed: 16 MHz

10
 Figure 3.1 Arduino UNO

3.1.2 Accelerometer and Gyroscope (MPU6050)

The MPU-60X0 is the world’s first integrated 6-

axis Motion Tracking device that combines a 3-
axis gyroscope, 3-axis accelerometer, and a Digital
Motion Processor all in a small 4x4x0.9mm
package. With its dedicated I2C sensor bus, it
directly accepts inputs from an external 3-axis
compass to provide a complete 9-axis Motion
Fusion output. The MPU-60X0 Motion Tracking
device, with its 6-axis integration, on-board
Motion Fusion, and run-time calibration firmware,
enables manufacturers to eliminate the costly and
complex selection, qualification, and system level
integration of discrete devices, guaranteeing
optimal motion performance for consumers. The
MPU-60X0 is also designed to interface with Figure 3.2. MPU6050
multiple noninitial digital sensors,

11
such as pressure sensors, on its auxiliary I 2C port. The MPU-60X0 is footprint
compatible with the MPU-30X0 family.

The MPU-60X0 features three 16-bit analog-to-digital converters (ADCs) for

digitizing the gyroscope outputs and three 16-bit ADCs for digitizing the
accelerometer outputs.
An on-chip 1024 Byte FIFO buffer helps lower system power consumption by
allowing the system processor to read the sensor data in bursts and then enter a
low-power mode as the MPU collects more data. With all the necessary on-chip
processing and sensor components required to support many motion-based uses
cases, the MPU-60X0 uniquely enables low-power Motion Interface
applications in portable applications with reduced processing requirements for
the system processor.

Figure 3.3 Connecting MPU6050 with Arduino

By providing an integrated Motion Fusion output, the DMP in the MPU-60X0

offloads the intensive Motion Processing computation requirements from the
12
system processor, minimizing the need for frequent polling of the motion sensor
output. Communication with all registers of the device is performed using either
I2C at 400kHz or SPI at 1MHz (MPU-6000 only).

Figure 3.4 Pin Diagram of MPU6050

3.1.3 Motor controller L293D

The L293 and L293D are quadruple high-current half-H drivers. These devices
are designed to drive a wide array of inductive loads such as relays, solenoids,
DC and bipolar stepping motors, as well as other high-current and high-voltage
loads. All inputs are TTL compatible and tolerant up to 7 V.

Each output is a complete totem-pole drive circuit, with a Darlington transistor

sink and a pseudo-Darlington source. Drivers are enabled in pairs, with drivers
1 and 2 enabled by 1,2EN and drivers 3 and 4 enabled by 3,4EN. When an
enable input is high, the associated drivers are enabled, and their outputs are
active and in phase with their inputs. When the enable input is low, those
drivers are disabled, and their outputs are off and in the high-impedance state.
With the proper data inputs, each pair of drivers forms a full-H (or bridge)
reversible drive suitable for solenoid or motor applications.

Figure 3.5 Pin Diagram of L293D

13
 Figure 3.6 Connecting L293D with Arduino

3.1.4 Motor

Figure 3.7. DC Motor

For constructing the self-balancing robot, we can use any type of motor such as
DC motor, brushless motor, gear motor, etc. and lies between 100rpm to 150
rpm. But we considered DC motor as Generally, three characteristic curves are
considered important for DC motors which are, (i) Torque vs. armature current,
(ii) Speed vs. armature current and (iii) Speed vs. torque. These are explained
below for each type of DC motor. These characteristics are determined by
keeping the following two relations in mind.

Ta ∝ ɸ.Ia and N ∝ Eb/ɸ

14
3.1.5 Construction of physical demonstrator

The demonstrator was designed both physically and in CAD. The used CAD
program is Circuit labs.
The battery is the component with the greatest value of density. The placement
of the battery at the top is to make sure that the centre of mass is located above
the pivot point. All the other components are placed close to each other to avoid
interference that comes with longer wires.

MPU6050

Arduino Uno

Encoder A Motor A
Motor Driver
L293D
Encoder B Motor B

Figure 3.8. Simple schematics of the used hardware and their

communication

3.1.6 Software

Software for the demonstrator, assembled and created in the Arduino

environment is presented schematically in Figure 3.9. A PWM-library was used
in order to transport the raw data from the IMU all the way to how the motors
behave, in terms of direction and PWM.

15
Figure 3.9. Simplified schematics of the software chain used for the validation
process

Software/editor used for the writing the program code is Arduino IDE v1.8.8
can be installed on Windows, Linux, Mac platform.

16
 Chapter 4
Initialising

4.1 Connections

Making the connections for this Arduino based Self balancing Robot is pretty
simple. We just have to interface the MPU6050 with Arduino and connect the
motors though the Motor driver module. The whole set-up is powered by the
7.4V li-ion battery. The circuit diagram for the same is shown Figure 4.1.
The Arduino and the L298N Motor driver module is directly powered through
the Vin pin and the 12V terminal respectively. The on-board regulator on the
Arduino board will convert the input 7.4V to 5V and the ATmega IC and
MPU6050 will be powered by it. The DC motors can run from voltage 5V to
12V. But we will be connecting the 7.4V positive wire from battery to 12V
input terminal of motor driver module. This will make the motors operate with
7.4V.

17
 Figure 4.1: Figure showing the connections

4.2 Programming

#include <PID_v1.h>
#include <LMotorController.h>
#include "I2Cdev.h"
#include "MPU6050_6Axis_MotionApps20.h"

#if I2CDEV_IMPLEMENTATION == I2CDEV_ARDUINO_WIRE

#include "Wire.h"
#endif

#define MIN_ABS_SPEED 20

MPU6050 mpu;
18
// MPU control/status vars
bool dmpReady = false;
uint8_t mpuIntStatus;
uint8_t devStatus;
uint16_t packetSize;
uint16_t fifoCount;
uint8_t fifoBuffer[64];

Quaternion q;
VectorFloat gravity;
float ypr[3];

//PID
double originalSetpoint = 173;
double setpoint = originalSetpoint;
double movingAngleOffset = 0.1;
double input, output;

//adjust these values to fit your own design

double Kp = 50;
double Kd = 1.4;
double Ki = 60;
PID pid(&input, &output, &setpoint, Kp, Ki, Kd, DIRECT);

double motorSpeedFactorLeft = 0.6;

double motorSpeedFactorRight = 0.5;
//MOTOR CONTROLLER
int ENA = 5;
int IN1 = 6;
int IN2 = 7;
int IN3 = 8;
int IN4 = 9;
int ENB = 10;
LMotorController motorController(ENA, IN1, IN2, ENB, IN3, IN4,
motorSpeedFactorLeft, motorSpeedFactorRight);

volatile bool mpuInterrupt = false; // indicates whether MPU interrupt pin has
gone high
void dmpDataReady()
{
mpuInterrupt = true;
}
19
void setup()
{
// join I2C bus (I2Cdev library doesn't do this automatically)
#if I2CDEV_IMPLEMENTATION == I2CDEV_ARDUINO_WIRE
Wire.begin();
TWBR = 24; // 400kHz I2C clock (200kHz if CPU is 8MHz)
#elif I2CDEV_IMPLEMENTATION == I2CDEV_BUILTIN_FASTWIRE
Fastwire::setup(400, true);
#endif

mpu.initialize();

devStatus = mpu.dmpInitialize();

mpu.setXGyroOffset(220);
mpu.setYGyroOffset(76);
mpu.setZGyroOffset(-85);
mpu.setZAccelOffset(1788);

if (devStatus == 0)
{
mpu.setDMPEnabled(true);

// enable Arduino interrupt detection

attachInterrupt(0, dmpDataReady, RISING);
mpuIntStatus = mpu.getIntStatus();

dmpReady = true;

packetSize = mpu.dmpGetFIFOPacketSize();

pid.SetMode(AUTOMATIC);
pid.SetSampleTime(10);
pid.SetOutputLimits(-255, 255);
}
else
{

20
Serial.print(F("DMP Initialization failed (code "));
Serial.print(devStatus);
Serial.println(F(")"));
}
}

void loop()
{

if (!dmpReady) return;

while (!mpuInterrupt && fifoCount < packetSize)

{

pid.Compute();
motorController.move(output, MIN_ABS_SPEED);

mpuInterrupt = false;
mpuIntStatus = mpu.getIntStatus();

fifoCount = mpu.getFIFOCount();

if ((mpuIntStatus & 0x10) || fifoCount == 1024)

{

mpu.resetFIFO();
Serial.println(F("FIFO overflow!"));

}
else if (mpuIntStatus & 0x02)
{
while (fifoCount < packetSize) fifoCount = mpu.getFIFOCount();

// read a packet from FIFO

mpu.getFIFOBytes(fifoBuffer, packetSize);

// track FIFO count here in case there is > 1 packet available

// (this lets us immediately read more without waiting for an interrupt)
fifoCount -= packetSize;
21
mpu.dmpGetQuaternion(&q, fifoBuffer);
mpu.dmpGetGravity(&gravity, &q);
mpu.dmpGetYawPitchRoll(ypr, &q, &gravity);
input = ypr[1] * 180/M_PI + 180;
}
}

4.2 PID Controller

A proportional-integral-derivative controller is a generic feedback controller.

PID controller processes the "error" as the difference between a measured
output and a desired given reference and tries to minimize the error by adjusting
the control parameters.

Figure 4.2. PID Control Parameter

22
Giving look towards how the PID controller works in a closed-loop system
using the system variable. ‘e’ represents the system error due to both system
noise and measurement noise, the difference between the desired output value
and the actual output produced. This error signal is given to the PID controller,
and the controller determines both the derivative and the integral of this error.
The input to the plant should be the summation of derivative constant multiplied
by derivative error, proportional constant times the proportional error and
integral times the integral error. When control signal (u) will sent to the plant as
the only input, and the output (y) is obtained according to the given input. The
new output (y) is then given back and subtracted to the desired reference to find
error signal (e) again and the loop continues. The PID takes this error and
calculates its control constants.

23
 Chapter 5
Discussion and conclusions
5.1 Discussion

The results of the validation process show that the model is currently not precise
enough to be implemented with LQR-control. The purpose of the validation was
that its results could serve as an indication of what in the model causes the error.
Since the discrepancy between the model and the demonstrator was concluded
to be large regarding the settling time, no unequivocal conclusion of what
causes the error was drawn. The cause of the large error most likely lies within
some of the assumptions made in the development of the model as listed below:

 The robot only moves in one direction of freedom

 The robot was represented as a pendulum attached to a cart
 The cart was represented as the motors with wheels, and the pendulum
was represented as the rest of the components
 The linearization is for angle deviation values close to its upright
position.
 The friction in the system is reduced to a constant proportional to the
velocity of the cart.
 The noise and delay in the angle measurement unit is insignificant

Furthermore, a compromise regarding the motor speed was made.

The assumption that the robot only moves in one direction of freedom is
considered to be realistic since it was seen in the demonstrator that the robot
only moves as mentioned. The simplification that the robot consists of a cart
and pendulum was made from it being a common assumption in similar
projects. In these projects the reliability of that assumption has not been
discussed, and that has been perceived as the simplification being reasonable.

Although the assumption of what part of the model the components belong to is
difficult to determine. The idea was that the components belonging to the

24
pendulum should all follow the movement of the pendulum and the components
related to the cart was rigid relative to the pendulum.

The friction in the system is summarized as a constant, f proportional to the

velocity of the cart. The value of this parameter is taken from a similar project.
How they came up with this value was not motivated. It was tested to vary this
parameter, but better results were not achieved. It is probably not the parameter
itself that is inaccurate. It is rather the assumption that all friction in the system
can be reduced to a parameter proportional to the velocity that is the problem.
The friction in the system is more complex than that. In fact, there are several
parts of the model where friction should be added. For example, the motor has a
static and dynamic friction, and this is probably an important factor since the
motors change direction often. For future work, the mentioned needs to be
investigated for a more accurate model. The assumption that the noise and delay
of the angular data could be ignored was made because adding it to the model
would make it more complex, and it was assumed that it would not make a
noticeable difference though these disturbances was minor. Though, for future
work, this is recommended. Especially if other measurement unit will be used,
the model will be more flexible.

The lacking speed of the motor is a problem. Though the demonstrator archived
to balance with a PID-control it could not handle bigger impulses than shown in
the results. For future work, a faster motor is recommended.

5.1.1 Difficulties Experienced

The difficulties experienced throughout the project include theory, hardware,

software and programming related problems. The main theoretical difficulty
encountered was associated with understanding the operation and mathematics
behind Kalman filtering techniques. This was necessary for implementing
sensor fusion of the inertial sensors within the programming. This aspect would
have required substantial time to rectify hence the simpler approach of
following the programming provided by Simon (2001) was pursued.

Gaining a thorough understanding of fuzzy control systems and their

implementation appeared to take a substantial amount of time early within the
project. The tuning and simulating aspects could have been further investigated
possibly leading to the development of an adaptive (self-tuning) fuzzy
controller. This would have been a substantial improvement over the fuzzy
controller implemented as part of the project.

The 1:52 gear head supplied with the right drive motor stripped the teeth off a
cog within a very short period of operation. Unfortunately, the item was
25
supplied from the USA which delayed the assembly stage for some time. It is
unclear at this time if the gear head and motor combination is suitable for the
loads and weight of the derived robot. Difficulty was also experienced in
acquiring critical components such as the 7805 and 7812 voltage regulators.
These remained on back order for six weeks before they were eventually
received.

The interaction system encountered several difficulties early in the project. On

installation, the interaction computer was functioning and it appeared that the
visual basic software development would be relatively straight forward. It was
then discovered that an incompatibility between the computer and PCI host
adaptor was causing the computer system to crash. This was soon followed by a
hard drive failure causing the stage to exceed the allocated timeframe. It was at
this time the interaction system was deemed non-essential and no longer
pursued.

Programming of the microcontroller proved to be the most difficult challenge of

the entire project. Although learning C programming was not overly difficult,
completing the hardware initialisation, fuzzy controller, Kalman filter and other
subroutines within the programming caused excessive time consumption for the
project. This was further compounded as the simulation phase could not be
adequately completed. It is unlikely that the project would have been as
completed on time if the simulation modelling was pursued fully even though a
robust program could have been developed.

5.1.2 Design Advantages and Disadvantages

The shape, size and layout of the robot proved the most advantageous aspects of
the robot’s design. The cylinder shape proved ideal for manoeuvring on the
spot. This was evident during assembly and performance maintenance activities
on the robot as turning it on the spot allowed easy access from the one location.
The child like size made the robot easy to move, handle and to access each of
the layers. The platform layout allowed grouping of systems and PCB’s without
overcrowding thus sampling the maintenance and fault-finding procedures.

There were no disadvantages discovered with the design of the robot. The
battery posed a potential disadvantage from its inherent weight of 7 Kg. This
accounts for a significant portion of the total weight as well as the space
required to store it within the robot’s chassis. The impact from the battery may
have been reduced by selecting a smaller physical size and rated battery but
then the capability and operability would be adversely affected. There is also a
potential that the motor and gear head combination may have been underrated
for the specific task.
26
5.1.3 System Performance and Results

The actual performance of the hardware aspects of the robot cannot be fully
guaranteed without completion of the microcontrollers programming. It is
anticipated that the manufactured robot would have been fully capable in
achieving stability, locomotion and interaction streaming. No actual
performance results are available at this time.

5.1.4 Results versus Expectations

At the beginning of the project, the expectations were quite substantial. The
goal was to develop a robot that was so robust that it could recover from
significant and deliberately induced tilt. As problems and difficulties started to
become evident in the programming, the expectations reduced to simply
providing a robot that could maintain stability. Incompletion of the program has
proved devastating as hence the results are not reflective of the expectations.

5.2 Conclusions

Modelling based on the inverted pendulum shows that the system is unstable
without a controller. A simple PID-controller can be implemented, but only to
control the angle deviation, ψ.

Since the demonstrator can receive angular data and position data, it is possible
to get data for all the states that are required for a state space controller.

The results of the validation process demonstrate that the model is not reliable.
That conclusion was made because of the big difference in settling time of the
impulses between the physical demonstrator and the corresponding simulation.
Reasons why the model in not reliable was discussed, where it was
recommended that the friction of the system should be investigated more
closely.

All required hardware for a robot controlled via LQR is mounted on the
demonstrator, so if the errors in the model are handled, the demonstrator is fully
prepared for implementation. Though, if the demonstrator is supposed to handle
impulses bigger than 8°, faster motors are recommended.

27
 Chapter 6
Future Scope
6.1 Recommendations

6.1.1 Improvements and Alterations

Improvements to the current version of the robot can easily be achieved through
the microcontrollers programming. This would provide the fundamental
benefits faster control responses, effective and efficient computations and
improved overall system performance. Completing the software implementation
of the interaction system would allow the operator to have video and audio
streaming capabilities, locomotion control and microcontroller reprogramming
capability. Although the hardware would not require any significant change, the
completion of visual basic programs would complete the process.

The used motors, DC motor have a rated speed of 120 rpm, it was determined
that it was too slow if the robot is going to handle impulses of greater
magnitude than 8°. Eventually, when an LQR-controller is implemented, the
robot should also be able to control steps. If the demonstrator cannot handle
small impulses it would probably not be able to handle steps either. Therefore,
the recommendation is to acquire faster motors.

6.2 Future Scope

The friction in the system needs to be investigated and added to the model.
When the model works properly the demonstrator is ready to implement the
theoretically derived LQR-control. With LQR the system will become faster
and can handle both disturbances as impulses and steps. It is also possible to
change the reference of the position that enables navigation of the robot.

Low noise reference voltage circuit board can be used to regulate the conversion
by providing an accurate voltage reference to the microcontroller. It will reduce
the unstable reference voltage and noise in data conversion process.

28
DC motor with encoder is recommended as encoder generally has higher torque
and speed specification compared to dc gear motor. The encoder can be used to
gain feedback for determining and control the motor speed very accurately.

In addition, the width of the wheel can be increased to increase its moment of
inertia and grip on the surface. However, for future work with modifications and
recommendations discussed above, better balancing performance can be
expected.

29
Reference
AMCI Tech Tutorials. 2015. Stepper vs. Servo. Available at: http://www.amci.com/tutorials/
tutorials-stepper-vs-servo.asp. [Accessed 13 May 2015].

Arduino Uno. 2015. Arduino - ArduinoBoardUno . Available at: http://www.arduino.cc/en/

main/arduinoBoardUno. [Accessed 22 April 2015]

EMG30. 2010. Data sheet. Available at: http://www.robot−electronics.co.uk/htm/emg30.htm

[Accessed 22 April 2015]

Faragher, Ramsey. 2012. Understanding the Basis of the Kalman Filter Via a Simple and
Intuitive Derivation. IEEE signal processing magazine.

Glad, Torkel. Ljung, Lennart. 2006. Reglerteknik - Grundläggande teori. 4th edn.
Studentlitteratur.

InvenSense Inc. 2013. MPU-9150 Product Specification. Sunnyvale, USA. Revision 4.3.
Available at: http://www.invensense.com/mems/gyro/documents/PSMPU-9150A-00v43.pdf.
[Accessed 22 April 2015]

Johansson, Hans. Lindahl, Per-Erik. Meyer, Robert. Grimheden, Martin. Sandqvist, William.
Paulsson, Magareta. 2013. Elektroteknik. KTH

Lauszus, Kristian. 2012. Kalman Filter. Available at: https://github.com/TKJElectronics

/KalmanFilter [Accessed 20 Mars 2015]

Loram, I, 2002. Human balancing of an inverted pendulum: position control by small,

ballistic-like, throw and catch movements. Journal of Physiology, 540.3, 1111.

Lövgren, Samir. 2015. Self balancing Robot. Available at: http://samirlovgren.se/pageid647.

[Accessed 11 May 2015]. 29

Redhat. 2015. What is open source software. Available at: https://opensource.com/resources

/what-open-source. [Accessed 13 May 2015].

Siemens PLM Software. 2015. Solid Edge. Available at:

http://www.plm.automation.siemens.com /en-us/products/solid-edge/. [Accessed 21 April
2015]

Velleman. 2013. Motor and power shield for Arduino. Gavere, Belgium. Available at:
http://www.velleman.co.uk/manuals/vma03.pdf [Acessed 29 Mars 2015]

Jin, D. 2015. Development of a Stable Control System for a Segway. Available at:
http://www.raysforexcellence.se/wp-content/uploads/2013/01/Dennis-Jin-Developmentof-a-
stable-control-system-for-a-segway.pdf. [Accessed 02 May 2015]

30