knight gear - ucf department of eecs synchronous driving 21 5.3.4.4 ... geared dc motor for knight...

138
KNIGHT GEAR Group # 6 Senior Design II Sponsor: None Group members: Rene Gajardo Siddharth Padhi Do Kim Jorge L Morales

Upload: trinhcong

Post on 26-May-2018

216 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

1

KNIGHT GEAR

Group # 6

Senior Design II

Sponsor:

None

Group members:

Rene Gajardo

Siddharth Padhi

Do Kim

Jorge L Morales

Page 2: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

I

Ethics Statement and Signature

The work submitted in this Senior Design documentation is exclusively prepared by a team consisting of RENE GAJARDO, SIDDHARTH PADHI, JORGE MORALES, and DO KIM and it is original. Excerpts from other’s work have been clearly identified, their work acknowledged within the text and listed in the list of reference. All engineering drawings, computer programs, formulations, design work, prototype development and testing reported in this document are also original and prepared by the same team of students.

RENE GAJARDO: __________________

SIDDHARTH PADHI: ___________________

JORGE MORALES: _________________

DO KIM: ______________________

Page 3: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

II

Table of Contents 1. Introduction 1

1.1 Executive Summary 1

1.2 Project Description 1

1.3 Motivation and Objectives 2

1.4 Project Requirements and Specifications 2

1.5 Review of similar works 3

2. Literature Survey 4

2.1 Electronic Luggage Follower 4

2.2 Autonomous Robot Luggage 4

2.3 Autonomous Mobile Payload Vehicle (AMP-V) 5

2.4 Autonomous Brilliantly Engineered Cooler (ABEC) 6

3. Design Alternatives 8

3.1 Overview of Conceptual Designs 8

3.1.1 Block Diagram 8

3.1.2 Power System 9

3.1.3 Chassis 9

3.1.4 Wheels and motors 9

3.1.5 Sensors 10

3.1.6 Path Tracking System 10

3.1.7 Obstacle Avoidance System 10

3.1.8 Microcontroller Requirements 11

3.1.9 Motor Controller Requirements 12

4. Project Management 13

4.1 Group Organization 13

5. Engineering Design and Analysis 14

5.1 Chassis and Vehicle Body 14

5.2 Suspension System 15

5.3 Wheel Classification 15

5.3.1 Types of Wheels 15

Page 4: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

III

5.3.1.1 Standard or Caster Wheels 16

5.3.1.2 Swedish Wheels 16

5.3.1.3 Spherical or ball Wheels 16

5.3.2 Characteristics of Wheels 17

5.3.2.1 Stability 17

5.3.2.2 Maneuverability 18

5.3.2.3 Controllability 18

5.3.3 Selecting a Wheel Configuration 18

5.3.4 How to Obtain Locomotion 19

5.3.4.1 Differential Driving 19

5.3.4.2 Ackerman Driving 20

5.3.4.3 Synchronous Driving 21

5.3.4.4 Omnidirectional Driving 22

5.3.5 Mechanical Design of Wheeled Robots 23

5.3.6 Braking 25

5.3.6.1 Mechanical Method 25

5.3.6.2 Electronic Method 25

5.3.6.3 Coding Method 26

5.4 Battery 26

5.4.1 Types of Batteries 26

5.4.1.1 NiCad (Nickel Cadmium) 27

5.4.1.2 NiMH (Nickel Metal Hydride) 29

5.4.1.3 Alkaline 29

5.4.1.4 Lithium Ion (Li-Ion) 31

5.4.2 Battery Comparison and selection 32

5.4.3 Recharging the Battery 34

5.4.3.1 Solar Powered Battery Charging 34

5.4.4 Wall Mount Battery Charger 37

Page 5: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

IV

5.5 Power Transmission 37

5.5.1 Power Distribution and Regulation 37

5.5.1.1 Texas Instrument Model LM2941 39

5.5.1.2 Linear Technology Model LT3014 40

5.5.1.3 LM7809 Linear Regulator 41

5.5.1.4 LM7805 Linear Voltage Regulator 41

5.5.1.5 PTH0407W Switching Voltage Regulator 42

5.5.1.6 DE-SW050 Switching Voltage Regulator 44

5.5.1.7 Linear Technology Model LT1121 46

5.6 Motors 48

5.6.1 Types of Motors 48

5.6.1.1 Brushed DC Motor 48

5.6.1.2 Brushless DC Motor 49

5.6.1.3 Geared DC Motor 49

5.6.1.4 Stepper Motor 50

5.6.1.5 Servo Motor 51

5.6.2 Motor Controller 51

5.6.2.1 Texas Instruments Model L293D 53

5.6.2.2 Texas Instruments Model SN754410 54

5.6.2.3 Texas Instruments Model DRV 8833 54

5.6.3 Motor Comparison and Selection 55

5.7 Camera or Vision System 60

5.8 Sensors 62

5.8.1 Types of Sensors 62

5.8.1.1 Ultrasonic Proximity Sensor 62

5.8.1.2 Infrared Proximity Sensor 66

5.8.1.3 Weight Sensor 68

5.8.1.4 Accelerometer 70

Page 6: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

V

5.8.1.5 Gyroscope 73

5.9 Wireless Communication 74

5.9.1 Wi-Fi 74

5.9.2 Bluetooth 75

5.9.3 ZigBee 75

5.9.3.1 XBee 75

5.10 Localization 78

5.10.1 Absolute Localization 78

5.10.2 Relative Localization 79

5.11 Control Algorithm 86

5.12 Microcontroller 91

5.12.1 MC68332 92

5.12.2 PIC 18F452 92

5.12.3 Intel 8051 92

5.12.4 Atmel ATMega2560 92

5.12.5 Microcontroller comparison 93

5.13 Budget and Financing 96

5.13.1 Finance Table 97

5.13.2 Man-hour Costs 97

6. Design Summary of Hardware and Software 98

6.1 Power System 98

6.2 Control System 99

6.3 Motor System 100

6.4 Sensor System 100

6.5 Central Processing System 100

6.6 Code Flow 101

7. Description of Prototype 103

7.1 Prototype Design 103

7.2 Components List 103

7.3 Prototype Construction 104

Page 7: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

VI

7.3.1 Frame Assembly 105

7.3.2 Steering System 105

7.3.3 Sensors 106

8. Testing 107

8.1 Safety 107

8.2 Dimensions 107

8.3 Sound Level 107

8.4 System Tests 107

8.4.1 Radio Frequency Testing 107

8.4.2 PI Controller Testing 109

8.4.3 Ultrasonic Sensor Tests 109

8.4.4 Simple Movement Tests 110

8.4.5 Simple Following Tests 111

8.4.6 Basic Obstacle Avoidance Tests 113

8.4.7 Advance Maneuvering Tests 113

8.4.8 Indoor Performance Tests 114

8.4.9 Weight Sensors and Solar Recharging Tests 116

8.5 Efficiency 118

9. Engineering Consideration 119

10. Appendices 121

Page 8: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

VII

Table of Figures

Figure 1: ELF Conceptual Design 4

Figure 2: Autonomous Robot Luggage 5

Figure 3: Automated Mobile Payload Vehicle 6

Figure 4: Autonomous Brilliantly Engineered Cooler 7

Figure 5: Basic Block Diagram of Knight Gear 8

Figure 6: Omnidirectional Wheels 17

Figure 7: Differential Drive 20

Figure 8: Ackerman Steering Technique 21

Figure 9: Synchronous Driving 22

Figure 10: Omnidirectional Driving 23

Figure 11: Ni-Cad Discharge Rate 28

Figure 12: Discharge Rate of Alkaline Battery 30

Figure 13: Discharge Rate of Li-ion Battery 31

Figure 14: NiMH Battery for Knight Gear 34

Figure 15: Schematic of Solar Panel 35

Figure 16: Tenergy Universal NiMH Battery Charger 37

Figure 17: Typical Application of LM2940 Model 40

Figure 18: Typical Application of LT3014 Model 40

Figure 19: Typical Application of LM7809 Model 41

Figure 20: Typical Application of LM7805 Model 42

Figure 21: Typical Application of PTH0407W Model 42

Figure 22: Power Up Waveform 43

Figure 23: Efficiency of PTH0407W 44

Figure 24: Relative Size and Shape of DE-SW050 45

Figure 25: Efficiency of DE-SW050 Switching Voltage Regulator 45

Figure 26: Typical Application of LT1121 46

Figure 27: Block Diagram of Power Supply of Knight Gear 47

Page 9: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

VIII

Figure 28: Geared DC Motor for Knight Gear 50

Figure 29: Texas Instrument L293D Model 53

Figure 30: Texas Instrument DRV8833 Model 55

Figure 31: SN754410 Motor Driver for Knight Gear 57

Figure 32: Schematic of 3 pin SN754410 58

Figure 33: Schematic of 2 pin SN754410 59

Figure 34: LV-MaxSonar EZ Beam Pattern 64

Figure 35: PCB Layout of MaxSonar EZ2 65

Figure 36: Sensing Object within Infrared Proximity’s Detection Range 65

Figure 37: How Infrared Proximity Sensor Detects Object 67

Figure 38: Building Blocks of Infrared Proximity Sensor 67

Figure 39: Schematics of Load Cell SEN10245 69

Figure 40: Load Cell SEN10245 for Knight Gear 70

Figure 41: ADXL 35 PCB Layout 72

Figure 42: ADXL 335 for Knight Gear 72

Figure 43: PCB Layout of IDG500 74

Figure 44: Xbee Series 2 Chip 77

Figure 45: PNP Inverter 77

Figure 46: EM406 Connector for GPS Module 79

Figure 47: Relative Localization 80

Figure 48: Relative Coordinate System for Localization 83

Figure 49: Determination of Instantaneous Angular and Linear Velocities 85

Figure 50: Controller Block Diagram 86

Figure 51: Effect of Integral Coefficient 87

Figure 52: Effect of Proportional Coefficient 88

Figure 53: Effect of Derivative Coefficient 89

Figure 54: Class Diagram for Control Algorithm 91

Figure 55: Schematic Diagram for Mega Pro 3.3V 94

Page 10: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

IX

Figure 56: Pi Connections for Mega Pro 3.3V 95

Figure 57: Power Schematics for ATMega 2560 96

Figure 58: Discharge Curve for 9.6V NiMH Battery 99

Figure 59: Block Diagram of Navigated Control System 99

Figure 60: Code Flow of Knight Gear 102

Figure 61: Flow Chart for the Prototype Software 106

Figure 62: Xbee Testing 108

Figure 63: Xbee Communication Testing 108

Figure 64: PI Controller Testing 109

Page 11: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

X

Table of Tables

Table 1: Hardware and Software Requirements 3

Table 2: Distribution of Work 13

Table 3: Wheel Configuration 25

Table 4: Approximation of Voltage and Current Consumption 27

Table 5: Battery Comparison 33

Table 6: Motor IC Comparison 56

Table 7: Truth Table of 3 pin SN754410 Motor Controller 58

Table 8: Truth Table of 2 pin SN754410 Motor Controller 59

Table 9: Image Sensor Comparison 61

Table 10: Prepackaged Video Systems 61

Table 11: Ultrasonic Proximity Sensor Comparison 63

Table 12: Infrared Proximity Sensor Comparison 68

Table 13: Accelerometer Sensor Comparison 71

Table 14: Gyroscope Comparison 73

Table 15: Wireless Communication Methods 75

Table 16: Xbee Series Comparison 76

Table 17: Microcontroller Comparison 93

Table 18: Finance Table 97

Table 19: Components List 104

Table 20: Ultrasonic and Infrared Test 110

Table 21: Simple Movement Test 111

Table 22: Following Test 112

Table 23: Obstacle Avoidance Test 113

Table 24: Advanced Maneuvering Test 114

Table 25: Indoor Performance Tests 115

Table 26: Weight and Solar Recharging Test 117

Page 12: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

1

1. Introduction

1.1 Executive Summary

Backpacks are a necessity for most college students. Unlike high school, college campuses, like ours here in US, often involves a great deal of walking with little time between classes to run back to dorm rooms or parking lots and exchange the books. Therefore, some students get an idea to carry all the textbooks, laptops, lunches, and basically the rest of their life into their backpacks. This has not only resulted in enormous increase in the weight of the backpacks; in addition, carrying heavy backpacks cause hunchbacks, shoulder pain, back pain, and other upper body pain. This is the reason why our group came up with an idea to resolve the heavy backpack problem. Our group developed a self-driving backpack called ‘Knights Gear’, which tracks and follows along its owner to the classes and allows the user to walk without lugging it. The objective of our project was to make a light weight, low-cost, portable, and easy to use autonomous robot. The main components of Knights Gear were a four wheeled platform with DC gear motors, a microcontroller unit, a motor controller, ultrasonic sensors, and RF transmitter. The Knight Gear turns on/off manually on the backpack or using the remote controller (RF transmitter). The rechargeable battery in the Knight Gear was charged through solar energy. Solar panel was mounted on the top platform of the robot and fed the battery during the daylight. The ultrasonic sensors and were mounted on front side of the robot (on left and right) and they detect and send the distance between the user and robot, and then microcontroller calculates the speed and direction to the motor controller. Once motor controller receives the signal, and then it provides enough power to the each motors and the robot begins to follow the user keeping fair distance from it.

1.2 Project description

The Knight Gear is a self-driving backpack that tracks and follows its owner that allows the user to walk without carrying it. The Knights Gear allows certain amount of weight to be conveyed. The transmitter sends signals to Knight Gear informing its position at all times. Students will have this small and handy transmitter with them. As long as the transmitter is switched on and sending signals to Knight Gear, it will follow keeping enough distance from the user. For the transmitter, ultrasonic sensors are used for the wireless function of the robot. Knight Gear also uses ultrasonic sensor to detect and avoid any obstacle in front of it. These sensors prevent the Knight Gear from bumping onto obstacles such as people, wall, and other things on the floor that can block its path. Knight Gear also features an automatic shut-down system. If a student stops on the way for more than few minutes then this automatic shut-down feature comes into play. It

Page 13: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

2

shuts down the system to save power if the location of transmitter is not changed. The body of the Knight Gear is made to allow aerodynamics. On the platform, which is bottom side of the Knight Gear, all the components are organized in a stable and secure way.

1.3 Motivation and Objectives

They say knowledge is the key to success. If knowledge is the key, then indubitably backpack is a key holder- where books, notes, journals are accumulated. Backpack plays an essential role in students’ life. Starting from as early as pre-school to graduate schools, students’ prime source of carrying their notebooks, calculators and educational accessories have been backpacks. However, it is strange that though backpacks have become an important part of students’ academic life, it has only been recently invented in 1967 by Greg Lowe; and since then many more alterations to it has arrived. Its objective of students easily accessing their books, binders, pen, pencil to school were met, but with conspicuous impediments. As students approach to higher studies, more books and notes supplemented to their backpack. This has not only resulted in tremendous increase in the weight of the backpacks; in addition, carrying heavy backpacks engendered hunchbacks, shoulder pain, back pain, and other upper body pain. Consequently, students started avoiding carrying certain books or notes that might not be necessary for the particular day. Our project makes life easier for students. We propose a thesis that alleviates these hunchbacks, shoulder pain or any upper body pain due to backpacks. We propose Knight Gear! Knight gear is a tracking robot that will follow its owner or others (if specified) to the classes. The goal of Knight Gear is to completely replace the traditional way of carrying the burden on shoulders; using Knight Gear students can carry heavier weight than they used to by just push of a button. The main goal of our project is to make a light-weight, portable, low cost and easy to use microcontroller inside the backpack that has the ability to detect the owner and calculate the speed and direction to tracks and follows along the user. The Knight Gear should be easy to be used by any person.

1.4 Project specifications and requirements In this section, project specifications and requirements are defined in order to plan the project as shown in Table 1.

Page 14: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

3

Hardware specifications

Size At most 24’ tall

Raised 6’ off the ground

Weight 5 lb.

Maximum payload 45 lb.

Maximum Speed 5 mph

Sensors used Weight sensor

Infrared sensors Ultrasonic sensors

Battery Life Up to 4 hours (rechargeable)

Motors used DC gear motors

Wireless connectivity (transmitter to user)

5-6 feet

Obstacle avoidance Yes

Terrain Indoor/outdoor Paved roads

Software requirements

Programmable in C or C++ is required for the devices

Must be robust to any possible errors

Must be tested before use

The code for the each subsystems must intertwine with each other

Table 1 – hardware specification and software requirements for the project

1.5 Review of similar works

The project Knight Gear is similar to other works done in the past, by either previous senior design groups or by other works online. Since the basic function is a robot that follows a specific signal, it is very common to find other projects that have implemented this. In order for the group to learn how others have accomplished this function and how others have built similar style robots, review of other similar works was done.

Page 15: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

4

2. Literature Survey

2.1 Electronic Luggage Follower

One of the projects viewed was Electronic Luggage Follower (ELF) from the Florida International University. The purpose of that project was to create a robot that was capable of assisting travelers with their luggage as they go through an airport. The robot was capable of following a single target and avoiding obstacles using sensors. This project, as shown in figure 1, was very similar to our idea for Knight Gear, in that it had the same basic functionality of carrying around a load for a specific user and following said user around. Since obstacle avoidance is also an important function of Knight Gear, this report gave the group some light on the knowhow of achieving this. ELF on the other hand was small and carried a smaller load that what Knight Gear is planned on carrying.

Figure 1 – ELF conceptual design Permission Pending

2.2 Autonomous Robot Luggage

Another project that has inspired Knight Gear is the project Autonomous Robot Luggage, shown in figure 2. This project was done by a hobbyist by the name of Benjamin Heckendorn. His idea was to create a way to have luggage follow a user whenever the user did not want to manually pull the luggage around. The robot luggage he created was a very low cost project because it was meant to be for hobby enthusiast. Benjamin’s robot showed the group how to implement the basic functions of Knight Gear in a cost effective way.

Page 16: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

5

Figure 2 – Autonomous Robot Luggage Permission Pending

2.3 Autonomous Mobile Payload Vehicle (AMP-V)

The AMP-V was a previous senior design project done by group 1 of the University of Central Florida’s Senior Design class of Fall 2011 to Spring 2012. The idea behind the robot was practically the same as ours, to carry the user’s payload in a stress-free manner. Doctor Samuel Richie informed us of this project, and told us of parts of which did not work as well as intended. From studying this project we learned to avoid using caterpillar tracks as a means of motions. AMP-V however had a big carrying capacity than the ELF mentioned previously, however its weight to payload ratio was less than desirable with a weight less than 35 pounds and a max payload weight of 25 pounds. The project was solar-rechargeable, and inspired us on our design or our robot. The AMP-V group had to fabricate their own chassis, which can be seen in figure 3, which we used as an inspiration on building our own chassis for Knight Gear.

Page 17: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

6

Figure 3 – Automated Mobile Payload Vehicle Permission Pending

2.4 Autonomous Brilliantly Engineered Cooler

(ABEC)

ABEC was a previous University of Central Florida Senior Design project with a

similar objective as Knight Gear, but with a more specific payload. This project

used a premade chassis and used GPS to follow the user. ABEC also utilized 3

ultrasonic sensors in the front of their robot for object detection and avoidance.

From this we took inspiration from their object avoidance system as well as using

their GPS localization and following systems as a backup system to the infrared

and ultrasonic system currently planned for Knight Gear. ABEC can be seen in

the figure below, figure 4.

Page 18: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

7

Figure 4 – Autonomous Brilliantly Engineered Cooler Permission Pending

Page 19: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

8

3. Design Alternatives

3.1 Overview of Conceptual Design

This section contains all the information about the physical requirements of Knight Gear, extending to the software needed to code the controller algorithms. This also contains information on our design choices for Knight Gear.

3.1.1 BLOCK DIAGRAM

This is the overall block diagram that is supposed to be followed for the implementation of Knight Gear is depicted below in figure 5.

Figure 5 – This is a basic block diagram of Knight Gear.

Page 20: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

9

3.1.2 Power System

The Knights Gear needed a good power supply that can put out a reasonable amount of current for the DC motors as well as run a microcontroller and sensors. There are many different types of batteries that were needed to be considered for a power source of the robot. The crucial factors that were considered for the batteries include: long duration, high performance, fair cost, size and environmental friendliness. Another important consideration for the battery was its recharge ability. It is not supposed to take too much time to recharge. Also, in order to operate the Knights Gear for a longer time, the power management systems was also considered. Moreover, using a photocell charger for the batteries turned out to be a good way to extend the battery life. Therefore, a solar powered battery charger was used to perform this requirement.

