LEONIDAS Critical Design Report
LEONIDAS Critical Design Report
Andy Chen
Bas Uytterhoeven-Spark
Michel Fathallah
Ann Zhou
Arash Mahmoudzadeh
Boris Chen
Harry Steel
Rupinder Kaur
Simon Thomas
Jeshua Morrissey
Shreyash Annapureddy
Trevor Wang
October 10, 2014
CubeSat Name / Number
Lead Institute
LEONIDAS (Low Earth Orbit Network Image and Data Acquisition System)
The University of Sydney
Michel Fathallah ([email protected])
Contact Person(s)
Jeshua Morrissey ([email protected])
Harrison Steel ([email protected])
CubeSat Unit
Science Payload
Other Payload
Independent Reviewer
2U
1x Multi-Needle Langmuir Probe
1x Camera and LCD Display
Name — Signature — Date Signed — Contact Info
1
Contents
1 System Overview
7
2 Payload Design
2.1 Multi-Needle Langmuir Probe (MNLP) Instrument
2.1.1 Scientific Justification . . . . . . . . . . . .
2.1.2 Technical Description . . . . . . . . . . . .
2.2 Selfie Camera and LCD Screen . . . . . . . . . . .
2.3 Open Data Platform . . . . . . . . . . . . . . . . .
3 Structural Subsytem
3.1 Selected Structures . . . . . . .
3.2 CAD Drawings . . . . . . . . .
3.3 Component Integration . . . .
3.4 Camera Boom Design . . . . .
3.5 Finite Element Analysis . . . .
3.6 LEONIDAS Moments of Inertia
3.7 Mass Balance Summary . . . .
3.7.1 Contingency Masses . .
Specifications
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
12
12
12
13
17
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18
19
20
21
22
22
25
26
26
Subsystem (ADCS)
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
29
29
30
32
32
32
33
37
37
38
40
41
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
42
42
43
43
47
48
49
49
50
50
50
51
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
and Center of Mass
. . . . . . . . . . . .
. . . . . . . . . . . .
4 Attitude Determination and Control
4.1 ADCS Components . . . . . . . . . .
4.1.1 Magnetorquers . . . . . . . .
4.1.2 Sun Sensors . . . . . . . . . .
4.1.3 Motor Driver . . . . . . . . .
4.1.4 IMU . . . . . . . . . . . . . .
4.1.5 GPS . . . . . . . . . . . . . .
4.2 ADCS Single Axis Control . . . . . .
4.3 ADCS 3-Axis Control . . . . . . . .
4.3.1 Frames of Reference . . . . .
4.3.2 Dynamic State-Space Model .
4.3.3 Aerodynamic Drag . . . . . .
4.3.4 Simulation . . . . . . . . . .
.
.
.
.
.
5 Electrical Subsystem
5.1 Initial Design . . . . . . . . . . . . . . . . . . .
5.2 Proposed Design (Prototype) . . . . . . . . . .
5.3 MOSFET Switch Circuit . . . . . . . . . . . . .
5.4 Circuit Design . . . . . . . . . . . . . . . . . .
5.4.1 Circuit Design Simulation Results . . .
5.5 Power Draw/Consumption . . . . . . . . . . . .
5.5.1 OBC (On Board Computer) . . . . . . .
5.5.2 Langmuir Probe (Primary Payload) . .
5.5.3 IMU (Inertial Mass measurement Unit)
5.5.4 GPS . . . . . . . . . . . . . . . . . . . .
5.5.5 Photodiodes (Sun Sensors) . . . . . . .
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5.6
5.5.6 Magnetorquers .
5.5.7 Motor Controller
5.5.8 ArduCam . . . .
5.5.9 Transceivers (RX
Battery Selection . . . .
. . . . . .
. . . . . .
. . . . . .
and TX)
. . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
51
51
52
52
52
6 On-Board Computer and On-Board Computer Data Handling Subsystem
54
6.1 Modes of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2 State Transition Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7 Communication Subsystem
7.1 System Design . . . . . .
7.2 Components . . . . . . . .
7.3 Ground Station . . . . . .
7.4 Subsystem Development .
7.5 Commands . . . . . . . .
7.5.1 User Commands .
7.5.2 System Commands
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
60
60
60
62
62
63
63
64
8 Thermal Control Subsystem
8.1 Proposed Thermal Protection . . . . . . . .
8.2 The Thermal Environment . . . . . . . . .
8.3 Thermal Analysis Outline . . . . . . . . . .
8.4 Thermal Inertia of the Satellite . . . . . . .
8.5 Heat Balance for the Satellite (Main Node)
8.6 Heat Balance for Battery (Second Node) . .
8.7 Heat Generation within the satellite . . . .
8.8 Radiative Transfer Terms . . . . . . . . . .
8.8.1 Solar Flux . . . . . . . . . . . . . . .
8.8.2 Albedo Flux . . . . . . . . . . . . .
8.8.3 Earth Infrared Flux . . . . . . . . .
8.8.4 Radiated Heat away from Satellite .
8.9 Numerical Model . . . . . . . . . . . . . . .
8.10 Results . . . . . . . . . . . . . . . . . . . . .
8.11 Conclusions on Thermal Design . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
66
66
66
66
67
68
68
69
69
69
70
70
71
71
71
72
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9 References and Published Papers / Presentations
74
Appendices
76
A Structural Design
76
B OBC and Data Handling Subsystem
83
C Thermal Control Subsystem
92
C.1 Mean Emissivities and Absorptivities . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
C.2 Presented area of spacecraft to radiation . . . . . . . . . . . . . . . . . . . . . . . . . 92
3
List of Figures
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
3D rendering of the completed LEONIDAS. . . . . . . . . . . . . . . . . . . . . . . .
High-level interactions between the different subsystems. . . . . . . . . . . . . . . . .
Instrument in stowed configuration (left) and deployed operational mode (right).[7]
Size and location of Langmuir probes (here folded along satellites side for launch)
and DAQ PCB board.[15] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ArduCam System. A) Arducam LCD Screen performing display, processing, and
storage of images. B) OV2640 Camera utilised on LEONIDAS[23]. . . . . . . . . . .
Camera boom and mounting. The Camera mount is designed to align the corner of
the cameras field of view with the LCD screen such that the maximum amount of
the earth is visible in the background. . . . . . . . . . . . . . . . . . . . . . . . . . .
Camera, Boom, and LCD screen during operation. . . . . . . . . . . . . . . . . . . .
Camera field of view, showing LCD screen including volunteer picture and USYD
Logo, and the earth at night. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Structural design progression for LEONIDAS. . . . . . . . . . . . . . . . . . . . . . .
Structure D. A) Detail of Boom mounting point and perspective view of structure,
B) Side view of structure demonstrating LCD mounting panel in lower half, C) Top
plate view demonstrating holes comply with QB50 hatch requirements. . . . . . . . .
Structure C. A) Perspective view of side sheets, B) Side view of structure demonstrating LCD mounting position in lower half. C) Cross sectional view of structure,
showing room for PC104 Boards . D) Top/Bottom plate. . . . . . . . . . . . . . . .
FEA Analysis of Von Mises equivalent Yield stress under static loading during takeoff for Structure A (Aluminium 1), Structure C (Aluminum 2) and Structure D
(Nylon and VeroWhite). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
FEA Analysis of total deformation under static loading during take-off for Structure
A and C (Aluminium) and Structure D (Nylon and VeroWhite) . . . . . . . . . . . .
FEA Analysis of axial (z direction) equivalent stress under random vibration conditions during take-off for Structure A and C (Aluminium) and Structure D (Nylon
and VeroWhite) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
LEONIDAS Assembly Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Copper spinning tool used to create the magnetorquers. . . . . . . . . . . . . . . . .
Copper spinning tool used to create the magnetorquers. . . . . . . . . . . . . . . . .
Motor driver used to run the magnetorquers. . . . . . . . . . . . . . . . . . . . . . .
Custom magnetorquer created for the LEONIDAS. . . . . . . . . . . . . . . . . . . .
PID controller block diagram, developed using MATLAB. . . . . . . . . . . . . . . .
Controller’s response to a step input of π/2 radians. . . . . . . . . . . . . . . . . . .
Satellite’s angular velocity in the x axis during de-tumbling. . . . . . . . . . . . . . .
Earth Centred Inertial Reference System[5] . . . . . . . . . . . . . . . . . . . . . . .
Orbital Reference System[5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PID simulation results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Initial power system design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Initial power system design flaw[10]. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Basic proposed power system design. . . . . . . . . . . . . . . . . . . . . . . . . . . .
MOSFET Switching Circuit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MOSFET Switching Circuit connected to the Solar Panels. . . . . . . . . . . . . . .
4
7
9
12
13
14
15
16
16
18
20
21
22
23
24
25
29
30
32
34
35
35
36
37
38
41
42
42
43
43
44
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
MOSFET design with 9V provided to the power control switches. . . . . . . . . . . .
MOSFET design with 9V provided to the power control switches simulation. . . . .
MOSFET design with 9V provided to the power control switches in the OFF configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MOSFET design with 9V provided to the power control switches in the OFF configuration simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Final Circuit Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Circuit Simulation causing battery 1 to discharge. . . . . . . . . . . . . . . . . . . .
Circuit Simulation causing battery 2 to discharge. . . . . . . . . . . . . . . . . . . .
Pin assignments for the PC/104 stack . . . . . . . . . . . . . . . . . . . . . . . . . .
State transition diagram of the LEONIDAS satellite . . . . . . . . . . . . . . . . . .
Picture of the XBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RFM22B Breakout Board [22] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Some sources of heat transfer, path of or orbit in sun (green) and eclipse (red), and
coordinate axes used in orbital model. . . . . . . . . . . . . . . . . . . . . . . . . . .
Radiation collected by satellite over two orbits, with orbital angle defined as in Figure
42. Albedo and Solar radiation are seen to drop to zero in the earth’s shadow, whilst
IR radiation and satellite internal heat generation are constant throughout. . . . . .
Thermal fluctuations of satellite over two orbits. . . . . . . . . . . . . . . . . . . . .
Side sheet to be cut for Structure C. . . . . . . . . . . . . . . . . . . . . . . . . . . .
More views of side sheet to be cut for Structure C. . . . . . . . . . . . . . . . . . . .
Top sheet to be cut for Structure C. . . . . . . . . . . . . . . . . . . . . . . . . . . .
More views of top sheet to be cut for Structure C. . . . . . . . . . . . . . . . . . . .
Assembly drawings of Structure D. Dimensions on top/bottom face demonstrate
access-hatch requirements are satisfied. . . . . . . . . . . . . . . . . . . . . . . . . . .
Assembly drawings of Structure D. Section A-A demonstrates interior view, made to
fit PC104 form-factor. Detail C section shows the boom-mounting support. . . . . .
ADCS Board. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ADCS PCB Schematic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Communications Board. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Communications PCB Schematic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Iduino Due Board. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Iduino Due PCB Schematic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Power Board. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Power PCB Schematic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Area presented to heat flux at different satellite orientations. . . . . . . . . . . . . .
45
45
46
46
47
48
49
55
58
61
62
67
71
72
77
78
79
80
81
82
84
85
86
87
88
89
90
91
93
List of Tables
1
2
3
4
5
List of Components used within the LEONIDAS. . . . . . .
Main physical properties of materials. . . . . . . . . . . . .
Resonant Frequencies of Structure D made from VeroWhite.
minimum. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cost and strength of each material. . . . . . . . . . . . . . .
Centre of mass for LEONIDAS (mm) . . . . . . . . . . . .
5
. .
. .
All
. .
. .
. .
. . . . . . . .
. . . . . . . .
are above the
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . .
. . . .
90Hz
. . . .
. . . .
. . . .
11
23
24
25
26
6
7
8
9
10
11
12
13
14
15
Moments of Inertia for LEONIDAS (g · mm−2 ) at centre
Summary of the Mass Budget in Annex 1. . . . . . . . .
GPS Specifications. . . . . . . . . . . . . . . . . . . . . .
Other ADCS components specifications. . . . . . . . . .
Modes of Operation . . . . . . . . . . . . . . . . . . . .
Commands available to the user. . . . . . . . . . . . . .
System Commands . . . . . . . . . . . . . . . . . . . . .
Thermal Inertia of the Satellite. . . . . . . . . . . . . . .
Heat generated within the satellite. . . . . . . . . . . . .
Surface properties of different Satellite faces. . . . . . .
6
of mass
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
26
28
33
33
59
64
65
68
69
92
1
System Overview
This document outlines the design and preliminary implementation of a complete, low cost 2U
CubeSat prototype over a 10 week period. The CubeSat is called LEONIDAS (Low Earth Orbit
Network, Image and Data Acquisition Satellite). This sub-$1000 CubeSat has 3 functional goals.
The first is to use a Multi-Needle Langmuir Probe to map F-region plasma turbulence, which
is relevant to the disruption of communication and GNSS signals. The second is to provide a
photography service which allows the upload of an image to the on-board digital display after
which a picture is taken with the Earth as the image’s backdrop with the goal of generating interest
among teenagers and young adults in astronomy and space technologies. The third is to provide
an open data platform in which data gathered on all the satellite sensors would be published online
regularly for academics, students and other organisations to use. To minimise costs, a number
of components where designed in-house and utilised rapid prototyping methodologies such as the
3D printing. This document also outlines the development of the ADCS, power, communications,
structure, payload and on-board computer subsystems. The CubeSat functionality and design were
simulated and tested throughout the implementation with results indicating the prototype design
is ready for space-grade development.
Figure 1: 3D rendering of the completed LEONIDAS.
The following pages contain a list of components used during development of LEONIDAS. Most
of the table should be self-explanatory, but the following Technical Readiness Levels (TRL) were
used:
1. TRL 1: Basic principles observed and reported
2. TRL 2: Technology concept and/or application formulated
3. TRL 3: Analytical & experimental critical function and/or characteristic proof-of-concept
4. TRL 4: Component and/or breadboard validation in laboratory environment
5. TRL 5: Component and/or breadboard validation in relevant environment
7
6. TRL 6: System/subsystem model or prototype demonstration in a relevant environment
(ground or space)
7. TRL 7: System prototype demonstration in a space environment
8. TRL 8: Actual system completed and ”Flight qualified” through test and demonstration
(ground or space)
9. TRL 9: Actual system ”Flight proven” through successful mission operations
8
Figure 2: High-level interactions between the different subsystems.
9
OBC
Name
Details
Manuf.
TRL
Qty
Price
Interface
1
1
$30
–
Iduino Due Pro
Arduino Due Compatible Board, 84 MHz, 32-bit,
ARM Cortex M3, Atmel SAM3X8E
Iduino
9
PCBs
Real Time Clock
4x PC/104 Standard PCBs
DS3231 AT24C32 Reat Time Clock
BEC
Generic
5
4
4
1
$126
$5
PC/104
I2C
Manuf.
TRL
ADCS
Name
GPS Breakout
Details
Qty
Price
Interface
2
1
$35
Serial
66 satellites, 10 Hz, 3m accuracy
Adafruit
4
10-DOF IMU Breakout
Accelerometer, gyroscope, magnetometer, barometer
Adafruit
4
1
$55
I2C
Sun Sensors
TAOS TSL260R-LF 940nm Photodetector Amplifier
SMT Package
TAOS
4
5
$20
ADC
Sparkfun
4
2
$20
GPIO/PWM
N/A
4
3
In-house
Manuf.
TRL
Qty
Price
Interface
Pololu
5
1
$15
–
Motor Controllers
Magnetorquers
Dual 1A TB6612FNG
In-house: 300 turns, 58ohm, 20g
10
Power
Name
5V Buck/Boost Regulator
3.3V Buck/Boost Regulator
Details
S7V8A, 2A maximum peak current
Pololu
5
1
$5
–
SW-008 0.8W Solar Panels
Miniisw
5
8
$40
–
Batteries
3.7V, 2500mAh Lithium Ion Polymer Batteries
Adafruit
4
2
$30
–
Battery Charge Regulator
USB/DC/Solar Lithium Ion Polymer Charger
Adafruit
4
1
$20
–
Solar Panels
1 ArduSat
2 Limit
for example
of 40km altitude
S18V20F5, 1A maximum peak current
Communications
Name
Antenna
Details
Tape Measure
Manuf.
TRL
Qty
Price
Interface
Kmart
7
1
$7
SMA
Antenna Adapter
SMA to uFL/u.FL/IPX/IPEX RF Adapter Cable
Adafruit
5
1
$5
XBee Adapter Kit
Onboard regulator, logic level shifting
Adafruit
4
1
$10
0.1” pins
Downlink Transceiver
RFM22B-S2 RD Transceiver Breakout, 433MHz, 256kpbs,
FSK, GFSK, and OOK modulation
Sparkfun
4
1
$25
SPI
Uplink Transceiver
XBee Pro 60mW u.FL connection, Series 1, WRL-08710
XBee
4
1
$55
Serial
Manuf.
TRL
Qty
Price
Interface
ArduCAM
4
1
$55
Payload
Name
Details
ArduCAM Shield:
11
Camera
160x120 to 1600x1200 resolution
Omnivision
–
–
I2C
Display
3.2” QVGA, 320x240 resolution, 168KB GDDRAM
ArduCAM
–
–
I2C
MicroSD card interface
ArduCAM
–
–
SPI
SanDisk
4
1
$6
Adafruit
4
1
$10
I2C
Manuf.
TRL
Qty
Price
Interface
N/A
4
1
In-house
Total
$574
SD card interface
8GB SD Card
Light Sensor
Digital UV Index, IR, Visible Light
Structure
Name
Structure
Details
3D Printed with Objet Eden 260V - VeroWhite Nylon
Plastic
Table 1: List of Components used within the LEONIDAS.
2
Payload Design
2.1
Multi-Needle Langmuir Probe (MNLP) Instrument Specifications
Figure 3: Instrument in stowed configuration (left) and deployed operational mode (right).[7]
2.1.1
Scientific Justification
The MNLP instrument, designed at the University of Oslo, provides absolute electron density
measurements at approximately 1 m spatial resolution, for optimised for orbits approximately 300
km as in the QB50 mission. These measurements can map F-region plasma turbulence, which are
particularly relevant due to their disruption of communication and GNSS signals that must pass
through the area, particularly in polar and equatorial regions. The probes are designed to detect
electron densities between 108 m−3 and 1012 m−3 , the anticipated range at this altitude, with this
range adjustable in design should the probes be used in different conditions. Sampling is possible
at up to 7kHz, and this can be changed in-flight by uploadable commands.
2.1.2
Technical Description
The MNLP consists of four probes of length approximately 200 mm (See Figure 4 for details).
They are folded along the sides of the CubeSat during launch, and are spring loaded to deploy once
the satellite is released into orbit (deployed configuration demonstrated in Figure 3, for further
visualisation see Assembly Integration and Test Plan). The probes are designed to optimally be
on the end of the CubeSat facing direction of flight, which is specified in the QB50 requirement
documents.
In addition to the probes attached to the end of the satellite, there is a DAQ PCB (80.00 ×
82.60 mm) which will be adapted to PC104 standard size. This board takes up less than 2 cm of
space within the satellite (Figure 4).
Probe Mass
Probe power consumption
225g, 20% margin[1]
400 mW (Standby) 900 (Complete Science Mode) mW[1]
12
The probe measures currents over an in-flight adjustable range of 1 nA and 1 A, which is filtered
and amplified before A/D conversion. Probes are calibrated pre-flight, then calibrated regularly
(i.e. once weekly) in-flight via voltage sweeps on all probes to account for effects such as probe
contamination. Processing is done by the probe’s PCB which selects data depending on operational
mode and performs time tagging. The instrument requires input data over the I2C bus indicating
a) Selection of which operational mode to use and b) DNEL signal to ensure appropriate storing of
measurement data before system power down.
Data output and downlink can be done in three operational modes, processed and outputted as
requested from the instrument:
• Complete scientific coverage mode (1.25 MB/orbit)
• Partial scientific coverage mode (312.5 kB/orbit)
• Irregularity survey mode (8.6 kB/orbit)
Figure 4: Size and location of Langmuir probes (here folded along satellites side for launch) and
DAQ PCB board.[15]
2.2
Selfie Camera and LCD Screen
The second payload will be a selfie service called Spacestagram. Customers from around the globe
will be able to send in pictures that will be uploaded to the CubeSat. Once there they will be
13
displayed on LEONIDAS’s externally mounted LCD display and a camera that points towards the
screen with the earth behind it as a backdrop snaps a selfie.
The LCD screen chosen is based on the ArduCam, a Camera/LCD package designed to work
with Arduino. The screen is 9.5cm diagonally, and via Arduino control (It communicates with
the OBC via I2C and SPI) can be switched on for short periods of time when photos are being
taken, such that usually there will be negligible power consumption. The screen includes a MicroSD
card reader which is used as storage for pictures taken when downlink is not available. Images are
compressed by the LCD/Camera system to jpg format and cropped, LEONIDAS default size being
612 × 612 px (the minimum required for Instagram), which leaves them at approximately 17 kb,
appropriately small for download.
The camera chosen is the OV2640 camera module, a 2 megapixel camera widely used in robotics
due to its small size, mass, and power consumption, that communicates with the Arducam LCD via
24-pin FPC cable. It has a field of view of approximately 40 degrees in each direction, from which
we can design a boom system to allow the camera to see all of the LCD screen, and a substantial
part of the Earth behind.
Figure 5: ArduCam System. A) Arducam LCD Screen performing display, processing, and storage
of images. B) OV2640 Camera utilised on LEONIDAS[23].
In order to have sufficient field of view to capture both the LCD screen and the earth background
we calculate a boom length of at least 15cm is required, and as described in Section 3 of this report
use a steel ruler for its creation, which would be folded (with the flexible FPC cable) into the side
14
of the craft for launch. A camera mount is 3D printed to operate with the given field of view, and
orients the camera to place the LCD in the bottom corner of the view frame.
Figure 6: Camera boom and mounting. The Camera mount is designed to align the corner of the
cameras field of view with the LCD screen such that the maximum amount of the earth is visible
in the background.
From this perspective the cameras field of view is approximately filled half by the LCD screen,
and half by the background of the earth / deep space. An additional benefit of substantial boom
length is that both the near picture and distant earth can be relatively well in focus, and this focusing
could be improved substantially via custom optics prior to launch. As a substantial portion of the
earth is in view the system can be used gainfully even without LCD screen operation as an orbital
imaging platform.
The boom deployment follows that of the Langmuir probes and antennae in order to avoid
interference. From then the camera remains in place. It is however, along with the screen, powered
down for most of the orbit and only activated for short 30 second bursts for imaging. When this
takes place the satellite rotates about its Z axis (direction of flight) to bring the desired background
(earth or deep-space) into view, takes all photos required (storing them on the MicroSD card), and
downlinks to earth once in view of the ground station. As well as the charge for the service of
providing a space selfie, additional avenues of operation to be pursued include the possibility of
including advertising in images (Such as the USYD logo in Figures 7 and 8) which could finance
ongoing operations of the satellite, or simply provide good publicity for the University of Sydney
15
and its faculty.
Figure 7: Camera, Boom, and LCD screen during operation.
Figure 8: Camera field of view, showing LCD screen including volunteer picture and USYD Logo,
and the earth at night.
16
2.3
Open Data Platform
The CubeSat would also serve as an open data platform. All of the information gathered on the
satellite itself would be transmitted back down, and published regularly online. This includes
information from sensors such as accelerometers, gyroscopes, magnetometers, UV sensors and light
sensors. We would hope that researchers and hobbyists would use this information. For example, a
group from Stanford is looking at predicting earthquakes by changes in the Earth’s magnetic field
from Low Earth Orbit. Our magnetometer would be able to provide some data they require for
their analysis.
As our satellite is based on the open-source Arduino processing system, with the easy to learn
C++ style Wiring language (being taught in many High-Schools), it can also function as a test-bed
for student programmers. This was an approach pursued by the recent ArduSat project, which
raised more than $100,000 US on Kickstarter[26] and was launched in 2013. Programs for data
collection, analysis and control could be uploaded by students from around the world, allowing them
to experience real programming in action. Whilst the satellite must remain within the bounds of
QB50 limitations, this still allows a lot of room for student experimentation. For example, students
could design a Magnetorquer attitude control algorithm about the Z axis (direction of flight, which
we are free to rotate about) and test it in a real situation!
17
3
Structural Subsytem
CubeSat structural designs face a number of engineering challenges, namely their tightly constrained
dimensions, large vibrational and load bearing requirements, and resistance to thermal fluctuations
and radiation degradation. As such, the fundamental designs utilised in most CubeSats have converged to virtual uniformity; the structure is made of space-grade Aluminium, exterior dimensions
comply with CubeSat launch standards, and internal dimensions are designed to accommodate the
PC-104 form-factor. In addition to these specifications, the QB50 mission requires kill switches
to disable internal systems during launch, and the entire top face (and 3̃cm of the internal space)
be made available for the m-NLP, all of which will be accommodated in our designs. QB50 Requirements dictate that the satellite can only be accessed via two hatches on the bottom face after
integration into the launch vehicle, however this can be done via a cable attached to the exterior of
the solar panel: holes in the bottom structural face need not exist or comply to the size requirements
unless desired.
For prototyping purposes, a number of structures (allowing different manufacturing approaches)
were considered, depicted in Figure 9. Structures A and B are based on standard industry with
substantial modification, whilst C and D have been created solely for LEONIDAS.
Figure 9: Structural design progression for LEONIDAS.
Structure
Manufacturing Technique
A
Aluminium (6061)
CNC
Nut/Bolt or Riveting
250 gram
B
Aluminium (6061)
CNC
Nut/Bolt
170 gram
C
Aluminium (6061) Sheet Metal
Laser-cut sheet metal and bending
Nut/Bolt
195 gram
D
VeroWhite (or Nylon)
3D Printed
Glue + Nut/Bolt
145 gram
18
Structural Fasteners
Mass1
Material
Structure A is based on that from Pumpkin Cubesat with a number of modifications, such as
splitting the structure into four side pieces (rather than one piece which would require bending),
enlarging holes on the top face so as to accommodate access requirements, and altering the asymmetrical side face from the original, which is designed to interface with Pumpkin CubeSats own
PCB boards. Face material thicknesses are 1.27 mm, and the (original) design has significant flight
heritage.
Structure B is based on that from the Cubesat shop (as such it also has significant flight heritage), and can be broken down into ten pieces (two side supports and 8 cross-beams). Little
modification was required as access areas and other integration factors already comply with QB50
requirements. Structural members are thicker than design A to compensate for the lack of crosssupports to some extent, however overall mass is still substantially lower.
Structure C is an original design, optimised for manufacture via laser cutting of Aluminium
sheet metal. As such, all parts of the structure are 1.5mm thick, and it is broken down into three
pieces (top and bottom faces, and one side face). Once cut the pieces can be bent into shape, the
side piece being bent to form the square external profile, and attaching tabs on end faces bent
down into position. This structure does away with much of the complexity, as manufacturers have
said previous designs have been very ambitions considering the time frame, and strength gains due
to increased structural thickness (over design A) may make up for the lack of cross-supports to
some extent. This structure has also been optimised for our particular mission, with holes being
inserted in appropriate places to attach our chosen solar panels, and one asymmetric face designed
to accommodate our LCD screen payload.
Structure D is also original, and is optimised for production via 3D printing. Current prototypes
are made of VeroWhite, a cheap 3D printing plastic, however this may be produced from Nylon
variants due to their superior material properties in the future.
The structure is essentially the same as structure C in terms of fastener placement and material
thickness, however cross-supports have been added to most faces as complexity is no issue for 3D
printing. Cross supports follow a similar design to Structure A, however they have been thickened
substantially to increase strength (allowable as the material is substantially lower density). One
part of the asymmetric face is left without supports for integration of the LCD screen payload, and
an inward-facing support is included for attaching the camera boom (See Figure 3 b). The structure
is optimised to locate the centre of mass close to the geometric centre, and minimise moments of
inertia. Whilst final designs would be printed in two pieces (Side and bottom faces connected, and
a separate top face), our prototype is split onto six pieces (top and bottom faces, four side faces)
in order to save material costs and printing time. This structure is significantly lighter than the
other designs, due to the plastic used having less than half the density of Aluminium, however
its load bearing and thermal/radiation resistance properties remain to be established. For more
visualisation of the structure see assembly plan.
3.1
Selected Structures
We have elected to produce two structures, and will be running tests on them concurrently. Those
selected are Structure C, made from Aluminium sheet metal, and Structure D, made from Verowhite.
1 Including
Structural Fasteners
19
As the most easily available means of production is 3D printing we chose to create Structure
D, and printed it from VeroWhite using the University of Sydney Engineering Faculty 3D printers.
This provides most of the structural capabilities required, however CubeSat requirements dictate
anodised Aluminium side-rails must be employed on all space craft. Therefore, our structure would
not comply with this CubeSat requirement, but due to manufacturing processes available it is as
close as we can get at the present time with the presented time restrictions. Further investigations
will look into the possibility of using a combination plastic/Aluminium structure. Additionally,
CubeSat requirements dictate that if the structure is not made out of certain Aluminium alloys a
DAR form must be submitted and the waiver process adhered to in order for the structure to be
qualified for launch. As this structure is 3D printed CAD Drawings are not needed, since modelled
files go straight to printer. An overview of the structure is seen in Figure 10, whilst more detailed
diagrams are located in the appendix.
A superior manufacturing technique, when available, is laser cutting of Aluminium sheet to
produce Structure C. This provides better strength performance, whilst fulfilling all CubeSat
requirements. An overview of this structure is pictured in Figure 11, whilst more detailed CAD
Drawings for this structure, demonstrating that it can be fashioned from a single piece of 1.5mm
thickness Aluminium and then bent into shape, are located in the appendix. This design was
submitted to a Chinese fabrication company for production.
Figure 10: Structure D. A) Detail of Boom mounting point and perspective view of structure,
B) Side view of structure demonstrating LCD mounting panel in lower half, C) Top plate view
demonstrating holes comply with QB50 hatch requirements.
3.2
CAD Drawings
Appendix Figures 45, 46, 47 and 48 show Structure C as submitted to manufacturers. From these
designs the components can be built then fastened to form the complete structure. Figure 11
summarises these drawings, showing detail of the LCD mounting area, top plate and supports.
20
Figure 11: Structure C. A) Perspective view of side sheets, B) Side view of structure demonstrating
LCD mounting position in lower half. C) Cross sectional view of structure, showing room for PC104
Boards . D) Top/Bottom plate.
Appendix Figure 49 and 50 show the assembly drawings and interior of Structure D. Interior
dimensions in all structures fit the PC104 form-factor. Dimensions of Structure D’s top plate
demonstrate the access hatch requirements for the QB50 mission.
Figure 10 summarises these drawings, showing detail of the boom mounting point (Figure 10a),
the cutout section in one side for the LCD screen (Figure 10b) and the Top/bottom panels, sized
in accordance with access hatch requirements.
3.3
Component Integration
PCB’s for LEONIDAS subsystems are all designed to PC104 standards, which will allow us to mount
them vertically inside the Cubesat structure, as all structural designs incorporate holes arranged
to fit this standard. Most components fit into the top half of the structure, and four 100mm screws
go through this section for mounting. In the lower half of the structure the LCD panel is along
one face, which prevents vertically stacked PC104 boards from being in that area, so other sides
are used for magnetorquer housing. Due to there being few components in the satellite’s lower half
batteries are to be placed near the middle of the satellite, which ensures mass balance leaves the
centre of mass close to the satellite’s geometric centre.
Solar panels are mounted externally on the structure using 3D-printed plastic tabs, however a
better long term solution would be custom-made solar panels mounted on PCB’s, allowing them to
capitalise on the available space. For more details see the Assembly Integration and Test Plan.
21
3.4
Camera Boom Design
The driving requirements on our Camera boom are that it must be able to easily extend once the
satellite is ready for operation, be able to fold into a small area on the side of the craft, and be able
to accommodate a 24-pin cable for transferring data from the camera. Using a steel measuring-tape
was identified as the best solution, as it was quickly available, light, and fulfils all the requirements.
These are frequently used as antennas on CubeSat missions, however substantial testing would be
required prior to launch to ensure sufficient rigidity and freedom from movement, as the camera
must maintain its position during photography. The boom mount point is depicted in Figure 10.
3.5
Finite Element Analysis
A finite element analysis was conducted in Solidworks, considering Structures A, C and D, and
considering the worst case load scenarios of vibration, shock and acceleration taken from QB50
requirements. For further details regarding the specific QB50 requirements for resonance, acceleration, random vibration and shock load requirements see QB50 requirement document.
Figure 12: FEA Analysis of Von Mises equivalent Yield stress under static loading during take-off for
Structure A (Aluminium 1), Structure C (Aluminum 2) and Structure D (Nylon and VeroWhite).
Three materials were used to do the structural simulation, Aluminium for Structure A and C,
and Nylon and VeroWhite for Structure D. The main physical properties of each materials are
shown in Table 2.
22
Aluminum[9]
Nylon[9]
Vero white[27]
2770
1140
1170
71
28.3
2.5
Poisson’s Ratio
0.33
0.4
0.4
Yield strength (M P a)
280
50
60
3
Density (kg/m )
Yong’s Modulus (GP a)
Table 2: Main physical properties of materials.
Static structural analysis corresponding to the structural loading during take-off is pictured
for the three cases in Figure 12.
As is illustrated in Figure 12, for aluminium structure A and C, the maximum Von Mises stress
occurs on the top, and are 9.6×106 P a and 5.3×106 P a, much smaller than yield stress of aluminum
(280 M P a) giving a factor of safety of at least 29 in both cases. On the other hand, for plastic
materials, the maximum Von Mises stress occurs on at the middle. To be precise, the maximum
stresses of the Nylon and Vero white structures are 3.2 × 106 P a and 3.19 × 106 P a, respectively,
which also meets the yield strength requirement (50 M P a for Nylon and 60 M P a for Vero white)
giving factors of safety of 15.6 and 18.8 respectively.
Demonstrated in Figure 13, the maximum total displacements of the structure occurs at the top
for the three materials, with Aluminium (1.19 × 10−5 m Structure A, and 1.14 × 10−5 m Structure
C) and Nylon (1.07×10−5 m) both significantly less than VeroWhite (1.1×10−4 m) is substantially
less than 1 mm, hence will be acceptable for our needs.
Figure 13: FEA Analysis of total deformation under static loading during take-off for Structure A
and C (Aluminium) and Structure D (Nylon and VeroWhite)
Random vibration also plays a critical role during launching process, so was tested in accordance
23
with QB50 requirements. From Figure 14, which shows Von Mises equivalent stress, comparing with
the results of simulation, the stress states are different between metal and plastic materials. This is
mainly because of different properties of materials and different structure. The maximum equivalent
stresses are 2.6 × 107 P a, 1.8 × 107 P a, 1.85 × 107 P a and 1.04 × 107 P a for Aluminium Structure
A, Aluminium Structure C, Nylon and VeroWhite respectively, giving factors of safety of 10.8, 15.6,
2.7 and 5.8. Whilst this is fairly low for Nylon, all materials are likely sufficient for this task.
Figure 14: FEA Analysis of axial (z direction) equivalent stress under random vibration conditions
during take-off for Structure A and C (Aluminium) and Structure D (Nylon and VeroWhite)
The final important aspect of analysis is identification of the structural resonances, which revealed resonant frequencies as in Table 3 for Structure D and VeroWhite. As the first mode of the
structure is at 126 Hz, this sufficiently exceeds the required 90 Hz minimum, so the structure passes
this test.
Mode
1
2
3
4
5
6
Frequency (Hz)
126.06
126.84
182.96
199.1
209.28
236.79
Table 3: Resonant Frequencies of Structure D made from VeroWhite. All are above the 90Hz
minimum.
Due to simulation results, though these three materials have different performance properties,
they all passed the tests. Table 4 shows the relative costs of manufacturing and strength among
the three materials.
24
Aluminum
Nylon
Vero white
Cost
high
medium
low
Strength
high
medium
low
Table 4: Cost and strength of each material.
3.6
LEONIDAS Moments of Inertia and Center of Mass
The moments of inertia for LEONIDAS are calculated from solidworks modelling of the complete
satellite. Internal layout of the satellite is described thoroughly in the assembly integration and
test plan document.
Figure 15: LEONIDAS Assembly Model
Low moments of inertia allow for more efficient attitude control, and an ideal system would
minimise the second moments of inertia, which bring interference terms into ADCS algorithm.
In order to minimise moments of inertia we have arranged the components within LEONIDAS
as symmetrically as possible, such that the center of mass is close to the geometric centre of the
satellite, and moments of inertia can be minimised.
25
From Origin
From Geometric Center
X = 50.70
0.70 (Towards +X)
Y = 49.61
0.49 (Towards -Y)
Z = 120.85
8.35 (Towards +Z)
Table 5: Centre of mass for LEONIDAS (mm)
Table 5 shows the centre of mass is 8.394 mm from the geometric centre of the satellite, which is
within the QB50 required 20mm diameter sphere around the geometric centre. Moments of inertia
for the satellite are in Table 6.
Lxx = 6582076
Lxy = 5081
Lxz = −83393
Lxy = 5081
Lyy = 6307690
Lyz = 124062
Lxz = −83393
Lyz = 124062
Lzz = 2794590
Table 6: Moments of Inertia for LEONIDAS (g · mm−2 ) at centre of mass
3.7
Mass Balance Summary
Table 7 is a summary of the mass budget table in Annex 1 of this report. It is found that the total
mass including contingency is less than 1500 grams, well within the 2kg allowed for a 2U CubeSat.
3.7.1
Contingency Masses
Contingency masses here, as in Annex 1, are calculated depending on what is known about the
particular component at the present time.
Components with development status ”Hardware” are those that we already possess, and as
such their masses are relatively well defined. For large components (such as structural panels) their
mass is known, and only minor changes are likely before launch, so their contingency is 5%. For
other connectors and structure parts, such as solar panel brackets, a 10% contingency is used, as
whilst we have created these parts, some changes may be made in the future.
Components which are standard components, such as Structural bolts and nuts, have zero contingency, as we have possession of these components, as well as manufacturer documents which
specify their mass precisely. Other purchased components, such as the GPS unit, batteries, magnetorquers and solar panels, have had their mass measured by us (and some come with mass estimates
from the manufacturer). These components have a 10% contingency due to the possibility of slight
inaccuracy in measurement, as well as the fact that minor additions (such as glue / solder) may be
required during integration with the satellite.
Components listed as ”Design Estimate” have been planned, in terms of quantity and component
makeup, however we have not begun assembling them, or even purchased all required components.
They therefore have large contingency margins, from 30-50%. For integration requirements (wiring)
the required wire length / size has also not been established, so again there are large margins on
these components.
26
The QB50 Langmuir probe specification document quotes the mass at ”225 grams including
20% margin” so this has been included as stated in our calculations.
27
Component
Development Status
LEONIDAS Mass (Grams)
# Parts
Estimated
Contingency
Total
6
124.64
6.232
130.872
Structural Subsystem
Structure
Hardware
Solar Panel Connectors
Hardware
32
6.8
0.68
7.48
Structural Bolts
Hardware
47
36.39
0
36.39
Structural Nuts
Hardware
87
13.35
0
13.35
Boom Assembly
Hardware
3
5.58
0.533
6.113
Glue / Epoxy
Design Estimate
1
15
5
20
Integration / Wiring
Design Estimate
3
20
6
26
Attitude Determination and Control Subsystem
Magnetorquers
Hardware
3
90
9
99
Sun Sensors
Hardware
5
0.65
0.065
0.715
ADCS Board
Component masses
1
85
8.5
93.5
Solar Panels
Kill Switch
Hardware
Solidworks
8
1
232
2
0
1
232
3
Battery
Hardware
2
104
5.2
109.2
Component masses
1
105
18.5
123.5
Design Estimate
1
35
7
42
Component masses
1
115
11.5
126.5
Hardware
4
8.56
0.856
9.416
Component masses
1
66
3.8
69.8
Thermal Tape
Design Estimate
1
10
5
15
Battery MLI insulation
Design Estimate
1
5
2.5
7.5
Electrical Power Subsystem
Power Board 1
Battery Attachment Board
OBC and OBC Data Handling Subsystem
OBC Board
Communication Subsystem
Antennae
Communication Board
Thermal Subsystem
Payload
Arducam LCD + PCB
Hardware
1
76
3.8
79.8
Camera + Cable
Hardware
1
4.8
0.48
5.28
Langmuir Probe
Specification Document
1
187.5
37.5
225
Table 7: Summary of the Mass Budget in Annex 1.
28
Total
1481
Target
2000
Margin
26%
4
Attitude Determination and Control Subsystem (ADCS)
4.1
4.1.1
ADCS Components
Magnetorquers
For 3 axis control, 1 magnetorquer is mounted on each axis of the CubeSat. The magnetorquers are
designed and built in house using the manual winding machine shown in Figure 16. This devices
uses a square mould and continuously wraps winding copper wires (IEC 60317) around it to create
a squared magnetorquer. The mechanical counter on the device is used to determine the number of
turns. There two mould sizes available but to match the size of CubeSat, the smaller mould is used
giving 40.96 cm2 as the area of magnetorquer. Originally, during winding process, a specific current
must be used through the wire to melt its coating and stick the wires together to achieve a stronger
magnetic field. However, due to the lack of a precise current control device, an alternative process
was set up where pieces of paper are inserted into the mould on all four sides and the winding is
done over the papers ensuring that the coil is surrounded by it. After the winding, to stick the wires
together, heat resistant glue is used. As the wire diameter is small, the papers absorb the glue and
create a hard wrapping around the coil. Using this process three magnetorquers were made with
the following properties:
• 295 turns, 27 g, 56.6 ohm
• 300 turns, 19 g, 57.6 ohm
• 300 turns, 20 g, 58.4 ohm
The torque strength of the magnetorquers were tested using a compass and a permanent magnet.
In each case, a strong torque was observed. Since the requirement for the detumbling and rotation
allowed a slow rate, the observed torque was deemed to be adequate.
Figure 16: Copper spinning tool used to create the magnetorquers.
29
4.1.2
Sun Sensors
Due to budget limitation, instead of using an actual sun sensor, TSL260R-LF AMS photodiode
sensors were used. There was also an option of using light-resistors but it was concluded that
photodiode provide more accuracy and more stable over time. By comparing the normalised output
voltage with the voltage-angle relationship in Figure 17, it was then possible to get an estimate
of the direction of the sun with respect to local CubeSat coordinate. To do so, five sensors were
placed on each side of the CubeSat and by triangulating values of each sensor, orientation of the
CubeSat with respect to sun was determined.
The sun sensors are used in conjunction with the IMU. Both are weighted and passed through
a linear filter to give a state.
Figure 17: Copper spinning tool used to create the magnetorquers.
Algorithm In order to properly make use of the sun-sensor output, the following algorithm was
implemented as a means of collecting the most effective data possible from the sun sensors. The
purpose of the algorithm is to determine the vector that points towards the sun (or some other light
30
source). This vector can then be fed into the three dimensional PID controller for the magnetorquers
to control which direction the satellite is facing.
First, a vector will be generated and stored with each sun sensor. This vector will be the
direction vector of that particular sensor. For example, the sun sensor on the top face might have
a direction vector of (0 0 1) while the sun sensor on the bottom face might have a direction vector
of (0 0 -1).
Then, we need to collect some calibration data (see Algorithm 1) (the maximum intensities
recorded by each sun sensor) which will aid in normalisation of recorded readings.
Algorithm 1 Find Maximum Sun-Sensor Value
for time ← 1 . . . 10 hours do
for sun sensor i ∈ {a, b, c, d, e} do
vi ← reading from sensor i
if vi > maxi then
maxi ← vi
end if
end for
end for
After this, when the location of the sun is required, each sun sensor will be read and the three
with the highest readings will be selected (A, B and C). At this stage, we have the following:
1. The normalised direction vectors: A = (ax ay az ), B = (bx by bz ) and C = (cx cy cz ).
2. The intensities measured on each sun sensor: IA , IB , IC .
3. The maximum intensities obtainable by each sensor: Amax , Bmax , Cmax
Using these values, we can trivially calculate the normalised voltage for each sensor as follows:
Ii
Vnormalisedi = imax
.
To simplify calculations, linearity was assumed for normalized voltages between 0.1 (60◦ ) and 1
(0◦ ). This results in the following expression for the normalised voltage:
Vnormalised = 1 − 0.015 × θ
Using this, we find the following expression for the angle given the normalised voltage.
θ = 66.67(1 − Vnormalised )
Using this expression and the normalised voltages found above, we can use the dot-product
identity to obtain expressions for the sun vector S = (sx sy sz ):
A · S = |x||y| cos θ = cosθ
B · S = |x||y| cos θ = cosθ
C · S = |x||y| cos θ = cosθ
By solving these equations for S, we can find the the sun vector as required.
31
4.1.3
Motor Driver
In order to control the direction of the torque produced by the magnetorquer and thus controlling
the direction of rotation of the CubeSat, it is necessary to employ motor drivers. The main purpose
of motor driver is to control the direction of output current supplied to the magnetorquer. Toshiba
TB6612FNG motor driver was chosen due to its ease of use and budget constraints. Figure 18
displays the input and output to the drivers. As shown, each driver is capable of controlling two
IOs simultaneously. The inputs and output are digital binaries and the magnitude of the voltage
is adjusted by the PWMA built-in functionality. For each motor, binary input of 01 provides the
voltage output of PWMA to the motor our and input 10 reverses the PWMA to the motor output.
The use of motor driver is essential in cases where the satellite is required to rotate to an
angle that is greater than angle of satellite with geomagnetic line. Since the torque generated by
magnetorquer tries to align the satellite with the geomagnetic line at the moment satellite crosses
this line, the torque automatically reverses direction and forces the satellite to turn back towards
the geomagnetic line. Thus by reversing the input current to the magnetorquer, it becomes possible
to further rotate the satellite away from the geomagnetic line.
Figure 18: Motor driver used to run the magnetorquers.
4.1.4
IMU
The IMU used includes a magnetometer, accelerometer and gyroscope, making it a 9 degree of
freedom IMU. This Adafruit model also includes a temperature sensor and barometer. The IMU
uses an AHRS algorithm (Attitude Heading Heading and Reference System) that returns the pitch,
roll and yaw of the satellite with respects to magnetic north. The IMU in its current iteration uses
only accelerometer and magnetometer data to give the attitude.
4.1.5
GPS
The CubeSat utilises an on-board GPS to determine longitudinal and latitudinal position above
the earth. The current GPS used in the satellite is the Adafruit Ultimate GPS. It has a technical
32
altitudinal limit of 40km, so for a space-ready satellite, a proper licensed satellite will need to be
used.
Sensitivity
Frequency of updates
Channels
Max Altitude
-165 dBm
10Hz
66 channels, 22 satellites tracking
40km
Table 8: GPS Specifications.
Component
Range
Sensitivity
Unit
Magnetorquers
±0.077
0.0006
N · m/T
0−5
0.1
V
Sun Sensors
Motor Drivers
0−5
0.02
V
Gyroscope (IMU)
±250
8.75 × 10−3
deg/s
Accelerator (IMU)
±2.0
1.1 × 10−3
g
Magnetometer (IMU)
±8.1
0.035
gauss
Table 9: Other ADCS components specifications.
4.2
ADCS Single Axis Control
The first part of ADCS control is attitude determination. The satellites position and velocity
properties must be determined to provide accurate inputs to the movement control and allow
for effect manoeuvring. Using the information provided a controller then calculates the required
outputs to the control systems resulting in accurate position and velocity control. The components
required to achieve this are:
1. Three axis magnetorquers
2. GPS
3. Five sun sensors
4. Three axis gyroscope
5. Three axis magnetometer
6. Three axis accelerometer
7. Dedicated microcontroller board
The magnetorquers are inlaid into 3 faces of the cube sat, whilst the sun sensors are placed
on every face of the cube sat barring the top side due to limited space availability. The IMU and
microcontroller boards are housed internally to protect them from exposure to degrading radiation.
33
The sun sensors allow for accurate location of the sun’s position relative to the satellite and this
information can be used to approximate location and spin rates, when combined with data recorded
from the IMU and GPS the satellite can successfully manoeuvre into a position with less than 15◦ of
error.
The attitude control of the satellite is primarily controlled with the use of a three axis magnetorquer. These are magnetic coils orientated orthogonally that generate a magnetic field which
interacts with the Earth’s magnetic field to produce a magnetic moment. The satellite has been
designed to minimise moment of inertia where possible to minimise the power consumption required
to position the CubeSat. The resultant inertia of the cube satellite is:


