Applications of Robotics: A Quadrupedal Robotic

Solution to Aid in Search and Rescue Operations

Alfred W. Martinez III Kristian Ornelas Edgar Granados Marcus Huston

Electrical Engineering Electrical Engineering Computer Engineering Computer Engineering
California State University, California State University, California State University, California State University,
Sacramento Sacramento Sacramento Sacramento
alfredmartinez555@[Link] krisornelas85@[Link] edgargranados153@[Link] marcushuston@[Link]
 Table of Contents
Executive Summary ........................................................................................................................................................................vi
I. Introduction .............................................................................................................................................................................1
II. Societal Problem ......................................................................................................................................................................2
A. Fall/Spring Societal Problem ................................................................................................................................................2
1) Introduction ......................................................................................................................................................................2
2) Natural/Non-Natural Disaster Statistics ...........................................................................................................................2
3) Search and Rescue Statistics ................................................................................................................................................5
4) Current Safety Equipment Needs .........................................................................................................................................5
5) Possible Solutions ................................................................................................................................................................ 8
6) Societal Problem Conclusion .............................................................................................................................................. 10
III. Design Idea ............................................................................................................................................................................. 10
A. Fall Design Idea .................................................................................................................................................................. 10
B. Spring Design Idea ............................................................................................................................................................. 12
IV. Funding ................................................................................................................................................................................... 13
A. Mechanical Aspects ............................................................................................................................................................ 13
B. Electrical Aspects ............................................................................................................................................................... 14
V. Project Milestones.................................................................................................................................................................. 14
A. Cardboard Model ................................................................................................................................................................ 14
B. 3D Printed Prototype (Part 1) ............................................................................................................................................. 14
C. 3D Printed Prototype (Part 2) ............................................................................................................................................. 16
1) Walking Gaits and Locomotion ..................................................................................................................................... 17
D. 3-Phase Brushless DC Motor Control ................................................................................................................................ 18
E. Battery Management System .............................................................................................................................................. 19
F. ODrive Development and Interfacing ................................................................................................................................ 20
G. PID Controller Implementation .......................................................................................................................................... 21
H. 3D Point Cloud Generation ................................................................................................................................................ 22
I. Implementation of Feedback Sensors ................................................................................................................................. 22
1) Inertial Measurement Unit ............................................................................................................................................. 22
2) Time-of-flight Sensors ................................................................................................................................................... 24
3) Rotary Encoders ............................................................................................................................................................. 24
4) Long Range Communication/Camera ............................................................................................................................ 24
J. Full-Scale Model Leg Prototype......................................................................................................................................... 25
VI. Work Breakdown Structure ................................................................................................................................................. 25
A. Brief Description ................................................................................................................................................................ 25
B. Work Breakdown Structure Diagram ................................................................................................................................. 25
C. List of Tasks & Hours Invested .......................................................................................................................................... 25
VII. Risk Assessment ..................................................................................................................................................................... 26
A. Lack of Technical Experience ............................................................................................................................................ 26
1) Risk Description ............................................................................................................................................................. 26

i
 2) Mitigation Techniques ................................................................................................................................................... 26
B. Embedded System Development Time .............................................................................................................................. 26
1) Risk Description ............................................................................................................................................................. 26
2) Mitigation Techniques ................................................................................................................................................... 26
C. Scheduling Conflicts with Mechanical Engineering Team & Schoolwork ........................................................................ 26
1) Risk Description ............................................................................................................................................................. 26
2) Mitigation Techniques ................................................................................................................................................... 26
D. COVID-19 / Campus Closure ............................................................................................................................................. 27
1) Risk Description ............................................................................................................................................................. 27
2) Mitigation Techniques ................................................................................................................................................... 27
VIII. Design Philosophy ............................................................................................................................................................. 27
A. Brainstorming Philosophy .................................................................................................................................................. 27
B. Prototyping Philosophy ...................................................................................................................................................... 27
IX. Deployable Prototype Status ................................................................................................................................................. 28
A. Brief Description ................................................................................................................................................................ 28
B. Prototype Performance ....................................................................................................................................................... 28
1) Inertial Measurement Unit Performance ........................................................................................................................ 29
2) Brushless DC Motor Performance ................................................................................................................................. 30
3) Time of Flight Sensor Performance ............................................................................................................................... 31
X. Marketability Forecast .......................................................................................................................................................... 32
A. Increase Marketability Discussion ...................................................................................................................................... 32
B. Necessary Changes for Manufacturing ............................................................................................................................... 33
1) Hardware ........................................................................................................................................................................ 33
2) Software ......................................................................................................................................................................... 33
3) Construction ................................................................................................................................................................... 33
XI. Conclusion .............................................................................................................................................................................. 34
References ...................................................................................................................................................................................... 34
Glossary .......................................................................................................................................................................................... 35
Appendix A. User Manual ......................................................................................................................................................... A-1
Appendix B. Hardware ............................................................................................................................................................... B-1
Appendix C. Software ................................................................................................................................................................ C-1
Appendix D. Mechanical Aspects .............................................................................................................................................. D-1
Appendix E. Vendor Contacts .................................................................................................................................................... E-1
Appendix F. Resumes .................................................................................................................................................................. F-1

ii
 Table of Figures:

Figure 2.1. Number of wildfires and acres burned in the U.S. from 1988 to 2017. Reprinted from “Wildfire Statistics.” ...............2
Figure 2.2. Top five years with the largest number of acres burned since 1960 in U.S. ...................................................................3
Figure 2.3. Burned/Unburned mapping of Pedrógão Grande in 2017 ...............................................................................................3
Figure 2.4. Map of historic earthquakes since 1769 ..........................................................................................................................4
Figure 2.5. 2011 Tohoku earthquake epicenter map ..........................................................................................................................4
Figure 2.6. Global tsunami events from 1890 to 2010.......................................................................................................................4
Figure 2.7. Annual percentage of flood peaks in the Easter United States ........................................................................................5
Figure 2.8. Potential Areas with High Risk of Wildfires. ..................................................................................................................6
Figure 2.9. Number of Natural Disasters from 1900- 2018 ...............................................................................................................7
Figure 2.10. End of Year Cost of Disaster Relief ..............................................................................................................................8
Figure 2.11. KOHGA3 Ground Robot for Search and Rescue and Vacant Building Inspection .......................................................8
Figure 2.12. Robot Snake, Biorobotics Laboratory Carnegie Mellon University ..............................................................................8
Figure 2.13. Boston Dynamics’ SpotMini .........................................................................................................................................9
Figure 2.14. Honda’s Asimo ..............................................................................................................................................................9
Figure 2.15. Thermite Fire Fighting Robot ........................................................................................................................................9
Figure 2.16. Prescribed fire in eastern Washington, United States .................................................................................................. 10
Figure 2.17. Firefighting Drone ....................................................................................................................................................... 10
Figure 2.18. Disaster Relief Drone .................................................................................................................................................. 10

Figure 3.1 Small Scale CAD Model of Robotic Dog ...................................................................................................................... 11

Figure 3.2 Small Model Joint Placement Diagram .......................................................................................................................... 11
Figure 3.3 Small Model Prototype Design ...................................................................................................................................... 11

Figure 5.1 Small Cardboard Model Prototype ................................................................................................................................. 14

Figure 5.2 Construction of the 3D Printed Small Model ................................................................................................................ 14
Figure 5.3 Diagram representation of our 12 Servo Dog ................................................................................................................. 15
Figure 5.4 3D Printed Small Scale Dog Model ............................................................................................................................... 15
Figure 5.5 STM32 Nucleo Board .................................................................................................................................................... 15
Figure 5.6. STM32 Cortex M4 Specifications ................................................................................................................................. 15
Figure 5.7 STM Nucleo Board Pinout ............................................................................................................................................. 16
Figure 5.8 2D Inverse Kinematic Nonlinear Equations ................................................................................................................... 17
Figure 5.9 Gait Cycle ....................................................................................................................................................................... 17
Figure 5.10 End-Effector Ellipse ..................................................................................................................................................... 17
Figure 5.11 Robotic Gaits ................................................................................................................................................................ 18
Figure 5.12 3-Phase BLDC Theory ................................................................................................................................................. 18
Figure 5.13 Turnigy Aerodrive SK3 Brushless DC Motor Efficiency: Rotational Accuracy Chart ................................................ 19
Figure 5.14 6 Volt Lead Acid Battery ............................................................................................................................................. 19
Figure 5.15 22.2 Volt Li-Po Battery ................................................................................................................................................ 20
Figure 5.16 Turnigy Aerodrive SK3 Brushless DC Motor .............................................................................................................. 20
Figure 5.17 The ODrive Motor Controller v.3.5 ............................................................................................................................. 21
Figure 5.18 Different Communication Protocols ............................................................................................................................. 21
Figure 5.19 SPI Communication Protocol ....................................................................................................................................... 21
Figure 5.20 MATLAB 3DOF System ............................................................................................................................................. 21
Figure 5.21 ORB-SLAM2 Point Cloud Map Example .................................................................................................................... 22
Figure 5.22 ROS Node Graph Example .......................................................................................................................................... 22
Figure 5.23 9DOF IMU ................................................................................................................................................................... 23
Figure 5.24 IMU Angular Velocity Calculation Process ................................................................................................................. 23
Figure 5.25 A look into the MPU6050 and the different readings it takes at different axes. ........................................................... 23
Figure 5.26 TOF Sensor Application ............................................................................................................................................... 24

Figure 9.1 MPU6050 IMU .............................................................................................................................................................. 29

Figure 9.2 MPU6050 Register Map ................................................................................................................................................. 29
Figure 9.3 IMU #1 X-Axis Rotation Filtered versus Unfiltered ...................................................................................................... 30
Figure 9.4. IMU #2 X-Axis Rotation Filtered versus Unfiltered ..................................................................................................... 30
Figure 9.5 CPR/10th of Second & RPM Comparison ..................................................................................................................... 31
Figure 9.6 VL6180X........................................................................................................................................................................ 31
Figure 9.7 TOF Sensor Testing Procedure (Top-View) .................................................................................................................. 32

iii
 Table of Tables:
Tab. 2. 1 Table format of Fig. 2.1 Forest Service (FS) and Department of Interior (DOI). ............................................ 2
Tab. 2. 2 Number of personnel and losses for FS and DOI ............................................................................................ 3
Tab. 2. 3 Worldwide Earthquakes from 2000 to 2016 .................................................................................................... 3
Tab. 2. 4 Number of hurricanes and hurricane related deaths ......................................................................................... 5
Tab. 2. 5 Table demonstrating the most common chemical substances firefighters interact with. ................................. 6
Tab. 2. 6 Natural Catastrophe Losses in the US 2018..................................................................................................... 7

Tab. 4. 1 ME Funding ................................................................................................................................................... 13

Tab. 4. 2 EEE/CPE Funding ......................................................................................................................................... 14

Tab. 9. 1 TOF Test Results ........................................................................................................................................... 32

iv
EXECUTIVE SUMMARY
Our project is a semi-autonomous robotic quadruped to help aid in search and rescue and other operations.
In this report we provide a detailed explanation of the work performed and our experience with this project
over our timeline from Fall 2019 to Spring 2020. Our goal for our project was centered around the idea to
help workers in the field of search and rescue, and to help prevent those people being in dangerous situations.
The inspiration behind the creation of a robotic quadruped was looking at the world’s problems and
understanding that there are disasters throughout the world. Once we had a better understanding of the
societal problem, we had to figure out a way to solve the problem or best help solve the problem. Since
disasters, whether it be natural or not natural are common throughout the world and not preventable, we
wanted to focus on something that is achievable and can work to help when those disasters occur.

Our milestones consisted mainly of the creation of our features. Once we were able to complete each feature
one at a time, we knew that we were one step closer to completing our design. Some of the big milestones
were completing the first prototype as well as the second prototype to show the progress we had made as
well as giving us inspiration to work towards a final product. Also, big milestones were the December
showcase because of the valuable feedback given for the rest of our project and what we needed to do in
order to succeed with our final design. Each aspect of our robotic quadruped had risks. Though most of the
project consisted mainly of software, the hardware parts of the project had the most risks. This is because the
software errors would only be compiling errors and mostly from just testing the software if it works. Our
hardware is a different problem though since the robotic quadruped is a movable object, parts move a lot and
they could break with random falls or become short circuited without much notice. There is also the issue
with building our second prototype is the amount of power consumption as well as stress on the parts. After
diagnosing and finding the broken part, it could take days or weeks to replace our items. All and all, we did
not run into many issues throughout the product that set us back to far. The main issue that we ran into was
the lack of time to work on and test our robotic quadruped since it was so complex and a big learning curve
for a lot of the software.

Many factors have affected the ability to ‘roll-out’ the project as a fully formed product, namely the
resources that are available for use as well as the time to completely get the project fully operational. All
measurable metrics have been met throughout the project's timeline. To improve on our design, we believe
that the main features are solid and would just need more refinement. More things need to be added to
software to be more consumer friendly and more inviting as well as the capabilities of the product. Hardware
wise, we could look at using different boards and microcontrollers to make the robotic quadruped cheaper as
well as smaller. Also, more fabrication of better integration of our robotic quadruped could be made to create
a nicer more robust robotic quadruped.

Overall, this document walks you through how we got the idea to solve the societal problem as well as the
tasks it took to complete the robotic quadruped. The product specifications will be discussed to allow the
reader to provide insight about the cost, purpose, and ability to compare the project to similar products.
Throughout the report, you will also find how we broke down each part and combined them into one
product. Also, this document provides the details about the various robotic industries to provide context as
to how our robotic quadruped will fit in the real world

v
 1

MegaByte: A Robotic Dog to Aid in Search and

Rescue Operations
Alfred Martinez III, Kristian Ornelas, Edgar Granados, Marcus Huston
Department of Electrical & Electronic Engineering, Computer Engineering Program, CSU Sacramento
6000 J Street, Sacramento, CA, USA

Engineering) came in to present their vision for their

