Briefing Overview and Context
SPECTRE is designing and prototyping a sail blade damping augmentation controller
for flapping and twisting blade oscillations for a proposed heliogyro CubeSat mission
SPECTRE is a continuation of last year’s GHOST senior design project which focused
on sail blade deployment and a blade pitching controller
Customer:
Project Purpose
Slides 4 -9
Design Description
Slides 11-22
Advisor:
Testing Overview
Slides 24-30
Dr. Xinlin Li
Test Results
Slides 32-39
Systems Engineering
Slides 41-43
Project Management
Slides 45-51
Dr. Keats Wilkie
NASA Langley
LASP
Department of Aerospace
Engineering Sciences, CU
Introduction
Content Breakdown
2
Project Purpose
Heliogyro Background
• Experimental on board spacecraft
propulsion system
•
Uses high aspect ratio “blades” that
generate thrust from solar radiation
pressure
•
Blades are held in place by centripetal
acceleration of spinning spacecraft bus
• Offers major advantages to traditional
solar sails
•
Order of magnitude thrust increases
•
Improved maneuverability
•
Potential applications in missions to
outer solar system and even
interstellar space
Heliogyro, Artist’s Conception (NASA JPL)
Heliogyro Diagram
4
Purpose of SPECTRE
Testing a heliogyro is impossible to demonstrate on earth. NASA is interested
in launching a small, inexpensive CubeSat heliogyro to demonstrate feasibility
and gain support in developing a larger scale satellite.
SPECTRE seeks to design the control system for the blades of the heliogyro
CubeSat that will pitch the blade, and damp twisting and flapping oscillations.
Controller Design Goals
o Pitch blades to +-90 degrees
o Provide damping to twisting blade oscillations
o Provide damping to flapping blade oscillations
o Must be compatible with 6U CubeSat platform
Example of 2 Blade 6U CubeSat Design:
Dimensions 10cm x 20cm x 30cm
Blade Dimensions approx. 18cm x 300m
Structural Design Goals
o Achieve CubeSat acceleration greater than 0.1 mm/s2
o Minimize structural mass and maximize blade storage volume
5
Blade Modes
Flapping Mode
Blade Root
Twisting Mode
Blade Housing
Blade Root
Blade Housing
𝜃𝑓𝑙𝑎𝑝
Blade Tip
Blade Tip
Other modes of blade oscillation are possible for heliogyro blades
These modes are the only modes being investigated by team SPECTRE
𝜃𝑡𝑤𝑖𝑠𝑡
6
Expected Behavior of Blade Analog
Earth Behavior
Space Behavior
• Frequencies directly tied to spacecraft angular
velocity 𝜔
• Flapping Mode Frequenecy can be
approximated as a pendulum
• Period Depends on the blade’s mass
(M) moment of inertia (I) and center
of gravity (R) measured from the
blade root. g remains constant for
Earth testing.
• 𝑓𝑓𝑙𝑎𝑝 =
1
2𝜋
𝑀𝑅𝑔
𝐼
• The torsional mode is best
estimated from the flapping mode
M
𝜔
R
• 𝑓𝑓𝑙𝑎𝑝 = 1.0 ∗ 𝜔
• 𝑓𝑡𝑤𝑖𝑠𝑡 = 1.4 ∗ 𝜔
g
• Angular velocities of proposed heliogyro missions
typically ~1/3 RPM
• 𝑓𝑓𝑙𝑎𝑝 ≅ 0.035 𝐻𝑧
• 𝑓𝑡𝑤𝑖𝑠𝑡 ≅ 0.049 𝐻𝑧
Based on the expected mode frequencies for space operations and the constraints of Heliogyro missions, the
controller is required to demonstrate a damping ratio of 𝜻𝒇𝒍𝒂𝒑 = 0.0073 𝜻𝒕𝒘𝒊𝒔𝒕 = 0.0136
Introduction
• 𝑓𝑡𝑤𝑖𝑠𝑡 = 1.4𝑓𝑓𝑙𝑎𝑝
7
Levels of Success
Success Level
Criteria
1
-Controller can pitch blades ± 90° within 5° of
commanded angle
-Controller can house enough sail material to produce
𝑚𝑚
0.1 2 of acceleration
𝑠
-Controller is compatible with 6U CubeSat platform
2
-Controller can augment damping on the first
torsional blade mode (𝜁 ≥ 0.0136)
3
-Controller can augment damping on the first
flapping blade mode (𝜁 ≥ 0.0073)
8
Design Changes Since TRR
Element Changed
Software Image
Filter
Housing Interface
Change Made
Reason
Filter changed Necessary for software
from YUV to
timing requirement
RGB
(image processing at 4+ Hz)
Bearing
system
removed
Bearing created too much
friction to perform torsional
damping tests and pitch
maneuvering. Interface
9
Design Description
20 cm
Baseline Design
Bevel
Gear
20 cm
CubeSat Bus
Linear
Motor
Driver
Rotary
Servo Motor
10 cm
Rotary
Motor Driver
Guide
Rail
Blade Flap Damping
Blade Pitching
Twist Damping
Bladeand
Sensing
Structural
Dimensions
• Linear
servo motor
and guide rails
• Camera
takes
images
of blade
tip
attached
to blade
spool
in
blade
• Rotary
motor
in CubeSat
bus
rotates
displacement
housing
provide
damping
for blade
• marker
Conforms
tohousing
CubeSat
entire
blade
unitrestrictions
• Uses
displacement
to
identify
type
flap oscillations
10x10x20cm
• Allows
for +-90 degree rotation
and
magnitude
of blades
blade oscillation
for
Can
store rolled
to 350
m in
• • Also
provides
damping
forupblade
twist
feedback
control
length and 17cm in width
oscillations
• • Image
done
Total processing
weight of 1.5
kg through
raspberry
pi
350 m
 Acceleration
