University of Portsmouth School of Engineering Meng Electronic and Electrical Engineering

November 18

Preliminary Report

2011
Balancing Robot Design and Development

A balancing robot provides several benefits compared to standard three or more wheeled models, the main being a more closely holonomic robot. Throughout the report, an in depth analysis will be carried on the design, simulation to be able to arrive at a functional prototype.

Author: Miguel Bernardo Student number: 41235 Unit co-ordinator: Dr Alan Hewitt Supervisor: Dr Djamel Azzi Unit: M586L

Preliminary Report Balancing Robot Design and Development

CONTENTS

CONTENTS
CONTENTS............................................................................................................................................ 1 1 INTRODUCTION .......................................................................................................................... 2 1.1 1.2 Statement of problem .............................................................................................................. 2 Objectives ............................................................................................................................... 3

1.2.1 Phase 1 - Research: ................................................................................................................ 3 1.2.2 Phase 2 Analysis: ................................................................................................................. 3 1.2.3 Phase 3 Modelling: .............................................................................................................. 4 1.2.4 Phase 4 Implementation: .................................................................................................... 4 2 RESEARCH .................................................................................................................................... 5 2.1 Ballbot Literature Review........................................................................................................ 5

2.1.1 Drive ....................................................................................................................................... 6 2.1.2 Equations of motion and controllability ................................................................................ 7 2.1.3 Cost of components for a similar Ballbot model ................................................................... 9 2.2 Two-Wheeled Robot (TWR) Literature Review..................................................................... 11

2.2.1 Drive ..................................................................................................................................... 12 2.2.2 Equations of motion and controllability .............................................................................. 13 2.2.3 Cost of components for a similar TWR model ..................................................................... 15 2.3 3 Research conclusions ............................................................................................................ 16

ELECTED DESIGN ANALAYSIS.............................................................................................. 16 3.1 Sensing Module..................................................................................................................... 16

3.1.1 Introduction ......................................................................................................................... 16 3.1.2 Accelerometers and gyro analysis ....................................................................................... 18 3.1.3 Building and simulating the IMU.......................................................................................... 19 4 PROJECT BREAKDOWN ........................................................................................................... 21 4.1 5 6 7 Plan & Milestones ................................................................................................................. 21

CONCLUSION ............................................................................................................................. 22 REFERENCES ............................................................................................................................. 23 APPENDIX ................................................................................................................................... 24 7.1 7.2 Detailed Gantt chart ............................................................................................................. 24 Arduino code for the IMU ..................................................................................................... 32

Preliminary Report Balancing Robot Design and Development

INTRODUCTION

1 INTRODUCTION
Robots degree of freedom is one of the main constraints that restrict their application in tight environments with objects constantly changing position. Conventional driven robots lack the usability of a balancing robot, because they need the base to support the entire frame, usually the taller and heavier the frame is, the wider the robot base will be to maintain equilibrium. Because of these constraints on conventional models this project has the intent to analyse existing pendulum based models and requirements as well as model a virtual robot and build a prototype to demonstrate the benefits of such design.

1.1 Statement of problem

Throughout the course of the task at hand, several steps will have to be taken and analysed to be able to feedback to a viable prototype. The main one will be the controllability feeding to the drive of the robot. There are two out of three possible cases that will be analysed before deciding on the final model to proceed. The first one consists of a single spherical wheel; this will allow creating a holonomic robot, where the available degrees of freedom are equal to the degrees of movement of the robot. The second is a single wheeled robot, similar to a unicycle. However, due to the inability to allow the robot to move sideways with the use of only the wheels drive this model will be discarded. The last model is a two-wheeled robot similar to the Segway, also a similar model falling under the two wheeled would be a bicycle type robot. However, the latter also requires additional drive to a sort of gyro to compensate lateral fall movement so it will also be discarded for analysis. All models, because of their inability to stand upright if no power is being driven to the motors are considered dynamic systems. The robots design can be viewed as an inverted pendulum where control theory will need to be applied to the dynamics of system. The applications of this type of robot are mainly in human assistance and interaction where crowded and narrow environments will require an agile reaction to the current scenario. Areas such as hospitality, by serving meals to customers; care homes, assisting elderly peoples needs; mobility platforms, a replacement to the current mobility chairs and even factories, assisting in manoeuvrability of heavy loads would greatly benefit from their use.

Preliminary Report Balancing Robot Design and Development

INTRODUCTION

The project will be basically a control theory application for the balancing robot stability but because of its uniqueness and not very widespread information and resources regarding the topic it will also cover the fields of mechanics, for the drive and frame; electronics, for the sensing capability of the robot and computer modelling, for the testing, development and simulation of the robot.

1.2 Objectives
The project is divided into phases and each phase has objectives as outcomes. Since the final goal is to reach a balancing robot which can interact in a crowded dynamic environment, or can be scaled to do so, by the completion of the project the following phases will be used to guide me through the task. The overall objective will be to be able to simulate and create a model which would balance, and if time permits the creation of a remote control and further on an interface to be able to detect/avoid/follow objects will be attempted.
1.2.1 Phase 1 - Research:

Research on available models of balancing robots and their viability, affordability (taking the allocated budget) and benefits compared to other models. Objectives: Research models; Study benefits/complexity and resources required for each model; Get components list price for each model; Decide on the model to create based on the findings above.

