Wington Brito, Nathan Wong Wington.brito@aggiemail.usu.edu nathan.wong@aggiemail.usu.edu May 4th, 2012 Donald Cripps Electrical and Computer Engineering Department Utah State University Dear Dr. Donald Cripps, Enclosed is our senior project report. We built an android-based robot prototype which operates as a package delivery. This project was sponsored by the mechanical and aerospace engineering (MAE) department. Meanwhile, we have become familiar with the hardware and software of the android platform devices. One of the great benefits of this project is that open the doors for potential ongoing research of multiple real-life application of advance smart electrical/electronic devices. I was the only programmer working on the project. This has given me multiple benefits such as learned different programming platforms and improving in such a great way my programming abilities. I appreciate your comments and guidance to make the electrical design and implementation of the project a success. I have learned very well with you the important of the design before the implementation. I am grateful for everything I have learned with you to become a great engineer. Sincerely, Wington Brito

Create a stable Android-based robotic platform that will provide power and a cell

phone interface for a functional payload module.

Androbot Final Report 05/04/2012

Wington Brito, Nathan Wong

I

Senior Project Final Report for

Android-Based Robot

ECE 4850

May 4th, 2012

Wington Brito,

Instructor Approval: ________________________________________

Dr. Donald Cripps

II

III

Acknowledgments

I would like to thank Dr. Steve Hansen for his constant guidance and support. Dr. Hansen

willingness helps to make this project a success. I could not have completed the project without

him.

IV

Abstract

Figure 1A. Androbot final prototype Figure 2B. Androbot first prototype The goal of this project was to build a stable Android-based robotic platform that will

provide power and a cell phone interface for a functional payload module. The main aspects

taken into account in the design were the power and torque of the motors, torque of the servos,

stresses on the top plate, traction, and how to communicate with the onboard cell phone.

One of the main parts of the robot is the dynamic leveling system. The design that was

chosen was a gimbal system with 2 servos controlling the leveling of the system. The reasoning

for this choice was the servos were quick enough to make the leveling system effective and not

lag behind and had the torque required leveling the platform with a 5 pound module attached to

it. The design for the motors was the Parallax motor mount and wheel kit. It was chosen mainly

because the whole motor, gearbox, mounting system, and wheels were already made and put

together. This was a great option, because it cut down a lot of time to design a gearbox that

would fit on a motor and provide the torque that was needed. The phone box and top plate were

both designed with respect to the stresses acting on them, particularly the dynamic stresses acting

V

on them from use. Due to certain unknowns such as initial acceleration of the robot

large safety factors were implemented to account for such unknowns. The design for the phone-

housing box was decided to be rapidly prototyped to allow for wireless communication and

provide enough strength. 18 gauge steel was decided for the chassis to provide ample strength

with respect to the stresses acting on it. Bike tires were decided as the design for the treads to

provide ample traction in common outdoor terrains. The on board cell phone is responsible for

the main computing of the system. The program running on the on board cell phone sends

instructions to operate the drive motors and the servo motors. The final software system design

of the project was chosen through different design tests where the concurrency or parallel

programming design was our final decision due to its ability to respond to multiple tasks or

multiple operations at once.

VI

Table of Contents 1.0 Introduction ………………………………………………………… 1 1.1 Background ……………………………………………………... 2 2.0 Review of Conceptual and Preliminary Design …………………... 5 2.1 Identified Need …………………………………………………... 5 2.2 Problem Definition ………………………………………………. 5 2.3 Mechanical Requirements ……………………………………….. 6 2.4 Electrical Requirements …………………………………………. 7 2.5 Software Requirements ………………………………………….. 7 3.0 Basic solution ……………………………………………………….. 8 3.1 Software system for cellphones …………………………………. 8 4.0 Design of system component ………………………………………. 8 4.1 Mechanical Design ……………………………………………… 8 4.2 Electrical system conceptual design …………………………….. 9 4.3 Software system design …………………………………………. 10 4.3.1 On board cellphone program ……………………………… .. 10 4.3.2 GUI program ………………………………………………… 10 5.0 Implementation and final approach ………………………………. 11 6.0 Design Results ………………………………………………………. 15 7.0 Project Management ……………………………………………….. 19 7.1 Budget ……………………………………………………………….. 22 8.0 Summary and Conclusions ………………………………………… 23 8.1 Mechanical Requirements ……………………………………….. 23 8.2 Electrical Requirements …………………………………………. 24 8.3 Software Requirements ………………………………………….. 24 Appendixes Appendix A. Battery Trade Study …………………………………….. 26 Appendix B. Motor Trade Study ……………………………………… 27 Appendix C. Servo Trade Study ……………………………………… 28 Appendix D. Phone Trade Study ……………………………………… 29 Appendix E. Angular Speed platform Calculations …………………… 30 Appendix F. Torque Calculations ……………………………………… 31 Appendix G. Motor Speed Requirements ……………………………… 32 Appendix H. Chassis Cover Plate Stress Analysis …………………….. 33 Appendix I. Budget …………………………………………………… 34 Appendix J. Weight …………………………………………………… 35