of 0.1 mm/s2
10 cm
Blade
Housing
Linear
Servo
Motor
Camera
Solar Sail
Blade
Material
Kapton Tape
CubeSat Bus View
Rotary
Servo Motor
20 cm
Guide
Rail
Raspberry
Pi
Camera
FOV
Guide
Rail
Markers
17 cm
Bevel
Gear
Blade
Tip
Motion
CubeSat Demonstrator with Deployed Blade (not to scale)
10 cm
Camera
Blade Housing with Deployed Blade
Linear
Servo
Motor
11
FBD
Serial
5V
5V
Serial
Serial
Voltage 12V
12V
5V
Arduino
Rotary
Motor
USB
Serial
PC User Interface
Motor Driver
Voltage
12 V
Encoder Feedback
Legend
Actuator
Position
Command
Motor Position
Feedback
Linear
Motor
Motor Driver
Power
Supply
Raspberry Pi
Blade Mode,
Angle, Rate
(UART)
1.8 V
Blade Position
Feedback
Supply Voltage
Encoder
Feedback
Image
Camera
12
Critical Project Elements
Element
Critical Requirement
Specific Components
Control Law
Software
Blade dynamics must be accurately
modeled so that damping can be
achieved
-MATLAB GUI
-Control law, gains
Motors
Root Must be moved in the
appropriate manner to achieve
damping
-Linear Actuator
-Rotary Actuator
Image
Processing
Sensing
Deflections must be calculated
accurately
-Raspberry Pi
-Image Processing
Algorithm
-Camera
-Markers
Electronics
/Communication
Communication must be fast enough
to damp blade modes
Arduino Due
Raspberry Pi
MatLab GUI
13
Concept of Operations
13
MatLab Graphical User Interface
Blade Angular
Position
Blade Angular
Velocity
Commanded
Motor Position
15
Twisting Mode Block Diagram
• State Space Model Converts the Moment at the root into a Tip Deflection
•Uses the Membrane Ladder Model
16
Twisting Mode Block Diagram
• Derivative Gain is applied to the Velocity of the blade tip
17
Twisting Mode Block Diagram
18
Twisting Mode Block Diagram
Delays
- Computation Time
- Communication Time
19
Twisting Mode Block Diagram
20
Flapping Mode Block Diagram
• These Systems use the Same Basic Concepts described in the
Twisting Mode
- Controller uses derivative gain
- Motor Subsystem gives the actual root position
- Delays Added into due to Communication and Computation time
- Sensor Subsystem imitates the Camera resolution
21
Flapping Mode Block Diagram
•State Space Model Converts the Moment at the root into a Tip Deflection
•Uses the Membrane Ladder Model
22
Testing Overview
Maneuverability Testing
Software-Electrical Timing Testing
Sensing Accuracy Testing
Natural Damping Testing
Flap Mode Damping Testing
Twist Mode Damping Testing
Levels of Success
Success
Level
Criteria
Requirements
1
- Pitch Blade ± 90° within 5° of
commanded angle
𝑚𝑚
- Capable of producing 0.1 2 of
𝑠
acceleration to CubeSat
- Compatible with 6U CubeSat platform
1. ± 90° blade housing maneuverability
2. Blade housing capable of storing 350 m by 17 cm
blade
3. Mass of less than 2.6 kg
4. Volume less than 2U (10 cm by 10 cm by 20 cm)
5. Draw no more than 5 W of power
6. Detect blade in low light environment
2
Design a controller that is capable of
providing damping to twisting blade
oscillations.
1.
2.
3.
3
Design a controller that is capable of
providing damping to flapping blade
oscillations.
1.
2.
3.
Image processing and communication must
take less than 0.25 seconds
Less than 1° of random sensing error, 5°
systematic error
Damping ratio of 0.0073 or higher
Image processing and communication must
take less than 0.25 seconds
Less than 5° of random sensing error, 5°
systematic error
Damping ratio of 0.0136 or higher
24
Testing Overview
Maneuverability
Purpose
To validate that controller is able to pitch blade ± 90°
within 5° of commanded angle.(Success Level I)
Procedure
1.
2.
3.
CubeSat is placed on test stand; front housing free to
rotate.
Pitch angle of ± 90° is commanded to Rotary Actuator
Angle that front housing unit has traveled is measured
with protractor and compared to commanded angle.
3.
Front Housing
Orientation
𝜃𝐶𝑂𝑀𝑀𝐴𝑁𝐷 − 𝜃𝑀𝐸𝐴𝑆𝑈𝑅𝐸𝐷
𝜃𝑀𝐸𝐴𝑆𝑈𝑅𝐸𝐷
𝜃𝐶𝑂𝑀𝑀𝐴𝑁𝐷
Front Housing/Blade Position After Actuation
25
Testing Overview
Electrical/Software Timing
3
Purpose
Arduino
Matlab
5
- Ensure controller is able to damp modes properly
(Success Levels II and III)
 The response time of the fully integrated electrical