1.2.2 Phase 2 Analysis:

With the model selected from Phase 1 the development part of the project starts here. Objectives: Breakdown model into modules for analysis; o Frame module; o Drive module; o Sensing module; o Control module;
3

Preliminary Report Balancing Robot Design and Development

INTRODUCTION

o Ability to add extra modules: Remote control wire/wireless and other custom modules.
1.2.3 Phase 3 Modelling:

Subsequently the modules will try to be modelled/simulated either separately or together to analyse and visualize the behaviour of the future prototype. Objectives: Create simulation for modules where possible; Design frame/construction; Derive mathematical equations to model the system; Derive control equations for the balancing.

1.2.4 Phase 4 Implementation:

This will be the final phase and some revisiting to previous phases might be done to correct/expand prototype possibilities. Things like remote controlling and possibility for modular expansion will be considered in this phase Objectives: Coding: o Drive; o Control; o Sensing; o Remote controlling. o Object avoidance o Object tracking Assembly: o Build frame; o Assemble components. Simulation: o Correct equations derived in previous phase if required.

Preliminary Report Balancing Robot Design and Development

RESEARCH

2 RESEARCH
2.1 Ballbot Literature Review
The Ballbot model is very similar to the robot named Serge which appears in sci-fi series Caprica. Throughout the research of Ballbot models I discovered that there are mainly two branches, depending on the type of drive they use. Thus, henceforth only those two will be analysed as all others have been based on them. The first robot was born in the labs of the Carnegie Mellon University (CMU) in 2006 by T. B. Lauwers, G. A. Kantor, and R. L. Hollis. It weighted 43 kg and had the approximate size of an average person, both in height and width (Watzman, 2006) and has a drive similar to an inverse mouse-ball. The second robot was developed in 2008 at the Tohoku Gakuin University (TGU) by Dr Masaaki Kumagai weighing 7.5 kg and with a height no bigger than 0.5 meters. The peculiar drive about the latter is that the wheels to drive the ball are placed 120 degrees apart making it harder to define the movement of the robot. These types of robots are truly holonomic because of their ability to have the controllable degrees of freedom equal to the total degrees of freedom the robot has. (The presented CMU model does not have that capability. However, in the research undertaken an analysis was being carried out to enable that feature to be available).

Figure 1 - Battlestar Galactica Comic Con Exclusives., 2009

Figure 2 - Ballbot balancing in the CMU motion capture lab, with Ralph Hollis looking on., 2006

Figure 3 - Masaaki Kumagai BallIP., 2008

Preliminary Report Balancing Robot Design and Development 2.1.1 Drive

RESEARCH

The CMU ballbot depicted in Figure 4 consists of two orthogonal rollers in relation to the sphere equator and perpendicular to each other. Both are linked to high torque DC servomotors through timing belts. Opposite to each active roller there is an idle roller which is spring loaded to add pressure to the ball insuring both drive rollers always have contact with the sphere. Ball transfers are used to help alleviate weight of bogy and the feedback control of the motors is provided by encoders.

Figure 4 CMU Ballbot inverse mouse-ball drive mechanism (Lauwers, Kantor, & Hollis, 2006)

The design method used in the TGU is based on three stepper motors forming 120 degrees between each other connected to omni-wheels. This has several benefits compared to the CMU model being the first the ability to yaw which is impossible in Lauwers et al model without adding extra motors. Also the TGU model because it uses the motors directly attached to omni-wheels it has the ability to support the robot weight without the ball transfer which reduces the friction in the ball and allows a smother drive. The downside is that it increases the computational requirements do calculate how to drive the ball.

Figure 5 TGU Drive (Justin Fong, 2009)

Preliminary Report Balancing Robot Design and Development 2.1.2 Equations of motion and controllability

RESEARCH

Both models have similar equations of motions (only changing coefficient like mass, ball radius, etc.). From a physics perspective they are considered as a wheel cart with two inverted pendulums perpendicular/decoupled to each other. Also several assumptions, such as static and non-linear friction, ball deformity and body flexibility, are made to simplify and allow a more linear approach to the controllability of the model.

Figure 5 CMU Ballbot model for equations and controller (Lauwers, Kantor, & Hollis, 2006)

Also equations of motion are assumed equal in both planes allowing the design of a single controller and the ability to apply it to the two planes. The dynamics of the system is thus derived using Lagranges equation approach, where T is the sum of the kinetic energy of the system and U the potential energy.
= (1)

In the CMU, they by defining the co-ordinates system as in Figure 5 and calculating the kinetic energy of the ball, we end up with:
=
2

(2)

Where

and

being respectively the inertia, mass and radius of the ball. The ball

potential energy is and always will be equal to 0 as it is assumed that the ball will not bounce or hop. The next step is to calculate the kinetic (Equation 3) and potential energy (Equation 4) of the Body.
= 2
2 2 2 2 2

+2

+ =

) cos( + ) +

cos( + )

( + )

( + )

(3) (4) 7

Preliminary Report Balancing Robot Design and Development

RESEARCH

With, distance from body centre of mass and ball, and angular velocity represented as the first derivative

and

is the body mass and inertia and with their

is the gravity acceleration. Ball and body angle are represented as

and , correspondingly. With the

