1. INFLIGHT DATA ACQUISITION SYSTEM FOR A SMALLER
AIRCRAFT
MUHAMAD NUR SYAMIM BIN IDRIS 1126585
PROJECT SUPERVISOR: DR. ARI LEGOWO
DEPARTMENT OF MECHANICAL ENGINEERING
KULIYYAH OF ENGINEERING
INTERNATIONAL ISLAMIC UNIVERSITY MALAYSIA
AUGUST 2016
2. ii
DECLARATION PAGE
I hereby declared that this thesis is based on my original work and research, with
exception of certain statements and studies, which were quoted and cited. I also declare that it
has not been previously or concurrently submitted as a whole for any other degree at IIUM or
other institutions.
MUHAMAD NUR SYAMIM BIN IDRIS 1126585
Signature: ………………………… Date: ……………………
3. iii
APPROVAL PAGE
I certify that I have supervised and read this study and that in my opinion, if conforms
to acceptable standards of scholarly presentation and is fully adequate, in scope and quality,
as Final Year Project report as a partial fulfillment for a degree of Bachelor of Engineering
(Aerospace) (Honors).
……………………………………………
[DR. ARI LEGOWO ]
Supervisor
4. iv
TABLE OF CONTENTS
DECLARATION PAGE ..........................................................................................................................ii
APPROVAL PAGE ................................................................................................................................iii
TABLE OF CONTENTS........................................................................................................................iv
LIST OF FIGURES.................................................................................................................................vi
LIST OF TABLES .................................................................................................................................vii
ABSTRACT..........................................................................................................................................viii
Chapter 1 : Introduction .......................................................................................................................... 1
1.1 Project Overview ................................................................................................................ 1
1.2 Problem Statement.............................................................................................................. 2
1.3 Objectives ........................................................................................................................... 2
1.4 Methodology Flow Chart.................................................................................................... 3
1.5 Report Outline.................................................................................................................... 4
Chapter 2 : Literature Review ................................................................................................................. 5
2.1 Inflight data acquisition system ......................................................................................... 5
2.2 Data Transmission .............................................................................................................. 7
2.3 Instrument sensors .............................................................................................................. 9
2.4 Miccrocontroller system .................................................................................................. 15
2.5 Summary of Literature Review......................................................................................... 19
Chapter 3 : Methodology .................................................................................................................. 20
3.1 The component selection and general information of the component.................................... 20
3.1.1 The CT UNO Board............................................................................................ 20
3.1.2 Inertial Measurement Unit – MPU 6050 ................................................................ 24
3.1.3 GPS-Ublox Neo-6M......................................................................................... 25
3.1.4 XBEE 1mW with antenna Series 1......................................................................... 26
3.2 Reassemble all the components of the system........................................................................ 28
3.3 Configuration and simulation using arduino software ........................................................... 32
3.3.1. Configuration of MPU-6050 sensor by using library MPU_6050......................... 33
3.3.2 GPS coding by using library TinyGPS++............................................................... 41
3.3.3 The combine coding of the GPS and the IMU-MPU-6050 .................................... 44
3.4 The final experimental setup ....................................................................................................... 56
3.5 The flow chart of the data collected processing .......................................................................... 59
3.6 Price Estimation of Design Product.................................................................................. 60
Chapter 4 : Results and Presentation Data ............................................................................................ 61
5. v
4.1 The quadcopter filght test............................................................................................................ 61
4.2 The manual way getting results................................................................................................... 61
4.3 Output from the initial setup using the arduino software ............................................................ 62
Chapter 5 :Discussion and Conclusion.................................................................................................. 74
5.1 Discussion......................................................................................................................... 74
5.2 Conclusion ........................................................................................................................ 76
References ............................................................................................................................................. 77
6. vi
LIST OF FIGURES
Figure 1 : The block diagram of the data system (John.F.Grabowsky & David.R.Stevens, 2001)........... 6
Figure 2 : The block diagram of the data acquisition unit and the data reitreval unit (Sanderson, 2000)
................................................................................................................................................................. 7
Figure 3 : Wireless system operation (Wikipedia.org) ........................................................................... 8
Figure 4 : The block diagram of hand band unit gyro and vehicle robot RF (Samarathunga &
Wanniarachi,, 2015) .............................................................................................................................. 11
Figure 5 : The (a) accelerometer and gyro sensitivy axes and (b) accelerometer and platform
coordinate axes (Skog & Peter, 2006) .................................................................................................. 13
Figure 6 : Example of Arduino Uno type ATmega328(Wikipedia.org) .................................................. 16
Figure 7 : Example of Arduino Uno Type ATmega328(wikipedia.org) .................................................. 16
Figure 8 : Example of Raspberry Pi (Wikipedia.org).............................................................................. 17
Figure 9 : The CT UNO microcontroller system retrieved from http://www.cytron.com.my/p-ct-UNO
............................................................................................................................................................... 20
Figure 10 : The comparison between the CT-UNO and Arduino UNO retrieved from
http://letsmakerobots.com/files/userpics/u21415/UNOvsUNO............................................................. 21
Figure 11 : MPU 6050 sensor retrieved from http://playground.arduino.cc/Main/MPU-6050........... 24
Figure 12 : GPS type Ublox Neo-6M retrieved from
http://www.tenettech.com/content/images/thumbs/0020721_uart_gps_neo_6m.jpeg........................... 25
Figure 13 : XBee 1mW Series 1 with antenna retrieved from www.cytron.com.my ............................. 26
Figure 14 : XBee connection pins as retrieved from the
http://www.techhelpblog.com/2012/12/05/xbee-s1-802-15-4-guide/ .................................................... 27
Figure 15 : Arduino UNO and MPU 6050 connection ......................................................................... 29
Figure 16 : Arduino UNO and GPS Ublox Neo 6M connection........................................................... 29
Figure 17 : Arduino UNO and XBee Series 1 connection..................................................................... 30
Figure 18 : Full circuit system connected of CT-UNO, MPU-6050,GPS Ublox Neo 6M and XBee also
with the external power source battery 11.1Volt................................................................................... 31
Figure 19 : The interface of the arduino software ................................................................................ 32
Figure 20 : The final setup of the in flight system product.................................................................... 56
Figure 21 : The final inflight system with external power source......................................................... 56
Figure 22 Quadcopter that used to test the inflight system NAZA type ................................................ 57
Figure 23 : The inflight test of the quadcopter...................................................................................... 57
Figure 24 : Connection between the inflight system and ground detected............................................ 58
Figure 25 : The XBee from ground and XBee in flight conncected ...................................................... 58
Figure 26 : In flight initial setup and output that come out from the arduino software after the
configuration ......................................................................................................................................... 62
7. vii
LIST OF TABLES
Table 1 : Comparison Between the Arduino Uno R3 and Raspberry Pi ( (Gouping, 2010)................. 18
Table 2 : Power pins(www.cytron.com.my) .......................................................................................... 22
Table 3 Input and output(www.cytron.com.my) .................................................................................... 22
Table 4 : The Pin assignments of XBee and their description retrieved from
http://www.sensorsuite.com/blog/xbee-pinout-series-2/ ....................................................................... 27
Table 5 : The specification of the XBee Series1.................................................................................... 28
Table 6: Bill Estimation of Design Product .......................................................................................... 60
Table 7: GPS and IMU data taken for 5m distance from the ground. .................................................. 64
Table 8 : GPS and IMU data taken for 10m distance from the ground ................................................ 66
Table 9 : GPS and IMU data taken for 15m distance from the ground ................................................ 68
Table 10: GPS and IMU data taken for 20m distance from the ground .............................................. 70
Table 11 : GPS and IMU data taken for 25m distance from the ground .............................................. 72
8. viii
ABSTRACT
This paper presents the study of development of acquisition inflight data system of a
smaller aircraft by selecting thecompatible sensors and microcontroller system. In addition,
this is to develop a real time system of the quadcopter by transmitting the position, speed and
acceleration to the ground XCTU and Terra Term system by configuring using the Arduino
Software. Some of the data are collected and compare so that it can be deduced from this
paper which effectives sensors are that can be improvise the smaller aircraft to do an activity
or mission.The parameters that will be collected were latitude,longitude and altitude from the
Global Positioning System(GPS) type of Ublox Neo 6M sensor and acceleration in x,y,z
direction and also yaw angle,pitch angle and roll angle from in Inertial Measurement
Unit(IMU) sensor type of MPU-6050.
9. 1
Chapter 1 : Introduction
1.1 Project Overview
There had been many research developed by scholars that an aircraft need a
development in instruments system so that it can flight safely and communicate well with
ground base. It is very important to have good communication and sensor system so that it can
detect any failure and dangered experienced by the aircraft. This had been studied and the
security of the aircraft can be protected by acquisite a system that can manage to supply
enough information and improvise data system.
In this paper, presents a flight data acquisition system of a smaller aircraft by selected
the simple example of instruments sensor and microcontroller system. In addition, this is to
developed real time data system of the smaller aircraft for example drone or quadcopter.
Some of the instruments can be collected and compare so that it can be deduced from this
paper which effectives instruments that can be acquisite the smaller aircraft to do an activity
or mission.
Hence, this research want to focus with the instruments sensor used to collect the
position,altitude ,acceleration and yaw,pitch,roll angle data of the smaller aircraft which are
by using IMU sensor and GPS sensor used along with the microcontroller system Arduino
Uno. The parameters that can be taken to indicate the performance system of the smaller
aircraft are the latitude,longitude,altitude, acceleration and also the yaw,pitch,roll angle that
will be discussed in the methodology chapter.
10. 2
1.2 Problem Statement
Previously past studies showed that the smaller aircraft like quadcopter use to have a
problem of balancing and at certain attitude it doesn’t have enough control to keep stability
and to encounter a flight aerodynamically firm. In order to have a good flight, it must need a
better vision and flight control so that a mission or activity of a smaller aircraft can be run
smoothly and secure.
1.3 Objectives
The objectives for this research are to develop a simple product of the
instrument sensor of smaller aircraft and to collect the attitude and position data
performance of the inflight data development system.
The main objectives of this research paper are:
1. To develop position and acceleration system of smaller aircraft by using GPS
sensor and IMU sensor.
2. To collect the altitude, position,acceleration and yaw,pitch,roll angle data of
the developed data system.
3. To transmit the real time of latitude,longitude,altitude, yaw,pitch and roll angle
data to the ground system.
11. 3
1.4 Methodology Flow Chart
Arduino Run Configure coding
IMU_TinyGPS++
Start
Valid Data
GPS :
Time,Date,Latitude,Longitude,Altitude
IMU : Accelertaion x,y,z and
yaw,pitch,roll
XBee accep the data and
transmit to the ground
XBee(receiver) receive the data
in the ground and give the
output within the range
End
No
Yes
12. 4
1.5 Report Outline
Chapter 1: This chapter is discussing about introduction which begins on
overview of inFlight Data Acquisition System(FDAS) and instrument used. Then, it
enlightens about the objective of this research and research methodology that show
how the research had been handled.
Chapter 2: This chapter will be discussing about literature review. Numbers of
research papers that related to this project’s topic for example concept of radar system
and ultrasound will be reviewed. Form that I can learn from the previous research
paper to prevent same problems happen and improved the research paper.
Chapter 3: This chapter focuses on methodology and design implementation.
In this chapter also, it will go through in selection of components selections and how
they can influence the design of this system. Both electrical design and mechanical
design are showed in this chapter as reference on how supposedly the final product
will be produced.
Chapter 4: The last chapter about discussion, conclusion and recommendation
for the outcome of this research paper.
13. 5
Chapter 2 : Literature Review
2.1 Inflight data acquisition system
A data system of aircraft need to be record efficiently so that it can operate in the most
safiest and secure condition. One of the aims of the data system inflight aircraft is to supply
information and pass it through the transmission connection to the ground based system.
The record of inflight data also are very essential as to provide the information,
observation and communication between the aircraft and the ground if the aircraft had been
missing or failure. According to (D.Miller, Jr., & Redmond, 1988) this inventions related to
components for monitoring and recording aircraft flight parameters both for providing a
record of selected flight data and for providing performance and maintanence information.
Another review from mid 80’s scholar was the inflight data system function to
transmit and transfer the data from another store and analyse the parameter of the data taken.
(A, Stephenson, & Suquamish, 1984) Mentioned an inflight data acquisition system use in an
aircraft flight data recorder accept the parameter data required analogly and then distribtute
the signals representative of various aircraft parameters to store information.
14. 6
From the scholar in 2001 also had shown the onboard aircraft data system was an
important part in order to communicate and examine the performance parameters of the
aircraft as stated by (John.F.Grabowsky & David.R.Stevens, 2001). The main point was it was
the communication vital between the aircraft and the ground system. In Figure 1 shows the
block diagram indicate the data parameters from the sensors which detected parameters to the
flight data acquisition unit(FDAU) and transmitted to the ground based system.
Figure 1 : The block diagram of the data system (John.F.Grabowsky & David.R.Stevens, 2001)
15. 7
2.2 Data Transmission
2.2.1 Radio Frequency
One of the best way to transfer the data parameters from aircraft to ground based
system is by Radio Frequency(RF) transmission. From (Sanderson, 2000) research, he finds
that the frequency of the radio signal at the first point is set with information and unset at the
second point, therefore gives an information services between the two points. In short, the
communication system work by transfer the frequency of the radio signal from one point to
another point as can be seen in Figure 2. It may be used for a variety of communication needs,
such as telephone service, video service, internet service, and other services requiring high-
speed data transfers. This data parameters of aircraft can be recorded through the data
transmission located at the ground field.
Figure 2 : The block diagram of the data acquisition unit and the data reitreval unit (Sanderson, 2000)
16. 8
2.2.2 Wireless Network
Wireless network communication is the transmission of data between the marks
without using the connection of electrical wires and medium transferring. It is the most
common uses nowadays and for example are mobile phone and radio. Some researcher had
found that the simpliest way to transfer and store the data of inflight data-ground based
system was by using the wireless communication.
As mentioned by (Farley, 2002) a device to enable automatic wireless communication
with an aircraft after the aircraft has parked at a gate. A terminal cellular bridge (TCB)
enables the retrieval of data from, and the sending of data to the aircraft by an internet service
provider. The internet service provider uses the Internet to send data to and receive data from
a remotely located network operation center and data warehousing center.
Figure 3 : Wireless system operation (Wikipedia.org)
17. 9
2.3 Instrument sensors
In order to provide the data system receives by inflight aircraft, it must needed the
instruments system such as sensors that detect the data receive analogly before transferring it
to the ground via network. Sensors are used to gives information about the environment that
human desired to know with non-physically involved. Among the sensors are gyroscope
sensor, accelerometer sensor and global positioning unit(GPS).
2.3.1 Gyroscope
Gyroscope is most of the common used to detect altitude and rotation stability of the
aircraft by using 3 axes of it. The previous research study by (Gerald, 1947) shows that the
use of automatic pilots on aircraft has generally been directed to the attitude control of the
craft about three axes of the craft, namely, in azimuth, pitch and roll. Such automatic pilots
have been effective in maintaining the craft at a constant, usually level, attitude. However, air
conditions may be such that, although the attitude of the craft is maintained constant, the
entire craft itself will be subject to accelerations and decelerations in many directions due to
air pockets, gusts, etc., which may render flight extremely erratic and uncomfortable to
passengers as well as causing undue stresses and strains in the aircraft and its controls.
18. 10
Scholars in 2013, where (Shu-hu, Shiju, & Liu, 2013) studied had mentioned the
gyroscope was used in microcontroller open source platform Arduino in combination with the
accelerometer to detect the attitude. They used the Kalman filter in order to improve the
attitude detection capability.This was also supported by the same research doing earlier that
had been done by (Yong & Zang, 2007) it said that the simulation by using the Kalman filter
had give a good results in the real experiment and applied to the self balanced robot.
The type of gyro sensor also determine the effectiveness of the project. The gyroscope
use along with the accelerometer and open source hardware of arduino. There have previous
research that can be reviewed according to (Juang & Kai-Yew, 2013), the robot used the
Parallax L3G4200D MEMS gyroscope which had advantages of three-axis angular
measurement and low power consumption.
However, another type of gyroscope used from the research of (Samarathunga &
Wanniarachi,, 2015) had classified by using Arduino ATmega328 and 2 axes Gyrometer
MPU6050 the contribute to the coordination according to the band motion of RF that transfer
the data given to the gyro so that it can control the hand gesture. The signal by the detector of
the gyro meter make it starts to move correlate with the RF signal given. This can be shown
by the block diagram in Figure 4.
19. 11
Figure 4 : The block diagram of hand band unit gyro and vehicle robot RF (Samarathunga & Wanniarachi,, 2015)
2.3.2 Acelerometor
Accelerometer is one of the famous used by aircraft to sense angular acceleration via
vibration to indicate the stability and condition of the aircraft engine. From the research study
of (Mollmann, 2005) the present invention relates to vibration monitoring for aircraft engines
and, more particularly, to an accelerometer configuration for measurement of system vibration
and indication of engine health for the aircraft engine.
While from the research study of (Zhi-yong, Zeng, & Zhang, 2011) the accelerometer
and gyroscopes were used in the quadcopter control mainly to have an optimul attitude angle
measurement. In addition, to encounter the noised interference problem of the quadcopter
controlthey had used the signal fusion with the Kalman filter and the results were well
reduced using this formula.
20. 12
In order to have a good and optimal results of detection of attitude and rotation control
in quarternion, there are some study of the calculation of accelerometer quarternion need to be
consider. The research of (Magnussen & M, 2013) state this calculation was based on
accelerometer and gyroscope from the Inertial Measurement Unit(IMU) . The calculation
results was based on the complex calculation and algorithm understanding.
Hence, the main point for the instruments sensor of this review were to determine
which suitable and supported by the project which are the accelerometer with the simplest
one.
2.3.3 Inertial Measurement Unit
Inertial measurement unit(IMU) is a device that combine the gyro and accelerometer
sensor which measure and detect the angular rate and sometimes uses in the control stability
of the UAV. The idea of development in IMU functionality had been study by some scholars
from (Skog & Peter, 2006) which state that main point of IMU study is at its calibration
where it said ideally independent of the orientation of the IMU, the magnitude of the
measured gravity force and angular velocity should be equal to the magnitude of the apparent
gravity force and applied angular velocity, respectively. Figure had been shown to show the
axes of the accelerometer and gyro.
21. 13
Figure 5 : The (a) accelerometer and gyro sensitivy axes and (b) accelerometer and platform
coordinate axes (Skog & Peter, 2006)
Another research from (Ahmad & Raja, 2013) where there were studied about the
various type of IMU sensor and the uses of it in unmanned aerial vehicle application. There
stated that the IMU’s as an alternatives way in navigation system application where it can
detect the position and attitude without GPS signal and also a lighter and cheaper devices.
And also another approach of IMU application was used by (D.Hazry, M.Sofian, & A.Zul,
2009) where its use for stabilizing the quadrotor by using the 3-axis accelerometer and 3-axis
gyroscope.
22. 14
2.3.4 Global Positioning Unit(GPS)
Generally, the Global Positioning Unit(GPS) is use to navigate and do detect the
positioning and location information of certain point. In aircraft system, the GPS do very
important in landing of an aircraft so that it can landing safely without harm. Studies from
(Alison K. Brown, 1994) reveals that the fixed ground facility includes a reference receiver
that measures differential corrections to the satellite code and carrier measurements and a
pseudolite that is employed to transmit these corrections to a broadband GPS receiver on
board the aircraft and to provide an additional code and carrier measurement to assist in the
navigation solution.
23. 15
2.4 Miccrocontroller system
In order to connect the instruments sensor to the aircraft, the microcontroller system
are used as a medium to gather the sensors system. The microcontroller system is a small-chip
size of computer contained integrated circuit with input and output control system. Two of
popular example of it recently are Raspberry Pi and Arduino Uno microcontroller board
design system.
And sometimes it also called as open source hardware which is designed as a platform
to develop a system instrumentation, utility circuit connection and also low cost development.
This also had been studied by (Russel, Steele, & Gooubran, 2012) where it discussed the
advantages of the open source software like Arduino which it helps to contribute to the rapid
development and encourage further development as mentioned earlier.
24. 16
2.4.1 Arduino
Arduino is an open source of computer hardware specifically a microcontroller
functions to project a system form of sensors and physical processed .There are many
researcher that developed an enhanced a system of sensors transmitted from physical form to
instrument sensors by using arduino.
It is also simply a more specifically contained a small sized computer characteristics
but in slight low memory storage because of the minor sized. According to (Gouping,
2010),Arduino makes the engineering project more very simple in term of usage. And also it
is more suitable use for sensor reading,LED driving and hardware application as it gives more
simplistic and better usage.
Figure 6 : Example of Arduino Uno type ATmega328(Wikipedia.org)Figure 7 : Example of Arduino Uno Type ATmega328(wikipedia.org)
25. 17
2.4.2 Raspberry Pi
Raspberry Pi is also an open source of computer hardware with a series of credited
card size that is function to do internet and software reading data more efficient and in
multitask ways.
According to (M Maksimović, V Vujović, N Davidović, & Milošević, 2014)
Raspberry Pi brings the advantages of a PC to the domain of sensor network, what makes it
the perfect platform for interfacing with wide variety of external peripherals. Comparative
analysis of its key elements and performances with some of current existing wireless sensor
nodes have shown that despite few disadvantages, the Raspberry Pi remains an inexpensive
computer with its very successfully usage in sensor network domain and diverse range of
research applications.
Figure 8 : Example of Raspberry Pi (Wikipedia.org)
26. 18
To compare between this two design and functions of microcontroller systems some
research had already been taken to considered. The table 1.0 below was provided by Gouping
Wang in 2010 where he compared between the Arduino Uno R3 and Raspberry Pi
Table 1 : Comparison Between the Arduino Uno R3 and Raspberry Pi ( (Gouping, 2010)
27. 19
2.5 Summary of Literature Review
From the review that had been done, there are some subcomponent need to be
analysed in this review. And also in order to achieve the objectives of the project which are
to develop a simple product of instrument sensors for a smaller aircraft and collected the
position and attitude data, this component are analysed and selected based on the review of
the previous research scholars. There are the instruments sensors; gyroscope and
accelerometer, GPS ,microcontroller system and also data transmission system.
The sensors selected are the main essential in order to monitor and control the position
and altitude of the small aircraft. From the three different countries of review it can be said to
improve and select the suitable gyroscope and accelerometer sensor are by select the
combination of the three axis gyro and three axis accelerometer sensor itself .And study by
most of the scholars from (Magnussen & M, 2013) and (Skog & Peter, 2006) had shown this
pattern of product developed.
It can be said that from the Table 1 by (Gouping, 2010) Arduino Uno was suitable for
the hardware application system for example sensors while Raspberry Pi is suitable for
software applicaton namely for internet data better usage and this statement was supported by
the Wang (2010).
28. 20
Chapter 3 : Methodology
The small aircraft flight data acquisition system works by combined and functioning
the microcontroller system, instrument system and also data transmission system.
Hence, some of the things were chosen to design this system. The arduino CT(Cytron Version
of Arduino)) UNO Board, Inertial Measurement Unit(IMU) type-MPU 6050, and also Digi
International XBEE Series 1 with antenna transmitter-receiver module.
3.1 The component selection and general information of the component
3.1.1 The CT UNO Board
Figure 9 : The CT UNO microcontroller system retrieved from http://www.cytron.com.my/p-ct-UNO
The CT-UNO is version for the improvise of Arduino UNO AT-Mega328p. The
functioning is similar with the Arduino UNO AT-Mega328p which support and provide the
storage of the system that connecting in the microcontroller. The CT-UNO can connect with
the USB micro B cable(phone USB type), power up the UNO to DC voltage of 15V and
29. 21
more stable,simple and harmonious as compare to the usual Arduino UNO AT-Mega328p as
shown in the figure below.
CT-UNO has the same characteristics and connections as Arduino UNO offer. 14
Digital I/O pins with 6 PWM pins, 6 Analog inputs, UART, SPI, external interrupts, and also
the I2C too. The SDA, SCL and IOREF pins is also in the CT-UNO There is also additional
of the ISP header pins (SPI and power). Hence, CT-UNO can have suitable and harmonious
with the Arduino UNO shield.
Figure 10 : The comparison between the CT-UNO and Arduino UNO retrieved from
http://letsmakerobots.com/files/userpics/u21415/UNOvsUNO
The CT-UNO contain 14digital input and output pins which basic connection pin for
the UNO are Vin ,5V, 3V3 and Gnd.
30. 22
Table 2 : Power pins(www.cytron.com.my)
VIN The input voltage to the Arduino board when it's using an external
power source Voltage can be supply through this pin, or, if
supplying voltage via the power jack, access it through this pin.
5V The regulated power supply used to power the microcontroller and
other components on the board. This can come either from VIN via
an on-board regulator, or be supplied by USB or another regulated
5V supply.
3V3 A 3.3 volt supply generated by the on-board regulator. Maximum
current draw is 50 mA.
GND Ground pins
Table 3 Input and output(www.cytron.com.my)
31. 23
Among the other basic configuration pins for the CT-UNO are by using the RX(0
pin),TX(1 pin) , External interrupts(2 and 3 pin) and other pins(PWM).
Serial: 0 (RX) and 1 (TX) pins. (RX) is used to receive while (TX) is to transmit the serial
data that configured from the arduino software. These pins are connected to the corresponding
pins of the CT-UNO’s USB to the Serial chip.
External Interrupts: 2 and 3. This pins can be control to send an interrupt on a low value, an
increase or decrease value, or a change in value.
PWM: 3, 5, 6, 9, 10, and 11. Provide 8-bit PWM output with the analogWrite() function.
SPI: 10 (SS), 11 (MOSI), 12 (MISO), 13 (SCK). These pins support SPI communication,
which, although provided by the underlying hardware, is not currently included in the
Arduino language.
LED:13. There is a built-in LED connected to digital pin 13. When the pin is HIGH value,
the LED is on, when the pin is LOW, it's off.
32. 24
3.1.2 Inertial Measurement Unit – MPU 6050
Figure 11 : MPU 6050 sensor retrieved from http://playground.arduino.cc/Main/MPU-6050
The MPU-6050 is the combination of the both accelerometer and a gyro in a single
sensor which is in the MPU-6050 chip . This sensor is basically can give out the x, y and z
data thus transferring data precisely to the UNO Board in a second. It connected to the UNO
board via the I2C bus which give directly data to the arduino software using I2C
configuration. The voltage use for this sensor is 3volt to the 5volt. But it is recommended that
to use the 5volt because of the I2C bus can be more efficient as the usage of voltage is higher.
33. 25
3.1.3 GPS-Ublox Neo-6M
Figure 12 : GPS type Ublox Neo-6M retrieved from
http://www.tenettech.com/content/images/thumbs/0020721_uart_gps_neo_6m.jpeg
The Ublox Neo-6M GPS is GPS sensor that can give out the location position ,time,
distance and also altitude data .This include that it have over 50 channel data and can send the
data in a second. Thus it enables to detect and find the satellite that had connected with this
Neo-6M GPS. Basically, the Ublox Neo-6M powered with 5Volt and have 4pins which are
Vin, Gnd, TX and RX that will connected with the CT-UNO Board.
34. 26
3.1.4 XBEE 1mW with antenna Series 1
Figure 13 : XBee 1mW Series 1 with antenna retrieved from www.cytron.com.my
XBees is the simple wireless communication that act as transmitter and receiver
communication within a range. XBee 1mW wire antenna series 1 as shown in the figure can
transmitted and received the data configuration in the microcontroller CT-UNO with a range
up to 100 meter (outdoor and within the line of sight). The detail for the XBee pins and
connection can be seen by the following figure.
35. 27
Figure 14 : XBee connection pins as retrieved from the
http://www.techhelpblog.com/2012/12/05/xbee-s1-802-15-4-guide/
Table 4 : The Pin assignments of XBee and their description retrieved from
http://www.sensorsuite.com/blog/xbee-pinout-series-2/
36. 28
The summary of basic general information of the XBee series 1 also can be found based on the
following table
Table 5 : The specification of the XBee Series1
Specifications Xbee S1 802.15.4
Performance
RF Data Rate 250kbps
Indoor/Urban Range 100ft(30m)
Outdoor/RF Line of Sight 300ft(100m)
Transmit Power 1mW(+0dBm)
Receiver sensitivity -92dBm
Digi Hardware S1
Power Requirements
Supply Voltage 2.8-3.3V DC
Transmit Current 45mA or 3.3V DC
Receive Current 50mA or 3.3V DC
Frequency Band 2.4GHz
Serial Data Rate 1200bps-250kbps
3.2 Reassemble all the components of the system
The data of the system were collected as the CT-UNO, XBee,MPU-6050 and GPS UBlox Neo 6M are
connected and configured by using arduino software to get the data desired. The final cicuit of
diagram connection of the system are attached as the following.
37. 29
Figure 15 : Arduino UNO and MPU 6050 connection
Figure 16 : Arduino UNO and GPS Ublox Neo 6M connection
39. 31
Figure 18 : Full circuit system connected of CT-UNO, MPU-6050,GPS Ublox Neo 6M and XBee also
with the external power source battery 11.1Volt.
40. 32
3.3 Configuration and simulation using arduino software
By using arduino software, it can be configure that the desired output for the sensor
that are being used.It consist th language (open source) and compiler. The flexible and
customize of programming language let the user to learn fast how to operate the arduino. The
Arduino IDE have customize library that nearly similar to the C and C++ which makes it
suitable for common user. The programming language also gives more control with
understandable coding for the user manage the input and output of the system. In this
experiment and simulation the arduino version 1.6.6 is being used. The software interface can be seen
in the following figure.
Figure 19 : The interface of the arduino software
41. 33
In this simulation using arduino software, it is required that to have latitude, longitude,
altitude, time, date , acceleration, yaw angle,pitch angle and roll angle at the end of the
results. Hence, the coding and configuration using arduino software and connection of sensor
made is shown according to the procedure below.
3.3.1. Configuration of MPU-6050 sensor by using library MPU_6050
The MPU-6050 sensor function can trigger the output of acceleration, euler
angle,quarternoins(w,xy,z) and also the yaw,picth and roll angle. In this simulation the desired
output that can be configured is the acceleration in x,y and z direction and also the yaw,picth
and roll angle.
Thus, the coding of MPU-6050 is used in this experiment that had been developed by
Rowberg(2012) but to compable with the XBee and GPS configuration some changes had
been made. The coding of MPU-6050 that had been configure is :
//Title: Mechanical Depth and IMU MPU6050 sensor reading
//
//Original Source:
//I2C device class (I2Cdev) demonstration Arduino sketch for MPU6050 class
using DMP (MotionApps v2.0)
// 6/21/2012 by Jeff Rowberg <jeff@rowberg.net>
// Updates should (hopefully) always be available at
https://github.com/jrowberg/i2cdevlib
//
/* ============================================
I2Cdev device library code is placed under the MIT license
Copyright (c) 2012 Jeff Rowberg
===============================================
*/
#include <String.h>
// I2Cdev and MPU6050 must be installed as libraries, or else the .cpp/.h
files
// for both classes must be in the include path of your project
#include "I2Cdev.h"
#include "MPU6050_6Axis_MotionApps20.h"
//#include "MPU6050.h" // not necessary if using MotionApps include file
42. 34
// Arduino Wire library is required if I2Cdev I2CDEV_ARDUINO_WIRE
implementation
// is used in I2Cdev.h
#if I2CDEV_IMPLEMENTATION == I2CDEV_ARDUINO_WIRE
#include "Wire.h"
#endif
// class default I2C address is 0x68
// specific I2C addresses may be passed as a parameter here
// AD0 low = 0x68 (default for SparkFun breakout and InvenSense evaluation
board)
// AD0 high = 0x69
MPU6050 mpu;
//MPU6050 mpu(0x69); // <-- use for AD0 high
/*
=========================================================================
NOTE: In addition to connection 3.3v, GND, SDA, and SCL, this sketch
depends on the MPU-6050's INT pin being connected to the Arduino's
external interrupt #0 pin. On the Arduino Uno and Mega 2560, this is
digital I/O pin 2.
*
=========================================================================
*/
/*
=========================================================================
NOTE: Arduino v1.0.1 with the Leonardo board generates a compile error
when using Serial.write(buf, len). The Teapot output uses this method.
The solution requires a modification to the Arduino USBAPI.h file, which
is fortunately simple, but annoying. This will be fixed in the next IDE
release. For more info, see these links:
http://arduino.cc/forum/index.php/topic,109987.0.html
http://code.google.com/p/arduino/issues/detail?id=958
*
=========================================================================
*/
// uncomment "OUTPUT_READABLE_QUATERNION" if you want to see the actual
// quaternion components in a [w, x, y, z] format (not best for parsing
// on a remote host such as Processing or something though)
//#define OUTPUT_READABLE_QUATERNION
// uncomment "OUTPUT_READABLE_EULER" if you want to see Euler angles
// (in degrees) calculated from the quaternions coming from the FIFO.
// Note that Euler angles suffer from gimbal lock (for more info, see
// http://en.wikipedia.org/wiki/Gimbal_lock)
//#define OUTPUT_READABLE_EULER
// uncomment "OUTPUT_READABLE_YAWPITCHROLL" if you want to see the yaw/
// pitch/roll angles (in degrees) calculated from the quaternions coming
// from the FIFO. Note this also requires gravity vector calculations.
// Also note that yaw/pitch/roll angles suffer from gimbal lock (for
// more info, see: http://en.wikipedia.org/wiki/Gimbal_lock)
#define OUTPUT_READABLE_YAWPITCHROLL
43. 35
// uncomment "OUTPUT_READABLE_REALACCEL" if you want to see acceleration
// components with gravity removed. This acceleration reference frame is
// not compensated for orientation, so +X is always +X according to the
// sensor, just without the effects of gravity. If you want acceleration
// compensated for orientation, us OUTPUT_READABLE_WORLDACCEL instead.
//#define OUTPUT_READABLE_REALACCEL
// uncomment "OUTPUT_READABLE_WORLDACCEL" if you want to see acceleration
// components with gravity removed and adjusted for the world frame of
// reference (yaw is relative to initial orientation, since no magnetometer
// is present in this case). Could be quite handy in some cases.
//#define OUTPUT_READABLE_WORLDACCEL
// uncomment "OUTPUT_TEAPOT" if you want output that matches the
// format used for the InvenSense teapot demo
//#define OUTPUT_TEAPOT
#define LED_PIN 13 // (Arduino is 13, Teensy is 11, Teensy++ is 6)
bool blinkState = false;
// MPU control/status vars
bool dmpReady = false; // set true if DMP init was successful
uint8_t mpuIntStatus; // holds actual interrupt status byte from MPU
uint8_t devStatus; // return status after each device operation (0 =
success, !0 = error)
uint16_t packetSize; // expected DMP packet size (default is 42 bytes)
uint16_t fifoCount; // count of all bytes currently in FIFO
uint8_t fifoBuffer[64]; // FIFO storage buffer
// orientation/motion vars
Quaternion q; // [w, x, y, z] quaternion container
VectorInt16 aa; // [x, y, z] accel sensor measurements
VectorInt16 aaReal; // [x, y, z] gravity-free accel sensor
measurements
VectorInt16 aaWorld; // [x, y, z] world-frame accel sensor
measurements
VectorFloat gravity; // [x, y, z] gravity vector
float euler[3]; // [psi, theta, phi] Euler angle container
float ypr[3]; // [yaw, pitch, roll] yaw/pitch/roll container
and gravity vector
// packet structure for InvenSense teapot demo
uint8_t teapotPacket[14] = { '$', 0x02, 0,0, 0,0, 0,0, 0,0, 0x00, 0x00,
'r', 'n' };
//================================================================
//Varialble For Mechanical Depth Sensor
//================================================================
#define RAW_MIN 50
#define RAW_MAX 387
char check = 0;
int sensorPin = A0; // select the input pin for the potentiometer
float sensorValue = 0; // variable to store the value coming from the
sensor
44. 36
float Degree;
float rodLength=0.9; // 1 meter
float offset=0.09;
float rad;
float Depth;
float D;
long tt=0;
float roll,pitch;
String dataString = "$DPDPT";
// ================================================================
// === INTERRUPT DETECTION ROUTINE ===
// ================================================================
volatile bool mpuInterrupt = false; // indicates whether MPU interrupt
pin has gone high
void dmpDataReady() {
mpuInterrupt = true;
}
// ================================================================
// === INITIAL SETUP ===
// ================================================================
void setup() {
// join I2C bus (I2Cdev library doesn't do this automatically)
#if I2CDEV_IMPLEMENTATION == I2CDEV_ARDUINO_WIRE
Wire.begin();
TWBR = 24; // 400kHz I2C clock (200kHz if CPU is 8MHz)
#elif I2CDEV_IMPLEMENTATION == I2CDEV_BUILTIN_FASTWIRE
Fastwire::setup(400, true);
#endif
// initialize serial communication
// (115200 chosen because it is required for Teapot Demo output, but
it's
// really up to you depending on your project)
Serial.begin(9600);
while (!Serial); // wait for Leonardo enumeration, others continue
immediately
// NOTE: 8MHz or slower host processors, like the Teensy @ 3.3v or
Ardunio
// Pro Mini running at 3.3v, cannot handle this baud rate reliably due
to
// the baud timing being too misaligned with processor ticks. You must
use
// 38400 or slower in these cases, or use some kind of external
separate
45. 37
// crystal solution for the UART timer.
// initialize device
Serial.println(F("Initializing I2C devices..."));
mpu.initialize();
// verify connection
Serial.println(F("Testing device connections..."));
Serial.println(mpu.testConnection() ? F("MPU6050 connection
successful") : F("MPU6050 connection failed"));
// wait for ready
Serial.println(F("nSend any character to begin DMP programming and
demo: "));
//while (Serial.available() && Serial.read()); // empty buffer
// while (!Serial.available()); // wait for data
// while (Serial.available() && Serial.read()); // empty buffer again
// load and configure the DMP
Serial.println(F("Initializing DMP..."));
devStatus = mpu.dmpInitialize();
// supply your own gyro offsets here, scaled for min sensitivity
mpu.setXGyroOffset(220);
mpu.setYGyroOffset(76);
mpu.setZGyroOffset(-85);
mpu.setZAccelOffset(1788); // 1688 factory default for my test chip
// make sure it worked (returns 0 if so)
if (devStatus == 0) {
// turn on the DMP, now that it's ready
Serial.println(F("Enabling DMP..."));
mpu.setDMPEnabled(true);
// enable Arduino interrupt detection
Serial.println(F("Enabling interrupt detection (Arduino external
interrupt 0)..."));
attachInterrupt(0, dmpDataReady, RISING);
mpuIntStatus = mpu.getIntStatus();
// set our DMP Ready flag so the main loop() function knows it's
okay to use it
Serial.println(F("DMP ready! Waiting for first interrupt..."));
dmpReady = true;
// get expected DMP packet size for later comparison
packetSize = mpu.dmpGetFIFOPacketSize();
} else {
// ERROR!
// 1 = initial memory load failed
// 2 = DMP configuration updates failed
// (if it's going to break, usually the code will be 1)
Serial.print(F("DMP Initialization failed (code "));
Serial.print(devStatus);
Serial.println(F(")"));
}
// configure LED for output
pinMode(LED_PIN, OUTPUT);
46. 38
}
// ================================================================
// === MAIN PROGRAM LOOP ===
// ================================================================
void loop() {
// if programming failed, don't try to do anything
if (!dmpReady) return;
// wait for MPU interrupt or extra packet(s) available
// while (!mpuInterrupt && fifoCount < packetSize) {
// other program behavior stuff here
// .
// .
// .
// if you are really paranoid you can frequently test in between
other
// stuff to see if mpuInterrupt is true, and if so, "break;" from
the
// while() loop to immediately process the MPU data
// .
// .
// .
// }
// reset interrupt flag and get INT_STATUS byte
mpuInterrupt = false;
mpuIntStatus = mpu.getIntStatus();
// get current FIFO count
fifoCount = mpu.getFIFOCount();
// check for overflow (this should never happen unless our code is too
inefficient)
if ((mpuIntStatus & 0x10) || fifoCount == 1024) {
// reset so we can continue cleanly
mpu.resetFIFO();
Serial.println(F("FIFO overflow!"));
// otherwise, check for DMP data ready interrupt (this should happen
frequently)
} else if (mpuIntStatus & 0x02) {
// wait for correct available data length, should be a VERY short
wait
while (fifoCount < packetSize) fifoCount = mpu.getFIFOCount();
// read a packet from FIFO
mpu.getFIFOBytes(fifoBuffer, packetSize);
// track FIFO count here in case there is > 1 packet available
// (this lets us immediately read more without waiting for an
interrupt)
fifoCount -= packetSize;
49. 41
3.3.2 GPS coding by using library TinyGPS++
By using TinyGPS++ coding in the arduino software, the desired output result that can
expected are GPS date, GPS time, location(latitude,longitude), and also the altitude. The
coding of TinyGPS++ used is :
#include <TinyGPS++.h>
#include <SoftwareSerial.h>
/*
This sample code demonstrates the normal use of a TinyGPS++
(TinyGPSPlus) object.
*/
static const int RXPin = 4, TXPin = 3;
static const uint32_t GPSBaud = 9600;
// The TinyGPS++ object
TinyGPSPlus gps;
// The serial connection to the GPS device
SoftwareSerial ss(RXPin, TXPin);
void setup()
{
Serial.begin(9600);
ss.begin(GPSBaud);
Serial.println(F("FullExample.ino"));
Serial.println(F("An extensive example of many interesting TinyGPS++
features"));
Serial.print(F("Testing TinyGPS++ library v. "));
Serial.println(TinyGPSPlus::libraryVersion());
Serial.println(F("by Mikal Hart"));
Serial.println();
Serial.println(F("Sats HDOP Latitude Longitude Fix Date Time
Date Alt Course Speed Card Distance Course Card Chars Sentences
Checksum"));
Serial.println(F(" (deg) (deg) Age
Age (m) --- from GPS ---- ---- to KICT ---- RX RX Fail"));
Serial.println(F("-------------------------------------------------------
---------------------------------------------------------------------------
-----"));
}
void loop()
{
static const double KICT_LAT = 3.253779, KICT_LON = 101.729336;
printInt(gps.satellites.value(), gps.satellites.isValid(), 5);
printInt(gps.hdop.value(), gps.hdop.isValid(), 5);
printFloat(gps.location.lat(), gps.location.isValid(), 11, 6);
printFloat(gps.location.lng(), gps.location.isValid(), 12, 6);
printInt(gps.location.age(), gps.location.isValid(), 5);
printDateTime(gps.date, gps.time);
printFloat(gps.altitude.meters(), gps.altitude.isValid(), 7, 2);
50. 42
printFloat(gps.course.deg(), gps.course.isValid(), 7, 2);
printFloat(gps.speed.kmph(), gps.speed.isValid(), 6, 2);
printStr(gps.course.isValid() ? TinyGPSPlus::cardinal(gps.course.value())
: "*** ", 6);
unsigned long distanceKmToKICT =
(unsigned long)TinyGPSPlus::distanceBetween(
gps.location.lat(),
gps.location.lng(),
KICT_LAT,
KICT_LON) / 1000;
printInt(distanceKmToKICT, gps.location.isValid(), 9);
double courseToKICT =
TinyGPSPlus::courseTo(
gps.location.lat(),
gps.location.lng(),
KICT_LAT,
KICT_LON);
printFloat(courseToKICT, gps.location.isValid(), 7, 2);
const char *cardinalToKICT = TinyGPSPlus::cardinal(courseToKICT);
printStr(gps.location.isValid() ? cardinalToKICT : "*** ", 6);
printInt(gps.charsProcessed(), true, 6);
printInt(gps.sentencesWithFix(), true, 10);
printInt(gps.failedChecksum(), true, 9);
Serial.println();
smartDelay(1000);
if (millis() > 5000 && gps.charsProcessed() < 10)
Serial.println(F("No GPS data received: check wiring"));
}
// This custom version of delay() ensures that the gps object
// is being "fed".
void smartDelay(unsigned long ms)
{
unsigned long start = millis();
do
{
while (ss.available())
gps.encode(ss.read());
} while (millis() - start < ms);
}
void printFloat(float val, bool valid, int len, int prec)
{
if (!valid)
{
while (len-- > 1)
Serial.print('*');
Serial.print(' ');
}
else
{
51. 43
Serial.print(val, prec);
int vi = abs((int)val);
int flen = prec + (val < 0.0 ? 2 : 1); // . and -
flen += vi >= 1000 ? 4 : vi >= 100 ? 3 : vi >= 10 ? 2 : 1;
for (int i=flen; i<len; ++i)
Serial.print(' ');
}
smartDelay(0);
}
void printInt(unsigned long val, bool valid, int len)
{
char sz[32] = "*****************";
if (valid)
sprintf(sz, "%ld", val);
sz[len] = 0;
for (int i=strlen(sz); i<len; ++i)
sz[i] = ' ';
if (len > 0)
sz[len-1] = ' ';
Serial.print(sz);
smartDelay(0);
}
void printDateTime(TinyGPSDate &d, TinyGPSTime &t)
{
if (!d.isValid())
{
Serial.print(F("********** "));
}
else
{
char sz[32];
sprintf(sz, "%02d/%02d/%02d ", d.month(), d.day(), d.year());
Serial.print(sz);
}
if (!t.isValid())
{
Serial.print(F("******** "));
}
else
{
char sz[32];
sprintf(sz, "%02d:%02d:%02d ", t.hour(), t.minute(), t.second());
Serial.print(sz);
}
printInt(d.age(), d.isValid(), 5);
smartDelay(0);
}
void printStr(const char *str, int len)
{
int slen = strlen(str);
for (int i=0; i<len; ++i)
Serial.print(i<slen ? str[i] : ' ');
smartDelay(0);
}
52. 44
3.3.3 The combine coding of the GPS and the IMU-MPU-6050
Hence,the results that to be expect are the GPS date, GPS time, latitude(deg),
longitude(deg), altitude(m), acceleration(deg) in x,y,z and yaw(deg),pitch(deg) and roll(deg).
The combine coding of the GPS and IMU-MPU-6050 is by using the Serial Event{} so that
the XBee can be configured and compability to transmit this data in the Arduino pins.
char receivevalue[40] = "";
bool GPSavailable = false;
int rcvsize = 0;
#include <TinyGPS++.h>
#include <SoftwareSerial.h>
static const uint32_t GPSBaud = 9600;
static const uint32_t XBEEBaud = 9600;
// The serial connection to the GPS device
byte RXPin=4;
byte TXPin=3;
SoftwareSerial myXBEE(RXPin, TXPin);
// The TinyGPS++ object
TinyGPSPlus gps;
////////////////////////////////////IMU
INIT//////////////////////////////////
//Title: Mechanical Depth and IMU MPU6050 sensor reading
//
//Original Source:
//I2C device class (I2Cdev) demonstration Arduino sketch for MPU6050 class
using DMP (MotionApps v2.0)
// 6/21/2012 by Jeff Rowberg <jeff@rowberg.net>
// Updates should (hopefully) always be available at
https://github.com/jrowberg/i2cdevlib
//
/* ============================================
I2Cdev device library code is placed under the MIT license
Copyright (c) 2012 Jeff Rowberg
===============================================
*/
#include <String.h>
// I2Cdev and MPU6050 must be installed as libraries, or else the .cpp/.h
files
53. 45
// for both classes must be in the include path of your project
#include "I2Cdev.h"
#include "MPU6050_6Axis_MotionApps20.h"
//#include "MPU6050.h" // not necessary if using MotionApps include file
// Arduino Wire library is required if I2Cdev I2CDEV_ARDUINO_WIRE
implementation
// is used in I2Cdev.h
#if I2CDEV_IMPLEMENTATION == I2CDEV_ARDUINO_WIRE
#include "Wire.h"
#endif
// class default I2C address is 0x68
// specific I2C addresses may be passed as a parameter here
// AD0 low = 0x68 (default for SparkFun breakout and InvenSense evaluation
board)
// AD0 high = 0x69
MPU6050 mpu;
//MPU6050 mpu(0x69); // <-- use for AD0 high
/*
=========================================================================
NOTE: In addition to connection 3.3v, GND, SDA, and SCL, this sketch
depends on the MPU-6050's INT pin being connected to the Arduino's
external interrupt #0 pin. On the Arduino Uno and Mega 2560, this is
digital I/O pin 2.
*
=========================================================================
*/
/*
=========================================================================
NOTE: Arduino v1.0.1 with the Leonardo board generates a compile error
when using Serial.write(buf, len). The Teapot output uses this method.
The solution requires a modification to the Arduino USBAPI.h file, which
is fortunately simple, but annoying. This will be fixed in the next IDE
release. For more info, see these links:
http://arduino.cc/forum/index.php/topic,109987.0.html
http://code.google.com/p/arduino/issues/detail?id=958
*
=========================================================================
*/
// uncomment "OUTPUT_READABLE_YAWPITCHROLL" if you want to see the yaw/
// pitch/roll angles (in degrees) calculated from the quaternions coming
// from the FIFO. Note this also requires gravity vector calculations.
// Also note that yaw/pitch/roll angles suffer from gimbal lock (for
// more info, see: http://en.wikipedia.org/wiki/Gimbal_lock)
#define OUTPUT_READABLE_YAWPITCHROLL
// uncomment "OUTPUT_READABLE_REALACCEL" if you want to see acceleration
// components with gravity removed. This acceleration reference frame is
// not compensated for orientation, so +X is always +X according to the
// sensor, just without the effects of gravity. If you want acceleration
// compensated for orientation, us OUTPUT_READABLE_WORLDACCEL instead.
54. 46
#define OUTPUT_READABLE_REALACCEL
#define LED_PIN 13 // (Arduino is 13, Teensy is 11, Teensy++ is 6)
bool blinkState = false;
// MPU control/status vars
bool dmpReady = false; // set true if DMP init was successful
uint8_t mpuIntStatus; // holds actual interrupt status byte from MPU
uint8_t devStatus; // return status after each device operation (0 =
success, !0 = error)
uint16_t packetSize; // expected DMP packet size (default is 42 bytes)
uint16_t fifoCount; // count of all bytes currently in FIFO
uint8_t fifoBuffer[64]; // FIFO storage buffer
// orientation/motion vars
Quaternion q; // [w, x, y, z] quaternion container
VectorInt16 aa; // [x, y, z] accel sensor measurements
VectorInt16 aaReal; // [x, y, z] gravity-free accel sensor
measurements
VectorInt16 aaWorld; // [x, y, z] world-frame accel sensor
measurements
VectorFloat gravity; // [x, y, z] gravity vector
float euler[3]; // [psi, theta, phi] Euler angle container
float ypr[3]; // [yaw, pitch, roll] yaw/pitch/roll container
and gravity vector
// packet structure for InvenSense teapot demo
uint8_t teapotPacket[14] = { '$', 0x02, 0,0, 0,0, 0,0, 0,0, 0x00, 0x00,
'r', 'n' };
//================================================================
//Varialble For Mechanical Depth Sensor
//================================================================
#define RAW_MIN 50
#define RAW_MAX 387
char check = 0;
int sensorPin = A0; // select the input pin for the potentiometer
float sensorValue = 0; // variable to store the value coming from the
sensor
float Degree;
float rodLength=0.9; // 1 meter
float offset=0.09;
float rad;
float Depth;
float D;
long tt=0;
float roll,pitch;
// ================================================================
// === INTERRUPT DETECTION ROUTINE ===
// ================================================================
55. 47
volatile bool mpuInterrupt = false; // indicates whether MPU interrupt
pin has gone high
void dmpDataReady() {
mpuInterrupt = true;
}
void setup() {
Serial.begin(GPSBaud);
myXBEE.begin(XBEEBaud);
// join I2C bus (I2Cdev library doesn't do this automatically)
#if I2CDEV_IMPLEMENTATION == I2CDEV_ARDUINO_WIRE
Wire.begin();
TWBR = 24; // 400kHz I2C clock (200kHz if CPU is 8MHz)
#elif I2CDEV_IMPLEMENTATION == I2CDEV_BUILTIN_FASTWIRE
Fastwire::setup(400, true);
#endif
// initialize serial communication
// (115200 chosen because it is required for Teapot Demo output, but
it's
// really up to you depending on your project)
while (!Serial); // wait for Leonardo enumeration, others continue
immediately
// NOTE: 8MHz or slower host processors, like the Teensy @ 3.3v or
Ardunio
// Pro Mini running at 3.3v, cannot handle this baud rate reliably due
to
// the baud timing being too misaligned with processor ticks. You must
use
// 38400 or slower in these cases, or use some kind of external
separate
// crystal solution for the UART timer.
// initialize device
Serial.println(F("Initializing I2C devices..."));
mpu.initialize();
// verify connection
Serial.println(F("Testing device connections..."));
Serial.println(mpu.testConnection() ? F("MPU6050 connection
successful") : F("MPU6050 connection failed"));
// wait for ready
Serial.println(F("nSend any character to begin DMP programming and
demo: "));
//while (Serial.available() && Serial.read()); // empty buffer
// while (!Serial.available()); // wait for data
// while (Serial.available() && Serial.read()); // empty buffer again
// load and configure the DMP
Serial.println(F("Initializing DMP..."));
devStatus = mpu.dmpInitialize();
// supply your own gyro offsets here, scaled for min sensitivity
56. 48
mpu.setXGyroOffset(220);
mpu.setYGyroOffset(76);
mpu.setZGyroOffset(-85);
mpu.setZAccelOffset(1788); // 1688 factory default for my test chip
// make sure it worked (returns 0 if so)
if (devStatus == 0) {
// turn on the DMP, now that it's ready
Serial.println(F("Enabling DMP..."));
mpu.setDMPEnabled(true);
// enable Arduino interrupt detection
Serial.println(F("Enabling interrupt detection (Arduino external
interrupt 0)..."));
attachInterrupt(0, dmpDataReady, RISING);
mpuIntStatus = mpu.getIntStatus();
// set our DMP Ready flag so the main loop() function knows it's
okay to use it
Serial.println(F("DMP ready! Waiting for first interrupt..."));
dmpReady = true;
// get expected DMP packet size for later comparison
packetSize = mpu.dmpGetFIFOPacketSize();
} else {
// ERROR!
// 1 = initial memory load failed
// 2 = DMP configuration updates failed
// (if it's going to break, usually the code will be 1)
Serial.print(F("DMP Initialization failed (code "));
Serial.print(devStatus);
Serial.println(F(")"));
}
// configure LED for output
pinMode(LED_PIN, OUTPUT);
}
void loop()
{
callIMU();
if(GPSavailable)
{
// Serial3.write(receivevalue, rcvsize);
// receivevalue ="";
callGPS();
printIMU();
GPSavailable = false;
}
}
void serialEvent()
{
int rcvsize = Serial.readBytes(receivevalue,40);
GPSavailable = true;
}
60. 52
void callIMU(){
// if programming failed, don't try to do anything
if (!dmpReady) return;
// wait for MPU interrupt or extra packet(s) available
// while (!mpuInterrupt && fifoCount < packetSize) {
// other program behavior stuff here
// .
// .
// .
// if you are really paranoid you can frequently test in between
other
// stuff to see if mpuInterrupt is true, and if so, "break;" from
the
// while() loop to immediately process the MPU data
// .
// .
// .
// }
// reset interrupt flag and get INT_STATUS byte
mpuInterrupt = false;
mpuIntStatus = mpu.getIntStatus();
// get current FIFO count
fifoCount = mpu.getFIFOCount();
// check for overflow (this should never happen unless our code is too
inefficient)
if ((mpuIntStatus & 0x10) || fifoCount == 1024) {
// reset so we can continue cleanly
mpu.resetFIFO();
// Serial.println(F("FIFO overflow!"));
// otherwise, check for DMP data ready interrupt (this should happen
frequently)
} else if (mpuIntStatus & 0x02) {
// wait for correct available data length, should be a VERY short
wait
while (fifoCount < packetSize) fifoCount = mpu.getFIFOCount();
// read a packet from FIFO
mpu.getFIFOBytes(fifoBuffer, packetSize);
// track FIFO count here in case there is > 1 packet available
// (this lets us immediately read more without waiting for an
interrupt)
fifoCount -= packetSize;
#ifdef OUTPUT_READABLE_QUATERNION
// display quaternion values in easy matrix form: w x y z
mpu.dmpGetQuaternion(&q, fifoBuffer);
Serial.print("quatt");
Serial.print(q.w);
Serial.print("t");
Serial.print(q.x);
Serial.print("t");
Serial.print(q.y);
Serial.print("t");
Serial.println(q.z);
64. 56
3.4 The final experimental setup
Figure 20 : The final setup of the in flight system product.
Figure 21 : The final inflight system with external power source.
65. 57
Figure 22 Quadcopter that used to test the inflight system NAZA type
Figure 23 : The inflight test of the quadcopter
66. 58
Figure 24 : Connection between the inflight system and ground detected
Figure 25 : The XBee from ground and XBee in flight conncected
67. 59
3.5 The flow chart of the data collected processing
Arduino Run Configure coding
IMU_TinyGPS++
Start
Valid Data
GPS :
Time,Date,Latitude,Longitude,Altitude
IMU : Accelertaion x,y,z and
yaw,pitch,roll
XBee accep the data and
transmit to the ground
XBee(receiver) receive the data
in the ground and give the
output within the range
End
No
Yes
68. 60
3.6 Price Estimation of Design Product
Table 6: Bill Estimation of Design Product
No Parts Quantity Price(RM)
1 Cytron-UNO 1 63.00
2 MPU-6050 sensor 2 45.00
3 GPS Ublox Neo 6M 1 190.00
4 XBee 1mW Series 1
with antenna
2 223.00
5. Male to Femal Jumper
Wire
3 set(40lines) 18.00
6. Bread Board 1 6.00
7. USB cable 1 available
8. Lipo 11.1Volt Battery 1 48.00
Total RM 593.00
69. 61
Chapter 4 : Results and Presentation Data
The desired results that get were from the simulation and experiment that conducted in
the KICT Building of International Islamic University of Malaysia as the coordinate
landmark position with the latitude of 3.253779 and the longitude of 101.729336 .
4.1 The quadcopter filght test
After running the first flight test, it is noticed that the data cannot be transmitted from
the inflight to the ground and the problem is identified during the second test of the flight. The
XBee cannot perform effectively during the flight test that will be discussed later in
discussion.
4.2 The manual way getting results
Hence, the manual way of getting results is performed to get a good and effective
results. The inflight system performed by carried away the system by walking and holding the
system manually and kept the distance from the ground.
The results varied as it takes five differerences distance(in metres) from the initial
setup of the in flight data system and ground. The distances that varied from ground are
5m,10m,15m,20m and 30m. The results that get can be seen in the Table 7, Table 8, Table 9,
Table 10, and Table 11.
70. 62
4.3 Output from the initial setup using the arduino software
Figure 26 : In flight initial setup and output that come out from the arduino software after the
configuration
71. 63
The initial data results of the real time transmitting the system (5m from the ground) are :
GPSDate : 8/17/2016
GPSTime : 5:50:02
Latitude(deg) : 3.247756
Longitude(deg) : 101.7385
Altitude(m): 61
Xacel(deg): -339
Yacel(deg): -180
Zacel(deg): 2195
yaw(deg): 41.35
pitch(deg): -4.56
roll(deg): -4.61
80. 72
Table 11 : GPS and IMU data taken for 25m distance from the ground
GPSDate GPSTime Lat(deg) Long(deg) Alti(m) Xacel(deg) Yacel(deg) Zacel(deg) yaw(deg) pitch(deg) roll(deg)
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
81. 73
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
* * * * * 0 0 0 180 nan nan
82. 74
Chapter 5 :Discussion and Conclusion
5.1 Discussion
As can be seen from the results, during the first flight simulation using the
quadcopter,the data transmitted is loss due to the connection of XBee that cannot transmitted
and connected clearly the data to the ground even after the takeoff of the quadcopter. This is
due to the XBee 1mW series 1 configuration that after a few manually flight test, it can be
configured that this XBee in this simulation can connected up until 20 meters only. Although
in the specification mentioned that it can transmitted and connected until 100 meter(outdoor
and within the line of sight), it can still cannot be identified the real problem of the XBee
range communication. However, when the in flight system simulate manually by holding the
system to distance of 5m ,10m and 15m the data can transmitted and work efficiently.
The data transmitted start to lost bit by bit when the distance of the flight system to the
ground is 20m and fully cannot connected when the distance achieved 25meter. It started by
the lost of the acceleration data in x,y,z and yaw ,pitch and roll angle before the GPS cannot
be transmitted fully and then cannot transmitted and connected with the XBee when the
distance is 25m as shown in the Table 11.
5.1.1 Achievement of Objectives
From the experiment and flight test that had been conducted, it can be said that the
objectives of this research paper had achieved successfully. The goals of this project are
mostly succeed as it have achieved all of the objective of this Final Year Project which are to
develop a system that will be able to collect data during in-flight using sensors attached in
83. 75
microcontroller board, to transmit the data generated in the microcontroller during in flight to
the ground receiver and to receive the real time data at the ground system. However, the data
that was collected are not accurate enough and needs to be calibrated to get more accurate and
precise reading.
Besides, various article and idea that we have been determine and we found only few
article and source that we can really compare and use it for our reference. Although there are
some difficulties and error that we make during the research and test, Alhamdulillah, Dr. Ari
Legowo always gives his advices and support to us.
5.1.2 Limitations and Recommendation
There are limitations and challenges that encountered along the project is
conducted. Firstly, process selection of components. Similar to what it had been
mention before, the component selection needs to be planned well to give a good
results and achieved the objectives. Other than that, data collection from MPU-6050
sensors should be calibrated to get more accurate data, thus the small aircraft
(quadrotor) flight with precise measurement and stable. We strongly advise that
further research needs to be carried out to calibrate the system so that it will be able to
get more accurate data. As for the transmitter and receiver, we suggest that in future it
has to be change or upgrade into the pro version for the system have more widen
communication range and will be able to transmit the data during in-flight to ground
without any problem at all.
84. 76
5.2 Conclusion
In conclusion, it can be said that for this Final Year Project 2, the goals of this project
are mostly succeed as it have achieved all of the objective of this Final Year Project which are
to develop a system that will be able to collect data during in-flight using sensors attached in
microcontroller board, to transmit the data generated in the microcontroller during in flight to
the ground receiver and to receive the real time data at the ground system. However, the data
that was collected are not accurate enough and needs to be calibrated to get more accurate and
precise reading.
85. 77
References
A, E., Stephenson, & Suquamish. (1984). Aircraft Flight Data Recorder Data Acquisition System.
United States: A New All Purpose Digital Flight Data Recorder.
Ahmad, N., & R. A. (2013). Reviews on Various Inertial Measurement Unit (IMU) Sensor Applications .
Kuala Lumpur: International Journal of Signal Processing Systems Vol. 1, No. 2 December
2013,Center of Product Design and Manufacturing, Dept. Of Mech. Eng., University of
Malaya.
D.Hazry, M.Sofian, & A. A. (2009). Study of Inertial Measurement Unit Sensor . Batu Ferringhi,
Penang, MALAYSIA: Proceedings of the International Conference on Man-Machine Systems
(ICoMMS),11 – 13 October 2009.
D.Miller, Jr., & Redmond. (1988). Aircraft Data Acquisition And Recording System. United States: An
Intermediate Solution between Basic and Expanded A.I.D.S.
Farley, R. J. (2002). Aircraft data transmission system for wireless communication of data between
the aircraft and ground-based systems.
Gerald, N. H. (1947). Aircraft Altitude Control.
Gouping, W. (2010). The Application Studies of Embedded System Development Platforms.
John.F.Grabowsky, & David.R.Stevens. (2001). Aircraft Flight Data Acquisition And Transmission
System. Los Angeles, CA(US): Teledyne Technologies Inc.
Juang, H.-S., & K.-Y. L. (2013). Design and Control of a Two-Wheel Self-Balancing Robot using the.
China: 2013 10th IEEE International Conference on Control and Automation (ICCA),Hangzhou,
China, June 12-14, 2013.
86. 78
M Maksimović, V Vujović, N Davidović, & Milošević, V. (2014). Raspberry Pi as a Wireless Sensor
node: Performances and constraints. Bosnia-Herzegovina: Information and Communication
Technology, Electronics and Microelectronics (MIPRO), 2014 37th International Convention
on,IEEE.
Magnussen, O., & M. O. (2013). Experimental validation of a quaternion-based attitude estimation
with direct input to a quadcopter control system. Atlanta: 2013 International Conference on
Unmanned Aircraft Systems (ICUAS),May 28-31, 2013, Grand Hyatt Atlanta, Atlanta, GA.
Mollmann, D. E. (2005). Accelerometer configuration .
Post, E., & N. G. (2013). Inertial Measurement Unit. United States: Massachusetts Institute Of
Technology.
Russel, L., Steele, A., & Gooubran, R. (2012). Low-cost, rapid prototyping of IMU and pressure
monitoring system using an open source hardware design. Canada: Instrumentation and
Measurement Technology Conference (I2MTC), 2012 IEEE International,2695 - 2699,13-16
May 2012,Graz.
Samarathunga, & Wanniarachi,. (2015). Wireless Gesture Control Vehicle. Sri Lanka: Proceedings of
the Research Symposium of Uva Wellasa University.
Sanderson, W. (2000). Communication system for providing broadband data services using a high-
voltage cable of a power system. United States.
Shu-hu, W., Shiju, & L. H.-g. (2013). Design of Simulating System of Gyroscope for Training Based on
Arduino. China: The Second Artillery Engineering University,Xi’an 710025,P.R.China.
Skog, I., & P. H. (2006). Calibration of MEMS Inertial Measurement Unit. Rio de Janeiro, Brazil: XVII
IMEKO WORLD CONGRESS, Metrology for a Sustainable Development,September, 17–22,
2006.
