Unmanned Ground Vehicle for Simulating

Unmanned Air Vehicle Landing

Team ECE2026
James Kuveke, Jonathan Luo, James Wales
Faculty Advisor: Professor Shalabh Gupta

Team ME56
Cody Corey, Marwan Ghellai, Julia Oppenheimer
Faculty Advisor: Professor Chengyu Cao

Sponsor Advisor: Mr. Alex Lorman

Final Report
May 2020
ABSTRACT
The United States government is constantly investing in ways it can monitor and protect
its oceanic borders. One of the ways it achieves this goal is the use of surveillance drones sent
out to sea to collect data and monitor important areas. Unfortunately, modern battery
technology and constant changes in weather make it extremely challenging to retrieve these
drones after their mission is complete. Our sponsor, ThayerMahan, wants to develop a method
of retrieving these drones so they can be used for multiple missions. To research the feasibility
of this, ThayerMahan has tasked our team with the development of a UGV to simulate the
landing of a UAV on an unmanned boat.
This paper will outline the design of a UGV that is capable of serving as a landing
platform for a UAV. Specifically, this report will focus on the electrical components necessary to
implement automated control. The UGV will have a similar layout to an electric car, with two
electric motors supplying the vehicle with rear wheel drive. In order to maneuver, the vehicle
will use skid steering. A separate mechanical engineering team will construct the frame and
landing platform that the electrical components can be attached to.
To achieve autonomous control and facilitate an accurate landing, the UGV will use RTK
GPS technology to transmit its position to the UAV. Once the UAV has received the position of
the UGV, it will locate the ground vehicle, and land on a landing platform. ThayerMahan will be
able to decide if they should move forward with a production model given the completion of
the project.

2
TABLE OF CONTENTS

Abstract 2
Table of contents 3
List of Figures and tables 3
Nomenclature/Glossary 4
I. Introduction 5
II. Problem Statement 6
III. Approach and design 6
A. Constraints 6
B. Real-Time Kinematic GPS 7
C. RTK Algorithm 7
D. Moving Baseline RTK Technique 8
E. Torque-Speed Curves 10
F. Connection Diagram 11
G. RTK Testing 12
H. Scrapped Designs 14
I. Control 14
J. Power Electronics 15
K. Final Design 17
L. Simulation/Testing Results 19
M. Standards 19
IV. Project management 19
V. Summary 22
References 23
Appendix 24
Figures & Tables
Figure 1 7
Figure 2 9
Figure 3 10
Figure 4 11
Figure 5 13
Figure 6 15
Figure 7 16
Figure 8 17
Figure 9 18
Figure 10.a 20
Figure 10.b 20
Table 1
19

3
Table 2
21

NOMENCLATURE/Glossary

Symbol Description Units

(s)
r,i Carrier phase measurement for Cycles
band ​i a​ nd satellite ​s

r,i (tr ) Phase for the ​i-​ th band of the Cycles

receiver's local oscillator at time ​t
(s)
i Phase for the ​i-​ th band of the Cycles
transmitted signal at time ​t

tr Navigation signal reception time Seconds

t(s) Navigation signal transmission time Seconds

at the satellite

N r,i (s) Carrier-phase integer ambiguity Cycles

ϵ Models carrier phase measurement Cycles

noise

fi Carrier frequency at band ​i Hz

dtr (tr ) Receiver clock offset from GPS at Seconds

time ​t

dT (s) (t(s) ) Satellite clock bias from GPS at time Seconds

t

t0 The initial time Seconds

(s)
0,i Initial phase for the ​i-​ th band Cycles

λi Carrier wavelength Meters

4
 Φr,i (s) Phase-range measurement Meters
(s)
r Geometric range between satellite Meters
and receiver antennas

Lr,i (tr ) The integer component of a Cycles

receivers oscillator

K r,i (tr ) Integer component of the term in Cycles

paper from reference [7]

Abbreviation Phrase

RTK Real-Time Kinematic

