Automated Irrigation Quadcopter Ceres By Dacota Singleton Tam Le David Martinez 9/2014 A Project Report Presented to The Faculty of the Computer Engineering Department San Jose State University In Partial Fulfillment Of the Requirements for the Degree Bachelor of Science in Computer Engineering
Senior Project Final Report
Aug 02, 2015
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Automated Irrigation Quadcopter
Ceres
By
Dacota Singleton
Tam Le
David Martinez
9/2014
A Project Report
Presented to
The Faculty of the Computer Engineering Department
San Jose State University
In Partial Fulfillment
Of the Requirements for the Degree
Bachelor of Science in Computer Engineering
Copyright © 2014
Dacota Singleton, Tam Le, David Martinez
ALL RIGHTS RESERVED
APPROVED FOR THE COLLEGE OF ENGINEERING
Lecturer Preetpal Kang, Project Advisor
Professor Keith Perry, Instructor
Dr. Xiao Su, Computer Engineering Department Chair
iv
ABSTRACT
Ceres Quadcopter Irrigation System
By Dacota Singleton, Tam Le, and David Martinez
Drones are currently being used to monitor and map large agricultural farms, but
can be utilized for so much more. Moisture sensors are used to reduce water
consumption by up to sixty percent while maintaining crop productivity. These sensors
are currently not being utilized on very large farms due to the difficulty in gathering the
data. Ceres will traverse fields, gathering moisture data wirelessly and bring that
information back to a central processing point for analysis.
The first objective of this project was to create an autonomous system that allows
farmers to more efficiently water their crops. Ceres is able to fly autonomously,
travelling to multiple locations through the use of a GPS module. The second objective
of the project was to give Ceres the ability to gather moisture data. Ceres accomplishes
this second objective by using a soil moisture sensor connected to a micro-controller and
wireless communication. A farmer can then use this data to decide which field actually
need to be watered.
This project demonstrates a new use for autonomous vehicles. Certain technologies
are not being utilized because gathering the data in impractical. Drones are able to gather
data when running miles of cables isn’t an option. Drones will continue to become more
and more relevant in industry and thus a curriculum that includes a course on drone
creation would be invaluable.
v
Acknowledgements
We would like to express our appreciation and gratitude towards our advisor
Preetpal Kang for his valuable and insightful ideas he provided during the planning and
development of our project. His willingness to use his extra time and provide us with any
help that lead us to the completion of this project was appreciated.
We would also like to thank several people outside our group that provided several
suggestions about the construction of our project:
Ryan Marlin
Thomas R. Mart
vi
Table of Contents
Chapter 1 Introduction
1.1 Project Goals and Objectives
1.2 Problem and Motivation
1.3 Project Application and Impact
1.4 Project Results and Deliverables
1.5 Market Research
1.6 Project Report Structure
Chapter 2 Background and Related Work
2.1 Background and Used Technologies
2.2 State-of-the-art
2.3 Literature Survey
Chapter 3 Project Requirements
3.1 Domain and Business Requirements
3.2 System (or Component) Functional Requirements
3.3 Non-function Requirements
3.4 Context and Interface Requirements
3.5 Technology and Resource Requirements
Chapter 4 System Design
4.1 Architecture Design
4.2 Interface and Component Design
4.3 Structure and Logic Design
4.4 Design Constraints, Problems, Trade-offs, and Solutions
Chapter 5 System Implementation
5.1 Implementation Overview
5.2 Implementation of Developed Solutions
5.3. Implementation Problems, Challenges, and Lessons Learned
Chapter 6 Tools and Standards
6.1. Tools Used
6.2. Standards
Chapter 7 Testing and Experiment
7.1 Testing and Experiment Scope
7.2 Testing and Experiment Approach
7.3 Testing and Experiment Results and Analysis
Chapter 8 Conclusion and Future Work
vii
References
viii
List of Figures
Figure 1.1. Market Shares Aerovironment ........................................................ Page No.03
Figure 1.2. Market Shares CybAero .................................................................. Page No.05
Figure 3.1. UML 2 Activity Diagram ................................................................ Page No.11
Figure 3.2. Process Decomposition Diagram .................................................... Page No.12
Figure 3.3. Domain Class Diagram for Ceres .................................................... Page No.12
Figure 3.4. Key Business Class State Machine Diagrams ................................. Page No.13
Figure 4.1. Context Diagram ............................................................................. Page No.20
Figure 4.2. Architecture Diagram ...................................................................... Page No.21
Figure 4.3. Signal Communication Diagram ..................................................... Page No.22
Figure 4.4. Data Flow Diagram ......................................................................... Page No.22
Figure 4.5. Control Flow Diagram ...................................................................... Page No.23
Figure 4.6. System Diagram .............................................................................. Page No.24
Figure 4.7. Sequence Diagram ........................................................................... Page No.27
Figure 4.8. Class Diagram ................................................................................. Page No.28
Figure 4.9. Class Association Diagram .............................................................. Page No.29
Figure 4.10. State Transition Diagram ............................................................... Page No.30
Figure 5.1. Gantt Diagram ................................................................................. Page No.37
Figure 5.2. Pert Diagram .................................................................................... Page No.38
Figure 7.1. Overview of Unit Testing ................................................................. Page No.43
Figure 7.2. Overview of Hardware Testing .......................................................... Page No.44
Figure 7.3. Directions of Motor ........................................................................... Page No.46
Figure 7.4. Accelerometer Testing Results ........................................................... Page No.49
Figure 7.5. Accelerometer Roll Results ................................................................ Page No.49
Figure 7.6. RC Testing Results ............................................................................ Page No.50
Figure 7.7. GPS Signal Verification and Satellite Connection .............................. Page No.52
Figure 7.8. 40% Soil Moisture Readings .............................................................. Page No.54
Figure 7.9. 60% Soil Moisture Readings. ................................................................ Page No.54
Figure 7.10. 90% Soil Moisture Readings ............................................................ Page No.55
Figure 7.11. Maximum Moisture Content ............................................................ Page No.56
ix
List of Tables
Table 1.1. Market Table Aeroinvornment ......................................................... Page No.04
Table 1.2. Market Table CybAero ..................................................................... Page No.06
Table 2.1. Relevant Course List ......................................................................... Page No.08
Table 3.1. Functional Requirements .................................................................. Page No.14
Table 3.2. Non-functional Requirements ........................................................... Page No.15
Table 3.3. Technology and Resource Requirements ......................................... Page No.17
Table 4.1. Use Cases .......................................................................................... Page No.25
Table 4.2. Test Cases ......................................................................................... Page No.26
Table 5.1. Team Responsibilities ........................................................................ Page No.33
Table 5.2. Task Table.......................................................................................... Page No.35
Table 7.1. Flight Test Results .............................................................................. Page No.48
Table 7.2. Spin Test Results ................................................................................. Page No.50
Table 7.3. Direction Test Results ......................................................................... Page No.51
Table 7.4. Hover Test Results .............................................................................. Page No.52
Table 7.5. Moisture Sensor Values ....................................................................... Page No.53
1
Chapter 1 Introduction
1.1 Project Goals and Objectives - Dacota Singleton
The goals of this project are to create an autonomous irrigation system for large
scale farm use. This was accomplished by creating a drone that travels between irrigation
points gathering moisture levels. The location of each irrigation point is hard coded into
Ceres. The moisture levels are sent to the drone through SJSUONE board
communication.
This project was focused on creating an autonomous irrigation system for farmers.
Some farmers have hired companies such as Labre Crop to create drones for field
monitoring purposes. This project takes this one step farther allowing the drone to
impact irrigation directly.
1.2 Problem and Motivation - Dacota Singleton
Most large-scale irrigation systems are inefficient in their use of water. Applying
moisture sensors to control irrigation has shown to reduce water consumption greatly.
The main issue with using moisture sensors on such a large scale is transferring the data
to some form of central control unit. Wires cannot be used as they would need to be
taken out whenever the land is ploughed. To combat this issue, a drone was created that
can gather the moisture data from a large farm quickly and easily. The drone then brings
that data to a control unit. From there a farmer can easily decide which areas need
watering and which don’t. This reduces water use while keeping costs of implementation
low. With droughts occurring more often, any amount of water this system saves will be
beneficial.
2
1.3 Project Application and Impact - Dacota Singleton
This project demonstrates an all new application for drones. This can lead to new
applications as people realize the wide range of uses a drone possesses. Autonomous
vehicular technology is a common subject at the college level. These vehicles are usually
ground based, due in part to the difficulty of creating an aerial vehicle. This project may
convince professors to add more practice with aerial vehicles in their curriculums, as they
are becoming more common in industry.
One common social issue with drones is privacy. Some people may be worried that
these drones are being use to spy on them. Hopefully, showing the usefulness of drones
should help alleviate some of this stress.
1.4 Project Results and Deliverables - Dacota Singleton
This project has two main deliverables: an autonomous quadcopter and a moisture
monitoring station. It also utilizes two different types of communication among its
systems. The first is SJSUONE board to board wireless communication. The second is
Bluetooth communication between Ceres and a laptop. The results of this project consist
of a quadcopter, moisture data gathering station, and a report. If Ceres functions on a
small scale properly, it will provide evidence that this system could be used to make large
scale agricultural irrigation more efficient. This is done by cutting down on manpower
and water usage.
1.5 Market Research – Tam Le & Dacota Singleton
This company is a world leader in the design and manufacture of small unmanned
aircraft systems (UAS). They have provided their systems for U.S. and allied armed
3
forces with reconnaissance data, helped protect endangered wildlife and preserve the
environment (AeroVironment, Inc. 2014).
The UAS that Aerovironment provide are based on their military UAS productions.
They wirelessly transmit video and other information generated by their payload of
electro-optical or infrared sensors which are connected to a hand-held ground control unit
(Aerovironment, Inc. 2014). The control unit is designed for durability and has a user
friendly graphical user interface. All of the UAS’s are designed to be portable and can be
assembled within five minutes.
The graph below shows the market trends of Aerovironment for October 17, 2014
from 10:00 AM to 4:00 PM. It shows that around midday of the 17th shares for
Aerovironment. As the day progressed the stock price dropped below the moving
average. This shows that investors of Aerovironment seems to have lost some faith in the
direction the company is moving towards. However, using a weekly view shows a fairly
better view of the company as the stocks show a better trend than the daily stock market
graph.
Figure 1.1: Market Share for Aerovironment
4
The table below provides numerical numbers for the stocks of Aerovironment. It
shows that there were 266,000 people who bought the stocks that day. This shows that
there is some interest in what this company is doing and that it is doing slightly well
combined with the information from the table and the graph.
Table 1.1: Market Table Aeroviornment
Lite Machines Corporation develops and manufactures UAV platforms as well as
corresponding control systems. They provide services to military, law enforcement and
civilian/industrial applications (Lite Machines Corporation 2010).
The Voyeur UAV has folding coaxial rotors so it can be easily stored. This design
allows for a soldier to hand launch the UAV in close proximity. These physical systems
are unconventional and simpler than traditional coaxial helicopter designs (Lite Machines
Corporation 2010). This design features onboard flight sensor data and control software
which stores terrain maps and mission profile information.
Previous Close: 29.3 Day's range: 28.17 – 29.77
Open: 29.75 52 week range: 24.58 - 41.67
Bid: 27.27 x 100 Volume: 250,852
Ask: 29.99 x 100 average volume(3m): 266,812
one year Target Estimate: n/a market cap: 643.07M
Beta: n/a P/E (ttm): n/a
Earnings Date: Nov 24 - nov 28 (Est.) EPS (ttm): n/a
Div& Yield: N/A(N/A)
5
CybAero develops and manufactures unmanned helicopters known as UAVs for an
international market. These UAVs are adapted to the unique requirements for each client
and reduce the risks of traversing hazardous environments (CybAero AB 2013).
APID 60 VTOL has three main components: platform, payload, and a ground
station with a control unit. It also includes avionics, sensors, video monitors, and data
links (CybAero AB 2013). The sensors that may be employed on the UAV can include a
video camera, IR camera, jammer, microwave radio equipment, biochemical sensors,
laser scanner, ground radar, and magnetometers.
The graph below shows the market shares from Cybaero. This graph is from July 1,
2014 to October 17, 2014. It shows that throughout these months that the market shares
have mostly stayed at the predicted moving average. Cybaero seems to be doing fairly
well and is evident in their semi-annual report.
Figure 1.2: Market Shares CybAero
6
Table 1.2 shows the income statement provided by CybAero’s semi-annual report.
The semi-annual report was from 2012 to 2014. It shows that the company had several
losses over the years but in their report they show that many investors and partners are
happy with what they have been doing. Overall, the company is doing fairly well.
Table 1.2: CybAero Income Statement
1.6 Project Report Structure – Dacota Singleton
Chapter two shows the technologies used in the creation of this project. Similar
technologies used by other markets will also be covered, displaying relevant background
information. This information is needed to convey what this projects real world
applications consist of.
7
Next, the requirements of this project will be covered. UML diagrams will aid in
describing the domain and business requirements of this project. Afterwards, both
function and non-function requirements will be described as well as context and
technological requirements.
The following section details the system design. Here the architecture interface and
structural design of the project are outlined. The constraints put on the project to
accurately show its limitations will be discussed. Finally, challenges faced and the
solutions or trade-offs used to combat these issues are listed.
Succeeding system design is the section covering system implementation. It
contains specifics on the different design implementations. Any techniques or algorithms
used will be explained here. It will also entail what lessons were learned during the
confronting of any and all issues faced during implementation.
A section covering tools and standards is next. This is where each tool used and
how they were used is listed. The standards relates back to each section of the report. It
depicts the specific standards that each component, requirement, design, interface, testing
protocol and documentation were based on.
The last chapter before the conclusion covers testing. The scope of the project is
explained by listing the major focus of the project and the criteria used for testing. Then
the experiment approach is described. The methods or techniques used will be listed
here. It will end with an analysis of the results received during testing.
8
Lastly, the conclusion will be covered. This section summarizes the project, what
was learned during the course of this class and any future work that could be done to
improve upon Ceres.
9
Chapter 2 Background and Related Work
2.1 Background and Used Technologies – Dacota Singleton
This project is based on two independent systems. The first is an autonomous
quadcopter and the second is an irrigation system that can sense water levels in soil.
Currently, most irrigation systems are time based, but different techniques can be
employed such as drip, flood, and center pivot. Each of these techniques is time-based
but also allows for user activation. Unfortunately, these techniques can lead to
over/under watering. Using sensors that measure the moisture level, which can then be
used as a signal to turn the system on, can water fields efficiently without human
intervention. An agricultural application of drones and aerial vehicles is real-time farm
monitoring; this allows farmers to see when something goes wrong. Fully autonomous
machines (including quadcopters) are also used for military reconnaissance and
exploration of dangerous areas. Automated machinery is also used for Amazon’s
quadcopter based delivery system, an application still in production.
Table 2.1: Relevant Course List
Course Application
Cmpe 124 Digital Design I This course taught us the basic on creating
actual circuits through hand on
experience.
Cmpe 127 Microprocessor Design I Gave us the knowledge on how to create a
system using several types of inputs for a
specific microprocessor.
Cmpe 187 Software-quality and Testing Testing any software creating for this
project is important. This software needs
to work under many conditions.
Cmpe 131 Software Engr I Aiding in the creation and understanding
of the software used in this project.
10
Table 2.1: Relevant Course List Cont.
Course Application
Cmpe 146 A hands-on understanding of the
SJSUONE Microcontroller, with
emphasis on object-oriented
programming and FreeRTOS.
Phys 50-52 General Physics A basic understanding of aerodynamics is
needed to work on a quadcopter.
2.2 State-of-the-art – Dacota Singleton
Drones and UAV’s are being used in many industries. In agriculture, several
companies are offering drones that will circle a predefined area and capture real time
images that can be viewed by the user. This allows farmers to check if irrigation systems
are set in place, are working properly, and determine if crops are still being gathered.
Maps are also created through this process, allowing data to be sent to agricultural
consulting agencies that can make suggestions on how best to utilize the given farm land
(Iowa Crop Consulting Firm, 2014). Labre Crop Consulting Company is one such
organization that offers both of these services.
Unmanned vehicles are being used in many non-agricultural industries as well.
Any industry where a cheap surveying resource is needed or sensor data needs gathering
can use drones. Searching for survivors with real-time imaging during a disaster is a
crucial use for hovering vehicles. A large number of drones can survey an area without
the need for pilots. Only a single operator is needed to watch the footage and alert rescue
teams to the location of any survivors.
There is currently no system that utilizes both an unmanned aerial vehicle and a
moisture regulator. Using moisture sensors to decide when to irrigate a field has been
11
shown to reduce water usage by over 50% (Haley, B. M., & Dukes, D. M 2012). New
systems will continue to be developed to utilize these technologies.
2.3 Literature Survey – Dacota Singleton
Several companies have begun using drones for agricultural purposes. One of the
first is Sense Fly. Their drone, eBee, can monitor a field through easy to program flight
patterns and create a 3d model of the farm (Iowa Crop Consulting Firm, 2014). News
reporters and the government also use drones to gather data. One such application is
searching for survivors during natural disasters such as floods or earthquakes. The
automated nature of the system allows several drones to survey an area quickly and
easily. Another application drones are beginning to be used for is the monitoring of
endangered animals such as African rhinos (Kreimer, B., N.D.). Journalists have also
been using drones to gather information on celebrities or film news stories from the sky
without the need of a helicopter.
Climate change is altering how irrigation practices of a particular area need to be
conducted. Using moisture sensors allows real time adaptations to be applied as issues
arise. Studies were done by the American Society of Civil Engineers to measure the
effectiveness of soil sensors. The study was done in Florida due to the changes between
dry warm weather in the spring and fall versus the increased rain during summer
months. The tests were done both on household yards and potted plants. Soil sensor
monitored automated irrigation systems were compared with time based irrigation
systems. Systems using a soil moisture sensor were able to maintain turf quality with a
65% decrease in water usage (Haley, B. M., & Dukes, D. M 2012).
12
Chapter 3 Project Requirements
3.1 Domain and Business Requirements – David Martinez
Figure 3.1: UML 2 Activity Diagram for Ceres
This UML 2 Activity Diagram acts as both the activity diagram and the Process
summary. Since the overall process of the system follows a simple flow, the two charts
could be consolidated into one. The basic flow of activity in the system begins with a
Home Base controlled by a user. The user will initialize a GPS path for the quadcopter to
follow using the path system interface.
The rest of Figure 3.1 describes the algorithm for the quadcopter to follow when it
continues on to each new destination. It will fly to the location, hover over the station
and communicate with the irrigation control system. When it receives the data it will
continue to the next station. When it has reached the final destination in the path
protocol, it will return back to Home Base.
13
Figure 3.2: Process Decomposition Diagrams for (A) Irrigation Control System and (B)
Ceres Quadcopter System.
Using the UML 2 Activity Diagram, both systems Ceres employs are visible. The
quadcopter will fly to the first water station, retrieve the Moisture data provided by the
Irrigation Control System, then continue to either fly to the next station or to the Home
Base.
Figure 3.3: Domain Class Diagram for Ceres.
14
Figure 3.3 shows the domain class diagram for the Ceres system, which visualizes
the major business classes. These two classes are the quadcopter and the irrigation
monitoring system. Quadcopter system contains three data components: GPS flight path
array, moisture data, and moisture handshake. GPS flight path array contains the
coordinates for each station. Moisture data contains the information given by the
irrigation monitoring system. Moisture handshake refers to the quadcopters ability to
initiate board to board wireless communication with the moisture monitoring system.
The irrigation control system contains three components: measure moisture
function, moisture data and quadcopter handshake. Measure moisture function gets a
signal from the moisture sensor to use as data for the soil content. The moisture data is
saved to memory and transmitted to the receiver. Quadcopter handshake transmits
relevant data to the quadcopter after the drone has initiated conversation.
Figure 3.4: Key Business Class State Machine Diagrams. (A) Quadcopter State Machine
Diagram and (B) Irrigation Control State Machine Diagram
15
Figure 3.4 depicts the actions of each component business class in the Ceres
System, showing the states that each takes to perform their given tasks. These states
depict actions taken by the two systems Ceres employs. It also demonstrates the
decisions made during these processes.
3.2 System (or Component) Functional Requirements - David Martinez
Table 3.1: Functional Requirements
Requirement No. Description
F01 The Ceres drone shall implement a CPU that stores and executes a
path program into memory.
F02 Ceres shall connect with a computer via USB to load or replace a
path program into the CPU.
F03 When Ceres is powered on, it shall begin executing the path
program, with the quadcopter hovering into the air for
initialization.
F04 F04A. Each sprinkler station shall use an equipped locator to send
a location signal to Ceres as a path destination.
F04B. This same station shall contain a digital moisture level
sensor
F05 Each Sprinkler station shall be in a standby mode, awaiting an
arrival signal from the Quadcopter.
F06 When an arrival signal is transmitted to the Irrigation Control, it
shall measure moisture level and save the data into a register.
F07 When saved, the Irrigation Control circuit shall transmit the
moisture data to the Quadcopter.
F08 When Ceres has successfully collected data the Irrigation Control
Circuit, it shall continue to the next destination on the programmed
path, repeating the process of data collection.
F09 When the path destination program has reached its final location,
the next path shall always fly the quadcopter back to the home
base.
16
3.3 Non-function requirements - David Martinez
Table 3.2: Non-functional Requirements
Requirement
No.
Description
NF01 Speed:
NF01A. The Ceres System should respond on an average of “3” seconds
per Ceres to Sprinklers communication.
NF01B. The Ceres System should respond on an average of “5” seconds
per Sprinkler to Ceres communication.
NF01C. Ceres shall have a maximum speed of “40” miles per hour.
NF01D. Sprinklers should have an average response time of “15” seconds
to respond to being activated.
NF02 Reliability:
NF02A. Ceres shall run on a rechargeable battery.
NF02B. Ceres shall always fly home when the path program has
concluded.
NF03 Robustness:
NF03A. In case of software failure, Ceres shall have a manual reset button
on the quadcopter.
NF03B. In case of software failure, Ceres shall have a system reset
programmed within 10 seconds of error.
NF03C. In case of hardware failure, Ceres shall have a separate locator
on the drone for user location.
NF04 Ease of Use:
NF04A. Employees of Ceres should be able to understand and work the
Ceres System without supervision after 4 hours of training.
NF04B. Customers shall be given a detailed instruction manual, with easy
to follow instructions.
NF04C. Customers should be able to operate the Ceres System without
supervision after 2 total hours of training.
NF04D. Ceres shall have the ability to be autonomous, and programmable
for remote control as well.
NF05 External Requirements:
Ceres shall comprise of two separate systems, the Ceres quadcopter
(Ceres) and the Ceres Irrigation System (Sprinklers), which will be used
simultaneously at runtime.
NF05A. Ceres shall be an electric quadcopter utilizing a lightweight
design for a large electronic carrying capacity.
NF05B. Sprinklers shall have an electrical system, primarily used for the
electronic components controlling the system.
NF05B. Sprinklers shall have an electrical system, primarily used for the
17
electronic components controlling the system.
NF05D. Sprinkler stations shall only store data for moisture levels, and a
real-time clock.
NF05C. Ceres System shall maintain a log, which keeps track of past
patrols of Ceres to each station.
NF06 Usability:
NF06A. Only one Ceres shall be used for a given set of Sprinkler stations.
NF06B. Only one data path shall be programmed to Ceres at a given time.
3.4 Context and interface requirements - David Martinez
Ceres’s quadcopter hardware shall be utilized in an outdoor environment. Ceres
will need to hover a safe distance away from the sprinkler water. This system should not
be used in rain as all electronics will most likely malfunction; it would also be deemed
unnecessary under those conditions. Given that Ceres shall be implemented in a dry
environment, the quad copter and irrigation system shall be built to withstand higher air
temperatures. Given that sprinklers shall be used with electronics, each moisture
monitoring station shall be built to withstand water from sprinklers and rain.
For development and testing, Ceres interface shall utilize a MultiWii 328P Flight
controller for quadcopter programming. For deployment, Ceres shall run similar to a
Windows environment with C# code to program the path sets. Data managing on the
quadcopter will be done using an SJSUONE microcontroller with “C-like” code. Ceres
shall also be able to transmit data regarding moisture data to a laptop through Bluetooth
communication.
18
3.5 Technology and resource requirements – Tam Le & David Martinez
Table 3.3: Technology and Resource Requirements
Part Name Description Characteristics
Turnigy 9x 9channel
transmitter
Contains module and 8
channel Receiver
V2 Firmware
HobbyKing x666
Quadcopter Frame
Lightweight frame for easy
add on
Fiber Glass Frame
666mm
9x5 Propellers Clockwise and Counter
Clockwise
N/A
10x6 Propellers Clockwise and Counter
Clockwise
N/A
MultiWii 328P Flight
Controller
Contains FTDI & DSM2
Port
ItG3205 Triple Axis
Gyroscope
BMA180 Accelerometer
BMP085 Barometer
Hobby King 30A Electronic
Speed Controls
4 needed, UBEC 30A
Hobbyking multi-rotor
power distribution board
DIY 8 x output PCB N/A
NTM Prop Drive Series 28-
26
4 motors needed 1000 kV, 235W
NTM prop drive 28 series
accessory pack
4 prop adapters needed N/A
turnigy nano-tech 6000mah
4s 25~50C lipo pack
Battery for quadcopter 6000mAh
Turnigy Reaktor 300W 20A
6s balance
charger/discharger
Includes accessories Lead Acid 2-24V
0.05-20A
Hobbyking power supply Power supply to be used as
alternative
100~240V, 5A
turnigy nano-tech 1300mah
3s 25~50C Lipo pack
Smaller Battery for
Quadcopter
1300mAh
MTK 3329 GPS Module To be used for GPS
Location
N/A
wRobot Arduino Soil
Moisture Sensor
Measures soil moisture
connects pin ports.
3.3-5V, 15mA
SJSUONE board Programmable embedded
systems board
FreeRTOS, C++
programmable
Bluetooth Bee Transciever To allow Ceres to
communicate with laptop
Low Power 1.8V
Operation, 1.8 to 3.6V I/O
Bluetooth Adapter Allow laptop to receive
Bluetooth signal
N/A
19
Each of the components mentioned in Table 3.3 is used to build and test Ceres.
There are two batteries mentioned in the table because testing required both of them. For
implementation, the 1300mAh will be the primary battery source, controlled by GPS
navigation as opposed to the documented transmitter/receiver. The SJSUONE board
includes an array of components built into the chip, including serial communication, flash
memory, built-in LEDs with push buttons, and a Micro SD slot. The board will power
the soil moisture sensor and receive data. A second SJSUONE board will be attached
and connected to the quadcopter for wireless communication.
20
Chapter 4 System Design
4.1 Architecture Design – Dacota Singleton
This design began by deciding the functionalities of the Ceres system. After that
was done, an overall design of the quad copter aspect was built, excluding
communication with other systems. Next the irrigation systems were designed and the
general list of parts was created. Finally, communication between the different systems
was researched and added to each system.
The design started with a base for the quad copter. Motors, gyroscopes, propellers
and control circuitry were researched. Receivers and transceivers were added to aid in
communication between multiple systems. Power supplies and moisture sensors were
also researched.
Figure 4.1: Context Diagram
21
This diagram shows how Ceres interacts with the market. It demonstrates all the
required individuals or jobs that need to be in place in order to create, sell, and install this
product. It also shows how they jobs communicate.
4.2 Interface and Component Design – David Martinez & Dacota Singleton
This section shows the general communication between Ceres and other systems.
As well as how Ceres functions from a data flow and control flow point of view. This is
done through the use of several diagrams.
Figure 4.2: Architecture Diagram
22
This diagram shows how the hardware pieces interact with each other. It
demonstrates which parts will be connect (either hardwired or over a signal) to each
other.
Figure 4.3: Signal Communication Diagram
This diagram shows how Ceres interacts with other systems, specifically how gps
signals communicate with satellites and how it sends or receives a signal from the
irrigation system.
Figure 4.4: Data Flow Diagram
23
This diagram shows how data is transmitted between the systems internal parts. It
begins with the moisture level being transmitted to the control unit for Ceres to take
where it’s needed.
Figure 4.5: Control Flow Digram
24
This diagram shows the decisions that the project makes, and the paths it takes
based on those decisions. Each possible pathway it demonstrated. This is used to show
how Ceres responds to any particular input.
Figure 4.6: System Diagram
25
This diagram shows the architecture of the individual systems implemented in this
project. Each system in this diagram is separated. This diagram also shows which parts
with communicate between the systems.
4.3 Structure and logic design – David Martinez & Tam Le
Table 4.1: Use cases Use Case
ID
Use Case
Name
Primary
Actor
Requirement
reference
Complexity Priority
1 Program a path Operator F02 High 1
2 Sync Ceres
with the Path
Operator F03 Med 1
3 Follow the
programmed
path
Ceres F07,F08, High 1
4 Communicate
with Sprinkler
Station
Ceres F09,F10,F11 High 1
Use Case Number: 1
Use Case Name: Program a path
Description: The operator uses the easy-to-use software included with Ceres to program a
path system for the Quad Copter to follow during runtime.
Use Case Number: 2
Use Case Name: Sync Ceres with the Path
Description: Connect the Quad Copter to the Computer Software using a USB cord to
have the path program load on the Quad Copter.
26
Use Cases Number: 3
Use Case Name: Follow the Programmed Path
Description: Once Ceres has the program loaded and set to execution mode, the Quad
Copter will begin flying on the programmed path.
Use Case Number: 4
Use Case Name: Communicate with Sprinkler Station
Description: When Ceres arrives at a Sprinkler Station, it will hover a specified height
above the station, and communicate with the Station.
Table 4.2: Test Cases
Test ID Test Case Description Requirements Pass/Fail Automated?
1 Have Ceres Fly F02,F03 Pass no
2 Program a Simple path F05,F06 Failed Yes
3 Retrieve Moisture Data F09,F10,F11 Pass Yes
4 Send moisture Data
Wirelessly
NF05C,
NF05D
Pas Yes
Test Case 1
During initial flight, control of Ceres is done with an RC controller. It needs to be able to
fly with the RC controller before automated flight can be tested.
27
Test Case 2
Automated flight is tested by loading in a predefined path and switching the quadcopter
to mission mode. The quadcopter should follow the path at a specified height and land
safely.
Test Case 3
The first SJ one board moisture sensing circuit needs to be tested. The moisture sensor is
placed in a patch of dirt and the moisture level is read on a laptop. The numbers are
logged and then water is added to the dirt. Steps are then repeated.
Test Case 4
The data is sent from one SJ one board to another and then read on a laptop to confirm
communication is working properly.
Figure 4.7: Sequence Diagram
28
The sequence diagram demonstrates the sequence for which communication will be
conveyed in our system. The operator programs Ceres, which will then travel to a
sprinkler station. The Sprinkler system will send soil moisture information to the Ceres
quadcopter and after a communication handshake routine the circuit will be put into wait
mode.
Figure 4.8: Class Diagram
The class diagram demonstrates the functionality and attributes of each class. The
three classes are the Operator, Ceres Quad Copter, and each Soil Mosture Sensor. The
operator functions to program the quad copter in the system, with Ceres and the Sprinkler
System performing the majority of the functions required of the system. The
functionality is the same to what is described in the sequence diagram, with the only
difference being the Fly() function. This general characteristic is what allows the
quadcopter to fly. The program name on the actual system is subject to change.
29
Figure 4.9: Class Assoiciation Diagram
An in-depth association diagram that shows the bi-directional characteristic
functions on each class. The GPS flight takes the quadcopter to the soil moisture sensor.
The quadcopter initiates a communication handshake, then the irrigation control receives
and acknowledges the handshake. The Irrigation control measures the soil moisture, then
sends the moisture data to the quadcopter.
Figure 4.10: State Transition Diagram
30
The state transition diagram demonstrates the specific states that Ceres will be in as
the system progresses in its function. State 1 has the system shut off, and then State 2 has
the program being synced into Ceres. State 3 is the traveling state, where Ceres
continues on the designated flight path. Ceres must determine if there are any stations
that it must go to; it will either go to the next station if there is one, or go back to the
home base. When the copter arrives at a station (State 4), it must first initiate the
communication with the soil moisture sensor circuit. Data will be transferred between
the two components during this state. It would then go back to State 3 to travel and
determine if there are any other stations to go to.
4.4 Design Constraints, Problems, and Trade-Offs and Solutions
4.4.1 Design Constraints – Dacota Singleton, Tam Le & David Martinez
There are several design constraints related to this project. They pertain either to
hardware, software or reliability. The quad copter, or Drone, needs to be light enough to
fly while it carries all other hardware that it will need in order to function properly. It
also has to be powerful enough to fly, and maintain its path, while it’s windy. A major
portion of the project will be finding the correct power to weight ratio for the quad
copter.
The next major constraint pertains to software, or a combination of software and
hardware implementation. Since the quad copter must fly autonomously it has to be able
to sense the signals from different locations accurately. It then must be able to fly to that
location, read the water level and send a signal to either turn on or turn off the irrigation
31
system of that area. To turn on an irrigation system however, this project needs access to
a working irrigation system that is controllable through an electronic signal. To
demonstrate this however, the signal will likely be sent to a laptop where the moisture
level can be shown.
Reliability is the final constraint. The purpose of a drone is for it to be able to do its
job without the need of constant supervision. This means it must be able to keep working
on its own for long periods of time without the need of a user. If anything goes wrong,
the quad copter could not only stop functioning, but it may also fall out of the sky. This
poses a threat to both the equipment, and anyone working below.
4.4.2 Design Problems & Challenges - Dacota Singleton, Tam Le & David Martinez
One major challenge of this project is waterproofing. The quad copter itself may
not need to be waterproof as a farmer does not need to run this irrigation system in the
rain, but the circuit that sends location and moisture level signals from the ground to the
quad copter will need to be waterproof. Any waterproofing done to this circuit cannot
interfere with its ability to send a signal.
Another challenge would be making this economically sound. This means the
drone system must be cost effective. If the drone is expensive to build, there would be no
economic benefit and thus would be an ineffective project.
The final challenge faced would be dealing with the image people have with drones.
Drones or any autonomous vehicle such as this quad copter currently have a stigma cast
32
on them thanks to popular media. Many people don’t trust drones because they believe
the government uses them to spy on people.
4.4.3 Design Solutions and Trade-Offs- Dacota Singleton, Tam Le & David Martinez
To solve the issues of this project being cost effective and the issue of weight the
parts will be carefully selected which will be just as powerful as needed without spending
excess money on equipment that may not fully utilize. The trade-off created due to this is
not having much leeway when it comes to adding functionality in the future. Next the
irrigation circuits will need to be waterproofed. This will be done, either by encasing the
circuit in a waterproof shell or by running waterproof cables from the moisture sensor to
a transmitter, keeping the transmitter away from all liquid.
Different methods may need to be put in place depending on the type of irrigation
system a particular farm is using. This does increase cost and may also affect signal
strength. To solve the reliability issue and the communication between all the hardware
devices through software, extensive testing will be done at each stage. The main trade
off associated with this is a longer testing period. The final challenge will be removing
the negative image of drones. To do this, Ceres will be marketed as an irrigation
autonomous quad copter, instead of using the term drone. Ceres’ functionalities should
speak for themselves when farmers favor towards using this product.
33
Chapter 5 System Implementation
5.1 Implementation Overview – David Martinez
The Project team consists of Dacota Singleton, David Martinez, and Tam Le. The
advisor to this project team is Lecturer Kang Preetpal. The following table will provide
the functions and the roles each member possesses:
Team
Member
Major Roles Assigned Responsibilities
Dacota
Singleton
Computer
Engineer
Team Lead
Programmer
Quad Copter construction
Quad Copter Programming
David
Martinez
Computer
Engineer
Irrigation system Designer
Programmer
Design irrigation system
Irrigation system programming
Tam Le Computer
Engineer
Quad Copter Designer
Lead Programmer
Quad Copter Programming
Automatic irrigation Programming
The scope of implementation for this project went to the physical building of a
quadcopter and the programming a soil moisture sensor circuit. The quadcopter was built
from components ordered through an online hobby store. C# is used for the flight
controller, utilizing an IDE made for the board. It was first built to fly via remote control,
requiring a majority of the allotted time for balance and stabilization. Once a successful
flight was made, the efforts were shifted to the GPS module, which gave the quadcopter
the capability to fly on its own to a specific GPS location. Included with the GPS module
is a user-friendly GUI that allows a location to be chose for the quadcopter to fly to. This
is the defining characteristic of the project, requiring the most time to accomplish.
34
For the soil moisture circuit, a moisture sensor was connected to a micro controller
and measured a potted plant using an analog-to-digital converter. Through Eclipse
Embedded, a C/C++ language was used to program the microcontroller, controlling the
moisture sensor and an embedded wireless component. The battery-powered
microcontroller sends the moisture level to a requesting second microcontroller on the
quadcopter. This second microcontroller requests the data when it gets near enough to
the first one, and the data is transmitted. The data is saved on an SD card inserted into
the microcontroller for further study.
5.2 Implementation of Developed Solutions – David Martinez & Tam Le
The quadcopter was built using a multiwii flight controller which sends signals to
the escs to control flight. The sensors are embedded on the flight controller which is
programed using an algorithm that calculates the orientation through the x, y, and z
coordinates for the accelerometer, gyroscope, and magnetometer orientation. These are
used to keep the quadcopter in balance during flight. RC signals are sent using a
transmitter installed to the multiwii flight controller. The program sets up the pins
through several define statements for the standard RX connections. This program allows
the radio controller the ability to communicate with the quadcopter. The GPS also uses a
similar code to define the pins that needed to be connected. The GPS module code
defines the actual equation for the flight path of the quadcopter through coordinates
found through the GPS function.
For the soil moisture sensor, an Arduino moisture sensor was used to send analog
signals through an analog-to-digital converter on an SJ one board. Utilizing embedded
35
pins on the SJ one board, the ADC translates the moisture sensors analog data to a digital
integer number. Further testing with a moisture meter on a potted plant was required to
validate the data from the moisture sensor. A loop was used to have the circuit wait to
retrieve data when a wireless request was received by another SJ one board.
The SJ one board achieved wireless communication with an embedded mesh
network-capable Nordic chip. Using this network with an antennae, the microcontroller
on the quadcopter could request and receive data from moisture sensor circuit. A series
of queue-based tasks and a semaphore driven mesh network created this wireless
communication system.
Table 5.1: Task List
Task
Mode Task Name Duration Start Finish
Predecess
ors Notes
Manually
Scheduled
Phase 1 -
Planning 83 days
Thu
1/23/14
Sun
5/18/14
Group members:
Dacota Singleton,
Tam Le, David
Martinez
Manually
Scheduled
Approved
Abstract V1 18 days
Thu
1/23/14
Sun
2/16/14
Assigned to entire
group.
Manually
Scheduled Get an Advisor 9 days
Thu
1/23/14
Tue
2/4/14 Dacota Singleton
Manually
Scheduled
Abstract,
Background and
related Work
27 days Mon
2/17/14
Tue
3/25/14 2 Dacota Singleton
Table 5.1: Task List continued
Manually
Scheduled
Project
Plan/Schedule 35 days
Tue
2/4/14
Sun
3/23/14 David Martinez
Manually
Scheduled Weekly Minutes 83 days
Thu
1/23/14
Sun
5/18/14 Dacota Singleton
Manually
Scheduled
Project
Requirements 39 days
Sun
2/16/14
Wed
4/9/14
David Martinez
(irrigation), Tam
36
Specification Le (Quad Coptor)
Manually
Scheduled
Project Detailed
Design 48 days
Sun
2/16/14
Tue
4/22/14 Entire Group
Manually
Scheduled
Project Test Plan
and Test Cases 53 days
Sun
2/16/14
Tue
4/29/14 Tam Le
Manually
Scheduled
Phase 2-
Prototyping 36 days
Wed
6/25/14
Wed
8/13/14
Same Group
Members
Manually
Scheduled
Project
Presentation 57 days
Sun
2/16/14
Mon
5/5/14 Entire Group
Manually
Scheduled
irrigation
Prototyping 94 days
Wed
4/9/14
Mon
8/18/14 David Martinez
Manually
Scheduled
QuadCoptor
Prototyping 76 days
Wed
4/9/14
Wed
7/23/14
Dacota Singleton,
Tam Le
Manually
Scheduled Ceres Prototype 20 days
Thu
7/24/14
Wed
8/20/14 12,13 Entire Group
Manually
Scheduled Phase 3 - Testing 87 days
Wed
8/20/14
Thu
12/18/14
Same Group
Members
Manually
Scheduled Ceres Testing 86 days
Thu
8/21/14
Thu
12/18/14 14 Entire Group
Manually
Scheduled
Ceres
Presentation 0 days
Wed
12/10/14
Wed
12/10/14 16,14 Entire Group
37
Figure 5.1: Gantt chart
38
Figure 5.2: Pert Chart
5.3 Implementation Problems, Challenges, and Lesson Learned – Dacota Singleton
This project came with many different challenges. The first and most common was
broken or incorrect parts. Hundreds of dollars were spent on ordering parts and a lot of
time was wasted waiting for new parts to arrive. One such instance occurred when we
realized that the battery was too heavy for the amount of force we were generating.
Another major challenge was just getting the quadcopter off the ground. There is an
endless number of things that can go wrong when building a quadcopter and it is
impossible to account for every variable in the planning phase. Crashing also became an
insue when a landing did not work correctly. One crash broke several parts that we did
not have spares of so more time was wasted waiting for those new parts. In the end we
39
were unable to get the autonomous flight to the point we would have liked due to all the
time lost in the basic building of the quadcopter.
Most of the issues encountered we problems with parts and little errors in the
building of coding of the project that ending up wasting a lot of our time. These issues
were mainly due to our inexperience with quadcopters and what goes into building them.
What took us several months to do originally would likely take just a couple weeks to
replicate now. If we had picked a senior project we would already somewhat
experienced with or had we experience with quadcopters we could have gotten to the
autonomous portion sooner. Or designed a better project from the beginning as our initial
design may not have been practical based on our experience.
40
Chapter 6 Tools and Standards
6.1. Tools Used – Tam Le & Dacota Singleton
The main tools and hardware used for the Ceres project included: Arduino IDE,
Eclipse IDE, Hyperload, Hercules, Neo-6m GPS Module, Arduino moisture sensor,
Multiwii flight controller, and the SJ one board.
The Arduino IDE and the Eclipse Embedded IDE were chosen due to the group’s
choice in boards. The Multiwii board was only compatible with the Arduino IDE and
other IDEs did not have the ability to upload the code to the Multiwii board. Eclipse was
used for the SJ One board as Eclipse Embedded version allowed for simple debugging
and easy programming for the board. Hyperload was used to upload the program on the
board through a .hex file. Hercules was needed in order to view the output of the
program uploaded onto the SJ one board. Hercules can also be utilized as a terminal for
FreeRTOS, allowing for user terminal input if necessary.
The Neo-6m GPS module was used to provide autonomous flight for Ceres. The
project uses a GPS module because it provided a simpler and more efficient method for
autonomous flight. Ceres would use the GPS module on the quadcopter to fly
autonomously by hardcoding GPS locations into Ceres as a flight path.
The boards that were chosen for Ceres were the Multiiwii and SJ One board. The
Multiiwii board was chosen for all of the extra sensors that came attached on the board,
such as the magnetometer, gyrometer, accelerometer, and barometer. The group decided
that with these sensor, it would be an adequate board to work as the flight controller for
Ceres. The SJ One board was chosen to be used as the controller for the water
41
management system. The board was chosen in part from the suggestion of the group’s
advisor, Preet. He suggested the board due to the functionalities it possessed such as
board to board communication and C-language programming. The board also utilizes
FreeRTOS, a real time operating system that allows can allow input commands through a
terminal. FreeRTOS initializes efficiently, allowing for instant program loading,
debugging, and execution.
Other tools in the project include Canvas which is being used to turn in updates,
weekly reports and assignments pertaining to Ceres. Criterion is being utilized to
enhance the quality of our final report. Microsoft office is being used to create and
design word documents as well as any PowerPoints the project may need. Visio is being
used to create charts and diagrams outlining specific parts of the project from activity
diagrams to business models. Text messaging and emails keep the group in constant
contact. GanttProject is being used to design this projects Gantt chart which allows us to
create a schedule for each section of the project and report.
6.2. Standards – Tam Le & Dacota Singleton
Three main standards will be followed during the creating of Ceres. These
standards are quality, simplicity and dependability. This three standards best represent
what a Drone, or any autonomous vehicle, should be.
Ceres must adhere to a certain standard of quality when it comes to parts and
production. If cheap and easily broken parts were to be used, Ceres would not likely
function properly in slightly harsher than normal conditions.
42
Simplicity is another standard followed during the creation of Ceres. Autonomous
devices can be very complicated to build and implement. This is why only the necessary
components and functions will be installed for its initial creation. The basic
functionalities must be in place and working properly before any unnecessary parts of
functions are added. Things like aesthetics are overlooked as it is unimportant in this
type of project, at least in the beginning.
The last standard is dependability. As an autonomous quad copter, Ceres needs to
be able to function for long periods of time in varying weather conditions. The only time
a user needs to be present is when Ceres needs to be connected or disconnected to a
charging station. Potentially this interaction could be removed using a wireless charging
pad. Nevertheless, Ceres must be able to function autonomously for extended periods of
time.
43
Chapter 7 Testing and Experiment
7.1 Testing and Experiment Scope – Tam le & Dacota Singleton
Testing will be done in several steps. The first step to testing Ceres on the software
side would be to do unit testing on the code that was written for the project. The code
will be compiled and checked on the Arduino IDE to check for simple syntax errors for
each module of the code. The focus on this part of the test is on the logical and syntax
errors of the code. The objective of this test is to make sure that the code written will be
error free. The hardware side of the project will be using a bottom-up testing for
integration testing. The hardware will be tested along the way as each component is
installed on the frame. The focus of these tests are to ensure that the code written was
correct and would create the outcome the team expected.
Figure 7.1: Overview of unit testing
44
Figure 7.2: Overview of hardware testing
7.2 Testing and Experiment Approach – Tam Le & David Martinez
The initial test of Ceres was to test each module of the code. The modules that
were tested are: GPS, MultiWii, Sensors, and RX. This was done by using the Arduino
IDE. The main focus on this test was to make sure that syntax errors and logic errors
would not be present within the code. To do this each module was tested by using unit
testing. If the module had passed the test script written the group would consider that
module as passed. The scope of this test was focused on the software side and
concentrated on syntax errors and logical errors within the code.
For each module there were specific test created. The tests for the GPS just
checked whether the GPS would receive a signal and if it did the code would respond by
outputting a zero if it failed and a one should it pass. The test for the RX receiver was
tested by doing similar tests with an output of zero or one if it failed or passed. The
45
Sensors were tested by an open source gui that the group used. The gui provided graphs
and numbers that would output signals based on the sensors data.
The radio controlled portion was tested next. It focused on the RC signals the
quadcopter would receive. The test involved connecting the multiwii board to the Wiigui
program which allowed the group to see if the remote control would transmit the signals
to the multiwii board.
The next test that was done was focused on the motor connections made with the
multiwii board. The objective of this test was to make sure that each connection was
created correctly to the board. This test was the first test in the group’s implementation
testing. The testing would involve turning on the quadcopter without the propellers
attached to see if the motors would run. If the motors ran than the group considered that
the test passed.
The following test involved the direction of the motors on the quadcopter. The
focus on this test was mainly the rotation of the motors. The test involved turning on the
quadcopter and viewing the direction the motors would spin. The test would be
considered successful if the group had two motors spinning clockwise and two motors
spinning counter clockwise as shown in figure 7.3.
46
Figure 7.3: Directions of motor
Once the quadcopter passes the RC, motor connections, and Motor rotation test the
group would conduct the liftoff test. The test focuses on the quadcopters ability to liftoff
and stay in the air for a specific amount of time. The test is considered successful if the
quadcopter can lift off the ground and stay in the air for a minimum amount of five
minutes. The test is conducted by placing the quadcopter on the ground and allowing for
the program to work with the remote control and applying the thrust to the quadcopter.
The GPS module is tested by checking the connections of the module. The focus
on this test is to make sure the GPS functioning correctly. The test involves, plugging the
quadcopter into the multwii config to see if a signal is produced by the GPS and if the
position of the quadcopter can be seen on the map API in the program. The test is
considered to be successfully if the GPS indicator on the gui is green and if the position
of the quadcopter can be seen on the map gui.
The final test of the quadcopter is to apply the GPS and test the path programed into
the quadcopter. The test will focus on the ability to travel autonomously with the GPS
installed on the quadcopter. The test involves hardcoding the flight path on the multiwii
board and switching the quadcopter to “mission mode” and allowing the quadcopter to
fly there. The test is successful should no problems occur during the flight path.
The moisture sensor was tested by programming the SJ one board to operate the
sensor and use the microcontroller as a data receiver. The test focused on making sure the
sensor produced a type of output. Research into the sensor required the use of an analog-
to-digital converter to achieve this goal. Once this was programmed into the board, the
47
moisture sensor was connected via wires and tested. The test involved putting the sensor
in a cup of soil to measure its moisture content. The test was successful if the water
sensor produced a numerical output that changed with the increase of water in a cup of
soil.
The numerical output of the water sensor was done by repeating the previous tests
output and comparing it to a typical moisture probe for a potted plant. The test focused on
comparing the numerical values with the various levels of moisture on a scale from 1-10.
The test involved putting both sensors into a potted plant with low moisture content,
taking the numerical value every 5 seconds, adding a certain amount of water, then
repeat. The test was successful if the numerical value had a direct correlation with the
level measured on the potted plant probe.
7.3 Testing and Experiment Results and Analysis – Tam Le & David Martinez
The results of the initial test for the separate modules of the code which are
separated into GPS, MultiWii, Sensors, and RX. The Table below show the expected
results and results that the group was expecting from the GPS, MultiWii, and RX
modules. As shown the test caught several errors in the code when it was written. Most
of the errors were from small mistakes in the naming of a variable or an equation that was
missing the correct variable. The test also allowed the group to catch some logical bugs
early in this stage of the project.
48
Table 7.1: Flight test results Module Test Number Test Action Expected Result Result Pass/Fail
GPS 1 Test code to check
the logic of the
GPS code
one Zero Fail
GPS 2 “” One One Pass
MultiWii 1 Used a code that
states whether the
led is “on” and
whether it is green
or red
On and Green On and red Fail
MultiWii 2 “” On and Green On and red Fail
MultiWii 3 “” On and green On and Red Fail
MultiWii 4 “” On and green On and green Pass
RX 1 Coded to test the
signals it receives
and displays in a
one or zero in the
output window
One Zero Fail
RX 2 “” One One Pass
Figures 7.3.1 to 7.3.2 show the test results for the Accelormeter sensor. The test
gave an acceptable result. The graph should be showing a straight line on both the roll
pitch and z values. It also provides the correct numbers as the expected numbers for Roll,
Pitch, Z are 0, 0, 255 when the quadcopter is on a flat surface. While the test showed the
Roll and pitch fluctuated between -1 to 0 it was still within an acceptable value for the
quadcopter to fly. The same result applied to the Z value within the accelormeter. While
it was off by one the value was still in an acceptable range that would allow the
quadcopter to keep level while in flight.
49
Figure 7.4: Accelerometer testing results
Figure 7.5: Accelerometer Roll testing results
50
Figure 7.6: RC testing results
Table 7.2: Flight test results
Test Number Expected Result Result Pass/Fail
1 Motors Spin Motors did not spin Fail
2 Motors Spin Motors spin Pass
The Results from table 7.2 show that in the first test we had a problem with the
connections. What the group found was that the ESCs had to be calibrated first before
the motors would spin correctly. Without the calibration the code written for the motors
to spin would not cause the spin the group was looking for. The calibration is needed to
set the minimum and maximum speed of the servo.
51
The motors directional test results can be seen in the following table. The first test
failed due to miscommunication between two of the team members and the wrong wires
were connected to the ESCS. The failed tests were easily fixed because only the wire for
the servos needed to be changed. The next thing that needed to be addressed were the
propellers. The group needed to have the correct propellers to produce a downward
thrust as the current propellers installed only two produced downward thrust will the
other two produced thrust upwards.
Table 7.3: Flight test results
Test Number Expected Result Result Pass/Fail
1 D2 and D3 spin
clockwise D5 and D6
spin counter
D2 and D5 Counter
spine D3 and D6
Clockwise spin
Fail
2 D2 and D3 spin
clockwise D5 and D6
spin counter
D2 and D5 Counter
spine D3 and D6
Clockwise spin
fail
3 D2 and D3 spin
clockwise D5 and D6
spin counter
D2 and D3 spin
clockwise D5 and
D6 spin counter
pass
The results for the Quadcopter flight test can be seen in table 7.3. With the first
initial testing of the flight the group believed that the lift and no hover was due to the
weight distribution of the large battery. The subsequent test proved to be more insightful
as the failure showed that it was not the weight distribution but the location at which the
pins were connected. The reason as to the failed test was due to the program only
working for D5, D6, D3, and D2 to provide the correct thrust even though the program
allowed the servos to spin correctly. After the corrections were made the group was able
to attain the lift and hover the project needed.
52
Table 7.4: Flight test results
Test Number Expected Result Result Pass/Fail
1 Lift off and hover for
at least one minute
Small jump no hover Fail
2 Lift off and hover for
at least one minute
small jump no hover fail
3 Lift off and hover for
at least one minute
Acceptable liftoff
and hovered for
about 1 min
pass
The result of the GPS module at first did not show promising results and displayed
the wrong icon when connected to the GUI and quadcopter. The reason for this wrong
result was that the old GPS module broke during testing and would
not power up. The second test of the new GPS module proved to
provide better results. The group knew that the module was powered
up and transmitting a signal due to the light on the GPS module. The
final test with the GPS module proved successful as can be seen in
figure 7.7. The test proved to be successful after fixing the RX and
TX connections.
The results of the moisture sensor produced a variety of results based on the water
content of the soil. For both tests made with the soil moisture sensor, the critical data was
achieved in the second test with the moisture probe. While a probe was measuring the
moisture of the soil, the digital water moisture sensor was calculating an average of
100,000 moisture measurements every five seconds, working to achieve variances in the
time it takes the soil to absorb the water. A half cup of water was added between tests to
give different percentages of water in the soil. The end value of each test indicates the
Figure 7.7: GPS signal
verification and satellite
connection
53
value that would the sensor would produce after stabilization. The following tables and
graphs give the results of the moisture test with the moisture probe and digital sensor.
Table 7.5: Moisture Sensor Values
Time(s) Digital Value (Ω) Moisture Percentage
0 1300 40%
5 1350 40%
10 1380 40%
15 1390 40%
20 1410 40%
25 1400 40%
30 1419 40%
35 1415 40%
0 1789 60%
5 1739 60%
10 1697 60%
15 1686 60%
20 1768 60%
25 1810 60%
0 2377 90%
5 2309 90%
10 2272 90%
15 2267 90%
20 2222 90%
25 2378 90%
30 2369 90%
35 2346 90%
0 2505 100%
5 2515 100%
10 2477 98%
15 2456 98%
20 2391 97%
25 2381 97%
54
Figure 7.8: 40% Soil Moisture Readings
These are the soil values when the potted plant was checked for the first time that
day. 40% indicates a need for water, and the soil moisture sensor takes time to stabilize a
solid reading.
Figure 7.9: 60% Soil Moisture Readings
55
These are the soil values when the potted plant was given half a cup of water. The
dip in the beginning of the graph indicates the absorbing of the water into the soil, as the
moisture content on the probe would predictably decrease before stabilization. Due to
leaves holding water and dripping at the 15 second mark, the readings saw a sudden rise
in moisture content.
Figure 7.10: 90% Soil Moisture Readings
These are the soil values when the potted plant was given a total full cup of water.
The dip in the beginning of the graph indicates the absorbing of the water into the soil, as
the moisture content on the probe would predictably decrease before stabilization. Due to
leaves holding water and dripping at the 20 second mark, the readings saw a sudden rise
in moisture content.
56
Figure 7.11: Maximum Moisture Content
After this point, any water added would bring about this type of result. The water is
added, and the sensor takes about 20 seconds to stabilize. This indicates that 2500-2520 is
the maximum soil moisture value the sensor can create, deeming the test a success.
The test had a few external factors, such as dripping leaves and added water
variances. The figure graphs of each soil percentage take these factors into consideration,
with the stabilized value being the end result of each graph. In order to find the maximum
value of the moisture probe, it was dipped in water, indicating which value on the meter
was the maximum value. As opposed to what the 1-10 values on the meter, the maximum
value of pure water was 5, indicating an imperfection in the probes design. The necessity
of digital probes for accuracy was proven through these tests.
57
Chapter 8 Conclusion and Future Work – Dacota Singleton
This project an autonomous quad copter moisture monitoring system was designed.
This system, Ceres, was done to provide large scale agricultural farms an ability to
improve water efficiently. It does this by gathering moisture data in a quick and efficient
manner. While the quadcopter and moisture monitoring systems have both been
developed, there is still more work to be done.
Several additions to this project would need to be made before it would be ready for
market. Ceres autonomous flight still has some bugs and would need to be absolutely
perfect and easy to use before it could be provided to farmers. Ceres, as well as the
moisture monitoring stations, need to be made completely water proof. While Ceres
doesn’t need to be used in the rain, if it’s in use and it begins to rain, precautions need to
be taken in order to prevent damage. Ceres also should be able to monitor its power
information. This way when the batteries begin to deplete, Ceres will notice and fly back
to home base or a charging station. A charging station where Ceres could land and
charge itself using wireless charging technology would also be a nice addition.
58
References
Collins, K. (n.d.). Police, paps and privacy: the challenges of drone journalism. Wired
UK. Retrieved March 14, 2014, from http://www.wired.co.uk/news/archive/2014-
02/12/drone-journalism-legal-and-privacy
Haley, B. M., & Dukes, D. M. (2012). Validation of Landscape Irrigation Reduction with
Soil Moisture Sensor Irrigation Controllers. American Society of Civil Engineers.
DOI:10.1061/(ASCE)IR.1943-4774.0000391
Iowa crop consulting firm offers ag services from drones. - Dealer Update Articles.
Retrieved March 14, 2014, from http://www.agprofessional.com/news/dealer-
update/articles/Iowa-crop-consulting-firm- offers-ag-services-from-drones-
245201631.html
Kang, P. (2014, October 27). SJ One Board. Retrieved October 27, 2014, from
www.socialedge.com/sjsu/index.php?title=SJ_ONE_BOARD
Kreimer, B. (n.d.). Drone Technology Will Prosper Africa. The Star. Retrieved March
14, 2014, from http://www.the-star.co.ke/news/article-158639/drone-technology-
will-prosper-Africa
McDonald RI, Girvetz EH (2013) Two Challenges for U.S. Irrigation Due to Climate
Change: Increasing Irrigated Area in Wet States and Increasing Irrigation Rates in
Dry States. PLoS ONE 8(6): e65589. doi:10.1371/journal.pone.0065589
Related Documents