summing of all kinetic and potential forces, Lauwers et al end up with the Euler-Lagrange equation of the model expressed in the form and coordinates and velocity with controllable variables ball and body angle and by re-arranging the outcome is Equation 5. Also in the CMU a model of the viscous component based on the torque matrix of equations.
( ) + ( , )+ ( )+ ( )= 0 (5)

is also added ending with

This new re-arrangement organizes the problem into Mass matrix, Coriolis and centrifugal matrix, Gravitational matrix and Damping matrix in respect to position the two planar systems. The controller used in the CMU model (figure 6) has the inner loop to provide the feedback of the ball velocity to a Proportional Integrator controller and the outer loop for the linear quadratic regulator for the full state feedback. The PI gains, and are experimentally chosen to make the real ball velocity track the desired ball velocity. and velocity in

Figure 6 CMU Ballbot model for equations and controller (T. B. Lauwers, 2006)

In the TGU model Dr Masaaki Kumagai opted for just a proportional derivative controller for the balancing. Also the proportional and derivative gains were achieved through experimentation. The desired output is after passed on to two virtual wheels which simulate the drive of the ball allowing the simpler PI controller derivation. The model based, shown in Figure 7 and 8, uses a similar derivation method but it relates to the wheel acceleration.

Preliminary Report Balancing Robot Design and Development

RESEARCH

Figure 7 TGU Ballbot model for equations and controller (Kumagai & Ochiai, 2009)

Figure 8 TGU Ballbot model for equations and controller (Kumagai & Ochiai, 2009)

In the TGU, Masaaki et al, also calculate and simulate model under a load condition and deduct that with a load on top of the ballbot the pendulum and inertia moment decrease which raises the centre of mass. The conclusion was that the robot acceleration decreased nearly inversely proportional to the inertia increase.
2.1.3 Cost of components for a similar Ballbot model

Merging the functionally of the two models and preventing the use of the complex drive from the TGU, a ballbot with the design below was created. The benefits as shown in Figure 9, are that it would be capable of yaw without the complexity of using the tri-omini-wheel design. Thus, the positioning of the wheels would be 90 apart and use a set of four to support the whole weight of the robot.

Figure 9 Proposed drive model based on Wu and Hawg research 2008

Preliminary Report Balancing Robot Design and Development

RESEARCH

Since the aim is to develop a robot which would be able to interact with a person, a scalable model with the requirements presented below is based on created constraints from the problem definition, thus this will reflect on the required components price and specifications to acquire. Motors: Enough torque to move the body and ball ( 3 10 kg ); Power requirement must not exceed 12v because of price; Be scalable for future adaption to full scale model. Radius size to be considered in regards to torque; Material of the wheel, from research plastic wears off to quickly; Radius size to be considered in regards to torque as well; Physical properties are of high importance for controllability: o As little as deformation as possible; o High friction; o Able to withstand frame mass. Body: Frame dimensions and material (Frame cost will be disregarded and the Mechanics Workshop provide a wide variety of components and until design is completed cost cannot be factorized.) Components List Module Drive Drive Drive Drive Drive Drive Microcontroller Microcontroller Microcontroller Power Power Power Name Price Unit Quantity 2 x Pololu Universal Hub (6mm shaft) 6.60 2 OmniWheel Black Small ** EUR ** 3.20 4 Pololu 37D mm Metal Gearmotor Bracket Pair 6.36 2 50:1 Metal Gearmotor 37Dx52L mm with 64 CPR Encoder 31.68 4 Bidirectional DC Motor Speed Controller (5-32V, 5A) 33.94 4 Basketball 5.00 1 Arduino uno 20.03 1 Triple Axis Accelerometer Breakout - ADXL335 15.53 1 Triple-Axis Digital-Output Gyro ITG-3200 Breakout 31.10 1 BT04065 - 4AA Extra-High Capacity Batteries 7.16 1 12v Battery 16.00 1 4 AA Battery case 0.70 1 Total: 396.72
10

Omni-wheel: Ball:

Preliminary Report Balancing Robot Design and Development

RESEARCH

2.2 Two-Wheeled Robot (TWR) Literature Review

Two-wheeled robots are more widely known and greater varieties of projects exist. The research was inconclusive in relation to the first design origin and time but it is widely accepted to consider these types of models to be a natural evolution of the inverted pendulum control problem fixed on a moving cart. The oldest found model was Joel le pendule in 1996 developed by LEI, Laboratoire d'lectronique Industrielle at cole Polytechnique Fdrale de Lausanne (EPFL) in Switzerland (Figure 10). The project only had a successful balancing robot after four years of the start of the project, on the 25th of January 2000. The aim of the project had no intended specific application. However, what was interesting in the design for the authors was a completely different structure and an unprecedented performance (EPFL, 2000). Several other models followed, some built out of Lego parts and others with solid and robust frames such as the LegWay and nBot (Figure 11). The latter is very well documented and due to its robustness it was aimed at rough terrain survey. The nBot created by David P. Anderson has won NASAs Cool Robot of the Week for 19th May 2003 and honoured the NASA page as one of the top 10 engineering and technical web sites for 2003 (Anderson, 2002). A commonly used application of the model is in the Segway Personal Transporter (Figure 12). It was invented by Dean Kamen and the locomotion consists in combining the user plus the frame to move the robot. When the user leans it destabilises the system dynamics forcing the control algorithm to compensate with wheel rotation returning it to a stable position.