3.1.3 Chassis

The designing of the chassis for the Knights Gear was very important because the main task of the robot was to convey the heavy textbooks. Therefore the chassis should easily bear much of the heavy weigh. Just enough weight that our motors could support. Also, the size of the chassis should just be large enough for the batteries, circuits, and the wheels to be installed. The platform of the circuit has been placed on the bottom side of the chassis thus there must be a protection board above the circuit to protect it from the heavy payloads.

In the design of the platform that would carry backpack, some factors were taken into consideration. It is meant to be light weighted, but of a strong enough material to hold the fully loaded backpack. Also it must be cost effective that designing the entire chassis should not be over 50 dollars.

3.1.4 Wheels and Motor

When deciding on what type of locomotion for Knight Gear we looked at continuous tracks, six-wheel, and four-wheel. Continuous track also known as caterpillar tracks, or tank treads, are a track had of either steel, rubber, or a combination of steel and rubber, rotated by a series of sprockets. The continuous tracks turned out to be a better option than tires through rough terrain and can glide over small obstacles and small gaps in the ground, and are less likely to get stuck in mud. However they lack in speed and maneuverability compared to tires and they are harder to maintain, as the loss of a single segment of track immobilizes the entire vehicle. Additionally, the tracks has the potential to slip off their sprockets and jam, which in worst case scenario, the track would need to be broken before the jam can be fixed.

Page 21: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

10

Due to the difficulty in maintenance and lower maneuverability and top speed compared to wheels, we decided not to work with continuous tracks and instead focus on a wheel vehicle. From here the decision came down to either using four-wheel locomotion or six-wheel locomotion. In the end our group decided to have four-wheel robotic locomotion for the Knight Gear, because it can handle relatively rough terrain and move at high speeds. While a six-wheel drive could do the similar to a four-wheel drive or marginally better than four wheels, it was more economically reasonable to just go with the four-wheels and four motors. A suspension system was required to allow all four wheels to maintain ground contact when the robot encounters the uneven terrain. Also, a deformable tire of soft rubber to the wheel shall be applied to create a primitive suspension. Two main wheels were powered by dc motors which are independently controlled for steering. The dc motors of the Knights Gear had enough torque and power to handle the heavy weight of the payload. Also it must be reversible to assist the steering system of the robot.

3.1.5 Sensor The most important task of the Knights Gear was to acquire knowledge about its surroundings. This task was done by taking measurements using various sensors and extracting meaningful information from those measurements. The sensors were easy to test and interface well with our selected microcontroller.

3.1.6 Path tracking system

This is the most important part of the project. The ultrasonic sensors were used to do this job. The ultrasonic sensors are widely used for distance measurement for the autonomous robots. The ultrasonic sensors use sound to measure the time between when a signal is sent versus when its echo is received back. Once the user turn on the device manually or using the remote control (transmitter), the sensors on the backpack receive the signal from it and feed the microcontroller to calculate the distance and direction between them. The Knights Gear follows its user keeping the distance of five to six feet.

3.1.7 Obstacle avoidance system

The Knights Gear will guide itself when an obstacle comes ahead of it. The ultrasonic sensors and infrared sensors will be used to detect any obstacle ahead of it and send the signals to the microcontroller. This distance information is then used to calculate a destination direction that the Knights Gear must move towards. Then, the motor controller actuating the motors interfaced to it to move the Knights Gear in an alternate direction.

Page 22: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

11

3.1.8 Microcontroller requirements

A microcontroller is a computing device capable of executing a program and it is usually responsible for all computations, decision making, and communications. There are many different microcontrollers available on the market (Arduino, BasicX, Polou, Parallax, BasicATOM etc.) and they have different range of products, specifications and potential applications. Therefore, a great amount of research should be conducted to find the right microcontroller for our project.

The microcontroller for the Knight Gear robot is small enough to be mounted on the platform. There are two motors, four-wheels, and a motor-controller on the platform, thus, a small size of the microcontroller was appropriate. The controller must be low cost but strong enough to take care of many tasks simultaneously. Since the budget of our group was small and limited, it was very important to find a company with a range of products within our budget. Also, the microcontroller was supposed to be powerful and capable enough to control and monitor the motor-controller, ultrasonic sensors, and radio frequency antennas simultaneously. Thus, the microcontroller carries out enough amount of processing, and which is influenced by factors such as processor clock speed, and internal data bus size and speed. The Word size was another important performance factor to be considered, because it affects the amount of data that the microcontroller can manipulate during a single instruction cycle. It also affects the range of numbers that can be handled. However, a larger word size was not necessarily better for the performance. For instance, if a system functionality can be implemented using an 8-bit Microcontroller, instead of using 16-Bit or 32-Bit Microcontroller. This may increase the complexity of the project and needs extra efforts demanded by the pricy Microcontroller. The controller also has enough input and output ports. The Knights Gear has at least three ultrasonic sensors two radio frequency antennas and a motor-controller, thus, the microcontroller must have minimum of six ports on it. Support and documentation is an important factor to be considered as well. Many microcontrollers are open source and have an active online community of supporters. Thus, our group needed to choose the right microcontroller company that had plenty of technical support and active online communities. Programmable language was another factor to be considered. Since most of the group members were familiar with C or C++, the microcontroller relied on these program languages was preferable.

Page 23: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

12

3.1.9 Motor controller requirements

A motor controller was an electronic device that acted as an intermediate device between a microcontroller, a power supply and the motors. Although the microcontroller calculated the speed and direction of the robot, it cannot operate them directly because of its limited power output. Therefore the motor controller that was needed for the Knight Gear provides enough current for the motors. The motor controller was small but powerful enough to move the fully loaded Knights Gear. The maximum speed of the robot would be 5 mph which was faster than the average walking speed.

Page 24: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

13

4. Project Management

4.1 Group Organization

In this project of Knight Gear, each person was given specific tasks to fulfill. These tasks accumulated to form Knight Gear. If someone in the group doesn’t complete or gets lazy, then other group members encourage and assist the person to get through the lean patch and accomplish the goal of this project. Everyone offered more than 100 percent in completion of Senior Design I documentation.

Knight Gear is a project that incorporates the various combinations of sub-systems together. These sub-systems were individually divided among the group members to ease the complexity of the design. Each group member did enough research to define, design and implements their respective sub-system and components. The division of the project, Knight Gear, is displayed below in Table 2.

Subsystem Group Member

Main Software Rene Gajardo

Linear Control System Siddharth Padhi

Frame Do Kim

Motors Do Kim

Power Supply Do Kim

Microcontroller Jorge Morales

Sensors Siddharth Padhi

Wheel Configuration Siddharth Padhi

Wireless Communication Rene Gajardo

Video System Siddharth Padhi

PCB Board Jorge Morales

GPS Siddharth Padhi

Autonomous Algorithms Rene Gajardo

Documentation formatting Jorge Morales

Table 2 – Distribution of work

Page 25: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

14

5. Engineering Analysis and Design

5.1 Chassis and Vehicle Body

The chassis and body design was a very important part of the project. Due to the size and payload of the Knight Gear, it was very hard to find the pre-made chassis from the most of hobby shops. Thus, our group decided to build it using raw materials like wood, plastic, or metals until we found the pre-made chassis or complete robot kits that chassis and wheels were combined to satisfy the requirement of our robot.

In the design of the chassis, several factors were taken into consideration. It was supposed to be cost effective, designing an entire chassis should not exceed an amount of 50 dollars, and it must be light weight, but of a strong enough material. Since, one of the important features of Knight Gear is to convey the heavy back pack; the chassis should easily bear the heavy weight up to 30 pounds. Also, the size of the chassis must be large enough for the batteries, electronics, and the wheels to be installed. There were several materials that we considered to be useful for the chassis of the Knight Gear.

The wood was extremely light weighted and very inexpensive materials that satisfied our weighing needs, and low cost management requirement for the chassis. However, they were very fragile and have low strength that cannot bear the heavy weight of the payload. This drawback of wood made it unsuitable material for our robot.

Aluminum was another material that could have been used for the chassis. They were light weighted also and very strong material that could withstand the heavy payload. They were not hard to work with and they were very easy to cut, shape, drill and bend. Moreover, aluminum has very high thermal conductivity; it could be useful to serve as a function of heat sinks for the robot. Only drawback of this material was its price is quite expensive. Thus, it would not be the cost effective to use the aluminum as basis material for the entire body of the robot.

The High Density Polyethylene or HDPE was another material that could be used for the chassis. The HDPE is very widely used in the chassis design of robot because it is inexpensive and very light but strong that have higher strength to weight ratio than metals. Also, the HDPE has very low thermal conductivity that it would be perfect for base part of the Knight Gear where the most of heat is generated.

In conclusion, our group decided to use both HDPE and aluminum materials to design our robot. The HDPE was used as basis material for the robot that platforms and sides of the robot were made with this material. The aluminum was used to connect the HDPE sheets, and to reinforce the strength of the base platform. According to the mcmaster.com, price of the 24’x48’x0.25’ HDPE sheet came out to be 27.30 dollars. This was large enough to make the every structural component.

Page 26: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

15

5.2 Suspension system The reason that suspension system was needed for the Knight Gear is because our robot has four wheels. When the four wheels were used in robot, it was not guaranteed that all the four points were on the plane. If the terrain was not even, such as the robot should climb over some small object, one of the wheels could lift off from the ground. This could potentially cause the robot to fall off to the ground. Moreover, if no suspension system was installed, the robot would receive high frequency shock from the ground. This vibration could damage the electronic devices on the robot, and also loosening the bolts that connects the joints of the robot body. Thus suspension system is highly recommended for the Knight Gear to increase the mobility over rough and uneven terrain and prevent the damage from the load. However, developing the suspension system was not quite easy. They involve many complicated parts, calculations, and were very expensive. The pre-made suspension part were already available in many robot shops but they were too pricy (minimum price is 30 dollars for each side). Therefore our group developed a simple suspension system by ourselves. We installed rubber of spring shock absorber for the each motor mount to function as suspension system. Although its performance would be quite low compared to the pre-made suspension system, we believe that it would help the mobility and prevent the vibration of the Knight Gear.

5.3 Wheel Classification

5.3.1 Types of Wheels

Just like any other robot, Knight Gear needed a locomotion mechanism to enable movement through its surroundings. There were several mechanisms to accomplish locomotion but most of them were either legged or wheeled. As far as Knight Gear goes, wheel was more appropriate option to enable movement than legged. Wheels were relatively easy to mechanically implement on Knight Gear. Balance control was not an issue because Knight Gear would have 4 wheels. Wheeled locomotion was very power efficient, even at high speed. Stability was also not a major concern in wheeled vehicle. It would provide smooth transition while carrying a decent high school or college load. Selecting the right type of wheel was almost as important as choosing the type of sensors and motors.

Wheels contradict broadly in terms of their performance in kinematics; as a result selecting the right type of wheels was dependent on the overall kinematics of Knight Gear. While wheels’ kinematics decided what type of motion is achievable, wheel’s geometry was also a key factor to look into which was closely linked to Knight Gear. The composition of wheel’s kinematic and its arrangement dictated the stability, maneuverability, and controllability of the vehicle. For instance, a car uses Ackermann wheel configuration where there are two wheels in the front are steerable and non-motorized and the two wheels in the rear are non-steerable

Page 27: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

16

but are motorized. The wheels are connected to an axis. A lot of automobile companies use this configuration for cars because it provides maximum stability, maneuverability and controllability for a given environment. In case of Knight Gear, it was difficult to select a wheel that would provide optimum results because it has to run indoors and outdoors including grass. There were about 4 different types of basic wheels. These are the following listed below:

Standard wheel with 2 degrees of freedom,

Castor wheel with 2 degrees of freedom,

Swedish 45 and 90 degrees or Omnidirectional wheel with 3 degrees of freedom, and

Ball or spherical wheel. These are omnidirectional also but fairly difficult to implement.

5.3.1.1 Standard and Caster wheels

Standard and Castor wheel were easy to implement. They had high load capacity and very high tolerance to, if there are any, ground anomalies. The high load capacitance and resistance to irregularities made it a good pick for Knight Gear; however, these were not omnidirectional. In order to achieve some sort of directionality, the steerable wheels were steered along the vertical axis and move around the horizontal axis. The configuration was easy to implement but when there was a high load then this method does not work. The vehicle does not move and causes high friction, increases the power consumption and reduces the accuracy of localization of the vehicle. Therefore, such wheels may not be the optimal choice for Knight Gear.

5.3.1.2 Swedish wheels

Swedish wheels were like normal wheels except that it offered low resistance to ground irregularities. Wheels run smoothly in any direction. The rollers connected to the surface of the wheel were passive. In addition, the only actively powered joint was served by its primary axis. The advantage of this type of configuration was that wheel can kinematically be in motion with very little friction along the ground and many other trajectories.

5.3.1.3 Spherical or Ball wheel

These were omnidirectional wheels. There were numerous ways in which spherical wheels can be implemented to Knight Gear. One of these was invented by West and Asada in 1997 as shown in the figure 6 in the next page.

Page 28: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

17

Figure 6 – Omnidirectional Wheels Permission Pending

In this design, power was transmitted from gears to roller right and then to the ball through friction between the roller and the ball. The ball rolled passively in any direction because the rollers were fixed at the roller right chassis and are actively powered.

Like it is explained above that the wheel type and wheel configuration were tremendously important. They influence the fundamental characteristics of:

Stability,

Maneuverability, and

Controllability

5.3.2 Characteristics of Wheels

5.3.2.1 Stability

Stability was a major concern when it came to mobile robots. Knight Gear should not lose balance while following its user regardless of moving in smooth or rough surfaces. In order to gain stability, a minimum of 2 wheels were required. In some of the configurations, these vehicles attain stability when the center of mass of the vehicle is underneath the wheel axle. In other configurations, wheels were required to make ground contact to accomplish static stability. Knight Gear has four wheels; this gives enough support and balance to achieve optimum stability.

Page 29: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

18

5.3.2.2 Maneuverability

Maneuverability was also a very crucial aspect of Knight Gear. An omnidirectional robot has the ability to move in any direction. Such movement was actively powered by its omnidirectional wheels that can move in more in more than 1 direction like Swedish wheels. Vehicles using Ackermann steering configuration have turning radius that is larger than the vehicle itself. As result, it was unable to move sideways. These required a combination of changes in wheel direction of forward and rear wheels to produce movement. Robots and vehicles using such steering and wheel configurations were comparatively cheaper than having omnidirectional wheels.

5.3.2.3 Controllability

Controllability is inversely proportional to maneuverability. Vehicles with high controllability will have low maneuverability. The omnidirectional wheel’s configuration allowed vehicle to achieve very high maneuverability, however this strength of the robot makes it convoluted to control the robot. For instance, in Carnegie Mellon’s Uranus robot all four wheels were to be driven at exactly the same speed in order to provide locomotion in precisely a straight line. Even minute errors in the speed of the wheels result in deviation from the desired path. However, because this vehicle used Ackermann steering configuration, the controllability of this robot was very straightforward and easy. Locking the wheels and only driving the motorized wheels resulted in a perfect straight motion. It was able to achieve same speed in all the four wheels because all of the wheels are connected to just one axis. Hence, the speed of an individual wheel will always be the same as others. Therefore, it was impossible to achieve optimum controllability along with maneuverability. One had to go down to strengthen the other.

5.3.3 Selecting a wheel configuration

From the research performed, wheeled robots were indubitably the better choice for Knight Gear than legged robots due to the following reasons:

Designing and implementation of wheeled structure was less complex than legged structure.

Standard designing techniques, control feedback systems, algorithm techniques and structural components were easily available for wheeled robots.

Wheels have faster response to a command. This was a major aspect of Knight Gear. Immediate response was necessary, to travel indoors or outdoors, with respect to user’s localization and time.

Percentage of error was higher in legged robot. Therefore, it was not the most efficient choice for Knight Gear.

Page 30: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

19

Legged robots consumed very high amount of power when compared to wheeled robots.

Once it was decided to use wheels over legged robots, it was important to choose which type of wheels to use for Knight Gear. Usually for a locomotive robot, most of the researchers and past projects have decided to go with omnidirectional wheels because they can carry the robot to any direction. However, standard wheels or caster wheels were more suitable for Knight Gear. Although, these wheels do not travel in all direction; but steering can be configured to reach out in all directions. Standard wheels made an optimal choice for Knight Gear because of the following reasons:

It was very easy to implement with all the available components.

The feedback from the standard wheel was higher than Swedish wheels and omnidirectional wheels for rotational directional change.

The change in speed does not affect Knight Gear directly.

If omnidirectional wheels were chosen, convoluted algorithms and calculations would have been needed to fulfill Knight Gear’s need. Whereas, algorithms for standard wheels are not that complex.

5.3.4 How to Obtain Locomotion

There were several mechanisms to provide locomotion that was required for the Knight Gear. These driving techniques are the following:

Differential drive,

Ackerman steering,

Synchronous drive, and

Omnidirectional drive

5.3.4.1 Differential Driving

In differential driving, wheels rotate at different speeds when turning around the corners. It is very similar to ‘tank-type’ steering but should not be confused with tank treads. Differential driving controls the speed of individual wheels to provide directionality in robot. The figure 7 on next page shows how changing the speed offered directional motion to robots. Correction factor was also required to be added to motor speed in order to fix the possible error that may occur due to difference in number of rotations of each wheel. The figure below shows how direction can be achieved in the robot. According to robotplatform.com –

“If the angular velocities are identical… then the robot tends to spin around its vertical axis. This compete turn capability is one of the greatest advantages of a differential driven robot.”

Page 31: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

20

“If the angular velocities are identical in terms of values and opposite in direction, then the robot is more likely to follow a linear path, either forward or backward based on the motors spin.”

“If the angular velocities are different in terms of values (same or different direction), then the robot makes a cure motion.”

Figure 7 – Differential Drive Permission Pending

5.3.4.2 Ackerman Driving

Ackerman steering, displayed in figure 8, was a configuration that is very often used in cars today. This configuration includes two motors: one single motor drives the wheels and another motor controls the steering. According to robotplatform.com, the merits of Ackerman steering were increased control, better stability, and maneuverability on road, less slippage and less power consumption. The turning radius of this type of configuration may cause the robot to skid but the inner tire turns with greater angle that the outer tire avoiding any tire slippage.

Page 32: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

21

Figure 8 – Ackerman Steering Technique Permission Pending

5.3.4.3 Synchronous Driving

In this technique, one motor synchronously actuates all the wheels and other motor defines the speed of the vehicle. As shown in figure 9, the second motor controlled the speed and steering of all the wheels. This happened to be the best design possible for even surfaces. It can be implemented with 3 or 4 wheels; more the wheels, more the design and algorithm complexities of robot’s motion analysis. Figure below shows how it can be executed by connecting wheels by a single drive and steer belt to the motor.

Page 33: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

22

Figure 9 – Synchronous Drive Technique Permission Pending from Robotplatform.com

5.3.4.4 Omnidirectional driving

Omnidirectional driving can be achieved by using Omni wheels and/or Caster wheels. Omni wheels consisted of small and big wheels. Small wheels were hooked up perpendicularly to the inner circumference of the bigger wheel. This allowed the wheel to move in any direction almost right away. One of the key merits of omnidirectional driving was that wheels do not rotate or turn to move in any direction. They were able to move in any direction without changing the orientation. Omni wheels were available is various varieties and coordinates as shown in figure 10.

Page 34: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

23

Figure 10 – Omnidirectional Driving Permission Pending

5.3.5 Mechanical design of wheeled robots

After choosing what type of locomotion to choose, what type of wheels to use, building the frame for wheels was itself a very important task. There were certain features that were to be taken care of while building the frame for Knight Gear. These features included appropriate configuration and orientation of wheels and correct procedures to achieve required motion.

1. Weight of Knight Gear – Most of the times the weight of the robot was mainly due to the type batteries, the motor system, the weight of the chassis and the frame itself. The robot maintained the optimal weight to offer desired motion.

2. Arrangements of components – The inclusion of sensors, motors, circuits, and other components were to be compatible with the frame of robot. It had to be wheel structured so; it did not disturb the stability of the Knight Gear.