6449833 −6521 −30890


I =  −6521 6285981 80453  mm4
−30890
80453
2840709
Figure 19: Custom magnetorquer created for the LEONIDAS.
The satellite is required to de-tumble after release over a period of up to 24 hours from a
maximum starting tumble rate of 10◦ per second. This requires a minimum dipole moment from
the magnetorquers of 0.001 A · m2 . The magnetorquers have been designed using 300 loops of
copper wire in a square shape of edges 0.065 m with a 0.004225 m2 area (see Figure 19). These
magnetorquers operate at 5 v in their maximum operating state and are capable of providing a
magnetic dipole of 0.11 A · m2 and a maximum possible torque of 3.4 × 10−6 N · m subject to the
orientation of the Earth’s magnetic field relative to the satellite.
The position and angular velocity of the satellite as well as the magnetic field strength of
Earth are determined through analysis of data retrieved from an array of 5 sun sensors, the solar
panels, the on board camera and most importantly the gps and the inertial measurement unit.
This information is fed back into the controller to determine the voltage to be applied to each
magnetorquer to manouver the satellite in the desired way.
The controller for the positioning system is a fairly simple PID controller (see Figure 20) with
a very high derivative term to account for the diminishing torque potential as the field lines of the
active magnetorquer approaches the Earth field lines. The preliminary design was modelled for a
one dimensional case as can be seen below with very successful results. The Given PID terms are
34
Figure 20: PID controller block diagram, developed using MATLAB.
as follows: KP = 100, KI = 10−5 , KD = 7000. The design for the one dimensional controller has
then been used to develop the 3 dimensional state space controller for orbital use. The controller
design allows for a 90◦ turn along the z-axis with a response time of 170 seconds and a settling
time of 220 seconds. The voltage supplied is forced to saturation for only the first 20 seconds of
the movement ensuring minimum power consumption throughout manoeuvres. The magnetorquer
setup also allows for stabilisation from de-tumbling under ideal conditions in under 600 seconds or
10 minutes.
Figure 21 shows the position response of the satellite after a step input of π/2 radians. The
initial conditions are angular velocity = 0 and angle to field lines 90◦ . It can be seen that there is a
fairly quick response time and an equally quick settling time allowing for fast and effect manouvering
of the sattellite whilst maintaining a power draw of less than 446.4 mW and a current of less than
90 mA.
Figure 21: Controller’s response to a step input of π/2 radians.
35
Figure 22 shows the angular velocity of the sattellite has been modelling under an ideal detumbling phase with the 10/s initial angular velocity in the x-axis, the axis with the highest inertia
and requiring the longest detumble time of all axis. The ideal conditions assumed are: contasnt
magnetic field strength of Earth of 0.00003 Tesla orthogonal to plane of rotation.
Figure 22: Satellite’s angular velocity in the x axis during de-tumbling.
36
4.3
4.3.1
ADCS 3-Axis Control
Frames of Reference
Earth Centred Inertial Reference System The Earth Centred Inertial Reference System
(ECI) (Figure 23) is a non-rotating frame commonly used in order to simplify the use of equations
of motion to describe orbital motion. The system has its x-axis in the direction of the vernal
equinox, z-axis in the direction of the North Pole and the y-axis orthogonal to the x-axis and z-axis.
Note that in this frame the acceleration caused by the Earth’s rotation about the Sun is negligible.
Figure 23: Earth Centred Inertial Reference System[5]
Orbital Reference System The orbital reference system (24) follows the cubesat around its
orbit. The system has its z-axis in the nadir direction, x-axis in roughly the direction of the
instantaneous orbital velocity vector as measured from the ECI reference system and its y-axis
orthogonal to the two in the negative angular momentum direction.
Reference Attitude System Also knows as the Control Reference System, the reference attitude
system is along the cubesats principal axes with its origin in the centre of mass. It is about where
all attitude control measurements are taken.
Body Reference System As its name suggests the body reference system is fixed to the body
of the cubesat. Its origin is located in the geometric centre of the cubesat, with its z axis parallel
37
Figure 24: Orbital Reference System[5]
the long face pointing away from the Langmuir probe, x-axis parallel to the communications array
and pointing in the LCD screen direction and the y-axis orthogonal to the two.
The layout of the LEONIDAS focuses on keeping the cubesat as symmetrical as possible in
its mass distribution. Therefore the reference attitude system and the body reference system are
treated as coincident and thus the inertial matrix reduces to the principal inertia matrix.
4.3.2
Dynamic State-Space Model
First the Euler equations for rigid body dynamics are obtained to describe the attitude of the
cubesat.
Tctrl + Tg + Td = I · ω̇S/N + ωS/N × (I · ωS/N )
Where Tctrl is the torque provided by the actuators, Tg is the torque from gravity gradient
effects, Td is the torque from other disturbance such as aerodynamic drag and residual magnetic
dipole moment. The disturbance torque will be ignored for simplicity reasons. The subscript S/N
refers to the angular velocity and acceleration in the ECI reference system, and as usual denotes
the satellite inertial matrix. The ωS/N × (I · ωS/N ) term represents a cross coupling between
angular velocity components as the dynamics are described in a rotating co-ordinate system, in an
38
inertial coordinate system this term disappears however the cubesat dynamics become much more
complex[28].
Assuming symmetry the reference attitude system axes and the orbital reference system axes
are the same, therefore we can rewrite the above in scalar form:
ω̇S/N x Ix = ωS/N y ωS/N z (Iy − Iz ) + Tx
ω̇S/N y Iy = ωS/N x ωS/N z (Iz − Ix ) + Ty
ω̇S/N z Iz = ωS/N x ωS/N y (Ix − Iy ) + Tz
Where Ix , Iy , Iz are the moments of inertia about the respective cubesat body axes and Tx ,
Ty , Tz are the respective total torques about the respective cubesat body axes. Now everything
with respect to the ECI reference system can be expressed in the reference attitude system via an
approximation of a direction cosine matrix.