Figure 10 Joe Pendulum (EPFL, 2000)

Figure 11 nBot (Anderson, 2002)

Figure 12 Segway with rider

11

Preliminary Report Balancing Robot Design and Development 2.2.1 Drive

RESEARCH

The drive component of the TWRs is nearly the same for all models, the use of a DC motor with encoders either attached to the wheel, wheel shaft or the motor shaft depending on the required resolution required, to feedback the wheel rotation. However, good wheel encoders prove to be expensive and hard to find as it was recognized in the first component research done for the Ballbot.

Figure 13 Encoder patterns to be read by optical sensor providing different type of characteristics.

Further research provided an alternative to what will prove to be a less expensive option. The use of servo motors set for continuous rotation or stepper motors provide a method of having the feedback without actually having the feedback mechanism. Because these type of motors work on degrees of rotation assuming an overcompensation on the motor torque specifications it can be assumed that when the rotation movement is requested it will be served, also the friction between the wheels are of contact with the floor is considered to be very high. Other than having servos, steppers or dc motors controlling the drive of either one or both wheels not much difference exists in the overall drive design of the TWR.

12

Preliminary Report Balancing Robot Design and Development 2.2.2 Equations of motion and controllability

RESEARCH

The pseudo algorithm derived by Anderson (Figure 14) provides a very good idea of how the system works and also how to derive the equations of motion. The differences compared to the ballbot are nearly non-existent, the only difference being that this represents the whole system as it will only need to balance in one axis because an assumption that the robot will not topple on its sides.

Motor Shaft Encoder Motor PWM Angle sensor

Angle Velocity Angle Position K2 Angle Velocity Derivation K3 Wheel Position

Derivation

K1

SUM

K4
Figure 14 nBot balancing pseudo algorithm (Anderson, 2002)

To derive the equations of motion in the TWR model we divide the system into two parts for analysis, the body and the wheels (Figure 15).

Figure 15 TWR pendulum body and wheel geometry and coordinates (Vamfun, 2007)

This ends up giving the following equations:

= = = ( cos( ) + sin( ) + (6)

13

Preliminary Report Balancing Robot Design and Development

RESEARCH

(7)

Where set of equations 6 represent the body equations applying Newtons Second law with x axis being parallel to Fxg, y axis parallel to Fyg and z axis perpendicular to both x and y axis. And equations set 7 are the wheel equations. When combined with the assumptions that the wheels will always stay in contact with the floor and no slippage will occur between the wheels and the floor Vamfum is able to achieve the following state equations.

( 21 22) 1 + ( 11 + 12) 2) = 21 1 + 11 2) (8)

With:
11 = +( + ) 12 = 21 = 21 = 22 = + = 11 22 12 21 1= 2= +

(9)

The controllability options for the two wheeled balancing robot are immense, they vary from LQR to simple matching the position of the wheel with the position of the centre of the body by the use of nothing more than the difference operation. Since the controllability of this model is easier to achieve, similar to the ballbot equations but with less complexity and various methods exist a more in-depth analysis will be undertaken if the path chosen is based on the TWR.

14

Preliminary Report Balancing Robot Design and Development 2.2.3 Cost of components for a similar TWR model

RESEARCH

The two wheeled inverted pendulum robot appears to have a very consistent approach in design and drive throughout all the research done. The model proposed consists of creating a very basic yet durable frame of a material still to be confirmed, can be wood like MBF or acrylic sheets. And will consist of a tall parallelepipeds shaped body with the microcontrollers inside and the wheels on the side. This way in a later date a modular approach can be taken if extra functions are required to be added to the robot. The proposed model will be similar to the one with Figure 16 and the location of the components has been placed in the rear view.

Figure 16 Proposed TWR

Components Module Drive Drive Microcontroller Microcontroller Microcontroller Microcontroller Power Power Name Servo - Medium Full Rotation Tamiya 70193 Slim Tire Set (4 tires) Arduino uno Xbee Wireless Bluetooth Transceiver Module RS232 / TTL Triple Axis Accelerometer Breakout - ADXL335 Triple-Axis Digital-Output Gyro ITG-3200 Breakout BT04065 - 4AA Extra-High Capacity Batteries 4 AA Battery case Total: Price Quantity Unit 9.06 2 6.80 1 19.98 1 9.39 0 15.53 1 31.10 1 7.16 1 0.00 1 98.69
15

Preliminary Report Balancing Robot Design and Development

ELECTED DESIGN ANALAYSIS

2.3 Research conclusions

Being the ballbot an evolution from the two wheeled robot and due to the lack of knowledge in inverted pendulum mechanics and although the ballbot presents a more challengeable and exciting project due to the budget constraints the decision of which project to follow is clear. Also both ballbot models were built by a team of electronic and mechanical engineers which allowed them to create a better prototype using each members field of expertise. The decision to build a two wheeled inverted pendulum robot is not the preferred but it is however the better option to provide knowledge and understanding of the inverted pendulum control problem. In the future the author would like to proceed with the creation of a prototype with dimensions similar to a person because the benefits presented are not only crucial to a robot that can easily interact in human environments but also presents a very economically profitable business aimed at several industries.

3 ELECTED DESIGN ANALAYSIS