system must be less than 0.25 seconds.
Procedure -Image captured, filtered, then sent to MATLAB through
2
Raspberry Pi
Camera → Raspberry Pi → Arduino → MATLAB
4
1
Camera
1
Camera
4
Arduino to be analyzed.
2
Raspberry
Pi
Arduin
o
5
- Frame Rate set in Python
- Time between receiving sending packets is measured
with a logic analyzer right before the signal reaches the
motor driver
-Adjustments are made until 4 Hz requirement is
reached
3
Arduino
Matlab
Each peak is a
data packet
Shifter
Logic Analyzer
Find average
time between
packets
26
Testing Overview
Sensing Accuracy Noise
Purpose
-Determine accuracy of data from
camera/image processor
-Determine inherent noise from
sensing method
-Verify marker type can be identified
and isolated from the surroundings
Procedure -The camera will take 1000 images of
the blade with 0 degree deflection
-Plots will show noise level
-Max variation from 0 will give the
sensor noise
-Test images from the Raspberry Pi
will be examined with filter software
in Matlab
Camera takes a
series of 1000
images of
nominal blade
Data plotted and
compared to 0
(expected value)
Max variation
from 0 gives
sensor noise
27
Testing Overview
Air Damping
3.
Purpose
-Determine the damping caused by air
(Success Levels II and III)
𝜉𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟 = 𝜉𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟+𝐴𝑖𝑟 − 𝜉𝐴𝑖𝑟
Procedure
Controller turned off.
1. Manually excite twist or flap mode.
2. Camera measures tip/angle displacement over 60 seconds
3. Data sent to PC
4. Data is post processed in Matlab to determine damping
ratio
5. Measured damping ratio 𝜉𝐴𝑖𝑟 is used later to determine
controller damping
2.
Camera
FOV
4.
1.
MATLAB GUI Display
28
Testing Overview
Twist Mode Damping
Purpose
-Validate Controller Performance (Success Level II)
 Verify the damping ratio is at least than .0136.
