Wington Brito, Nathan Wong [email protected] [email protected] 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