MB RTK Moving Baseline Real-Time Kinematic

DC Direct Current

GNSS Global Navigation Satellite System

UART Universal Asynchronous Receiver-Transmitter

RTCM Radio Technical Commission for Maritime

UNAVCO Government run research facility supplying RTCM credentials

GPS Global Positioning System

UAV Unmanned Air Vehicle

UGV Unmanned Ground Vehicle

USV Unmanned Surface Vehicle

I. INTRODUCTION
This report discusses the design of an electrical system for an unmanned ground vehicle
(UGV) in order to simulate a moving maritime landing platform for an unmanned air vehicle
(UAV). The UAV will perform an autonomous landing on top of the UGV by receiving accurate
coordinates from the UGV. To produce coordinates accurate enough to use for a drone landing,

5
RTK GPS will be implemented allowing cm accuracy. The desire for this system comes from our
sponsor ThayerMahan. ThayerMahan is an autonomous maritime surveillance company that
creates and maintains systems that survey and gather information for the United States
government and other clients. ThayerMahan currently supplies systems for streaming data
about the seafloor, detecting illicit maritime activity, and monitoring ships traveling in and out
of U.S. seaports. By adding UAVs to their products, they can supply products that cover and
maintain an even more extensive range for the U.S. government. The creation of a UGV capable
of functioning as a landing platform would be highly beneficial for ThayerMahan, as it would
allow the company to implement UAVs capable of being retrieved and reused into their product
line.

II. PROBLEM STATEMENT

ThayerMahan is a defense contracting company based out of Groton, CT. They provide
their clients with class leading autonomous maritime surveillance technology. Through the use
of ThayerMahan’s products, the government and other industry partners can thoroughly
monitor borders, undersea infrastructure, and protect natural resources. Years of working with
their various clients has helped ThayerMahan to identify a trend. Many of these clients use
UAVs to monitor maritime activity from the air, but nearly none make it back to land. These
UAVs can cost anywhere between $10,000 - $80,000, but with national security at stake,
companies and the government are willing to get only a single use out of them. ThayerMahan
believes they can solve this problem. One of their products, SeaWatch, is an autonomous USV
that detects electronic activity from potentially illicit vessels. By adding a UAV to work alongside
USVs like SeaWatch, ThayerMahan could expand their market, and greatly extend the life of
surveillance drones.
The task given by our sponsor ThayerMahan is to design and fabricate an autonomous
UGV capable of serving as a landing platform for an autonomous UAV. This UGV will serve as a
model for a maritime USV, helping ThayerMahan decide if a production model is viable. Upon
being assigned this project our team was given requirements that have to be met. The UGV that
we construct must weigh less than 100 pounds, move autonomously using precision GPS
technology, and move at a velocity of at least 2 knots. Once the UAV has landed on the UGV, it
must be secure, meaning it will not fall off due to a disturbance such as rough seas. Finally, it
must be easy to retrieve the UAV from the UGV, meaning no landing mechanism should impede
the retrieval of the UAV.

III. APPROACH AND DESIGN

6
A. Constraints
1. The vehicle must be able to move at no less than 2 knots.
2. The UAV must land on the vehicle while it is moving at no less than 2 knots.
3. The UGV must be able to move autonomously or via radio command.
4. The vehicle cannot weigh more than 100 lbs.
5. Both the UGV and UAV must uitilize RTK GPS.
6. The UGV must stream its coordinates to the UAV.
7. The budget of the UGV team is roughly $1000.

B. Real-Time Kinematic GPS

Real-Time Kinematic (RTK) GPS refers to an incredibly accurate form of GPS technology
that is vital for the completion of this project. RTK systems consist of three major components;
GNNS satellites, a moving rover station, and in most scenarios, a stationary base station. Unlike
most GPS technology, RTK uses the carrier wave from GNNS satellites to perform range
calculations. To determine range, the number of carrier cycles between the satellite and the
rover is multiplied by the carrier wavelength. The calculated range still contains error due to a
signal phase shift caused by sources such as ionospheric and tropospheric delays, satellite clock
bias, and ephemerides [1]. To reduce this error, the base station sends its well known location,
code, and carrier measurements obtained from visible GNNS satellites to the rover, allowing
the rover to fix the error and obtain cm level accuracy [1].