This topic will try to divide the project into smaller blocks allowing better time management and easier overall design. Since the robot proposed for simulation and building is the two wheeled inverted pendulum robot the initial division into modules will be the following. The Drive, this will include motors (and motor drivers if required) as well as the required analysis and measuring of the components properties. Frame, which will consist in design and material analysis for the robot, also, the equations of motion and control will fall under this category. Microcontroller, being the brain of the robot this module will possibly overlap with other modules but will be considered individual because a final composition of all the sketched codes for each module will be required. Finally, the sensing module, which will consist in creating an accurate measuring unit to be easily interfaced with the microcontroller.

3.1 Sensing Module

3.1.1 Introduction

Most systems which are dynamically unstable require a method to determine their orientation before they are able to be controlled. A good example is UAVs (Unmanned Air Vehicles) due to the fact that they do not have a pilot who would be able to percept/acquire data, say from looking out of the cockpit window to be able to then take the required action to compensate
16

Preliminary Report Balancing Robot Design and Development

ELECTED DESIGN ANALAYSIS

the direction or altitude to bring the aeroplane to the required position they will require a set of sensors to be able to do that inferring automatically in a lack of a person. Applied to the project the required measurements will be the ability to detect the direction of the movement, the speed of the vehicle and how fast it is rotating or falling, depending on the plane. With this in mind a set of basic movements will be analysed in order to determine the problem and required sensing module. Based on the proposed model at the end of the research the demonstration and analysis of three conceivable situations the robot will encounter will be set forth to better understand the sensing requirements.

Centre of mass

Centre of mass

Centre of mass

Scenario 1 - balancing position

Scenario 2 - rotate on z axis Figure 17 - Possible scenarios the robot will face

Scenario 3 move

In scenario 1 the robot is still. However, due to the fact that it is on top of two wheels it will be impossible to keep upright position. Thus, it will be required to detect how many degrees per time frame it is falling to be able to feed that value to the control algorithm. Because, of the two wheels we can assume the robot will always fall in the same plane. The direction of the fall will need to be identified to compensate the motors in the right direction. For the second scenario the robot will require to turn on its own z axis. However, if we can always maintain the position in scenario 1 we can neglect having to detect motion in another plane saving the requirements of having to measure an extra acceleration.

17

Preliminary Report Balancing Robot Design and Development

ELECTED DESIGN ANALAYSIS

In the last scenario, when the robot moves we will need to detect the fall while preventing it from going to the upright position, so that is always in a permanent fall state allowing for the movement to occur. For this we will need to detect the displacement of the wheel, thus an accelerometer that detects movement in a plane perpendicular to plane z and the wheels will be required. Henceforth, that plane will be regarded as x plane and we can consider it as parallel to the surface the robot will be on. All scenarios assume that the wheels will never lose contact with the floor.
3.1.2 Accelerometers and gyro analysis

To be able to have the required measurements an accelerometer would suffice. However, research in building robots that need to know their position in space indicates that it alone does not provide accurate readings; this is due to motor oscillation that introduces noise into the readings. An Inertial Motion Unit (IMU) compensates those inaccuracies introduced by the false readings. It consists in combining a gyroscope with and accelerometer (and sometimes a magnetometer to detect magnetic orientation) to provide a reliable reading. In addition the values read are passed through a Kalman filter, it basically consists of inferring present values based on previous readings and estimations of future values, this allows us to have a smoother output of values with less discrepancies.

Figure 18 - Accelerometer

The accelerometer for the IMU (Figure 18) will read the inertial and gravitational force, so if we have a three axis accelerometer like the one chosen in the components and it is still, we will measure one g-force in the z axis according to the datasheet, as this will be the earth gravitational pull. The output of data is analogue and the resolution will value depending on the reference voltage which is equal to the supplied voltage and can swing from 1.8 to 3.6 volts. The sensing capability is from +3g to -3g.

18

Preliminary Report Balancing Robot Design and Development

ELECTED DESIGN ANALAYSIS

The gyro (Figure 19) will measure the disturbances in the current axis, measuring the rotation in that axis. For the selected component the interface uses the I2C protocol which simplifies communication. For example, to read a certain rotation axis value, we only need to specify the address of the register we would like to get (it needs to be read twice because the values are 16bit 2s complement). The sensing capability goes from -2000/s to +2000/s and it has separate input voltage and reference voltage, able to go from 2.1 to 3.6v.

Figure 19 - Gyro

3.1.3 Building and simulating the IMU

The IMU will be the gyroscope and the accelerometer attached to the microcontroller, Arduino board. Following the datasheet the diagram in Figure 20 shows how they have been connected to the microcontroller.

Figure 20- Sensor Diagram

19

Preliminary Report Balancing Robot Design and Development

ELECTED DESIGN ANALAYSIS

A small sample code was also created to test interfacing with the sensors (see Appendix 7.2), following this a Matlab model was designed to be able to analyse the readings from the sensors and help towards creating a model for developing the control algorithm.

Figure 21- Matlab Simulink designed model

The Simulink model in Figure 21 connects to the serial port of the connected Arduino board with the attached sensors, which transmits a vector of the three rotations, as in Figure 20 and displays the values in the three boxes, one for each of the axis. It is also being attempted to get a visualisation of the actual rotation in the 3D model feeding of the parsed vector read from the serial link (Figure 22).