Page 35: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

24

Here are several of the wheeled configurations available for a robot shown in Table 3:

Wheel Configuration Illustration Description

Static unstable two-wheeled

The front wheel allows controlling the orientation i.e. steering and the rear

wheel drives the vehicle.

Static stable two-wheeled

If the center of mass is below the wheel axle, this type of wheel achieves stability. The desired speed is achieved by changing the speeds and directions of the

wheels.

Differential drive with a castor wheel

The center of gravity should be maintained within the triangle formed by the ground contact

points of the wheels.

Tri-cycle drive, front/rear steering and

rear/front driving

The drive wheels are at the rear of the robot. A differential allows the vehicle to avoid the mechanical

destruction.

Tri-cycle drive combined steering and

driving.

The front wheel is used for both driving and steering. The two wheels in the rear keep the

stability of the robot.

Synchronous drive wheel

The synchronous drive system consists of a two motor drive

configuration. One motor rotates wheels and another motor

changes direction.

Page 36: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

25

Front driven/steered Ackerman steering and

Front steered/rear driven Ackerman

steering

The difference of these two mechanisms is similar to the three

wheel system mentioned previously.

Omnidirectional

By changing the rotational speeds and directions of each drive the

required locomotion can be achieved.

Table 3 – Wheel Configurations

5.3.6 Braking Systems

Many of the motion done by the robot Knight Gear were done with the purpose of following its target. But there will be times when the robot will need to do a sudden stop or need to not move. When implementing DC motors into Knight Gear, the action of braking can be established with three different methods. It can be either done mechanically, electronically, or through coding. All three will be explained and one was chosen as the appropriate method for braking in Knight Gear.

5.3.6.1 Mechanical Method

The mechanical method of braking was one of the most common seen today with large automobiles. This method involved using a very high amount of friction on the axel or wheel to stop the robot from moving. Equivalence to this would be a brake pad on a vehicle pushing against the drum of the wheel. The downside to this method was that it would be purely mechanical and would take time to implement this properly so it works every time.

5.3.6.2 Electronic Method

The electronic method of braking in a robot was one that varies depending on the motor. This method required that the power be shorted and the ground be connected to the ground. Certain motors would break easily than other when shorted out. The motor, however, would still continue to rotate, but it would also oppose the rotation toward the direction of movement. Although it could be unreliable because it all depends on the motor, it is simple to implement. This

Page 37: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

26

method was viable when cost needs to be kept at a minimum because no extra parts are needed.

5.3.6.3 Coding Method

The coding method for braking was the last of the three methods for implementing a braking system in a robot. It was the most accurate method for completely stopping the robot in place. The implementation of this method required some coding and knowledge of the current velocity of the robot. By finding out the current velocity of the robot, a signal can be sent to the motor controller to make the motor turn in reverse until the velocity of the robot is zero. Although it could become tedious to check the velocity every time the robot has to stop, it can make the stop more stable no matter where it is positioned. Whether it is on a flat surface, or an incline, with this method the robot can fully stop anywhere.

In conclusion, the coding method was the one chosen to implement into Knight Gear for the braking system. Since it was the only one that required no extra components, and since it purely coding, it would be much simpler to implement than a brake pad or an extra switch.

However, due to time constraints and the unfortunate mishaps that occurred during the senior design 2 project, we did not have more than enough time to implement coding method in Knight Gear.

5.4 Battery

5.4.1 Types of Batteries Knight Gear needed to operate freely without power supply wired from the walls. Thus the batteries were needed to be installed to provide enough power for all the electric components inside the robot to work properly. The elements that consumed most of the power are microcontroller, dc motors, sensors, motor controller, and vision system. Following Table 4 summarizes the approximation of

the voltage and current consumption from each component of the Knight Gear.

Page 38: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

27

Devices Voltage Consumption Current Consumption

Microcontroller 5-9V 15mA

Motor controller 5V 15mA

DC motors 3-6V 500mA(x4)

Ultrasonic Proximity Sensor 2.5-5.5V 3.0-3.5mA

Infrared Proximity Sensor 2.5-6V 50mA

Weight sensor 9V -

Vision System - 50mA

Total ~2100mA

Table 4 – Approximation of the voltage and current consumption

From the approximation above, the DC motors consumed the majority of current and the batteries of the Knight Gear needed to provide at least 9V of voltage and 2100mA of currents. There were several different types of batteries that might use for the Knight Gear. The batteries were classified into two broad categories by its re-usability. The primary batteries (disposable batteries) were designed to be used once and discarded, and secondary batteries (rechargeable batteries) were designed to be recharged and used multiple times. For Knight Gear, our group decided to go with rechargeable batteries instead of ones that can’t be recharged because the idea that we were interested in solar powered battery charger. Also, the primary batteries that required constant replacement might pose to be costly due to the amount of trials we intend to run causing it to potentially be very expensive in the long term. Thus, buying a rechargeable battery might seem more expensive in short term; it was much more cost effective in long term of use than the primary batteries. There were many different kinds of rechargeable batteries with different technology in the market, however only several that had affordable price and the proper sizes for the Knight Gear were discussed.

5.4.1.1 NiCad (Nickel Cadmium)

The nickel-cadmium or NiCad was a rechargeable battery that used a nickel oxide hydroxide and metallic cadmium as electrodes. The NiCad batteries were good for small to medium size of robots like Knight Gear. They provided higher current output, and were more affordable than NiMH, and can be recharged within 2 hours.

For a common AA size cell, the maximum average discharge rate was about 1800mA, and the nominal cell potential was 1.25V. Another advantage was that they were easy to store and don’t damage under most normal circumstances.

Page 39: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

28

Also low temperatures do not usually affect the NiCad and it had a good load performance meaning that it accepted the charge on the first try. This made the Ni-Cad a good choice in any type of climate setting.

However, the NiCad battery does contain toxic metals that are considered environmentally unfriendly. This meant that if these batteries were used in Knight Gear, each battery must be removed before the equipment can be disposed of in a landfill or recycle center. Because of these toxic metal issues, some countries are limiting the use of this type of battery, which insured it would be harder to dispose of older used ones in the future. A memory effect is another big disadvantage of the NiCad batteries. When a NiCad battery has been charged a certain amount of times, eventually the battery starts remembering its maximum charge is something that it actually is not. That is to say the battery says it is 100 percent charged, but actually it is only 80 percent charged. Thus, over the many recharging process, the battery can only store less and less power after each charge. This memory effect could be prevented if the battery is recharged fully before its use. The NiCad batteries have flatter voltage vs. time curve during discharge, as it can be seen in figure 11. Therefore, the voltage is more the less the same during the discharging process. However this method can’t be fulfilled because the Knight Gear would use the solar powered battery recharging system that fully recharging the batteries at all the time is almost impossible.

Figure 11- Ni-Cad discharge rate Permission Pending

Page 40: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

29

5.4.1.2 NiMH (Nickel Metal Hydride) Nickel Metal Hydride or NiMH batteries were another type of rechargeable battery. The technology used in NiMH was very similar to the nickel cadmium battery (NiCad). The NiMH used positive electrodes of nickel ox-hydroxide like the NiCad, yet the negative electrodes used a hydrogen-absorbing alloy instead of cadmium. NiMH battery can have two to three times the capacity of a similar size NiCad, and their energy density come close to that of a lithium-ion (Li-ion) battery.

For a common AA size cell, the maximum discharge rate was about 1100mA to 2800mA, and the nominal cell potential was 1.25V. A complete discharge of this type of battery to its polarity could cause everlasting damage. Similar to the NiCad batteries, NiMH were not expensive and were light weight. Another big advantage of NiMH was that they had no problem with memory effect that NiCad batteries had. Also they don’t contain any toxic materials. Thus they pose less environmental hazard for its disposal than that of NiCad batteries. However the NiMH batteries came in various capacities. Therefore it was necessary to check to be sure that the battery had the right capacity for the Knight Gear to operate properly. Also, the battery with high capacity might not charge completely in some battery charger. Another disadvantage of NiCad was that they have short shelf life. That is to say if the battery is not in use for two to three months, they self-discharge at a rate up to 25% per month. The discharge rate was heavily related to the temperature, the rate increases as temperature goes high. Thus, with steamy hot weather in Florida, self-discharge rate would be poor. Moreover, compare to alkaline batteries, the NiMH have slightly less voltage just like NiCad.

5.4.1.3 Alkaline Alkaline batteries were available in both primary and secondary types. The Alkaline used the manganese dioxide as positive electrodes and zinc powder as negative electrodes. Similar to NiMH and NiCad, Alkaline batteries were inexpensive, light weight, and have small size. The common AA size cell, the maximum discharge rate as about 700mA and the nominal cell potential was about 1.5V. This was one of the benefit that rechargeable alkaline provide more voltage than NiMH and NiCad. Another advantage of Alkaline over the NiMH was that it lost the charge gradually that gives the notice when to recharge the batteries. The NiMH and NiCad tended to steep drop in voltage when they were in time to be recharged. Also, alkaline batteries do not contain the toxic metal and they can be disposable. Another

Page 41: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

30

benefit was that alkaline has very low self-discharge rate that it can hold the charge up to seven years. However, alkaline rechargeable batteries had a very big disadvantage that they have lower capacity compare to the NiMH. The capacity of an alkaline battery was heavily dependent on its load amount. Thus alkaline might had an adequate capacity about 2500mAh for low power devices but for the high power devices the capacity would be dropped to as little as 500mAh. Moreover, alkaline can’t be fully recharged. Each time it recharges the battery; they lose some portion of their capacity. Therefore the battery has fewer recharge cycles (as few as 10 cycles) than NiMH battery. The discharge curve of alkaline battery is shown below in figure 12.

Figure 12 - Discharge rate of Alkaline batteries Permission Pending

Page 42: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

31

5.4.1.4 Lithium-ion (Li-ion) A lithium-ion battery or Li-ion was another type of rechargeable battery. The Li-ion used an intercalated lithium compound as the electrode material that lithium ions moved from the negative electrode to the positive electrode during the discharge, and moved back to negative electrode during the charging process. Unlike the batteries discussed above, the Li-ion batteries were quite expensive, and have various shapes and size. One of the advantages of Li-ion battery was that they have one of the best weights to energy ratio. Thus they were much lighter than other rechargeable batteries. Also the energy density of Li-ion was generally twice that of the standard NiCad. The load characteristics were reasonably good and behave similarly to NiCad in terms of discharge. The discharging curve of Li-ion battery was shown in figure 13.The high cell potential of 3.6V allows battery pack designs with only one cell whereas NiMH and NiCad require several cells connected in series to have that potential. Moreover, Li-ion was a low maintenance battery that there was no memory effect and no scheduled cycling was required to maintain the battery’s life. Also, the self-discharge rate was much less than the NiCad.

Figure 13 - Discharge rate of Li-ion battery Permission Pending

Page 43: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

32

However, the Li-ion batteries were fragile and require a protection circuit to maintain the safe operation. The protection circuit must be built in the battery to limit the peak voltage of each cell during the charge and prevent the voltage from dropping too low on discharge process. Also, the cell temperature should be monitored to prevent the temperature extremes. The Li-ion battery was very dangerous compared to other secondary batteries because it could be erupted or explode in the high heat. Another disadvantage of Li-ion was that the life span was dependent upon aging from shelf life regardless of whether it was charged, and not just on the number of charge and discharge cycles. Also, as batteries age, their internal resistance rises. This causes the voltage at the terminals to drop below the load, reducing the maximum current that can be drawn from them. Eventually they reach a point at which the battery fails to operate frequently after two or three years. Another major disadvantage of Li-ion batteries was that they contain toxic metals and require disposal at a hazardous waste station.

5.4.2 Battery comparison and selection

As discussed above, there were four different types of batteries that were considered as the power supply of Knight Gear. The characteristics of those batteries are tabulated in Table 5 for us to make the best selection of the battery.

Page 44: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

33

NiCad NiMH Alkaline Li-ion

Voltage (V) 1.25 1.25 1.50 3.6

Capacity (mAH) 600 ~ 1500 Depends on

brand

1200 ~ 2600 Depends on

brand

2000 At first use

2100 Depends on brand

Capacity load Low High High High

Recharge cycle 1000

if charged properly

500 ~ 1000 10 ~ 50 300 ~ 1000

Charging time (fast charge)

1 ~ 1.5h 2 ~ 4h 2 ~ 3h 2 ~ 4h

Charge/discharge efficiency (%)

70 ~ 90 66 Varied by

capacity load 80 ~ 90

Operating temperature (°C)

-20 ~ 45 -20 ~ 45 -20 ~ 60 0 ~ 45

Over charging tolerance

Moderate Low Moderate Very low

Disposal Not available Available Available Not

available

Self-discharge rate 10% / month 25%

<2%

8% at 20 °C

15% at 40 °C

30% at 60 °C

Memory effect Yes No No No

Price $ 5~7 $ 5 ~ 7 $4 $ 7 ~ 10

Table 5 – Battery Comparison

In conclusion, the battery selected for the Knight Gear was NiMH, because this battery had high capacity, no memory effects and environmentally friendly. Also, the NiMH batteries can be charged at any time without affecting battery life which was good characteristic for our solar powered charging system. For the Knight Gear, 9.6V 2100mA battery will be used as power supply of robot. A display of the battery that will be used is shown below in figure 14.

Page 45: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

34

Figure 14 – This is a picture of NiMH battery that will be used to power Knight Gear

5.4.3 Recharging the Battery

5.4.3.1 Solar powered battery charging For Knight Gear, our group decide to go with rechargeable batteries instead of ones that can’t be recharged because the idea that we were interested in solar powered battery charger. The reason that we were interested in solar powered charger was because the solar energy was becoming increasingly popular as the people begin to take notice the high cost of electricity and the seriousness of environmental pollution. Advantages of solar energy were that they don’t produce any environmental pollution and generate electricity with no cost. Since there was no need of burning fossil to generate the electricity, solar energy was no harm to our environment. Also, the solar powered battery charger employs solar energy to supply electricity to charge batteries therefore it was always free to charge the batteries whenever the sunlight was provided by the sun. On the other hand, some disadvantages of solar energy were that their initial cost was to be very expensive, and they were only able to generate electricity during the daylight and no energy was to be produced for about half of each day.

Page 46: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

35

However, considering the fact that the sun’s light is readily available for free, this initial cost will be paid in a long term of use. In order to find the right solar panels for our project, some approximation should be made to get the solar energy power requirement. The energy stored in the NiMH battery pack is 9.6V * 2000mAh = 19.2W per hour. Thus if we select the solar panel that provide 5W per hour, then it would take at least four hours to completely recharge the batteries. Also, in order to connect the solar panels and the battery pack in parallel, Schottky diodes will be needed to prevent the batteries from discharging through the solar panel when there is no sunlight. The following diagram shows a simple schematic that possibly used for the connections between the battery and solar panels. The schematic of the solar panel is depicted below in figure 15.

Figure 15 – schematic diagram of the connection between battery and solar panels

After deciding on the amount of power needed to be drawn by the solar panels, we investigated on what type of panel to get. The material of the panel was important due to the different efficiencies of different materials in transforming solar energy into electricity. There were several different types of solar panel in used today. Some of the solar panels suitable for Knight Gear were the following:

1) Monocrystalline 2) Polycrystalline 3) Amorphous

Page 47: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

36

These types of solar panels were looked into in order to find the best match for Knight Gear. Monocrystalline

Monocrystalline silicone solar panels were the most efficient type of materials to use for solar panels. These were one of the oldest and most sturdy ones. Extremely pure molten silicon produces the crystal of silicon, which eventually leads to monocrystalline silicon. These panels were one of the most efficient by having an efficiency of 13-17%. Monocrystalline solar panels have lots of empty spaces and since they were cut from a single crystal and rarely fill up a square solar cell module. However, since they were made with high silicon content they were more expensive than other materials. They also require extra time and energy to produce such photovoltaic cell. Polycrystalline

In comparison to monocrystalline silicon, polycrystalline silicon were made from square cast ingots of silicon, they were also less expensive than their monocrystalline counter parts, but have a lower efficiency rate. As a result, one generally needs a larger polycrystalline solar panel to match the power output of a monocrystalline solar panel. These were also produced from extremely pure molten silicon however, using casting process. In the technique, silicon was heated at a very high temperature and then cooled down. This leads to a formation of poly-multi-crystal form. The silicon block was then cut into 0.3mm slices. The thickness of the anti-reflective layer determines the blue appearance of the silicon. It absorbs most of the sun light and reflects very little. Polycrystalline, like mentioned above, lacks in efficiency. The efficiency rate of such type of photovoltaic cell was 11-15%. Amorphous

This type of solar panel was non-crystalline silicon. Amorphous solar panels were most found in calculators. The production process requires only few raw materials therefore, the layer of semi-conductor coating was only 0.5-2 micro meters thick. The film of amorphous silicon was deposited as a gas on a smooth surface. Chemical process takes place to finish the process. The efficiency of amorphous photovoltaic cell was only about 6-8%.

In the end we decided to use small polycrystalline solar panels to build our battery recharger for Knight Gear. Even though they provided less efficiency than monocrystalline panels, it assisted our budget from going too high.

Page 48: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

37

5.4.4 Wall Mount Battery Charger (optional) Although our group decides to use solar energy to recharge the battery, wall mount battery charger might be needed for the fast charging. As discussed above, when a 5W solar panel was used for recharging, it would take at least four hours to completely recharge the battery. Therefore, the waiting time for recharging could be a waste of time when we conduct the many tests for our devices such as sensors, motors, and microcontroller. Thus, using a wall mount battery charger would shorten the time it takes for the testing process. Moreover, the solar panels were only able to generate electricity during the daylight and no energy would be produced for about half of each day. Also, there were times when cloud cover obscures the sun and the efficiency of solar panels drops. Therefore wall mount battery charger was optional but should be needed for the Knight Gear. The following picture was a candidate of the wall mount battery charge from Tenergy that would possibly be used for the optional charging method of power supply for the Knight Gear. The battery pack that would be used in the execution of knight gear is exemplified below in figure 16.

Figure 16 – Tenergy Smart Universal NiMH/NiCD Battery Pack Charger: 6V-12V

Reprinted with permission

5.5 Power Transmission 5.5.1 Power distribution and regulation Although we have a battery pack that provide sufficient voltages for every electric devices on the Knight Gear, power regulation circuit must be implemented to regulate this input voltage. In the Knight Gear, different electronics require different voltages. For instance, when microcontroller requires 5V, the gear motors require 9V, and several of sensors require different voltage as well. Thus if we connect the battery directly to the every devices, it would damage the circuit and the robots would fail to work. Moreover the batteries were never at a

Page 49: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

38

constant voltage that the electronic devices which were sensitive to the input voltage and operate correctly only within a certain narrow voltage range such as microcontroller and sensors could be damaged from it. Therefore the voltage regulation circuit must be implemented to prevent such problems. The voltage regulator was designed to maintain and provide constant voltage level for the devices. The most commonly used methods for the voltage regulation were using the linear and switching regulators. Switching Regulator In a switching regulator, transistors were turned completely on or off like a typical switch. When they were on lots of current could flow but there was almost no voltage across the transistor therefore the transistor dissipates very little power. When the transistor was off there was usually a voltage across the transistor but there was no current so again there was very little power. Energy was usually stored and filtered through inductors and capacitors and regulation was controlled by varying the percentage of time on versus off. The advantage to this was that if there was very little heat or wasted power, making this design capable of being very efficient. However, disadvantages of switching regulators were that they were more complex to implement than the linear regulator. They usually require inductors, transistors and filters for the circuit design. Switching voltage regulator processes by taking small loads of power, which comes from input voltage and then was redirected to the output. Switching regulators undergoes a process where an electric switch was used and a simple controller regulates the flow of energy, which was then transmitted to the output. There was very little amount of heat that was wasted in such type of regulator, which was why this was more efficient between the two types of regulators. It could achieve up to 85% of efficiency. In addition, the efficiency was less dependent on the input voltage. Therefore, it could power big loads from input voltages. Switching voltage regulators were ideal high efficiency was required. For instance, these could be mobile devices, digital cameras and computers. Although switching regulator provides great efficiency rate, it failed to simplify the implementation of design. These regulators were very convoluted. It incorporated a complex design circuit, which made it, slightly, unwanted among beginners. Switching regulators empowered any other regulators when it came to moving more than 200mA of load at high input voltages. Linear Regulator On the other hand, in a linear regulator, the transistor was turned partly on so as to provide the proper resistance to the load, thus the load always sees the same voltage. Since it is partly on, there was a definite voltage drop across the regulating transistor and there was as much current simultaneously as the load was demanding. Therefore power was being dissipated across the transistor