Fig.1: RTK GPS with stationary base station [1].

C. RTK Algorithm

7
 As explained in the previous section, RTK GPS requires error correction to calculate an
accurate number of carrier cycles. To perform the correction, the carrier phase measurement
must first be calculated using equation (1) [6]:

(1)
When expanded this is equal to equation (2) [6]:

(2)
To calculate phase range, we then multiply the carrier phase measurement found in equation
(2) by the carrier wavelength [6]. This results in the phase-range measurement shown in
equation (3) below:

(3)
In the equations above, the term accounting for the carrier cycles error is the integer ambiguity
term N r,i (s) . Without this term, it would be impossible to produce accurate phase-range
measurements. The equation solving for integer ambiguity is detailed in (4):

(4)
The math behind this calculation is quite complicated and beyond the scope of this project. For
those interested in how it is calculated, please refer to our references [7].

D. Moving Baseline RTK Technique

For most applications, RTK with a stationary base station is sufficient. In certain
scenarios, a technique known as Moving Baseline RTK is a more viable technique. In MB RTK
systems, the base station moves relative to the rover station. By mounting both the rover and
base to a vessel, the system is able to calculate an accurate heading [3]. MB RTK is able to
achieve a heading because both rover and base move relative to GNNS satellites, but remain
fixed relative to each other. In a scenario such as a UAV landing on a USV, this heading proves
to be invaluable. Knowing both the heading, location, and speed allows the UAV to accurately
track the USV and facilitate a landing.

8
Fig.2: Moving Baseline RTK on a Boat [5].

9
E. Torque-Speed Curves:
One of the constraints of this project is the speed at which the vehicle can move. It is
important to calculate whether or not the vehicle can reach those speeds using the purchased
motors. In order to do this a Torque-Speed curve can be created. Torque and speed have an
inverse linear relationship and by measuring the speed in no torque conditions as well as the
torque in no speed conditions, you can extrapolate a line between the two. Both variables
should be measured at rated conditions because it will give us our practical maximum speed
and torque. By then calculating what torque the motors will be experiencing while rotating the
wheels, we can find the rotational speed at maximum voltage that the motors can achieve, and
therefore the maximum speed at which the vehicle will be traveling.

Fig.3: Torque-Speed curve.

10
F. Connection Diagram

Fig. 4: UGV signal block diagram

Green Wires: ​Signal Connections Red Wires: ​Power Connections
Blue Wires: ​Antenna Connections

The block diagram above details both the components necessary for the UGV to
function, and the signals that will be sent between them. In the setup above, the vehicle has
the ability to move autonomously, or via radio control. In order to move autonomously, the
user will be able to initiate a driving path using waypoints set in the ground control software.
The waypoints will then be uploaded to the UGV using the connection between the telemetry
module on the vehicle, and the one in the ground control computer. As the UGV moves, the
RTK position found using the MB RTK setup will be sent into a microprocessor. Once the
microprocessor receives the Tx output signal from the rover, it will use this information to
calculate the coordinates at the center of the landing platform. Once the coordinates are
corrected, they can be sent to the transmitter to relay to the UAV. While the coordinates are
being sent to the UAV, the same coordinates will be fed into the GPS port on the Pixhawk. This

11
will allow the Pixhawk’s control software, Ardupilot, to monitor the position of the vehicle, and
relay it to the telemetry module on a computer for observation. Additionally, the Pixhawk will
send PWM signals to the motor driver, allowing changes to be made to the vehicle's speed and
heading.