1
ψ −θ
0



ωS/N = ωS/R +  −ψ 1
φ   −ω0 
−φ
θ
1
0
Where φ is roll, θ is pitch, ψ is yaw, and ω0 is the rotational velocity of the satellite around
the Earth. ωS/R can be expressed in its axis components ωx , ωy and ωz which then gives the
differential equations for the angular acceleration in the reference attitude system. Ignoring the low
order quadratic terms and linearising the differential equations yield:
ω̇x = −σ1 ω02 ψ + (1 − σ1 )ω0 ωz +
ω̇y =
Tx
Ix
Ty
Iy
ω̇z = −σ3 ω02 ψ + (1 − σ3 )ω0 ωx +
Tz
Iz
where
Iy − Iz
Ix
Iz − Ix
σ2 =
Iy
Ix − Iy
σ3 =
Iz
σ1 =
Next the linearised gravity disturbance developed by Psiaki is used[25]:


−σ1 φ


Tg = 3Iω02  σ2 θ 
0
39
Now, the linear state space model can be derived:
ẋ = Ax + Bu
Where the system matrix is[25]:

0
0


0
0


0
0

A=
2
 −4ω0 σ1
0


0
3ω02 σ2

0
0
0
1
0
0
0
1
0
0
0
0
0
0
0
0
0
ω02 σ3
−ω0 (1 + σ3 )
0
0