Page 50: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

39

which turns into heat. This heat was wasted power and the reason that switching regulators were more efficient than the linear regulators. Linear regulators were easy to use and were not very expensive. The process of linear regulators undergoes taking the difference between the input voltage and output voltage. This difference between voltages was directly proportional to the heat generated by the linear regulator. Hence, larger the difference between input and output voltage, the more the heat voltage regulator generates. As a matter of fact, some of the linear voltage regulators wasted power during stepping down voltage than what it actually ended up providing to a particular device. Efficiency of a linear voltage regulator was about 40%. Linear regular was not very efficient. Therefore, it could go as low as 14%. This inefficiency causes lot of wasteful heat that needs to be dissipated through large and expensive heatsink. This also causes a danger to the device’s battery life. There are several ways of determining which type of regulator, switching or linear, was suitable for Knight Gear. From the research done, it turned out that if the linear voltage regulation wasted less than 0.5W of power, then a switching regulation was not worth a try, given that it would go through the convoluted circuit design to improve the efficiency and its relatively high price was not ideal if the waste was less than 0.5W or power. While on the other hand, if the waste through linear regulation process was more than 0.5W then switching regulation was almost a must. However, considering that the Knight Gear was operating at low voltages and the heat waste will not be very critical, our group decided to go with the linear regulator for the power regulation system. Some of the criteria of the regulator that were needed to be considered for our project include type and range of the applied input voltage, required output voltage, maximum load current, minimum dropout voltage, quiescent current, power dissipation, and shutdown current.

5.5.1.1 Texas Instruments Model LM2941

The Texas Instruments model LM2941 was low dropout voltage regulator. A regulator’s dropout voltage was the voltage required between the input and the regulated output voltage. The LM2940, with a .5V of low dropout at 1 amp provide a regulated 5 volt output. Thus it was much cooler than the regular linear regulators. Some other low dropout voltage regulators would also be used to regulate the output voltage to 9V or 6V. The schematic of LM2941 is shown below in figure 17.

Page 51: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

40

Figure 17 – Typical application of Texas Instruments model LM2940 Reprinted with permission

5.5.1.2 Linear Technology Model LT3014

This model was another low dropout voltage regulator that provided wide range of input voltage from 3V to 80V with dropout voltage of 350mV. Advantage of this model was that output voltage can be adjusted in a large range from 1.22V to 60V. Also no extra diodes were needed for this model thus implementation was much easier. Disadvantage was that output current was only 20mA which was smaller than some devices’ current requirement. The schematic of LT3014 is shown on next page in figure 18.

Figure 18 – Typical application of Linear Technology model LT3014 Reprinted with permission

Page 52: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

41

5.5.1.3 LM7809 Linear Regulator

A 9V voltage regulator was needed to regulate high voltage coming from battery, which would be used to charge the devices. 9V LM7809 will supply inductive charging to Knight Gear. LM7809 linear regulator offered output current up to 1A and fixed output voltage from 5V to 24V. It also offered thermal overload and short circuit protection. The figure 19 below displays the schematic of LM7809 9V linear voltage regulator.

Figure 19 - Schematic of LM7809 Reprinted with permission from Texas Instruments

5.5.1.4 LM7805 Linear Voltage Regulator

LM7805 used a 5V linear voltage regulator. The three terminal L7805 linear voltage regulator was an ideal regulator for Knight Gear due to 5V output signal. According to the datasheet of this regulator, two capacitors were needed to be implemented for filtering. One of the capacitors was 0.33µF and other was 0.1µF. The 0.33µF was placed in parallel with the input voltage of LM7805 regulation. This particular capacitor would filter out any noise engendered from the voltage sources. The 0.1µF would also be placed in parallel to the output voltage of LM7805 regulation. This capacitor would reduce any noise generating from high frequency alternating current. Together, both of the capacitors would provide a clean signal of 5V. A schematic of LM 7805 is shown with the two capacitors in figure 20.

Page 53: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

42

Figure 20 - Schematic of LM7805 Reprinted with permission from Texas Instruments

5.5.1.5 PTH0407W Switching Voltage Regulator

PTH0407W was a voltage regulation that was highly integrated and provided up to 3A of current at very low price. The advantage of this voltage regulator was that it required less man hour work and cost of printed circuit board (PCB) design. It provided an output current at much higher efficiency and at low waste of heat. The input voltage varies from 3V to 5.5V. The switching regulator allowed to step down the voltage to as low as 0.9V to 5V with about 1W of dissipation of power. Furthermore, the output voltage varies from 0.9V to 3.6V with a resistor. PTH0407W switching voltage regulator incorporated on/off function. It also offered an under-voltage and over current protection system. Schematic of PTH0407W is shown on next page in figure 21.

Figure 21 - Schematic of PTH0407W

Reprinted with permission from Texas Instruments

Page 54: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

43

Pin 5 of this regulator was the on/off inhibitor. It set the output voltage to be turned off from this switching regulation. The product performs ideally when inhibit pin was opened. Use of a transistor was preferred and it applied low voltage to the inhibit control pin 5, when it was turned on. During the power up, internal “soft-start” circuit slows the rate of the rise of output voltage. Therefore, it reduced the current drawn from its input source. This “soft-start” circuit broached a short time delay of 10ms. This was where a valid input source was recognized. Figure 22, shows the power up rise from an input voltage of 3V and output voltage of 1.8V and measured current of 2A.

Figure 22 - Power up waveform

Reprinted with permission from Texas Instruments Any fault that may exist that could potentially limit a system’s capability in a system was protected by the output overcurrent protection system. This protection system does not allow PTH0407W to except the limited current value. Any attempt to increase current beyond this limitation would cause reduction in the output voltage. Current was supplied until the fault was completely removed from the system; and once it was removed, the output voltage was restored in no time. The efficiency of PTH0407W against the output current is shown below in figure 23.

Page 55: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

44

Figure 23 - Efficiency of PTH0407 at various given output voltage

Reprinted with Permission from Texas Instruments

5.5.1.6 DE-SW050 Switching Voltage Regulator DE-SW0XX is a family of switching voltage regulators that was very simple and very easy to integrate in a system. DE-SW050 offered the end user to take a load of up to 30V from a high input voltage and compress it to 5V in very efficient way. The efficiency of this voltage regulator was 83% and could reach to 87%, if used wisely. Another great advantage of this regulator was the already integrated decoupling capacitors. The following image in figure 24 is the relative size and shape of DM-SW050 switching regulator.

Page 56: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

45

Figure 24 - Relative size and shape of DE-SW050 Permission Pending

Although, it was relatively bigger in size when compared to other linear voltage regulators however the efficiency it generated was good enough to disregard the larger dimensions of this switching voltage regulator. The graph in figure 25 shows the efficiency against the input voltage

Figure 25 - Efficiency of DE-SW050 switching voltage regulator

Permission Pending

Page 57: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

46

5.5.1.7 Linear Technology Model LT1121

This low dropout voltage regulator also provided large range of input voltage from 3.75Vto 30V with dropout voltage of 400mA. Output voltage could be adjusted from 3.3V to 5V which was very suitable for our project. The schematic of LT1121 is shown below in figure 26.

Figure 26 – Typical application of Linear Technology model LT1121 Reprinted with permission

These were some candidates of the low dropout linear regulators that would possibly be used in the design of our power supply for the Knight Gear. Since our battery would provide 9.6V, this source voltage would be converted to the subsystems at voltages of 9V, 6V, and 3V by using the low dropout voltage regulators. The following diagram on the next page shown in figure 27 represents the overall concept of the power supply system that will be used for the Knight Gear.

Page 58: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

47

Figure 27 – Block diagram of power supply system of Knight Gear

However, as time progressed we decided to go with LM2940 and LM3940 Linear Voltage Regulators. LM2940 operated at 6V to 5V at 1A and LM3940 operated from 5V to 3.3V at 1A.

Page 59: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

48

5.6 Motors 5.6.1 Types of Motors For the Knights Gear to move along the user it was necessary to decide on what kind of motor to use. As specified in the requirement part of the report, four DC motors were supposed to be used for the Knights Gear. The reason we choose DC motors instead of AC motor was because our robot was powered with direct current (DC) coming from batteries and the electric components in the robot also uses DC. Thus, it was more convenient to have the same type of power supply for the motors. Also, the reason we choose four motors is because it made the robot easier to position and control. Some of the criteria of the motors that were needed to be considered for our project include RPM, torque, and ability to operate in both clockwise and counter-clockwise direction, and minimum voltage and current need. There were several different types of DC motors that were commonly used in four wheeled robots. The three kinds that were considered were DC motors, stepper motors, and servo motors. DC motors were very simple, inexpensive, small and powerful. Also their speed could be controlled easily by varying the source voltage. However, their torque was not strong enough to move the robot with heavy loads. Thus, gear-train reductions were needed to reduce the speed and increase the torque output of the motor. Since the Knight gear would follow the user carrying at most 50lb of loads, it required large torque with moderate speed about 3 ft./sec. The DC motors were available in brushed, brushless, stepper, and servo. There were several key differences between the different technologies.

5.6.1.1 Brushed DC motor Brushed DC motors depended on a mechanical system to transfer current, while brushless dc motor used an electronic mechanism to control current. The brushed motors had a wound armature attached to the center with a permanent magnet bonded to a steel ring surrounding the rotor. As the brushes come into contact with the rotary electrical switch, the current passes through to the armature coils. The common brushed dc motors that used for robotics have the RPM range from 5000 to 10000 which was very high rotation speed compare to others. One of the advantages of the brushed motor was that it was very easy to control and motor controller was not necessary when the robot just needs a constant speed. All we had to do was just vary the supply voltages to the motor to control its speed. Also, brushed DC motors were very inexpensive compare to other motors. However, the brushes inside the motors can be wear out very quickly and require

Page 60: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

49

replacement and, also the commutator itself was subject to wear and maintenance was highly needed. Noise problem was another drawback of the brushed DC motor, at the higher speeds, brushes inside the motor have increased difficulty in maintaining contact and causes imperfect electric contact and the noise. For the Knight Gear, there are four motors will be installed, thus the noise produced by each motors will be very noisy and unpleasant for its user.

5.6.1.2 Brushless DC motor Unlike the brushed motor, brushless DC motors uses an electronic mechanism to control the current. They used a magnet, driving coils and sensors that sense the position of the rotor to rotate the motor. In brushless DC motor, there is no contact inside the motor due to absence of brushes. Thus, compared to the brushed DC motor, less maintenance is required and less noise was generated. Also, speed range was much higher than the brushed motor because there were no mechanical limitation imposed by brushes and commutator. Moreover, the heat dissipation was not high because its internal rotor construction was different and more efficient compare to the brushed motor. However, the motor controller was required in order to control the brushless motor. Since there was no physical contact inside the motor, it was hard to know when and where the current should be applied. Therefore it was indispensable to get a separate electronic motor controller if the brushless motor was used in Knight Gear. This requirement poses much higher cost for the brushless motor. Although brushless DC motor had higher price and require complex controls, compare to the brushed motor, brushless DC motors are very widely used in robotics because they have longer life, higher efficiency, less maintenance, low electrical noise generation and other good characteristics

5.6.1.3 Geared DC motor

Since the torque generated by a brushed or brushless DC motor was too small and the speed was too needlessly high, gear reductions are usually used to reduce speed and increase torque. If we choose either brushed or brushless motor for the Knight Gear, it would be better to buy the product which already has the gear reduction system. Geared DC motor was a bigger, more powerful version of DC motor that gear reducer was integrated. The geared DC motors were very often used in robotics and other control situations where a small motor with lots of power was needed. The speed was generally controlled using pulse width modulation of the fixed input voltage. Like other DC motors, geared DC motor can operate in both

Page 61: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

50

clockwise and counter clockwise and its speed can be altered by varying the voltage applied to the motor. Input voltages range of the motor used for robotics range from 3-30V. However, if we bought the new geared dc motors, it was very expensive compare to the motors without gear train, and if we bought the old one, the gear train might get noisy and the gears could go bad. Although geared dc motors were quite expensive, it would be the only choice if we bought the brushed or brushless DC motor for the Knight Gear unless we manually built the gearing system by ourselves. Figure 28 depicts image of motor that will be used to drive Knight Gear

Figure 28 – This is the Geared DC Motor that will be used in Knight Gear.

5.6.1.4 Stepper motor

Stepper motor was another type of motor that could be used for Knight Gear. Unlike other DC motors discussed above, the stepper motor doesn’t rotate continuously. That is to say, it only terns in small steps and in order to make it spin like other motors, we had to give power to the different parts of the motor in a specific sequence. Thus it was more complex to control the stepper motor than the regular DC motors.

Some advantages of stepper motors were that they don’t require the gear reduction to control its speed and torque, and provide precise control of the position.

Page 62: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

51

However, since the motor doesn’t rotate continuously, they have poor performance on the uneven surfaces. Also, the stepper motors consume very higher current compare to other motors especially when they spin continuously. Moreover their complexity in controlling requires special driving circuit to provide the stepping rotation.

Although the stepping motors provide the shaft to rotate in the precise manner, their high consumption of current and unstable mobility on the various loads and complexity in controlling make our group to keep aloof from buying this motor for the Knight Gear.

5.6.1.5 Servo motor Similar to the stepper motor, original form of the servo motor does not spin continuously. That is to say, the original form of servo motors is used to move a shaft to a certain position between 180 to 270 degrees. Therefore they were originally used for controlling of the robot’s arms, plane’s wing and others where the precise angle is needed. . However, they could be modified for 360 degree rotation by changing their internal electronics. By doing this modification, the servo motor lost its position control function but gain the speed control function. Advantages of the motors were that they were available in various sizes and come with standard mounting holes that made us easy to mount on the Knight Gear. And after the modification, servo motors need only one output pin for interface, and don’t need an external motor controller The drawback of the motor was that they need to be modified in order to function as spin motor which could be a risky work to do. Also, since they are originally designed for the position control motor, torque and speed was relatively low compare to other DC motors. Thus servo motor with higher toque and speed was very pricy. Although the servo motors can be controlled directly from the microcontroller and easy to mount for the Knight Gear, their price is high and required modification accompanies some risks. In conclusion, DC geared motor was used for the four wheels of the Knight Gear. DC geared motor had higher torque operating under the low current, which can save the energy, and it is originally design as the continuous motor thus no modification is needed. Also, its price was relatively low compare to other stepper or servo motor. The spur type of gearing will be used because it is most common gear type that used widely in the robotics and their price is relatively low. The 6V DC spur gear motor would be used and its price is range from 12 dollars to 17 dollars.

5.6.2 Motor Controller

In order to control the motors in the Knight Gear, selection of the right motor controller was very crucial part for the project. Although the microcontroller can

Page 63: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

52

decide the speed and direction of the motors, they cannot be connected directly to the motors. Most of microcontrollers had some input and output pins that can be set to high (5v) to low (0V) under the software coding. However since their pins were only capable of supplying a very few mA of currents and the motors generally required much more current and voltage to operate, input and output pins of microcontroller cannot be used for controlling the motor. On the other hand, the motor controllers were designed to provide the enough current and voltage to the motor but they cannot decide how fast the motor should spin. Therefore motor controller and microcontroller needed to work together to make the motors to move properly. Some of the criteria of the motor controller that were needed to be considered for our project are that it must be rated for voltage of our battery pack and it also must be able to handle the motor’s stall current. Moreover, communication method between microcontroller and motor controller should be met. For Knight Gear, PWM would be used for the communication between the microcontroller and the motor controller. There were two different methods that can be used to build a motor controller for Knight Gear. First, we could build our own motor controller by using a small motor driver integrated circuit. One of the advantages of these circuits was that their price would be very low. Their price would range from as little as 1 dollar to 5 dollars. Thus even if there were some mistake building the controller and this chip was burned, it would not be a big loss for us buying just a new chip. Also, it was not very hard to get more current or heat dissipation out from the chip. If we had bought the motor that require more current needed than a single IC can provide we could just connect the IC chips in parallel to get more allowable current and heat dissipation. Only drawback of this circuit was that they are mostly used to handle two motors. Since the Knight Gear has four motors and each motor need to be controlled independently, at least two motor driver Ics will be needed for our project. Second, we can simply buy a finished motor controller product that was available in the market. One of the advantages of the finished motor controller products was that they already have a motor driver and some certain logics integrated in the circuit. Therefore the motor controller was widely used for the beginners who just wanted a plug and play to control their motors. Another advantage of the motor controller was that they provide some useful features for the users. Many of the motor controllers have H-bridge circuit that could be used to control the direction of each motor, and have on-board current and voltage monitoring system that prevented the over current problems. Moreover, some motor controller have built in charging system that they can charge the Li-MH or Li-CD battery using their on board current regulator. However, most of the motor controllers were way too expensive compare to the

Page 64: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

53

driver Ics. Their price ranged from thirty dollars to as much as few hundred dollars. This was a very big drawback because if this controller get damaged or failed during the trial, we would not have a choice but to buy the new expensive product again. There were four different driver Ics and motor controllers that were very capable for our project. At first, we had researched for four different products of both drivers IC and motor controller. However, since the price of finished motor controller product was way too expensive for our low budget project, the three different motor driver Ics were discussed only, and then we will compare those three to select the best product for our project.

5.6.2.1 Texas Instruments Model L293D The Texas Instruments model L293D was a very popular motor driver IC that was widely used for controlling DC and bipolar stepper motors. This motor driver IC can either control two DC motors with individual directional and speed control, or four DC motors with just on and off. This model can support pulse width modulation control and had ability to handle a wide range of operating supply voltages from 4.5V to 36V and enough output current of 600mA for each channel. Also this model included output diodes that no extra diodes were needed. Moreover, this model had standard pin packages for schematic design that made it easy to implement the circuit. Other features that were provided in this model included thermal shutdown, internal electrostatic discharge protection, and high-noise-immunity inputs. According to mouser electronics website, price of this model is $3.12 each. The schematic of L293D is shown below in figure 29.

Figure 29 – Texas Instrument model L293D Reprinted with permission

Page 65: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

54

5.6.2.2 Texas Instruments Model SN754410 The Texas Instruments model SN754410 was another widely used motor driver IC that function very similar to the L293D model stated above. This motor driver IC could either control two DC motors with individual directional and speed control, or four DC motors with just on and off. This model also has the ability to handle a wide range of operating voltages from 4.5V to 36V. This model can support pulse width modulation control as well. The SN754410 also has the protection diodes for running inductive loads as well but can provide more continuous current up to 1.1A. Although the model L293D has sufficient continuous current output of 600mA for the motor that we are already choose, model SN754410 could be used as replacement if we decide to use more powerful motors for the Knight Gear. According to mouser electronics website, price of this model was $1.87 each which was somewhat cheaper than the L293D model. As the diagram shows below, pin-outs of the SN754410 are exactly same as the pin-outs of the L293D model. Thus this model was a direct plug in replacement of L293D model and the block diagram for the motor connection and state table is same as well.

5.6.2.3 Texas Instruments Model DRV8833 Another motor driver IC that we considered was Texas Instruments model DRV8833, which can be seen in the figure on next page. This model has dual H-bridge and was designed for driving two DC motors or one stepper motor. Each of the H-bridge includes circuitry to regulate or limit the winding current. Compare to other models stated above, this model has the ability to handle small range of operating voltage that from 2.7V to 10.8V and provided less continuous current up to 500mA. This model can also support pulse width modulation control that would be used for the speed control. The DRV8833 also has the protection diodes for running inductive loads as well so no external diodes are needed. Other features that are provided in this model include under-voltage lockout and protection against over-current and over-temperature, reverse-voltage protection circuit and current limiting system if sense resistors are added. According to mouser electronics website, price of this model was $2.58 each. The functional block diagram of DRV8833 is shown on next page in figure 30.

Page 66: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

55

Figure 30 – Texas Instrument Model DRV8833 Reprinted with permission

5.6.3 Motor controller comparison and selection As discussed above, there were three different types of motor driver Ics that were considered as candidates for the motor controller of Knight Gear. The characteristics of those Ics are tabulated below in table 6 for us to make the best selection of the motor controller.