G. RTK Testing
To achieve a working integration of the MB RTK system, we will now outline a testing
procedure. Our procedure for testing will be as follows:
1. Wire together the two RTK-GPS2 in a MB RTK configuration. To do this, one module will
function as the rover and the other as the base. The output Tx2 UART signal from the
base will feed into the Rx2 UART input port on the rover. See figure 5 for details on how
the RTK chips will connect with each other and the Pixhawk.
2. With the modules wired together, we will begin to set up the software components. We
will download u-center, a GNNS evaluation program produced by ublox, the supplier of
the RTK chip. Using u-center, we will be able to receive and record outputs from the RTK
modules.
3. With the u-center software downloaded, we will connect USB-C cables from a computer
to the two RTK modules, allowing us to upload configuration instructions to the boards.
The RTK modules will be configured to send RTCM3 correction data between each
other. The Rover will also be configured to send NMEA outputs from its UART2 so the
Pixhawk can interpret the positional data. Both the RTCM3 and NMEA connections will
operate using 115200bps.
4. Once we have verified that we have configured the RTK modules correctly, we will
power them on, and use u-center to test any signals being sent.
5. After the previous setup has been made, we will move into the debugging and
adjustments phase. Any errors made in the setup will be found using the u-center data
feed. We will use this data to fix or change any parts of the configuration.
6. After showing that the RTK modules are outputting their expected positions, we will
move into making corrections of the positions using a microprocessor. This will involve
feeding the output from the Rover into a processor, that will center the coordinates
about the middle of the landing platform.

12
 Fig. 5: RTK integration with Pixhawk Controller
The signal coming from the Tx output of the rover is the position of the rover chip
relative to the position of the base. To adjust the coordinates to be at the center of the UGV,
the Raspberry Pi will halve the position between the rover and base. For instance, if the
coordinates of the rover are (X,Y,Z), and Y is the distance between the two RTK stations, the
Raspberry Pi will output (X,Y/2,Z). This works because the center of the landing platform will be
exactly halfway between the two RTK antennas.

13
H. Scrapped Designs
In initial designs, we expected to utilize range sensing devices to implement obstacle
avoidance. This involved the implementation of either ultrasonic or lidar sensors. After careful
consideration, we decided that obstacle avoidance was not a top priority. Meetings with our
sponsor made it clear that implementing RTK GPS was most important, and should be the focus
of the project. Implementing obstacle avoidance would take time that could be spent working
on the RTK system. Combined with the fact that our budget was getting close to being filled, we
decided to leave the obstacle avoidance sensors out of the current design.

I. Control
For the controller, we have opted to use a Pixhawk. Pixhawks are designed to work with
Ardupilot, simplifying the implementation of the control system. We had considered using an
arduino as the microprocessor to execute control, but decided against it. Because team UAV
had already committed to using a Pixhawk and Ardupilot, it made sense. By implementing a
design similar to Team UAVs, we will be able to more easily collaborate on the RTK integration
and help each other with debugging and testing.
Ardupilot is an open source autonomous vehicle software with the capability to control
both land and air based vehicles. It is compatible with Pixhawk. The software has built in
control algorithms as well as a library of modules which allow the vehicle to perform autopilot.
By using Ardupilot it eliminates a large proportion of coding for our team. This is beneficial for
us as we are an EE based team and not CSE. Although the team will have to do some coding, the
extensive libraries available for Ardupilot will leave our team with more time to work on RTK
integration, coordinate position correction, and debugging.
In order to easily upload Ardupilot configurations and monitor the UGV, we are using
MissionPlanner, an open source ground station software designed for Ardupilot. Using mission
planner, we can configure settings such as skid steering, throttle response, and most
importantly, set waypoints for the vehicle to move between. In figure 6, below, you can see
what the opening window of Mission Planner looks like. Using the telemetry modules fitted to
the ground computer and UGV, Mission Planner allows us to monitor the vehicle’s movement in
real time. Additionally, this allows us to upload new movement parameters such as turning
radius without having to plug the pixhawk into our computer.

14
 Fig. 6: Mission Planner home screen