VII

List of Tables

Table 1. Budget ……………………………………………………………………………………………………………………… 22

List of Figures

Figure 3A. Androbot final prototype ……………………………………………………………………………………… IV

Figure 4B. Androbot first prototype … …………………………………………………………………………………… IV

Figure 5. Basic Android platform ………………………………………………………………………………………….. 6

Figure 6. Speed formula ……………………………………………………………………………………………………….. 8

Figure 7. Electrical design ……………………………………………………………………………………………………… 9

Figure 8. User interface ………………………………………………………………………………………………………… 10

Figure 9. Schedule ………………………………………………………………………………………………………………. 21

1

1.0 Introduction

This purpose of this project is to design a small robot that is controlled by an internal

android-based cell phone that can take advantage of the multiple sensors on-board. The robot

will be able to be controlled by an application on a second cell phone. At a system level, the

robot prototype will consist of a 14.2 x 5.5 x 4.7 inches tank car which will be powered by an

android smartphone and at the same time be operated by a second wireless device. The

prototype, as mentioned before, will be using two android smartphones and the IOIO board for

the interface. As stated by SparkFun Electronics, “the IOIO (pronounced "yo-yo") is a board

specially designed to work with your Android 1.5 and later device. The board provides robust

connectivity to an Android device via a USB or Bluetooth connection and is fully controllable

from within an Android application using a simple and intuitive Java API - no embedded

programming or external programmer will ever be needed.” This project is being design by the

Androbot team which is composed of three mechanical engineers, a computer engineer, and a

double major in computer engineering and computer science. The robot will be designed by the

mechanical engineers while the electrical and software design will be designed by two computer

and electrical engineers. This project will use wireless communication to control the robot from a

specified distance and later on from anywhere in the world.

The idea behind our project is to use existing technology integrated in the smartphone to

do many of the robot functionalities. For instance, the Androbot team will be making use of

important features of the phones such as sensors and cameras to avoid obstacles collision, self-

balancing, temperature reading, and others.

In general the robot will consist of a 1.5’x1.5x1.5 mini box, and on top of this platform

we will be putting our IOIO board, which will be the microcontroller interface for external

2

devices, and the phone. One important goal of this project is to take advantage of the powerfully

computing power of these smartphone devices, and be able to implement a 10,000 dollars project

with less than 2000 dollars. As you can see, this project is the beginning of what will be a big

economic saving for our future technology researches.

1.1 Background

The Androbot project entailed designing a robot platform that would integrate cell phone

technology to use as its onboard computer. The intent of the project was to utilize as many of the

cell phones built in features and sensors as possible. The utilization of built in computing

capabilities and sensors were desired to provide an alternative means of fabrication for a robotic

platform that would possibly reduce the cost of fabrication.

A robotic platform was designed with implementation of a cell phone as its onboard

computer to accomplish the desired capabilities. The design was done for Dr. J Steven Hansen

and Dr. Byron Wood as a senior project to further the knowledge and understanding of cell

phone implementation capabilities for a robotic platform.

The results of design and analysis provided criteria for deciding on essential components

of the robotic platform design. Design components that were pertinent to analysis were the

selection of drive motors, method of dynamic leveling, battery selection, phone selection,

electronic component selection, and method of wireless communication for the robotic platform.

The design process for the Androbot project started by deciding on how to integrate the

computing power and built in sensors of a cell phone for a robotic platform. The dynamic

leveling system was decided to most significantly and simply demonstrate the ability of the

phone integration.

3

The secondary design approach that followed were determining the method of dynamic

leveling, drive for motion, mode of traction, mode of wireless communication, power source,

interface for payload, and chassis layout.

The dynamic leveling took into account linear actuators and servos. Servos were chosen

because their speed, accuracy, and space requirements optimized the dynamic leveling system

with respect to speed and space requirements. The linear actuators available for the project were

limited based on speed requirements and required too much space allotment from the chassis

layout. A gimbal system utilizing two servos offered the best space constraints and offered many

different servo options that met design requirements.

The drive motion for the robot was decided on by speed goals, power transmission

capabilities, power constraints, and weight constraints to be electric motors assemblies that

include a drive wheel. Hobby electric brushless motors were considered as a possibility due to

their minimal cost and optimal power output, but they require being geared down to transmit the

power to the drive wheels of the robot. Power drills were also considered as the drive source

because of their built in gearing, optimal power output, and availability. Power drills had

undesirable current draw, so due to power constraints they weren’t decided on. Time constraints

greatly drove the decision to go with prefabricated motor and drive wheel assemblies. If more

speed or torque is desired for future requirements hobby motors and power drills should be

reassessed as possible sources for drive motion for the robotic platform.

The mode of traction was decided to be bike tires tracks based on traction, weight, time,

and budget constraints. Bike chain treads assembled with bolts, nuts, and cut piping were

considered as a viable option due to their availability and tread dimension constraints. They

4