Page 67: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

56

Model L293D SN754410 DRV8833

Brand Texas Instrument/ Stmicroelectrics

Texas Instrument

Texas Instrument

Operating supply voltages

4.5V ~ 36V 4.5V ~ 36V 2.7V ~ 10.8V

Tolerant peak output currents

1.2A 2A 1A

Continuous currents per each channel

600mA 1.1A 500mA

H-Bridges Quadruple-Half Quadruple-Half

Dual

Control method PWM PWM I2C / PWM

Internal diodes YES YES YES

Price (from mouser electronic website)

$3.12 *2 $1.87 *2 $2.58 *2

Table 6 – Motor Ics comparison In conclusion, Texas Instrument model SN754410 would be used as motor controller for the Knight Gear. This model provided sufficient continuous current of 1.1A with lowest price thus this model seems very cost effective. Also, this model had standard pin packages for schematic design and no extra diodes were needed that made it easy to implement the circuit. The picture of SN754410 that is to be used for Knight Gear is displayed on the next page in figure 31.

Page 68: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

57

Figure 31 – This is SN754410 motor driver that will be used in Knight Gear.

There were two different ways to use the SN754410 motor driver to control each motor.

4) 3 pin mode, or 5) 2 pin mode

Each had its advantages and disadvantages.

3 Pin mode

This requires one hardware PWM pin plus two general-purpose digital output pins per motor. The following diagram, in figure 32, shows how to make this 3 pin mode for SN754410.

Page 69: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

58

Figure 32 – This is the schematic of 3pin SN754410 Permission Pending

The benefit of this mode was that it could support all the possible motor drive states such as forward, reverse, brake and coast. Variable speed was achieved by changing the PWM signal from the microcontroller. The following table 7 shows the truth table of motor function using the 3 pin mode.

PWM (1,2 EN and 3,4 EN)

Digital output pin

(1A or 3A)

Digital output pin

(2A or 4A)

Motor state

0 - - Coast

1 0 0 Break

1 1 1 Break

1 1 0 Forward

1 0 1 Reverse

Table 7 - Truth table of 3 pin SN754410 motor controller

2 pin mode

This required one hardware PWM pin plus one general-purpose digital output pin. The following diagram shows how to make this 2 pin mode for SN754410 in figure 33.

Page 70: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

59

Figure 33 – This is the schematic of 2pin mode for SN754410 Permission Pending

The drawback of this mode was that it did not support the ‘coast’ motor drive state. Consequently to achieve variable speed settings the motor alternates between full speed and brake via the PWM pin. Although it only used two output pins of microcontroller, it caused the motor under some stress and would wear out the motor more quickly than the 3 Pin-mode. The following table 8 shows the truth table of motor function using the 2 pin mode

PWM (1A or 3A)

Digital output pin

(2A or 4A)

Motor state

0 0 Break

0 1 Reverse

1 0 Forward

1 1 Break

Table 8 - Truth table of 2 pin SN754410 motor controller

Although the 2 pin mode required only two output pin of microcontroller, it would put some stress and wear out the motor fast. Thus, if our microcontroller had available output pins, 3 pin mode would be used for the motor controller of the Knight Gear.

Page 71: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

60

5.7 Camera or Vision System

The vision system was not a requirement of the Knight Gear. However, it was a remarkable accessory to have in the system. The video system would have been used to view the surroundings of the Knight Gear and comfortably follow its user. The vision system was not as critical as some of the other sensors like infrared, like ultrasonic, or radio frequency antennas. This was because the vision system by itself was an independent system. It neither depended on other system nor should it affect the capabilities of sensors, driving, and steering of Knight Gear. The purpose of camera system was to provide vision to Knight Gear. In order to implement the camera system, it had to meet the following specifications:

It must not weigh any more than 500 grams.

It must have a range of approximately 100 meters.

The operational current should not be any more than 500mA

A lot of research had been performed to execute this system. There were several ways though which such camera system could have been implemented. Few of these methods were:

Through an image sensor,

Through a webcam or camcorder, or

Through a prepackaged in-built video system. The image sensor was probably the hardest of the lot to implement. In this technique, everything was built around the image sensor through some extensive coding. In order to receive data, a transceiver was needed that has data rate and bandwidth to send the information or data wirelessly. In addition, the system needed a lot of power to compress and format the video, and send it to the transceiver. A minimum resolution of 640 x 480 was required by the image sensor to appropriately interpret the data. Such type of video system that used image sensor had the potential to be least expensive but at the price of time. Building such a system was very time consuming. The image sensor comparison is shown on next page in table 9.

Page 72: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

61

Image Sensors Resolution Image Senor

Size Frame Rate

MT9V024IA7XTC WVGA 1/3 inch 60 fps

MT9V024IA7XTR WVGA 1/3 inch 60 fps

MT9V032C12STC WVGA 1/3 inch 60 fps

MT9V032D00STC WVGA 1/3 inch 60 fps

MT9V034C12STC WVGA 1/3 inch 60 fps

MT9V034C12STM WVGA 1/3 inch 60 fps

Table 9 – Image Sensor comparison

Second method was to get the video from a webcam and construct the remainder of the system around it. This method lessened the work load that the first method, however this system was still quite challenging to build. A processing unit is still needed to compress, convert, format and send the video information wirelessly to a display unit. The issue with this type of technique was finding such processing unit that can use the raw video data and possibly convert it to a format and send it to the transceiver that was compatible to Knight Gear. Such type of video system was costlier than the first method but again, to build a video system using this method would require excessive time in hand.

The last method was to buy a prepackaged in-built video system for Knight Gear. This was the costliest of the all the methods discussed but was not time consuming. Such a video system incorporated a video camera, video transmitter and a video receiver, and was rather easy to implement. All it would take was simply mounting the package on the front of Knight Gear. This would have allowed Knight Gear to see the surroundings. Table 10, lists the two prepackaged system that were looked into.

Prepackaged System

Range Weight Price

24ghzmiwicoc 150 m 9 g $39.99

SFA-010256 100 m 1.3 kg $64.99

Table 10 – Prepackaged in-built video system comparison.

Unfortunately due to time constraints and having spent so much money on other necessary features, we decided not to go for vision system. Its absence does not hurt Knight Gear

Page 73: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

62

5.8 Sensors

5.8.1 Types of Sensors

Knight Gear utilizes multiple sensors to accomplish tracking and localization of the user and obstacles. The weight sensor is also used as a safety measure to verify that the load on Knight Gear is low enough to not burn out the motors equipped to it. The ultrasonic sensors were used to find the user and track the user along.

5.8.1.1 Ultrasonic Proximity Sensor

Piezoelectric transducer is used to determine sound waves in ultrasonic proximity sensors. It engenders high frequency sound waves (above 20,000 Hz), which is incorporated in these sensors, to measure the echo encountered by the detector, and is then received after reflecting back from the target. Ultrasonic sensor played an indispensable role in Knight Gear. Some of the key advantages of ultrasonic sensors were as follows:

No physical contact was needed with the object that was to be detected. Thus, the target for the sensor would be attached to the back of the belt or hook of the user. The sound waves would exude from the emitter to follow and find the target, and returns back to the detector. Having a wide range was essential for the sensor because the user would be in motion.

Since there was no mechanical contact with the target, the numbers of operating cycles were unlimited.

Ultrasonic proximity sensors would work regardless of the target’s color, atmospheric dust, rain, snow, reflecting and metallic surfaces or any repugnant conditions.

It provided resistance to external disturbances such as vibration, noise, and infrared lights.

Having said some of the vital benefits of ultrasonic proximity sensor to Knight Gear, these were not ideal. There were limitations to accuracy when dealing with target that was not perpendicular in respect to the sensor. Another major issue of ultrasonic proximity sensor was when sound waves reflected off the walls in strange pattern creating ghost echo. Noise issues were also to be taken into account while using multiple sensors.

Numerous types of ultrasonic proximity sensors were taken into account when it comes to selecting the best for knight gear. These were LV-MaxSonar EZ series, XL-MaxSonar EZ/AE/WR series, HRLV-MaxSonar EZ series, and HRXL-MaxSonar WR/WRC series from MaxBotix. All the ultrasonic sensors that were looked up during the research in order to pick the best fit for Knight Gear are listed in table 10 with its specifications. From all these possible choices, LV-MaxSonar-EZ (EZ0-EZ4) fulfills the general need of distance sensor of Knight Gear. According to MaxBotix website LV-MaxSonar EZ are “low cost ultrasonic

Page 74: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

63

distance sensors to provide a component module solution that offered easy to use outputs, no sensor dead zone, calibrated beam patterns, stable range readings, low power demands, and a host of other feature”.

Now, within the LV-MaxSonar EZ (EZ0-EZ4) series, the beam width gets narrower and sensitivity get lower as progressed from EZ0 to EZ4. LV-MaxSonar EZ0 provides most of the same characteristics as EZ1, EZ2, EZ3, and EZ4 except that it has widest beam width and most sensitive beam pattern of all. Wider the beam width, the better it was for people detection. However, this also resulted in more noise and ghost echoes. Detection angle and detection pattern is crucial while deciding which type of sensor to use. Figure 34 and Figure 36 provides a good illustration of the detection pattern of EZ0-EZ4 and detection angle of EZ1 respectively. Figure 35 shows the PCB layout of EZ series. A graphic representation of detection angle of EZ2 was not available, but from the model of EZ1 an idea of beam pattern can be attained. Table 11 below lists all the ultrasonic products that were looked into.

Products Resolutio

n Reading Rate

Maximum Range

Required

Voltage

Required

Current

Operational Temperatur

e Price

XL-MaxSon

ar-EZ 1cm 10Hz

300in-420in

3.5V-5.5V

3.4mA 0C – 65C $27.95

XL-MaxSonar-AE

1 cm 10Hz 300in-420in

3.5V-5.5V

3.4mA - 40C – 70C $29.95

LV-MaxSon

ar-EZ 1 cm 20Hz 254in

2.5V-5.5V

2.0mA - $21.95

.

HRLV MaxSon

ar-EZ 1 mm 10Hz 195in

2.5V-5.5V

3.1mA 0C – 65C $28.95

HRXL MaxSonar-WR

1 mm 6Hz-7.5Hz

196in-393in

2.7V-5.5V

3.1mA -40C – 65C $97.95

Table 11 – Ultrasonic Proximity Sensor Comparison

Page 75: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

64

Figure 34 – LV-MaxSonar-EZ beam Pattern Reprinted with permission

Page 76: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

65

Figure 35 – PCB Layout of MaxSonar EZ2 Permission Pending

Figure 36 – Sensing Object within Infrared Proximity’s Detection Range Reprinted with permission

Page 77: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

66

EZ2 is steadiest of all EZ models. It neither has the widest nor the narrowest beam width. It has a resolution of 1 inch, uses frequency of 42 kHz to measure distance, virtually no dead sensor dead zone, and has maximum range of 254 inches (6.45 m). It reads from all 3 sensor outputs: analog voltage, serial and pulse width. It functions on 2mA current and voltage between 2.5-5.5V. EZ2 is a very good fit for the given specifications. Thus, from these specifications, and Figure 28 and 30, LV-MaxSonar EZ2 seems the most plausible choice for Knight Gear. The cost of EZ2 is also very reasonable with $27.95 when compared to EZ0, EZ1, EZ3 and EZ4 being $27.95, $25.95, $27.95, $27.95 respectively.

However as we went along with the project, we realized that these sensors were from Maxbotix, and all the sensors from maxbotix had one built in speaker for emitter and detector. We came to realization that we needed two different speakers (one for emitter and one for detector) for Knight Gear. This is due to the fact that we used three ultrasonic sensors, one on the user and two on the robot. The one ultrasonic sensor on the user was only supposed to transmit sound waves to the robot; hence we had to cover the receiver. The two ultrasonic sensors on the robot were only supposed to receive the sound waves, so we had to cover the transmitter. And, this was only possible using Parallax Ping))) 28015 Sensor. It provided maximum range of 118 inches at required voltage and current of 5V and 30mA respectively at a cost of $29.99

5.8.1.2 Infrared Proximity Sensor

Infrared proximity sensors sent out beams of infrared light and then analyze the returning light. The photo-detector inside the sensor detects any incoming reflection of this light. These reflections allow the sensor to determine the location of the object. Infrared proximity sensor works as a triangulation as demonstrated in Figure 37. In Knight Gear, infrared light will be emitted from this sensor which will be reflected back by the person/object to the proximity sensor. The sensor will evaluate the time taken and returning angle with modulation to assay the distance. Figure 38 on the next page portrays the building blocks of infrared sensor.

Page 78: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

67

Figure 37 – How infrared proximity sensor detects object Permission Pending

Figure 38 – Building blocks of infrared proximity sensor

Page 79: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

68

Infrared sensors were relatively cheaper but were not as powerful as ultrasonic sensors. They offered short range and are not as effective outdoors as they were indoors. Bright light from the sun will affected the accuracy of infrared proximity sensor. The modulation technique provided the best chance for outdoor use however, there was an anomaly expected from the various light reflecting capabilities of surfaces in the surroundings. The list of infrared sensors that were looked up for choosing a good fit for Knight Gear are listed in table 12.

Products Voltage

Operational Range

Distance Price

GP2Y0A02YK0F 2.7V – 6.2V 150cm $14.95

GP3Y0A21YK 2.7V – 5.5V 10cm-80cm $13.95

GP2D12 4.5V – 5.5V 10cm-80cm $9.95

Pololu 2.7V – 5.5V 60cm $5.95

Table 12- Infrared proximity sensor comparison

The infrared proximity sensor that was being considered was Sharp’s GP2YOAO2YKOF for Knight Gear. Sharp’s “GP2YOAO2YKOF has an analog output that varies from 2.8V at 15cm to 0.4V at 150 cm”. It required a supply voltage of 4.5-5.5V in DC. This sensor worked best when sensing objects up to 5 feet. This should be fairly filling to the general requirements of Knight Gear because even an ideal and best proximity sensor will struggle to confront the light reflecting surfaces from the surroundings. Sharp’s “GP2YOAO2YKOF long range costs only $14.95 when compared to Sharp’s GP3Y0A21YK which provides short range of 80 cm (2.6 ft.) and costs $13.95.

Infrared Proximity Sensor was supposed to be a backup sensor to ultrasonic sensors. These were not ideal to use in outdoor conditions. And, because Knight Gear worked just fine using only the ultrasonic sensors in terms of sensing the user, infrared proximity sensor was not used.

5.8.1.3 Weight Sensor

A weight sensor also needed to be implemented to fulfill the needs of this project. Knight Gear worked only and only when the weight of the backpack is less than or equal to 30lbs. It would not work and would give an error signal if the weight happened to be more than 30lbs. The weight sensor worked as a Wheatstone

Page 80: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

69

Bridge Network, where 4 strain gauges are connected with 4 separate resistors. When a force or load is applied, resistance changes and results in change in output (The voltage is zero at equilibrium with no load/force). This small change in output voltage is measured and augmented carefully from low amplitude to high amplitude and then examine to calculate the weight of the load and displayed on a LCD screen to the user.

SEN-10245 load cell, shown in figure 39, will be used for the execution of weight sensor. Figure 40 shows the actual sensor that is bought from sparkfun. This sensor costs $9.95 and is not complicated to implement.

Figure 39 – Schematics of Load Cell SEN10245

After we bought the weight sensor, we tried our best to get it work, but we failed. The weight sensor needed an amplifier to boost the signal to be seen in oscilloscope. Regardless of the weight we put on the sensor, it showed no change in the output voltage. Hence, we decided not to implement the weight sensor on the Knight Gear.

Page 81: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

70

Figure 40 - This is SEN10245 load cell that will be used to check the weight of the load on Knight Gear.

5.8.1.4 Accelerometer

An accelerometer was supposedly to be use in the system to detect velocity, position, shock, vibration or acceleration of gravity. It would have played a major role in evaluating the localization and positioning of Knight Gear by evaluating the inertial measurement of velocity and position. Accelerometer could measure acceleration in one, two or three orthogonal axis. 2-axis accelerometer is sufficient enough for the purpose of Knight Gear and costs more than 3-axis accelerometer which provides more accurate data of x, y and z axis of Knight Gear without supplementing extra weight. Accelerometers that were looked into are listed in table. These devices and possible were looked into during the research and implementation of Knight Gear are listed below in table 13.

Page 82: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

71

Products Range Interface Axes Voltage

Requirements Current

Requirements Price

ADXL 193 ±

250g Analog 1 3.5 – 6 V 1.5 – 2 mA $29.95

ADXL335 ±3g Analog 3 1.8 – 3.6 V 350µA $24.95

BMA180

±1, 1.5, 2, 3, 4,

8, 16g

SPI and I2C

3 2 – 3.6 V 650 - 975µA

This product

is retired.

LIS331 ±6, 12, 24g

SPI and I2C

3 2.16 – 3.6 V 250µA $27.95

MMA7361 ±1.5, 6g

Analog 3 2.2 – 6V 400-600µA $11.95

MMA8452Q ±2, 4,

8g I2C 3 1.95 – 3.6 V 165µA $9.95

MMA7341L ±3, 11g

Analog 3 2.2 – 3.6 V - $9.95

Table 13 – Accelerometer comparison

Triple axis accelerometer – ADXL335, fits the best need of Knight Gear. It costs $24.95 from sparkfun when compared to double axis accelerometer – 202JE costs $20.88 from Digikey. ADXL-335 provided very low noise and uses very low power to offer sensing range of ± 3g. This sensing range of ± 3g was very accurate in a limited range and should have maximized the sensitivity without losing any of Knight Gear’s functionalities. According to ADXL-335 data sheet from sparkfun, the ADXL-335 has radiometric output; hence “the output sensitivity varies proportionally to the supply voltage. At Vs = 3.6V, the output sensitivity was typically 360m V/g. At Vs = 2V, the output sensitivity was typically 195 m V/g.” The innovative design technique of ADXL-335 ensured very high performance and has compensated for adverse temperatures The bandwidth of ADXL-335 ranged from 0.5Hz to 1600Hz for X and Y axis and 0.5Hz to 550Hz for Z axis. It was small and low profile chip with dimensions of 4 mm x 4 mm x 1.45

Page 83: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

72

mm and weighs only 2 grams, which made it suitable for Knight Gear. The schematic of ADXL 335 is shown below in figure 41; and figure 42 shows the actual sensor that is bought from sparkfun.

However, we the accelerometer did not come in handy. Knight Gear performed all the required functions without any extra need of the accelerometer. Hence, we decided to lie back when it came to accelerometer and save some money.

Figure 41 - ADXL335 PCB layout Permission Pending

Figure 42 - This is ADXL-335 accelerometer that will be used to calculate distance, position and velocity of Knight Gear.

Page 84: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

73

5.8.1.5 Gyroscope

Unfortunately, accelerometers were affected by gravity and it may not have offered precise and accurate readings of Knight Gear’s orientation, therefore gyroscope was taken into consideration to enhance the performance of Knight Gear. Unlike accelerometer, gyroscope is not affected by gravity and has the upper hand when it comes to determining the orientation of an object in motion. Historically, gyroscopes were used for “space navigation, missile control, under-water guidance, and flight guidance. Now they are starting to be used alongside accelerometers for applications like motion-capture and vehicle navigation” according to sparkfun webpage on Accelerometer, Gyro and IMU Buying Guide.

In addition to gravity, vibration also affects the orientation and localization of accelerometer. As a result, dual axis gyroscope will be implemented in the Knight Gear to measure the rotation of X and Y axis and to compensate on accelerometer’s functionality. IDG-500 Integrated dual axis gyroscope is being used for Knight Gear. It is the world’s smallest dual axis gyro sensor with highest dynamic range to measure fast action motion. The features of IDG-500 involve two separate outputs per axis: 500 degrees/s full range for high speed and 110 degrees/s full range for high precision. Its low pass filter integration with auto zero function and a temperature sensor makes it ideal. This gyroscope has high vibration rejection over a wide range of frequency with 10,000 g of shock tolerance. Some more gyroscope products that may be suitable for Knight Gear have been listed below in table 14.

Products

Range Interface Axes Voltage

Requirements

Current Requiremen

ts Price

LPY503AL

±30/s, or ±120/s

Analog 2

(x/z) 2.7 – 3.6 V 6.8mA $29.95