𝜉𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟 = 𝜉𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟+𝐴𝑖𝑟 − 𝜉𝐴𝑖𝑟
Procedure
Control system turned on.
1. Tip mass manually displaced and released to excite
mode
2. Control system attempts to damp out blade
oscillations.
3. Image processing data sent to PC/Matlab and
displayed
2. Control Law
Implementation
3. Data
Transmission
4. Data Display
Camera View
1. Manual Excitation
𝜃𝑡𝑤𝑖𝑠𝑡 = atan(
𝐿𝑒𝑓𝑡𝐶𝑒𝑛𝑡𝑟𝑜𝑖𝑑 𝑌𝑉𝑎𝑙𝑢𝑒 −𝑅𝑖𝑔ℎ𝑡𝐶𝑒𝑛𝑡𝑟𝑜𝑖𝑑 𝑌𝑉𝑎𝑙𝑢𝑒
𝐿𝑒𝑓𝑡𝐶𝑒𝑛𝑡𝑟𝑜𝑖𝑑 𝑋𝑉𝑎𝑙𝑢𝑒 −𝑅𝑖𝑔ℎ𝑡𝐶𝑒𝑛𝑡𝑟𝑜𝑖𝑑 𝑋𝑉𝑎𝑙𝑢𝑒
)∗
𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 𝑡𝑜 𝑏𝑙𝑎𝑑𝑒 𝑡𝑖𝑝
𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 𝑡𝑜 𝑚𝑎𝑟𝑘𝑒𝑟𝑠
29
Testing Overview
Flap Mode Damping
Purpose
-Validate Controller Performance (Success Level III)
 Verify the damping ratio is at least .0073.
𝜉𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟 = 𝜉𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟+𝐴𝑖𝑟 − 𝜉𝐴𝑖𝑟
Procedure
Control system turned on.
1. Tip mass manually displaced and released to excite
mode
2. Control system attempts to damp out blade
oscillations.
3. Image processing data sent to PC/Matlab and
displayed
2. Control Law
Implementation
3. Data
Transmission
4. Data Display
1. Manual Excitation
Camera View
𝜃𝑓𝑙𝑎𝑝 = 𝐴𝑣𝑒𝑟𝑎𝑔𝑒 𝐶𝑒𝑛𝑡𝑟𝑜𝑖𝑑 𝑌 𝑉𝑎𝑙𝑢𝑒 −
𝑌 𝑃𝑖𝑥𝑒𝑙 𝑅𝑒𝑠𝑜𝑙𝑢𝑡𝑖𝑜𝑛
2
∗
𝑌 𝑃𝑖𝑥𝑒𝑙 𝑅𝑒𝑠𝑜𝑙𝑢𝑡𝑖𝑜𝑛
𝐶𝑎𝑚𝑒𝑟𝑎 𝐹𝑂𝑉
30
Test Results
Maneuverability Test
Controller Timing Test
Sensing Accuracy Test
Natural Damping Test
Flap Mode Damping Test
Twist Mode Damping Test
Test Results:
Maneuverability
•
•
•
90o Command
±6o error
Rotary Motor Capable of pitching to 90o with <1o
error
Gear Backlash and Mechanical error ≈ 5o
No time requirement for pitch maneuver
45o Command
±6o error
•
Decreasing magnitude of position command
decreases overshoot
•
Use position commands that can obtain
critically damped performance for controller
implementation (angles ≤ 12o)
12o Command
Positioning Performance Limited by
±6o error
 Manufacturer motor software/driver
 Gear backlash and mechanical rigidity
 Motor rotor inertia to load inertia ratio