were decided against due to their extensive weight, and assembly time requirements. The Bike

tire option is more beneficial with respect to budget, time, availability, and traction constraints.

The mode of wireless communication was decided to be client-server based on the

capabilities, functionalities, and integration of Java language to handle sockets programming

over TCP/IP networks on the android platform. Ad-hoc mode was considered as a possible

solution for the communication because it easily allows a very effective peer-to-peer

communication between the two electronic devices avoiding the access points or routers. Ad-

Hoc has the minimum advantage with respect to the signal in a short range. However, it was

decided against due to its minimum documentation with android development. Additionally,

client-server has a fast and more efficient way of implementation over Ad-hoc.

The power supply was decided to use multiple off-the-shelf go-kart batteries in parallel.

The batteries are 12 volts, and two in parallel should provide more than enough power than

required. Other available batteries were prohibitively expensive, heavy, or costly to use to

achieve the equivalent effect and the go-kart batteries provide the best brute force and cost-

effective solution.

5

2.0 Review of Conceptual and Preliminary Design

2.1 Identified Need The clients Dr. Steven Hansen, a professor in the MAE, and Dr. Byard Wood,

mechanical and aerospace engineering head department, desire to take advantage of the cell

phone computing power in the design of a robot platform for modular payloads for future senior

design teams.

Often many important projects are not being implemented because of the high cost that

they involve. Many of these projects have the goals of improving or solving social needs but due

to economic reasons, they have not been built.

The design and implementation of this project will contribute to have a very efficient

package delivery system, a big push in technologic, and many other contributions.

2.2 Problem Definition

This robot as mentioned before will involve three different fields which are mechanical,

electrical, and software. The robot prototype will consist of a small tank car platform which has

the dimensions 14.2 x 5.5 x 4.7 inches and weighs around 2 lbs. An android smartphone will be

place on top of the car platform, and a second cell phone will be used to control the phone on the

robot. The interface between the smartphone and the actual robot prototype will be the IOIO

board which interprets the cellphone commands and control the peripheral devices like the

actuators and any other payload that might be added to the design.

The prototype will be drive by tanks treads which will allow moving forward, backward,

and turning left and right. The prototype will have a payload up to 1 lb. It will also be able to

6

navigate outdoors terrain (pavement, gravel, and grass). Figure 1 gives a better illustration of

how this prototype would look like.

The electrical connections of the

prototype will be as follow: A wireless

connection between controlling phone to the

controlled phone to the IOIO board, from

the IOIO board to the control signal processing which will be driving the peripherals, and from

the controls signal processing to the actuators.

The user will be able to control the robot with an android application or some sort of

wireless device like a remote computer or cellphone. For the purpose of our design, we will need

a smartphone capable of running Android 4.0 operating system or above.

The two phones will be program to follow the design requirement or client specifications

for our case. In other words, the robot will be programmed to avoid obstacle move through

pavement, and response to the external sensing from the smartphones features.

2.3 Mechanical Requirements

• Weight: less than 50 lbs.

• Size: less than 1.5’x1.5’x1.5’

• Module interface for payload

• Payload to withstand up to 5 lbs.

• Budget $3000

• Forward and backward motion

• Able to turn left and right

• Tilt sensing with dynamic leveling in all directions for equilibrium up to ±10°

Figure 10. Basic Android platform

7

• Capable of navigating outdoors terrain

2.4 Electrical Requirements

• Wireless communication

• Power: Rechargeable off-the-shelf battery

• 15 minutes active use

• 24 hours stand by use

• Maximize power allotment for payload

• Communication interface for payload

• Use IOIO board

2.5 Software Requirements:

• On Board Cell phone runs Android 4.0 or greater

• User Interface Cell phone runs Android 1.5 or greater

• IOIO libraries, IOIO firmware, and IOIO boot loader

• Android application for control of robot

8

3.0 Basic solution

Our team’s objective is to create a low, wide, track based robot platform that will provide

power and a cell phone interface for a functional module, and to design one module for the

platform.

Some of the future goals of this prototype are to operate either manually or autonomous.

As already said before, we are planning to control this device wirelessly. The main goal of this

project is to be able to wirelessly control the robot powered by a potential smartphone.

3.1 Software system for cellphones

For this project, we will be using Google open source operating system Android. The

software packages include a very good programming development environment to help the

software engineers be more efficient. The advantage of using this free operating system will be

the rich tools that it comes with such as the multiple built-in libraries.

4.0 Design of system component

The designs of the different components of this project were chosen through a set of calculation

and analysis.

4.1 Mechanical Design

Figure 2 shows the analysis that we

went to accomplish the speed which

the tank required.

Figure 11. Speed formula

9

All the calculations are taking in consideration the physical phenomenon.

4.2 Electrical system conceptual design

For the electrical several components were analyzed to accomplish our last design. The main

device of the electrical system of

the circuit started with the on

board cellphone. The on board

cellphone will gives the

computing power that the robot

needs. For instance, the on board

cell phone will be responsible for manipulating the commands of the system. Following the on