L3G4200D

±250/s, ±500/s,

or ±2000/s

SPI and I2C

3 2.4 – 3.6 V 6.1mA $49.95

ITG 3200 ±2000/s I2C 3 2.1 – 3.6 V 6.5mA $49.95

LPR5150AL

±1500/s I2C 2 2.7 – 3.6 V - $29.95

IDG500 ±500/s Analog 2 2.7 – 3.3 V - $39.95

Table 14 – Gyroscope Comparison

Page 85: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

74

IDG-500, schematics shown in figure 43, demanded a supply voltage of 2.7V-3.3V and its output is independent of the supply voltage. It provides lowest cross axis sensitivity to accomplish the best signal accuracy and costs only $39.95 from Component distributors which fulfills more than the operational requirement of Knight Gear.

But just like accelerometer, we decided not to use gyroscope. Implementing gyroscope in Knight Gear can incorporate some heavy programming; and because Knight Gear is able to perform to its full potential without gyroscope, it didn’t felt the need of this sensor.

Figure 43 – PCB layout of IDG500 Permission Pending

5.9 Wireless Communication

In order for Knight Gear to follow a user, the group decided for a wireless communication between the robot and the transceiver. This communication could was with a multitude of different antennas and wireless communication devices. The purpose of the implementation of wireless communication in Knight Gear was for localization of the user which is the main feature of Knight Gear and its top priority. Some wireless communications looked at were Wi-Fi, Bluetooth, and ZigBee.

5.9.1 Wi-Fi

Wi-Fi allows for LANs to be deployed without wires for different clients. Wi-Fi use Point to hub communication, and has an operating frequency of 2.4 and 5 GHz. This method was the first one looked at when designing Knight Gear’s wireless communication. Wi-Fi is very common in most laptops and wireless devices, and uses 802.11b or 802.11g with a range of 50-100 meters. A down side to using Wi-Fi was the complexity and knowledge needed to be able to operate them. But

Page 86: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

75

a positive of Wi-Fi was the range of 50-100 meters, which was very large compared to the other 2 choices.

5.9.2 Bluetooth

Another viable option for wireless communication was Bluetooth. Bluetooth was designed for low power consumption and short range devices. Bluetooth uses radio technology to send data in chunks on different frequencies at 2.4 GHz. Bluetooth has a range of 10-100 meters and was another great choice for Knight Gear’s communication.

5.9.3 ZigBee

Lastly, ZigBee was the final choice for wireless communication in Knight Gear. ZigBee was a low cost, low power, wireless mesh network. Devices using ZigBee operate at a radio frequency of 2.4GHz and were usually very simple devices. The communication is based on peer to peer connections and required very little knowledge to use because of lack of complexity.

The table 16 below shows comparison on the three different wireless communication methods and different specifications.

ZigBee Wi-Fi Bluetooth

Range 10-100 meters 50-100 meters 10-100 meters

Operating Frequency

2.4 GHz 2.4 and 5 GHz 2.4 GHz

Complexity Low High High

Power Consumption

Low High Medium

Table 15 - Wireless communication methods

Based on these specifications, the group decided on going with ZigBee as the wireless communication of Knight Gear’s user following protocol.

5.9.3.1 XBee

When looking for wireless antennas for Knight Gear that used ZigBee, the name that repeatedly showed up was XBee by Digi. The XBee antennas are very popular with hobbyist around the world and were very low cost and easy to program and use. Even with the large amount of documentation and examples of the XBees being used, there are many different XBee models and different series of XBees to examine and decide which is best for Knight Gear. To start off,

Page 87: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

76

ZigBee and XBee were different things. ZigBee was the protocol while XBee was the wireless communication device. For Knight Gear, the group mainly focused on two versions of the XBees: Series 1 and Series 2.

The first is Series 1, also known as XBee 802.15.4. This model of XBees was the easiest to work with as in they require no preparation or configuration to use. They can benefit from configuration, but they do not need it. Only downside to these was that they are not compatible to XBee series 2 or above.

XBee ZB was the current version of the Series 2 of the XBee. These XBees can run in a transparent mode or work with API commands. The XBee 2B were even newer versions of the Series 2 which improve power usage. Although these two XBees were different versions of Series 2, they could work with one another unlike a Series 1 working with a Series 2.

The following table 17 shows a comparison of a Series 1 antenna with a Series 2 antenna.

XBee Series 1 XBee Series 2

Range 300 ft. 400 ft.

Power Consumption 50mA @ 3.3v 40mA @ 3.3v

Frequency 2.4 GHz 2.4GHz

Data Rate 250 kps 250 kps

Cost $22.95 $20.95

Table 16 – Xbee Series comparison

Based on the previous table showing comparisons on the Series 1 or Series 2, Knight Gear was chosen to have a Series 2 XBee RF antenna. The main reason for this choice was to alleviate the budget for the group and availability of components from SparkFun.

For Knight Gear, we will focus on serial communication using the XBee Series 2 antennas which will focus on mainly the pins 2 and 3, shown in the figure 44.

Page 88: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

77

Figure 44 – Xbee Series 2 Chip

Permission Pending

In order to trigger the PING ultrasound sensor with the XBee Series 2, we needed to invert a serial signal from low to high using an inverter. In order to make a low cost inverter, we decided to use a PNP inverter. Using the serial out on the XBee and inverting it as shown below in the figure, we can get a high pulse trigger for the PING sensor. The PNP inverter circuit is shown below in figure 45.

Figure 45 – PNP Inverter Permission pending

Page 89: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

78

5.10 Localization

Knight Gear needed to accurately identify its position at all times regardless if it was situated outdoor or indoor. Determining where Knight Gear was, at a random point of time in extremely necessary because while navigating, it needed to avoid colliding with walls, hitting people and come to sudden stop if someone comes in front of it. There were two ways in which awareness of locality can be achieved. One way was dead reckoning system and other was using external references system. Dead reckoning system would calculate the current location of Knight Gear by using positions, fixes from past states and advances its position based upon estimated speeds, time and distance covered. This was a great technique to find Knight Gear’s position indoor and outdoor without using any external references. However, there was a major flaw with dead reckoning system. If Knight Gear had been in motion or working for a long period of time, then incremental errors accumulate. This resulted in losing localization accuracy. It alone cannot be precise by itself. Therefore, with the help of accelerometers and gyroscopes, dead reckoning system could prove to be more effective than before. This method would have been implemented for indoor. If the user walks into the classroom building, the Global Positioning System (GPS) would not be as effective as dead reckoning system. Hence, it would be mainly used for indoor purpose. The implementation and execution of Knight Gear’s positioning was a very convoluted problem.

5.10.1 Absolute Localization

As the name states, absolute localization located the robot using the coordinate system. In this localization, no approximate estimation was required to initiate the localization process. This technique used sensors to provide information on the surroundings of the robot and the information can be interpreted to determine its position based upon the coordinate landmarks. This method was relatively complex to implement and requires harnessing of the robot environment with beacons. The processing was much faster in absolute localization when compared to relative and offers data with maximum accuracy and precision. However, in absolute localization the environment had to be already set up with beacons to process the triangulation method. The purpose of Knight Gear was to follow the user outdoor and indoor locations regardless if it was a place it had been before or otherwise. Therefore, planting beacons already in the location doesn’t fulfill Knight Gear’s requirements. But, if something goes wrong in relative localization, absolute localization is definitely a back we can go to.

$29.99 MediaTek 3329 from Sparkfun looks like a good fit for Knight Gear. It weighs only 6 grams and provides great sensitivity at -165dBmW. The schematics of MT3329 GPS module is shown below in figure 46.

Page 90: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

79

Figure 46 - EM406 connector for the MT3329 GPS module Permission Pending

5.10.2 Relative Localization

This technique was the same as dead reckoning system. Current position of the robot can be determined incrementally by evaluating displacement, initial positioning, speed the robot is travelling, and direction it was travelling. Sensors like gyroscope, accelerometer, and inertial measurement units help in calculating the relative localization of the robot. This method gives advantage to the position of the root with an elevated frequency. However, this technique incorporates a lot of minute errors that add up. These errors were wheel slippage, uneven floors, and lot of incremental errors that accumulate to give localization with accumulated errors. Local positioning system was chosen instead of a global positioning system because the global positioning system introduces the need for a global observer into the team. Many of the currently available global positioning systems were not accurate enough for Knight Gear. Satellite based GPS was only accurate up to within a couple of meters. Satellite based GPS also works very poorly when indoors or in enclosed areas. Instead, a local positioning system was used to maintain the formation parameters in the robot team. The position of relative localization is shown below in figure 47.

Page 91: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

80

Figure 47 – Relative Localization Permission Pending

From the figure above, the following equations can be concluded:

xK+1 = xK + ΔDK . Cos (k +Δk/2)

yK+1 = yK + ΔDK . Sin (k +Δ

k+1 = k +Δk

In order to localize Knight Gear accurately, it was important to minimize the number of incremental errors. Therefore, several motor schemas, static obstacle, move to goal, and maintain-formation were implemented. These additional algorithms would not affect the overall orientation and configuration of Knight Gear. Furthermore, background schemas and noise form a reactive grease, which deals with some of the problems that was based entirely on navigational methods. Each of these schemas engenders a vector that represents the desired behavioral response which was stimulated by current sensory. Simultaneously, the importance of these individual behaviors was demonstrated by a gain value. Multiplication of the outputs of these individual behaviors by its gain, and then summing and normalizing the results provides a high level combined behavior. The maintain-formation motor schema causes a movement vector towards the desired formation position. The direction of the vector was always towards the desired formation position however, the magnitude relies on how near or far the robot was away from it. Using the distance from desired position, three zones were basically used for magnitude computations. The radii of these zones were the guidelines to maintain formation schema. According to a weekly report on cooperative control project, the magnitude of the vector was calculated as follows:

“Ballistic zone: the magnitude is set at its maximum, which assimilates to the schema's gain value.”

Page 92: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

81

“Controlled zone: the magnitude varied linearly from a maximum at the farthest edge of the zone to zero at the inner edge.”

“Dead zone: in the dead zone vector magnitude is always zero. The role of the dead zone was to minimize the problems associated with position reporting errors and untimely communication.”

To ease the discussion that follows, the following formation terms are introduced:

Rpos, Rdir the robot's present position and heading.

Rmag, the robot's present speed.

Fpos, the robot's proper position in formation.

Fdir, the direction of the formation's movement; towards the next navigational waypoint.

Faxis, the formation's axis, a ray passing through Fpos in the Fdir direction.

Hdesired, desired heading, a computed heading that will move the robot into formation.

heading, the computed heading correction.

speed, the computed speed correction.

Vsteer, steer vote, representing the directional output of the motor behavior, sent to the steering arbiter.

Vspeed, speed of the motor behavior, sent to the speed arbiter. The magnitude of the required speed correction was determined and evaluated by the maintain formation speed behavior, and then it casts its vote by adding the correction to the current speed to minimize the accumulated errors.

Vspeed = Rmag + K speed

In the above equation,

K is a constant that was set before the actual runtime in order to adjust the rate of correction.

speed is the correction calculated by formation speed behavior.

The three zones: ballistic zone, controlled zone, and dead zone determine speed. The sizes of these zones are the parameters of formation behavior.

speed is set negative if Fpos of the robot is negative. speed is positive if Fpos

of the robot is positive.

In a method very similar to the motor schema-based approach the magnitude was computed as follows according to weekly report on cooperative control project:

Ballistic zone: 1.0

“Controlled zone: the magnitude varies linearly from a maximum of 1.0 at the farthest edge of the zone.”

“Dead zone: in the dead zone the magnitude is always zero.”

Page 93: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

82

The maintain-formation-steer behavior followed similar sequence of steps to evaluate an egocentric steering direction, the angle for the front wheels with respect to the vehicle body. The magnitude of correction was necessary to calculate using this behavior. The magnitude of correction was determined based on how far laterally the robot was from its formation position. The maximum correction was for the robot to head directly towards the formation axis, the minimum was for the robot to head directly along the formation axis. The magnitude of heading computed by the formation heading behavior was determined as follows

Ballistic zone: 90, i.e. head directly towards the axis.

Controlled zone: the turn varies linearly from a maximum of 90 at the

farthest edge of the zone to 0 at the inner edge.

Dead zone: 0, i.e. head parallel to the axis.

The sign convention of the correction was set according whether the robot is left or right of the formation axis. The sign was positive if the robot was on the left side of the axis and is calling for a right turn. The sign was negative if the robot was on the right side of the axis and is calling for a left turn. Hdesired can now be determined with reference to the formation axis:

Hdesired = Fdir - heading

The heading will bring it to formation axis and align it properly when Knight Gear continues moving. On the other hand, if the formation had stopped moving then, Hdesired was instead set to take the robot directly to its position:

Hdesired = Fpos - Rpos

Ultimately, Hdesired is translated into an egocentric angle for Knight Gear’s front wheels:

Vsteer = Hdesired - Rdir

The positive angle designates a right turn and negative angle designates a left

turn. If the result of the angle was either greater than 180 or less than -180,

360 was added or subtracted to ensure the result is within bounds. Finally the angle was clipped to the physical limits of the vehicle.

Knight Gear’s positioning can be seen as determining the relative distance between the user and Knight Gear. Considering the range in which Knight Gear will be active and the accuracy needed, another method can be used for the localization. A trilateration system would be used to fulfill desired requirements. This system was based on the time taken for an ultrasonic signal to traverse a certain distance. The distance between two points can be measured using the time taken for an ultrasonic signal to travel from one point to another in an open space. By emitting an RF signal and Ultrasonic signal simultaneously the

Page 94: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

83

difference of the time for the two separate signals to reach a certain target can be considered as the time for the ultrasonic signal to travel between the two points since the speed of a RF signal was much faster than the speed of an ultrasonic signal. This, however, will only be sufficient to calculate the distance, not an actual position. Using this distance a parameter can be drawn around the receiving point and the signal would have originated somewhere on the perimeter of this circle. If there were two more receiving points also measuring the time difference between the RF signal and the ultrasonic signal two more circles can be drawn around those points and the point at which all of these circles intersect will be the point where the signals emitted. This idea was used to create a local positioning system on Knight Gear. By locating three receiving points on advantageous positions on a robot’s local coordinate system, namely A, B and C, the required equations can be derived to estimate one robots position with respect to another. Figure 48, displays a graph with A,B and C coordinates.

Figure 48 –Relative coordinate system for Localization Permission Pending

( )

( )

( )

( )

( )

( )

Let

Page 95: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

84

By substituting we get,

( ) (1)

( ) (2)

( ) (3)

( ) ( )

(

)

( ) ( )

(

) (

)

(

) (

)

The relative angular position was also an important factor in determining Knight Gear’s positioning. Most applications have either used compasses or GPS modules in order to determine the relative angular positions. Having said that, the relative angular position can be determined by using 3 ultrasonic beacons instead of 1 with each beacon being on the origin, X-axis and Y-axis of a robot frame, respectively. The approach mentioned does not require the use of additional types of sensors other than the ultrasonic sensors already being used. The drawback of this method was the requirement of multiple capture modules in order to measure the distance to 3 beacons except of 1.

( )( )

( )( ) ( )( )

Page 96: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

85

Considering that the Knight Gear doesn’t require sharp angular movements the error that can be accumulated can be considered negligible. Once the relative position and orientation between the members of the robot team are determined, the instantaneous angular and linear velocities can be determined by speeds of the wheels on the differentially driven robots as shown in figure 49.

Figure 49 – Determination of instantaneous angular and linear velocities Permission Pending

A complete understanding of the dynamic state of the formation of the team of robots could be obtained by measuring the relative distances, relative angular positions with the use of ultrasonic sensors and the linear and rotational speeds of each robot through feedback from the driving motors. The parameters needed to maintain the formation can be shared by communication between the master and the slaves using RF communication according to a specific. This was another advantage of using RF signals for the trilateration system

In order to obtain the required positions, orientations and speeds after making the necessary data acquisitions a feedback control system was necessary. The most attractive choice was a PID control system because it is a suitable, tested and proven control algorithm for the controlling of mobile robots. Two separate PID control loops were needed in order for obtaining the required linear/angular velocities from the required positions/orientations and the ultrasonic sensory data

Page 97: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

86

inputs and subsequently to obtain these required velocities through controlling the rotational speeds of the driving motors through PWM signals and encoder feedbacks. The block diagram of the controller is shown on next page in figure 50.

Figure 50 - Controller Block Diagram

5.11 Control Algorithm For controlling Knight Gear, we decided on using a proportional-integral-derivative controller (PID Controller) to have it follow the user. In addition to this we add collision detection algorithms to avoid obstacles as Knight Gear makes its way towards the user. Additionally we use Bluetooth and GPS as additional input signals for the PID controller. The PID controller calculated the current error, the integral of the previous errors, and divertive of the future errors to calculate the ideal turning angle to stay on target. All three types of errors are multiplied by a coefficient and then added together. The value of these coefficients dictated if and by how much the target

Page 98: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

87

will be overshoot by the correction angle calculated by the PID controller. The effects of the integral coefficient can be seen in the figure below, figure 51.

Figure 51 – Effect of the integral coefficient Work in public domain.

As can be seen in figure 37, a high integral coefficient caused a huge initial overshoot of the target and big ripples in accuracy, thus a low integral coefficient would be used in Knight Gear’s PID controller. The effects of the current or proportional error coefficient can be seen in the figure below, figure 52.

Page 99: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

88

Figure 52 – Effect of the Proportional coefficient Work in public domain.

Figure 38 shows that a high proportional error coefficient could also cause a large overshoot, thus a small value would be chosen. The value of the proportional error coefficient must however be great than the value of the integral coefficient since we wanted the proportional error to be the major driving force of the PID controller. The effects of the derivative coefficient can be seen in the following figure, figure 53.

Page 100: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

89

Figure 53 – Effect of the Derivative coefficient Work in public domain.

As can be seen the change in the derivative coefficient does not change the magnitude of the overshoot by much, but it does affect the length of time the overshoot is in effect. As the coefficient rises however, the ripple’s magnitude decreases, thus one would like a higher derivative coefficient, but not one that was greater than the proportional coefficient. The main control algorithm will call the PID controller with the sensory information from the infrared and ultrasonic fused sensors. The PID controller will use the previous values to calculate the error, integral, and the derivative and return to the main control algorithm two velocities which will be passed to the front motors causing Knight Gear to turn on the direction of the slower front motor. These velocities are calculated with adding to the left front motor and subtracting from the right front motor the PID’s error correcting velocities to a base velocity used for all four motors. This is done since a positive correcting indicates that the user is to the right of Knight Gear and it needs to turn so by increasing the motors of the left front wheel, while a negative value indicates that the right front wheels must speed up to turn leftward. Before the velocities are sent to the motors the main control algorithm will call the collision detection algorithm with the ultrasonic information from the ultrasonic sensor and Knight Gear’s planned motion vector to determine if there is an object in front of Knight Gear and if it will collide with it. If there is no imminent collision

Page 101: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

90

the collision detection algorithm does not alter the velocities of the motors; however, if there is an imminent collision the algorithm then decides if it can be avoided by moving an arc or to stop Knight Gear completely. This is determined by using the relative localization calculations to determine if the object will come into collision because it is headed to Knight Gear, if Knight Gear is headed towards the object, or if the vectors of Knight Gear and the object would intersect soon. From there it the algorithm calculates the most efficient method of avoiding the collision; for example, if Knight Gear is in a collision course with a moving obstacle it would most likely be best to just stop advancing until the obstacle has passed the vector of movement. If there is no IR signal to supply the PID controller the main control algorithm will instead use GPS or Bluetooth signals depending on which gives the more accurate reading. Bluetooth will be implemented due to the lack of accurate GPS signals while indoors. Using these signals Knight Gear would continue to use the previous values calculated in the PID controller to locate the user and continue to follow them with the infrared and ultrasonic fused signals. However, in the end we decided not to use the derivative factor for the implementation of Knight Gear. After further researching, it turned out that Derivative was not necessary to fulfill Knight Gear’s functions. The class diagram of the new PI control that we used is shown is figure 54.

Page 102: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

91

Figure 54 - Class Diagram for the Control Algorithm

5.12 Microcontrollers

For the project of Knight Gear, the group decided that a good choice would be to have one central microcontroller for all the heavy computing and multiple small controllers for sensors, motors, and accessories. The central microcontroller does not need to be very powerful, but enough to be able to handle and process all incoming data that is simplified by the smaller, weaker, outer microcontrollers which handle the analog I/O from the devices. First, microcontrollers must be examined for the central unit. This controller is the most vital, as it is the main processing unit for the tracing algorithm which decides all the other functions of

Page 103: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

92

the Knight Gear robot. Later, smaller controllers will be examined in order to decide on motor controller, sensor controller, and accessories control (such as GPS, Bluetooth, etc.).

5.12.1 MC68332

The Motorola MC68332 was a viable option for the project Knight Gear. The MC68332 processor came with a Linux operating system and is programmable in C and C++. It can be programmed in C and was very low cost of $11.94, so it had become a good choice for the project. These microcontrollers were very versatile because of the many I/O ports on it. The processor also was very small, and can be easily placed in the chassis of Knight Gear. Since the MC68332 was a 32-bit microcontroller, and has 2-Kbyte static RAM, it could be a very good fit as a central processing unit for the whole system for interpreting all the signals from the motor controllers and sensor controllers.

5.12.2 PIC 18F452

The PIC18 Family of microcontrollers was another option for the project Knight Gear. This processor was a RISC processor, had 16-bit instructions, and was programmable in C. These processors also have 28 pins, making them another great choice for the central processor of Knight Gear. Looking specifically at the PIC 18F452 processor, at a cost of $4.68 it was cost effective and useful for the project Knight Gear. If this processor was used as the central processor, the group would be trading cost over memory.

5.12.3 Intel 8051

The Intel family of microcontrollers had a processor small and powerful enough to match the specifications needed for the microcontroller, and that was the Intel 8051. The 8051 was an 8-bit microcontroller, has 32 input/output lines, and was programmable in C using Keil IDE embedded development tool. It was small power usage and low memory was perfect for taking input and outputs from the sensor systems or the motor systems.

5.12.4 Atmel ATMega2560

Another great option for the microcontroller for Knight Gear was the Atmega 2560 from the Atmel family. Specifically speaking, the Mega Pro 3.3v from Sparkfun. This microcontroller allowed for Knight Gear to fully use all the pulse wave modulation lines that it required for all of the ultrasound sensors and for the motor drivers. With a 3.3 volt operating voltage, 54 digital I/O pins, 15 of them being PWM, 16 analog inputs, and a large amount of documentation from

Page 104: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

93

different hobby websites make the Mega Pro a great low power option for the microcontroller for Knight Gear.

5.12.5 Microcontroller comparison

In all, the four microcontrollers could be implemented in different ways to make the robot, Knight Gear, function properly. The table 17 below shows how the microcontrollers compare to one another in order to choose a viable option.

MC68332 Intel 8051 PIC 18F452 Atmega 2560

Digital I/O 15 24 24 54

Analog I/O 15 8 8 16

Operating Voltage

5V 3.3V 5.5V 3.3V

Cost $11.94 $1.50 $4.68 $17.98

Table 17 - Comparison of the three microcontrollers

Based on the table, and on what the group and the project required form the microcontroller, the best choice would be the Atmega 2560 from Atmel. Shown below in figure 55 is the schematic diagram for the Mega Pro 3.3V from Sparkfun, which is what the group will be using when working with Knight Gear.

Page 105: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

94

Figure 55 – Schematic diagram for the Mega Pro 3.3V Permission Pending

Below is the pin connection for the Mega Pro 3.3V in figure 56.

Page 106: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

95

Figure 56 – Pi Connections of the Mega Pro 3.3V Permission Pending

The following figure 57 represents the power schematic of the ATMega2560.

Page 107: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

96

Figure 57 – The Power Schematics for ATMega2560

5.13 Budget and Financing

For the senior design project Knight Gear, the expenses were covered mostly by the group members. The group would pay out-of-pocket for all cost related to the parts acquisition, labor, and building of Knight Gear. As a group, each member chipped in over $100, depending on how much all the parts in total would cost.. $500 dollars was the soft cap for the financing of the whole project.

If the expected cost for Knight Gear surpasses $500, the group would in turn look for support for funding the extra costs of the project. Parts will start being acquired as quickly as possible to ensure that the prototyping and testing was done quickly and efficiently. One of the decisions made by the group was to acquire and test parts quickly in order to get replacements in case of malfunctions or miscalculations of parts chosen. A table of the cost of parts is shown below.

Page 108: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

97

5.13.1 Finance Table

Our estimated finance that will go in the implementation of Knight Gear is listed below in Table 18.

Part Cost

Ultrasound Sensors $254.82

Weight Sensor $9.95

Accelerometer $24.95

Op Amp, Fuses, Schottky Diodes $48.41

6 Motor Drivers $16.29

Heat Sinks $15.67

LP Motor and Wheels $119.65

HP Motors and mounts $136.55

2 6V Batteries $28.29

5x Motor Drivers and Voltage Regulators

$27.29

Battery $5

Motor $12

Motor Controller $1.87

Chassis $27.30

Microcontroller $4.68

PCB $527

Total $1232.43

Table 18 – Finance Table

5.13.2 Man Hour Costs

The work put into Knight Gear by the group had no monetary cost, but does had time spent. During research and designing of the robot alone, the group had spent over 50+ hours each member. When added to an estimate of 20 hour each member for prototyping and testing, that would give a total of 70+ hours per member spent on the project Knight Gear.

Page 109: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

98

6. Design Summary

Knight Gear was an autonomous robot with the purpose of following a single user for the purpose of assisting them with carrying their materials around. The robot has multiple systems being implemented at once, and some of these communicate with one another. The major systems were Power, Motors, Sensors, and Central Processing. In this section, these four systems will be defined and their functionality explained. Also in this section, how all four of these systems work together were explained.

6.1 Power System

The power system for Knight Gear was very intricate. Knight Gear had a NiMH as the main power source. This was chosen because of the high capacity it had. It had a total of 9.6 V with 2100 mA, and was a very good power source for Knight Gear. This was the main part of the power system for Knight Gear. Another major component of the power system for Knight Gear was the solar panel that is being implemented into it. One of our goals with the power system for Knight Gear was to make the battery rechargeable, while it is in standby, with a solar panel. This feature added to the survivability of Knight Gear as it operated during the day and outside. Lastly, Knight Gear has 3 different voltage regulators that will be implemented in order to power the motors, sensors, and microcontroller. These voltage regulators vary between 9V, 6V, and 3V. These components all together defined the power system of Knight Gear, and a block diagram of this has been shown in the group’s power research and implementation section.

The power on Knight Gear would be either on or off. When the robot is off, the solar panel would be charging the battery, if possible. This will give the battery a longer lifetime and in turn give Knight Gear a longer operating time. When the power was on, the solar panel would switch off and the battery would power the components of Knight Gear. While power was activated, Knight Gear would run until one of two scenarios happens. One being that power will be used until standby mode or turned off. The way Knight Gear was used, this seemed like the most common case because the user would only need to carry a load for short bursts of time. This gave Knight Gear a very long battery life when though about because a person had the chance to stop and set Knight Gear into standby or would reach their destination in a short amount of time. The second scenario was that power would be used until the battery has no more charge. This would be a very unlikely case because of who the intended user is. The user wouldn’t be using Knight Gear for extremely long periods of time. Shown below is the discharge rate for the 9.6 V NiMH battery that was being implemented in Knight Gear. As the graph shows, the discharge time was very long and shows how the battery, if used how it is designed to be used in short periods of time, will give Knight Gear a very long life. The discharge curve is shown in figure 58 on next page.

Page 110: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

99

Figure 58 - Discharge curve for 9.6V NiMH battery Permission Pending

6.2 Control System

The control systems of Knight Gear could be divided into several components such as formation controlling level, communication level, and individual decision making. Robot controller had a multi-level hierarchical architecture such can be distinguished as artificial intelligence level, control mode level. It was important to address the all the levels in order to achieve good results.

The simplest case the control system of a mobile robot consists of at least input module (sensors), control module and output/driver module (motors). A block diagram of such control system is shown below in figure 59.

Figure 59 - Block Diagram of Navigated Control System

Permission Pending

Page 111: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

100

6.3 Motor System

Now that the power system for Knight Gear had been defined, the motor system was very simple to define. The motor system for Knight Gear consisted of four 6V DC spur gear motors and a Texas Instruments SN754410 motor controller. The motor system was directly affected by the power system and the central processing system. The four 6V DC spur gear motors were powered by the power system using a 6V voltage regulator. These four motors will have to move one individual wheel each, because we were looking to carry loads and if one motor had to power multiple wheels the weight of the load Knight Gear would have to carry would decrease. In the design of Knight Gear, there were two extra wheels that were not powered by the motors and were only be implemented for stability reasons. The motor controller from the motor system was directly communicating with the central processing system. The central processing system was telling the motor controller whether it needed to slow down, speed up, turn left, or turn right. All of these commands came from the microcontroller in the central processing system, which will be computing multiple factors from the sensor system. Out of the four main systems that make up Knight Gear, the motor system is the simplest of them.

6.4 Sensor System

The third main system in Knight Gear, and one of the most important ones, was the sensor system. The sensor system is composed of ultrasonic proximity sensors. The ultrasonic sensors, specifically the Parallax PING))) 28015, Knight Gear will use these sensors for two purposes. First being the locating of the user. This was done by using multiple ultrasound sensors on Knight Gear picking up on an ultrasonic signal being sent from the user. With multiple ultrasonic sensors, Knight Gear used the data received as distances from each sensor as a way to calculate which direction the user was. The second function of the ultrasonic sensors was collision avoidance. This was a very important function of Knight Gear. The tracking algorithm would be in the central processing system. So all the ultrasonic sensors are doing was sending data directly to the microcontroller which in turn will take the data and analyze where the user is.

