465 senior lab final report

American Institute of Aeronautics and Astronautics
1
CASA IMU Report
Fugett, Daniel and Kraft, Brian
California Polytechnic State University, San Luis Obispo, California, 93405
A project was given by CASA to design and test an Inertial Measurement Unit that can be
used for a low-cost UAV. Given to this project were a Sparkfun IMU containing both an
accelerometer and a gyroscope, and an Arduino Uno microcontroller. The objectives of this
project were to read the IMU sensor values into an Arduino IDE, calibrate the sensors for the
gravity bias, low pass filter the measurements to remove noise, and propagate the measured
values to find position, velocity, and attitude of the IMU. A software plan was created that
would complete those objectives. Upon first implementation of the software, the values
returned were too inaccurate, so further work was done to refine the software. Eventually the
software was accurate enough to be able to predict the position of the IMU to within 3 degrees
of the actual attitude of the Arduino. The future steps to this project would be implementing
a Kahlman filter or some other more refined filter. Additionally sensor blending would likely
improve the results that were obtained. Overall the data that was obtained was relatively
accurate for the instrumentation and the time period provided.
Nomenclature
ACL_CON = conversion factor to natural units for accelerometer “Convert_Threshold”
alpha1 = smoothing factor Exponential Smoothing
avg_iter = number of samples in the average “Lowpass_Mechanical”
cnt = counting variable “Lowpass_Mechanical”
GYRO_CON = conversion factor to natural units for gyroscope “Convert_Threshold”
here_x = most recent measured sample (LSB) “Lowpass_Mechanical”
i = counting variable “Measure_from”
Measure = structure containing the measured value from previous (LSB) “Convert_Threshold”
MyValues = structure holding calibrated and converted data (m/sec2) “Convert_Threshold”
Offset = structure containing the offset value as measured before (LSB) “Convert_Threshold”
some_Values = structure containing averaged value (LSB) “Lowpass_Mechanical”
t_step = time since previous integration (sec) Kinematic Equations
t_Values = structure type, applies to all mentioned structures “IMU.h”
values = array holding sensorregister data, “Measure_from”
xacc = array holding acceleration from current and previous time
(m/sec2)
Kinematic Equations
xpos = array holding position from current and previous timestep (m) Kinematic Equations
xvel = array holding velocity from current and previous timestep
(m/sec)
Kinematic Equations
I. Introduction
Inertial Measurement Units (IMUs) are commonly used to assist in guidance and navigation of aerospace vehicles.
Two of the common sensors used in IMUs are accelerometers and gyroscopes.An accelerometermeasures the absolute
acceleration of the vehicle with respect to the inertial frame of reference. This can be integrated overtime to determine
the velocity and position of the vehicle. Gyroscopes measure the vehicle’s angular velocity, which can then be
integrated over time to determine the vehicle’s attitude. This project will design and test a simple IMU

2
1 Undergraduate, Aerospace Engineering, 1 Grand Ave., AIAA member.
1 Undergraduate, Aerospace Engineering, 1 Grand Ave., AIAA member
to be used on a new low-cost UAV. The IMU will be capable of three axis measurements; however gravity bias and
sensor noise will need to be accounted for in order to make the measurements accurate.
The IMU will need to be controlled by some sort of processorto be useful. In this case, the IMU will be connected
to a microcontroller that will feed the IMU commands while receiving data. There are many different families of
microcontrollers, but in this project an Arduino Uno will be used. Arduino is part of a family of microcontrollers that
has been developed in an open-source environment. The programming platform used for the Arduino will be the
Arduino Integrated Development Environment (IDE). This IDE uses a language similar to C, and is capable of
communicating to the IMU using a protocol called I2C. Detailed knowledge of this protocol is not necessary for this
project, as Arduino features a host of internal libraries that can take of it.
The objectives of this project are to:
1) Connect the IMU given to Arduino that has been installed on a computer
2) Display on the computer screen simple and unfiltered data from the sensors on the IMU.
3) Calibrate the sensors for gravity bias and low pass filter the measurement noise.
4) Propagate the velocity, position, and attitude of the IMU over time.
5) Develop a library that communicates with the IMU using singular function calls.
6) Become familiar with both the Arduino and the IMU.
At the end of this project, there should be an IMU and Arduino setup that outputs accurate position and attitude
measurements, which can be tested by moving the IMU around on the table.
II. Apparatus and Procedure
To complete our objectives, a Sparkfun SEN-10121 was used for our IMU. This breakout board includes the
ADXL345 accelerometer and the ITG-3200 gyroscope. This allows the lab setup to feature only one interface between
the Arduino and the two IMU sensors. An Arduino Uno microcontroller with a serial cable to connect to a computer
was also included. Lastly, 4 small breadboard cables and a breadboard were used to connect the IMU to the Arduino
Uno board. These components were all connected in the following way