32
Test Results: Image Processing Timing
Algorithm Speed Improvements
Sensing Sample Rate (seconds / sample)
1.8
0.625 fps
1.6
1.4
1.2
1
0.8
1.67 fps
0.6
3.18 fps
0.4
0.2
28 fps
0
31 fps
Original Alogorithm
Changes Made
Performance
Change
29 fps
c
Current Algorithm
Camera module
left on between
frame captures
Video acceleration Images saved and
firmware activated loaded as JPEG
instead of PNG
Image resolution
decreased
Error Checking
added
~2.5x faster
~ 2x faster
~ 1.1x faster
~ 1.05x slower
~ 10x faster
(hardware
accelerated)
33
Test Results: Total System Timing
Camera Results
- Capture images at a rate of 29
Hz
Camera
Raspberry Pi
Arduino
Matlab
Arduino
Shifter
Total Computational Time for
Software as a Whole
- Computational time averaged
at 0.0223 seconds, or 45
packets/sec
Logic Analyzer
(separation of packets as seen
using logic analyzer)
- Timing is consistent with 1000
packets sent in 31 seconds
(1000/31 = 32 packets/sec)
Timed using timing functions in
Python for the Raspberry Pi and a
logic analyzer for the Arduino
Each peak is a
data packet
Average of 30
packets a second
34
Test Results: Sensing Accuracy/Noise
Max Noise at 0.17˚
Noise Requirement: < 1˚
Actual noise is smaller since
periodic behavior at flapping
frequency is observed
Max Noise at 2.9˚
Noise Requirement < ˚5
35
Test Results: Air Damping
fflap
= 0.39 Hz
ζflap,air = 0.0083
ftwist
= 0.625 Hz
ζtwist,air = 0.0096
36
Test Results: Twist Mode Damping
Success Level II Validation
Air Damping Only
Controller and Air Damping
Flapping Mode
Testing
Results
Model
Results
Damping Ratio of Air
0.0048
0.0044
Damping Ratio of Controller +Air
0.0404
0.0438
Damping Ratio of Controller
0.0356
.0394
Required Damping Ratio
0.0136
37
Test Results: Flap Mode Damping
Success Level III Validation
Air Damping Only
Controller and Air Damping
Flapping Mode
Testing
Results
Model
Results
Damping Ratio of Air
0.0083
0.0085
Damping Ratio of Controller +Air
0.0223
0.0230
Damping Ratio of Controller
0.0140
0.0145
Required Damping Ratio
0.0076
38
Controller Testing Results Summary
Success
Level
1
2
2+3
3
Requirements/Constraints
Status
Notes
Controller able to pitch blades to ± 90° with ± 5° of accuracy

Motor firmware prevents
from using optimal PID
gains
Controller can house a blade capable of providing 0.1 mm/s2 of acceleration
to the CubeSat (350 m by 17 cm)

Controller and blade occupy 2U of volume (10cm x 10cm x 20cm)

Actual Dimensions 10.05 x
12.9 x 20.1 cm
Controller no more than 5 watts of power

Power draw varies from 3-
Controller must conform to CubeSat weight requirement ~1.3 kg/U, total of
2.6 kg

Mass of 1.26 kg
Controller can sense blade deflections without ambient light source

Controller must provide a damping ratio of 0.0136 or higher to twisting
mode

Achieved 0.0356
Controller must detect blade deflection angles with less than 1° of random
error and 5° systematic error

Random <0.2°, systematic
<2°
Controller must perform image processing and communication at greater
than 4 Hz

Runs at >20 Hz
Controller must provide damping ratio of 0.0073 or higher to flapping mode