6.5 Central Processing System

The last main system of Knight Gear was the Central Processing system. This system included the microcontroller. This system is what makes Knight Gear do everything. All other systems rely on this central processing system. The microcontroller is the ATMega 2506 by Atmel. This microcontroller was chosen for Knight Gear because of its programmable memory size and low cost. This microcontroller would house the tracking algorithm, the collision detection and avoidance algorithm, and would keep track of the state of Knight Gear. The state of Knight Gear was either to be on “standby” or “work”. Standby state occurred whenever Knight Gear senses the user is not moving for longer than sixty

Page 112: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

101

seconds. This was a timer kept in the microcontroller and once it activated the standby status, the microcontroller let the power system know that it could switch to let the solar panel charge the batteries. The microcontroller does not stop its functions for tracking and tracing movement though. It would continue to tell the sensors to check if the user is moving or not. Once Knight Gear sensed movement again, it would let the power system know to switch back from solar panel charging to battery use. For the tracking algorithms, Knight Gear senses if the user was moving left or right and also check if the user was moving forward or backwards. This was done by the microcontroller telling the sensor system to check where the signal was and take back timing data which can be converted to distance inside the microcontroller. Once the distance from Knight Gear was calculated, the central processing system will signal the motor controller with speeds for each of the four motors. These speeded that it signals out, determined by the tracking algorithm, would turn make Knight Gear move towards the user signal. This process of looking for a signal and commanding the motor controller was repeated many times at a high speed, making it so that Knight Gear never loses where the user was.

6.6 Code Flow The figure displayed below defined our robot at simplest level. This code flow shown in figure 60, is the basis of our software design. Knight Gear pinged the user and the user emitted ultrasonic waves to Knight Gear. It detected and wave and direction vector was calculated after minimizing any noise, if there was. Sensors emitted ultrasonic waves for collision detection. If sensors did not time out and the calculated distance is less than 0.5m, then collision avoidance vector was calculated and knight gear advanced to the new calculated vector. If sensors did time out then Knight Gear advances on the new calculated direction vector.

Page 113: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

102

Figure 60 - Code Flow of Knight Gear

We decided not to implement the obstacle avoidance because of how we were tracking the user with the ping, echoed off the transmitter or the robot might interfere with the control algorithms or collision detection. The only alternative was to purchase new sensors that worked on a different frequency, but we could not afford them due to budget concerns.

Page 114: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

103

7 Description of Prototype

We implemented a virtual prototype of all subsystems of Knight Gear on Xilinx. We will use this to prototype the response of the sensors. Using Xilinx we can saw what data the sensors would return depending on the input data we provided and we can learn what to expect when we build the actual robot.

7.1 Prototype Design

Using Xilinx we built Verilog or schematics for the ultrasonic sensor and the motors. We then tested the inputs required by the motors to spin to their appropriate angular velocities and we test the link between the sensors and the motors. After doing these tests of concepts, the components of Knight Gear and the user’s transmitter should be tested before being integrated into the prototype. Finally after that, the prototype can be build and the software that allows Knight Gear to follow the user is tested.

7.2 Components List

These are the components that were used in the implementation and execution of Knight Gear. This is a tentative components list; number of a particular device may or may not change depending on the functionality of each device in this list below in table 19.

Page 115: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

104

Components List

3 Ultrasonic Sensors

1 Four-Wheel robot frame

1 Infrared Sensor

1 Infrared Tag

4 Wheel Motors

1 Solar Panel

1 Solar panel battery recharger

1 Chassis

1 Weight Sensor

1 IMU

1 Camera System

2 Motors

2 Xbee Antennas

A packet of Bolts

Table 19 – Components List

7.3 Prototype Construction

The prototype for Knight Gear was built to test out all the basic functions of Knight Gear as defined previously. The main prototype was built after finishing the tests on Xilinx and fully testing the sensors themselves to verify that they were in working condition. The sensors were attached to the Knight Gear prototype along with downloading the main control software. The four wheels were attached to the four individual motors with were connected to the main controller which assigned them there angular velocities. After attaching the wheels and the carry case the solar panel was attached to the battery. With the psychical prototype finished the transmitter is built. The transmitter had clip that attached it to the user’s belt and will contain one ultrasonic sensor and radio frequency transceiver. The transceiver is used to locate the transmitter and the ultrasonic sensor is used to increase the accuracy of the ultrasonic sensor on the prototype.

Page 116: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

105

7.3.1 Frame Assembly

Instead of buying a premade chassis, we decided to make our own. We could not find any premade chassis that would it the desired length and support all the components. Making a cassis from scratch does add time but because we had one member of the group is familiar with building similar machines, it made it easy for us. We attached the motherboard to the frame and connected the four motors to both the frame and the motherboard. The power supply was connected both to the mother board and to the solar panels which were used to recharge the batteries while the prototype was in use outdoors.

7.3.2 Steering System

The prototype was implemented to the main controller scanned for the user using ultrasonic sensors and then sends that information in the PI controller. The ultrasound sensors were used to determine the distance from the robot. The sensors were rotated until the user was located by the RF transceiver, then the ultrasound sensors are pulsed so to triangulate the distance from the user with how long it took for the echoes to return to Knight Gear. The data was given to the controller which then calculated how off center Knight Gear was from the user; this was known as the current error value. With this the controller then calculated a velocity vector using this error along with the previous error values and potential future error values to reach the user. The vector formula used three constants, one for each of the three types of errors, as multiplier to determine how much of an impact the specific errors have on the velocity vector of the robot. The velocity vector that Knight Gear implemented send to the motor controllers that decode the vector into the velocity at which the individual motors must spin at for Knight Gear to advance in the instructed vector. The graphical representation is shown in figure 61 on next page.

Page 117: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

106

Figure 61 - Flow chart for the prototype software.

7.3.3 Sensors

After finishing the proof of concept, the transmitter and the robot can start being built. The transmitter will have an ultrasonic transmitter embedded in it to improve the ability of the software in Knight Gear to locate and follow the user and had an rf tag used for ultrasonic sensors to pick up. These were tested before being implemented into the robot verifying their data with those of the Xilinx prototype. The RF tag should be picked up by the two ultrasonic sensors should be more accurate than just using the ultrasonic sensor on the machine.

Page 118: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

107

8 Testing 8.1 Safety Harness

To ensure if Knight Gear is safe for public location, lot of testing will be done indoors and outdoors. Does, Knight Gear possess any threat to people in the surrounding? This is a prime question that needs to be checked after the prototype is built. Knight Gear should be very well harnessed to keep it within its limits. It is not specifically decided that how this segment of Knight Gear will be test, however it is reasonable to implement a force sensor if necessary.

8.2 Dimensions

To test the dimension, we go back to the goals and specifications of Knight Gear. Dimensions will be marked on the floor and the building of the framework will be carried out meticulously throughout the project. This will give very less percent error to the desired dimensions of Knight Gear.

8.3 Sound Level

During the testing of Knight Gear, there is also a segment that determines if the sound level is too loud to disturb the people around. For this type of testing, we would need volunteers’ feedback if they think the noise level is too much or not.

8.4 System Tests

The following sections are used to test the functions of Knight Gear, along with its components. Included are tests for the infrared, ultrasonic, and weight sensors and the motors. There are also tests for Knight Gear’s ability to follow the user while they do simple, complex, and specific actions and areas. These tests will be used to edit the parameters of Knight Gear if need arises. All tests will be conducted inside the University of Central Florida inside or in the vicinity of the Harris Corporation Engineering Center and the Engineering I building.

8.4.1 Radio Frequency Testing The figure 62 below shows how Xbee is programmed to give us the ID, high and the low for the signal which is shared by the sender and receiver.

Page 119: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

108

Figure 62 – Xbee Testing

The figure 63 shows that the Xbee is communicating successfully.

Figure 63 – Xbee Communicating Successfully

Page 120: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

109

8.4.2 PI Controller Testing The values of the ultrasound sensors are printed in the computer. The components of the PI controller are then printed. Also the direction (left or right) of the turn is printed. Finally the adjusted speed of the motors is printed. Figure 64 below shows the distance measuring from the user to the robot.

Figure 64 – PI Controller Testing

8.4.3 Ultrasonic Sensor Tests The transmitter for Knight Gear’s user is attached to the user’s back and should be unobstructed, preferably clipped to the belt of the user. These tests are designed to ensure the transmitter emits the proper tags so that the robot can follow the user properly. The tests should be concluded in a lab were the signals transmitted by the sensors can be measured. The tests are listed on the next page in table 20.

Page 121: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

110

Test Description Outcome Comments

The tester should have the infrared sensor emit a beam that should be deflected on the transmitter. The transmitter should be no more than 30 cm from the sensor. The sensor should return the distance of the transmitter.

Untested

Infrared sensors were removed from the design of Knight Gear early while in the building phase thus the test was never conducted.

The tester should have the transmitter within one meter of the ultrasonic sensor. The sensor should detect and return the distance from the transmitter to the sensor.

Success

The ultrasound sensors returned data accurate to 3 centimeters plus or minus the actual distance.

The tester should have both sensors on at the same time and have the transmitter be equidistant from both while being within reach of both (30 cm). Both sensors should give the same distance from the transmitter.

Untested

Same reasons as the infrared sensor test.

Table 20 –Ultrasonic sensor tests

8.4.4 Simple Movement Tests

These tests are made to test simple movements of the robot, such as following the user in a forward line, turning left to follow the user, or turning right to follow the user while the user is in sight of the robot. One more test should be conducted to make sure the robot would rotate to locate the user then advance toward the user. These tests should be conducted in an open area, with two testers. One tester should take the role of the user while the second tester should turn on the robot when the user is in position. The testing is listed on the next page in table 21.

Page 122: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

111

Test Description Outcome Comments

The user should stand about two meters in front of the robot. The other tester should then turn on the robot. The robot should now search for the user and after locating it in front of it, it will move straight forward. The robot should stop about half a meter away from the user.

Success

Knight Gear advanced in a near perfect line while searching the user straight in front of it. Knight Gear stopped within half a meter from the user.

The user should stand about two meters in front of the robot and one meter to the right of it. The other tester should then turn on the robot. The robot should locate the user and gentle curve forwards and to the right and stop within half a meter from the user.

Success

Knight Gear tracks the user and stops within half a meter from the user. The arc of travel is not too smooth.

The user should stand about two meters in front of the robot and one meter to the left of it. The other tester should then turn on the robot. The robot should locate the user and gentle curve forwards and to the left and stop within half a meter from the user.

Success

Knight Gear tracks the user and stops within half a meter from the user. The arc of travel is not too smooth.

The user should stand two meters to the right of the robot. The other tester should then on the robot. The robot then would scan for the user, turning counterclockwise until it locates the user. The robot should then head towards the user and stop within five meters from the user.

Failure