board cell phone, we have the IOIO board connected to the cell phone through USB. The IOIO

board is responsible for interpreting the on board cellphone commands and converting those

commands to a very low level language. The low level language or machine language is the way

the IOIO board communicates with the h-bridges. The h-bridges are the controllers used to

manipulate the drive motors and the servo motors. The way we are handling the motion of the

prototype is with two DC motors which are responsible for the displacement of the robot. The

leveling system of the robot is being simulated with a 4 set of LED packages. Finally, the whole

power of the system is being provided by 12 DC volts power supply. The advantage of designing

with the IOIO board is that the input voltage for the IOIO is between the ranges of 5V to 15V.

Therefore, we do not need a voltage regulator for the system. However, we included one for a

better performance of our chips. See figure 3 for a better understanding.

Figure 12. Electrical design

10

4.3 Software system design

The software system of the project is one of the most completed systems. The reason why the

programming of the project is challenging is because we are mixing 3rd party software. In other

words, we are working with the IOIO libraries and methods, android operating system, and the

Java programming language. All three of them are developed by different companies. However,

you do not need to panic because the storm has already passed. Once you figure out the little

trick of this software, the programming come so natural.

4.3.1 On board cellphone program

In the on board cellphone is where 80 percent of the programming is being done. The design of

program is based on multithreading and data sharing. The program is dividing on threads

according to the platform. For instance, the IOIO board has its own threads which are started

every time the IOIO is connected to the cellphone, and the java threads are started as soon as the

application is being launched.

4.3.2 GUI program

The graphical user interface is relatively easy compare to the on board cellphone program. The

main purpose of this application is to send the user commands and to display the onboard

cellphone features information such as

the accelerometer and proximity

sensors. The design of the GUI is built

to be very user friendly. The reason

behind it is that we want anyone from

Figure 13. User interface

11

any country or any culture could understand how to operate the system in a few seconds. Figure

4 gives you a good illustration of this design.

5.0 Implementation and final approach

The design problems that were analyzed for the Androbot project were the motor torque, chassis

top plate stress, angular velocity and torque of servos for dynamic leveling, voltage draw, and

current draw from battery cells.

For control of the robot, an android phone and an IOIO board were selected to provide

logical control signals, programming and interfacing. Use of the phone is a fundamental

requirement of the project, and the IOIO board is the best and only real option for interfacing to

the rest of the robot. The only other alternative to the IOIO board would be to “crack” the

android phone and hijack or repurpose existing control signals. This method is highly

undesirable for two main reasons; firstly it greatly reduces phone reliability and overall system

reliability. Secondly, it requires that the internal control signals of the phone need to be mapped

without the use of proprietary documentation of the internal mechanisms of the phone. A feat

that is not entirely guaranteed to be successful and potentially costly as it may destroy the phone

nor cost-effective in terms of time.

The motor torque was determined by first designating a diameter for the drive wheel of

the robot. To optimize the desired speed goal, the diameter of the drive and front wheels needed

to be maximized. Dividing the length constrains into three sections for the wheels, and leaving

some buffer room for adjustments, a six inch diameter was chosen for the front and drive wheels.

Once the wheel diameter and velocity of the robot where derived, the force to move the robot on

a 20° incline was calculated based on the maximum weight constraints of the robot. From the

force requirements derived, the minimum torque was calculated to move the robot under most

12

demanding design requirement conditions of maximum weight and 20° incline. The maximum

torque was calculated based on the maximum weight and incline to prevent the robot from

flipping over. For torque calculations reference appendix F.

For the chassis top plate a stress analysis was done to derive criteria to choose a material

and thickness that will be able to withstand the stress on it do to the leveling system and module.

To be able to analyze the stresses on the top plate a finite element program called FEMAP was

used. Static and dynamic conditions were evaluated for the stress on the top chassis plate. Static

conditions assumed a module and dynamic leveling system consisting of 15 pounds. The

dynamic evaluation of the stresses was based on the 15 pounds of the module and leveling

system being acted on by the initial forward or backward acceleration of the robot causing a

moment arm to produce stress concentrations at either the front or back screw mounts. To

ensure significant strength and limit vibrations for current design and to provide a contingency

for unknown future modules 18 gauge steel was selected. For results reference appendix G.

To determine the criteria for the dynamic leveling system a minimum servo speed and

minimum torque were calculated based on the goal speed of the robot and module weight

requirements. The time for the robotic platform to go from a level platform to a 20° incline at 5

mph was calculated. The 20° required for it to translate was divided by the time derived

resulting in the minimum angular velocity requirements of the servos. The torque requirements

for the servos were calculated by taking into account the distance from the axis of rotation of the

servo to the center of mass of the module. For calculations reference appendix E.

A voltage of 12V was selected as the highest power supply signal in the robot, as it works

well with motors and other elements of the electronics, this became a self-imposed minimum

requirement on the batteries. The power supply decision was based on a selection of batteries

13

ranging from small efficient nickel-metal hydride cells to large high capacity lead-acid batteries.