1


ω0 (1 − σ1 ) 


0

0
0
The input matrix is:

0
0





B=




0
0
0
0
Ixx
0
0
Iyy
0
0
0


0 

0 


0 

0 

Izz
The state vector is:
x = [φ θ ψ ωx ωy ωz ]
The control vector is simply calculated from the control torque generated from the magnetourqers in newton metres.


0
bz −by


Tctrl =  −bz
0
bx 
by −bx
0
Where is the magnetic moment matrix generated by the magnetourqers, and is the Earth’s
magnetic field intensity matrix[6].
4.3.3
Aerodynamic Drag
At an altitude of 300 − 650 km the effects of aerodynamic torque and gravitational torque are
comparable[8]. The aerodynamic drag can be estimated using the standard approach to calculate
atmospheric drag[11].
1
Fd = − cd Asat ρV 2
2
Where Fd is the aerodynamic drag force, cd is the coefficient of drag, Asat is the cross section
of the satellite perpendicular to the satellites motion, is the density of air and V is the orbital
velocity.
40
As the LEONIDAS is essentially a rectangular box the coefficient of drag is approximated to
be 2.1[31]. Assuming a circular orbit of 380 km altitude the orbital velocity is approximately 7683
m/s and the density of air at this altitude is estimated with the law of atmosphere which gives a
mean value of 1 × 10−11 [19]. The satellite also has its centre of mass greater than the geometric
centre in the z direction, therefore in flight it will be stable with the langmuir probe facing forward
and therefore the cross section of the satellite perpendicular to the satellites motions is the small
face with an area of 0.01 m3 . This gives an aerodynamic drag of −6.2 × 10−6 N which will give an
aerodynamic torque of the order of 10−7 N · m as Taero = Fd × d, where d is the torsion arm which
is the distance from the centre of pressure to the centre of mass of LEONIDAS in flight.
4.3.4
Simulation
In the following simulation results (Figure 25) are of a simple PID control algorithm was developed
to control the attitude of LEONIDAS using the dynamic model derived above.
Figure 25: PID simulation results.
From the simulation results we can see the slow response of the magnetorquer control with the
gravity gradient as the main disturbance. Also observed is the tendency for the magnetorquers to
over estimate then oscillate back to the desired angle.
41
5
5.1
Electrical Subsystem
Initial Design
The initial design for the EPS involved using the solar panels to directly power all subsystems,
utilising a single battery as a backup reservoir during the an eclipse. The system requires the use
of an LDO and current sensor to track the power output from the solar panels and in turn smooth
the varying power signals from the solar panel. This design is depicted in Figure 26.
Figure 26: Initial power system design.
The problem faced with this design is the large variability in the voltage and current provided
by the solar panels depending on the orientation of the solar panels with respect to the sun, this is
evident in Figure 27:
Figure 27: Initial power system design flaw[10].
42
5.2
Proposed Design (Prototype)
The new design involves using batteries as the primary source of power for all the subsystems of
the satellite. The reason for this choice is due to the fact that batteries are able to provide as much
current as the subsystems require to power them efficiently, and the voltage out of the batteries are
easier to regulate using Buck boost converters.
The EPS uses two batteries, where one battery charges, whilst the other supplies power to
the satellites subsystems. Using an ADC on a microcontroller the battery voltage drop across the
supply battery is measured, once the voltage drops to 3.2V, the supply battery is swapped to the
previously charging battery and now the discharged battery is charged. The basic circuit design is
shown in Figure 28:
Figure 28: Basic proposed power system design.
5.3
MOSFET Switch Circuit
The design of the switches requires the use of an NMOS configured as show in Figure 29.
Figure 29: MOSFET Switching Circuit.
43
When the gate voltage (Vin ) is greater than the threshold voltage VGS > Vth .
The mosfet behaves as a closed switch allowing current to flow from Vdd to ground; the larger
VGS the larger the current that is able to flow through mosfet, as the current of the mosfet is
dependent on the gate source voltage:
w
1
µn Cox (VGS − Vth )2
2
l
Hence it is important to ensure that the VGS is maintained at a high potential. The proposed
NMOS for the switching circuit (IRF 1405) has a Vth ranging from 2.5V - 4V.
Some of the NMOSs are required to be connected to the battery during the charging process
(as shown in Figure 30).
I=
Figure 30: MOSFET Switching Circuit connected to the Solar Panels.
Digital I/O pins connected to Vin can provide a maximum of 5 volts to the gate, therefore:
VGS = 5V − 3.7V = 1.3V =⇒ VGS ≥ Vth
Hence an additional control switch is required that is capable of providing 9V to the gates of
the power control switches, Figure 31 shows the circuit design and results of the 9V gate voltage
output.
The circuit functions as a not gate, when the gate voltage is set high, Vout is low and when the
gate voltage is set low Vout is approximately 9V.
44
Figure 31: MOSFET design with 9V provided to the power control switches.
Figure 32: MOSFET design with 9V provided to the power control switches simulation.
45
Figure 33: MOSFET design with 9V provided to the power control switches in the OFF configuration.
Figure 34: MOSFET design with 9V provided to the power control switches in the OFF configuration simulation.
46
5.4
Circuit Design
The overall circuit design is shown in Figure 35, some design assumptions made during the simulation include:
• Modelling solar panels as an ideal voltage source
• Modelling BCR (Battery Charge Regulator) as an ideal voltage source
Figure 35: Final Circuit Design.
47
5.4.1
Circuit Design Simulation Results
When a low signal is sent to the gate of EPS control switch circuit, battery 2 will be charging while
no current from the BCR will be flowing to battery 1, hence battery 1 will be discharging. This is
verified through the circuit simulation results in Figure 36.
Figure 36: Circuit Simulation causing battery 1 to discharge.
48
When a high signal is sent to the gate of the EPS control switch circuit, battery 1 will be
discharging while no current from the BCR will be flowing to battery 2, hence battery 2 will be
discharging. This is verified through the circuit simulation results in Figure 37.
Figure 37: Circuit Simulation causing battery 2 to discharge.
5.5
Power Draw/Consumption
The components that draw power within all the subsystems of the satellite are as follows:
5.5.1
OBC (On Board Computer)
The duty cycle of the OBC is assumed to be running at a 100% during all modes of operation
except during standby mode, during this phase it assumed that the OBC will only run 25% of the
time to monitor vital aspects of the satellites condition and position.
The max power consumption of the OBC is 0.055Watts, during the various operation modes:
1. Sleep/Standby Mode: 0.001375 Watts
2. Primary Payload Operation Mode: 0.055 Watts
3. Secondary Payload Operation Mode: 0.055 Watts
49
4. Communication Mode: 0.055 Watts
5. Recovery/De-tumble Mode: 0.055 Watts
5.5.2
Langmuir Probe (Primary Payload)
The Langmuir probe will only be active during the primary payload operation mode, this mode
will be active for the full orbital period unless operation mode of the satellite has been changed.
The max power consumption of the probe is 0.8 watts, during the various operation modes:
1. Sleep/Standby Mode: 0 Watts
2. Primary Payload Operation Mode: 0.8 Watts
3. Secondary Payload Operation Mode: 0 Watts
4. Communication Mode: 0 Watts
5. Recovery/De-tumble Mode: 0 Watts
5.5.3
IMU (Inertial Mass measurement Unit)
According to the QB50 requirement the satellite is required to send regular telemetric data of the
satellite position and condition. Hence for this reason the IMU will be running at a 100% during
all operation modes except during the sleep/standby mode, where the IMU will be running for 25%
of the time, similar to the OBC.
The max power consumption of the IMU is 0.024 Watts, during the various operation modes:
1. Sleep/Standby Mode: 0.006 Watts
2. Primary Payload Operation Mode: 0.024 Watts
3. Secondary Payload Operation Mode: 0.024 Watts
4. Communication Mode: 0.024 Watts
5. Recovery/De-tumble Mode: 0.024 Watts
5.5.4
GPS
Forming part of the ADCS subsystem, the GPS module has the same duty cycle as the IMU sensor.
The max power consumption of the GPS is 0.1 Watts, during the various operation modes:
1. Sleep/Standby Mode: 0.025 Watts
2. Primary Payload Operation Mode: 0.1 Watts
3. Secondary Payload Operation Mode: 0.1 Watts
4. Communication Mode: 0.1 Watts
5. Recovery/De-tumble Mode: 0.1 Watts
50
5.5.5
Photodiodes (Sun Sensors)
The photodiodes are assumed to be running at a 100% duty cycle in all operation modes except in
the sleep/standby mode where it will only be running at a 25% duty cycle.
The max power consumption of the photodiodes are 0.02178Watts, during the various operation
modes:
1. Sleep/Standby Mode: 0.005445 Watts
2. Primary Payload Operation Mode: 0.02178 Watts
3. Secondary Payload Operation Mode: 0.02178 Watts
4. Communication Mode: 0.02178 Watts
5. Recovery/De-tumble Mode: 0.02178 Watts
5.5.6
Magnetorquers
From research of other cube sat systems, during any operation mode the nominal operating duty
cycle of the magnetorquer is 8%[4] (dependent on the max power consumption). During the
recovery/de-tumble mode (according to QB50 requirements must run for two days during initial
orbital insertion) during which time the magnetorquers will run for 50% of time.
The max power consumption of the all 3 magnetorquers combined is 0.6 watts, during the
various operation modes:
1. Sleep/Standby Mode: 0 Watts
2. Primary Payload Operation Mode: 0.048 Watts
3. Secondary Payload Operation Mode: 0.048 Watts
4. Communication Mode: 0.048 Watts
5. Recovery/De-tumble Mode: 0.3 Watts
5.5.7
Motor Controller
The operational duty cycle of the motor controller is tied to the magnetorquers, hence both the
components share the same duty cycle.
The max power draw of 2 of the magnetorquer is 0.0165 watts, during the various operation
modes:
1. Sleep/Standby Mode: 0 Watts
2. Primary Payload Operation Mode: 0.00132 Watts
3. Secondary Payload Operation Mode: 0.00132 Watts
4. Communication Mode: 0.00132 Watts
5. Recovery/De-tumble Mode: 0.00825 Watts
51
5.5.8
ArduCam
This is the secondary payload, this payload was decided to run at a duty cycle of 50% due to its
large power draw, and also due to its infrequency of operation.
The max power draw of the ArduCam module is 2 Watts, during the various operation modes:
1. Sleep/Standby Mode: 0 Watts
2. Primary Payload Operation Mode: 0 Watts
3. Secondary Payload Operation Mode: 1 Watts
4. Communication Mode: 0 Watts
5. Recovery/De-tumble Mode: 0 Watts
5.5.9
Transceivers (RX and TX)
According to the QB50 requirement the transceiver must send data every 30 seconds in its orbit,
this equates to approximately 5% of the total 5520 second orbit. During the communication with
ground station in Sydney, a communication window of approximately 128 seconds is available. For
a factor of safety within the power budget this time period is doubled to ensure required power is
sent to the transceiver. This equates to a duty cycle of 10.85%. The receiver of the communication
system must be on at all times, a 100% duty cycle.
The max power draw of the transceiver is 0.14586 Watts, during various operation modes:
1. Sleep/Standby Mode: 0.0495 Watts
2. Primary Payload Operation Mode: 0.054318 Watts
3. Secondary Payload Operation Mode: 0.054318Watts
4. Communication Mode: 0.06 Watts
5. Recovery/De-tumble Mode: 0.054318 Watts
5.6
Battery Selection
From the power budget of the satellite, the max power draw occurs during the operation of the
secondary payload operation, a draw of 2.60 watts (assuming 80% efficiency), and running for the
full orbital period the power in joules equates to:
Energy = 2.60 × 5520 = 14352 J
This means that the watt-hour of the batteries and the watts required by the solar panel is:
15091
= 3.99
3600
Assuming 60% efficiency if the solar panels, and 80% efficiency of the satellite subsystems:
W attHour =
52
W attHourBattery = 4
W attSolarP anels = 6.6watts
The most powerful yet cheaply available solar panel provides 0.8 watts, and the max number of
solar panels that are able to fit are 8, hence 8 solar panels will provide 6.4 watts of power in total,
which is acceptable within a 3.5% margin.
The battery chosen to power all the subsystems is capable of 10.5 Watt hours, which is more
than capable of powering the satellite.
In order to charge the battery, at least 4 Watt hours must be delivered to the battery, the
selected BCR is capable of supplying 4.3V at 1A, this has a watt hour of:
W attHour = 4.3 × 1 = 4.3
Hence the BCR is capable of charging the batteries fully even in the most power hungry mode
of operation.
53
6
On-Board Computer and On-Board Computer Data Handling Subsystem
LEONIDAS will be powered by an Atmel SAM3X8E. This is a 32-bit ARM Cortex M3 processor.
The CPU will be responsible for the complete control of the satellite and all of its subsequent
systems (attitude determination and control, power, communications, payload).
Operating Voltage
Digital I/O Pins
Analog Input Pins
Analog Outputs Pins
Flash Memory
SRAM
Clock Speed
3.3V
54 (of which 12 provide PWM output)
12
2 (DAC)
512 KB all available for the user applications
96 KB (two banks: 64KB and 32KB)
84 MHz
Throughout development, the Arduino Due has been shown to be quite capable of handling
all the processing done onboard. Its clock speed is 84 MHz, a considerable jump from simpler
microprocessors such as the Arduino Uno which has a clock speed of 16 MHz.
Due to the time constraints, LEONIDAS will have a complete Arduino Due compatible development board mounted on-board. This will eliminate the need to solder on the CPU as a surface
mount component to the PCBs directly and would make its programming much quicker. The Iduino
Due Pro [32] was chosen because it would fit on the PC104 standard board size (95.9 x 90.2 mm).
The Iduino Due Pro has a size of 86.3 x 53.3mm down from the 101.9 x 53.59 mm of the full Due
board. To save space, the Iduino Due Pro has the external programmer removed from the chip but
it is not necessary to program the board itself.
LEONIDAS adopts the mechanical layer of PC/104 as the standard for its PCB design. This
makes the satellite fairly modular as each board is a module of its own (power, OBC, ADCS, communications). QB50 does not require the CubeSat to use this standard but its commonly used in
CubeSats. Through the stack runs the power rails and all other inter-board communications. The
PC/104 stack pin assignments are shown in the following figure. Note that only the J1 stack of the
PC/104 standard is used and not J2. The PCB schematics and boards are included in the appendix.
54
Figure 38: Pin assignments for the PC/104 stack
PCBs were chosen over other alternatives like etching because it provided a higher resolution
for the wire grid. It was also a simpler process and each board doesnt have to be manually drilled
over 100 times for each individual component. The cost is largely the same.
Most of the components chosen for LEONIDAS are packaged breakout boards. This makes it
55
easier to integrate them into the system through means of soldering and would considerably simplify the connections. For example, in the case of the IMU, it comes packaged with 4 sensors: an
accelerometer, a magnetometer, a gyroscope and a barometer/thermometer. The board simplifies
all this into one package and presents all the sensors through one power rail and one I2C interface.
Most of the other breakout boards are the same in this regard.
LEONIDAS includes an SPI, an I2C bus and several TX/RX interfaces. The SPI is primarily
used to communicate to the SD card and the display on the ArduCAM board and to the downlink
transceiver. I2C is used as communication to all the other smaller boards like the IMU, UV sensor,
real time clock and camera). The separate TX/RX lines are for the GPS and uplink transceiver.
For a full list of components and how they communicate, please refer to section 1.
For its selfie payload, LEONIDAS uses the ArduCAM Rev C. board [16] to control the camera,
the LCD and the on-board storage.
• The camera module used is the OmniVision OV2640. This camera supports several image
resolutions between 160x120 and 1600x1200. In addition to this, the OV2640 supports realtime JPEG compression, significantly reducing the resultant image filesize.
• The ArduCAM breakout board is packaged with a 3.2 QVGA LCD which supports a maximum
resolution of 320x240. The display is accessed through the SSD1289 LCD controller using a
standard SPI interface.
• The SD card used for this project is an 8GB Sandisk micro SD card. Due to the nature
of the payload, 8GB is more than enough storage required. Each uploaded image requires
approximately 151KB of storage while each selfie requires approximately 17KB of storage.
This allows for approximately 50,000 individual selfies to be stored on the SD card.
Arduinos have been shown to be fairly competent in a space environment. Several Arduino-based
satellite have been launched into space, most notably the ArduSat-1 and ArduSat-X satellites [17].
As such, the microchip itself (the only common component between the ArduSat and LEONIDAS)
can be given a TRL of 9. The PCBs and other components can only be given a level of 5 since it
is shown that most PCBs can withstand a relevant environment.
All data received from either of the payloads, in addition to required location and power logging
data, will be saved to the external 8GB SD card before it is transmitted to the ground station.
Data saved to the SD card will typically be in an uncompressed, comma-separated value format to
reduce the complexity of data collection.
Data on the SD card will not be deleted unless requested by the ground-station. Although this
allows for the possibility of dropping data due to a lack of storage space, this will only happen if
the ground station hasnt made contact in several days.
All software for this system will be written in the Arduino programming language (an implementation of Wiring) which is very similar to C. It also has aspects of C++ in order to take advantage
of the namespacing and object orientation functionality. The software will be split up into individual modules. The software is fairly modularised with each module typically performing some
hardware or utility function, such as logging or payload management. The main loop is a simple
56
event processor, which will traverse a queue of pending events one at a time. Events are added to
this queue during various interrupt service routines (ISRs) such as timers or communication events.
Depending on the current operational mode of the device, certain events will be enabled or disabled
as required. The event queue will have multiple priority levels, which can influence which events
are processed before others.
6.1
Modes of Operation
6.2
State Transition Diagram
Figure 39 shows how the LEONIDAS will transition between states. Most of the state transitions
are caused directly via commands (in orange), some transitions happen automatically (such as the
movement from de-tumbling to normal operation) and the initial transition from standby to safe
mode is triggered via a hardware switch. States in a dashed circle may be run in parallel with other
states.
57
Figure 39: State transition diagram of the LEONIDAS satellite
58
Spacecraft
Mode
Description
Standby
Mode
When the CubeSat is in the launch vehicle, it is completely powered off. Once the CubeSat
is released the onboard mechanical switch is also released, enabling the EPS to be powered
up, enabling the whole satellite.
Safe Mode
This mode is intended to keep the satellite alive.
Only essential components are ON all the time such as the OBC, EPS and the receiver. The
transmitted is turned ON occasionally.
During this mode, to conserve power, the satellite has an uncontrolled attitude.
Recovery /
De-tumble
mode
This mode governs the period of time after deployment from the spacecraft where the detumbling of the CubeSat is necessary. This more is used to recover the CubeSat from any
spin-ups during the CubeSats mission/lifetime.
The ADCS components will be on full power during the de-tumbling in addition to all other
essential CubeSat components like the OBC and EPS. Payload Operation modes cannot
be activated from this mode before the satellite goes into Normal Mode. Once either 2
days have expired or the CubeSat has successfully destabilised, it would switch into Normal
Mode.
Normal
Mode
This is the mode of operation which the satellite is usually in. All of the essential components
are on such as the OBC, EPS and the receiver. The ADCS component is intermittently
enabled to make small attitude adjustments. Payload and transmission mode of operations
are accessed only through this mode.
Payload
Operation
Mode 1
This mode focusses some of the OBC resources on the Langmuir probe. The probe is operated and data is collected. It can be intermittently turned on throughout normal operation.
It is akin to enabling and disabling the Langmuir probe as opposed to having a dedicated
mode of operation.
The OBC will store the information within the SD card storage and once a link is established
with the ground station, the information will be transmitted through Transmission Mode.
Payload
Operation
Mode 2
This mode operates the camera and the LCD screen. It will only be activated for a very
short period of time. The selfies can be displayed on the LCD and cycled through at very
fast intervals, taking up no more than 1 minute per orbit. This mode could concurrently
run with Payload Operation Mode 1 and acts on top of Normal Mode, where it is simply
enabled or disabled.
The OBC will store all the images taken on the SD card and once a link is established with
the ground station, the information will be transmitted through Transmission Mode.
Transmission This mode is activated once the CubeSat is within transmission range of the ground station.
Mode
This can act on top of the normal mode of operation since no other components need to be
shut off for transmission to occur.
Table 10: Modes of Operation
59
7
7.1
Communication Subsystem
System Design
The communications system consists of two transceivers, each with their own antennas. These
two transceivers are both off-the-shelf components, a Digi Xbee is dedicated to downlink communications from the satellite to the ground station, whilst a HopeRF RFM22 is used for receiving
commands from the ground station. Both transceivers can transfer data from a data bus to the
on-board computer, operating in a full duplex mode, so that commands can be sent and received
simultaneously.
During system integration and testing, the Xbee was used to both transmit and receive commands in a half-duplex mode. This allowed easy testing of software components in software once a
single transmitter assured to be functioning correctly.
The communication uses the AX.25 data link layer protocol to frame data which is being transmitted to the ground station. Specifically, the transmission uses the AX.25 UI frame setup to send
data, as it works best for a fixed structure of commands and photo data. The satellite also assumes
that received commands are also using the UI frame. Specifically, the UI frame uses 112 bits of
Addressing frame, 512 bytes of information and a 16bit frame checking sequence. The Leonidas
Satellite has the callsign LEON, and SSID 0x60.
7.2
Components
The Digi Xbee PRO Series 1 is used for downlink transmission of acknowledgement commands,
scientific data, photos, and location data. This transmitter was chosen due as it is known to be
highly reliable, and has a well-documented interface with the Arduino computer used on the satellite. The XBee used in the proof of concept operates at 2.4GHz (S-band) with a RF data rate
of 250kbps, and transmission power of 60mW. However, for space situations, this Xbee should be
replaced with a long distance XBee Pro, which transmits at a frequency of 902-928 MHz at 9.6kbps,
with a transmission power of 100mW. This upgrade to the hardware will allow the transmitter to
work at much greater ranges in space, but was not implemented in the proof-of-concept model due
to the additional costs of procuring another long-range Xbee to act as a ground station. Both
transmitters use FSK modulation to encode data. The on board computer communicates with the
XBee module via a serial interface.
It is worth noting in the downlink budget that the bandwidth is less than the required value of
10 dB. Replacing the short range XBee currently used in the prototype with the long-range XBee
discussed above increases the bandwidth to 15dB. However, the ground station at the University
of Sydney does not support a 915MHz signal, so another ground station would need to be chosen,
or the hardware at the university would need to be upgraded.
The XBee module is connected to the communications PCB via a breakout board, which allowed
efficient testing using a breadboard. This also allows the specific XBee module to be swapped out
effortlessly if an upgrade is necessary, or if a different series of the transceiver is used. The pin
allocations are given below:
60
Figure 40: Picture of the XBee
XBee Breakout Pin
External Pin
5V
5V power bus
GND
Ground power bus
TX
RX2 on OBC
RX
TX2 on OBC
The HopeRF RFM22 is a transceiver which is used to receive instructions from the ground
station. These instructions include reporting position, changing values used by the on-board computer, and commands as to when to take photos using the satellites camera. The receiver must
also be able to receive user photos to display on the LCD. The receiver operates at 434 MHz at
9.6kbps, with a receive current of 18.5 mA and using the frequency-shift keying (FSK) modulation technique. This receiver was chosen do to its low power consumption and extensive Arduino
libraries. The on board computer communicates with the RFM22 module via a SPI interface. A
breakout board (RFM22B-S2 RF TRANSCEIVER BREAKOUT BOARD WRL-10154) [20] was
used for implementation and integration. The pin-out for the board is provided in the diagram
below:
Half-wave dipole antennae will be used for both uplink and downlink transmission, with the
transmitter antennae each having a length of 16mm and the receiver antennae having a length of
164mm. These lengths were found using an online tool [18], and verified using other tools and
hand calculations. The antennae for the budget proof-of-concept model were constructed from
measuring tape and mounted to the outside wall of the satellites structure via screws and nuts.
The Xbee connector uses a u.FL connector to connect to the antennae, while the RFM22 uses a
SMA connector to receive signals from the antennae.
61
Figure 41: RFM22B Breakout Board [22]
7.3
Ground Station
The ground station to be used on the mission is the University of Sydney ground station, with the
antennae mounted on the universitys electrical engineering building (Latitude: S33◦ 53’, Longitude:
E151◦ 11’, Altitude: 56m). This ground station has the capability of receiving in the very high
frequency (VHF), ultrahigh frequency (UHF), and S-Band frequency bands, and can transmit at
144-148 MHz and 430-438 Mhz. The ground station is run from a Linux-based system, which can
be set up to receive AX.25 packet format and FSK modulation.
However, given the limited time span for the project, it was recommended to the team to avoid
using the USyd ground station due to a large expected learning time for the system. Therefore in
system integration and testing, a mock ground station was set up consisting of another Digi XBee
Series 1 Pro, a USB connector for the XBee module, and the X-CTU wireless program. However,
X-CTU only allowed for text commands to be transmitted, so in-house software was developed to
be able to download and upload photographs to the satellite.
7.4
Subsystem Development
The initial communications system design composed of two Texas Instrument CC1101 transceivers,
with one operating in the UHF range for downlink and the other operating in the VHF band for
uplink communications. However, investigation into the transceiver found that its modulation technique was not BPSK as initially planned, but it used FSK. Secondly, integration into the system
was found to be difficult, as the CC1101 transceiver chip required additional hardware and cir-
62
cuit design, the Arduino-focused interface boards did not operate in the VHF frequency band, and
the documentation for programming in C or for the Arduino on board computer was less than ideal.
Investigation into other low cost transceivers found that for the given budget and time frame,
the system design would need to be changed for the proof-of-concept implementation. Most applicable transceivers, such as the ones provided by Radiometrix, offered a limited frequency band
range, FSK modulation, and a low transmission power, which are less than ideal for space situations. However, given the project restraints, the non-space-grade components will work on the local
model, and be conceptually equivalent for the high cost components for a more expensive system.
The XBee and RFM22 transceivers were chosen against other components due to their frequent
use in other Arduino-based projects, which meant that there was a wide range of documentation,
troubleshooting and public libraries.
Once the components were acquired from online retailers, the transceivers were soldered to their
respective adapters, and the XBee was implemented first using the device in a half-duplex manner
with another Xbee device connected to a PC via a USB cable and adapter. This allowed strings
to be sent and received between a PC and an Arduino Uno board used in testing. The RFM22
receiver circuit was then constructed using a breadboard, however the testing transmission device
which was planned to be used could not operate in the way we had initially expected. Whilst
waiting for another transceiver to arrive so that the RFM22 could be used, the AX.25 protocol
was investigated and implemented into the XBee communications code using the UI packet frame
design. Receiver software was also developed in this time which could transmit messages to the
satellites XBee in the same AX.25 format.
The XBee was then integrated with the on-board computer, which involved the implementation
of user commands to affect the behaviour of the spacecraft. These were implemented using two
circular buffers for transmission and receive strings. A second UHF transceiver was used to test the
RFM22 receiver, however there appeared to be an error in the SPI interface between the Arduino
Uno and the transceiver. The setup was tested in reverse with the satellites transceiver set to
transmit using the manufacturers example code, however the issue was not resolved. The XBee was
then set to operate in a half-duplex manner to receive and transmit data until the issues with the
RFM22 transceiver were resolved.
7.5
7.5.1
Commands
User Commands
To communicate with the satellite, a list of user commands were constructed to control the satellites
functionality. The user commands are listed below.
For the commands SET and GET listed in Table 11, the following key/value pairs are allowed:
1. SET/GET TRANSMIT ON/OFF
2. SET/GET LOG-LEVEL DEBUG/INFO/ERROR
3. SET/GET DISPLAY-LOG ON/OFF
4. SET/GET MODE [mode]
63
Command
SET [key] [val]
Result
Sets the corresponding variable for different functionality of the satellite, mostly used in testing. The transmitter and display screens can
be turned on and off, the log level can be set to acquire logging data,
and the satellite can be set to a specific system mode.
GET [key]
Gets the current value of some configuration variable.
LIST
Returns a list of all the files on the Satellite’s SD card
REMOVE [filename]
Removes a file with the given filename from the satellite’s SD card.
UPLOAD [filename]
Uploads the given file to the satellite. The file will be split into chunks
and each chunk will be uploaded separately.
DOWNLOAD [filename]
Downloads the given file from the satellite. The use-case would be to
retrieve pictures, geo-positional data files, or probe data, or logging
files.
SELFIE
Commands the satellite to search the SD card for any uploaded pictures
which do not have an associated selfie JPEG file, and sequentially take
all the photos.
DOWNLOAD SELFIE
An extension of the download command which automatically queues
all the selfie JPEG files for download.
Table 11: Commands available to the user.
7.5.2
System Commands
In addition to the above mentioned user commands, there are also a series of system commands
(see Table 12) which are used to complete complex operations such as downloading or uploading
files. These commands can either be sent from the satellite to the ground station or vice versa.
The commands were designed in this way to allow the satellite to be as stateless as possible.
Under this command system, the ground station is responsible for requesting the correct block to
download or uploading the correct block at the correct time. Due to the relatively small length of
time the satellite is available, it is possible that large files may not download in a single orbit. This
command architecture supports partial downloading of files over separate orbital runs. In addition
to these large-file requirements, this design also allows the satellite to be almost completely stateless,
greatly simplifying the required code and, hence, improving the stability of the software as a whole.
64
Command
Direction
Result
DOWNLOAD-BLOCK [f] [id]
GS → Satellite
Request the given block ID from the satellite
(f is the file, id is the block ID).
BLOCK [f] [id] [n] [s] [d]
Satellite → GS
Transmit a single block from the satellite to
the ground station (f is the file, id is the
block ID, n is the total number of blocks, s
is the size of the block, d is the block data).
UPLOAD [f] [o] [s] [d]
GS → Satellite
Upload data into the given file at some offset.
The satellite will only acknowledge once all
data has been received and written to the
file (f is the file, o is the offset to the start
of the block, s is the size of the block, d is
the block data).
Table 12: System Commands
65
8
8.1
Thermal Control Subsystem
Proposed Thermal Protection
In order to maintain the satellite within QB50 required ranges, and the battery within its operating
range, we propose usage of Kapton thermal tape on the outside of the structure due to its favourable
optical properties, which has an emissivity of 0.81 and absorptivity of 0.87[24]. This will cover 12%
of each of the three identical side faces and the bottom face, and 22% of the face with LCD panel.
We assume the Langmuir probe face is entirely covered in Aluminium finished with Alodine 1200[14]
and that we cant use any thermal tapes here. In order to maintain battery temperature within
operating limits multi-layer insulation (having a conductivity of 0.02 W ·m−1 ·K −1 [29]) of thickness
3mm will protect the battery. As excessive cold is our most difficult challenge, we consider the cold
case for heat transfer.
8.2
The Thermal Environment
Our 2U cubesat is designed to be operated in a sun-synchronous orbit at approximately 380 km
altitude. Unlike inter-planetary probes, or to some extent those in geostationary orbits, LEO
satellites must take into account thermal interference from the earth, as well as heat absorbed
directly from the sun, and that radiated by the satellite back into space. QB50 Requirements
dictate that our satellite’s temperature stay between -20◦ C and 50◦ C.
We assume the orbit is effectively circular, as in Figure 42, with the satellite spending part
of each orbit in direct sunlight (green arc, Figure 42) then a period in eclipse (red arc, Figure
42). The sunlight period corresponds to approximately 60.7% of the orbit (substantially greater
than half due to the altitude of 380km) corresponding to 55.8 minutes, then 39.3%, 36.2 minutes,
in the dark. The m-NLP instrument requires pointing approximately in the direction of satellite
motion, allowing us to make the simplifying assumption that the satellite is oriented perfectly in
this direction.
The satellite’s heat balance equation is dominated by a number of external heat transfer mechanisms (Figure 42) which are to be accounted for in calculations. Inbound heat sources in order of
decreasing magnitude include incident sunlight, present during the light part of the orbit, Albedo
radiation (sunlight reflecting from the earth’s surface or atmosphere back to the satellite) present
again essentially for the light part of the orbit, and Earth’s Infrared radiation, present through
the entire orbit. Outgoing heat transfer is mostly due to that radiated away from the satellite’s
body. Other heat sources potentially include internal heat generation from electrical components,
and the Aerothermal heat flux (due friction with the atmosphere), but at altitudes of 380 km this
is negligible.
8.3
Thermal Analysis Outline
We will treat the satellite as a one thermal node, with a secondary node set out for the battery
(as it is the most temperature-critical component). Treating the bulk of the satellite as a single
thermal mass is an approach utilised in a number of studies on other spacecraft such as those
on the OUTFI-1 Nanosatellite[24] and Compass-1[29]. As our satellites internal structure is far
from optimised (and would change substantially before any sort of mission) we will not attempt
to measure or simulate conduction through the structure and components, instead assuming that
this process will be relatively fast, meaning the satellite maintains a homogenous temperature
66
Figure 42: Some sources of heat transfer, path of or orbit in sun (green) and eclipse (red), and
coordinate axes used in orbital model.
throughout. For the different heat sources we will generally assume conservative or mean measured
values, as we expect the satellite to be most likely at risk of excessively low (rather than hot)
temperatures. This is motivated by previous studies[24][29] of CubeSats which have shown cold
cases (i.e. conservative/low estimations of heat fluxes) present the major engineering challenges
(preventing very low battery and component temperatures). That is to say, rarely do CubeSats
similar to ours become too hot, since they do not have significant internal heat sources such as
chemical engines, the major challenge is being not warm enough. We break the satellite down into
six faces, neglecting any radiation that might be collected by the antennas, and assume they are
comprised of solar panels, structural material, thermal tape, and the rail material. For this purpose
we assume that the side rails on the satellite are made from anodised Aluminium (rather than
Verowhite) as we would need to use this in order to comply with CubeSat standards for launch.
Thermal balances will be performed on the two nodes then integrated over many orbits in MATLAB
until a stable temperature cycle is achieved.
8.4
Thermal Inertia of the Satellite
We model the Satellite as two thermal nodes: The majority of the satellite structure and subsystems,
and a separate node for the battery. The main node is broken down into three pieces as shown in
Table 13.
Note The value for Structure is taken as that of an average of Nylon Plastic (Verowhite thermal
properties are not well established) and Aluminium as it is assumed that in order to comply with
QB50 requirements a significant portion of the structure (Whether it is Structure C or D) must be
67
Component
Mass (kg)
Specific Heat (J · kg −1 K −1 )
Structure
PCBs
Solar Panels
0.2
0.85
0.25
1300[2]
1136[24]
1600[29]
Total (Csatellite )
1625.6 J · K −1
Table 13: Thermal Inertia of the Satellite.
.
Aluminium (such as the exterior rails), whilst a substantial amount will by Nylon/Verowhite, such
as interior supports and components for attaching solar panels/antenna/camera boom.
The batteries in our satellite comprise 0.1kg mass and have a specific heat of 1350 J ·kg ·K −1 [24]
giving a heat capacity of Cbattery = 135 J · K −1 .
8.5
Heat Balance for the Satellite (Main Node)
Heat flow in and out of the main node is governed by the equation:
Q̇total = Q̇solar + Q̇albedo + Q̇IR + Q̇gensystems − Q̇radiative − Q̇battery
Where Q̇solar = incoming radiation from the sun (Watts), Q̇albedo = solar radiation reflected
from earth, Q̇ir = infrared radiation from earth, Q̇gensystems = heat generated by internal components, Q̇radiative = heat radiated to deep-space by the satellite and Q̇battery = heat transferred
to/from the second thermal node, the battery.
This equation is used to calculate changes in satellite temperature according to:
Qtotal = Csatellite × ∆Tsatellite
Where Csatellite is the heat capacity of the main node (J ·K −1 ) and ∆Tsatellite is the temperature
change of the satellite.
8.6
Heat Balance for Battery (Second Node)
The battery is modelled as a homogenous thermal mass with its entire surface area covered in
insulation. The exterior of the insulation is assumed to be at the same temperature as the main
node (rest of the satellite), producing a simple energy balance between conduction and temperature
change.
k × Abattery ×
(Tsatellite − Tbattery )
= Qbattery = Cbattery × ∆T − Qgenbattery
xinsulation
Where k = conductivity of battery insulation(W · m−1 K −1 ) Abattery = surface area of battery
(m2 ), Tsatellite = temperature of the satellite (Main Node) (K), Tbattery = Temperature of the
battery, xinsulation = thickness of battery insulation (m), Cbattery = heat capacity of the secondary
node (battery) (J · K −1 ) and Qgenbattery = heat generated by battery charge / discharge (W ).
68
8.7
Heat Generation within the satellite
We estimate the heat generated internally by our satellite by considering a number of the less efficient components and the heat dissipated by their operation, following the method of[24]. Assuming
a power consumption of 3.5 Watts averaged throughout the orbit, all of which must pass through
batteries (as seen in Table 14).
Factor
Battery Charge/Discharge
On-board Systems
3.5
3.5
88%[12][24]
78%[24][29]
0.45 = Qgenbattery
1.0 = Qgensystems
Power Throughput (W )
Efficiency
Heat Dissipated (W )
Table 14: Heat generated within the satellite.
.
(Efficiencies have been estimated as an average of component efficiencies for on-board systems,
and standard Li-Ion efficiency for the Batteries.)
These heat generation figures are similar in magnitude to those found in CubeSats, and actually
underestimate heat generation compared to other studies in similar circumstances[24][3], which is
ideal as we believe our satellite will likely be close to the cold limit of allowable temperatures (rather
than too hot).
8.8
Radiative Transfer Terms
All radiative transfer terms are scaled depending on the optical properties of the satellite at their
incident face. For thermal analysis, NASA and ESA adopt the standard of assuming optical properties of materials are constant over two ranges, the visible spectrum (0.3 m to 2.5 m wavelength),
and the IR Spectrum (4.25m to 40m wavelength). By Kirchoff’s 2nd law the absorbance and emissivity of a material is approximately constant at any given angle, so we call α the absorptivity
(and emissivity) in the visible spectrum, and the emissivity (and absorptivity) in the infra-red
spectrum.
These values are calculated for each face of the satellite (See Appendix C), which includes
adjustment for the absorptivity of the solar panels due to some incident radiation being converter
to power.
On the exterior of the satellite we have included Kapton tape due to its thermal properties,
however if desired temperature control is not achieved a range of paints and coatings may be
implemented to keep fluctuations within desired ranges [3].
8.8.1
Solar Flux
The solar flux in Low Earth Orbit varies throughout the year by a small degree, but is here
approximated as a constant flux (for which incoming rays are assumed to be parallel do to the suns
great distance) of Fsun = 1367 W · m−2 [3][24]
This gives the heat flux absorbed by the satellite as:
Qsolar = Fsun × Asun × αsun
69
Where Qsolar = heat absorbed (W ), = mean absorptivity of each face, and Asun = area of
satellite presented to the sun at each point, accounting for rotation throughout the orbit (Calculation
of this area is described in Appendix C).
8.8.2
Albedo Flux
The albedo flux is a result of sunlight reflected from the earth’s surface and atmosphere, particularly
cloud cover, and is modelled as (for each face):
Qalbedo = Fsun × albedoearth × Aearth × αearth × Xf
Here Qalbedo = incoming flux absorbed by satellite due to albedo reflected radiation (W ),
albedoearth = average albedo of the earths surface, varying between values of 40 80% above clouds
to 5-10% above open land and forests[24], but taken here to average to 35%[3], Aearth = area presented by the face to the earths surface (either 0.2 × 0.1 or 0.1 × 0.1 m2 ), αearth = mean weighted
absorption coefficient of satellite towards earth, and Xf is an approximation for the amount of
reflected radiation reaching the satellite[24]:
Xf = [cos(0.9θ)]1.5 × Vf
Where the first factor is a correction for the satellite-earth-sun angle of reflection, and Vf is the
view factor, an approximation for the proportion of radiation leaving the Earth that strikes the
satellite, given by:
ρ
Vf = r2.1 [sin( )]2.6
2
Where ρ = angle between satellite face normal and earth surface normal and r = R/(R + h)
with R = 6371km, the radius of the earth, and h = 380km, the altitude of the orbit.
8.8.3
Earth Infrared Flux
The Earth IR flux is a result of the warm earth radiating away heat, which can be modelled as an
ideal blackbody radiator at Tearth = 255 K[3]. The total radiative heat transfer from a black body
is given by:
4
Fblackbody = σ0 Tearth
Where σ0 = 5.67 × 10−8 W · m−2 K −4 is the Stefan-Boltzman constant, and T = temperature of
body (K). As we have already calculated the view factor, this is now relatively easy to calculate.
Q̇IR = Aearth × earth × Fblackbody × Vf
Where is the mean surface emissivity of each given face.
70
Figure 43: Radiation collected by satellite over two orbits, with orbital angle defined as in Figure
42. Albedo and Solar radiation are seen to drop to zero in the earth’s shadow, whilst IR radiation
and satellite internal heat generation are constant throughout.
8.8.4
Radiated Heat away from Satellite
Approximating the satellite as a black body we can calculate the rate it radiates heat from the
Stefan-Boltzman law for a black body as described above. This gives the total rate of heat loss as:
4
Qradiative = Atotal × × σ0 × Tsatellite
Where Atotal is the total satellite surface area (m2 ), is the surface Emissivity and Tsatellite is
the mean temperature of the satellite.
8.9
Numerical Model
The previous equations are integrated numerically in MATLAB over time from arbitrary initial
temperature conditions according to the relation:
dT = Qtotal × dt/C
Where dT is a change in temperature of the satellite (K), dQ is the rate of heat transfer (W ),
dt is the time step length (s) and C is the heat capacity (J · K −1 ). We run the model in one degree
steps (corresponding to 15 seconds flight time) and integrate over many orbits until temperature
approaches a stable oscillation.
8.10
Results
As anticipated the temperatures of the two nodes fluctuate as throughout the orbit, and with the
current thermal covering the satellite’s temperature stays well within the −20 → 50◦ C range in
the QB50 requirement. Mean satellite temperature through the orbit is greater than zero, meaning
sufficiently insulated components in the interior could be made to maintain a temperature above
freezing.
71
Figure 44: Thermal fluctuations of satellite over two orbits.
The battery’s insulation serves two protective purposes. Firstly, insulation decreases the rate of
heat transfer, thereby decreasing the magnitude of fluctuations in the battery temperature, which
are now ranging between 4 → 12◦ C. If we included more insulation, the temperature of the battery
would approach a constant level as it would have such resistance to temperature change that no
appreciable difference would happen over an orbital timescale. Secondly, the heat the battery generates is trapped inside it by the insulation, which shifts the mean battery temperature throughout
the orbit to approximately 7◦ C, rather than the mean satellite temperature of approximately 2◦ C.
Even if the heat generation assumption for the battery is erroneous, since the mean satellite temperature is above zero we could include thicker insulation to render the battery temperature nearly
constantly this value, which is within its operating range.
A major weakness of our analysis is that we have only considered two nodes, meaning many
factors such as transient conduction through the structure, and the fact that different components
will be isolated to temperature changes to some degree, have been ignored. This would result in
the exterior parts of the satellite having larger temperature fluctuations, whilst those in the interior
would be of smaller magnitude. This is an ideal situation for many components, as the solar
panels are typically efficient over a much larger temperature range than the internal processing and
control PCB boards. Previous studies have shown similar conclusions and thermal solutions are
required when considering more simplistic analysis (such as done here) or more complex conduction
models[24][29].
8.11
Conclusions on Thermal Design
We find that by using Kapton tape on the exterior of the spacecraft we are able to maintain the
temperature of most components to fluctuations between −9 → 13◦ C during the orbit, well within
the QB50 requirement of −20 → 50◦ C, which coincides with the allowable temperature ranges for
most LEONIDAS subsystems.
Via the use of 3mm thick MLI the battery temperature is maintained between 4 → 12◦ C during
the orbit, an ideal temperature (above the 0◦ C minimum for charging) for their operation.
72
Additional MLI could be employed on the exterior of the spacecraft to boost temperature
further, however many components have a longer operational life at lower temperature, so a colder
spacecraft is ideal for many operations.
Therefore, this passive thermal solution proves sufficient for LEONIDASs needs, and is easily
and cheaply implemented with minimal power and mass requirements.
73
9
References and Published Papers / Presentations
References
[1] Qb50 sensor selection working group final report. https://www.qb50.eu/sswg_report.pdf,
March 2012.
[2] Incropera FP Dewitt DP Bergman TL Lavine AS. Principles of Heat and Mass Transfer.
Wiley Press, 7th edition, 2014.
[3] Escobar E Diaz M Zagal JC. Design automation for satellite passive thermal control. In The
4S Symposium 2012.
[4] Graversen T Frederiksen MK Vedstesen SV. Attitude control system for aau cubesat. Technical report, AALBORG UNIVERSITY INSTITUTE OF ELECTRONIC SYSTEMS DEPARTMENT OF CONTROL ENGINEERING.
[5] Pedersen D R Grunnet J D Larsen J A Laursen K K Kolakowska E Amo I P. Attitude control
system for aausat-ii. Technical report, Aalborg University Institute of Electronic Systems.
[6] Bai X Hagel P Wu X Xiao S. Improved predictive control for virtual satellite attitude control.
In Proceedings of the 31st Chinese Control Conference.
[7] Kataria D Leff C Smith A Chaudery R Reinhard R Asma CO. Sensors and science.
https://www.qb50.eu/download/workshop/workshop5th/5_5thQB50WS-ScienceUnits_
and_Sensors.pdf, January 2013. QB50 5th Workshop.
[8] Lumpp J E Jr Rawashdeh S A. Aerodynamic stability for cubesats at iss orbit. Journal of
Small Satellites, 2(1):85–104, 2013.
[9] Callister WD Rethwisch DG. Materials Science and Engineering: An Introduction. Wiley
Press, 8th edition, 2010.
[10] Craig Clark Ritchie Logan. Power budgets for mission success. http://www.clyde-space.
com/documents/2276, 2011.
[11] Dempster A G Rizos C Qiao L. Analysis and comparison of cubesat lifetime. In Australian
Space Science Conference Series.
[12] Valoen LO Shoesmith MI. The effect of phev and hev duty cycles on battery and battery pack
performance. In Plug-in Highway Electric Vehicle Conference.
[13] Kataria DO Smith A.
Qb50 science units.
https://www.qb50.eu/download/
3rdQB50Workshop_presentations/04-Sensors-DKataria.pdf, 2012. 3rd QB50 Workshop.
[14] Moen JI Trondsen E Bekkeng TA Lindem T. Qb50 m-nlp science unit interface control document issue 4. Technical report, QB50 Specification Documents.
[15] Aslan AR Umit E. A double cubesat with an x ray detector for in situ environmental measurements of qb50. http://www.nanosat.jp/images/report/pdf/NSS-05-0403.pdf, 2013.
The 5th Nano-Satellite Symposium.
74
[16] ArduCam. Arduino based camera. http://www.arducam.com, 2014.
[17] Ardusat. Ardusat homepage. http://www.arducam.com, 2014.
[18] Radio Brandy. Dipole antenna calculator. http://www.radiobrandy.com/dipole1.html, n.d.
[19] Manuel Ruiz Delgado.
Atmospheric drag:
Modeling the space environment.
http://ocw.upm.es/ingenieria-aeroespacial/modeling-the-space-environment/
contenidos/material-de-clase/mse06_atmos.pdf, 2008.
[20] LittleBird
Electronics.
Rfm22b-s2-rf
transceiver
breakout
board.
http://littlebirdelectronics.com.au/products/
rfm22b-s2-rf-transceiver-breakout-board, 2014.
[21] Red Rock Energy group. Heliostat design concepts. http://www.redrok.com/concept.htm,
2012. Data from University of Western Australia Architecture Science Lab.
[22] HopeRF. Rfm22 ism transceiver.
General/RFM22.PDF, n.d.
https://www.sparkfun.com/datasheets/Wireless/
[23] Arducam Inc. Arducam / camera modules. http://www.arducam.com/about-us/, 2014.
[24] Jacques L. Thermal design of the oufti-1 nanosatellite. Master of aerospace engineering thesis,
University of Liege.
[25] Psiaki M L. Magnetic tourqer attitude control via asymptotic periodic linear quadratic regulation. Journal of Guidance, Control and Dynamics, 24(2):386–399, 2000.
[26] Nanosatisfi LLC. Ardusat your arduino experiment in space. https://www.kickstarter.
com/projects/575960623/ardusat-your-arduino-experiment-in-space, 2012.
[27] RedEye 3D Printing. Verowhiteplus material properties. http://www.redeyeondemand.com/
verowhite-polyjet/, 2014.
[28] Wisniewski R. Satellite attitude control using only electromagnetic actuation. PhD thesis,
Aalborg University Department of Control Engineering.
[29] Czernik S. Design of the thermal control system for compass-1. Diploma thesis, University of
Applied Sciences Aachen.
[30] RUAG Aerospace Defence Technology. Sara 21 satellite antenna rotary actuator specification
document. Technical report, RUAG Space Zurich.
[31] The Engineering Toolbox. The drag coefficient expresses the drag of an object in a moving
fluid. http://www.engineeringtoolbox.com/drag-coefficient-d_627.html, 2014.
[32] GE Tech Wiki. Iduino due pro. http://www.geeetech.com/wiki/index.php/Iduino_DUE_
Pro, 2013.
75
Appendices
A
Structural Design
76
Figure 45: Side sheet to be cut for Structure C.
77
Figure 46: More views of side sheet to be cut for Structure C.
78
Figure 47: Top sheet to be cut for Structure C.
79
Figure 48: More views of top sheet to be cut for Structure C.
80
Figure 49: Assembly drawings of Structure D. Dimensions on top/bottom face demonstrate access-hatch requirements are
satisfied.
81
Figure 50: Assembly drawings of Structure D. Section A-A demonstrates interior view, made to fit PC104 form-factor.
Detail C section shows the boom-mounting support.
82
B
OBC and Data Handling Subsystem
83
Figure 51: ADCS Board.
84
Figure 52: ADCS PCB Schematic.
85
Figure 53: Communications Board.
86
Figure 54: Communications PCB Schematic.
87
Figure 55: Iduino Due Board.
88
Figure 56: Iduino Due PCB Schematic.
89
Figure 57: Power Board.
90
Figure 58: Power PCB Schematic.
91
C
Thermal Control Subsystem
C.1
Mean Emissivities and Absorptivities
The top (Langmuir Probe) face is predominantly Aluminium and is finished with Alodine 1200[14],
which has emissivity, = 0.15 and absorption, α = 0.08[30]. Side and Top faces include hard
anodised Aluminium rails along the cubesat sides, having = 0.86 and α = 0.86[24] Kapton tape
has = 0.81 and α = 0.87[24], and glass of the lcd screen is approximately ≈ 0.9 and α ≈ 0.85[21].
Solar cells have an emissivity = 0.81[24]. The Solar Cell absorptivity must be corrected to
account for the fact that with some efficiency they convert radiation into electricity (some of which
is then being returned to the satellite as heat). This follows the relation α = α0 − γ where γ is the
cell efficiency (typically 20-30% over the lifetime of the spacecraft) and α0 is their absorptivity if
no electricity were generated, typically ¿ 0.9 for good cells, leading to a reasonable estimation of
solar cell absorptivity α = 0.71[24]. We calculate the mean coefficients for each side of the satellite
by breaking down the areas in question (see Table 15).
Areas (m2 )
Respective Respective α
Mean Values
Standard Side (x3)
0.0136 (Solar Panel), 0.004 (Anodised Rails), 0.0024 (Kapton)
0.81, 0.86, 0.81
0.71, 0.86, 0.87
0.82,0.76
LCD Side (x 1)
0.0048 (LCD), 0.0068 (Solar Panel),
0.004 (Anodised Rails), 0.0044
(Kapton)
0.9,0.81, 0.86, 0.81
0.9,0.71, 0.86, 0.87
0.84,0.81
Top Face (x 1)
0.01 (m-NLP)
Satellite Face
Bottom Face (x 1)
0.002 (Anodised Rails),0.0068 (Solar Panel), 0.0012 (Kapton)
0.15
0.08
0.15,0.08
0.86,0.81,0.81
0.86,0.71,0.87
0.82,0.76
Table 15: Surface properties of different Satellite faces.
C.2
Presented area of spacecraft to radiation
The area presented by the satellite to the sun that may collect radiation, A, will vary throughout
the orbit. We will approximate the 2U cubesat as a perfect rectangular prism, 200 x 100 x 100 mm
in dimensions.
For the Solar flux, when the satellite is near the South Pole it will be just the top (Langmuir
Probe) face area, Ab = 100 × 100 mm, when near the North Pole just the bottom face area, and
when on the equator one of the side faces, As = 200 × 100 mm. As the satellite may rotate about
the axis of its motion during flight (such as when aiming the selfie camera) the area presented
by
√
the satellite side will vary, from the full area of one face As = 100×200 mm (Figure 59a) to 2×As
when one of its edges is presented to the incoming flux (Figure 59b). If we are to assume orientation
along this axis is essentially random with respect to time, we can calculate that the mean side area
presented will be 1.27As . As the orientation of the satellite changes as it moves around the earth
the area presented by the sides will change sinusoidally (Figure 59d) Giving the area presented to
the sun as:
Asun = |cos(α)| 1.27As + |sin(α)| Ab
Figure 59: Area presented to heat flux at different satellite orientations.
93
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement