Download 1 - Purdue College of Engineering

AAE 450 (Div.2) Senior Design Report
Spring 2007
Project PurdueSat
Faculty Advisor: Prof. David L. Filmer
Team members:
Kautilya Vemulapalli
Mark James
Paul Moonjelly
Pinak Trivedi
Table of Contents
1. Introduction………………………………………………………. 2
2. Attitude Determination System………………………………….. 6
3. Attitude Control System………………………………………….. 16
4. Power System……………………………………………………... 47
5. Flight Computing System………………………………………… 50
6. Structures & Circuit Board Design……………………………… 62
7. Conclusion…………………………………………………………. 72
1
1. Introduction
Author: Paul Moonjelly, Project Engineer
1.1 Project Description
Project PurdueSat is an interdisciplinary project to design, build, and
launch Purdue University’s first satellite. The PurdueSat is classified as a nano-satellite
and is a double cube of approximately 10 cm x 10 cm x 20 cm sides with a 2 kg gross
mass. The satellite will conform to the CubeSat standard defined by California
Polytechnic State University and Stanford University (The CubeSat Standard was
designed to provide developers with necessary guidelines like outer dimensions,
recommended materials, restrictions etc. to interface with the P-POD – a standard
deployer which was developed to standardize the interface and bring down launch costs
to a minimum) . The satellite is primarily regarded as a platform for nano-satellite
technology development. The satellite will demonstrate a prototype attitude
determination and control scheme. Upon completion (projected for mid 2008), the
spacecraft will be launched aboard a Russian Dnepr or similar launch vehicle, in
conjunction with the Cal Poly/Stanford CubeSat program.
The senior design project intends to build on the design framework that has
evolved as a result of the interdisciplinary team effort that has been underway for 3 years.
The project should revamp the design and accelerate the PurdueSat development several
fold. The goal was to finish the design and development of the following subsystems –
the Attitude Determination System, the Attitude Control System, the Flight Computing
System, the Power System, and the Structural Design – by the end of the semester.
1.2 PurdueSat Mission
The primary emphasis of the PurdueSat Mission is to develop engineering
technology which can be useful for Purdue’s future CubeSat missions and the nanosatellite community in general (The emphasis was shifted from the science mission to its
2
engineering mission early in the semester). The engineering mission can be formally
stated as follows:
1. To perform “Attitude Determination” with 1 degree accuracy
2. To perform “Autonomous Attitude Control” with 5 degree accuracy
Thus the engineering objectives include testing a novel attitude determination system
suitable for nano-satellites and implementing an autonomous electromagnetic attitude
control system. Additionally, the Purdue CubeSat will test the suitability of a DSP
processor to nano-satellite applications.
The scientific mission of PurdueSat is to measure the radiation environment on
the satellite’s nearly polar, circular orbit. Radiation data will be collected, stored, and
transmitted to the ground station at Purdue.
The PurdueSat Senior Design Project also has an educational mission in that it
gives Purdue students a unique opportunity to gain hands-on experience with spaceflight
hardware. While the senior aircraft design course builds and tests a remotely-piloted
airplane, the senior spacecraft design course is a conceptual design – completed on paper
alone. PurdueSat Project enables Purdue’s aspiring astronautics students to obtain
valuable multi-disciplinary, hands-on experience. Also, the use of a DSP processor
compatible with MATLAB and LabVIEW will demonstrate the technology that can be
used by astronautics students to implement their MATLAB/LabVIEW models directly on
embedded platforms which saves a lot of development time.
1.3 Overview of the Satellite System
The PurdueSat system will be composed of the following subsystems: Attitude
Determination System, Attitude Control System, Science Payload, Communication
System, Power Subsystem, and Flight Computing System.
Attitude Determination System: This subsystem is responsible for the determination of
the orientation of the satellite in three dimensional space. It uses a magnetometer and a
sun sensor for obtaining the information about the satellite orientation, which are then
processed through computationally intensive estimation algorithms to extract meaningful
attitude data.
3
Attitude Control System: This subsystem deals with the autonomous control of the
orientation of the satellite in order achieve a nominal orientation which is nadir pointing antennas facing the earth so that the communication link with the ground stations is not
disrupted. The electromagnetic torque rods along the 3 axes of the satellite fire in a
periodic manner depending on the outputs of the control law algorithm in order to
achieve this.
Science Payload: This subsystem is mainly comprised of a radiation detector which
samples the radiation levels in the low earth orbit of the satellite and stores the data
whenever any activity is detected.
Communications System: This system is concerned with the transmission of data and
commands to and from the ground station. It also interfaces with all the other subsystems
and informs them to take appropriate action depending on the commands received.
Power System: This subsystem provides regulated power to all the subsystems onboard
and thus is the source of energy for the entire satellite. The solar power is harnessed using
solar cells and stored by charging the batteries onboard. It regulates the power and shuts
down less critical systems under low power conditions (For example, when in eclipse
where solar power is unavailable).
Flight Computing System: This is the brain of the entire satellite and is composed of 2
different computers. A Blackfin 16-bit Digital Signal Processor running at 650 Mhz
handles all the mathematically intensive algorithms and a 32-bit ARM7 microprocessor
running at 60 Mhz acts as the satellite host computer performing all the house keeping
operations. These computers communicate with each other using a high speed serial
connection.
The Satellite Structure which holds everything in place is regarded as a separate
entity which forms the skeleton of the satellite.
4
1.4 Areas of Focus
The key areas of focus for the Senior Design Project were the following:
1. Attitude Determination System
2. Attitude Control System
3. Power System
4. Flight Computing System
5. Satellite Structure
The work done in each of these areas and the current status are documented in the
following chapters.
5
2. Attitude Determination System
2.1 Attitude Determination
Author: Paul Moonjelly
2.1.1 Purpose
The Attitude Determination System is responsible for providing the 3-axis attitude
knowledge to the Attitude Control System which needs to know the current orientation in
order to perform any control operations. The Attitude Determination System handles the
sensory inputs from different sensors and performs computations on them in order to
estimate the current attitude – the orientation of satellite in three dimensional space.
2.1.2 Design Methodology
2.1.2.1 Attitude Determination
Attitude determination typically utilizes a combination of sensors and
mathematical models to arrive at a good attitude estimate. At least two vectors are
required to determine the attitude. It takes three independent parameters to determine the
attitude, and a unit vector is only two independent parameters because of the magnitude
constraint. Hence three scalars are required to determine the attitude. Thus more than one
but less than two vector measurements are needed. The attitude determination problem is
thus either underdetermined or overdetermined and all algorithms really only estimate the
attitude.
Two non collinear vectors are needed to determine the 3-axis attitude. These
vectors have to be known both in the inertial frame and the satellite body frame. These
vector components are used in one of the attitude estimation algorithms to determine the
attitude in the form of a quaternion or Euler angles or a rotation matrix. The vectors in the
body frame are obtained by using sensor measurements onboard the satellite. The same
vectors in the inertial frames are calculated using mathematical models.
6
2.1.2.2 Choice of Sensors & Algorithm
The PurdueSat Attitude Determination System uses a sun vector and a magnetic
field vector as the two vectors of choice. A sun sensor measures the components of the
sun vector in the body frame and a mathematical model of Sun’s apparent motion relative
to the satellite would be used to determine the components of the same vector in the
inertial frame. A 3-axis magnetometer measures the components of the magnetic field
vector in the body frame and a mathematical model of the Earth’s magnetic field relative
to the satellite is used to determine the components in the inertial frame. An attitude
determination algorithm is then used to compute the rotation matrix or the quaternion
between the inertial and the body frames.
The Triad algorithm is the simplest deterministic attitude determination algorithm.
This algorithm is based on discarding one extra piece of information in the
overdetermined problem as explained earlier. The algorithm does not just throw away
one of the components of the measured vector. It is based on constructing two triads of
orthonormal unit vectors using the vector information available. Let the vector
measurements in the satellite body frame be b1 and b2, and let the inertial vectors be r1
and r2. It is assumed that the first vector measurement b1 is more accurate. Two triads are
constructed as in the following equations:
t1b = b1
t1r = r1
t2b = (b1 x b2) / |b1 x b2|
t2r = (r1 x r2) / |r1 x r2|
t3b = (t1b x t2b)
t3r = (t1r x t2r)
Rotation Matrix, Rbr = [t1b t2b t3b][ t1r t2r t3r]T
The Triad algorithm was chosen for implementation during this semester because of two
reasons. The first one is that the Triad algorithm is the most straight forward one and it is
not demanding in terms of the computational load. The second reason is that there is an
order of magnitude difference in the expected accuracies of the sun sensor (<0.5 deg
accuracy) and magnetometer (5 deg accuracy) attitude measurements according to
literature. Hence the use of mathematically intensive statistical attitude estimation (which
7
weigh both sensor measurements optimally) algorithms will not result in significant
accuracy improvements. However, this choice will have to be reviewed later once both
sun sensor and magnetometer have been fully developed and tested for their accuracies.
2.1.3 Current Status
It was decided to develop the sun sensor in-house and a considerable amount of
design and development effort has been done. The details of the sun sensor development
are explained in the next section. Several attitude determination algorithms were
surveyed and the Triad algorithm was chosen for implementation. Triad algorithm has
been implemented in MATLAB and the results have been verified. The choice of sensor
combination has been finalized as a sun sensor and a magnetometer. The Triad algorithm
has verified that this combination can determine the attitude rotation matrix whenever the
satellite is not in eclipse or magnetic field vector and sun vector are non collinear.
2.1.4 Future Work
It was found in literature that the QUEST algorithm gives accurate attitude
estimations if the two sensor accuracies become comparable. It was also not extremely
demanding in terms of computing power even though it was much more than the Triad
algorithm. So this needs to be looked into once the sensors have been tested for their
accuracies.
An extended Kalman filter will also be a good idea for future implementation to
get better attitude estimates and it can provide attitude information even with out both
sensors being completely functional. A Kalman filter will be able to give reasonable
estimates of attitude even when the satellite is in eclipse and the sun sensor is useless.
Another possibility is making use of the information from the rate gyros which are used
for providing rate feed back to the Attitude Control System. Even though the gyro error
grows with time they can provide short term attitude information by integration of the
attitude rates coupled with information from other sensors available.
The Printed Circuit Boards (PCB s) for the magnetometer and the sun sensor have
to be fabricated.
8
2.1.5 References
[1] http://www.aoe.vt.edu/~cdhall/courses/aoe4140/attde.pdf
[2] http://www.cubesat.aau.dk/dokumenter/ADC-report.pdf
[3] http://www.cubesat.aau.dk/dokumenter/acs_report.pdf
9
2.2 Sun Sensor
Author: Mark James
Purpose
The sun sensor system as a whole is of vital importance to the attitude determination and
controls system. This sensor is 1 of 3 sensory inputs onboard the satellite and is
responsible for generation of the sun vector, the vector pointing from the satellite to the
center of the sun. When combined with a second vector from the magnetometer, this
gives information about the satellite’s orientation in the orbit frame. This is necessary for
ensuring a stable spacecraft orientation which is a main goal of the Purdue cubesat
mission. This is of importance to the mission because of the communications
requirement. The satellite must have a stable nadir orientation with its dipole antenna
pointing toward the Earth at all times when outside of solar eclipse.
Specifically, the sun sensor box is an important component of the sensor system. The sun
sensor system design uses a position sensitive detector (PSD) that requires a single light
beam to illuminate the detector surface in order to create the desired vector. This means
that all other light must be blocked from the detector surface. The box is also needed for
mounting purposes and structural integrity of the sun sensor system.
Design Methodology
2.2.1.1 Enclosure
The sun sensor box is made from a dark opaque plastic in order to provide strength,
create a non-conducting surface to eliminate shorts, block external light, and minimize
reflections inside of the box. The box has a pin hole on the top with a ledge for the PSD
to rest on. This creates a height, z, between the PSD surface and the pinhole. Figure 2.21 displays a crude image of the box with labeled dimensions.
10
Figure 2.2-1: Sun Sensor Box with PSD in place
The height, z, has a critical value in order to achieve a maximum desired angle θ while
maintaining a high angle resolution. The height, z, was determined to be 2.5 mm using
Equation 2.2-1 for a desired angle θ.
tan  
L2
z
Equation 2.2-1
L is the fixed PSD surface width of 9 mm and  is chosen to be at least 60 degrees. The
angle resolution is next checked. The computing system responsible for sensor devices is
a 10-bit system. This means there are 1024 data points available after analog-to-digital
conversion across the PSD surface in each direction (x and y). Using Equation 2.2-2 to
determine the smallest change in x position across the detector surface and Equation 2.23 to calculate the smallest change in angle, δθ is determined to be 0.2 degrees. This is a
very high resolution for  detection. Noise considerations are neglected at this point,
but are examined in the sun sensor electrical board section.
x 
L
 0.00879mm