Achieved 0.0140
39
Systems Engineering
Systems Approach
Develop
Concept of
Operations
Fall
Semester:
Top-Down
Design
Damping
System
Requirements
High Level
Design
Subsystem
Design
Component
Testing
Verify System
Reaches
Damping
Ratios
Verify
Subsystem
Performs as
Expected
Verify
Subsystem
Design Meets
Requirements
Subsystem
Testing
Spring
Semester:
Bottom-Up
Verification
and Validation
Assembly
Full System
Testing
41
Systems Challenges
Interfacing and
Communication
Mechanical
Integration
Subsystem
Interdependencies
• Components do not always use
the same protocol
• Communication requires more
time than expected
• Delicate parts can be damaged
by movement
• Limited volume and mass from
CubeSat regulations
• Subsystems testing progress is
dependent on one another
• Full system testing requires
each to be working flawlessly
Arduino Due
TTL
Protocol
TTL to RS-232
RS-232
Protocol
Actuator Drivers
42
Lessons Learned
•
Understanding what the objective is is crucial to the high level
design
•
Interfacing between subsystems can take much more testing time
than planned
•
Using high TRL componentry reduces testing time
•
Testing procedure will save components
•
Safety first!
•
Compromises must be made when choosing a design; there is
no perfect solution (“least worst” solution!)
43
Project Management
Original SPECTRE Schedule
1
2
3
4
5
6
7
8
9
10
11
12
13 14
15
Spring Break
Week
MSR
TRR
45
SPECTRE Schedule Accuracy
Week
1
2
3
4
5
6
7
8
9
10
11
12
13 14
•
Task Completed In
time expected
•
Task took more time
than expected
•
Task took less time
than expected
46
Schedule Discrepancies
Major Tasks Completed Ahead of Schedule
Task
Weeks
Early
Reason
Major Tasks Completed Behind Schedule
Task
Create Graphical
User interface
2 weeks
Interface was written in
MatLab instead of Labiew
Finish machining
tasks
Interface Image
Processer and Motor
Controller
1 week
Task was given excessive
margin
Testing with motors
Weeks
Late
Reason
2 weeks
Machine shop availability
was limited
3+
Weeks
Machining delays,
Driver boards replaced 2x
Interface Image
Processor and Camera
2 weeks
Development board was
changed to Raspberry Pi 2
Write and Test image
processing code
3 weeks
Language changed from
C++, Python timing was
inaccurate
Overall, Verification and Validation Tests were delayed 3 weeks,
3.5 weeks of margin were originally scheduled
47
Scheduling Approach / Lessons Learned
•
Major design modifications were made early in the semester
 Changing image processing board resulted in a 2 week setback in software
 Could have been much larger if change was made later
•
Schedules need to be flexible in case of unavoidable changes
 Schedule margin was absolutely necessary due to delays in both software and
hardware progress
•
Mistakes are sometime unavoidable and should be made earlier if possible
 Load bearing motor testing could have started earlier which could have prevented
the need for overnight shipping of replacement parts
48
Margin as a percentage of total Budget
Budget Changes / Margin Progression
60
$ 2600
$ 2410
50
$ 1950
40
30
$ 930
20
10
0
Margin at CDR
Margin at MSR
Image processing board
and camera changed
(~$200)
Margin at TRR
Bought Additional Mounting
Components (~$100)
Extra boards purchased to
Increase software
productivity (~$250)
Misc. Printing, Shipping
etc. (~$75)
Current Margin
Rotary Motor Driver
Replaced 2x (~$550)
Redundant Linear Motor
Purchased (~$275)
Expedited Shipping 2x
(~$150)
49
Budgeting Approach / Lessons Learned
•
Forecasting additional purchases can be difficult
 Project budget margin decreased by ~$1700 since CDR
•
Project margin should be put to use when possible
 Relatively inexpensive parts can be re-purchased to improve productivity
 Multiple image processor and motor controller boards were purchased so teammates
can work in parallel
•
Expensive components need to be protected
 $1000 actuators protected by voltage regulators in motor drivers