Knight Gear only detects the user if it’s within a 100o

cone in front of Knight Gear.

Table 21 – Simple movement tests

8.4.5 Simple Following Tests

These tests are meant to test the ability of the robot to follow the user in simple paths without obstacles. These tests require only one tester who will act as the user. The tests should be conducted in an open area. The testing is listed below in table 22.

Page 123: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

112

Test Description Outcome Comments

The user should turn on the robot. Then walk forward for fifteen to twenty meters in a straight line. The robot should follow in a straight line and stop within half a meter.

Success

Knight Gear follows the user in an almost perfect line, which small derivations which are quickly fixed. Knight Gear stops within half a meter of the user.

The user should turn on the robot. Then walk in a curved path to their right for fifteen to twenty meters. The robot should follow in a smooth arc behind the user and stop within half a meter.

Success

Knight Gear followed the user in a wide arc, and stopped within half a meter from the user.

The user should turn on the robot. Then walk in a curved path to their left for fifteen to twenty meters. The robot should follow in a smooth arc behind the user and stop within half a meter.

Success

Knight Gear followed the user in a wide arc, and stopped within half a meter from the user.

The user should turn on the robot. Then walk forward for five meters, then turn left and advance ten meters, and finally turn right and advance forward. The robot should follow and make smooth curves whenever the user takes a turn and stop within half a meter from the user.

Success

Knight Gear would follow the user as they tuned as long as the user did not make too sharp of a turn to put them outside of Knight Gear’s 100o

cone of detection in front of it.

The user should turn on the robot. Then walk forward for five meters, and then stop. The user should wait for the robot to catch up, then continue walking forward another five meters, then stop again and wait for the robot. The user then waits for the robot to come to a complete stop before advancing ten more meters. The robot should follow and stop within half a meter from the user, and continue to follow when the user starts walking again.

Success

Knight Gear successfully stopped when it reached the user and continued when the user advanced more than a meter away from Knight Gear at each of the stops.

Table 22 – Simple following tests

Page 124: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

113

8.4.6 Basic Obstacle Avoidance Tests

These tests are designed to test how the robot handles basic obstacles such as hills, corners, and bystanders. The hill test can be tested in front of the Harris Corporation Building in the University of Central Florida. The other tests may be conducted indoors or around buildings. The hill test and the corner test only require one tester to act as the user, while the bystander test requires two testers: one to play the user and one to play the bystander. The testing description is listed on next page in table 23.

Test Description Outcome Comments

The user should turn on the robot. Then the user should walk straight up and down a hill or pair of inclined planes. The robot should move straight up the hill then down the hill without stopping.

Success

As long as the incline was not too sharp Knight Gear was able to follow.

The user should turn on the robot. Then the user should walk towards a corner either indoors or around a building. The robot should follow the user around the corner, avoiding collision with the corner and not stopping.

Success

As long as the user stays away from the corner Knight Gear will follow.

The user should turn on the robot, while the bystander is five meters in front of the robot. The user should walk towards the bystander and go around them. The robot should follow the user and avoid the bystander. The robot should not stop while avoiding the bystander.

Success

As long as the user makes a wide enough turn, Knight Gear will avoid hitting the bystander due to its large turning radius.

Table 23 – Basic obstacle avoidance tests

8.4.7 Advance Maneuvering Tests

These tests are designed to gauge the maneuverability of the robot by seeing how adaptable it is to rapid movements of the user. This is represented by the user moving faster or slowing down and having the robot adjust its speed to match the user’s speed. Another test would have the user change directions sharply and quickly having the robot follow the user. A final test would make sure the robot can avoid incoming obstacles such as walking bystanders. The first two tests need to be done in an open area or hallways were sharp turns are possible. The final test requires multiple testers to take the role of bystanders to impede the robot and force it to avoid them while following the user. The testing of advance maneuvering is listed on next page in table 24.

Page 125: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

114

Test Description Outcome Comments

The user should turn on the robot. Then they should start walking forward for ten meters. Then the user should increase their speed and move for another ten meters. Finally they should slow down back to walking speed. The robot should be following the user and be matching their speed. Thus the robot should slow down when the user slows down.

Failure

Knight Gear can only match the average walking speed of a user.

The user should turn on the robot. Then the user should walk forward and take sharp turns quickly. The robot should follow the user, it might stop on the turns to look for the user, but it should only occur when the user takes an incredibly sharp turn really quickly.

Failure

Once the user makes a turn sharp enough to leave the cone of detection, Knight Gear losses the user.

The user should turn on the robot. Then the user should move forward for then meters, then do a U-turn and walk fifteen meters. Afterwards a sharper U-turn should be taken. The robot should follow the user without stopping on the first U-turn, but it might for the second turn.

Success

As long as the turn is not sharp enough to lose Knight Gear, Knight Gear will follow the user in a U turn.

The user should turn on the robot. Then they should walk towards the bystanders. The bystanders then slip in between the user and the robot. The robot should sense the bystanders and avoid them, and then it should look for the user and try to catch up if needed. The robot should not stop when avoiding the moving bystanders, but it might stop when looking for the user.

Failure

Knight Gear lacks object avoidance features.

Table 24 – Advanced maneuvering tests

8.4.8 Indoor Performance Tests These tests are designed to test how Knight Gear would behave indoors, and how Knight Gear navigates through doors and elevators. All the following tests require one more tester to aid in opening doors and holding the elevator door open for the tester who plays the part of the user and Knight Gear. The first test would see how Knight Gear navigates through big double doors like those used for entrances of buildings. The second test involves making a corner in a hallway. The third test sees how Knight Gear navigates through regular doors. The final test will test how Knight Gear handles entering and leaving elevators. These tests can be seen in the following table, table 25.

Page 126: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

115

Test Description Outcome Comments

The user should turn on the robot. The assistant should open the big double door. The user should walk through the double doors. Knight Gear should follow the user through the double doors; it should avoid the center frame of the door if it exists in the double door used for the test.

Success

The double sized doors were big enough for Knight Gear to pass without crashing into anything.

The user should turn on the robot. Then the user should walk forward in a hallway with a 90 degree turn. Knight Gear should follow without turning into wall. The user should then go into the corner and go past it without making a sharp turn or hugging a wall. Knight Gear should follow without losing the user.

Success

As long as the user avoided being close to the walls, Knight Gear followed the user.

The user should turn on the robot. The assistant should open the door. The user should walk through the door. Knight Gear should follow the user through the door, it should avoid the center frame of the door as long as the user enters through the center of the door.

Success

The user must stop in front of the door and have Knight Gear be directly facing it the user then needs to walk in a straight line through the door.

The user should turn on the robot. The assistant should call for the elevator and enter first while holding the doors of the elevator open. The user should walk into the elevator as far as possible as to give Knight Gear enough space to enter the elevator. Knight Gear should follow the user into the elevator; it should avoid the frame of the elevator and stop without obstructing the elevator’s door. The user should then turn off the robot. The user should move Knight Gear such that the robot is in the back of the elevator and the user is near the door, Knight Gear should be facing towards the door of the elevator. The user should turn on the robot again while the assistant holds the door open again. The user should walk out of the elevator and have Knight Gear follow the user out of it without colliding with the assistant or the inside of the elevator.

Success

The elevator doors must be open before turning on Knight Gear so the echoes of the transmitter do not affect Knight Gear too much.

Table 25 – Indoor Performance Tests

Page 127: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

116

8.4.9 Weight Sensors and Solar Recharging Tests

The robot is equipped with weight sensors which when tripped would not allow the robot to move. These sensors are set to trip at fifty pounds of weight. The batteries of the robot should be rechargeable by solar energy, thus equipped with a solar recharger. The test for the sensors can be done anywhere while solar battery tests should be done both indoors and outdoors. Only one person is needed to play the part of the user in these tests. The testing of weight sensors and solar recharging is listed on next page on table 26.

Page 128: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

117

Test Description Outcome Comments

The user should insert forty-five pounds into the robot. Then they need to add a five pound weight. The robot should then be turned on. The user should advance. The robot should not move from its location. The user should then take out the five-pound weight, then move forward again. This time the robot should follow the user.

Failure

We were unable to get any useful data out of the weight sensors, the output voltage emitted by them never changed, even when we changed the load.

The user should check the charge of the battery before implementing this test. This part of the test should be conducted indoors. The user should have the robot follow them for a period of thirty minutes. Then the user should check the charge of the battery. Then the robot should be placed outside in the sun, and be left to charge in the sunlight for thirty minutes. The user should then check the charge of the battery again. The charge of the battery after the thirty minutes in the sun should be higher that after the thirty minutes of indoor operations closer to its base case.

Success

The charge of the battery was higher after being left in the sun.

The user should check the charge of the battery before implementing this test. This part should be conducted indoors. The user should have the robot follow them for thirty minutes. Then the user should check the charge of the battery, and note how much the charge has dropped. The user should then recharge the battery to the charge prior to the test. This part of the test should be conducted outside. The user should then have the robot follow them in a similar path to how they had the robot follow them indoors for thirty minutes. The charge should be then checked again and the reduction in charge noted. The change in the charge for the outdoor test should be lower as it should be charging the battery as it follows the user.

Success

The charge of the battery was slightly higher in the outdoor leg of the test compared to the indoor leg.

Table 26 – Weight sensor and solar recharging tests

Page 129: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

118

8.5 Efficiency Efficiency is one of the most important aspects of testing. It evaluates how changing certain components affects the overall efficiency of Knight Gear. This can be done by measuring current using amp meter and connecting it to the power line and recording the current passing through it while Knight Gear is on the move. A Google app can record the speed of the vehicle and average speed can be obtained. At the end of each run, voltage of the motor will be recorded. Once we have the current, voltage, and speed, we can compute the efficiency level of each component and then data will be accumulated to find the efficiency of Knight Gear as a whole.

From the equations given below, we can calculate the efficiency:

, and

Page 130: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

119

9. Engineering Consideration While building Knight Gear, it is very important to keep track of every single operation that is being performed and its possible positive and negative consequences. This is necessary because once the prototype is build; it doesn’t approach any harmful measures to itself and to its surroundings. For instance, it is crucial to write concrete algorithms for sensor fusion for the following sensors: infrared proximity and ultrasonic proximity sensors, so that it performs strictly what is been told to it. Similar consideration is applied to Inertial Measurement Units (IMUs) where algorithms have been implemented to amalgamate gyroscope and accelerometer.

Together these fusions of sensors result in very precise deductions as to where Knight Gear is positioned and accurately follow its user. Therefore, it is vital to trust and rely on the algorithms and tested thoroughly because if Knight Gear does end up running into a person or go off track then it is absolutely not acceptable. If such mishap does happen then a user would wonder what some possible ways to overcome such scenario are. Fortunately, Knight Gear is not as big as a car neither as heavy as a printer. It is about 24 inch tall and weighs only about 5lbs. If Knight Gear deviates from the path then, there is an emergency stop button on Knight Gear which will be placed on the top of frame, making it easier for the user to identify and use it when needed. However, that will not be necessary because as soon as Knight Gear hits something or comes into collision with an obstacle or a person then it will stop motion right at that moment and at that location. This will not cause any problem in reading or storing information. Once it is switched ‘on’ again, Knight Gear will accumulate all the information from accelerometer, gyroscope, GPS, beacons and inertial measurement units to find its location and start moving forward.

The unusual and unfortunate mishap of Knight Gear is not all that there is to its engineering consideration. A lot is asked about if the robot is a good fit to our world and if it will create any type of pollution that will not be bearable by the people? Two of the most important aspects of Knight Gear are the following:

Maintenance, and

Environmental Impact

How long will it operate on batteries? When does it require charging? Will it display a warning sign that battery is dying and needs charging? How much information will be recorded through the vision system of Knight Gear? How will the user extract or receive the video data in a format that is compatible to the system and at the same time easily accessible to the user? All of these questions are incorporated in maintenance section. While maintenance is a very essential to Knight Gear, it is also responsible for any environment impact that may take place.

Does Knight Gear exude any gases that could cause is potentially harmful to people around it? All the type of sensors and motors that Knight Gear is so much

Page 131: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

120

relied upon, do they cause noise pollution that will interfere other people’s conversation both indoor and outdoor. These are some potential aspects that need to be answered in the final segment of the prototype.

Knight Gear holds no harm to public nor does it pollute the environment. If

anything, perhaps, it may cause noise pollution because of four motors. However,

the merit of Knight Gear overcomes any of disadvantages if there is any. The

best advantage of Knight Gear is that students now will not have to carry their

backpack with them. They will have Knight Gear to support them and prevent

causing any upper body pain of students.

Page 132: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

121

10. Appendices

A. References

Sensors

"Infrared vs. Ultrasonic - What You Should Know | Member Robot Tutorials." Infrared vs. Ultrasonic - What You Should Know | Member Robot Tutorials. N.p., n.d. Web. 24 Apr. 2013.

"How to Use Pyroelectric ("Passive") Infrared Sensors (PIR)." Ladyadanet Blog RSS. N.p., n.d. Web. 24 Apr. 2013.

“Home | Product Categories | Infrared | SEN-08958." Infrared Proximity Sensor Long Range. N.p., n.d. Web. 24 Apr. 2013.

"Home | Product Categories | Flex / Force | SEN-10245." Load Sensor. N.p., n.d. Web. 24 Apr. 2013.

"Load Cells or Load Sensors How They Work?" Load Cells or Load Sensors How They Work? N.p., n.d. Web. 24 Apr. 2013.

"Compare Infrared and Ultrasonic Distance Sensors." Compare Infrared and Ultrasonic Distance Sensors. N.p., n.d. Web. 24 Apr. 2013.

"Transducer Beam Spread." Transducer Beam Spread. N.p., n.d. Web. 24 Apr. 2013.

"InvenSense Inc.: Gyroscope Evaluation Board: IDG-500EVB." IDG-500EVB, Gyroscope Evaluation Board, InvenSense Inc., CDI. N.p., n.d. Web. 24 Apr. 2013.

"Society of Robots - Robot Forum." Human Following Sensor. N.p., n.d. Web. 24 Apr. 2013.

"Society of Robots - Robot Forum." GPS Navigation Tutorial. N.p., n.d. Web. 24 Apr. 2013.

"Infrared Proximity Sensing: Building Blocks, Mechanical Considerations, & Design Trade-offs." Infrared Proximity Sensing: Building Blocks, Mechanical Considerations, & Design Trade-offs. N.p., n.d. Web. 24 Apr. 2013.

"Home | Accelerometer, Gyro and IMU Buying Guide." Accelerometer, Gyro and IMU Buying Guide. N.p., n.d. Web. 24 Apr. 2013.

Page 133: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

122

"MB1020 LV-MaxSonar-EZ2 Ultrasonic Rangefinder." MB1020 LV-MaxSonar-EZ2 Ultrasonic Rangefinder. N.p., n.d. Web. 24 Apr. 2013.

Motors and Power Systems

"DC Motors." Motors. N.p., n.d. Web. 24 Apr. 2013.

"Robot Power Systems - Electronics & Control Projects." Robot Power Systems - Electronics & Control Projects. N.p., n.d. Web. 24 Apr. 2013.

"Robot MarketPlace - Motors." Robot MarketPlace - Motors. N.p., n.d. Web. 24 Apr. 2013.

"Motors and Actuators." - RobotShop. N.p., n.d. Web. 24 Apr. 2013

"How to Build a Robot Tutorial - Society of Robots." How to Build a Robot Tutorial - Society of Robots. N.p., n.d. Web. 24 Apr. 2013.

"Why Is Your Robots Motors Not Strong Enough? (Gearing)." Let's Make Robots! N.p., n.d. Web. 24 Apr. 2013.

"Power Transmission for Mini Robots." Power Transmission for Mini Robots. N.p., n.d. Web. 24 Apr. 2013.

.PID and Obstacle Avoidance

Naik, Ankur. Arc Path Collision Avoidance Algorithm for Autonomous Ground.Http://scholar.lib.vt.edu/theses/available/etd-01162006-112326/unrestricted/AnkurThesis.pdf. N.p., n.d. Web.

"Control Tutorials for MATLAB and Simulink -." Control Tutorials for MATLAB and Simulink -. N.p., n.d. Web. 24 Apr. 2013.

"What Are Good Strategies for Tuning PID Loops?" Control. N.p., n.d. Web. 24 Apr. 2013.

"PID Control." Let's Make Robots! N.p., n.d. Web. 24 Apr. 2013.

General

"Robot Platform | Knowledge | Wheel Control Theory." RSS. N.p., n.d. Web. 24 Apr. 2013.

"How to Build a Robot Tutorial - Society of Robots." How to Build a Robot Tutorial - Society of Robots. N.p., n.d. Web. 24 Apr. 2013.

Page 134: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

123

"Future Tense." Future Tense. N.p., n.d. Web. 24 Apr. 2013.

Principles of Robot Locomotion. N.p.: n.p., n.d. Web.

"How Does a Robot Work? - Lesson - Www.TeachEngineering.org." How Does a Robot Work? - Lesson - Www.TeachEngineering.org. N.p., n.d. Web. 24 Apr. 2013.

"Introduction to Robots." Introduction to Robots. N.p., n.d. Web. 24 Apr. 2013.

Solar Panel

"Different Types of Solar Panels." Home Solar 101 A Homeowners Guide to Solar Different Types of Solar Panels Comments. N.p., n.d. Web. 15 July 2013.

"Solar Panel Efficiency and the Factors That Affect It | 1BOG.org." Home Solar 101 A Homeowners Guide to Solar Solar Panel Efficiency and the Factors That Affect It Comments. N.p., n.d. Web. 15 July 2013.

"Solarbotics." Solarbotics. N.p., n.d. Web. 17 July 2013.

"CleanTechnica." CleanTechnica. N.p., n.d. Web. 17 July 2013.

"Solar Charger for My Robot." Let's Make Robots! N.p., n.d. Web. 17 July 2013.

Self-sustaining Solar Powered Robot. N.p., n.d. Web. 17 July 2013

"Thread: Make Your Own Load Cell (force Sensor) from Stuff You Already

Have." Make Your Own

Load Cell

Load Cell (force Sensor) from Stuff You Already Have. N.p., n.d. Web. 17 July

2013.

Load Cell Technology. N.p., n.d. Web. 17 July 2013

Page 135: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

124

B.Copy Right Permission emails:

Linear Technology

Steve Knoth ([email protected])

Add to contacts

12:45 PM

To: 'do kim'

Cc: [email protected]

Hi,

That’s fine, good luck ion your project, and thank you for asking.

Steve

Steve Knoth

Senior Product Marketing Engineer Power Products Group Linear Technology Corporation

408-432-1900 x2364

P.S.: If replying to this email, please include all previous correspondence. This retains the history and helps us keep up with your situation.

Thank you!!!

LINEAR TECHNOLOGY CORPORATION

Page 136: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

125

******Internet Email Confidentiality Footer******

This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail, or by telephone 408-432-1900 extension x2364 and destroy the original transmission and its attachments without reading or saving in any manner. Thank you.

do kim ([email protected])

4/21/13

To: [email protected]

To whom it may concern, I am a student at the University of Central Florida and currently working a design with a group of four people as part of the senior design course requirement. We are considering using your voltage regulator for our power supply design and would like permission to use an image from your website. The paper will not be published and is for educational purpose only. The proper citations for the copyrighted work will be included in the report. please let me know if any more information is needed. Thank you for your time and consideration, Do-yong Kim

Texas Instruments copyrights

Page 137: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

126

Maxbotix

Siddharth,

Thanks for the email. I am glad to assist you with your questions. Please see my remarks below in black text.

You state: I need to use some of your datasheets and pictures of LV-MaxSonar EZ series. Can I get the permission to print your datasheet, detection pattern on my documentation.

You are given permission to use the images for the LV-MaxSonar-EZ sensor on your documentation paperwork for your senior design project. If you need any sensor images, on the bottom of the MB1010 product page there is a download link for all the LV-MaxSonar-EZ photos. The download is entitled "High Resolution Pictures.zip".

We thank you for taking the time to request permission to use the sensor's photos for your project.

Please let me know if you have any questions.

Best regards, Tom Bonar Technical Support of MaxBotix Inc.

Page 138: KNIGHT GEAR - UCF Department of EECS Synchronous Driving 21 5.3.4.4 ... Geared DC Motor for Knight Gear 50 Figure ... Flow Chart for the Prototype Software 106

127