1024
tan  
x
z
 0.2
Equation 2.2-2
Equation 2.2-3
Figure 2.2-2 displays the fabricated enclosure including the back plug.
11
Figure 2.2-2: Sun Sensor Box and back plug
The box is designed with two side mounting flanges. The top part of the box will slide
into a fitted hole which is cut into the satellite side walls. The box will hold itself in place
with the side flanges and fit flush with the outer satellite panel. The plug, shown on the
left side of Figure 0-2, is designed to hold the PSD in place while the small slot allows an
exit for any connecting wires. Together, the box and plug complete the sun sensor
enclosure.
2.2.1.2 Pinhole
The enclosure works as a pinhole camera when a small hole is introduced to the top of
the box. Since the sun is effectively an infinite distance away from the pinhole with
respect to the distance between the PSD surface and the hole, the light beam hitting the
PSD will be in focus regardless of what height z is chosen. The pinhole size is therefore
carefully chosen to produce enough light on the PSD surface while maintaining accurate
distinction between small δθ values. It is noted that the width of the light beam projected
onto the PSD surface is decreased with increasing angle of incident light. This minimum
width is determined to be no less than half the pinhole diameter for a maximum angle of
60 degrees. Using Equation 2.2-4, the pinhole is chosen to be 0.2 mm in diameter so that
the decreased width is no less than 0.1 mm. However, this value may be too small in
order to produce a strong PSD output current signal since it has not yet been tested in
direct sunlight. Figure 2.2-3 illustrates the pinhole dimensions and decreased width with
increased angle with respect to the sun.
12
Figure 2.2-3: Sun Sensor Box showing reduced visible width
w  D sin 90   
Equation 2.2-4
Finally, the top surface of the box in beveled out around the pinhole to create a 130
degree cone. This allows light to pass into the hole at an angle up to 65 degrees in any
direction. Since the box is designed to handle a maximum angle of about 60 degrees in
any direction (120 degree cone), the 130 degree beveled cone provides a large enough
margin.
2.2.1.3 Sun Vector
The vector pointing to the sun is determined from the x and y coordinates of the light
beam position on the PSD. This is made possible by the Hamamatsu detector shown in
Figure 2.2-4. The detector is a photodiode with uniform resistance in two directions.
When a beam of light reflects onto the surface, the x and y resistances are decoupled and
altered based upon which quadrant the light beam passes onto. Unique currents relating to
these x and y positions now pass through the detector outputs and into an analog
computer. One function of this analog computer, referred to as the sun sensor circuit
board, computes the necessary calculations defined by the PSD manufacturer to get the
exact x and y position of the light beam on the detector surface. This relation is shown in
Equation 2.2-5.
13
Figure 2.2-4: Hamamatsu Position Sensitive Detector
2 x I 2  I 3   I 1  I 4 

L
I1  I 2  I 3  I 4
2 y I 2  I 4   I 1  I 3 

L
I1  I 2  I 3  I 4
Equation 2.2-5
In this equation, x and y relate to the coordinates and L is defined as 10 for this specific
position sensitive detector. The currents I1 through I 4 relate to the four different currents
output by the detector.
Next, the sun vector is easily determined from the x and y coordinates along with the
known height, z, from the PSD surface to the pinhole. The sun vector is defined below in
Equation 2.2-6. The ŝi unit vector system is fixed in the sun sensor frame with origin
fixed at the center of the pinhole. The sun vector points toward the center of the sun and z
is defined as 2.5 mm. This S frame is defined in Figure 2.2-5.