The major factors that were considered: minimum voltage that could drive the main drive

motors, total power density, cost, and weight. The battery pack decided on is a dual lead-acid go-

kart pack for its 12 volts, high mW-hr capacity, low cost, and low overall “battery-pack” weight.

A “battery-pack” is loosely defined as an equivalent pack of numerous smaller batteries. For

example, the nickel metal-hydride cells had the best power density, but creating a pack of them

that would give 12 volts and sufficient mW-hrs would require 27 cells, with a much greater

weight and much greater cost, an order of magnitude more than the go-kart batteries. One

undesirable, yet manageable factor is the fact that the go-kart batteries are lead acid. Lead acid

has a non-linear power density dependency on temperature and current draw, also the failure

mode of lead acid batteries can potentially be catastrophic. These factors are manageable because

the battery is sealed, and that two batteries in parallel will have more than enough mW-hrs even

in the worst-case non-linear scenario.

For control of the robot, an android phone and an IOIO board were selected to provide

logical control signals, programming and interfacing. Use of the phone is a fundamental

requirement of the project.

On the software implementation a new approach was found during the early design and

implementation of the code. The onboard program is being implemented using multi-threading

method. The idea is to be running a background thread which will be doing the server constant

operation of the system. The thread sever is started on the launching of the application. Then it

sits there listening to the client which is the phone with the user interface application. When the

onboard program is running, the background thread is continuously waiting for a client request.

As soon as any communication is establish between the two phones, then the sever thread reads

14

any incoming commands or message from the user. The server thread is responsible for

interpreting and updating the commands. The commands are being shared for all the threads in

the program. The reason why the commands are global is to allow easy sharing, and it is very

important to know that the IOIO thread does not respond to concurrency. Therefore, the IOIO

thread needs to have access to a global variable to respond to the user commands. Moreover, the

IOIO thread is started when the USB connection between the phone and the IOIO board is made.

On the other hand, the user interface application is being implementing through a thread and

listeners. In this side of the system, all the buttons or any other external interface are being

handled by listeners. We also have the client thread which is sending all the user inputs to the

server. The reason why we designed the program this way is to simulate what we know parallel

programming.

15

6.0 Design Results

For the Androbot project many different things were looked at to make sure that it met

design requirements. One of the major issues was to figure out how to design the leveling system

on top of the robot. The first design had 4 linear actuators holding up a plate. There were many

flaws with this design. The first flaw was the linear actuators were to slow. If the robot hits a

20° slope at 5 mph the leveling system needs to be able to level itself at 146.67° per second,

reference appendix E for calculations. Another problem was that the linear actuators required a

lot of space allotment from the chassis. The last problem with the linear actuators was the

programming. Programming the linear actuator with no feedback would have been very difficult

and time consuming. Encountering all these challenges a different design was sought out. A

design using servos in a gimbal system that dynamically levels the platform was investigated.

This approach only required 2 servos, and it greatly decreased the size of the leveling system on

top of the robot. Another major advantage the servos had over the linear actuators was the

response time, servos had response times quicker than needed, and had feedback which reduces

the difficulty of coding for the leveling system. Servos were the clear way to go with the

dynamic leveling system, because they had the speed we needed, reduced the space allotment for

the dynamic leveling system, and made the coding a lot simpler.

Another major aspect of the robot was deciding what motors to use. The first thing to do

was figure out what kind of power was needed from the motors. For the calculations of the

torque required reference appendix F, and for the motor power calculations reference appendix

G. Many different options for motors ranging from drills, to remote control cars were analyzed.

Many of the motors had the power needed, but not all of them had the torque needed, because

most of the motors were not geared. The motors that were decided on are pre-built mount and

16

wheel kit motors. The main reason for this decision was they were already made and geared, so it

didn’t require designing and creating a gear box which would have taken a lot of time. For a

table of motor options considered reference appendix B.

One other place that required particular attention to was the top plate of the robot,

because it is where the leveling system with module will be attached to the robot. This area was

analyzed to make sure it would be able to withstand the stresses placed on it. For the analysis of

the top plate a finite element program was used to analyze the stresses on the plate. A model was

done in FEMAP to simulate the static and dynamic loads placed on the plate and the stresses

caused from them. For FEMAP models of stresses on top plate reference appendix H. After

analyzing the stresses on the top plate in FEMAP an 18 gage steel was selected to be strong

enough to withstand the leveling system and other modules that can be placed on top of the

leveling system without the top plate failing.

The box that houses the onboard phone was an important consideration that was

analyzed. The first idea was to make the box out of metal, but it was realized that that would

cause a faraday cage inhibiting electrical signals from getting in or out of the box. This prevented

the design with a metal box to accomplish the requirement for wireless communication. To

overcome this problem designs consisting of non-metallic materials were to be analyzed to

determine what would be able to withstand the stresses of mounting a module to it. The idea for

a box done by rapid prototyping was proposed, but due to lack of information on the physical

properties of the rapid prototyping material a stress analysis would have been inconclusive. The