Abstract— As disasters continue to happen every year senior design project, our team became very
throughout the world, the increase in search and rescue
intrigued of the possible project that could be
workers continue to rise as well as the danger they put
themselves into. We aim to create a design to help lower the developed with both teams working together. The
chances of injury and keep more people safe by creating a ME team proposed an intercollegiate collaborative
semi-autonomous robotic quadruped. This document is project in which the electrical/computer engineering
intended to summarize our Fall 2019 and Spring 2020 team would assist in designing the control and
semesters, in terms of the technical work we have
feedback system of a quadrupedal robot. Robotics
completed. The paper starts by explaining the societal
problem and followed with the design idea as a proposed has a wide variety of applications in the real world;
solution. In addition, we highlight the funding that was in fact, in today's modern day, you can find an
required to make this project possible as well as the cost it application of a robotic system in nearly everything
will take to build the robotic quadruped. We also discuss the imaginable. Whether it'd be in the medicine,
project milestones and their significance, as well as the work
logistics, or manufacturing field; robotics has shown
breakdown structure, which includes the risk assessment
and task assignments for each team member. Included, we to be very impactful in everyday human life, and as
have documentation for our design, which includes the further development is done, will become even more
hardware/software block diagram and schematics. We have essential in dealing with societies' necessities. Thus,
also included any mechanical drawings and renders that for our team finding a solution for a societal issue no
were used in our project. Additionally, we included our test
longer became a problem. It was choosing which
plan along with the test results. This report also touches on
some of the possible applications our robotic design could societal issue our project would best be able to solve.
be used for. This includes specifications outlining a relative In the end, our team settled on designing a robotic
cost of manufacturing and developing, analysis into the quadruped that would be able to operate semi-
current Robotics Industry, as well as the top competitors in autonomously to aid in search and rescue operations.
the industry. This document has information about the
Search and Rescue Workers, Disaster Relief
problem statement to the design and all the way to the
finished product of our senior design project. Workers, and Firefighters are all typically put into
highly dangerous situations which prevents them
Index Terms— Robotics, Quadruped, Search and Rescue, from helping victims as thoroughly as they would
Disaster Worker, Robot, Open Source, ROS, DC Motor, otherwise like to. The idea of a semi-autonomous
Semi-Autonomous, Machine Vision, PID Control robotic quadruped is to help save lives of victims and
search and rescue teams that put their lives in danger
I. INTRODUCTION
every day. In our endeavor to design our quadruped
During the first semester of Senior System Design, robot, our team ultimately ended up creating the
our group was tasked with designing a certain control and feedback system for a small model
product that would be able to tackle a real-world robotic system that would be able to sustain its
societal issue. Initially, like many other groups, we walking movement, through the help of sensor
struggled to bring about a realistic solution that modules. It was originally planned that the final
would successfully be able to address one of deployable prototype would be a large-scale model,
societies’ problems. Nonetheless, when a team from roughly 3 feet tall, 100+ lbs., and able to move semi-
a different engineering department (Mechanical autonomously; however due to the worldwide
 2

coronavirus pandemic, our development time was

impacted, and our final deployable prototype was a
small-scale model system and the control/walking
algorithm for a large-scale model leg. This document
will present the design and technical information that
was conducted by our team in our attempt to design
a semi-autonomous quadrupedal robot.

II. SOCIETAL PROBLEM

A. Fall/Spring Societal Problem
1) Introduction
This section studies the situations as of Fall 2019 Figure 2.1. Number of wildfires and acres burned in the U.S.
from 1988 to 2017. Reprinted from “Wildfire Statistics.”
in Disaster Relief and Search and Rescue, S.A.R.,
efforts around the globe and attempts to find areas Source: Please refer to [27]
where improvements can be made based on existing
models and what is achievable and economical. About 14,000 residences were destroyed and about
Several branches of SAR Robotics were studied, 18,000 buildings in total. Multiple California Urban
these were sorted into Aerial, Ground, and Marine. Search and Rescue (US&R) Task Forces and human
Furthermore, these categories were divided into remains canine search teams were deployed from
disaster relief, search and rescue, firefighting, and across California to assist law enforcement with the
crisis management. search for, and recovery of, victims missing
throughout Paradise and other towns devastated by
2) Natural/Non-Natural Disaster Statistics the fire. Throughout the two-week span, the wildfire
This section presents all the necessary statistics killed 85 people. Even two weeks after the fire,
regarding the amount of disasters that occur search and rescue crews were still trying to find
throughout the world, indicating that there is a hundreds of people.
problem.

a) Wildfires
This subsection provides numerous statistical
datasets regarding wildfires. Wildfires are a form of
ground search and rescue; also, other forms of fires
can devastate urban areas to include them in urban
search and rescue. A recent example would be “The
Camp Fire” in Paradise, CA. They had to evacuate
52, 000 people throughout the city and surrounding
area. The fire lasted for two weeks and burned across
153,000 acres.

Tab. 2. 1 Table format of Fig. 2.1 Forest Service (FS) and

Department of Interior (DOI).

Source: Please refer to [12]

 3

b) Earthquakes
This subsection presents statistical data regarding
earthquakes and other relevant earthquake-related
information.
One of the most recent big earthquakes was the
2011 Tohoku 9.0 earthquake which later caused a
Tsunami to hit the city. The combined total of
Figure 2.2. Top five years with the largest number of acres confirmed deaths and missing is more than 16,000.
burned since 1960 in U.S. Due to the earthquake and tsunami, the Japanese
Source: Please refer to [27] government ordered over 100,000 troops, a total of
236 aircrafts and 50 vessels/cargo planes were
deployed to aid in the field. This incident is classified
under the form of water and urban search and rescue.

Tab. 2.2 Number of personnel and losses for FS and DOI

Source: Please refer to [12]

Up to this point, all the data represented occurs

within the U.S., but wildfires are an issue
experienced worldwide. Fig. 2.5 shows the 2017
wildfire mapping of the burned and unburned areas
of Pedrógão Grande, located in Portugal.

Tab. 2.3 Worldwide Earthquakes from 2000 to 2016

Source: Please refer to [3]

Figure 2.3. Burned/Unburned mapping of Pedrógão Grande in

2017

Source: Please refer to [14]

 4

c) Tsunamis/Hurricanes/Floods
Subsection C provides data related to tsunamis,
hurricanes, and floods, respectively.

Recently, Texas has been hit with record breaking

rainfall during the Tropical Storm Imelda which has
caused flash flooding. They have seen up to 42
inches of rain within a three-day period. This storm
has left at least two people dead and has had rescue
crews with boats scrambling to reach stranded
drivers and families trapped in their homes during the
relentless downpour. There has been a combination
of about 1,000 high-water rescues and evacuations to
get people to shelter. The classification of the
Tropical Storm Imelda falls under the categories of
urban search and rescue as well as water search and
rescue.

Figure 2.4. Map of historic earthquakes since 1769

Source: Please refer to [3]

Figure 2.5 below shows the map of the epicenter

of the 2011 earthquake in Japan. The earthquake had
a magnitude of 9.0 and was the largest recorded
earthquake in Japan in over 100 years. The
Figure 2.6. Global tsunami events from 1890 to 2010
earthquake cost more than $300 billion which makes
it the most expensive disaster. Source: Please refer to [20]

Figure 2.5. 2011 Tohoku earthquake epicenter map

Source: Please refer to [20]

 5

Source: Please refer to [30]

d) Avalanches
Avalanches are a form of mountain search and
rescue. The largest avalanche in history was on May
30th, 1970 off the coast of Peru. An earthquake
caused the north slope of Mt. Huascaran to collapse.
The avalanche ran for almost 11 miles and estimates
that 20,000 people were killed in the event. Statistics
show that about 25% of victims were killed by the
trauma of the event. Of those that survive the trauma,
the first 15 minutes is crucial for survival. The search
for victims must start immediately if they are buried.
In the present day, ski patrols, helicopters and
mountain rescue teams are sent out to search and
rescue the buried victims. For avalanche rescue
teams, they usually have a first team that can travel
light and move quickly to locate and uncover buried
victims. After that depending on the severity, they
will transport the victim via the ski patrol or by
helicopter. Overall the plan for search and rescue
teams has evolved tremendously.

3) Search and Rescue Statistics

People may go missing for a variety of reasons,
which brings the need of various search and rescue
groups. Search and rescue can be broken down into
four different categories. The first being ground
search and rescue. Ground search and rescue is the
Tab. 2.4 Number of hurricanes and hurricane related deaths search for persons who are lost or in distress on land.
The next is Mountain Rescue which is the search and
Source: Please refer to [30] rescue operations specifically in rugged and
mountainous terrain. Urban Search and Rescue is the
location and rescue of persons from collapsed
buildings or other urban and industrial entrapments.
Water search and rescue is the capability to
coordinate and conduct water search and rescue
response efforts for all hazards involving water. All
of these include locating, accessing, medically
stabilizing, and freeing victims from their specific
areas.

4) Current Safety Equipment Needs

With an increasing number of deployment
missions by search and rescue personnel, the need of
equipment and supplies has also seen a jump in
demand. For instance, the year 2017, was the most
Figure 2.7. Annual percentage of flood peaks in the Easter destructive year in California in terms of property
United States loss/damage, as more than 9,133 fires burned across
the state. That year alone saw an unprecedented
 6

number of search and rescue deployments; which

utilized so much of California’s Fire and Rescue
resources, that it required additional assistance from
10 other states. Having said that, this section aims to
discuss the most common problems that SAR
personnel face when deploying on missions; as well
as, the resources needed by workers and victims.

a) Closer Look into The Needs and Risks of

California Firefighters
Most of the largest fires in California have taken
place within the past 20 years. These frequent
occurrences have led to the need of more fire
combatant equipment. When dealing with wildfires,
firefighters must come equipped with fire resistant
pants and shirts, a helmet, eye protection, gloves, Figure 2.8. Potential Areas with High Risk of Wildfires.
leather boots, and fire shelter. On the ground, they Source: Please refer to [27]
must be prepared to contain the spread of the fire by
common means such as digging “fire lines”, cutting
down trees and bushes, or creating “backfires” to
deprive the main fire of fuel.

Even with all this equipment aimed to protect and

maintain the safety of firefighters, firefighters still
run the risk of developing respiratory or carcinogenic
issues in the future. The International Agency for
Research on Cancer (IARC) classified occupational
exposure as a firefighter as possibly carcinogenic to
humans. In Fent et al.’s article, “Contamination of
Firefighter Personal Protective Equipment and Skin
and the Effectiveness of Skin decontamination,” he Tab. 2.5 Table demonstrating the most common chemical
analyzed the health effects associated with substances firefighters interact with.
contaminated fire equipment utilized by firefighters.
Source: Please refer to [27]
Due to the low maintenance of fire suits, as
laundering them is only commonly performed once As the upward trend in natural disasters continues,
or twice a year, toxins can accumulate on the suits disaster relief individuals will be more susceptible to
and could transfer onto the skin of firefighters. becoming exposed to hazardous materials. New risk
management techniques need to be developed and
implemented; in order to maintain the health and
safety of SAR workers.

b) Quantifying the Disaster: The Health and

Economical Effects Influenced by Natural
Disasters in the General Population

Oftentimes, when a natural disaster occurs such as

a catastrophic storm, flood, hurricane, wildfire etc.
the priority many times is to act upon the current
situation. Similarly, this is the same when
 7

researchers analyze the health consequences of When it comes to flooding, there can be a variety
natural disasters; as the research focuses primarily on of toxins and carcinogens that become present in the
the populations impacted and the immediate water. Storm surges can create situations where
aftermath. Prochaska and Peters (2019) argue that water meets hazardous materials; which in turn, may
there has been very little research done on the health flow into bodies of water used by people.
effects of natural disasters in older adults over a long
period of time. The article proposes correlations Economic strain may also be an apparent
between exposure to these events and the long-term consequence of a natural disaster. For instance,
development of cancerous diseases in older adults. according to Munich Re, in 2018 the US saw an 82-
As discussed before, the current trends show an billion-dollar loss due to natural disaster events that
increase in occurrences of severe weather events in had occurred.
the United States; with, this increase has also led to
an increased exposure to natural disasters by the
general population.

Tab. 2.6 Natural Catastrophe Losses in the US 2018

Source: Please refer to [5]

However, the worst loss for the United States’

economy was in 2017 where the US saw a total loss
of 307 billion dollars due to 16 events that cost more
than $1 billion each (Amadeo, 2019). Economic
impacts like these have a tremendous impact on low-
Figure 2.9. Number of Natural Disasters from 1900- 2018 income communities as it takes much longer for them
to recover; since they have less access to resources.
Source: Please refer to [5]

Some of the most common natural disasters that c) Relief Efforts

Americans are exposed to are flooding and wildfires. During search and rescue operations, the main
In the case of wildfires, potential risks of cancer can objective of a team is to rescue the largest number of
be associated with the exposure of particulate matter people in the shortest time, while also mitigating the
in the air. For instance, smoke from wildfires contain risk factor. The immediate priority after a natural
high levels of ash and particulate matter (PM2.5) that disaster is providing emergency first aid and medical
remains suspended in the air. The specific health services to injured persons. In most cases first
concern is the harmful airborne PM associated with responders consist of doctors, emergency workers,
forest fires. These smaller airborne particles, and police units. Currently, the United States has
specifically PM2.5, have been found to embed and provided a total of 270 billion dollars in disaster
accumulate in the lungs resulting in respiratory relief efforts as of August 2019.
diseases such as lung cancer.
 8

rescued. Thermal cameras, range finders, location

tracking systems, and 3D mapping systems are all
currently being used to varying degrees and being
constantly improved.

One example of a current SAR robot is Japan’s

KOHGA3. This tracked robot is built to analyze
damaged buildings whenever Japan is hit with an
earthquake. The aim being to protect inspectors and
workers as well as provide rescue workers with more
eyes and, therefore, greater efficiency.

Figure 2.10. End of Year Cost of Disaster Relief

Source: Please refer to [24]

5) Possible Solutions
Currently, Rescue Teams and Firefighters are put
into highly stressful and erratic environments. The
proposed, main solution to this problem is to add
more robotic technology to help analyze dangerous
situations, speed up the searching processes when
disasters do happen, react to fires more rapidly and
Figure 2.11. KOHGA3 Ground Robot for Search and Rescue
from more dynamic approaches, and give all this and Vacant Building Inspection
information to the teams in the situations so that they
can help people in need with better assurance of their Source: Please refer to [17]
own safety. Currently, robotic models are used as Another example of current robotic technology
live streams that feed information to a remote falls under snake-like robotics. These newer designs
location out of danger. Eventually, the goal would be are light, thin, and can fit into narrow areas rescue
to allow autonomous or semi-autonomous robots to workers cannot readily access. These types of robots,
replace workers and to allow greater environmental still being developed, could one day help rescue
control over any disaster type situation. This requires workers locate victims trapped under rubble piles in
highly intelligent robotics as well as teams that are broken down buildings or miners stuck in caves and
trained to operate them. mines.

a) Search and Rescue Robots

Modern search and rescue workers are equipped
with a multitude of tools to evaluate and interact with
the dangerous situations they are placed in. Robotic
technology is a broad topic on its own, but in general
most current robots are limited to searching and not
so much rescuing. This is caused by robots not
having the level of sensitivity and dynamic motion
control needed to analyze and transport victims in an
efficient and safe manner. Many robots in use will be
sent out to locate and send visual/audio feed to an
operator that can then send that information to rescue
workers. This alone is still a vital piece to rescue Figure 2.12. Robot Snake, Biorobotics Laboratory Carnegie
situations when victims have a limited time to be Mellon University
 9

Source: Please refer to [7]

Likely the most difficult of all the forms of robotics

is the walking/running type robots that emulate
humans and walking animals. It is very easy to
imagine the usefulness of futuristic walking robots.
Dogs, cats, horses, and mules have all been worked
alongside humans for millennia and having robotic
counterparts to match these aspects is not simply
science fiction. Robotic quadrupeds have the ability
to traverse rough terrain quickly, ever more
efficiently, and can relay data just the same as any of
the other robots discussed. Quadrupeds are being
thoroughly researched and developed; many
companies and universities are developing their own
walking robots under different specifications which
leaves hundreds, possibly thousands, of design ideas
across the globe. Boston Dynamic, Honda, MIT, Figure 2.14. Honda’s Asimo
Stanford, and many others have customized Source: Please refer to [16]
prototypes.
These robots can be highly versatile in the future
working in all areas of society not exclusively search
and rescue.