J. Power Electronics
After careful consideration, our team landed on a UGV setup using two brushed DC
motors and two 12 V lead acid batteries. In our original designs, we had picked two brushless
DC motors and a set of LiPo batteries to power the vehicle. Many other UGVs use a similar two
wheel configuration with LiPo batteries supplying power, but these components are much more
expensive. Our original budget for the UGV was only $1000, and the necessary RTK modules
cost $439.50 on their own. Because the RTK is so vital to the project, we decided to save money
by going with the less expensive option. The brushed motors and lead acid batteries are bulkier
and weigh much more, but saving the extra money gave us some room for failure. In the event
that a part breaks, we had room in the budget to order new parts.
The motors that were tested for our design are the Weelye RS550 12V 30kHz motors
with gearbox. By using a stroboscope and by referencing data sheets, we were able to find
values for the no-load speed and stalling torque. Using this we created a rough torque-speed
graph which can be used to determine if the motors are viable to achieve the required speed
once the dimensions of the frame and wheels for the vehicle are finalized and torque
requirements can be calculated[12].

15
Fig. 7: Torque-Speed graph for Weelye motor

16
K. Final Design

Fig. 8: Final Design circuit and wiring layout

Green Wires: ​Signal Connections Black Wires: Ground Connections
Blue Wires: ​Antenna Connections Red Wires: ​Positive Voltage Connections

In figure 8 above, you can see the final layout and design for the electronics portion of
the UGV. This diagram is drawn to scale and illustrates where each component is placed on the
chassis. Our final design uses a 2 motor, rear wheel drive layout configured for skid steering.
We decided to go with a skid steer layout for our final design as it was the most cost effective

17
method and simplest to implement. By using the two drive motors to steer the vehicle, there is
no need for a complicated front axle design. This meant the ME team working on the UGV was
able to keep costs at a minimum and focus on the landing platform. Additionally, skid steering
meant we only had to worry about controlling the two drive motors. Any other steering method
would have meant implementing a seperate motor to turn the front wheels. Considering our
vehicle is simulating an oceanic vessel, spending any time on this would have been a waste.
In order to supply power to the motors, we ended up purchasing a Sabertooth 2x12 A
dual motor driver. Unlike the HiLetgo driver we originally purchased, the Sabertooth driver
allows for differential control. This means that it can spin one motor forward, and another
backward at variable speeds. This functionality was critical in order to implement skid steering.
To perform the baseline calculation, our final design utilizes a Raspberry Pi 3B. The
Raspberry Pi provides more than enough processing power in order to perform the baseline
calculation, and more importantly, is extremely compatible with mainstream transceivers. This
meant that finding an appropriate transceiver to send the GPS coordinates was relatively easy.
While testing the vehicle under radio control, we found that the front wheels generated
far too much friction to enable smooth steering. In order to overcome this, ME team UGV fitted
a set of shopping cart wheels to the front of the vehicle. This design change was simple, but
effective. Doing so made the vehicle very easy to maneuver under radio control. In figure 9 you
can see a picture of the final vehicle design fitted with the shopping cart wheels.

Fig. 9: Final Vehicle Design

18
L. Simulation/Testing results.
In order to see the working vehicle please visit our website where an embedded
youtube link shows the vehicle moving under radio control.
Link: ​https://ecesd.engr.uconn.edu/ecesd2026/

M. Standards
● NMEA-0183 [8]
● RTCM
● IEEE 2008 [10]
● IEC 62133 [9]
● UL 2054 [10]
● ​UL 2056 [10]
● e-CFR 1926.441[11]

IV. PROJECT MANAGEMENT

Raci Chart:

Table 1: RACI chart showing each member's responsibilities.

19
 Through the chart above, each team member’s respective responsibilities in the project
are presented. Many of our responsibilities are the same, this was done on purpose as it
allowed each of us to get help on the more complicated portions of the project.

Gaant Chart:

Fig. 10.a: Gaant chart with expected project timeline.