3
Figure 1. Circuit Schematic
In the above schematic, the Arduino Uno is connected to a computer via a USB cable. The 3.3V port on the
Arduino is connected to the 3.3V port on the IMU. Similarly, the ground port on the Arduino is connected to the
ground port on the IMU. The SDA port on the IMU was connected to the A4 pin, and the SCL port on the IMU was
connected to the A5 pin.
Next, the Arduino IDE was downloaded and installed on the working computer. With that setup, the software
development was ready to begin. The following steps were taken in the development of the software.
Step 1: Read simple and unfiltered data from the sensors to the computer screen. This was done to ensure that the
I2C functions were implemented correctly, and that the accelerometer and the gyroscope were in working condition.
To do this, the proper registers for each sensor were referenced from the sensor register maps. To turn on the
accelerometer, the command 0 was given to register 0x2D- Power Control. This wakes up the accelerometer and puts
it into standby mode. Next the command of 8 was given to the power register, turning the accelerometer into
measurement mode. To turn on the gyroscope, the command of 0 was given to register 62- Power Control. Then a
command of 24 was given to register 22. This sets the gyroscope to the proper orientation. Next, the measured values
were read from registers 0x32 to 0x37 from the accelerometer and from registers 29 to 34 from the gyroscope.These
measured values were then printed to the serial monitor from the Arduino.
3.3V
GND
SDA
SCL
INT1
INT0
IMU

4
Step 2: Implement a function library that can be used for all further commands. This was done to clean up the
code. For example, the commands to turn on both sensors were reduced to a simple function call, taking up only a
couple lines of code. To do this, 2 functions were written, one that feeds a given register a command, and one that
measures values from the sensors.The functions were created such that they could be used for both the accelerometer
and the gyroscope.The functions were written into a .cpp file, and a proper header file was created as well. These files
were then implemented into the Arduino libraries using the import libraries tool. The library was called IMU, so a
#include “IMU.h” line was written into the script. All future created functions were written into this library as well.
Step 3: Calibrate the accelerometer and the gyroscope for sensorbias. This is done to ensure that the sensors read
data that make sense.For example, while the IMU is at rest, the accelerometer and the gyroscope should read 0 in all
directions; which the raw data does not show. To do this, the algorithms in reference AN3397 [1] were followed. A
new function was created that could take many measurement samples and average them, producing a calibrated valu e
to be used for the offset. The values from this function were called the offset variables. For all future measurements,
the offset variables were subtracted fromthe most recently measured variables to form the used variable.
Step 4: Convert the used variable from voltage output to physical units. When the IMU outputs data, it gives a
serial voltage reading based on the sensitivity of the sensor. But for the accelerometer, the preferred acceleration units
are m/s2, and for the gyroscope, the preferred measurement unit is deg/sec. To do this, the resolution units of the
different sensors were looked up. For the accelerometer, the resolution was 4 mg/LSB [2]. So the measured variables
were all multiplied by .004 to convert them to g’s, and multiplied again by 9.81 to convert them into units of m/sec2.
For the gyroscope, the resolution is 14.375 LSB/ o/sec [3]. So the measured variables were all divided by 14.375 to
convert their values into o/sec. These conversion were implemented inside another function inside the IMU library.
Step 5: Implement a low pass filter. This is needed because the sensor’s data is noisy, so to produce accurate
position and attitude values the noise needs to be removed. To implement a low pass filter, reference AN23397 [1]
was used again. Both the “Filtering” and the “Mechanical Filtering Window” algorithms were used. This means all
measured values had to be an average of a larger amount of samples taken. Because a measurement average was
already implemented in a function in Step 3, this filtering just needed a proper calibration to determine how many
samples to take per measurement value. For the mechanical filtering window algorithm, the measured values are just
compared to a certain threshold value. If the measured values fall beneath the threshold then the values are set to 0
instead. This ensures that a “no movement condition” can be met.
Step 6: Integrate the measured values from the IMU to determine velocity, position,and attitude of the IMU. This
is done because those are the measurements that the UAV will use to navigate. To integrate, the kinematic equations
are used in conjunction with a designated time step.Further details about these equations are given in the next section.
The output of the kinematic equations, velocity, position, and attitude, are propagated with time such that the IMU
constantly outputs those values and changes themwith respect to the new measurements fromthe IMU.
III. Analysis
In order to power on the sensors and prepare them for measurement, a function “Write_to” was developed in the
IMU library. When fed a device address, register, and command, the function will simply write the respective
command. This function is called multiple times in the setup function in the Arduino, and by the end of the function
the IMU is fully prepared to start outputting values.
After powering on the sensors,the rawdata needs to be taken from the sensors (step 1).This is done with a function
in the IMU library called “Measure_from.” A sample of the code in this function is shown below.
int i = 0; (1)
while(Wire.available()){ (2)
values[i] = Wire.read(); (3)
i++; (4)
} (5)