b) Firefighting Robots
Robotic Firefighting Systems typically entail a
remote-controlled vehicle with fire suppression
technology attached to it, like a water hose. They can
travel into areas deemed unsafe for humans such as a
collapsing building or closer to a fire that would be
too hot for a firefighter. They also have the added
benefit of being able to detect voices, body
signatures and map out hotspots to avoid walking
over collapsible spots.
Figure 2.13. Boston Dynamics’ SpotMini

Source: Please refer to [19]

Figure 2.15. Thermite Fire Fighting Robot

 10

Source: Please refer to [29] Source: Please refer to [32]

Adding Autonomy to these robots would free up

Firefighters to worry about people in rooms and
trapped in various locations while the Robots
analyzed and hosed down the fires. In the future,
firefighting robots could be deployed in wildfire
locations with teams of “Hotshots” to automate ditch
digging, logging, setting backfires, or carrying
additional equipment.

Figure 2.18. Disaster Relief Drone

Source: Please refer to [32]

A group of aerial drones could be set up to map the

progress of a fire and track its movement.

6) Societal Problem Conclusion

Natural Disasters are a consistent issue across the
globe especially for impoverished communities. This
Figure 2.16. Prescribed fire in eastern Washington, United report’s aim was to study common forms of natural
States
disasters and their statistical side effects including
Source: Please refer to [27] fatalities, suburban devastation, and economic
c) Drone Technology impact on specified regions. Following this, the
Aerial drones can be used as standalone units or in report aimed to find solutions to these disaster
a mini fleet to record terrain and battle fires from situations by improving safety standards for
above. Currently, drones are being tested to track firefighters, rescue workers, and disaster relief
wildfire movement in large areas that are incredibly workers using robotics. The general notion being that
difficult to navigate, but, in the future, it is possible creating safer conditions for rescue workers is
to have a team of drones dropping mapping hot zones tantamount to improving rescue effort efficiency as
and movement while other drone drop water and well and increasing relief effort responses. By
extinguishing material over the flames while looking at firefighting robots and drones, adding a
firefighters tackle other angles. The same approach small, well-trained team to a wildfire effort could
could be used in large buildings and skyscrapers to increase overall coordination, tracking, and possibly
attack fires from the winds using hoses carried by aid in stopping wildfires and saving thousands of
drones. acres of forest. Estimated with increased
performance over the next few decades and higher
agility robots, one day, perhaps, only a small team of
robotic technicians could be putting out entire forest
fires with no personnel in direct conflict with the
flames.

III. DESIGN IDEA

A. Fall Design Idea
1) Brief Description
Fall semester brought a unique opportunity for the
team to classify exactly what aspects of the robotics
Figure 2.17. Firefighting Drone project they wanted to tackle. Topics ranging from
 11

Motor Control to Dynamic Motion to Machine

Vision were discussed and ranked to achieve a list of
what best suited the needs of the team and project.
The search and rescue robot we decided to take
further would be designed in two groups: a large
model and a small. Each would give the opportunity
to tackle different aspects at different paces.

Figure 3.3 Small Model Prototype Design

Source: Please refer to [6]

The larger model would take much longer to

construct due to the complexity of its mechanical
design. The design would also use a series of more
complex electronics to move its limbs. This
included: BLDC Motors connected to spinning rods,
Figure 3.1 Small Scale CAD Model of Robotic Dog encoders that measure the RPM of the Motors in both
Source: Please refer to [6] directions, limit switches that prevent motors from
crashing passed their limits, and distance sensors that
measured the angle of the limbs externally. This was,
The small model would be built as a bare-bone of course, still a work in progress itself; other
design of a quadrupedal robot using 12 Servo Motors solutions included absolute encoders to measure the
to achieve the 3-DOF per leg as requested in the final exact position of the motor along its rod and
design. By using small Servo Motors, the team could potentiometers in the joints.
begin to easily control the angles of the limbs and
move into the realm of robotic locomotion without
waiting for the construction of the much larger 2) Problem Reiteration
design. The first subjects tackled in the Fall semester were
robotic locomotion using Servo Motors and Walking
Gaits. The mechanical engineers helped us find
several sources of robotic dogs from online 3D
models. The next step would be to take these models
and create a CAD model that was modified and
printed to our specifications. With the model built,
we wanted to have the small model built, coded, and
walking in a basic motion by the end of the semester.

3) Idea Uniqueness
Figure 3.2 Small Model Joint Placement Diagram
To be clear, this project was similar in many
Source: Please refer to [21] aspects to other projects built in on other campuses,
companies, and hobbyists. It is difficult to say what
makes this project specifically unique over other
projects. For this team, this project was selected due
to its unique goals and challenges that may offer
 12

great opportunities to learn realistic robotics design • Control the speed and rotary positions of a motor
processes and techniques. to a certain accuracy.

4) Feature Set & Measurable Metrics

B. Spring Design Idea
The Fall Semesters Feature Set and Measurable
Metrics were one of the first challenges faced with 1) Brief Description
this kind of project. The two teams decided that this With the Fall Semester completed along with most
project would not be completed but be a multi-year of the original goals and plans, it was time to plan a
project. This meant that we had to first decide what course of action for the Winter Break and the Spring
we could realistically accomplish by year’s end and Semester through to the end of the school year. By
what was most important for us to focus on. the showcase in the Fall, we had a walking prototype
with the small dog and were able to control the
At the start of the semester, we originally had BLDC Motors to some degree. With this in mind, we
planned to split into two pairs. One team would focus gained more realistic insight into what was
on the kinematics, servo motors, and walking motion achievable given the time restrictions and course
of the robot; the other team would focus on working work from the previous semester. For the Spring
in Linux to work on the cameras and computer Semester we would focus on building a single, large
software for guiding the robot through visual and leg instead of the full robot. We would also focus on
distance sensors. This slowly fell apart as we found controlling the small dog using an embedded
out the level of difficulty that the cameras brought. computer instead of a microcontroller to allow
This eventually was dropped out of the project for the integration with more modern features. These
next semester students or club members to take over. included wireless control over Wi-Fi, Python
language, and camera accessibility to expand the
Our feature set was built as a list of what we robot further throughout the Winter and Spring. For
believed was achievable by the Fall semester’s end the Spring, we also had all the parts assembled and
with caution in mind: redesigned for a single leg of the large model. This
included two moving joints, the sensors to control
a) Small Model: them, and the power to maintain them.
• Control the servo motors using embedded C
programming language. 2) Problem Reiteration
This semester’s goals were the extension of the
• Finishing kinematic model of the servo robot Fall’s semester with further steps in some areas. We
legs. wanted to further our ability to make the small
prototype walk using the servo motors. We hoped to
mount one or two cameras on top of this model and
• Controlling the angles of the joints to a certain
use them as a form of input data to the robot, as well
degree accuracy.
as adding an IMU to make the prototype have
balancing feedback features. Basically, the plan for
• Making the Servo Robot walk in a straight line
the small dog in the spring semester was to continue
for at least three meters to a certain
working on the walking gaits and locomotion while
linear accuracy.
adding cameras and feedback sensors to make the
robot more responsive and advanced. For the large
b) Large Model:
model, the Spring semester goals were reduced from
• Complete a 3D printed mount that will hold the building the entire robot dog to just building a single
BLDC Motors and the rotary encoders. leg and mounting that to a testing platform. This
would allow us to test motor speed, angular control,
• Connect a motor to a motor controller and access torque control, power consumption, and mechanical
the hardware through software. stability. All of which were highly important to be
tested before we could go further in the mechanical
 13

design. Some of this did not last to fruition due to Ballscrew support
campus shut down and lab closure. bearings 8 $22.75 $182.00

3) Feature Set & Measurable Metrics 250 mm ballscrew, thighs 8 $20.59 $164.72
The features planned for this semester were more
realistic than the previous semester. Each team Linear rail leg supports
(rod to be cut in half) 4 $37.35 $149.40
member was to undertake only one main feature and
work exclusively on that to ensure everyone was 200 mm ballscrew, hip
working hard but not overworking. joints 4 $33.99 $135.96

The Spring Feature Set was more compact and 30mm ball bearings 8 $9.00 $72.00
more achievable; however, it has since been reduced 30 mm steel tubes,
further due to campus shutdown: 2.0mm x 300mm, hip
supports 4 $17.28 $69.12
a) Small Model: 3 x 1 x 36 Aluminum
• Controlling the motors and joints using an beam, backbone 1 $52.68 $52.68
embedded computer instead of a microcontroller. 40 x 40 Aluminum Ext
91" 1 $49.14 $49.14
• Attaching an IMU to the body platform and
implementing feedback into the walking 10mm ball bearings 12 $3.00 $36.00
software to increase balance.
20x60 Aluminum Ext
800mm 2 $17.30 $34.60
b) Large Model:
• Implementing power control system for the leg to 20x40 Aluminum Ext
operate for a certain length of time and begin 700mm 2 $14.95 $29.90
testing power consumption. Wheel bearings for ball
screw support 2 $10.99 $21.98
• Controlling the angles of the joints via the BLDC
Motor Controllers in software. Assorted hex screws 1 $19.99 $19.99
20 x 20 Aluminum Ext
600 mm 2 6.79 $13.58
IV. FUNDING
A. Mechanical Aspects 3/8 threaded rod 10ft 1 $7.98 $7.98
1) Mechanical Component Breakdown
3/8 washer 25 piece 1 $3.45 $3.45

3/8 hex nut 25piece 1 $2.97 $2.97

T-nuts 1 x M3 1 x M4 lot
Tab. 4.1 ME Funding of 20 2 $1.26 $2.52

Total Source: Please refer to [6]

Bill of Materials MECH Cost: $1,767.99
UNIT TOTAL
PART DESCRIPTION QTY COST COST

3D printing filament 20 $20.00 $400.00

1/4 Aluminum sheet 36" x
36" 2 $160.00 $320.00
 14

B. Electrical Aspects
1) Electrical Component Breakdown

Tab. 4.2 EEE/CPE Funding

Grand
Bill of Materials Total: $2,504.70
Club or
PART UNIT TOTAL Team
DESCRIPTION QTY COST COST: Funded
Brushless DC
motor 12 $85.85 $1,030.20 Club
O Drive 3.6 (24V
version) 6 $129.00 $774.00 Club
NVIDIA Jetson
Nano 1 $99.00 $99.00 Club Figure 5.1 Small Cardboard Model Prototype
Time of Flight Source: Please refer to [6]
Sensors 2 $50.00 $100.00 Team

I2C MUX 1 $13.50 $13.50 Team B. 3D Printed Prototype (Part 1)

The miniature prototype was the most used model
Rotary Encoder 12 $24.25 $291.00 Club
throughout the course of the project. It facilitated the
IMU 1 $5.00 $5.00 Team most learning because of its small, carriable size and
Nucleo STM simplistic design. It allowed us to cut passed the steps
Board 1 $12.00 $12.00 Team of difficult motor control and higher power
consumption and practice robotics with less risk.
Servo Motors 12 $15.00 $180.00 Team

Source: Please refer to [6]

V. PROJECT MILESTONES
A. Cardboard Model
The first iteration of our robot design was made of
cardboard, glue, and tape. This was simply a
brainstorming model and it allowed the mechanical
engineers on the team to communicate with the
electrical and computer engineers on how best to
begin this project. The cardboard model was used for
roughly the first month of the Fall Semester and
ended when the 3D model was designed, and printing
began. The greatest lessons learned from this model
were: (1) controlling servo motors through
microcontrollers, (2) using while loops and time
delays properly, and (3) the restrictions on the range
of motion on the joints. This was also an opportunity Figure 5.2 Construction of the 3D Printed Small Model
to gain basic understanding on how to properly
Source: Please refer to [6]
assign pins and use an ARM M4 microcontroller.
The miniature prototype was designed to operate
using 12 high torque servo motors placed directly in
each joint, called ‘Direct Drive’ in robotics. This
 15

meant that the motors were in a situation that would features would be added to increase the robots impact
allow them to be damaged easily if not used properly, reaction when walking on hard surfaces.
but it allowed them to be as light as possible with the
largest range of motion possible. Alternatives to this One major aspect of this prototype was the
design we considered including using cabling, microcontroller itself. The first thing that had to be
springs, struts, or gears coupled between the motors concurred was controlling a servo motor from the
and the joints. adjustable systick timers and clocks within the ARM
Cortex M4 chip itself. The team decided to use a M4
Microcontroller over a hobbyist Arduino board
because they have much more capabilities. These
include faster clock speeds, lower level port and
peripheral control, and lower power consumption.
The main drawback of these more advanced chips are
the added difficulties caused by the lack of support
online.

Figure 5.3 Diagram representation of our 12 Servo Dog

Source: Please refer to [6]

Figure 5.5 STM32 Nucleo Board

Source: Please refer to [4]

Figure 5.4 3D Printed Small Scale Dog Model

Source: Please refer to [6]

All these options had specific benefits, but the

largest common drawback was the added weight, Figure 5.6. STM32 Cortex M4 Specifications
design time, and build time that caused them to each Source: Please refer to [4]
be left out. If a second robot was to be built, these
 16

Most people who make recreational drones or as some of these may sound, if the project could be
robots use either Arduino Microcontrollers or fragmented correctly these could serve individual
Raspberry Pi boards. The ARM Cortex chips, purposes within the main body of the project to bring
however, are industry standard across a range of together a fully operational robot. The thinking from
products for being cheaper, more compact, and the start of the semester was that we would make the
faster. They are used in everything from common robot’s walking gaits and peripheral control in either
household electronics to automobiles to expensive Verilog or C/C++. Then we would simultaneously
medical supplies. All of which influenced our begin working on the camera systems in MATLAB
decision to use the more advanced chips for our or Python.
project.
C. 3D Printed Prototype (Part 2)
The STM32 MCU was used to control our smaller By early to mid-October we had a fully built model
prototype consisting of 12 Servo Motors and a with the 12 servo motors properly controlled by the
UART Tx/Rx Setup to print out the data onto a ARM Cortex Microcontroller. The chip selected was
terminal in a PC. After Researching and Trial and mounted onto a PCB Prototyping board which was
Error, it was found that the PWM Channels were then mounted onto the center of the robot; for power
control on the ARM Cortex through a series of supply we used a cable power supply that fed the
General Purpose & Advanced Timers. Each with a motors 7.5V and fed into an inverter that supplied the
set of 3 to 4 Registers that controlled the PWM chip with 5V. With the clocks and pins set up
channels separately. On the next page is a diagram of correctly, we had a fully operational platform with
the Chip used with all the pins initialized to their angular control of the 12 joints independently of one
correct pins. another. The next steps to follow would be to use the
12 moveable joints in uniform to create more
advanced motion.

At this point, we moved onto the walking patterns