Figure 21- Matlab Simulink designed model

20

Preliminary Report Balancing Robot Design and Development

PROJECT BREAKDOWN

4 PROJECT BREAKDOWN
4.1 Plan & Milestones
The project will span over two semesters with the final goal of achieving a balanced and controlled two wheeled robot. A Gantt was created to depict in detail the tasks taken and yet to be done as well as the project milestones assigned by the lecturers and self-assigned milestones such as decisions and estimated prototype readiness (See Appendix 7.1 for more detail).

21

Preliminary Report Balancing Robot Design and Development

CONCLUSION

5 CONCLUSION
At this stage with the research done the selected type of design to follow is the two wheeled inverted pendulum. Some initial design analysis and the assembly of the sensing unit is complete. For the next step I will work on perfecting the sensing to give accurate readings by simulating real value readings and displaying them on the modelled 3D Matlab Simulink model. After, the frame design with the drive module will be assembled so the equations of motions and afterwards the control can be designed, as they mass of body and some other values of the final prototype.

22

Preliminary Report Balancing Robot Design and Development

REFERENCES

6 REFERENCES
Ballbot balancing in the CMU motion capture lab, with Ralph Hollis looking on. (2006). Retrieved November 7, 2011, from http://www.msl.ri.cmu.edu/projects/ballbot/images/Ballbot_Goldfein_small.jpg Masaaki Kumagai BallIP. (2008). Retrieved November 7, 2011, from http://a1.twimg.com/profile_images/688323178/ballip_rev20.jpg Battlestar Galactica Comic Con Exclusives. (2009). Retrieved November 7, 2011, from http://everyjoe.com/files/2009/07/serge-usb-keychain.jpg Anderson, D. P. (2002, December 12). nBot Balancing Robot. Retrieved November 6, 2011, from Geology SMU: http://www.geology.smu.edu/~dpa-www/robo/nbot/ EPFL. (2000, January 25). EPFL - Joe the pendulum. Retrieved November 3, 2011, from EPFL: http://lei.epfl.ch/page-36905-fr.html Hollis, R. (2011, January 4). Microdynamic Systems Laboratory. Retrieved October 11, 2011, from Dynamically-Stable Mobile Robots in Human Environments: http://www.msl.ri.cmu.edu/projects/ballbot/ Justin Fong, S. U. (2009, May 22). TGU Drive. Adelaide. Kumagai, M., & Ochiai, T. (2009, September 29). Development of a Robot Balanced on a Ball. Tohoku, Japan. Lauwers, T. B., Kantor, G. A., & Hollis, R. L. (2006). A Dynamically Stable SingleWheeled. Proc. IEEE Intl. Conf. on Robotics and Automation,, 3. Steve. (2004, April 6). Steve's LegWay. Retrieved November 6, 2011, from Team Hassen Plug: http://www.teamhassenplug.org/robots/legway/ Vamfun. (2007, August 20). Modeling a Two Wheeled Inverted Pendulum Robot. Watzman, A. (2006, August 9). Carnegie Mellon Researchers Develop New Type of Mobile Robot That Balances and Moves on a Ball Instead of Legs or Wheels. Retrieved October 15, 2011, from http://www.msl.ri.cmu.edu/projects/ballbot/text/BallbotAugustFinal.pdf

23

Preliminary Report Balancing Robot Design and Development

APPENDIX

7 APPENDIX
7.1 Detailed Gantt chart

24

Preliminary Report Balancing Robot Design and Development

APPENDIX

25

Preliminary Report Balancing Robot Design and Development

APPENDIX

26

Preliminary Report Balancing Robot Design and Development

APPENDIX

27

Preliminary Report Balancing Robot Design and Development

APPENDIX

28

Preliminary Report Balancing Robot Design and Development

APPENDIX

29

Preliminary Report Balancing Robot Design and Development

APPENDIX

30

Preliminary Report Balancing Robot Design and Development

APPENDIX

31

Preliminary Report Balancing Robot Design and Development

APPENDIX

7.2 Arduino code for the IMU

8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 //The Wire library is used for I2C communication #include <Wire.h> //ITG3200 sensitivity is 14.375 LSB/(degrees/sec) #define GYROSCOPE_SENSITIVITY (1 / 14.375) //Voltage reference for the ADC #define V_REF 3.3 //Number of calibration samples #define CALIBRATION_SAMPLES 128 //Number of samples per value returned #define SAMPLES 4 //16bit 2s complement range #define G_RESOLUTION 32767 //Accelerometer pins #define PIN_X 0 #define PIN_Y 1 #define PIN_Z 2 //This is a list of registers in the ITG-3200 char WHO_AM_I = 0x00; char SMPLRT_DIV= 0x15; char DLPF_FS = 0x16; char TEMP_OUT_H = 0x1B; char TEMP_OUT_L = 0x1C; char GYRO_XOUT_H = 0x1D; char GYRO_XOUT_L = 0x1E; char GYRO_YOUT_H = 0x1F; char GYRO_YOUT_L = 0x20; char GYRO_ZOUT_H = 0x21; char GYRO_ZOUT_L = 0x22; //Calibration variables for g_ == gyro and a_ == accelerometer long g_xBias = 0, g_yBias = 0 , g_zBias = 0; long a_xBias = 0, a_yBias = 0, a_zBias = 0; float a_sensitivity=0; int a_0g=0;