5
In this code, i represents a counting variable. values is an array which holds the read value. So together,these
lines of code pull the 6 bytes of data needed for the three axis measurement from the sensor. In the next step in the
function, the 6 byte values in value are conjoined together to formthe measured data.
The measured data that is output from the “Measure_from” function takes the form of a structure. This structure
contains the data points forthe x, y, and z components from the sensor.To create this structure,a new type was defined
in the IMU library. This code can be found below:
typedef struct t_Values{ (6)
float x; (7)
float y; (8)
float z; (9)
} t_Values; (10)
So now all further structures used in functions are of type t_Values, meaning that all structures have an x,y,
and z component that is a float variable. This will allow the x,y, and z components from a sensorto all be output
from a function at once.
Occasionally, a large amount of samples are desired to be taken, and then averaged to produce the measured value.
For example, this needs to be done for the calibration offset variable (step 3), talked about more below. In order to
achieve this, the function “Lowpass_Mechanical” was developed in the IMU library. A portion of this code is shown
below.
while (cnt <= avg_iter){ (11)
here_x = Measure_from(….) (12)
some_Values.x = some_Values.x + here_x; (13)
cnt++ (14)
} (15)
some_Values.x = some_Values.x / avg_iter; (16)
In these lines, cnt is a count variable, meaning it starts at 0 and increases by one for every iteration. here_x is the
most recent measured sample. some_Values is a structure which will contain the average value, and this structure is
what will be returned from the function. And avg_iter is an input variable which tells the function how many samples
the average should contain.
Next, the sensordata needed to be calibrated for the gravity bias (step 3) and converted into natural units (step 4).
To calibrate for the gravity bias, the offset variable that was recorded prior is subtracted from the recently measured
value. To convert the value into natural units,a simple multiplication by a conversion factoris needed. These are both
accomplished in the following line of code, given in the x direction for the accelerometer only. This code can be found
in the “Convert_Threshold” function inside the IMU library.
MyValues.x = (Measure.x - Offset.x)*ACL_CON; (17)
In those lines, MyValues (m/sec2 or deg/sec)is a structure which holds the calibrated and converted sensorvalue.
Measure (LSB) is a structure which holds the most recently measured sensorvalue. Offset (LSB) is a structure which
holds the sensorvalue for offset, which is measured in the beginning of the code. ACL_CON is the conversion factor
from voltage reading to m/s2, and is equal to 9.81/250. Because both sensors need an offset, a very similar line of code
can be used for the gyroscope,with a variable for GYRO_CON instead. GYRO_CON is equal to 1/14.375 to convert
the measurement into degrees/sec.
After being calibrated and offset,the measured variable needs to be passed through a low pass filter (Step 5). One
of the low pass filters implemented is a simple mechanical threshold. In order for the measured value to be passed on
to integration, it needs to be above a certain threshold value; otherwise the measured value becomes zero. To
accomplish this, there are more lines of code in the function “Convert_Threshold”
if ( abs(MyValues.x) <= thresh){ (18)

6
MyValues.x = 0;} (19)
In this code, the variable thresh (m/sec2 or deg/sec)is an input into the function, and represents the threshold value
that the user desires. If the threshold is set too high, then valid data points might be lost and the IMU could always
think that it is in the “no movement” condition even if it is moving. If the threshold is set too low, then noisy signals
from the filter could cause the sensors to read that the IMU is moving, even when it is at rest. The thought process
behind setting the threshold value is discussed in the next section.
To implement the second part of the low pass filter (step 5), a rolling average needs to be implemented. A function
was needed to take many samples from a sensor,and then output the average of those samples as the measured value.
However, this function was already developed in “Lowpass_Mechanical.” Therefore, in order to fulfill that step, the
:Lowpass_Mechanical” function needed to be implemented directed after the raw measurements are taken.
In order to integrate the measured acceleration and angular velocity, the kinematic equations were used. This code
was not put into the function library, instead it is just written into the main Arduino script. An example of the code
used for the x position and x angle is shown below.
xvel[1] = xvel[0] + xacc[1] * (t_step/1000); (20)
xpos[1] = xpos[0] + xvel[1] * (t_step/1000) + ((xacc[1] * (t_step/1000)^2; (21)
xang[1] = xang[0] + xavel[1] * (t_step/1000); (22)
xpos (m) is the array holding the position information for both the current and previous time step. xvel (m/s) is the
array holding the velocity in the x direction. xacc (m/s2) is the array holding the acceleration in the x direction, which
is measured from the IMU. Similarly for the gyroscope information, xang (deg) is the array which holds the total
rotation in the x direction, while xavel (deg/sec) contains the angular velocity in the x direction, which is measured
from the IMU. The variable t_step (ms) contains the time since the previous integration has happened. For all arrays
the second variable of the array is for the current time step,while the first element of the array is for the previous time
step.
Lastly in the IMU library, a function titled “Print_myvalues” was created. This function takes an x, y, and z value,
and prints them to the serial monitor in an easily comprehendable way. The values can be acceleration, velocity,
position, angular velocity, or attitude.
So in summary, the following steps were taken in orderto take data from the sensors
Table 1. Procedure with Functions
Step # Description of Step Functions in Library Used
1 Power on Sensors “Write_to”
1 Read raw data from sensors to ensure working condition “Measure_from”
3 Create Offset variable “Measure_from”; “Lowpass_Mechanical”
3 Read a set of measured data from sensors “Measure_from”
5 Implement a low pass filter using averaged values “Lowpass_Mechanical”
3 Offset the measured data with the offset variable “Convert_Threshold”
3 Convert the measured data into natural units “Convert_Threshold”
5 Implement a low pass filter for no movement condition “Convert_Threshold”
6 Integrate the measured values over time The Kinematic Equations
6 Print the Position and Attitude Values “Print_myvalues”
This is how the code was first developed and implemented. The following section details what changes the code
underwent after this first implementation.

7
IV. Results and Discussion
Pictures please! Show the results.Describe something unexpected or surprising to you. What did you learn? What
went right? What went wrong?
A. Exponential Filtering
One of the problems the code ran into was time lag. Often, a sudden move of the IMU would register in the
few measurements after, but not immediately. The reason forthis problem was discovered when the code was imported
to Matlab. To import into Matlab, the IMU code would be uploaded to the Arduino. Then the Matlab script would be
run that takes in the IMU data for a few seconds, then plots the data against time. Both the immediately measured
value and the averaged value from the low-pass filter would be graphed. An example of this filtering is included in
the results section for the angular velocity from the gyroscope.Keep in mind that this methodology was used for both
the angular velocity and the accelerations.
The value passed into the low pass filter using averages often lags behind the true value. This means that the
position and velocity readings will also lag behind the true values, such that they will still be readings movement even
after the IMU is put to rest. In order to fix this problem and obtain more accurate and real-time measurements, a new
low pass filter needed to be applied. The low pass filter chosen was an exponential smoothing filter. The equation for
exponential smoothing was implemented into the code in the following way:
xacc[1] = alpha1*Acc_Real.x + (1-alpha1)*Acc_prev.x; (23)
Where xacc[1] is the value of the most recent measured and filtered accelerometer reading. Acc_Real is a structure
holding the most recent sampled raw measurement for x acceleration. Acc_prev is a structure holding the previous
iteration’s filtered measurement value. And alpha1 is the smoothing factor. The value for the constant alpha1 was
chosen to best eliminate the noise from the signal while still accurately representing the raw data. The smoothing
factor value was eventually chosen as 0.1. A smoothing factor closer to zero places a higher weight on incoming
values while a value closer to one places higher weight on the previously measured values. Since we want our code
to be adaptive to quick changes in acceleration or angular velocity a value closer to zero was chosen. Multiple test
runs were conducted and this value proved to be the most effective for our application. The results of this filter and
the averaging filter, when passed into Matlab, can be seen in Figure 3 below.
Figure 2. Low Pass Filter with Exponential Smoothing and Averaging: In this picture the green line represents the raw
data, the black line represents the exponentially smoothed data and the red line represents the averaging filter.
By comparing these two lines, it can be seen that the exponential smoothing filter accurately follows the raw data
without having the lag of the averaging filter. Also the exponential smoothing seems to measure the values more
accurately. Overall this type of filtering proved to be easy and extremely beneficial for ourdata.An additional example
of this type of smoothing can be seen in the results section.
B. Movement End Check
Something that AN3397 [1] recommended implementing was a movement end check. This is similar to the
threshold check that was implemented beforehand. However, if the accelerometer were rapidly moved to a new
location, unless the integration of acceleration while it was positive perfectly matched the integration acceleration
while it was negative,then a small velocity would be left over. This is called “sloped positioning” and means that the

8
velocity will never reach zero. This might be desired in some cases, but because this IMU is connected to a static
computer, there should be no velocity left over after movement. Therefore the movement end check implemented
checks to see if the accelerometer starts to read similar values in the current iteration to the previous iteration, and if
it does, the velocity variable is set to zero. This will ensure that short movements of the accelerometer are tracked
more accurately, and that short movements don’t cause small velocities to be left over due to measurement errors.
And in the case of the UAV in flight, the acceleration of one time step should never be so close to the acceleration of
a previous time step, due to internal vibrations and external disturbances,so this condition could only be triggered on
the ground. The movement end check was implemented in the following way:
n4 = abs(abs(xacc[1]) - abs(xacc[0])); (24)
if (n4 < 5){ (25)
xacc[1] = 0;
c1++;
(26)
}
if (c1>3){
xvel[1]=0;
c1=0;}
(27)
(28)
(29)
In this case, xacc[1] (m/sec2), like before, means the most recent filtered measurement value. xacc[0] m/sec2
contains the previous iterations filtered measurement value. And xvel[1] (m/sec) contains the velocity for this
iteration. Therefore, if the difference between the two values is less than 5 the acceleration will be set to zero (which
serves as anothermechanical filter) and a counterwill increment. If the difference between the two values is less
than five for four consecutive passes then the velocity will be set to zero and the counter will start over again. This
ensures that only large changes in acceleration appear in the data and that the velocity and acceleration do not
continue to increase or decrease after movement has ceased.
C. Gravity Bias with Quaternions
Eliminating the gravity bias was a challenging task in this assignment. If the accelerometer remained flat on the
table for the duration of the experiment then it would be quite easy to set an offset and remove the effects of gravity.
Unfortunately this methodology breaks down if the accelerometer pitches or rolls during data collection. To prevent
this issue a quaternion was used to constantly update the attitude of the accelerometer relative to the inertial frame.
The first step in this process is determining the angle between the gravity vector in the inertial frame and the gravity
vector in the body frame.
c4 = -zacc[1]/ sqrt(xacc[1]*xacc[1] + yacc[1]*yacc[1] + zacc[1]*zacc[1]); (30)
ang = acos(c4)/2; (31)
In this code a dot product is performed and this value is then divided by the norm of both of the gravity vectors.
The dot product simplifies to –zacc[1] and the other values for the acceleration (yacc[1] and xacc[1]) are used to
calculate c4. C4 simply serves as a place holder and is implemented into an inverse cosine function and then divided
by two (since the angle used in quaternion math is always divided by two, this is merely a simplification of the code).
In order to obtain this value a cross product was performed and each component of this cross product was divided by
the magnitude of the cross product. These values combined with the angle can be used to find all four components of
the quaternion. From there, these values could easily be converted to a rotation matrix and the gravity vector could be
subtracted from the accelerations measured in the body frame. The code to calculate the quaternion and the rotation
is extremely tedious and was difficult to debug in Arduino. Since the Arduino does not understand complex matrix
this body of code is quite long and I suggest you view the header titled “// Quaternion Calculation” and “//Rotation
matrix calculation” in the appendix.
A check was performed to ensure the gravity vectordid not affect the acceleration readings when a roll or a pitch
was performed. Figure 3 and Figure 4 showthe checks to ensure the gravity bias is constantly removed from the data.
The red line depicts the acceleration with the gravity vectorremoved and the blue line represents the true accelerations
that are measured. Physically rotating the accelerometer induced some error in the sensorbut overall the quaternion
was extremely accurate.

9
Figure 3. Acceleration Calculations for Y-Axis Gravity Vector
Figure 4. Acceleration Calculations for X-Axis Gravity Vector
As the gravity vector becomes more prominent in otheraxes, the z-value starts to dips until it finally reaches zero.
When the Z-value is at zero this means that the gravity vector is present solely in other axes. The red line maintains a
constant value of zero therefore proving the functionality of the quaternion in our code.
D. Results
When all of the function in the Analysis were implemented and run, the code would generate position and attitude
measurements successfully. However, they were wildly inaccurate in the beginning. All ideas implemented in the
previous section were just to narrow down the accuracy of the measurements.

10
The basic idea of the code as described in the Analysis section worked and remained throughout the project. The
sensors were turned on without a hitch, and their raw values were read to ensure that they were in good working
condition. The IMU library was implemented with great success.The library cut down on the amount of code required
to be shown in one singular Arduino script, allowing the coding and debugging process to be quicker. The conversion
and threshold function worked well, with the only change to it being what the threshold value was set to 0.1 for both
the accelerometer and the gyroscope. And the kinematic equations remained unchanged.
As previously mentioned, lag proved to be an issue when determining the position and velocity through integration.
A check was performed for each axis to ensure that the accelerometer was outputting data accurately. The
displacement that were measured were slightly higher than the actual displacements that were implemented and this
is likely due to the amount of iterations required to enact the movement end check. A faster sampling of the data and
an alteration of the smoothing value might mitigate this issue.No delays were used in this code therefore speeding up
the iterations was not an option and therefore these results were the best that could be produced given the code and
the equipment that was used.
The first movement check that was performed was the X-axis movement and is shown below in Figure . Spurious
effects were measured in both the Y and the Z axes but this did not significantly contribute to the data that was
measured. These perturbations might not have been entirely erroneous considering it is difficult to slide an Arduino
across the table in purerly one axis. It is important to note that the Z-axis only changed by a small quantity and might
be more representative of the error that was produced by the code.
Figure 5. X-Axis Movement
The Y-axis check is depicted in Figure 6, shown below. The same trends that were discussed for the X-axis
movement could be applied to this graph. As previously mentioned, it is likely that the Arduino was also moved
some distance in the X-direction. The check for Z-axis movement is also shown below, please refer to Figure 7.

11
Figure 6. Y-Axis Movement
Figure 7. Z-Axis Movement
Examining the data it is obvious that the filter did not work as effectively as it once had. By implementing more
code for the quaternion and othernecessary calculations the number of iterations performed per second slowed down.
This produced error which produced a deformed shape for the integration. Although the different levels of integration
do look logical for some checks they are not perfect. Given more time this code could likely be rewritten to increase
the number of iterations that can be performed for a given time period
A similar check was performed for the angular velocity and angle calculations. The angular velocity data was
filtered and some of the subplots that will follow this paragraph feature the relationship between the filtered angular
velocity and the raw angular velocity.

12
Figure 8 shows the raw and filtered angular velocity used to calculate the angles. Figure 9 shows the angles that were
calculated through the data presented in Figure 8. Once more lag was an issue with the filtering of the data.These two
figures verify that a single angle can be measured without a large influence on the othertwo angles. The Arduino was
rotated 90 degrees about the X-axis which accurately correlates to the peak of the data at a value of about 1.57 radians.
Figure 8. Raw and Filtered Angular Velocity for X-Axis Check
Figure 9. Angles for X-Axis Check
Figure 10 and 11 correlate to a similar check for the Y-Axis. Once more the Arduino was rotated by 90 degrees
and the peak of the curve accurately corresponds to about 1.57 radians.

13
Figure 10. Raw and Filtered Angular Velocity for Y-Axis Check
Figure 11. Angles for Y-Axis Check
Figure 12 and 13 correlate to a similar check for the Z-Axis. Once more the Arduino was rotated by 90 degrees and
the peak of the curve accurately corresponds to about 1.57 radians.

14
Figure 12. Raw and Filtered Data for Z-Axis Check
Figure 13. Angles for Z-Axis Check
V. Conclusion
Overall the values that were determined proved to be relatively accurate. The angles that were calculated proved
to be the most accurate of all of the values that were integrated. This is likely due to the fact that these values only
underwent one level of integration whereas the position values required two integrations therefore compounding any
error that was present. Angles were measured within 3 degrees of their true values while the positions varied more
greatly. A quaternion was used to remove the gravity bias and this methodology proved effective throughout the code.
Initial offsets were also implemented to ensure they did not induce any transient effects. The exponential smoothing

15
filter provided to be effective for frequent iterations but started to breakdown as more complicated calculations slowed
down the code. A different filter or gravity bias algorithm might be more effective to reduce the amount of time that
the code takes to iterate. Furthermore a restructuring of the code to measure more values before attempting to filter
could also be viable, it is difficult to say without these numbers at hand. Despite all ourefforts lag was not completely
removed from the code and this induced transient effects on all of the measurements. A more refined code with
adaptive filtering based off of the magnitude of previous changes in data could be the best method for filtering this
data. As the values increase or decrease rapidly more data points could be used to ensure the data is represented
smoothly.
VI. References
[1] Seifert, Kurt, and Oscar Camacho. "AN3397: Implementing Positioning Algorithms Using Accelerometers."
02/2007; <http://cache.freescale.com/files/sensors/doc/app_note/AN3397.pdf>
[2] “ADXL345 2 Axis Digital Accelerometer Reference Sheet”; Sparkfun Electronics, Analog Devices Inc.
<https://www.sparkfun.com/datasheets/Sensors/Accelerometer/ADXL345.pdf>
[3] “ITG-3200 Product Specification, Revision 1.4” Sparkfun Electronics, InvenSense Inc.
<https://www.sparkfun.com/datasheets/Sensors/Gyro/PS-ITG-3200-00-01.4.pdf>
[4] “Inertial Measurement Unit – Lab Manual 2015-2” Department of Aerospace Engineering, California
Polytechnic State University, San Luis Obispo.

465 senior lab final report

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Similar to 465 senior lab final report

Similar to 465 senior lab final report (20)

465 senior lab final report