Fig. 10.b: Second Semester detailed timeline of Deliverables.

Figure 10.a represents a broad expected timeline for the design of the vehicle, whereas
Figure 10.b was created at the beginning of the spring semester and best projected an accurate
timeline for our remaining deliverables. The reason we began working on waypoint movement
using a normal GPS module and not the RTK’s was due to a mix-up in regards to ordering the
RTK antennas. Although we had specified that two Antennas were to be ordered, only one

20
showed up. The shipping process for the second antenna took around a month so in the
meantime we used a standard, less precise GPS for testing purposes. When the university
closed, our team was on track with Figure 10.b, and had finished implementing radio control of
the vehicle. At that time, we were underway with implementing the GPS module and moving
via waypoints. Because this project was very hands-on, it was greatly impacted by Covid-19.
With team members having to work from home; coordination was much more difficult. Most
importantly, some of the team members ended up taking different portions of the project with
them. This meant that no one team member had all the necessary parts. This combined with no
access to the university's labs, made some of the testing impossible. In light of these issues, our
teams reached out to the sponsor and asked how to proceed. Mr.Lorman instructed both team
UGV and UAV to move to theory as working on the physical vehicles was no longer feasible.

UGV Purchase Sheet:

Part Use Part Name Price/Unit Quantity Total

Weelye Kids Cars 550 30k RPM 12V
Drive motor + gearbox Motor $15.98 2 $31.96
Tallysman Wireless Inc.
RTK Antennas 33-1825-05-0150 $108.35 2 $216.70
SparkFun GPS-RTK2 Board -
GPS chips ZED-F9P $219.95 2 439.9
Flight Controller Pixhawk PX4 Flight Controller $73 1 $73
Wiring 12 Ga wire $20.95 1 $20.95
Motor Driver Sabertooth 2x12 12a Motor Driver $77.95 1 $77.95
Remote Control
Receiver FlySky FS-iA6B Receiver $14.99 1 $14.99
Raspberry Pi MakerFocus 2pcs Wireless
Transmitter Transceiver $10.99 1 $10.99
Pixhawk PX4 Flight Controller
Pixhawk Connectors Connectors $9.50 1 $9.50
Baseline calculation Raspberry Pi 3B $41.99 1 $41.99
Pololu 5V, 5A Step-Down Voltage
Power conversion Regulator $14.95 1 $14.95
Lead Acid Battery
Charger SafeAmp 12-Volt charger $14.99 1 $14.99
$967.87
Table 2: List of purchased items and their prices

21
 Although our initial project constraints included a budget limited to 1000 dollars, our
team was given flexibility to go above this amount if the parts proved to be necessary for the
completion of the project.

V. SUMMARY
Unfortunately due to the Covid-19 pandemic, our sponsor instructed all teams to cease
in person meetings and move to theoretical design. This meant that our team was unable to
complete the final phases of the project. These include implementing the RTK-GPS, movement
between waypoints, and the landing of the drone. Although we were unable to complete these
portions, we believe that we have demonstrated the feasibility of the project and have laid the
foundation for any future endeavors.
The sponsor has indicated that they would like to continue work on the project, so next
year's team should be able to finish what we couldn’t. The groundwork that we have laid could
allow future team’s to consider working on a gimbaled platform. Although the design
constraints that we were given meant that our vehicle only had to move on flat ground, this
does not accurately represent the simulation. A real autonomous maritime vessel would
experience choppy waters, meaning the platform would not always be level. In actual practice,
a gimbaled platform would be invaluable as it would always keep the landing platform perfectly
level, regardless of the vehicle's orientation.