//This is a list of settings that can be loaded into the registers. //DLPF, Full Scale Register Bits //FS_SEL must be set to 3 for proper operation //Set DLPF_CFG to 3 for 1kHz Fint and 42 Hz Low Pass Filter char DLPF_CFG_0 = (1<<0); char DLPF_CFG_1 = (1<<1); char DLPF_CFG_2 = (1<<2); char DLPF_FS_SEL_0 = (1<<3); char DLPF_FS_SEL_1 = (1<<4);

//I2C devices each have an address. The address is defined in the datash eet for the device. The ITG3200 breakout board can have different address depending on how 56 //the jumper on top of the board is configured. By default, the jumper i s connected to the VDD pin. When the jumper is connected to the VDD pin the I2C address 57 //is 0x69. 58 char itgAddress = 0x69; 59

32

Preliminary Report Balancing Robot Design and Development

APPENDIX

60 //In the setup section of the sketch the serial port will be configured, the i2c communication will be initialized, and the itg3200 will be configured. 61 //Calibration for the itg3200 and adxl335 62 void setup() 63 { 64 //Create a serial connection using a 9600bps baud rate. 65 Serial.begin(9600); 66 67 //Initialize the I2C communication. This will set the Arduino up as the 'Master' device. 68 Wire.begin(); 69 70 //Read the WHO_AM_I register and print the result 71 char id=0; 72 id = itgRead(itgAddress, 0x00); Serial.print("ID: "); 73 74 Serial.println(id, HEX); 75 76 //Configure the gyroscope 77 //Set the gyroscope scale for the outputs to +/-2000 degrees per second 78 itgWrite(itgAddress, DLPF_FS, (DLPF_FS_SEL_0|DLPF_FS_SEL_1|DLPF_CFG_0) ); 79 //Set the sample rate to 100 hz 80 itgWrite(itgAddress, SMPLRT_DIV, 9); 81 82 //calibrate gyro and calibrate accelerometer 83 for(int sample = 0; sample < CALIBRATION_SAMPLES; sample++) 84 { 85 g_zBias += (itgRead(itgAddress, GYRO_ZOUT_H)<<8) | (itgRead(itgAddre ss, GYRO_ZOUT_L)); 86 g_xBias += (itgRead(itgAddress, GYRO_XOUT_H)<<8) | (itgRead(itgAddre ss, GYRO_XOUT_L)); 87 g_yBias += (itgRead(itgAddress, GYRO_YOUT_H)<<8) | (itgRead(itgAddre ss, GYRO_YOUT_L)); 88 a_xBias += analogRead(PIN_X); 89 a_yBias += analogRead(PIN_Y); 90 a_zBias += analogRead(PIN_Z); 91 delay(10); 92 } 93 g_xBias = g_xBias / CALIBRATION_SAMPLES; 94 g_yBias = g_yBias / CALIBRATION_SAMPLES; 95 g_zBias = g_zBias / CALIBRATION_SAMPLES; 96 97 a_xBias = a_xBias / CALIBRATION_SAMPLES; 98 a_yBias = a_yBias / CALIBRATION_SAMPLES; 99 a_zBias = a_zBias / CALIBRATION_SAMPLES; 100 a_0g = (a_xBias + a_yBias)/2; 101 a_sensitivity = 1.000/( a_zBias - a_0g); 102 Serial.println(a_sensitivity); 103 Serial.println(a_0g); 104 Serial.println(a_sensitivity*(a_zBias - a_0g)); 105 Serial.println(a_xBias); 106 Serial.println(a_yBias); 107 Serial.println(a_zBias); 108 } 109 110 //The loop section of the sketch will read the X,Y and Z output rat es from the gyroscope and output them in the Serial Terminal 111 void loop()

33

Preliminary Report Balancing Robot Design and Development