50
Industry Cost Comparison
Average Entry Level Aerospace Engineering Salary $65,000 for 2080 hours of work
$ 31.25 per hour exclusive of benefits
(8 team members) x (30 total weeks) x (20 hours / week) x ($31.25 /hour) x (200% 0verhead)
= $ 300,000 total industry cost of employee time
60x larger than project budget of $5000
From a budgetary perspective, managing employee time efficiently can have the
largest impact on the overall costs of a project
51
Backup Slides
Blade Sensing
•
The controller measures tip deflections and velocities using a camera sensor to film markers placed half the distance from th e blade
tip. The images it captures can be used to determine mode of oscillation and deflection angles.
Nominal Blade Image
•
Twisting Blade Image
Flapping Blade Image
The pixels of the markers are identified in the images by applying a YUV threshold filter and the centroids of the markers are us ed
to calculate twist and flap angles
•
•
𝜃𝑡𝑤𝑖𝑠𝑡 = atan(
𝜃𝑓𝑙𝑎𝑝 =
𝐿𝑒𝑓𝑡𝐶𝑒𝑛𝑡𝑟𝑜𝑖𝑑 𝑌𝑉𝑎𝑙𝑢𝑒 −𝑅𝑖𝑔ℎ𝑡𝐶𝑒𝑛𝑡𝑟𝑜𝑖𝑑 𝑌𝑉𝑎𝑙𝑢𝑒
𝐿𝑒𝑓𝑡𝐶𝑒𝑛𝑡𝑟𝑜𝑖𝑑 𝑋𝑉𝑎𝑙𝑢𝑒 −𝑅𝑖𝑔ℎ𝑡𝐶𝑒𝑛𝑡𝑟𝑜𝑖𝑑 𝑋𝑉𝑎𝑙𝑢𝑒
)∗
𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 𝑡𝑜 𝑏𝑙𝑎𝑑𝑒 𝑡𝑖𝑝
𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 𝑡𝑜 𝑚𝑎𝑟𝑘𝑒𝑟𝑠
𝐿𝑒𝑓𝑡𝐶𝑒𝑛𝑡𝑟𝑜𝑖𝑑 𝑌𝑉𝑎𝑙𝑢𝑒+𝑅𝑖𝑔ℎ𝑡𝐶𝑒𝑛𝑡𝑟𝑜𝑖𝑑 𝑌𝑉𝑎𝑙𝑢𝑒−𝐶𝑎𝑚𝑒𝑟𝑎 𝑌 𝑅𝑒𝑠𝑜𝑙𝑢𝑡𝑖𝑜𝑛
2
∗
𝐶𝑎𝑚𝑒𝑟𝑎𝐹𝑂𝑉
𝐶𝑎𝑚𝑒𝑟𝑎 𝑌 𝑅𝑒𝑠𝑜𝑙𝑢𝑡𝑖𝑜𝑛
Budget Breakdown
1%
5%
18%
46%
30%
Electronics
Motors
Housing
Misc
Margin
Solar Sail Blade Material
Kapton
Tape
Properties
• Constructed from Aluminum coated Mylar, total thickness of 2.64 𝛍m
• Maximum areal density of 6.0 g/m2 , allows for 2.3 g/m2 of support
material.
• Blades are stiffened by edge loading the sail with Kapton tape
• Further stiffened by adding tip mass equal to 10% of the total blade mass
Thrust
• Blades provide 4.5*10-6 N of thrust per m2 based on solar pressure at 1
AU
• Solar sail will need to accelerate the spacecraft at least 0.1 mm/s 2 to be
useful
Introduction
• For a 6U cubesat weighing approximately 8 kg, ~45 m2 deployed area needed
• Two bladed CubeSat with 2U width needs ~350 m blade length
Tip Mass
• Aspect Ratio of 2333:1
15 cm
56
Sun
Orbital Operations
• Blade can pitched in and out of solar flux to
modulate the moment for attitude control
and the thrust for orbit control
Blades pitched 90°
perpendicular to solar pressure
𝜔
• To increase/decrease spacecraft orbit
velocity blades must pitch over a 90 degree
range
 Blade dynamics need be sensed while