decision to design the phone-housing box by rapid prototyping was based off of intuitive

inspection of the rapid prototyping material first hand. It was determined that it would likely be

able to withstand the stresses acting on it. The design of the box was optimized to withstand

17

maximum stresses by placing the bolt holes on the outside of the box. It was also determined

that the box would be built and tested early to ensure its ability to accomplish the requirements

of holding up the module. If the design fails it would be reevaluated and solutions such as

increasing the thickness of the box, or reinforcing the box will be designed, built, and tested.

The IOIO board is the best and only real option for interfacing to the rest of the robot.

The only other alternative to the IOIO board would be to “crack” the android phone and hijack or

repurpose existing control signals. This method is highly undesirable for two main reasons;

firstly it greatly reduces phone reliability and overall system reliability. Secondly, it requires that

the internal control signals of the phone need to be mapped without the use of proprietary

documentation of the internal mechanisms of the phone. A feat that is not entirely guaranteed to

be successful and potentially costly as it may destroy the phone nor cost-effective in terms of

time.

The power supply decision was based on a selection of batteries ranging from small

efficient nickel-metal hydride cells to large high capacity lead-acid batteries. The major factors

that were considered: minimum voltage that could drive the main drive motors, total power

density, cost, and weight. The battery pack decided on is a dual lead-acid go-kart pack for its 12

volts, high mW-hr capacity, low cost, and low overall “battery-pack” weight. A “battery-pack” is

loosely defined as an equivalent pack of numerous smaller batteries. For example, the nickel

metal-hydride cells had the best power density, but creating a pack of them that would give 12

volts and sufficient mW-hrs would require 27 cells, with a much greater weight and much greater

cost, an order of magnitude more than the go-kart batteries. One undesirable yet manageable

factor is the fact that the go-kart batteries are lead acid. Lead acid has a non-linear power density

18

dependency on temperature and current draw, also the failure mode of lead acid batteries can

potentially be catastrophic. Reference appendix A, for battery trade study.

Another discussion of the group was to decide which phones to use. The phones decision

was made on what phones are carrying the latest android operating system. Having the latest

version of android would guarantee that it would have the most recent built in libraries. Most of

the android libraries will help the programmers to be more efficient and creative. It is also

important to remark that the phones decision was also influenced by the phone hardware

features. One of the main requirements of this project is to be able to have a device, which

integrates as many features as we need for the project. Therefore, we need to pick a phone that

can help us to meet our requirements and leave the door open to work in our future goals.

Reference appendix D, for the phone trade study.

On the software implementation a new approach was found during the early design and

implementation of the code. The onboard program is being implemented using a multi-threading

method. The idea is to be running a background thread which will be doing the server constant

operation of the system. The thread sever is started on the launching of the application. Then it

sits there to literately listen to the client, which is the phone with the user interface application.

When the onboard program is running, the background thread is continuously waiting for a client

request. As soon as any communication is establish between the two phones, then the sever

thread reads any incoming commands or messages from the user. The server thread is

responsible for interpreting and updating the commands. The commands are being shared for all

the threads in the program. The reason why the commands are global is to allow an easy sharing,

and it is very important to know that the IOIO thread does not respond to concurrency.

Therefore, the IOIO thread needs to have access to a global variable to respond to the user

19

commands. Moreover, the IOIO thread is started when the USB connection between the phone

and the IOIO board is made.

On the other hand, the user interface application is being implementing through a thread and

listeners. In this side of the system, all the buttons or any other external interface are being

handling by listeners. We also have the client thread which is sending all the user inputs to the

server. The reason why we designed the program this way is to simulate what we know parallel

programming.

7.0 Project Management

Our team consists of two senior engineers, Nathan Wong and Wington Brito, who are

very motivated and experienced in their respective field. Nathan Wong is a computer engineer.

He will be responsible for the electrical design and implementation of the project. He also has

the programming skills and experiences to help the project be completed by the end of this

semester, Spring 2012. The other engineer is Wington Brito. He is a double major in computer

engineering and computer science. He will be responsible for the software design and

implementation of the project. Mr. Brito has very good experience working on different software

engineering projects using object oriented languages; for instance, a blokus game and a cyclist’s

club system. As you could imagine, the programming of this project will be very intense, but the

engineers in the team have qualifications and experience to approach it and complete it.

Tasks

Our team will perform the following tasks:

1- Research which will be completed by Wington Brito

20

1.1 Understand how android devices operate

1.2 Download and get the required software

1.3 Learn from similar projects

2- Robot prototype (Tank car) which will be completed by Nathan Wong

2.1 Draw out the entire system diagram

2.2 Draw all the different possibilities

3- Electrical assembly which will be completed by Nathan Wong and Wington Brito

3.1 Connect the necessary electrical devices such as IOIO board and the phone

3.2 Have the entire electrical diagram

4- Programming which will be completed by Nathan Wong and Wington Brito

4.1 Software requirements

4.2 Class diagrams

4.3 Coding

4.4 Be able to have a nice user interface

21

This is our Work Breakdown Structure:A Gantt chart would be better. What are your deadlines

for accomplishing your tasks.

22

7.1 Budget

Below is a table that shows or our expenses in the project.

Cost/Unit Units Total Cost

Electrical Batteries $21.95 3 $65.85

misc electronics $70.00 1 $70.00

Mechanical Motors $300.00 1 $300.00

wheels $20.00 4 $80.00

axles $2.00 4 $8.00

Treads $20.00 2 $40.00

servos $154.00 2 $308.00

misc leveling $100.00 1 $100.00

Chasis $500.00 1 $500.00

Hardware $100.00 1 $100.00

Track $20.00 2 $40.00

Computer Phone $380.00 1 $380.00

Phone 2 $350.00 1 $350.00

Total Cost $2,341.85

Buffer $658.15

23

8.0 Summary and Conclusions

The Androbot project entailed designing a robot platform that would integrate cell phone

technology to use as its onboard computer. The intent of the project was to utilize as many of the

cell phones built in features and sensors as possible. The utilization of built in computing

capabilities and sensors was desired to provide an alternative means of fabrication for a robotic

platform that would possibly reduce the cost of fabrication.

The results of design and analysis provided criteria for deciding on essential components of the

robotic platform design. Design components that were pertinent to analysis were the selection of

drive motors, method of dynamic leveling, battery selection, phone selection, electronic

component selection, and method of wireless communication for the robotic platform.

8.1 Mechanical Requirements

• Weight: less than 50 lbs. .............................................................................................. 47 lbs

• Size: less than 1.5’x1.5’x1.5’ ..........................................................................1.5’x1.5’x1.2’

• Module interface for payload .......................................................................................... Yes

• Payload to withstand up to 5 lbs. .................................................................................... Yes

• Budget $3000 ..........................................................................................................$2341.85

• Forward and backward motion ....................................................................................... Yes

• Able to turn left and right................................................................................................ Yes

• Tilt sensing with dynamic leveling in all directions

with equilibrium up to ±10° ....................................................... = 999 oz in

• Capable of navigating outdoors terrain .........................................................Yes, Bike Tires

24

8.2 Electrical Requirements:

• Wireless communication ........................................................................................... Ad-Hoc

• Power: Rechargeable off-the-shelf battery ..................................................................... Yes

• 15 minutes active use ................................................................................................. 25 min

• 24 hours stand by use ...................................................................................................... Yes

• Maximize power allotment for payload .......................................................................... Yes

• Communication interface for payload ........................................................... Yes, USB Hub

• Use IOIO board ............................................................................................................... Yes

8.3 Software Requirements:

• On Board Cell phone runs Android 4.0 or greater .......................................................... Yes

• User Interface Cell phone runs Android 1.5 or greater ................................................... Yes

• IOIO libraries, IOIO firmware, and IOIO boot loader.................................................... Yes

• Android application for control of robot ......................................................................... Yes

If more time were available for the project a design process for a gear box would be done to

minimize the cost, maximize the output, and achieve the goal speed of the drive motors by

selecting electric brushless hobby motors for the drive motors, or possibly modifying electric

drills to use as the drive motors. A module would be selected, designed, and functionally

implemented. The method for the wireless communication would be reevaluated and decided on

based on different time constraints. Later on, we would also integrate the abilities to have the

robot to operate in auto-mode. As describe before we would like to use most of the cell phones

features. In order to accomplish such goal, we would need to integrate some external proximity

sensors, because the cell phone proximity sensor is very limited for the protection and well

functionality of the Androbot. Phone placement and mounting would be reconsidered to allow

25

for the camera and impact sensor to be utilized while still providing dynamic leveling. The

chassis material and thickness would be reevaluated based on module implementation, torque,

and impulse of the drive motors not currently known.

26

Appendix A.

Battery Trade Study

Battery Volts mAh kJ/unit

Weight(batt only,lbs) $/mJ

Enegy Density kJ/lb

Cost/unit (batt only)

Cost/drill combo

D Cell (flattop)* 1.2 10000 3.33 0.362 3.14 9.22 $10.45D Cell * 1.2 10000 3.33 0.362 2.31 9.22 $7.709 Volt Cell* 8.4 200 0.47 0.041 9.32 11.50 $4.35PT-0990** 9.6 1500 4.00 1.500 6.23 2.67 $24.90PT-0990** 9.6 2000 5.33 1.500 6.54 3.56 $34.90PT-1000** 12.0 1500 5.00 1.500 5.79 3.33 $28.95PT-1010** 12.0 2400 8.00 1.500 5.74 5.33 $45.95PT-0315** 12.0 1500 5.00 1.500 5.19 3.33 $25.95EVX12340 CSB(golf cart) 12.0 34000 113.33 29.500 0.68 3.84 $77.57Razor Ground Force (go cart) 12.0 8000 26.67 4.960 0.90 5.38 $23.95Genesis Cordless Drill***

18.0 1100 5.50 0.500 3.63 11.00 $19.99 39.99

*economies of scale, for multiple per purchase **other comparable brands V*1000*mAh = Wh Wh/60/60 = Ws = Joule Joule/lb = power density

27

Appendix B.

Motor Trade Study

MOTORS Cost<$150480 W 213.8 g 35.8 mm $23.32 1200 rpm480 W 0.471348317 lbs 1.409449 in $23.32 15120 rp

165 g 35.8 mm $28.47 4300 rpm0.363762733 lbs 1.40945 in $28.47 4300 rpm

2600 W 374 g 39.8 mm $59.00 2150 rpm2600 W 0.824528861 lbs 1.566929 in $59.00 49450 rp1600 W 370 g 35.8 mm $36.15 2800 rpm1600 W 0.81571037 lbs 1.40945 in $36.15 35280 rp1800 W 449.2 g 44 mm $60.15 2400 rpm1800 W 0.990316482 lbs 1.732283 in $60.15 40320 rp2200 W 535 g 44 mm $69.50 1600 rpm2200 W 1.1794731 lbs 1.73228 in $69.50 26880 rp

341 g 42 mm $159.99 2050 rpm0.71875 lbs 1.65 in $159.99 2050 rpm

300 W 128.6 g 35.8 mm $23.80 2200 rpm300 W 0.283514469 lbs 1.40945 in 23.8 27720 rp

1200 W 280 g 35.8 mm $32.20 810 rpm1200 W 0.617294334 lbs 1.40945 in $32.20 13608 rp

GEARED MOTOR

KITS1.45 w/ wheel lbs $300.00 – 2 13.1034 rpm1.45 w/ wheel lbs $150.00 190 rp

Redline T8 1/8th Scale 380-30T Brushless 540L-26T Brushless

Mount and Wheel Kit

Tacon 540XXL g EZRUN-CRAWLER-Tacon Brushless 540XL-6T Brushless 8T Brushless

Power>200W Weight<1 lb Diameter<2 in 200<rpm

9T Brushless

28

Appendix C.

Servo Trade Study

GWS S689-2BB/MGWS S777C 1501MG HSR-5980SG HSR-5995TG HS-7955TG HS-7945T

Torque > 240 oz-in 416 oz-in 583 oz-in 240 oz-in 417 oz-in 417 oz-in 333 oz-in 319.4 oz- Price < $200 $39.95 $59.95 $19.95 $109.99 $124.99 $93.99 $139.99Digital/Analog Analog Analog Analog Digital Digital Digital Digital

Steel Gears Titanium Gears Titanium Gears Titanium G

29

Appendix D.

Phone Trade Study

Requirements G1 Nexus OneNexus S Droid X Nexus PrimeAndroid Vers 1.6 2.3 2.3** 2.3** 4Ram 192 MB 512 MB 512 MB 512mb 1 GBMemory 256 MB 512 MB 16GB 6.6 GB 16/32 GBCPU 512MHz 1GHZ 1GHZ 1GHz Dual 1.2GHzTalk Time 5H 20Min 7 H 6 hours 8 H 17 h 40 minStand By Time 406 250 428 hours 220H 290 hCamera 3.15 Mpx 5.0 Mpx *5.0 Mpx 8 Mpx 5 Mp, 1.3 MpBlue Tooth x x X x xGyroscope X xAccelerometer x x X x *xUSB 2.0 2.0 2.0 2.0 2barometer xGPS x x X x xCost (approx) 125$(used225-250$(u240-250$(u120-150(us650-7xx

*has additional front facing 0.3 Mpx camera

**can be upgraded to android 4.0

Appendix E.

30

Angular Speed of Platform Calculations

Appendix F.

31

Torque Calculations

Appendix G.

32

Motor Speed Requirements

33

Appendix H.

Chassis Cover Plate Stress Analysis

34

Appendix I.

Budget

Cost/Unit Units Total CostElectrical Batteries $21.95 2 $43.90

Misc electronics $120.00 1 $120.00Mechanical Motors $300.00 1 $300.00

Wheels $10.00 4 $40.00Mounting $30.00 1 $30.00Treads $20.00 2 $40.00Servos $157.50 2 $315.00Misc leveling $100.00 1 $100.00Chasis $500.00 1 $500.00Hardware $100.00 1 $100.00

Computer Phone $380.00 1 $380.00Phone 2 $350.00 1 $350.00

$2,318.90$681.10

Total CostBuffer

35

Appendix J.

Weight

Weight/Unit(lbs) Units

Mechanical Motors 3.2 2 6.4 lbsServos 0.4 2 0.8 lbsPhone box 0.5 1 0.5 lbsLeveling 2 1 2 lbs40 nuts 1 1 1 lbs40 bolts 1 1 1 lbs40 washers 1 1 1 lbsChassis 10 1 10 lbsWheels 1 4 4 lbsTracks 1.5 2 3 lbs

Electronics Batteries 5 2 10 lbsPhone 0.3 1 0.3 lbsMisc 1 1 1 lbs

41 lbs9 lbs

Total weight

Weight

weight buffer