112 113 114 115 116 117 118 119 120 121 122 123 124 {

APPENDIX

//Create variables to hold the output rates. double g_xRate, g_yRate, g_zRate, g_tSensor; //Gyro ITG-3200 Values double r_vector[2]; //Read the x,y and z output rates from the gyroscope. g_xRate = readX(); g_yRate = readY(); g_zRate = readZ(); g_tSensor= readT(); readAccel(&r_vector[0]);

//Print the output rates to the terminal, seperated by a TAB character. 125 Serial.println("XXX,YYY,ZZZ"); 126 Serial.print(g_xRate); 127 Serial.print(','); 128 Serial.print(g_yRate); 129 Serial.print(','); 130 Serial.println(g_zRate); 131 //printDouble(r_vector[PIN_X],10); 132 Serial.print(analogRead(PIN_X)); 133 Serial.print(","); 134 // printDouble(r_vector[PIN_Y],10); 135 Serial.print(analogRead(PIN_Y)); 136 Serial.print(","); 137 // printDouble(r_vector[PIN_Z],10); 138 Serial.print(analogRead(PIN_Z)); 139 Serial.println(); 140 //Wait 10ms before reading the values again. (Remember, the output rate was set to 100hz and 1reading per 10ms = 100hz.) 141 delay(1000); 142 } 143 144 void readAccel(double *a_xyz) 145 { 146 for(int sample=0 ; sample < SAMPLES; sample++){ 147 a_xyz[0] +=analogRead(PIN_X); 148 a_xyz[1] +=analogRead(PIN_Y); 149 a_xyz[2] +=analogRead(PIN_Z); 150 } 151 a_xyz[0] = ((a_xyz[0] / SAMPLES) - a_0g) * a_sensitivity; 152 a_xyz[1] = ((a_xyz[1] / SAMPLES) - a_0g) * a_sensitivity; 153 a_xyz[2] = ((a_xyz[2] / SAMPLES) - a_0g) * a_sensitivity; 154 } 155 //This function will write a value to a register on the itg-3200. 156 //Parameters: 157 // char address: The I2C address of the sensor. For the ITG3200 breakout the address is 0x69. 158 // char registerAddress: The address of the register on the sensor that should be written to. 159 // char data: The value to be written to the specified register. 160 void itgWrite(char address, char registerAddress, char data) 161 { 162 //Initiate a communication sequence with the desired i2c device 163 Wire.beginTransmission(address); 164 //Tell the I2C address which register we are writing to 165 Wire.send(registerAddress); 166 //Send the value to write to the specified register 167 Wire.send(data);

34

Preliminary Report Balancing Robot Design and Development

168 169 170 171 172 //End the communication sequence Wire.endTransmission(); }

APPENDIX

//This function will read the data from a specified register on the ITG-3200 and return the value. 173 //Parameters: 174 // char address: The I2C address of the sensor. For the ITG3200 breakout the address is 0x69. 175 // char registerAddress: The address of the register on the sensor that should be read 176 //Return: 177 // unsigned char: The value currently residing in the specified re gister 178 unsigned char itgRead(char address, char registerAddress) 179 { //This variable will hold the contents read from the i2c device. 180 181 unsigned char data=0; 182 183 //Send the register address to be read. 184 Wire.beginTransmission(address); 185 //Send the Register Address 186 Wire.send(registerAddress); 187 //End the communication sequence. 188 Wire.endTransmission(); 189 190 //Ask the I2C device for data 191 Wire.beginTransmission(address); 192 Wire.requestFrom(address, 1); 193 //Wait for a response from the I2C device 194 195 if(Wire.available()){ 196 //Save the data sent from the I2C device 197 data = Wire.receive(); 198 } 199 200 //End the communication sequence. 201 Wire.endTransmission(); 202 203 //Return the data read during the operation 204 return data; 205 } 206 207 //This function is used to read the X-Axis rate of the gyroscope. 208 //Usage: long g_xRate = readX(); double readX(void) 209 210 { 211 double data=0; 212 for (int sample = 0; sample < SAMPLES; sample++) 213 { 214 data += (itgRead(itgAddress, GYRO_XOUT_H)<<8) | (itgRead(itgAdd ress, GYRO_XOUT_L)); 215 } 216 data = data / SAMPLES; 217 data = (data - g_xBias) * GYROSCOPE_SENSITIVITY; 218 return data; 219 } 220 221 //This function is used to read the Y-Axis rate of the gyroscope. 222 //Usage: long g_yRate = readY(); 223 double readY(void)

35

Preliminary Report Balancing Robot Design and Development

224 225 226 227 228 {

APPENDIX

double data=0; for (int sample = 0; sample < SAMPLES; sample++) { data += (itgRead(itgAddress, GYRO_YOUT_H)<<8) | (itgRead(itgAdd ress, GYRO_YOUT_L)); 229 } 230 data = data / SAMPLES; 231 data = (data - g_yBias) * GYROSCOPE_SENSITIVITY; return data; 232 233 } 234 235 //This function is used to read the Z-Axis rate of the gyroscope. 236 //Usage: long g_zRate = readZ(); 237 double readZ(void) 238 { double data=0; 239 240 for (int sample = 0; sample < SAMPLES; sample++) 241 { 242 data += (itgRead(itgAddress, GYRO_ZOUT_H)<<8) | (itgRead(itgAdd ress, GYRO_ZOUT_L)); 243 } 244 data = data / SAMPLES; 245 data = (data - g_zBias) * GYROSCOPE_SENSITIVITY; 246 247 return data; 248 } //This function is used to read the Temperature sensor. 249 250 //Usage: long g_zRate = readZ(); 251 double readT(void) 252 { double data=0; 253 254 data = (itgRead(itgAddress, TEMP_OUT_H)<<8) | (itgRead(itgAddress , TEMP_OUT_L)); 255 data = 35 + ((data + 13200)/280); 256 return data; 257 } 258 259 void printDouble( double val, unsigned int precision){ 260 // prints val with number of decimal places determine by precision 261 // NOTE: precision is 1 followed by the number of zeros for the des ired number of decimial places 262 // example: printDouble( 3.1415, 100); // prints 3.14 (two decimal places) 263 Serial.print (int(val)); //prints the int part 264 265 Serial.print("."); // print the decimal point 266 unsigned int frac; 267 if(val >= 0) 268 frac = (val - int(val)) * precision; 269 else 270 frac = (int(val)- val ) * precision; 271 int frac1 = frac; 272 while( frac1 /= 10 ) 273 precision /= 10; 274 precision /= 10; 275 while( precision /= 10) 276 Serial.print("0"); 277 278 Serial.print(frac,DEC) ; 279 }

36