and angular control of the robot. This involved more
trigonometry and calculus. The robotics community
refers to this as Kinematics. Robotic Kinematics
applies geometry to the study of the movement of
multi-degree of freedom kinematic chains that form
the structure of robotic systems. By controlling the
links and angles of the body we moved onto walking
gait equations. First, we worked at converting the
angle control of the joints to position control in 3D
space. This meant that we could control the position
of the four feet. Next, we worked at creating a
circular pattern of moving the foot through a series
Figure 5.7 STM Nucleo Board Pinout
of positions that would mimic walking. After a lot of
Source: Please refer to [4] trial and error, the walking gaits were perfected to a
degree suitable for showcasing.
We also began to consider which programming
languages were more useful than others for the tasks
we laid out for ourselves to achieve. The main
breakdown was a split between timing reliability,
lowest level power consumption, simplicity and
support, and the ability for rapid prototyping. The
primary languages chosen were: (1) Python, (2)
C/C++, (3) MATLAB, even (4) Verilog. As absurd
 17

Figure 5.9 Gait Cycle

Figure 5.8 2D Inverse Kinematic Nonlinear Equations Source: Please refer to [1]
Source: Please refer to [28]
It was found that using elliptical patterns for the
Above is a diagram demonstrating the Inverse feet, you could effectively cover ground if the robot
Kinematics Equations used to get the robot to walk was well balanced and the diagonal legs moved
properly. Specifically, the goal of these equations is simultaneously. The diagram above demonstrates
to convert the X (x, y) position of the foot compared human bipedal motion. It is visible that each leg
to the hip joint, to two angles for the joints. This moves opposite to the other. It is also obvious that
would give us the ability to control where the feet are the legs both move in a cyclic pattern mimicking the
in vector space while letting the function solve for ellipse shape when walking straight.
the angles to give the robot joints. Of course, this
took considerable time and effort to fully understand,
implement, and test, but it all seemed to work
perfectly besides the standard deviations in the 3D
print model and the looseness of the servo threads.

1) Walking Gaits and Locomotion

Walking the dog was undoubtedly the hardest part
of the project last semester. At this point each of the
feet could be positions on demand as well as the
corresponding angles in each of the joints. Now,
torque, speed, and angular momentum all came into
play. To make the robot walk, prototypes and
products from other schools, studies, or companies
had to be studied to gain a basic understanding of Figure 5.10 End-Effector Ellipse
what has been attempted in the past. It was found that Source: Please refer to [17]
many of the robots built began with studying dog
walking patterns first. By searching the internet, we An ellipse, shown above, was used to mimic the
were able to find many examples of diagrams and changing position of the foot throughout its walking
videos showing how exactly dogs walk over flat and gait. These equations were drafted into a useable,
uneven terrain. These would become the base for our embedded C program and added as another layer to
experimentation throughout the process. the previous segments of code. The same variable
names: h, k, a, & b; were used to keep a consistent
understanding between the code and the pure,
mathematical diagrams above them. By use of
trigonometry and algebra, we were able to output
constant values for the X and Y position along the
ellipse to be fed into the servo motor inverse
 18

kinematics equations. Once cyclic motion was exactly they were more effective for our needs than
achieved in the code, it was time to make the robot brushed DC motors, stepper motors, or servo motors.
walk. To achieve this, the legs vertical to each other
had to start with a phase shift of 180 degrees to For us, the lighter weight, higher torque, and
ensure they were perfectly opposite to one another. greater efficiency really drove home the idea that
Finally, to have the robot continuously walk, the they best fit our needs. ‘Field Oriented Control’, a
main while loop would continuously call a function developer term which refers to controlling Brushless
to step through the ellipse at a constant rate. DC Motors in practical applications. This meant
studying how the three-phase sine waves from the
With the robot walking in a basic walking pattern, motor controller boards would be impacting the
we had an open-loop system. The system walked motors and the noise given off by using high power
almost correctly but would simply continue walking sine waves in small locations. This also meant
if it was tipped over. The next step was to begin learning how to control the motors by mounting
practicing feedback systems and implementing them encoders on each one for position control as well as
into the walking equations to make the walking more the voltage, current, and torque requirements for our
accurate and responsive. For these steps, each team goals.
member tried to implement their version and
research the next steps for closed loop
responsiveness. These added feedback sensors will
be discussed in the sections below.

Figure 5.12 3-Phase BLDC Theory

Source: Please refer to [2]

Above is a diagram of the basic BLDC motor

control layout. By manipulating the transistors rise
and fall time and rapidly switching between the three
phases of the BLDC’s coils, the motor is given
unique advantages. These include greater efficiency
Figure 5.11 Robotic Gaits than other motors, higher torque output, and,
Source: Please refer to [17]
therefore, they can replace bigger motors that output
the same results.
D. 3-Phase Brushless DC Motor Control
The motors we used were massive in size and The following graph shows the motor spinning at
difficult to interface with for first time users. With no a specified RPM (shown in pink) and Voltage.
background knowledge in the use of 3-phase motors, Gradually, the torque, or strain, on the motor is
the team struggled to first learn what size was increased making the motor work harder to maintain
necessary for the torque we needed. And we were its original goal speed. To maintain this set speed, the
unsure exactly how much power the motors would motor controller will increase the current sent into
require or how to measure the consumption to begin the motor’s three set of coils (shown in red). As these
the research. Throughout the course of the year, most two factors were changing, an efficiency coefficient
of these concerns were studied and researched to was being measured to calculate the different
determine how 3-phase motors operated and why between the expected, theoretical, and the actual
 19

output power usage. The trend shows a gradual chemistries available on the market as well as the
decline in efficiency as the torque is increased, but it specifiers that were relevant to our project. Important
is very shallow and maintains very steady efficiency terms included: Charge / Discharge Rate, Capacity,
throughout the course of the test. Voltage, and Cell Count. The two forms of batteries
used and tested included Deep Cycle Lead Acid and
Lithium Polymer Batteries; both having specific
qualities that pertained to our mission.

Deep Cycle Lead Acid Batteries were the first

choice because they were the cheapest option, had a
very high discharge rate, and came in the correct cell
count / voltage required for our mission. The
downsides to the Lead Acid Batteries were their large
size and weight, their voltage drop-off after 50%
usage, and their low recharge cycle rate. This meant
Figure 5.13 Turnigy Aerodrive SK3 Brushless DC Motor
Efficiency: Rotational Accuracy Chart
that the lead acids were great for testing but for the
final product, Lithium Polymer Batteries would be
Source: Please refer to [2] selected.

Our test procedures for the Fall semester stipulated

that we would aim to control one or two motors using
the motor control board selected by the Fall semester
senior showcase. This was achieved to some degree
because we had a prototype of the motor mount
designed and built by the mechanical engineering
team. There were issues with the design however; the
design did not hold the motor correctly enough to
prevent friction between the rotating motor and the
surface of the mount. Secondly, the motor encoder
was not mounted to an accurate enough degree to
prevent error. These two issues combined led to the
motor controller constantly receiving corrupt data
that led to failure in our testing. Still, at low speed,
the motors were controllable in both position control Figure 5.14 6 Volt Lead Acid Battery
mode and velocity control mode, meaning we were
Source: Please refer to [31]
successful in our efforts. It is also important to note
that the motors were being controlled on an
embedded SOC, NVidia’s Jetson Nano, for its small Lithium Polymer Batteries are the ideal choice for
form factor and reasonable strength over other most RC applications and fit perfectly into our scope.
similarly sized products. They have the highest energy density of all the forms
available on the market currently but come at a much
E. Battery Management System higher sticker price. They are sold in the form of
common cell counts. Each cell being built to
After researching the motors and motor control maintain a voltage of 3.3V. For our robot to operate
boards, it became necessary to power them properly in the torque and force ranges theorized, we will need
so they could meet our specific current requirements. to use Lithium Polymer batteries that can output
To this aim, the team began studying different types roughly 24 Volts and maintain constant current up to
of batteries. This included the different battery 15-20 Amps. This is no cheap or simple task on its
 20

own. Currently there is a simplistic design being used

to maintain the correct voltage.

Figure 5.15 22.2 Volt Li-Po Battery Figure 5.16 Turnigy Aerodrive SK3 Brushless DC Motor
Source: Please refer to [31] Source: Please refer to [2]
In the Spring, the team increased their goal to The first step of this task required the team to
controlling the motors by adding several feedback implement the correct parameters in the ODrive
sensors. These included limit switches to keep the firmware, so that the ODrive could properly control
motors from running off past their assigned range of the motors. For instance, if we want our motor to spin
motion and time-of-flight sensors that would allow at a specific fixed RPM, then we needed to confirm
the motors to be controlled through distance that our motor is spinning at the desired speed. The
measurements assigned by the user. ODrive may need to know factors such as the type of
motor, the number of pole pairs, and the motor KV
F. ODrive Development and Interfacing to accurately calculate the appropriate parameters to
The BLDC motors that our design will utilize run drive the motor. Once we have effectively configured
on three phases alternating current and it is supplied the controllers, we can then drive the motor at a
by the ODrive Motor Controller. The ODrive will specific RPM using some of the ODrive’s prewritten
provide pulses of current to the motor windings; commands via the Python Library. Now, by using an
which in turn, will control the speed and torque of the external device such as a tachometer, we can
motor. The ODrive already comes with equipped determine the RPM accuracy of the ODrive motor
communication interfaces that can be 6 used to controller with that of the tachometer. If there is
control several aspects of the controller, which noticeable difference in the desired RPM with the
ultimately affect the control of the motors. By using actual RPM; the ODrive Controller also comes with
a communication interface and some of the pre- other parameters, we can adjust to drive the motor at
written commands, we can effectively control a much more accurate speed. However, since
variables, such as: supplied current, supplied voltage, development and support for the ODrive firmware is
maximum rpm, maximum torque etc. of each motor. consistent, the controller should drive the motor
reliably to the desired speed.
 21

The part that would require more work and time to

complete would be modifying the ODrive firmware
so that it uses SPI as its default communication
protocol; and using its built in FREERTOS
middleware, in order to assign tasks and implement
a PID controller. By default, the ODrive utilizes
UART communication to communicate with
external microcontrollers. However, the ODrives
have a STM32F4 chip that is used to program each
of the pins on its board.

Figure 5.17 The ODrive Motor Controller v.3.5

Source: Please refer to [2]

A. System Communication Protocols

The entire control system initially used the SPI
Communication protocol, running at over 1 MHz
Each ODrive would receive the same readings from
the IMUs simultaneously and perform the
appropriate calculations based on their local
parameters i.e. the positions of each motor they are
controlling. In order to accomplish this task, the very Figure 5.19 SPI Communication Protocol
first thing that the team did was set up an MCU as a
Source: Please refer to [28]
master device that would take readings and transmit
them overusing SPI. This is a very trivial step if it is
done using STM’s supported IDE known as
G. PID Controller Implementation
STM32CubeMX, as all we need to do is assign
certain pins to the SPI clock, MOSI, MISO, and A PID system was implemented into the software
GND. The CS (Chip Select) pin would not be used in of the TOF sensors. It worked by taking the user
this design, as all ODrives would receive the same input ‘desired’ distance for the TOF sensor to read.
IMU readings, and they would perform their own That value was compared to a filtered version of
“local” calculations. what the TOF sensor was reporting to the Jetson
Nano.

Figure 5.18 Different Communication Protocols Figure 5.20 MATLAB 3DOF System

Source: Please refer to [6] Source: Please refer to [28]

 22

The comparison result would trigger a PID using the Kinect with the Jetson Nano, we found that
function that would make the motor spin in either the ROS distribution installed (Kinetic) on the Nano
direction until it met its desired position given by the is not compatible with the Kinect and the Operating
user. It did so through a series of functions that System is not compatible with any other ROS
adjusted the speed and direction of the motors at a distribution. Our solution to this problem was to use
decreasing rate as the motor closed in on its desired a simpler much less powerful Logitech monocular
position. More details about this will be discussed in webcam that was compatible with the ROS Kinetic
other sections. distribution. Using ROS, we were able to combine
ORB-SLAM with RVIZ, which is the ROS
H. 3D Point Cloud Generation visualizer and displays the generated map and create
a map at a rate of about 19 FPS. By using a
At the beginning of Fall semester, we were set on
monocular camera to create the map, it was not
having the robotic dog operate semi-autonomously
possible to extract the correct distance from the
while navigating in a 3D point cloud generated map.
camera to the points in the map.
The 3D point cloud map would be generated by
performing Simultaneous Localization and Mapping,
otherwise known as SLAM. Due to the unforeseen
circumstances of the Coronavirus pandemic we were
unable to obtain actual images of our point cloud, but
the figure below shows an example of a generated
map using the ORB-SLAM2 program.

Figure 5.22 ROS Node Graph Example

Source: Please refer to [13]

I. Implementation of Feedback Sensors

1) Inertial Measurement Unit
The IMU (Inertial Measurement Unit) module was
a large portion of our robot’s feedback system that
provided information back to our main computing
Figure 5.21 ORB-SLAM2 Point Cloud Map Example device, the Jetson Nano. The IMU measures certain
Source: Please refer to [18] data such as linear and angular acceleration in the
XYZ axis; some also come equipped with a
Being able to write a program that can perform temperature sensor and magnetometer that can
SLAM is math intensive and could be considered a provide other useful data. In our case, we used the
senior project on its own. To circumvent the MPU 6050 IMU which was able to give us linear and
difficulties of developing a SLAM solution, we angular acceleration; and the temperature readings.
decided to use an existing one in the form of a Robot
Operating System (ROS) node. ROS allows robotic
developers to use open-source programs to perform
robotic specific actions. We initially decided to use a
XBOX One Kinect camera because it has a built-in
stereo camera, infrared sensor, 50 degree field of
view, and can be found for an extremely cheap price.

Unfortunately, after roughly two weeks of

implementation and troubleshooting of the SLAM
 23

both data plots were compared, we expected to see a

considerable difference in the data plotted as the
noise variable has a profound effect on the
accelerometer and gyroscope data. The consistency
of the calibrated IMU was another requirement in our
device test plan. To do this, we utilized two
calibrated IMUs and perform some specific-
controlled movements on them to collect the data.
The movements should be nearly identical so that no
Figure 5.23 9DOF IMU factors from this variable should be considered as
much as others.
Source: Please refer to [22]

The development platform that we utilized for the

first semester of Senior Design was
STMicroelectronics’ proprietary and free to use
software: STM32CubeMX. The software allowed us
to efficiently configure initialization settings for the
microcontrollers we were going to use and allowed
code generation to be much faster. Figure 5.24 IMU Angular Velocity Calculation Process

The IMU is a very sensitive device and is quite Source: Please refer to [11]
easily susceptible to noise from the environment. In
addition, there hadn’t been any previously developed
library in order to interface the IMU with our specific
board. Thus, this was the very first feature that the
team worked on the beginning of the semester.
Designing a library for hardware interfacing is a very
tedious and complicated task. It required quite a bit
of time to debug and test the functions of the library
were performing the expected operations;
nonetheless, once every aspect was tested, we were
able to effectively interface the MPU6050 with the
STM32F303K8 NUCLEO board. Our designed
utilized the DMA, NVIC, and I2C features of the
board in order to efficiently capture data from the
IMU.
Figure 5.25 A look into the MPU6050 and the different
Moreover, once we retrieved the data, another readings it takes at different axes.
problem arose and that was data calibration. This was
Source: Please refer to [4]
another feature that we worked on in the beginning
of the semester, and that was to use filtering
techniques to clean up our sensor data. By simply When we compared the plotted calibrated data
applying a complementary filter when writing the with the uncalibrated plotted data, we saw that there
interfacing software, we can filter out a great portion were “spikes” in our acceleration plot when we jolted
of the noise and have reliable readings. The testing the IMU back and forth. For the angular position plot
procedure for the IMU was exactly as outlined in our there should be a steady drift of the readings over
Device Test Plan. The team used a plotting library in time for the uncalibrated IMU. For the calibrated
Python in order to plot the uncalibrated readings of IMU, the readings for both the position and angular
the IMU with that of the calibrated readings; When position should fairly remain stable even with sudden
 24

movements. There should be no drift on the angular be the VL6180X, capable of reading the distance
position plot, the plot should remain relatively stable between 5mm to 200mm, developed by
when the IMU is stationary. STMicroelectronics and the breakout board was
supplied by Adafruit. The sensor interfaced via the
2) Time-of-flight Sensors I2C communication protocol and did have a fixed
ODrive Robotics is still in the process of updating address of 0x29 with no possibility of changing it in
the board’s firmware to support absolute encoders Python without it losing its new address when turned
which allows us to determine the absolute position of off; in other words, the sensor did not have any non-
the BLDC. The current firmware, however, only volatile memory.
supports rotary incremental encoders which can only
provide the angular velocity and index signal which For us to read from multiple TOF sensors we
is like the way a bookmark function. Incremental needed an I2C multiplexor. We used the TCA9548A
encoders can be used to find the absolute position but 8-to-1 I2C multiplexor which had a Python library
was deemed impractical to have our robot perform a supplied by Adafruit decreasing the development
homing sequence on every startup. The other reason time. After wiring up the Jetson Nano I2C bus to the
it was deemed impractical was because the BLDC I2C Mux, where the Mux was wired up to the
motors would be driving a pulley which in turn appropriate pins on the TOF sensor, we were able to
rotates the rod moving the ball screw carriage along read from the sensors at a rate of about 400kHz.
the road. The way the actuation works would be
prone to slippage, thus making the homing sequence 3) Rotary Encoders
pointless as slipping occurs. The incremental rotary encoders are used to
determine the angular velocity of the BLDC motors
Our solution of obtaining the absolute position of and ODrive Robotics built-in a safety feature in their
the ball screw carriage was to use a Time-of-Flight boards preventing the motors from reaching a certain
sensor that would read off a flat surface attached to speed without encoders mounted and connected.
the carriage. The figure below shows a diagram of Implementing the rotary encoders was plug-and-play
how it would work for our application. due to the simplicity of the ODrive tool. We just
needed to set up the encoder specifications into the
boards such as the CPR (counts per revolution),
encoder type, and index signal. After setting up the
encoders we were able to have full control of the
BLDC motors.

4) Long Range Communication/Camera

In order to make the robotic quadruped operate
semi-autonomously, the team also proposed adding
long range functionality to the project. The idea was
to have a first-person view (FPV) camera on the front
of the robotic quadruped in order to have an image
Figure 5.26 TOF Sensor Application transmitted back to us to aid in search and rescue
operations. This is normally a wide-angle camera to
Source: Please refer to [6] give you a full view of the data that is in front and
near the robotic quadruped while under operation.
We were using the TOF sensor as feedback for
The camera will then need to be connected to a
motor control using the ODrive boards for
transmitter to send the data images to a computer or
commands. Each motor would need a TOF sensor as
screen fast enough to get accurate representation of
feedback so we would need 12 TOF sensors for the
the surrounding area while under operation.
12 BLDC motors, we were only able to get a single
leg working with 2 degrees-of-freedom, so we only
To properly test this, first we needed to setup and
implemented 2 sensors. The TOF sensor we used to
connect the FPV camera to a board in order to make
 25

sure we can get images and data from the camera at us to take a realistic look at what was achievable,
real time. Once we have the camera working and how long each core component of the project should
transmitting data to our computer, we then needed to take, and how to partition the workload into sub-
setup the transmitter and receiver in order to be able categories. By doing such partitioning, we were able
to move the camera freely and still be able to transmit to assign tasks to members and track their progress
data to our computer. After we get these both setup to what we had originally estimated.
and working, the next part would be to test them. The
things we tested were the resolution of the camera to Some of the original estimations were off,
make sure it meets the specifications, the response however. Timing on a project like this can be tricky
time of the camera and how fast the data is sent back to calculate accurately. But having these charts
to the computer, and the distance of how far the allowed us to adjust timing and stay on track without
signal we will be able to get before the signal is developing ‘tunnel vision’.
cutout or the response time is unusable. In order to
test the resolution of the camera, we can see the B. Work Breakdown Structure Diagram
resolution on our computer as well as if the images
sent from the camera are pixelated. The next thing to
test is the response time in which we can see in code
how fast the data is sent back to us as well as moving
objects in front of the camera and seeing if there is a
delay in the image we see on our screen. The last
thing to test is the distance of the signal of the
transmitter/receiver, and we would test this by going
outside and measuring the distance of how far we can
move before the images become unusable due to the
signal being weak.

J. Full-Scale Model Leg Prototype

To reach the point of leg control, the TOF sensors
and encoders needed to be implemented beforehand.
After we set up the ODrive boards and confirmed
that we were able to control the leg without feedback,
we wrote a Python module that utilized all of the
necessary libraries such as the ODrive tool, sensor
implementation, and other libraries we wrote to
compute the kinematics. Source: Please refer to [6]

VI. WORK BREAKDOWN STRUCTURE C. List of Tasks & Hours Invested

A. Brief Description Feature Team Member Hours Invested
The project was coordinated with a work Full-scale Model Edgar Granados 30 Hours
breakdown structure, WBS, as specified by the Leg Electronics Marcus Huston 30 Hours
guidelines of the course. This was the team’s first Kristian Ornelas 30 Hours
time using such tool as a time management device Alfred Martinez 30 Hours
and it proved to be greatly beneficial on multiple Full-scale Model Edgar Granados 30 Hours
occasions. For one, the WBS served to help us decide Kinematics Marcus Huston 30 Hours
what bits could be fractioned up and placed on a Kristian Ornelas 60 Hours
timeline before beginning research and development Alfred Martinez 30 Hours
on our project. Since the WBS diagram, was required
to be developed early in the course, it forced each of Edgar Granados 30 Hours
Marcus Huston 30 Hours
 26

Small-scale Kristian Ornelas 20 Hours when we encountered unforeseen problems during

Model Alfred Martinez 30 Hours development.
Electronics
Small-scale Edgar Granados 30 Hours
Model Marcus Huston 30 Hours
The last way we fought against this risk was by
Kinematics Kristian Ornelas 45 Hours putting the time in to learn what we needed and spend
Alfred Martinez 30 Hours the necessary amount of man hours to complete the
tasks with the level of difficulty taken into
Camera System / Edgar Granados 30 Hours consideration.
Software Marcus Huston 30 Hours
Kristian Ornelas 80 Hours
Alfred Martinez 30 Hours B. Embedded System Development Time
1) Risk Description
Power System Alfred Martinez 20 Hours
Source: Please refer to [6]
The amount of time to develop an embedded
system can be time intensive and difficult when
compared to a high programming/scripting language.
The plan was to program the ODrive boards in C but
VII. RISK ASSESSMENT with the combination of our other courses, the
Every engineering project will have risks involved workload in senior design, and the time necessary to
but a good engineer will try to seek out those risks implement robotic applications in an embedded
beforehand and take the necessary precautions to system.
avoid said risks. This section will examine the risks
we identified and what steps were taken to mitigate 2) Mitigation Techniques
them. After we realized just how long the development
time of the robotic dog in embedded C would be, we
A. Lack of Technical Experience decided to control the large-scale leg using a
1) Risk Description combination of the ODrive tool library and Python.
The technical skill and experience required will Due to the large number of mathematical libraries for
vary project to project, but this robotic quadruped did performing matrix operations, ODrive Robotics also
need a fair amount of both skill and experience. The converted the ODrive tool into a Python library
risk related to our lack of technical skill and capable of issuing commands to the motors using a
experience is that we would not be able to move the Python script.
project forward and plateau our development.
C. Scheduling Conflicts with Mechanical
2) Mitigation Techniques Engineering Team & Schoolwork
The steps we took to help mitigate this risk 1) Risk Description
included the following: consulting with our lab In the demanding major of any concentration in
instructors, research, and time. With our limited engineering making sure everyone on the team can
knowledge, a great resource we took advantage was meet to discuss project topics or to work on the
consulting with Professor Levine and Professor project tasks, this becomes even more difficult as our
Thomas for advice on how to proceed. Their team consists of four EEE/CPE members and four
knowledge and experience were invaluable to our ME members. The specific risk involved is that if the
overall project progress. team members cannot meetup based on their
availability, then the project cannot move forward.
We were extremely out of our comfort zone for this
project and needed to do the proper research on 2) Mitigation Techniques
robotics, various types of actuators, batteries, etc. By The primary way we mitigate this risk was to
doing extensive research we were able to arm maintain constant communication for updates and
ourselves with knowledge to better prepare ourselves use a user-friendly phone application capable of
communicating over most devices. Luckily everyone
 27

on our team had a compatible device so contact was analyze the market and decide between a wheeled
able to remain. robot or a legged robot. A wheeled robot is easier to
design and operate which makes it more stable, but
the downfall of a wheeled device is that it cannot go
D. COVID-19 / Campus Closure over complex material. This made us choose a legged
1) Risk Description robot since we could program it to be able to walk
This particular risk is one that most of the world over obstacles as well as stay balanced when moving.
was not prepared for. The risk in this case was that After we decided we wanted to make a robotic
the CSUS campus would need to be shut down in quadruped, we talked to the mechanical engineering
order to minimize the spread of the virus and team into designing what materials would be best
advocate social distancing. If the campus would be used as well as how the legs would move.
closed then we would no longer have access to the
B. Prototyping Philosophy
labs in Riverside Hall despite our FOB keys, thus,
continuing our work would be a significant challenge Once we decided on a robotic quadruped, we
with no workspace. wanted to start prototyping in order to start working
on the code since we knew it would be a long and
tedious process. This gave the mechanical
2) Mitigation Techniques engineering time to come up with an idea of how the
The mitigation we took for this risk was to final robotic quadruped will look like as well as how
continuously work on our written assignments from it will move. Our first idea was to make a quick
home and communicate over a virtual meeting prototype that would be cheap, easy to make, and fast
application. Fortunately, the project was expected to to build. The first prototype we created was a
be finished just a few days before the campus was cardboard model with servos and an Arduino
officially closed and did not require us to be on microcontroller. This made it cheap to make as well
campus to work on the project. as fast and easily programmable. Creating the first
prototype gave us time to start learning about the
VIII. DESIGN PHILOSOPHY
walking gaits as well as the kinematics it would need
The Societal Problem that we wanted to address is in order to walk without falling over. Once we got
that disasters happen every year and are some walking gates programmed and tested, we ran
uncontrollable which increases the need for search into issues once we started to speed up the walking
and rescue workers which means the danger they put gaits. The issue we ran into was the grip at the end of
themselves into rises as well. We aim to create a the cardboard robotic quadruped legs were hard to
design to help lower the chances of injury and keep get grip since most tables were slippery as well as
more people safe by creating a semi-autonomous being made out of cardboard. We tested out gluing
robotic quadruped. This section goes through and rubber bands to the feet to produce more grip against
will cover how we approached solving our societal the slippery surface but only helped so much. After
problem and how we decided a robotic quadruped we came across this issue and attempted to fix it, we
would be a solution. decided it would be best to make a bigger more
A. Brainstorming Philosophy complex robotic quadruped that we could design to
walk better. The second prototype we designed was
In order to come up with a solution to our societal
a little bigger 3d printed robotic quadruped with high
problem, we had to understand the societal problem
torque servos as well as an STM32 board to control
in a greater depth as well as what products are out
the robotic quadruped. This made it so our robotic
there that can be a solution to the problem. The first
quadruped had even legs, a perfect body, as well as
thing we had to look at was the main type of disasters
stronger servos that could support the body while
that happen every year and which type of disasters
under pressure walking. With the new prototype
that we wanted to focus on. Since disasters are such
built, we were able to program and test different
a complex topic, we decided to choose a narrower
walking gaits as well as faster moving gaits and even
topic which is to aid the disaster workers with a robot
bouncing in place. Once we reached this point in the
designed to help with search and rescue. We had to
process, the mechanical engineering team came up
 28

with a complete design for our main robotic origin or “balanced” state, and as the dog transitioned
quadruped. The only issue was that we had to wait into its walking gait, the algorithm would begin to
for parts to come in as well as machining for some of drive the appropriate controls to the servos; in order
those parts that a professional would have to take to, maintain the system’s stability. For the larger
care of. Instead of waiting for a long time and doing scale model dog, because the team was able to
nothing, we came up with ideas that we could work calculate and produce the kinematic equations for
on as features that we could add to the main robotic this system as well, the same control algorithm could
quadruped. We also worked on building one leg that also have been used. We had proposed using the
we can start coding on to give us an idea of how big Jetson Nano Development Board as the main “brain”
and how to control the brushless motors. The leg of the system in which it would communicate with
consists of O-drives, brushless DC motors, encoders, the sensor modules (IMU and TOF Sensors), and
and metal rods. In order to control the legs, the TOF with the ODrive Motor Controllers to control the
sensors and encoders needed to be implemented motors. The only main difference between the small-
beforehand. After we set up the ODrive boards and scale model and larger scale model would have been
confirmed that we were able to control the leg the TOF sensors, but nonetheless, we could have
without feedback, we wrote a Python module that incorporated this difference within the ODrive
utilized all of the necessary libraries such as the Feedback System and modeled this as a servo in the
ODrive tool, sensor implementation, and other small-scale model. Unfortunately, because of the
libraries we wrote to compute the kinematics. This unexpected events that had occurred due to the
gave us a fully built leg with control of it as well as COVID-19 pandemic, several of our resources and
a small prototype with walking gaits and kinematic facility equipment were restricted to us. And with the
equations to step distances. This gave us a big idea lockdown order and social distancing regulations put
of how to program the full built robotic quadruped as in place by our local government, our development
well as basic control of the legs. We would just need time was tremendously impacted. Even though the
to combine everything we had into one big robotic team was unable to assemble the full-scale model
quadruped. This leads to our final deployable dog, all the components needed to have a working
prototype. robotic system were designed and tested. Thus, in
theory, our full-sized model would have been able to
IX. DEPLOYABLE PROTOTYPE STATUS stand and maintain its stability if all these
A. Brief Description components had been integrated together and tested.
The next sections will discuss the testing results and
In the end of the Spring semester, our final
parameters that were designed by our team; and how
deployable prototype included a small-scale model
they related to our measurable metrics and final
system capable of maintaining its walking gait and
feature set.
stability by using an IMU module as the feedback
device. In addition, the team was also able to design
the kinematic and control program for a large-scale B. Prototype Performance
model leg. The large-scale model leg could move to This section will present a detailed overview and
a chosen position given by the user to a very accurate outline of the performance of our deployable
degree. It also utilized feedback modules such as prototype and give specific information of each of
TOF sensors, Rotary encoders, and a motor driver to the components used. It will give a general
appropriately control the speed and required torque explanation and background information of the
of each individual motor. The small-scale robotic component module, the manufacturer’s
dog had the potential of being able to accurately specification, testing procedure, and testing results.
maintain its stability and walking algorithm even if Lastly, the overall performance of the final prototype
changes in its environment were introduced. will be examined and how applicable it would be in
Although the team was not able to fit the IMU sensor real world situations.
module onto the small dog; in theory, the control
algorithm that was written should have gotten an
initial reading of the dog, set the initial reading as the
 29

1) Inertial Measurement Unit Performance According to the manufacture specifications, the

This section highlights the listed test procedures modules support I2C communication protocol with a
for the Inertial Measurement Unit. Covering the maximum clock frequency of 400 KHz. The
sensor’s purpose, listed qualities from the accelerometer can output readings at 1,000 Hz with
manufacturer, and, of course, the tests conducted on a maximum output value of ±16 g. For the
the device to determine their accuracy. gyroscope, it can represent an angular velocity value
The purpose of the device testing procedure for the of up to 2,000 °/s at a maximum data rate of 8000 Hz.
Inertial Measurement Unit is to determine whether The power requirements for the breakout board that
the modules can accurately take readings from each contains these sensors can operate at voltage levels
of the sensors. Hardware defections and noise from 2.375-3.46V respectively. Lastly, both modules
sensitivity are some of the most common errors that contain a series of 16-bit ADCs that are used to
arise from sensor data. In general, the most common convert the analog signals from the sensors and write
way to correct the data is by utilizing software it to the FIFO Buffer which can later be read through
filtering algorithms such as low pass, the IMUs registers. Further feature customization
complementary, the Kalman filter. Once the data has can be performed by writing to specific registers in
been corrected, the measurements will then be used the IMU module.
in the control algorithm that will adjust the positions
of the servos, so that the entire robot system
maintains its stability. To do this, during the
initialization of the robot, it will be placed in a static
starting position. Then the system will capture the
readings from the IMU and set this orientation as the
origin point. Now, as the robot begins to transition to
its walking gait; anytime there is a fair enough
deviation from the origin point, the algorithm will
adjust the position of the servos so that the system
tries to maintain stability based on initial readings of
the IMU.

Figure 9.2 MPU6050 Register Map

Source: Please refer to [4]

Two steps were done to demonstrate the noise

sensitivity correction as well as the hardware
functionality. As previously mentioned, one of the
most common issues with IMU readings is
susceptibility to noise. Luckily by applying simple
Figure 9.1 MPU6050 IMU filtering algorithms we can compensate for this issue.
In our design we utilized a complementary filter to
Source: Please refer to [4]
correct the data that was being received from the
The Inertial Measurement Unit used in this design IMU. The characteristics of the accelerometer is that
is an MPU6050 IMU module in which it comes it tends to suffer from sudden jitters and spikes in its
equipped with a 3-axis accelerometer, temperature readings; nonetheless overtime the readings are
sensor, and 3-axis gyroscope. The accelerometer and fairly accurate. For the gyroscope the readings are
gyroscope can take measurements in the x, y, and z very precise, however, the gyroscope suffers from
axis of an object. Using these readings, we can then drift due to integrating over time. When we apply a
calculate the roll, pitch and yaw of an object. complementary filter, we effectively take the
 30

advantages of both accelerometer and gyroscope,

fuse the data, and get a very accurate estimation of
what the reading should be. The filtered data does not
suffer from these random spikes in readings nor does
the data drift as time passes. The following plotted
data demonstrates the calculated Roll Angle of the
IMU using the accelerometer, gyroscope, and
complementary filter. The test utilized two IMUs in
order to determine whether there were any hardware
issues with the IMU. The data demonstrates that both
IMUs had very similar readings when plotting the
roll angle; thus, we can conclude that the data given
off the IMUs was accurate and there were no
hardware problems.

Figure 9.4 . IMU #2 X-Axis Rotation Filtered versus Unfiltered

Source: Please refer to [6]

2) Brushless DC Motor Performance

The BLDC motors were a primary component of
the device. They were to be attached directly to ball
screws to create custom linear actuators. This design
went through several iterations, but the most current
iteration includes the motor being attached via metal
spring coupler to the rod directly.

Since the design was immature and the device

specifications are not entirely known, motors were
selected that would overcompensate for any weight
Figure 9.3 IMU #1 X-Axis Rotation Filtered versus Unfiltered requirements thrown at it. This meant that the test
Source: Please refer to [6] motors came at a higher cost, higher current
consumption, and higher weight, but this allowed us
to find which speeds and torques worked best for us
situation. The motors were selected after researching
hobby RC maker projects and other engineering
projects. By ordering these types of motors, we were
able to see them in use in many examples online to
see expected results. Industrial level motors were out
of the budget supplied to us as well as the typically
too bulky. BLDC Motors have several benefits over
regular Brushed DC Motors. They are typically 85-
90% efficient, whereas brushed motors are typically
60-70% efficient. They are lighter for equivalent
torque, have a longer lifespan, and are quieter due to
 31

less contact between parts. The specifications of Source: Please refer to [6]
BLDC Motors can be hard to comprehend at first.
In the python scripts used to control the motors then
legs, the RPM was controlled by adjusting the
The most significant specification for our purposes
number of encoders clicks every 100 milliseconds in
was the KV Rating – the measure of revolutions per
a constant while loop. We were able to control the
minute given 1 volt and no load. The RPM can
motor to a very accurate degree after overcoming the
therefore be estimated by multiplying the voltage
current limiting issues and attaching the encoder to
given to the motor by its KV rating. In our case, 24
the motor mount with more stability.
volts is being constantly supplied to the motors. Our
specific motor has a kV rating of 192.
3) Time of Flight Sensor Performance
The purpose of the time-of-flight sensors are to
Max Speed = (192kV) * (24 volts) = 4608 RPM
provide the position of the carriage along the rod
where the carriage corresponds to a specific angle of
The motors were tested for their ability to hold
the limbs which in turn, allows the robot to perform
specific RPM specified by the user through software.
various gaits. The time-of-flight we decided to use is
This was considered an integral component to the
the VL6180X which is manufactured by
project because we needed to have accurate control
STMicroelectronics. The sensor does not come
of the motor’s speeds and rotary positions along the
installed on a breakout board but Adafruit does
ball screw. Without the motor tests conducted
manufacture a breakout board capable of operating at
accurately; we could not proceed to controlling the
any voltage between 3V-5V. The sensors used were
angles of the leg joints on the robot accurately. This
chosen because their features aligned with what our
would then prevent us from properly being able to
project required. The sensors are primarily designed
control the walking motion and balancing of the dog.
to read on the range of 0mm to 100mm with a
The specific test conducted on the motors was to
potential to read higher ranges depending on the
control their RPM by using encoders mounted to the
surface reflectance of the object and ambient
spinning shaft in their center axis. The specific
conditions. The sensor can only be interfaced using
sensors used were the CUI AMT102 Capacitive
the I2C bus. So, the sensor is limited to reading at a
Encoders. They have a rotational resolution of 8192
rate of 3.2Mbit/s but the Adafruit library that allows
points per rotation [CPR], and a maximum reading
our single board computer to interface with the
speed of 7500 RPM. This meant that all there was
sensor was limited to 4Kbit/s.
left to do was write the script to control the encoder
reading and motors then test them to an external
metric. The external metric used was a standard
Tachometer which measured the side of the motor as
it rotated. This allowed for a quick and accurate
comparison between the RPM external reading and
the input value from the software.

Figure 9.6 VL6180X

Source: Please refer to [6]

In order to verify that the VL6180X sensor was

working properly and providing accurate readings
for feedback. The figure below shows a top-level
diagram of the test procedure setup.

Figure 9.5 CPR/10th of Second & RPM Comparison

 32

The percent error was consistently under 10%

which is small enough for the sensors to fulfill their
purpose.

X. MARKETABILITY FORECAST
A. Increase Marketability Discussion
Robotics is an interdisciplinary branch of
engineering and is normally a programmable,
mechanical device used in place or to help a person
to perform tasks with a high degree of accuracy. This
opens a huge world of possibilities, from large,
intricate systems to small common daily used
items. Robots are seen everywhere and have
integrated into our society and daily lives. These
inventions are changing the way we live and work.
Robots can be used in many situations and for lots of
purposes.

Figure 9.7 TOF Sensor Testing Procedure (Top-View) When it comes to the potential consumers that our
quadruped robot can be aimed toward, the most
Source: Please refer to [6] obvious buyer could be government agencies, such
as the military. The global military robot market is
The first step in the test procedure was to setup the
projected to grow to 30.83 billion by the year 2022.
TOF sensor directly aligned with an object. Then a
This expansion in the market is due to developing
tape measurer was placed along the side of both the
countries such as India, China, and Russia adopting
object and sensor. A Python script was written to
these technologies and increasing their research
read the data from the sensor and calculate the
budget. One of the main drivers that seems to project
average of ten samples. The average was compared
success in this consumer market is the military’s
to the actual range from the tape measurer. This
focus on using robots as an alternative for human
sequence was done for every inch starting at a range
soldiers for specific tasks. For instance, our
of 1 inch to 8 inches. The percent error was then
quadruped robot has the capabilities of being
calculated comparing the measured range and the
deployed in situations which would be too dangerous
actual range. See Table 9.1. for the test results of this
for actual human personnel. Such situations could
test procedure.
include providing medical assistance to wounded
soldiers, or even traverse through a hostile
Tab. 9.1 TOF Test Results
environment. One of the advantages that our robot
Actual Measured Percent Error could potentially provide; and at the same time take
Distance (mm) Distance (mm) (%) advantage of, is the emphasis in legged locomotion.
The use of legged robots over their wheeled
25.4 23.2 8.66
counterparts is that they provide the advantages of
50.8 45.8 9.84 traversing through uneven terrain and maintain
76.2 70.4 7.61 dynamic stability.
101.6 97.8 3.74
127.0 119.0 6.30 Moreover, because the design of our robot has the
152.4 142.8 6.30 attribute of being highly portable toward other
177.8 162.4 8.66 applications, another potential consumer market
203.2 184.8 9.06 could be in the logistics robotic market. The global
Source: Please refer to [6] logistics robot market is expected to reach around
11.8 billion by 2022. Logistics robots are used to
 33

automate the process of storing and moving products board or microcontroller that can handle everything
as they are packaged through the supply chain. As that the Nvidia Jetson Nano does as well as the O-
companies, such as Amazon continue to experience drives. The idea would be to simplify the boards into
rapid growth and dominate the ecommerce domain; one complete board with only the correct number of
the demand for faster and more efficient logistical inputs and outputs to control everything that is
strategies will need to be considered for the ever- needed on the robotic quadruped. This will simplify
expanding group of customers. According to the wire management throughout the robot as well as
Tractica Research Group, “worldwide shipments of draw less power throughout the entire system so then
warehousing and logistics robots will grow rapidly the robotic quadruped could run longer and more
over the next 5 years.” In fact, they predict that the efficiently. With combining all the boards into one,
number of units will increase from 194,000 in 2018 it will clean up the robotic quadruped, give less room
to 938,000 by 2022. As previously mentioned, for hardware errors, as well as lower the cost in
because our robot can be ported into other creating the robotic quadruped. With changing some
applications, the use of it as a logistical robot could of the hardware and lowering the cost, that would
be a viable option to meet the market demands of the make the robotic quadruped more marketable.
logistic robotic industry.
2) Software
In order to fully understand where a project will fit The next area that would need improvement before
within an existing market or industry. One must the robotic quadruped is ready for manufacturing is
examine what products their project will be the software that is being ran for the robotic
competing against. Robotics is not an entirely new quadruped. Currently the robotic quadrupeds’
area of study but the marketing and retailing of movements are mostly controlled through the O-
robots is relatively new. With the robotics industry drives which take a lot of lines of code which makes
still in its infancy, a semi-autonomous quadruped it less efficient and more prone to errors. Also, in
will be able to find a place amongst its competition. order to make the robotic quadruped more
The SPOT, in our case, would be the primary marketable, we would need to add more software to
competitor of our robotic quadruped. The SPOT make the robotic quadruped more functional as well
features include speed of 1.6 m/s, 90-minute runtime, as stable. With updated software and more testing,
swappable battery, 360 degrees of vision for the code, the robotic quadruped would become more
autonomy, and customization options. The autonomous as well as dynamically stable. This
applications that Boston Dynamics claim to be means that the robotic quadruped would be smarter,
suitable for the SPOT are construction, oil/gas, faster, and more stable. With more testing and more
entertainment, and public safety. Our robotic features, it would make the robotic quadruped better
quadruped would be primarily competing against the for more applications as well as more marketable for
SPOT in public safety. In order to compete with what it can do.
something such as the SPOT, we would need to make
some changes to our robotic quadruped. 3) Construction
The last area that would need improvement to
B. Necessary Changes for Manufacturing make the robotic become more marketable and
readier for manufacturing is the construction of the
With the cost of creating the robotic quadruped
robotic quadruped. To improve on cost, it would be
being approximately $4000, in order to sell it as a
beneficial to have a company produce the
product and ready for manufacturing, as well as
construction of the robotic quadruped in bulk. It
compete with other products, then we would need to
would also be better to make the robotic quadruped
make some changes to the hardware, software, and
not as big and heavy. Using lighter materials and
construction of the robotic quadruped.
making it smaller would make the robotic quadruped
more efficient as well as cost effective. Another thing
1) Hardware
that the robotic quadruped will need is protective
In order to get the robotic quadruped ready for
encasement for the legs as well as the body to make
manufacturing then we would need to create a PCB
 34

sure the wires and boards to not get harmed as well [4] “MPU-6050 GY-521 3-Axis Accel & Gryo Sensor
as for user’s safety. Module,” ProtoSupplies. [Online]. Available:
[Link]
accel-gryo-sensor-module/.
With changing the hardware, software and
construction of the robotic quadruped, it will make [5] “Number of recorded natural disaster events,” Our World
the robot, lighter, smaller, smarter and most in Data. [Online]. Available:
importantly at lower costs. The idea is to change the [Link]
events.
hardware into one microcontroller/ board, use lighter
constructing materials, as well as modifying the [6] Alfred Martinez III, Edgar Granados, Marcus Huston and
code/ software to make the robotic quadruped Kristian Ornelas, “Search & Rescue Robotic Quadruped,”
smarter and more capable of completing its tasks. All Dept. Elect. Eng., CSUS., Sacramento, CA
and all, it would not be very hard to do, just smaller
[7] B. Yirka, “Robot snake automatically wraps around an
adjustments and testing to make the robotic object when thrown (w/ Video),” [Link], 22-Mar-2013.
quadruped ready for manufacturing and ready for the [Online]. Available: [Link]
market. [Link].

XI. CONCLUSION [8] BBC World. National Interagency Fire Center (NFIC),
2017.
With the increasing number of natural and non-
natural disasters there is a demand for solutions to [9] Boston Dynamics [Online]. Available:
aid or assist in saving as many lives as possible as [Link]
well as minimizing the cost of said disasters. This
[10] D. Kumar and V. Divakar, “SPY ROBOT USING SELF-
demand along with the advancements in BALANCING ALGORITHM WITH PAN AND TILT ...”
technology, even more so in the fields of robotics [Online]. Available:
and automation, is enough reason for the [Link]
development of a semi-autonomous robotic ion/281746636_SPY_ROBOT_USING_SELF-
quadruped. Although this specific project will take BALANCING_ALGORITHM_WITH_PAN_AND_TILT_C
ONTROL_OF_CAMERA/links/55f6ee1108aeafc8abf51ed6/S
multiple years to complete and will need to be PY-ROBOT-USING-SELF-BALANCING-ALGORITHM-
optimized better both electronically and [Link].
mechanically, the benefits of aiding in search &
rescue operations that could potentially save lives is [11] David Wooden, Matthew Malchano, Kevin Blankespoor,
insurmountable. When this very complex project is Andrew Howard, Alfred Rizzi, Marc Raibert, "Autonomous
Navigation for BigDog", IEEE International Conference on
finally completed by several teams of Robotics and Automation.
undergraduates, what could possibly be as exciting
is what projects in advanced robotics does industry [12] Department of Conservation.
have in store for us.
[13] Dr. Asad Yousuf, Mr. William Lehman, Dr. Mohamad A.
REFERENCES Mustafa, Dr. Mir M Hayder, "Introducing Kinematics with
Robot Operating System (ROS)", 122nd ASEE Annual
[1] “*Gait* - Physical Therapist Assistant 180 with P. Hill at Conference & Exposition.
Washtenaw Community College,” STUDYBLUE. [Online].
Available: [14] F. Tedim and D. Roye, Imprensa da Universidade de
[Link] Coimbra, 2020.

[2] “54V, 1.5kW, >99% Efficient 3-Phase BLDC Drive [15] G. Kenneally, A. De, D. Koditschek. “Design Principles
Reference Design,” [Link], 26-Aug-2019. [Online]. for a Family of Direct-Drive Legged Robots.” IEEE
Available: [Link] ROBOTICS AND AUTOMATION LETTERS, VOL. 1, NO.
phase-bldc-drive-reference-design/. 2, JULY 2016.

[3] “Facts Statistics: U.S. catastrophes,” III. [Online]. [16] H. P. Moravec, “Robot,” Encyclopædia Britannica, 27-
Available: [Link] Nov-2019. [Online]. Available:
catastrophes. [Link] .
 35

[17] Huang, W., Kim, J., and Atkeson, C. (2013). Energy- [28] O. Takehiko, K. Hajime, O. Hock, J. Šedo, E. Raju, L. S.
based optimal step planning for humanoids. In 2013 IEEE R. Krishna, N. Rao, M. A. Rusafi, M. Billal, F. Yasmin, S.
International Conference on Robotics and Automation Iqbal, and A. Talli, “Inverse kinematics problem of 3-DOF
(ICRA), pages 3124–3129, Karlsruhe, Germany robot arm in 2D plane. (a) Three...,” ResearchGate, 31-Jul-
IEEE Entity Web Hosting - Home. [Online]. Available: 2018. [Online]. Available:
[Link] [Link]
[Link]. problem-of-3-DOF-robot-arm-in-2D-plane-a-Three-joints-
and-an_fig3_46401997.
[18] Ilya Afanasyev, Artur Sagitov, Evgeni Magid, "ROS-
Based SLAM for a Gazebo-Simulated Mobile Robot in [29] P. Sayta, “Thermite Firefighting
Image-Based 3D Model of Indoor Environment", International Robot,” #InnovationVibe. [Online]. Available:
Conference on Advanced Concepts for Intelligent Vision [Link]
Systems, 2015.
[30] S. A. Archfield, R. M. Hirsch, A. Viglione, and G.
[19] Introducing SpotMini. Boston Dynamics. Blöschl, “Fragmented patterns of flood change across the
[Link] United States,” AGU Journals, 09-Oct-2016. [Online].
Joel Chestnutt, Navigation Planning for Legged Robots. Available:
[Link]
[20] K. Reid, “2011 Japan earthquake and tsunami: Facts, GL070590.
FAQs, and how to help,” World Vision, 29-Feb-2020.
[Online]. Available: [Link] [31] S. Seok, A. Wang, D. Otten, and S. Kim, Actuator design
relief-news-stories/2011-japan-earthquake-and-tsunami-facts. for high force proprioceptive control in fast legged
locomotion, 2012 IEEE/RSJ International Conference on
[21] Kalouche, Simon. “Design for 3D Agility and Virtual Intelligent Robots and Systems, 2012.
Compliance Using Proprioceptive Force Control in Dynamic
Legged Robots.” The Robotics Institute Carnegie Mellon [32] Snapolitano, “The Future of Disaster Relief Includes
University, Carnegie Mellon University, Aug. 2016, Drones and AI,” U.S. Chamber of Commerce Foundation, 07-
[Link] Jun-2018. [Online]. Available:
and-virtual-compliance-using-proprioceptive-force-control-in- [Link]
dynamic-legged-robots/. disaster-relief-includes-drones-and-ai.

[22] Kenta Takaya, Toshinori Asai, Valeri Kroumov, GLOSSARY

Florentin Smarandache, "Simulation Environment for Mobile
Robots Testing Using ROS and Gazebo", 20th International
Conference on System Theory Control and Computing Robot: a programmable machine capable of carrying out
(ICSTCC), 2016. complex actions

[23] Kuindersma, S., Permenter, F., and Tedrake, R. (2014). Quadruped: an animal which has four feet
An efficiently solvable quadratic program for stabilizing
dynamic locomotion. In IEEE Intl. Conf. on Robotics and Inertial Measurement Unit (IMU): an electronic device that
Automation (ICRA), Hong Kong, China. measures and reports a body’s force, angular rate, and
orientation
[24] M. Shuman, “Fire risk leaves Tuolumne County residents
scrambling to find affordable insurance,” modbee, 16-Jul- Time-of-Flight Sensor: an electronic device that measures and
2019. [Online]. Available: reports distance using an infrared light transmitter and
[Link] infrared light receiver.

[25] M. Simon, “Watch Boston Dynamics' Robot Dog Strut Autonomous: capacity to make an informed decision
Through a Construction Site,” Wired, 12-Oct-2018. [Online].
Available: [Link] Incremental Encoder: an electronic device that provides
prepping-its-robot-dog-to-get-a-job/. rotational position changes

[26] Marc Sons, Christoph Stiller, "Efficient Multi-Drive Map Brushless DC Motor (BLDC): a motor that converts supplied
Optimization towards Life-long Localization using Surround electrical energy into mechanical rotational energy
View", Intelligent Transportation Systems (ITSC) 2018 21st
International Conference on, pp. 2671-2677, 2018. Multiplexer: a device that selects between analog or digital
input signals and forwards it to a single output
[27] Number of Fires throughout the United States. 2018.
 APPENDIX A. USER MANUAL
INTRODUCTION:
This user manual is intended as a reference resource for future teams who are interested in continuing the
design and development of the robotic quadruped. The user manual outlines several key components and
how they are to be set up in order to have them fully operational. In addition to the step by step process of
setting up, the user manual also includes visual aids to help in the demonstration of each component set up.
It is assumed that the readers of this manual will be familiar with some of the software tools needed to
follow the step by step process; if in any case they are not, please refer to the online official documentation
for each unfamiliar software tool. If there are any questions or concerns regarding the steps in the user
manual, please contact us.

Table A1.1. Large-Scale Leg Startup

Step Description: Process: Visual Aids:
Number/Name:
Step 1: ODrive This step is to [1] Connect the A, B and C
ensure the ODrive phase terminals on the board
motor controller to the motors ensuring that the
board is correctly middle wire of the motor is
connected to the connected to the B phase
3-Phase BLDC terminal
motors as well as
the power supply [2] Connect the 5 wires from
and computer the encoder to the proper
interface via USB. terminals on the ODrive.
(Make sure to match encoders
to the corresponding axis of
the motor. Marked as “M0” or
“M1”

[3] Connect the Jetson

Nano you will be using to
control the motors via USB to
the micro-USB port on the
ODrive board. (Please note
that the board cannot turn on
via USB)

[4] To power up the board,

connect a 12-24V power
supply to the DC positive and
negative ports on the board.

[5] Open up an internet

browser and proceed to the
ODrive Documentation
Website to set up the
appropriate software.

Appendix A-1
[6] Install either Python3 or
Anaconda (a distribution of
Python). It is extremely
recommended that you install
Anaconda as several essential
libraries are installed with it
that would otherwise be
needed to install separately
with Python Standalone

[7] Open up a terminal

window and run the command
“python”, “py” or “python3”.
Assure that Python3 is the
version currently running by
using the command
Python –version before
entering the previous
command.

[8] Install the ODrive tool

onto the python environment
by using the following
command:
pip install odrive

[9] Assuming you are using

Windows, you will need to
install a final driver for the
ODrive tool to detect the
ODrive module. Install the
Zadig utility driver as shown
in the visual aid.

[10] Check ‘List All Devices’

from the options menu, and
select ‘ODrive 3.x Native
Interface (Interface 2)’. With
that selected in the device list
choose ‘libusb-win32’ from
the target driver list and then
press the large ‘install driver’
button.

[11] To launch the main

interactive ODrive tool, type
odrivetool Enter. Connect
your ODrive and wait for the
tool to find it. Now you can,
Appendix A-2
 for instance type
odrv0.vbus_voltage Enter to
inspect the boards main
supply voltage. It should look
something like the diagram
shown in the visual aid.

[12] Now you will be able to

type commands into the
odrivetool shell and will be
able to control the motor. One
thing to keep in mind is in
order to have full control of
the motor, and encoder must
be mounted to it. Otherwise
the motor will not calibrate
and motor control may not
function.

Step 2: Jetson This step [1] Connect the appropriate

Nano provides the I2C bus pins from the Jetson
process of Nano to Vin, GND, SDA, and
ensuring the I2C SCL on the I2C Mux
MUX, TOF (TCA9548A)
sensors, and
power are [2] Connect any of the SDA#
connected and its corresponding SCL# to
properly. the SDA/SCL pins to the TOF
sensor (VL6180x). Also connect
the Vin and GND pins on the
TOF sensors to the same power
supply as the I2C MUX

[3] Ensure the proper

peripherals are connected to the
Nano such as the keyboard,
mouse, and HDMI cable

[4] Power up the Nano via its

micro-usb cable by a 5V power
supply capable of providing at
least 1.5A

Appendix A-3
 Step 3: Jetson This step [1] Go to the terminal and use
Nano provides the the “sudo i2c detect” command
Access/VSCode process of to ensure that the I2C address of
accessing the the MUX is detected. (Ensure
VSCode that that Step 2 is completed)
contains the
Python source [2] To enter the VSCode IDE
code that can be enter in the command “code-
built on to create oss” and the relevant code can
more demanding be found in the “Megabyte”
actions from the folder
large leg.
[3] The Python scripts can now
be executed. (Note: The scripts
that require the use of the I2C
bus must be run as a super user
in order to access the bus

[4] The Large-Scale Leg can

now be controlled

Appendix A-4
 Table A1.2. I2C Set Up
Step Number / Description: Process: Visual Aids:
Name:
Step 1: Setting This step [1] Download the STM32
up the provides Software from their official
communication information on website like the visual aid
protocol(s) how to setup the shows.
communication
protocol on an
STM32 board
using the
STM32CubeMX
software. [2] Load the software up and
you will need to make sure
that you select the correct
development board you are
using, otherwise the pin
configurations will not work.

[3] Now we will be able to

properly set up any
supported communication
protocol needed to have the
MCU interfaced with another
module. The following visual
aids demonstrate the
supported communication
protocols on this MCU; as
well as the pin diagram that
becomes automatically
assigned by the software
when enabling a feature.

[4] The next step will be to

set up the proper clock
frequency configuration in
the “Clock Configuration”
tab. To do this we simply
input our desired frequency

Appendix A-5
within the allowed boxes.
The desired input frequency
can be acquired for the
module specifications you
are trying to interface. And
the specific bus can also be
determined through the
MCU’s datasheet.

[5] With the appropriate pin

and clock configurations set
by the software, you will
now be able to appropriately
interface any desired module
sensor that supports the
configuration set by you.

Appendix A-6
Step 2: IMU This step is to [1] Connect the appropriate
interfacing and give information I2C bus pins from assigned
measurements on how to pins on the STM32 Board to
interface the Vin, GND, SDA, and SCL
IMU with the on the MPU 6050.
ARM cortex
development [2] Also connect the Vin and
board or Jetson GND pins on the TOF
Nano board. sensors to the same power
supply as the I2C MUX

[3] Ensure the proper

peripherals are connected to
the MCU such as the
keyboard, mouse, and HDMI
cable

[4] Download the software

project from the appropriate
source code folder, so that
you are able to use the IMU
library that was written for
the MCU.

[5] Run the program using

either Keil uVision or
Attollic Truestudio in order
to test if the IMU is sending
data to the MCU.

[6] To run on the Jetson

Nano, simply install the
adafruit library using the
following command:
sudo pip3 install adafruit-
circuitpython-mpu6050

Appendix A-7
[7] Now that the proper
support library installed, the
next step is to run the
provided python script:
[Link] in order to have
the IMU module properly
interfaced with the Jetson
Nano.

[8]: Run the script by typing

the following command:

python [Link]

[9] You should see angles

being printed onto the
terminal shell after clicking
enter on the keyboard.

Appendix A-8
 Table A1.3. Small Dog Set Up:

Step Number / Description: Process: Visual Aids:

Name:
Step 1: Checking all Making sure all Servo [1] Simply check the
wire connections Motors are connected pin female to male
correctly. connectors to ensure
that all Servo Motor
*This step assumes that wires (12 motors x 3
all the Software has been wires each)
updates and the user will
not be concerned with [2] If any are loose or
maintenance or disconnected,
upgrading. reconnect in the correct
orientation. Each set of
wires should be labeled
1 through 12.

Step 2: Powering This step requires the [1] Simply attach either
and Testing user to connect 2S Li-Po power source to the
Batteries (7.5 V) to the connectors available.
onboard connector.
[2] A switch at the top
Alternatively, a DC of the PCB board will
barrel-jack connector is allow the user to keep
also available on the the power supply
PCB board to connect an attached without
AC-DC, 5V-10Amp constantly running. A
Power Supply. red dot will indicate the
‘ON’ setting.
*Note: The Barrel Jack
Connector will add some
instability into the
system.

Appendix A-9
 APPENDIX B. HARDWARE

Figure B1.1. Large-Scale Dog Hardware Block Diagram

Figure B1.2. I2C MUX Block Diagram

Appendix B-1
 Figure B1.3. Time-of-Flight Testing Procedure (Top-View)

Figure B1.4. Small-Scale Dog Hardware Block Diagram

Note: Barrel-jack DC Power Supply not shown (5V – 10Amp).

Appendix B-2
 APPENDIX C. SOFTWARE

Figure C1.1. TOF Sensor Feedback Flowchart

Appendix C-1
Figure C1.2. ORB-SLAM2 3D Point Cloud Flowchart

Appendix C-2
Figure C1.3. Small-Scale Dog Software Block Diagram

Appendix C-3
 APPENDIX D. MECHANICAL ASPECTS

Figure D1.1. Large-Scale Dog CAD Model

Figure D1.2. Large-Scale Dog CAD Model (Side-View)

Appendix D-1
Figure D1.3. ME Full Assembly

Figure D1.4. ME Leg Assembly

Appendix D-2
Figure D1.5. ME Hip Assembly

Figure D1.6. ME Ball Screw

Appendix D-3
Figure D1.7. Small-Scale Dog CAD Model

Appendix D-4
 APPENDIX E. VENDOR CONTACTS
Name: Phone Number: E-mail: Website:

ODrive Robotics, INC N/A info@[Link] [Link]

ST Microelectronics N/A N/A [Link]

Nvidia N/A N/A [Link]

us/autonomous-machines/embedded-
systems/

Fethi Belkhouche (916) 278-7346 belkhouf@[Link] [Link]

Thomas Douglas (916) 278-6366 [Link]@[Link] N/A

Russ Tatro (916) 278-4878 rtatro@[Link] [Link]

Appendix E-1
 APPENDIX F. RESUMES
KRISTIAN JOSUE ORNELAS
(707) 386-0338 ● krisornelas85@[Link] ● 1929 Oliveglen Ct. Fairfield, CA
OBJECTIVE:
Actively seeking a full-time or internship position in Hardware, Firmware, or Software Engineering
EDUCATION:
Bachelor of Science, Electrical & Electronic Engineering Concentration: Analog/Digital & Controls
California State University, Sacramento, CA Expected: May 2020
Overall GPA: 3.24 Major GPA: 3.43
WORK EXPERIENCE:
Electronics Hardware Intern S&C Electric Company May 2019 – August 2019
• Assisted in the design and implementation of a Linked List DMA within a FPGA between a digital signal processor
and microprocessor used to increase data transfer efficiency
• Successfully wrote four state machines in Verilog capable of interfacing with external memory via the AHB-Lite
bus and verified expected results with ModelSim
• Documented Linked List DMA project with state machine flowcharts and block diagrams
• Presented summer project details with PowerPoint to 20 full-time engineers and managers
Dangerous Goods Specialist Lead Fedex Express July 2015 – November 2017
• Effectively trained and managed six high performing team members in auditing and data entry
• Decreased company spending by developing an efficient auditing process for maximum productivity and efficiency
• Inspected 20 – 70 pieces of hazardous material per shift with four team members before the daily deadline
SKILLS-LANGUAGES, TOOLS, PLATFORMS:
C, C++, Verilog, Python, MATLAB, Quartus Prime, OrCAD PSpice, Attollic TrueStudio, STM32CUBEMX, Libero, Linux (Ubuntu,
Debian), VMWare, Visual Studio, ModelSim, Oscilloscope, Logic Analyzer, Signal Generator, FPGA, x86 Assembly, PCB Design,
Analog Circuits, Robot Operating System (ROS), RTL Design, GitHub, Embedded Systems
PROJECT EXPERIENCE:
Senior Design Project (in progress):
• Semi-Autonomous Quadrupedal Robot: Currently involved in designing and building a Semi-Autonomous
Quadrupedal Robot with 7 other team members. Assisting in the design of the Control and Power Systems by
implementing kinematic models in code, simultaneous localization and mapping through a monocular camera with
ROS and I2C/UART communication protocols for TOF/IMU sensor readings as feedback in Python.
Digital/RTL Design Projects:
• 4-bit Adder: Designed a full 4-bit adder in Verilog, verified using ModelSim simulator, individually assembled test-
bench, and a FPGA
• Sequence Detector: Individually, developed a state machine in Quartus using Verilog, built to detect a pre-
determined sequence of bits
Computer Interfacing Projects:
• Wheeled Robot: In a team of two, assembled a wheeled robot capable of line-following using IR sensors and
performing maneuvers specified by the user in C programming language
• Raspberry Pi Camera: Successfully wrote a Python script in a Raspberry Pi that would take a picture and request the
user to name the file and automatically save it in a pre-determined folder
• NVIDIA Jetson Nano GUI: Created a graphical user interface with Python and the OpenCV library that displays the
livestream via webcam and the IMU data being read by the NANO using the I2C protocol
AFFILIATIONS/AWARDS:
Dean’s Honor List Fall 2018 – Fall 2019
IEEE, Member Fall 2018 – Present
SHPE, Member Spring 2018 – Present

Appendix F-1
 EDGAR GRANADOS ONATE _______________ ______
• (916) 793-5496 • edgargranados153@[Link] • [Link]/Edgar153
OBJECTIVE: _____________________________________________________________________________________
Actively seeking a full time/internships opportunity in the areas of Hardware, Firmware, or Software Engineering.
EDUCATION: _____________________________________________________________________________________
Bachelor of Science, Computer Engineering Expected: December 2020
California State University, Sacramento
Overall GPA: 3.32 Major GPA: 3.41
WORK EXPERIENCE: __________________________________________________________________________
Software Development Freelance March 2019 - May 2019
• Worked with a client to implement a software program that monitored user activity on a web forum and discord
text channel. The program would automatically tweet user content from these forums onto the client’s business
twitter account. Twitter’s Java and Python APIs were used to design and create the software.
Client Services Assistant Granados Gardening Service January 2015 – Present
• Communicate with clients regarding services, quotes, and customer support for my father’s business. Other
responsibilities include planning out and designing schematics for landscaping projects requested by clients.
SKILLS-LANGUAGES, TOOLS, PLATFORMS: _____________________________________________________
C, Java, Verilog, Python, JavaScript, Kotlin, Android Studio, Selenium Web Driver, Jenkins, Keil uVision, ARM Assembly, x86
Assembly, Git Version Control, TestNG, Apache Maven, HTML/CSS, Xilinx Vivado Design Suite, Quartus Prime, DOS, Windows
(XP, Vista, 8.1, 10), MS-DOS, UNIX, Linux (Ubuntu, Debian), VMWare, OpenCV, Machine Vision, Oracle SQL, PHP, Eclipse
IDE, Embedded Systems, Robotics, Logic Analyzer.
CURRENT AND RELEVANT PROJECTS: ___________________________________________________________
Senior Design Project:
• Semi-Autonomous Quadrupedal Robot: Designed the Control and Feedback System of a semiautonomous quadrupedal
robot. The team consisted of 4 Mechanical Engineer (ME), 2 Electrical Engineer (EE), and 2 Computer Engineer (CpE)
students. Interfaced several sensor modules and assisted in writing the walking algorithm for the robot. Embedded C and
Python was used to write the control algorithm of the robotic system as well as several communication protocols to
interface modules together.
Java Projects:
• Shopify Automation Tool: Designed a web scraping application that would allow users to automatically search and
checkout items out of various Shopify seller websites. Selenium WebDriver, TestNG, Apache Maven, Git Version
Control, and Jenkins was used to deploy this application.
• Client Billing System: Created and coded a GUI program, using the [Link] package, for my father’s Gardening
business. The program allowed users to add/delete client profiles, input client information, and provided the user with an
automated invoice-making service that printed out invoices.
• Real-Time Cryptocurrency Monitoring System: Implemented a cryptocurrency monitoring program using Java Sockets
and the [Link] package. The program would retrieve information about cryptocurrency coins from several finance
websites and display them onto a console window. The program was utilized by 16+ users
Computer Hardware and Machine Vision Projects:
• Direct Mapped Cache Design: In Verilog, designed and simulated a cache controller module that utilized the direct
mapping scheme to store data onto cache blocks. The controller would be able to interface between a CPU and Main
Memory to perform read or write operations.
• PCI Bus Arbiter: In Verilog, designed and simulated a PCI Bus Arbiter that performed bus arbitration among multiple
master devices on a PCI Bus. The bus arbiter utilized the Round-Robin Priority Scheme to designate the PCI Bus to the
appropriate master device.
• Object Detection and Tracking Robot: Designed a robot that would be able to detect and follow a spherical object. Python
and OpenCV was used for image processing and controlling the robotic system.
Android App Development:
• Remote Video Surveillance Application: Currently developing a mobile surveillance application for the Android platform.
The app will allow users to monitor their home surveillance systems from their phone using the system’s IP Address and
network protocols such as DDNS and Port Forwarding.
AWARDS/CLUBS: ______________________________________________________________________________
Deans Honor List Spring 2017 – Spring 2019
Engineering and Computer Science Scholarship Fall 2019
Web Development Club, Member Fall 2018 – Spring 2020
ACM, Member Spring 2019 - Present
SHPE, Member Fall 2019 – Present
Appendix F-2
Alfred W. Martinez III
Electrical & Electronics Engineer Objective:
7248 Sunwood Way
Sacramento, CA Actively seeking a full time/internships opportunity in the areas of
(916) 571 - 4991 Hardware, Firmware, or Software Engineering.
alfredmartinez555@[Link]
[Link]/in/AlfredMartinezIIIEEE
EDUCATION
Bachelor of Science, Electrical & Electronic Engineering California State University, Sacramento, CA
Expected Graduation: May 2020
Concentration: Controls / Embedded Systems
Major GPA: 3.461
Overall GPA: 3.227
SKILLS/TOOLS/PLATFORMS
Embedded Systems, C / C++, Python, Java, ARM Assembly, x86 Assembly, Linux, MATLAB, Quartus Prime, Verilog & VHDL, PSpice, ModelSim,
Advanced Design System, Visual Studios, VMWare, PCB Design, Atollic TrueStudio, Oscilloscope, Logic Analyzer, Signal Generator,
STM32CubeMX, PyCharm, Arduino, Robotics, Machine Vision, OpenCV, NumPy, Windows, Robot Operating System (ROS).
COURSEWORK
Circuit & Network Analysis, Controls & Feedback Theory, Transmission Line Theory, PCB Design, Circuit Design, Simulating, and Testing,
Electromechanical Conversion, Robotics, Machine Vision, Communication Systems, Microprocessor Architecture and Programming, Product Design
Management
WORK EXPERIENCE
Delivery Driver, Domino’s Pizza, Sacramento, CA
February 2017 - Now
Officer Candidate, United States Marine Corps, USA
December 2015 - Now
Math & Science Tutor (Grades 9-12), Freelance / Private
December 2015 - May 2018
Line Cook / Oven Section Leader, Pete’s Restaurant & Brew, Sacramento, CA
January 2016 - July 2018
PROJECTS
Robotic Dog (Mini & Large), Senior Design
AUGUST 2019 - MAY 2020
ARM Cortex M4: Developed a bare-metal robot dog using an STM32 Arm Microcontroller. At the base, clocks, timers, and pulse width
modulation registers were all assigned to control 12 robotic joints in real time.
PCB Prototyping & Wire Management: Developed a prototyping board to house all components and connections to facilitate simplistic debugging
and prevent damage to components. Learned proper soldering and PCB prototyping techniques.
Robotic Kinematics: Used trigonometry and geometry to control the position of the 4 legs of the robot using angular control of the joints.
Remote Monitored Fish Tank
JANUARY 2019 - JUNE 2019
GUI & Embedded System Connection: Worked on a user interface using an online Apache Web Server that could display data from embedded
sensors in a fish tank remotely. This included temperature, humidity, water level, and security sensors as well as a motor to control the feeding
rate of fish food.
Firefighter Camera Assistant
JANUARY 2020 - MAY 2020
Machine Vision / OpenCV / Python: By using footage from a firefighter’s helmet camera, a system was developed to detect edges of
furniture/rooms/hallways in a smoky or dark room and relay that data to a small screen placed inside the helmet.
Verilog/VHDL Designs & Simulations
AUGUST 2019 - MAY 2020
Developed and Simulated four-bit adders, multipliers, and multiplexers. Also, developed several finite state machines, flip-flops, and a 4-bit
microcontroller in Verilog.

Appendix F-3
Marcus Huston
8146 Big Sky Drive, Antelope, CA 95843 | (916) 616-7927 | marcus.huston96@[Link] | Computer Engineering Student
Education
Bachelor of Science in Computer Engineering Spring 2020(est.)
Minors: Applied Mathematics & Studio Art Overall GPA: 3.20 / 4.00
California State University, Sacramento

Member of Tau Beta Pi – Engineering Honors Society - achieved the top 12.5% of your
Junior class or 20% of your Senior class. Tau Beta Pi is the only engineering honor society
representing the entire engineering profession.

Professional Profile
I am an innovative individual looking to collaborate in diverse environments in order to
immerse / enhance my knowledge, problem-solving skills, and project management
experience to challenge me to grow and learn new languages / emerging technologies.

Skills Summary
• Java, C, Python, x86 Assembly, Verilog, Microsoft Office and Adobe Suite.
• Experience working with Oscilloscopes, Microcontrollers, and FPGA.
• Good analytical, communication and technical writing skills

Relevant Courses
CMOS and VLSI Database Management Systems Operating System Principles Advanced Math Science & Engineering
Computer Networks & Internets Advanced Computer Organization
Probability & Random Signals Computer Hardware Design Electronics
Data Structures & Algorithm Analysis Advanced Logic Design Computer Interfacing
Discrete Structures System Programming Unix Network Analysis Signals & Systems

Work Experience
Law Office of Marcus, Regalado, & Marcus, LLP American Sign Language Glove
Student project to create a bridge between ASL and
August 2014 – Present
• Internal and external communication
English by converting signed data and displaying it
• Data entry / Calendar statutes as letters.
• Client intake process coordinator October 2018 – December 2018
• Utilization review manager • Organized and directed weekly team meetings and optimized group
• Assisting the attorneys/paralegals effectiveness.
• Assists in the development of project scope and project management • Created schematics to optimize design and transition into simulation
documentation using MS Office. and analysis
• Trained incoming employees in preparation for their job • Integrated embedded systems to communicate and increase speed
• Reports on analytics and project progress • Ability to quickly adapt, debug, and solve technical problems
• Installed software and hardware on employee machines • Code: C Programming Language
• Hardware: Raspberry Pi, Analog to Digital Converter, Accelerometer,
Flex Sensors, etc.
Project / Leadership Experience Magnetic Levitation Quadcopter Drone
Hornet Hyperloop Student research project to design, create, and build a
International Student competition organized by SpaceX drone that levitates based on rpm against the magnetic
and the Boring Company. fields
Controls Team March 2019 – Present
• Designed, analyzed, and debugged various software and systems • Troubleshooting skills
• Optimized design using simulations and analysis • Performed background research and study for the solidification
• Use of CAN bus communications for main pod controls as well as data processing of materials in magnetic fields.
acquisition • Researched and analyzed to decrease friction
• Ability to work with other engineers, collaborate, and test ideas • Designed and analyzed a structure capable of holding neodymium N52
• Ability to solve technical problems grade magnets for solidification process.
• Code: C Programming Language • Code: C Programming Language

Appendix F-4