VS   xsˆ1  ysˆ2  zsˆ3
Equation 2.2-6
14
Figure 2.2-5:
ŝi unit vector system definition
Current Status
The sun sensor box is designed and fabricated, ready for use.
Future Work
The box must be tested in direct sunlight to determine whether the pinhole size is large
enough. From laboratory tests with the current sensor circuit board, the pinhole appears
to be too small for a wide angle to be achieved. Also, with the current design placement
on the cubesat of the second sun sensor, the mounting flanges need to be mounted on the
perpendicular axis to their current placement. This will allow the sensor box to fit in the
small gap where the antennas rest un-deployed. These are minor changes and should be
an easy fix in future semesters.
Resources
Hamamatsu data sheet:
http://sales.hamamatsu.com/assets/pdf/parts_S/S5990-01_S5991-01.pdf
15
3. Attitude Control System
3.1 Attitude Dynamics & Control Law
Author: Pinak Trivedi
3.1.1 Purpose
Introduction
The design requirement for the spacecraft dictates it will rotate around the earth from 600
to 800 km near circular orbit with a nadir pointing orientation spinning about the spin
axis. The spacecraft will travel in a polar orbit with a period time of about 90-100
minutes [1]. The spacecraft is assumed to be a rigid body with a circular orbit.
Coordinate System
The reference will be the orbital coordinates. The x axis is pointing towards the earth.
The y axis will be tangent to the orbit and the z axis will be orthogonal to the two. The
inertial coordinates refer to system with center of Earth as the origin. The x axis is
perpendicular to tangent of the equator, y axis is tangent to the equator, z axis completes
the right hand rule. This frame is denoted by i. The orbital coordinates will be fixed to
the spacecraft. See figure 1 for the free body diagram of the system. This frame is
denoted by b. The body will be same as the orbital frame for our purposes after controls
is applied. This frame is denoted by a.
16
Figure 1: FBD of Body Coordinates
3.1.2 Design Methodology
To determine the dynamics model we will need to determine what type of orbit the
spacecraft will have, what disturbances it will encounter, whether they are feasible to
model or not.
3.1.2.1 Orbit
The spacecraft will have a near circular orbit. This is further assumed to be circular since
the eccentricity is estimated to be zero. This combined with the short life cycle of the
satellite will make for a fair assumption.
3.1.2.2 Disturbances
As the spacecraft orbit the earth it will undergo many disturbance forces that may detract
it from its course or bring about instability in it. Therefore it is important to model the
disturbance torques that are typically encountered by a spacecraft at a low earth orbit.
Gravity Gradient Torque
17
The gravity gradient torque is the result Earth’s varying gravity field, which varies as the
inverse square of the distance from earth. The moments of inertia influence the behavior
of this torque, which makes it crucial to have favorable inertias, and the altitude of the
spacecraft. The gravity gradient refers to the fact that there exists a greater force on the
spacecraft closer to the Earth. This will be modeled in the equations of motion.
Solar Radiation
This disturbance is the hardest to model, caused by the solar pressure from the radiation
of the sun and its reflections off of Earth and Moon. This will be ignored in the modeling
process for such reason and also the fact that the disturbance caused is negligible.
Aerodynamic Drag
This results from the spacecraft interaction with the atmosphere. This torque can be
neglected due to the altitude of this mission which is between 600 km to 800km.
Earth’s magnetic field
This torque is created by interaction of the spacecraft’s magnetic field with that of the
Earth. This torque acts cyclically on the spacecraft and also depends on the altitude.
This torque is also absent because the magnetic torque created by the control system
should overwhelm this disturbance. [2], [3], [4]
3.1.2.3 Equations of Motion
Assumptions
The spacecraft is assumed as an un-symmetric rigid body.
The gravity gradient
disturbance is modeled while ignoring the aerodynamic, solar, and magnetic field
disturbances.
The equations of motion can be derived using Newtonian method to derive Kinematic
and Dynamic equations of motion of the spacecraft. The kinematic equations give the
orientation while the dynamic equations give the torques of the spacecraft.
18
Variables and Constants
dH/dt is momentum rate
H is angular momentum
ω is angular velocity
ώ angular velocity rate
Ω is orbital velocity
Ω = √μ / Rcom3
q is quaternions
q’ is quaternion rate
E is quaternion transformation matrix
Tgg is gravity gradient torque
C is controls equations
B is magnetic field
3.1.2.4 Kinematics Equations
The kinematic equation is shown in Equation 0-1 for this system and will be used to
simulate the position of the satellite for the system.
q’ = ½ [ω1x3 0]*ET
Equation 0-1
For the Derivation See Appendix A
3.1.2.5 Dynamic Equations
Equation 0-2 is the dynamic representation of the system, one can see it has gravity
gradient term which is shown in Equation 0-3 and the controls terms in Equation 0-4.
dH/dt = Ibi* ώ bi + ωbi X (I X ωbi) – Tgg + C Equation 0-2
Tgg = 3* Ω2*(a1 ∙ I ∙ a1)
Equation 0-3
19
C=mXBXB
Equation 0-4
For the Derivation See Appendix A
Table 1 Preliminary Parameters
Ix
0.0038 Nm2
Iy
0.0084 Nm2
Iz
0.0089 Nm2
Altittude
700 km
e
~0 [3]
3.1.2.6 Control
Attitude control is necessary to keep the satellite in its orbit to resist disturbances and
basically do what it is designed to do. There are two general types of control systems,
active and passive.
3.1.2.7 Passive Controls
These control schemes are useful if one does not have any rigid mission requirements and
a cheap method of controlling satellite trajectory. These generally require no moving
parts and are lighter.
Gravity Gradient
In this case the satellite can be oriented in a manner where the gravity torque can stabilize
the satellite. To utilize this effectively the satellite must have the inertial properties
where the smallest moment of inertia must be nadir pointing.
20
Passive Magnets
This utilizes permanent magnets in a satellite to align it along the Earth’s magnetic field.
This presents an effective and cheap method as a control mechanism. This can only work
for near Earth orbits.
Spin
Spin due to solar radiation may provide adequate momentum to stabilize the spacecraft.
3.1.2.8 Active controls
This type of control scheme allows total control of the satellite movement. Magnetic
coils, spinning rotor, momentum wheels, and chemical thrusters are some methods of
controlling satellite movement.
Magnetic Coils
This uses Earths own magnetic field to convert the magnetic interaction between the field
of the coil and the Earth into magnetic moment which can stabilize the spacecraft. This
has the advantage of requiring no fuel and moving parts, therefore being lighter.
Spinning rotor
This requires a rotor about the axis which needs stabilization. It can stabilize the spin
axis or all three axes depending on the mission requirement.
Momentum wheel
There are many types; however they require momentum dumping which may need
chemical thrusters or magnetorquers. This ends up adding additional weight and a
complexity of moving parts.
Chemical Thrusters
These, as well as electric thrusters, require fuel and add additional complexity and weight
for the satellite of this weight class, which it can do without. [2], [3], [4]
21
3.1.2.9 Controllability
The first issue that arises when picking a control scheme is whether it will make the
system controllable in the manner desired. To do this first one must linearize the nonlinear system about the desired Lyapunov Stability. Then derive the controls law and do
a preliminary test for controllability. To check for controllability one must satisfy the
following condition:
For a matrix size Anxn, rank of [B, A* B, … An-1*B]. The rank of this matrix must equal
to the rank of matrix A.
The rank of the current system is fully controllable in time invariant domain. Due to the
magnetic field interaction, however, the time varying system will not always be
controllable when the magnetic fields are parallel to each other at the poles and the
equator.
3.1.2.10 Control Scheme
Linear Quadratic Regulator control scheme was utilized to control the satellite. Time
invariant system was derived about the equilibrium points shown below. The controller
is derived from a discretized linear model at sample time of 1000 per second with upper
limit of 1,000,000 data point per second as the upper limit.
3.1.2.11 Linearizing
The non-linear equations must be stabilized about equilibrium points that the controller
can drive the system to. To do this, the non-linear system must be linearized about
required equilibrium points.
To find these points one must solve the following
conditions:
F1 (x1e, x2e , xne) = 0
…
22
Fn (x1e, x2e , xne) = 0
They can also be found using the “trim” command from matlab. To use this command
one must have estimated location of equilibrium points.
The linearization points for the system:
For Dynamics equations
[ω1 ω2 ω3] = [δ ω 1
δ ω2
Ω+ δ ω 3]
For Kinematics equations
[e1 e2 e3 e4]= [δe1 δe2 δe3 1]
Once the process is completed one can have a state-space representation of the system
For Continuous time:
x’(t) = Ax(t) +Bu(t)
y(t) = Cx(t) + Du(t)
For Discrete time:
x (n+1) = Ax(n) + Bu(n)
y(n) = Cx(n) +Du(n)
And now the state space controller can be designed.
3.1.2.12 Linearized Matrix
The linearized matrix is currently time invariant. It is presented below for nadir pointing
satellite.
23
A=[0
wo*(Iy-Iz)/Ix 0
0
0
0;
wo*(Iz-Ix)/Iy
0
0
0
6*wo2*(Iz-Ix)/Iy
0;
0
0
0
0
0
0.5
0
0
0
wo
0
0.5
0
-wo 0
0
0
0.5 0
I = [Ix
0
0;
0
Iy
0;
0
0
Iz]
B= [inv(I)*[-((b32)+(b22))
[b2*b1
[b3*b1
0;
0]
b1*b3]
-((b32) + (b12))
03x3
0;
0
b1*b2
b3*b2
6*wo2*(Ix-Iy)/Iz;
b2*b3]
-((b22)+(b12))]
] [2], [3], [4]
3.1.2.13 Simulink Model
Below one can see the simulink model used to run the non-linear model with the
controller applied. The results that will be presented are from the model below and other
accompanying matlab files that will accompany this report will show the work and the
necessary details. In the following figure, the block named unsymmetric is the non-linear
system and controller, the gain block applies the gains calculated from another matlab
code and the extra clock output is to make all calculation have the same array length.
24
Figure 2: Simulink Model
3.1.3 Results
Several types of disturbances were simulated and the results are presented below. There
seem to be some wrinkles that will need to be ironed out but on the whole this provides a
proof of concept of controllable system.
The first set of plots will show typical disturbance forces encountered as predicted by
Aalborg University [2] and University of Urbana Champaign [3]. The second will show
detumbling simulation, and the third one will show a grossly incorrect orientation of the
spacecraft [4]; the latter two which may be encountered right after the launch from the PPOD.
Initial conditions for figure 3 and 4:
w1,2,3 = 0.001; e1 = 0.001; e2 = 0.001; e3= 0.001; e4 = 1;
25
Quarternions in relation to time e1=blue e2=red e3=cyan e4=green
1
0.8
0.6
quaternions
0.4
0.2
0
-0.2
-0.4
-0.6
-0.8
-1
0
1000
2000
3000
4000
time in seconds
5000
6000
7000
Figure 3: Quaternions for Normal Disturbances
Angular Velocity in relation to time w1=blue w2=red w3=cyan
0.1
0.08
0.06
angular rates
0.04
0.02
0
-0.02
-0.04
-0.06
-0.08
-0.1
0
1000
2000
3000
4000
time in seconds
5000
6000
7000
Figure 4: Angular Rates for Normal Disturbances
26
Initial conditions for figure 5 and 6:
w1,2,3 = 0.01; e1 = 0.01; e2 = 0.01; e3= 0.01; e4 = 0.999;
Quarternions in relation to time e1=blue e2=red e3=cyan e4=green
1
0.8
0.6
quaternions
0.4
0.2
0
-0.2
-0.4
-0.6
-0.8
-1
0
1000
2000
3000
4000
time in seconds
5000
6000
7000
Figure 5: Quaternions for Detumbling
Angular Velocity in relation to time w1=blue w2=red w3=cyan
0.1
0.08
0.06
angular rates
0.04
0.02
0
-0.02
-0.04
-0.06
-0.08
-0.1
0
1000
2000
3000
4000
time in seconds
5000
6000
7000
Figure 6 Angular Rates for Detumbling
27
Initial conditions for figure 7 and 8:
w1,2,3 = 0.01; e1 = 0.998; e2 = 0.01; e3= 0.01; e4 = 0.099;
Quarternions in relation to time e1=blue e2=red e3=cyan e4=green
1
0.8
0.6
quaternions
0.4
0.2
0
-0.2
-0.4
-0.6
-0.8
-1
0
1000
2000
4000
3000
time in seconds
5000
6000
7000
Figure 7: Quaternions for Incorrect Orientation
Angular Velocity in relation to time w1=blue w2=red w3=cyan
0.1
0.08
0.06
angular rates
0.04
0.02
0
-0.02
-0.04
-0.06
-0.08
-0.1
0
1000
2000
3000
4000
time in seconds
5000
6000
7000
Figure 8: Angular Rates for Incorrect Orientation
28
3.1.4 Current Status
Currently we have a proof of concept of a working controller for the satellite.
3.1.5 Future Work
The requirements of the current project required a spinning satellite about its nadir axis.
This was difficult to achieve due to lack of literature on the subject. However, this paper
show the basic proof of concept achieved in controlling the satellite, and more schemes
such as Linear Matrix Inequality can be tried to achieve better results.
Appendix A
ω1x3 = [ω1 ω2 ω3]
E = [e4 -e3 e2
e3 e4 -e1
-e2 e1 e4
-e1 -e2 -e3
e1
e2
e3
e4]
Kinematic Equations
ed1 = 0.5*[W1*e4 - W2*e3 + e2*(W3 + wo)];
ed2 = 0.5*[W1*e3 + W2*e4 - e1*(W3 + wo)];
ed3 = 0.5*[-W1*e2 + W2*e1 + e4*(W3 - wo)];
ed4 = 0.5*[-W1*e1 - W2*e2 - e3*(W3 - wo)];
Dyanmic Equations
wd1 = K1*[ W2*W3 - 12*wo^2*(e1*e2 - e3*e4)*(e3*e1 + e2*e4)];
wd2 = K2*[ W1*W3 - 6*wo^2*(1 - 2*e2^2 - 2*e3^2)*(e3*e1 + e2*e4)];
wd3 = K3*[ W1*W2 - 6*wo^2*(1 - 2*e2^2 - 2*e3^2)*(e1*e2 - e3*e4)];
29
Appendix B
Codes
% Purdue model, Discrete works here
clear all
clc
global A B C D Ai Bi Ci
u1=398600.4418E8; %from wikipedia searching: Gravitational constant
a=700000; % semimajor axis, assuming 700 km orbit
c=sqrt(u1/a^3);
wo= c;
Iz = 0.0089;
% Inertial along body z-axis [kg-m^2]
Iy = 0.0083;
% Inertial along body y-axis [kg-m^2]
Ix = 0.0038; % nadir pointing
I=[Ix 0 0; 0 Iy 0;0 0 Iz];
% A is the linearized matrix see additional notes to see
% about which the nonlinear model was linearized
A=[ 0
wo*(Iy-Iz)/Ix 0
0
0
wo*(Iz-Ix)/Iy 0
0
0
6*wo^2*(Iz-Ix)/Iy
0
0
0
0
0
Iy)/Iz;
0.5
0
0
0
wo
0
0.5
0
-wo 0
0
0
0.5 0
0
% A=[A zeros(6,1);1 zeros(1 6)] % intergral
% B is the where the controls law goes see notes
the points
0;
0;
6*wo^2*(Ix0;
0;
0 ];%[dw dq ]'
b1=6E-5;
b2=b1/10;b3=b1/10; % Define the B field of earth. This is the lowest
recorded B field recorded as presented in UIUC paper on ION cubesat
I2=[-((b3^2)+(b2^2)) b1*b2 b1*b3;b2*b1 -((b3^2) + (b1^2)) b2*b3;b3*b1
b3*b2 -((b2^2)+(b1^2))]; %the derived control law, see Wertz book
%or any paper on cubesats using magnetic coils
B = [inv(I)*I2;zeros(3,3)];% inv(I) is at the corresponding w terms
% B=[inv(I);zeros(3,3)]/1E4;
% B=[B;zeros(1,3)]% when you add an integrator
%C is this becuase we are currently assuming full observability and D
is
%zero because we are assuming no sensor noise
C = [eye(3) eye(3)] ;
% C=[C zeros(3,1)] ; %when you add an integrator
D=[zeros(3,3)];
%% check controllablity
%using PBH test to determine controllablity by checking rank
%the rank of [e*I-A|B] = n for every eigenvalue to be fully
%controllable
%
%
%
%
%
%
%
clc
cntrlblty_6=rank(ctrb(A,B));
e=eig(A)
for i=1:length(e)
r=e(i)*eye(6)-A;
r=[r B];
30
%
rank_eig(i)=rank(r);
% end
%
% disp('rank_eig')
% disp(rank_eig)
%% Integral controller
close all
Ai = [A zeros(6,1);1 zeros(1,6)];
Bi = [inv(I)*I2;zeros(4,3)];
Ci = [eye(3) eye(3,4)];
sys=ss(Ai,Bi,Ci,D);
% The sampling time used is 1000 per second 1E6 is the upper limit for
our
% current hardware
sys=c2d(sys,.001)
N=[1*eye(3); zeros(4,3)];%part of the discrete time equation = See Help
dlqr
[K,S,E] =dlqr(sys.a,sys.b,diag([1E-4 1E-4 1E-4 5E1 5E1 5E1 1E2])*1E3,eye(3),N); %discrete a & b are substituted
% [K,S,E] =lqr(A,B,diag([1E1 1E1 1E1 2E4 2E4 2E4])*1E0,eye(3));
%continuous
[num den]=ss2tf(A,B,C,D,1)
time1=7000;
sim('unsym',[1 time1])
figure(1)
plot(t,e1(:,2),'b')
hold on
plot(t,e2(:,2),'r')
plot(t,e3(:,2),'c')
plot(t,e4(:,2),'g')
plot(t(:,1),e1(:,2).^2+e2(:,2).^2+e3(:,2).^2+e4(:,2).^2,'k')
title('Quarternions in relation to time e1=blue e2=red e3=cyan
e4=green')
xlabel('time in seconds')
ylabel('quaternions')
% legend('e1','e2','e3','e4','deviation from constraint')
axis([0 time1 -1.1 1.1 ])
figure(2)
plot(t,w1(:,2),'b')
hold on
plot(t,w2(:,2),'r')
plot(t,w3(:,2),'c')
title('Angular Velocity in relation to time w1=blue w2=red w3=cyan')
xlabel('time in seconds')
ylabel('angular rates')
axis([0 time1 -.1 .1 ])
% legend('W1','W2','W3')
E
K
%% Make controller using LQR. Continous time
% clc
31
%
%
%
%
%
%
%
close all
sys=ss(A,B,C,D);
[K,S,E] =lqr(sys,1E0*diag([1E-4 1E-4 1E-4 1E0 1E0 1E0]),eye(3));
% using pole placement
% wn=5;z=0.7;
% K=place(A,B,[roots([1 2*z*wn wn^2])' -3 -3.4 -3.9 -3.8])
[num den]=ss2tf(A,B,C,D,1)
% S-function to describe the dynamics of the circular orbit
% Input is a angles and quaternions
%*****************************************************
%This s-fxn block is similar to those from the examples you will find
on
%the AAE 421 website. The only things changed here are the inputs to 3
%because this is a multi-input multi-output system and we have three
inputs
%and the rest was changed acccording to the guidlines provided by the
%example
function [xp,x0,str,ts] = unsymmetric(t,x,u,flag)
%***************************
%
%
%
%
%
t is time
x is state
u is inout
flag is a calling argument used by Simulink.
The value of flag determines what Simulink wants to be executed.
switch flag
case 0
% Initialization
[xp,x0,str,ts]=mdlInitializeSizes;
case 1
% Compute xdot
xp=mdlDerivatives(t,x,u);
case 2
% Not needed for continuous-time systems
32
case 3
% Compute output
xp = mdlOutputs(t,x,u);
case 4
% Not needed for continuous-time systems
case 9
% Not needed here
end
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% mdlInitializeSizes
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
function [xp,x0,str,ts]=mdlInitializeSizes
global A B C D Ai Bi Ci % these need to be global mostly because you
need B as seen at the end function xp = mdlDerivatives(t,x,u) for
feedback
% make sure the feedback gain is -K as the model is
% simulink is created right now.
% Create the sizes structure
sizes=simsizes;
sizes.NumContStates = 7;
%Set number of continuous-time
state variables
sizes.NumDiscStates = 0;
sizes.NumOutputs = 7;
%Set number of outputs
sizes.NumInputs = 3;
%Set number of intputs
sizes.DirFeedthrough = 0;
sizes.NumSampleTimes = 1;
%Need at least one sample time
xp = simsizes(sizes);
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
global A B C D Ai Bi Ci
W10 = 1*.01; %w/omega
W20 = 1*.01; %w/omega
W30 = 1*.01;
e10 = 1*.01;
e20 = 1*.01;
e30 = 1*.01;
e40 = .999;
u=398600.4418E8; %from wikipedia searching: Gravitational constant
a=700000; % semimajor axis, assuming 700 km orbit
c=sqrt(u/a^3);%orbital
wo= c;
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
x0=[W10;W20;W30;e10;e20;e30;e40];
% Set initial state [w10,w20,w30,e10,e20,e30,e40]
str=[];
% str is always
an empty matrix
ts=[0 0];
% ts must be a matrix of at
least one row and two columns
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
33
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% mdlDerivatives
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
function xp = mdlDerivatives(t,x,u)
%parameters
global A B C D Ai Bi Ci
I2=0.0083;
I3=0.0089;
I1=0.0038;
K1 = (I2 - I3)/I1;
K2 = (I3 - I1)/I2;
K3 = (I1 - I2)/I3;
u1=398600.4418E8; %from wikipedia searching: Gravitational constant
a=700000; % semimajor axis, assuming 700 km orbit
c=sqrt(u1/a^3);
wo= c;
W1 = x(1);
W2 = x(2);
W3 = x(3);
e1 = x(4);
e2 = x(5);
e3 = x(6);
e4 = x(7);
wd1 = K1*[ W2*W3 - 12*wo^2*(e1*e2 - e3*e4)*(e3*e1 + e2*e4)]; %2*pi*J/I1*s*W2;
wd2 = K2*[ W1*W3 - 6*wo^2*(1 - 2*e2^2 - 2*e3^2)*(e3*e1 + e2*e4)];% +
2*pi*J/I2*s*W1;
wd3 = K3*[ W1*W2 - 6*wo^2*(1 - 2*e2^2 - 2*e3^2)*(e1*e2 - e3*e4)];
ed1 = 0.5*[W1*e4 - W2*e3 + e2*(W3 + wo)];
ed2 = 0.5*[W1*e3 + W2*e4 - e1*(W3 + wo)];
ed3 = 0.5*[-W1*e2 + W2*e1 + e4*(W3 - wo)];
ed4 = 0.5*[-W1*e1 - W2*e2 - e3*(W3 - wo)];
% u = is the output of the gain block feedback ie when you open the
model you
% see that the gain block reads K*u, when you double click on the gain
% block you see y=K*u or u.*K etc. The product y is actually outputted
as
% u which goes back into the states
u
xp= [wd1, wd2, wd3, ed1, ed2, ed3, ed4]'+ Bi*u; %you need this here or
you controller won't be doing anything
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% mdlOutput
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
function xp = mdlOutputs(t,x,u)
global A B C D
% Compute xdot based on (t,x,u) and set it equal to sys
xp=[x(1) x(2) x(3) x(4) x(5) x(6) x(7)];
34
References
[1] Purdue Cubesat Report, Fall 2006.
[2] Graversen, Torben, Michael K. Frederiksen, and Soren V. Vedstesen. Attitude
Control System for AAU Cubesat. Diss. Aalborg Univ., 2002.
[3] Gregory, Brian S. Attitude Control System Design for ION, the Illinois Observing
Nanosatellite. Diss. Univ. of Illinois At Urbana-Champaign, 2001.
[4] Makovec, Kristin L. A Non-Linear Magnetic Controller for Three-Axis Stability of
Nanosatellites. Diss. Virginia Polytechnic Institute and State Univ., 2001.
35
3.2 Actuator - Magnetic Torque Coil
Author: Mark James
Purpose
The magnetic torque coil board provides the propulsive capability of the spacecraft. The
board is responsible for the physical act of attitude control, determined from the control
law. Secondly, the board is responsible for all power generation onboard the satellite. It is
designed to fit four solar cells at the center, where sunlight is converted into battery
power.
Design Methodology
3.2.1.1
Square Loop Current
The coil is designed to be a square current-carrying loop. This design is optimal for the
purpose of the board in a way that maximizes torque produced and power generated from
solar cells. The loop runs along the outside of the rectangular board which leaves room
for the four solar cells mounted in the middle. The board is to serve as the outer panels of
the satellite so that no space inside is compromised. This is also a necessity for maximum
incident sunlight onto the solar cells. Looking at Equation 3.2-1 for the magnetic
moment produced from a current carrying loop, it can be seen that maximum area inside
the loop is an optimal choice.

M  INAAvg nˆ
Equation 3.2-1
In this equation, M is the magnetic moment, I is the current through the loops, N is the
number of turns, AAvg is the average area of the loops, and  is the permeability of the
core material. The moment is produced in the n̂ direction which is found by using the
right-hand-rule with respect to the direction of current flow. The torque produced by the
board can be next calculated using Equation 3.2-2

 
T  M B
Equation 3.2-1

where B is the local magnetic field.
36
3.2.1.2
Printed Circuit Board Dimension Analysis
The board is a printed circuit board (PCB) with the square loop winding toward the
center. This is unlike a solenoid, which makes things a bit more difficult to analyze. Since
Equation 3.2-1 refers to the average enclosed area, an iteration must be done for the
decreasing square loop average area. The equation for average area takes the form of
Equation 3.2-3
ab 

AAvg    AAvg  i i 
N 
i 1 
N
Equation 3.2-3
where N is the total number of turns, ai is the length of each loop, and bi is the width of
each loop. A series for was derived in the form of Equation 3.2-4 to determine the length
and width of each loop.
N
 a
i 1
i
N
 b
i 1
i
 a max  2d  N i  1
 bmax  2d  N i  1
Equation 3.2-4
In this equation, amax is the first (maximum) outer loop length, d is the distance between
each loop measured from the center of each wire, and N is the total number of turns.
It is known that the maximum amount of turns is favorable to produce a high magnetic
moment, but there is a limitation in order to fit the solar cells on the same board.
However, the trade off is acceptable with about a 45% loss in magnetic moment with the
decreased number of turns. This loss is made up for by printing the square loop on both
sides of each board, and using two boards per moment direction. The result is a total
magnetic moment of 0.1 A-m2 per direction with each board producing 0.05 A-m2.
Although only 32% of the total board surface is used by the square loop, the loss is
minimized since the loops are around the outer portion of the board where maximum
magnetic moment is produced.
37
3.2.1.3
Power Usage
In satellite applications, there is a heavy limitation on power provided to each subsystem.
At this point, it is determined that each moment direction should not deplete more than
0.3 watts. The coils will not use more than a total of 0.3 watts to create the desired
magnetic moment vector determined by the control law. Although each moment direction
can use a maximum of 0.3 watts, a pulsed width modulation (PWM) system will be used
to create the desired vector. This means that all the coils relating to each moment
direction are pulsed at full power at a specified frequency and pulse width. Two coil
moment directions will not be on at the same time, only allowing 0.3 watts to be used.
The coils will be coordinated with respect to time through PWM to produce an effective
single vector.
In order to determine the current through the coil as well as the power used, the length of
the wire is needed. The wire length was derived in the form of Equation 3.2-5.
l  2b  a 
2 N 1
 (a  id )  (b  id )  b  d (2 N  1)
Equation 3.2-5
i 1
In this equation, a and b are the outer loop length and width dimensions, d is the
distance between the loops from center to center, and N is the total number of turns.
Once this length is known, the resistance in the wire is calculated using Equation 3.2-6
Rw 
l
s
Equation 3.2-6
where  is the conductivity of the wire material and s is the cross sectional area. The
method for determining wire current is done by fixing two parameters. Power usage is
fixed to a desired value of 0.3 Watts and voltage is fixed to the supply limitation of 5
Volts. Next, the required total resistance is calculated by combining Joule’s and Ohm’s
law, taking the form of Equation 3.2-7.
RT 
V2
P
Equation 3.2-7
Once this total resistance is known, coil is run in parallel including the two coils on each
board along with the two boards used to produce an amplified magnetic moment. Since
the wire resistance does not match the total resistance, the H-bridge resistance is added to
38
meet this requirement in order to produce the desired power output from the limited
voltage. Equation 3.2-8 shows the relation for H-bridge resistance.
RHB  4 RT  Rw
Equation 3.2-8
Finally, the current is calculated using Equation 3.2-9.
I
3.2.1.4
P
RT
Equation 3.2-9
Results
When fixing the power generated by the coil and the supply voltage, current and total
resistance also become fixed. It is known that by decreasing the supply voltage, a lower
total resistance is achieved to produce the same power generation. This required total
resistance can be matched by decreasing the H-bridge resistance as well as the coil
resistance. To decrease the coil resistance, the wire cross sectional area can be increased
as well as the total length decreased. The following plots are shown as a function of trace
width of the wire. By increasing this width, the number of turns and total length decrease.
When the supply voltage is too low, an impossible negative H-bridge resistance is
sometimes required to create the required total resistance. This is accounted for by
increasing trace width of the wire to decrease wire resistance and increase H-bridge
resistance while minimizing the loss of turns. The result is an increased magnetic
moment, as shown in Figure 3.2Error! Reference source not found.-1. It is noted that
these plots have steps or jagged trends due to a limitation on number of turns. The
number of turns is limited to integers, and is rounded down so that half turns are not
implemented.
39
Figure 3.2-1: Magnetic Moment and H-bridge Resistance vs. Trace Width
This figure is plotted for a supply voltage of 0.5 Volts and a power output of 0.3 Watts.
As shown, the H-bridge resistance becomes a feasible positive value at a trace width of
0.73 mm. This corresponds to a maximum magnetic moment of a large 0.36 A-m2.
Figure 3.2-2 shows the number of turns and coil current for this optimal supply voltage.
40
Figure 3.2-2: Number of Turns and Coil Current vs. Trace Width
The number of maximum turns has decreased to 12 at the optimum trace width of 0.73
mm while maintaining a current of 0.6 A. According to the ExpressPCB software guide,
a maximum of about 0.7 A is allowed at this trace width. The coil current for this design
is below 0.7 A, and therefore is allowable and optimized for maximum magnetic
moment. However, the supply voltage is limited to 5 Volts at this point due to the supply
choice. To create and maintain the low voltage of 0.5 Volts from the 5 Volt supply
system, a large amount of power will have to be dissipated through a resistor which
cannot be afforded. Therefore, the system is limited to the 5 Volt supply design. Figures
3.2-3 and 3.2-4 show the specifications for this design. As shown, a maximum magnetic
moment of 0.096 A-m2 is achieved with an H-bridge resistance of 299 Ohms. The
number of turns used is 32 with a trace width of 0.18 mm and a low current of 0.06 A.
41
Figure 3.2-3: Moment and H-bridge Resistance vs. Trace Width
Figure 3.2-4: Number of Turns and Coil Current vs. Trace Width
42
Finally, the relationship between total resistance, wire resistance, and H-bridge resistance
is shown in Figure 3.2-5.
Figure 3.2Error! Reference source not found.-5: Resistance vs. Trace Width
Current Status
The magnetic torque coil board design is completed and finished in ExpressPCB
software. The PCB is ready for fabrication at this point.
Future Work
The magnetic moment produced by these coils may be a little too low for quick
stabilization. However, the moment produced is in the expected range and can be
increased by using more power or adding additional boards inside the satellite. A
different supply voltage that can create lower voltages should be considered for the
design. As shown in this report, a low voltage can easily produce over two times the
amount of magnetic moment by using the same amount of power. If this path is chosen,
43
the torque coil board and H-bridge resistance will need to be redesigned as specified in
this report.
References
[1] Makovec, Kristin L. “Spacecraft Magnetic Field Interactions.”A Nonlinear Magnetic Controller
for Three-Axis Stability of Nanosatellites. Blacksburg, Virginia, 2001. 62-67.
MATLAB Code
%Mark James
%AAE 450 - Purdue Cubesat
%Modified 5/4/07
%This code calculates magnetic moment and other coil properties
%for the large board. The coil is printed on a PCB and the wire has a
%rectangular cross sectional area.
clc
clear all
close all
%Constants
t=linspace(0.007,0.15,2^12)*2.54/100;
%m
Wire Trace Width
h=0.0017*2.54/100; %m
Wire height
mu=1; %N/A^2
B_1=4;
%Number of layers
sigma=59.6e6;
%S/m copper conductivity
V=5;
%Supply Voltage (V)
%-----------------------b1 direction--------------------------%calculating power usage
%using the bisection method of iteration
R1hb1=0.2;
R1hb2=0;
n=1;
for j=1:length(t)
d(j)=0.007*2.54/100+t(j); %m
distance center to center
b=.185-t(j);
a=.083-t(j);
bi_min=0.162+t(j);
ai_min=0.06+t(j);
N1max(j)=floor((b-bi_min)/(2*d(j))+1);
N1=N1max(j);
aimin=a-2*(N1max(j)-1)*d(j);
bimin=b-2*(N1max(j)-1)*d(j);
s=t(j)*h;
%wire cross sectional area
Ao_1=a*b;
%calculating lsum used in total wire length calculations
lsum(j)=0;
44
for i=1:2*N1-1
lsum(j)=lsum(j)+(a-i*d(j))+(b-i*d(j));
end
Aavg_1(j)=0;
i=0;
N11=1:1:N1;
ai=0;
bi=0;
%Calculating Average Loop Area
for i=1:length(N11)
ai(i)=a-2*(N11(i)-1)*d(j);
bi(i)=b-2*(N11(i)-1)*d(j);
Aavg_1(j)=Aavg_1(j)+(ai(i)*bi(i))/N11(length(N11)); %A-m^2
end
%Running everything in Parallel
L12(j)=(2*b+a-(b-(2*N1-1)*d(j)) + lsum(j)); %total wire length
P12(j)=.3; %power
Rw12(j)=L12(j)./(sigma*s); %wire resistance, Ohms
R12(j)=V^2/P12(j); %total resistance, Ohms
R1hb2(j)=4*R12(j)-Rw12(j); %H-bridge resistance, Ohms
I12(j)=sqrt(P12(j)/R12(j)); %current
M12(j)=I12(j)*N1*B_1*Aavg_1(j)*mu; %Magnetic Moment, A-m^2
%I1(j)=V./R(j);
%P1(j)=I1(j).^2*R(j);
%Ensuring the H-bridge resistance is above 0.2 Ohms
if R1hb1-R1hb2(j) <= 0
R1hb(n)=R1hb2(j);
L1(n)=L12(j);
P1(n)=P12(j);
Rw1(n)=Rw12(j); %Ohms
R1(n)=R12(j); %Ohms
I1(n)=I12(j);
M1(n)=I1(n)*N1*B_1*Aavg_1(j)*mu; %A-m^2
t1(n)=t(j)*1000;
N1max1(n)=N1max(j);
n=n+1;
end
end
%Plotting
figure
subplot(2,1,1)
plot(t*1000,N1max);grid on;
title('Number of Turns vs Trace Width - 5 Volts, 0.3 Watts, Large
Panel')
xlabel('Trace Width (mm)');
ylabel('Number of Turns');
subplot(2,1,2)
plot(t*1000,I12);grid on;
title('Current vs Trace Width - 5 Volts, 0.3 Watts, Large Panel')
xlabel('Trace Width (mm)');
ylabel('Current (A)');
45
figure
subplot(2,1,1)
plot(t*1000,M12);grid on;
title('Magnetic Moment vs Trace Width - 5 Volts, 0.3 Watts, Large
Panel')
xlabel('Trace Width (mm)');
ylabel('Magnetic Moment (A-m^2)');
subplot(2,1,2)
plot(t*1000,R1hb2);grid on;
title('H-bridge Resistance vs Trace Width - 5 Volts, 0.3 Watts, Large
Panel')
xlabel('Trace Width (mm)');
ylabel('Rhb (\Omega)');
%hold on
figure
%subplot(3,1,1)
plot(t*1000,R12,'k');grid on;
title('Resistance vs Trace Width - 5 Volts, 0.3 Watts, Large Panel')
xlabel('Trace Width (mm)');
ylabel('R (\Omega)');
hold on;
plot(t*1000,Rw12,'b--');
plot(t*1000,R1hb2,'m--');
legend('Total Resistance','Wire Resistance','H-Bridge Resistance')
46
4. Power System
Author: Paul Moonjelly
4.1 Purpose
This subsystem provides regulated power to all the subsystems onboard and thus
is the source of energy for the entire satellite. The solar power is harnessed using solar
cells and stored by charging the batteries onboard. It regulates the power and shuts down
less critical systems under low power conditions (For example, when in eclipse where
solar power is unavailable).
4.2 Design Methodology
The lack of enough Electrical Engineering manpower on the team ruled out the
option of carrying out a board design from scratch. Hence Commercial-Off-The-Shelf
power boards available in the satellite market were surveyed. It was found that the
ClydeSpace EPS board manufactured by Clyde Space, Scotland would meet the power
and size requirements of the PurdueSat. It was also found that the board was
economically feasible since it would fit well into the PurdueSat budget. They also had
some space heritage and hence reliability is not of much concern.
Fig 4.1: Power System Block Diagram
47
The block diagram of this Power System is shown in figure 4.1. This system has 6
Battery Charge Regulators (BCR) on board each of which can be connected to an array of
solar cells.
Fig 4.2: Solar Cells from Spectrolabs Inc.
4.3 Current Status
The Power System board manufacturer was contacted and an order has been
placed. The board is under development and will be shipped within one month. The solar
cell manufacturer was also contacted for more information on solar cell wiring and
configuration. But the ITAR regulations caused a problem in revealing technical details
to the Project Engineer who is an international student. This issue is being worked on.
4.4 Future Work
The configuration of solar cells needs to be finalized after resolving the ITAR
regulation conflicts with the solar cell manufacturer. The compatibility of the
recommended configuration with the Power board has to be verified as well. The Power
board manufacturer recently announced a higher capacity Power System which might be
feasible for the PurdueSat and has enquired if Purdue wanted to use the higher capacity
version of their board. This question also needs to be addressed.
48
4.5 References
[1] http://www.clyde-space.com/Power_Systems.html
[2] http://www.spectrolab.com/DataSheets/TNJCell/tnj.pdf
49
5. Flight Computing System
Author: Paul Moonjelly
5.1 Purpose
The Flight Computing System (FCS) functions as the brain of the entire satellite.
All the other subsystems are connected physically to the Flight Computing System and
each one of those has a software component that lives inside the FCS. It is this software
component that enables the timely and proper functioning of each subsystem. Thus Flight
Computing System is responsible for performing all of the operations of the satellite
including control of onboard hardware devices, scheduling of operations, performing
mathematically intensive computations for generating control outputs, maintenance of
data, and communications with a ground station on Earth.
5.2 Design Methodology
5.2.1 Design Drivers
The primary mission of the PurdueSat is accurate attitude determination and
autonomous control which required handling of highly complex numeric processing tasks
by the Flight Computing System. This was because the algorithms for attitude
determination and control involved several matrix multiplications and inversions which
were to be carried out on 4x4 matrices containing floating point data. Hence the
computational demands imposed by the Attitude Determination System and the Attitude
Control System were a primary design driver in the choice of a computing system.
The second major driver was the need for a platform familiar to Aerospace
Engineering students which would reduce the learning curve and facilitate rapid design
and development. Using assembly level programming or even low level embedded C
programming for development was not a feasible option because of the lack of Electrical
Engineering manpower. The maintenance of the software after development would also
50
pose serious challenges to new incoming Aerospace students. Hence a user friendly but
extremely powerful embedded computing platform was necessary.
The other constraints that drove the design were the allowable power
consumption figures and the size limitations imposed by the CubeSat platform. The
Commercial-Off-The-Shelf (COTS) availability of the hardware platform with the above
mentioned characteristics was also a concern.
5.2.2 Primary Computing Platform
Embedded LabVIEW from National Instruments was chosen as the software
platform. The Blackfin Digital Signal Processor from Analog Devices was chosen as the
hardware platform. The LabVIEW Embedded Module for Blackfin Processors is a
comprehensive graphical development environment for embedded design which was
jointly developed by Analog Devices and National Instruments. This provides seamless
integration of the LabVIEW development environment and Blackfin embedded
processors. This approach can reduce development time significantly and simultaneously
provide a high-performance embedded processing solution.
The Blackfin Processor incorporates Digital Signal Processing capabilities and
microcontroller like features in an extremely power-efficient architecture. It provides a
low-power, unified processor architecture that can run operating systems while
simultaneously handling complex numeric processing tasks which makes it ideal for the
requirements of the Attitude Determination and Control systems.
Fig 5.1: ‘Embedded LabVIEW on Blackfin’ platform
51
The ‘Embedded LabVIEW on Blackfin’ platform provides several advantages.
The LabVIEW is a graphical programming language based on a block diagram approach.
This is very much similar to the MATLAB/Simulink platform that Aerospace students
are already familiar with. LabVIEW abstracts away the low level complexities of the
embedded system. The Virtual Instrument (VI) - analogue of a subroutine or an object in
some other programming languages - approach in LabVIEW provides an intuitive view
of the entire system, making programming and debugging several times faster. A lot of
the VI s for generic digital signal processing and microcontroller type functions are
generally provided by hardware manufactures as ready made black boxes that take in
certain inputs and provide the specified outputs.
Fig 5.2: LabVIEW Ready Made Virtual Instruments (VI s)
The Zmobile mixed signal board from Schmid Engineering AG, Switzerland was
chosen as the motherboard for the PurdueSat. Zmobile is an ultra low power mixed signal
mainboard powered by the Blackfin Processor (Zbrain BF533 core module) that would fit
into the CubeSat form factor. This board was a readily available Commercial Off The
Shelf (COTS) product with an affordable price tag that would fit into the CubeSat budget.
The company - Schmid Engineering AG - heavily supports Embedded LabVIEW
software development and they have agreed to provide software consultation for
PurdueSat. The Zmobile also provided a space saving Plug-In-Stack concept using a
52
proprietary Zbus connector which eliminated the need for wires when interfacing
additional boards.
Fig 5.3: The Zmobile Motherboard from Schmid Engineering AG
Fig 5.4: The Zmobile and Zbus Plug-In-Stack Concept
53
5.2.3 Architecture & Hardware Specification
Dual processor architecture was chosen for the Flight Computing System. This
would enable the high power Digital Signal Processor to be duty cycled only when the
complex numeric processing tasks are to be performed. A low power Host Computer
would keep running all the time and send wake up signals to the Digital Signal Processor
whenever its service is required. Inter-processor communication is established through a
UART link between the two computers. All house keeping functions will be handled by
the host computer and complex numeric processing tasks like those required by Attitude
Determination and Attitude Control Systems will be performed by the Digital Signal
processor. This approach would keep power consumption of the Flight Computing
System at a minimum.
A 32-bit ARM7 CPU running at 60 MHz - ‘Coridium ARMmite’ from Coridium
Corp., CA - was chosen to be the Host Computer. It has 8 10-bit Analog to Digital
converters (ADC s) onboard running at a 100 KHz sample rate and has an extremely
small form factor. The power consumption figure (250 mW) is low too. The Digital
Signal Processor on the Zmobile mentioned previously was a 16-bit computer running at
an aggressive 650 MHz. It had 4 14-bit ADC s running at 140 KHz sample rate.
Fig 5.5: The ARM Host Computer running at 60 MHz
54
Fig 5.6: The Blackfin DSP core module (onboard the Zmobile) running at 650 MHz
The architecture of the entire satellite system was designed as shown in figure 5.5.
The Flight Computing System forms the center of the architecture with each subsystem
having an appropriate type of link to it. The red wires represent an analog link interfacing
to the Analog to Digital converters (ADC s) onboard the Flight Computing System. The
wires with an arrow on both ends indicate a serial communication link (digital IO) of
some sort. The remaining wires represent general purpose digital input output lines. The
Communication System, the Power System and the Temperature sensors are connected to
the Flight Computing System through an I2C link. The 3-axis gyro unit is interfaced
through an SPI link. Two sun sensor units and the magnetometer board are connected to
the Flight Computing System through 3 analog channels each. The magnetometer has
higher resolution than the sun sensors and hence is connected to the 14-bit ADC s on the
Zmobile unit. The Zmobile has provision for onboard flash memory and that will serve as
the data storage unit for the satellite (like a Hard Disk Drive).
55
Fig 5.7: Architecture of the Entire Satellite System
56
5.2.4 Software System Design
The following were the software design requirements: A set of input actions were
to be performed, a set of output actions were to be performed, and Communications with
ground station was to be performed. All these had to be performed autonomously and
also in a periodic fashion. Input actions involved the reading of several different samples
like radiation samples, power samples, temperature samples etc. Output actions included
sending of torque coil control outputs, power control outputs etc. Communications
actions involved sending data and results to the ground station and receiving commands
from the ground station. The PurdueSat operations are illustrated in figure 5.8.
Fig. 5.8: Operational Requirements for the PurdueSat
57
The software architecture was designed with four main components - Device
Drivers, Applications, System Software, and Supporting Software. Device Drivers
are a set of software components that represent a mechanism to handle the low level
details of operating every hardware device onboard the satellite. Each device driver
directly interacts with a single hardware device completely abstracting away the details of
device operation. All device drivers provide a standard interface to the applications so
that the development of applications and device drivers can be independent of each other.
Applications are a group of software components that contain a mechanism to use the
hardware devices onboard at appropriate times. Operation of each hardware device would
be accomplished by the interaction of an application with one or more device drivers. A
particular application and the associated device drivers completely contain the software
segment of a particular satellite subsystem.
System Software is a mechanism for providing processing time to applications
based on the commanded status for each application. System software also provides an
inter-application communications mechanism enabling applications to affect the
operations of the other applications. System software should bring the software system
up to a preset configuration upon power-up and should launch and kill applications as
necessary. Supporting Software provides all the miscellaneous functionalities like event
logging, data storage in a custom file system, standard library functions etc. The entire
satellite software system can be represented as a hierarchical circle shown in figure 5.9.
The device drivers form the outermost ring which corresponds to the lowest level in the
hierarchy. The applications form the next level in the hierarchy. The functionalities get
abstracted away in moving closer to the center of the ring as can be seen from the figure
5.9.
58
Zbrain DSP
Driver
Zmobile ADC
Driver
ARM Processor
Driver
Zmobile SPI
Driver
Sun Sensor
Driver
Onboard ADC
Driver
Power
Driver
Gyro
Driver
Sun Sensor
Application
UART
Driver
Power Application
Gyro Application
Temperature
Driver
Magnetometer
Driver
Real Time
Clock
Driver
Magnetometer
Application
Temperature
Application
Startup Sequence
Application Manager
Housekeeping
Application
Torque Coil
Application
Torque Coil
Driver
Reset Module
Watchdog
Timer
Driver
Communication
Application
TNC
Driver
Att. Determination
Application
System Software
Payload
Application
Inter-processor
Comm. Driver
Att. Control
Application
Applications
Payload
Driver
Flash Memory
Driver
Device Drivers
OS Services
Libraries
Supporting
Software
Fig 5.9: PurdueSat Software System
59
5.3 Current Status
The Flight Computing System hardware design has been completed. The Digital
Signal Processor motherboard (Zmobile) has been procured from the sponsor. The ARM
host computer board has also been shipped. The primary computing platform –
‘Embedded LabVIEW on Blackfin’ has been tested by implementing a quaternion
multiplication algorithm and results have been verified. However, a bug was found in the
operation of Embedded LabVIEW which prevents the LabVIEW front panel window
from updating the current variable values in the debug configuration. This stalled further
implementations and performance analysis. National Instruments has been contacted in
order to find a solution.
A preliminary design of the software system for the dual processor architecture
has been completed as explained in the previous section. This design has been
implemented on a Windows platform to verify the feasibility of the design, by using
delay loops inside applications in place of computational algorithms. It has been verified
that the current software architecture can satisfy all the operational requirements of the
satellite.
5.4 Future Work
The problem with the debug mode in LabVIEW Embedded has to be addressed
before further progress in algorithm implementation can be made. Upgrading to the latest
version of LabVIEW might be a possible solution according to the consultant company Schmid Engineering AG.
Once the algorithms from the other subsystems are ready, they have to be
implemented in Embedded LabVIEW and tested on the Zmobile platform. The software
for the house keeping operations has to be implemented on the ARM Host Computer as
well.
60
5.5 References
[1] http://www.coridiumcorp.com/ARMmite.php
[2] http://www.cubesat.auc.dk/dokumenter/ADC-report.pdf
[3] http://cubesat.ece.uiuc.edu/Files/ACS_Bryan_Gregory_Thesis.pdf
[4] http://cubesat.ece.uiuc.edu/Files/thesis_dabrowski_050405.pdf
[5] http://www.zbrain.ch/en/default.php
61
6. Structure and Circuit Board Design
Author: Kautilya Vemulapalli
6.1 Software Used
To build the components of this satellite, two programs were used along with
Mathlab. CATIA was used to virtually build the parts and merge them to build the
satellite. ExpressPCB was the other program used. This software was used to design the
circuit board for the sun sensor board and the torque coil board.
6.2 Sun Sensor
6.2.1 Sun Sensor Box
The primary purpose of the sun sensor box is to keep the sun sensor safe and also
to avoid unwanted stray light from changing the readings. For this purpose, the box was
made with a certain minimum thickness so as to keep it structurally strong. A support was
also made so that the box could be securely fixed to the side of the satellite. A cap was
also added to close the box and hold the sensor inside. A conical hole was made on the
front side of the box such that the sun sensor could have 140 degree field of view. A
ledge was also made inside the box so as to keep a gap of 1.6mm between the sensor and
the box. Both the box and cap were made out of black plastic to minimize reflections.
The box was made with a thickness of 3mm and with the support having a thickness of
2mm. The cap was made 1mm thick and a hole was made in the cap for the wires from
the sun sensor to be brought out.
Figure 6.1: Sun Sensor Box and Cap
The box was tested with the sensor to check whether the dimensions used were sufficient.
The tests conducted were successful.
62
6.2.2 Sun Sensor Circuit Board
A circuit board was designed to analyze the data from the sun sensor. The board
design was changed multiple times until the required parameters were obtained and the
noise was removed. The schematic for the sun sensor board designed is shown in figure
6.2.
Figure 6.2: Sun Sensor Circuit Board
The board was designed using software called ExpressPCB based on the
schematic. Since space and weight are limited in the satellite, the board was designed
such that it can be made as small as possible. After multiple designs, 2 sun sensor circuits
were put on the same board to reduce the volume and mass taken up by the boards. The
board was designed such that the dimension would be same as those of the DSP board to
make stacking easier inside the satellite. The board was designed with certain circuit
board design requirements to reduce noise and errors. Figure 6.3 and figure 6.4 show the
board with the wiring and only with the component positions respectively.
63
Figure 6.3: Sun Sensor Circuit Board
Figure 6.4: Sun Sensor Circuit Board Component Positions
64
The power supply design was also setup on the sun sensor board but each sun sensor
circuit had its own power supply.
6.3 Torque Coils.
A prototype torque coil board was designed for the satellite. The board also acts
as the outer panel of the satellite. It holds the solar cells on the sides of the satellite. A
maximum of 31 coils could be set on each side of the board while leaving space for the
solar cells as shown in figure 6.5. The solar cells are to be place in a two by two
arrangement on the board on the inside of the coils allowing for a total of 16 solar cells.
The screw holes were setup such that they do not affect the coils or the solar panels. The
coils will be covered with an insulator to prevent short circuits when the board is fixed to
the crossbars.
Figure 6.5: Torque Coil Circuit Board
6.4 Satellite Structure
Computer models of the satellite were made to simplify the design stage and also
the construction of the satellite. The models help simulate the satellite long before any
physical model is built. Some of the satellite structures are based on the previous project
report and models. During this semester, the satellite was changed from a single cubesat
to a double cubesat. The maximum allowed dimension of a double cubesat according to
the CubeSat Design Specification are 227mm by 100mm by 100mm with a minimum of
75% rail and a maximum weight of 2kgs. The center of mass should also be located
65
within 2cm of the geometric center. The total length of the cubesat was made 224mm
from 100mm while the widths were kept at 100mm. The torque coil circuit boards are
used as the sides, top and bottom of the cubesat with the solar panels attached to it.
Initially, a gravity gradient boom was also designed to passively stabilize the
satellite while in orbit. The boom would be extended for stability once the satellite was
launched. After further analysis and controller analysis, the boom design was cancelled to
save mass, volume and also design the controller to be able to control the satellite without
it.
The previous design of the antenna deployment mechanism was used as the base
for designing the new one. Only one set of dipole antenna was installed for
communications. One sun sensor and the radiation detector were set up on opposite sides
of the antenna deployment system. The thickness of the deployment system was also
increased from 30mm to 32mm to be able to fit the sun sensor. This still satisfies the 75%
rail length criteria.
Figure 6.5: Torque Coil Circuit Board
The rails lengths were increase to 192mm and designed according to the design
specifications with a 7mm extension at the top and bottom. Holes on the rails were put in
depending on the locations of the four cross bars for each side of the cubesat. Even
though the rails are the primary structural support, the cross bars keep the structure intact
and from twisting. The holes that are drilled into the cross bars are used to support the
66
internal components. Thus the cross bars have been made with a minimum thickness of
1mm.
Figure 6.6: Cross Bar and Rail
The components and the circuit boards were modeled as accurately as possible
and with data presently known. Figure 6.7 shows the model of the Zmobile (DSP) board
made for estimating inertia.
Figure 6.7: Zmobile Board
The mass of the total satellite was presently estimated at 0.471kg and the inertia were
estimated to be
I1 = 2.661 gm/m2,
I2 = 2.163 gm/m2,
I3 = 1.524 gm/m2.
These values are not accurate but come close to the values from the mathlab analysis
done for the given mass. Knowing the exact weights and materials the components are
made of will help in obtaining the inertia and mass estimates more accurately. Also some
67
of the boards have to be better modeled due lack of information on them at present.
Figure 6.8 and figure 6.9 show the satellite with the components in it.
Figure 6.8: CubeSat
Figure 6.9: CubeSat Internal Components
The components inside the satellite were arranged such that center of mass is within
20mm of the geometric center. The model was found to have the center of mass at 2.8mm
along x-axis, 2.1mm along y-axis and 8.3mm along the z-axis from the geometric center.
The z axis is along the satellite axis, y-axis is along the antennas and x-axis completes the
coordinate system.
6.5 Future Work
The satellite model can be further improved and the inertia calculated more accurately
when the specifications of the new components are found. The center of mass can also be
moved closer to the geometric center by moving the components around.
68
6.6 References
[1] www.expresspcb.com
[2] http://www.smps.us/pcb-design.html
[3] Catia books from CGT 163 and CGT 226
[4] Toorian, Armen, “CubeSat Design Specification (CDS) Revision 9”, 2005
[5] ExpressPCB drawings
[6] Catia models created
6.7 Appendix
Inertia and center of gravity estimation code:
clear;clc
%EARTH
G = 6.67*10^-11;
R = (6378.1 + 700)*10^3;
me = 5.9742*10^24;
%TOTAL MASS
mt = 0.471;
%ANTENA1
l1 = 0.4064;
ms1 = 7860*(l1)*1/100*0.15/1000; %mass = density*length*width*thickness
%ANTENA2
l2 = 0; %0.4064;
ms2 = 7860*(l2)*1/100*0.15/1000; %mass = density*length*width*thickness
%GRAVITY GRADIENT BOOM WT
%mw = [0.05:0.01:0.2];
69
mw = 0; %[0:0.025:1];
%mw = sym('mw', 'real');
lw = 0; %[0:0.25:5];
%lw = sym('lw', 'real');
%GRAVITY GRADIENT BOOM
lggb = lw;
mb = 7860*(lggb)*0.15/1000*1/100;
%SATELLITE
a = 224/1000;
b = 100/1000;
ml = mt - 2.*ms1 - 2.*ms2 - mw - mb;
%TRANSFORMATION MATRIX
%alpha = 45 %deg
alpha = sym('alpha','real'); %deg
tm = [cosd(alpha) -sind(alpha) 0; sind(alpha) cosd(alpha) 0; 0 0 1];
%INERTIA MATRIX
ib11 = ml./6.*(b.^2) + 2.* ms1.*(1./12.*l1.^2 + 1./4.*(l1).^2) + 2.* ms2.*(1./12.*l2.^2 +
1./4.*(l2).^2);
ib22 = ml./12.*(a.^2 + b.^2) + 2.*ms2.*(1./12.*l2.^2 + 1./4*((l2).^2 + a.^2)) + mw.*(lw
+ a./2).^2 + mb.*(1./12.*lggb.^2 + 1./4.*((lggb).^2 + a.^2));
ib33 = ml./12.*(a.^2 + b.^2) + 2.*ms1.*(1./12.*l1.^2 + 1./4*((l1).^2 + a.^2)) + mw.*(lw
+ a./2).^2 + mb.*(1./12.*lggb.^2 + 1./4.*((lggb).^2 + a.^2));
ib = [ib11 0 0; 0 ib22 0; 0 0 ib33]
%ia = tm'*ib*tm;
%i11 = ia(1,1); i12 = ia(1,2); i13 = ia(1,3)
70
%i22 = ia(2,2); i21 = ia(2,1); i23 = ia(2,3)
%i33 = ia(3,3); i32 = ia(3,2); i31 = ia(3,1)
format long
%f2 = 1/(mt*R^2)*(3/2*(i22 + i33 + i11 - 5))
%f2 = 1./(mt.*R.^2).*(3./2.*(ib(2,2) + ib(3,3) - 2.*ib(1,1)))
f2 = 1./(mt.*R.^2).*(3./2.*(ib22 + ib33 - 2.*ib11))
F = -G.*me.*mt./R.^2.*(1 + f2)
Rcg = (R.^2./(1 + f2)).^0.5
x = R - Rcg
format short
71
7. Conclusion
Author: Paul Moonjelly
The objectives for the semester were achieved as listed below:
Dynamics and Control:
Attitude Estimation algorithms were surveyed a suitable one was implemented.
The choice of sensor combination finalized and the Attitude Determination System
preliminary design has been completed. The in-house design and development of sun
sensor has been completed. A control algorithm for non spinning case was developed and
implemented. A 3-axis gyro (ADIS16350) for rate feed back to the controller was chosen
(and the manufacturer was contacted) as the need was recognized during the course of the
development of the control algorithm.
Propulsion:
The feasibility of in-house developed Electric Propulsion to PurdueSat was
studied and was decided to be infeasible at this point since the in-house technology was
not ready to be flown. Hence magnetic torque coils were chosen as the actuator and its
design has been completed.
Structures:
The entire satellite (including the Printed Circuit Boards for each subsystem) was
modeled in CATIA and the inertia parameters and the location of center of mass has been
calculated. The satellite structure was fabricated in the machine shop as well. The Printed
Circuit Board designs for the sun sensor and magnetic torque coils (forming the satellite
outer wall) were also completed.
Computer & Electronics:
The Flight Computing System hardware design has been completed and the
hardware was procured from the sponsor. The primary computing platform – ‘Embedded
LabVIEW on Blackfin’ has been tested. A preliminary design of the software system for
the dual processor architecture was completed and has been implemented on a Windows
platform to verify the design feasibility. The Battery & Power Conditioning Board was
chosen and has been ordered.
72
Thus the PurdueSat Senior Design was successful in revamping the design of the
PurdueSat and accelerating the development of PurdueSat several folds over the course of
one semester (The future work corresponding to each subsystem has been addressed in
the last section of each chapter).
73