in the Earth’s shadow
Earth
Blades hit by solar flux
and generate thrust,
orbital velocity increases
𝑑𝑉
Blades parallel to
solar flux, orbital
velocity unchanged
𝜔
Blades pitched 90°
parallel to solar pressure
Introduction
• Two 90° pitch maneuvers are
performed during 1 LEO orbit to
maximize a change in velocity
𝜔
𝜔
57
Damping Ratios
Blades oscillations need to be small enough to preserve 95% of the surface
area of the blade exposed to the solar flux.
𝜃𝑓𝑙𝑎𝑝,𝑚𝑎𝑥 = 18.9°
𝜃𝑓𝑙𝑎𝑝,𝑚𝑎𝑥 = 25.8°
Twisting
Maximum amplitude of 90°
12.5 minute window (1/8 orbital period in LEO) for blades to settle
2.01 rad/minute oscillation frequency
25.8
= 0.0136
Flapping
Maximum amplitudes (~1° -2°) always less than 𝜃𝑓𝑙𝑎𝑝,𝑚𝑎𝑥
50% damping in ½ orbital period (45 minutes)
2.93 rad/minute oscillation frequency
ln .5
𝜁𝑡𝑤𝑖𝑠𝑡 = 2.93∗45 = 0.0073
Backups
𝜁𝑡𝑤𝑖𝑠𝑡 =
ln 1− 90
2.01∗12.5
58
Rope Ladder Analog
• Current heliogyro reseach uses a rope ladder assumption to investigate
blade dynamics
• Extremely thin sail material (2.64 𝜇𝑚 thickness) has negligible internal forces
• Assumes the sail blade material has no stiffness or internal damping
• Rope ladder assumption allows for blades to be constructed from support
materials alone for blade testing
• Reduction in surface area results in less damping being provided by air
7
Hz
15
String/Wire
Blade
Skeleton
Rope Ladder Blade Diagram
Kapton
Tape
Regular Sail Blade
Introduction
1
3
• 2.2 meters in length, 𝑓𝑓𝑙𝑎𝑝 = Hz, 𝑓𝑡𝑤𝑖𝑠𝑡 =
Tip Mass
Tip Mass
15 cm
15 cm
59
Frequency Testing Tested Blades
Several “Rope Ladder” blades with masses similar to sail blades of the same area were built to
test the accuracy of the frequency estimates
• Modes were excited manually and filmed to observe frequencies
Blade Tip
• Blade Frequencies matched predicted frequencies, < 3% error
•
Marker
Length (m) Width (m)
AR
Mblade(g)
Mtip(g)
1
1.5
0.1
15
0.034
0.12
2
1.5
0.1
15
0.034
2.04
3
1
0.1
10
0.023
0.13
4
1.5
0.2
7.5
0.034
0.24
𝑓𝑓𝑙𝑎𝑝
𝑓𝑓𝑙𝑎𝑝
𝑓𝑡𝑤𝑖𝑠𝑡
𝑓𝑡𝑤𝑖𝑠𝑡
%
%
Blade Predicted Observed Error Predicted Observed Error
0.428
0.400
0.508
2.00 0.588
1.71 0.571
0.04 0.7122
0.600
0.577
0.732
2.04
3
0.420
0.407
0.509
4
0.414
0.417
0.72 0.579
0.588
1.15
1
2
1.05
2.73
Camera
Scaled Test Blade Being Filmed
Backups
Blade
Motion of
Blade
60
Testing Overview
Electrical/Software Timing
Time between receiving
packets is measured in
MatLab.
Adjustments
are made until 4 Hz
requirement is reached
Camera
→ Raspberry Pi → Arduino → MATLAB
61
Testing Overview
Maneuverability
Pitch command sent
to rotary actuator
62
Previous CONOPS
2.
63
Testing Overview
Twist Mode Damping
Images captured with
Raspberry Pi provide
angle and velocity to
Matlab, where the
results are plotted for
the twist mode with
the controller on
Uncoupled Twist
mode is excited
manually, with
controller on
Top-Down View
Blade Root
θtwist
Blade Tip
64
Time Requirements
●
Backups
●
The Controller Continues to act like a controller at
.91 seconds
At 1 second the controller does not display the
desired characteristics
1 second Time step
.91 Second Time step
65
Linear Actuator Position
Rotary Actuator Position
Backups
Requirement for Actuators
66
Resolution of 4 degree
Resolution of 3 degree
Backups
Requirements for Rotary Actuators
67
Resolution of 3mm
Resolution of 1.4mm
Backups
Requirements for Linear Actuators
68
Angular Acceleration
Linear acceleration
Backups
Requirements for Actuators
69