22
REFERENCES
[1] Hexagon, “Real-Time Kinematic (RTK),” ​An Introduction to GNSS​. [Online]. Available:
https://www.novatel.com/an-introduction-to-gnss/chapter-5-resolving-errors/real-time-kinem
atic-rtk/. [Accessed Nov 25, 2019]
[2] GMV, “RTK Fundamentals,” ​navipedia​. [Online]. Available:
https://gssc.esa.int/navipedia/index.php/RTK_Fundamentals. [Accessed Dec 1, 2019]
[3] Simon Lightbody and Gary Chisholm, “Techniques in Relative RTK GNSS Positioning,” Trimble
White Paper.​ [Online]. Available:
http://www.survey-solutions-scotland.co.uk/uploaded_files/WhitePaper_TechniquesInRelative
RTKGPSpositioning_14261_ENG.pdf. [Accessed Dec 1, 2019]
[4] Swift Navigation, “GNSS RTK Use Cases and Applications,” Nov 27, 2017. [Online]. Available:
https://support.swiftnav.com/customer/en/portal/articles/2628573-gnss-rtk-use-cases-and-ap
plications. [Accessed Dec 1, 2019]
[5]​ GNSS SDR, “Signal Processing Blocks,” December 14, 2018. [Online]. Available:
https://gnss-sdr.org/docs/sp-blocks/observables/. [Accessed Dec 3, 2019]
[6]​“ArduPilot.” ​ArduPilot Documentation: - ArduPilot Documentation​,
https://ardupilot.org/ardupilot/index.html.
[7] M. Petovello, C. O’Driscoll, ​Carrier phase and its measurements for GNSS: What is the carrier
phase measurement? How is it generated in GNSS receivers?​ Inside GNSS, vol. 5, no. 5, pp.
18–22, Jul./Aug. 2010
[8]ublock, NEO-M8P u-blox M8 High Precision GNSS Modules Data Sheet, [online],
https://cdn.sparkfun.com/assets/2/f/6/8/3/NEO-M8P_DataSheet__UBX-15016656_.pdf,
[Accessed Dec 1, 2019]
[9] Consumer product safety commission, Battery Safety standards, [online]
https://www.cpsc.gov/Regulations-Laws--Standards/Voluntary-Standards/Topics/Batteries,
[Accessed Dec 4, 2019]
[10] US Department of Commerce, A Guide to United States Electrical and Electronic Equipment
Compliance Requirements, February 2017, [online],
https://nvlpubs.nist.gov/nistpubs/ir/2017/NIST.IR.8118r1.pdf. ​[Accessed Dec 4, 2019]
[11] occupational health and safety standards, ​Regulations (Standards - 29 CFR),​ [online],
https://www.osha.gov/laws-regs/regulations/standardnumber
[12] Motor Control Tips, “​The Torque Equation and the Relationship with DC Motors,​” ​ MARCH
9, 2017. [Online]. Available: https://www.motioncontroltips.com/torque-equation/

23
APPENDIX
Senior Design Project Checklist
Project name: ​Unmanned Ground Vehicle for Simulating Unmanned Air
Vehicle Landing

Sponsor: ​ThayerMahan

Team members (majors/programs):

James Kuveke (EE)

Jonathan Luo(EE)

James Wales (EE)

Faculty advisor(s):

Dr. Shalabh Gupta

Skills, Constraints, and Standards: (​Please check (√) all those that apply to your project.​ ​)

Skills: (√)
Analog circuit design and troubleshooting √
Digital circuit design and troubleshooting √
Software development/programming √
Embedded Systems/Microcontrollers √
Web design
RF/wireless hardware √
Control systems √
Communication systems √
Power systems √
Signal processing √
Machine shop/mechanical design
Other (please specify): Python coding, MatLab coding
Constraints:
Economic (budget) √

24
Health/safety √
Manufacturability √
Environmental (e.g., toxic materials, fossil fuels)
Social/legal (e.g., privacy) √
Standards:
List​ standards/electric codes that you used (e.g., If applicable, list the name or # here:
IEEE 802.11, Bluetooth, RS-232, VHDL, etc.) ● NMEA-0183 [8]
● RTCM
● IEEE 2008 [10]
● IEC 62133 [9]
● UL 2054 [10]
● ​UL 2056 [10]
● e-CFR 1926.441[11]

25