Transcript CUBIK - Virginia Tech

CUBIK
CubeSat Universal Bus Integrated Kit
The
NeoCubists:
David Carton
Fadi Mantash
Julien Pierru
Ryan Reisman
Ankit Singhal
Robert Thompson
Bryan Tisinger
“It’s not the size of the satellite that matters”
Systems Analysis Design Process

Weigh Relative Merits of Subsystems
Options Against Each Other and
Constraints

Determine Interactions Between
Subsystem Options
Primary Design Constraints
Maximum Mass: 1 Kg
Maximum Cost: $2,500
Minimum Life: 1 Year
Other Design Constraints and
Preferences

Power Generation: Solar Panels Only, 5 of 6
sides required
 Minimum 50% of Internal Volume
Available for Third Party Payloads
 Deployable Structure/Systems by
Permission Only
Subsystems

Structure
 Power
 Communications

Software
 Flight Computer
 ADCS
Power Subsystem Goals

Generate, store, regulate, and distribute
power
 Provide constant power through eclipse
 Supply enough power to meet average and
peak loads
Power Subsystem Options

Batteries
– Nickel cadmium (NiCd)
– Nickel metal hydrides
– Lithium Ion

Regulation
– Shunt voltage regulator
– Series voltage regulator
– Integrated circuit regulator
Power Subsystem Analysis
Power Subsystem
Power Generation
(Solar Cells)
Power
Regulation/Distribution
Power Storage
(Batteries)
Other
Subsystems
Battery Analysis
Graphs courtesy of Toshiba-Europe
Shunt vs. Series Regulators
Courtesy of Integrated Publishing
Power Subsystem Analysis
Results

Lithium ion batteries perform best of the three
types shown
 Power must be regulated to several different levels
before being distributed to subsystems and
batteries (multiple regulators may be needed)
 Integrated circuit regulators would be more
efficient, cost effective, and have less mass than
shunt or series regulators wired on a breadboard
Communication Interactions
Software
Structure
Power
Communications
ADCS
Flight computer
Communication Subsystem
Goals

Ability to receive information from ground
station and transmit data or information
from satellite to ground station.

This has to be done at minimum power
consumption.
Communication Subsystem
Communication System Components
Communication System
Transponder
Antenna
Communication Subsystem
Transponder Analysis
Transponder
# of stations
receiving
signal
Power
Production
Cost
FM
1 at a time
2 mW
$100
Linear
20+
3 mW
simultaneous
users
Readily
available
chips
May require
special order
or design
$20 and
up
(depending
on design)
Communication Subsystem
Antenna Analysis
Antenna
type
Size
Circular
2m or 70 cm $300- High and
$400 lasting
quality
0.5m - 1m
$50- Fades
$100 quickly
Single
plane
Cost
Quality of
reception
# needed
1
3 or 4
Communication Subsystem
Analysis Results
Transponder:
 The FM transponder is a very high quality transponder and is
readily available, with a disadvantage being the number of
receiving stations.
 Linear transponder can be accessed by multiple ground stations
however production cost could be higher in order to meet user
requirements.
The transponder choice will greatly depend on the time of
direct communication needed with satellite.
Communication Subsystem
Analysis Results
Antenna:

Single plane antennas are better in terms of size and cost
but not in in terms of signal reception.

Choice of antenna will greatly depend on amount of
money we can allocate to this subsystem and the type of
experiments we will allow our users.
Flight Computer Subsystem
Goals
• The heart of the CubeSAT – so computer must be stable!
• To regulate the performance of the bus
• To communicate with other subsystems of the unit and to
maintain a synchronization between them
•To store the experimental data and perform the necessary
computations
Flight Computer Subsystem
Analysis
• The flight computer is comprised of “A Processing Center”, “A
Storage Unit” and “A Control Unit”
• The flight computer receives commands from the ground station
and sends them to the flight computer software for interpretation. On
getting a response from the flight software it directs the command to
the appropriate subsystem for execution.
• The flight computer is responsible for the power regulation, the
communication and the data storage and computation for the Unit.
Flight Computer Subsystem
Analysis Results
• Based on the functionality of the Flight Computer, this Subsystem
can be designated as the “Heart” of the entire unit
• Every subsystem communicates to and from the Flight Computer for
instructions on the next mode of operation
• This subsystem is the common interface for the various subsystems
among themselves
• The Flight Computer is the bridge between all the subsystems of the
Unit
Flight Computer Flow Diagram
Ground Station
Command
Flight Computer
Command
Response
Power
Communications
ADCS
Flight Computer
Flight Computer Software
Subsystem Goals
FCS must consist of a Real Time
Operating System
●Handle telemetry formatting and
communications decoding
●Handle drivers for spacecraft
components
●Be Open Source
●
Flight Computer Software
Subsystem
The Flight Computer Software architecture
looks like the following:
Real Time Operating System
Communication Decoding
Software
Telemetry Formatting Software
Spacecraft Components Drivers
Payload
Power
ADCS
Flight Computer Software
Subsystem Analysis
Operating
System
Supported
Architecture
License
Source code
availability
Real
Time
Integrated
Compiler
Linux
Intel, AMD Alpha
SPARC
PowerPC
GPL
Yes
C/C++
Intel, AMD
MIPS
PowerPC
GPL
Yes
Partly
No
Separate
module
Microcontroller
Motorola, Hitachi
GPL
Yes
Yes with
patch
C/C++
QNX
uClinux
Yes
Flight Computer Software
Subsystem Analysis Results
•Linux is a very powerful, lightweight and multiarchitecture RTOS,
available through multiple distributions (Red Hat, Mandrake, SuSE,
Debian…), and totally open source.
•QNX has the same characteristics as Linux though the facts that its code
is not entirely open source and that no integrated compiler exists with the
RTOS lead to a less easy to use system.
•uClinux, the Linux OS built specially for microcontrollers has one
drawback: it is not originally Real Time. A patch has to be installed
afterwards.
•There also exists RTOS specially designed for specific microcontrollers,
but they tend to be less polyvalent, designed to work well for one specific
task.
•For the software, different object oriented languages exist, C/C++,
ADA; but among the developers team and customers, the C language is
the most widely known.
Structure Subsystem Goals

Provide structural support for bus
components, control elements, and payload

Mitigate thermal effects
from bus components
and/or from the environment
[Titech CubeSat, 2001]
Structure Subsystem Options

Structural Elements
– Material:
Al alloy, Mg alloy, Stainless Steel
– Panels:
Shape, thickness (< 1/8”)
– Posts (rails): L-shaped, solid, square tube

Internal Structure
– Bus:

Custom design, use a PC form factor
Thermal Regulation
– Passive (coatings, heatsink)
Structure Subsystem Analysis
a*
Availability†
Machinability‡
23.6


2700
23.6


Mg AZ31
1770
26.0


Stainless
Steel 304
7900
16.6


Material
Density
(kg/m3)
(µm/C)
Al 7075
(P-POD)
2810
Al 6061
* Coefficient of Thermal Expansion, per linear meter at 20C
† Rating based on range of available sizes, thicknesses, extruded shapes
‡ Rating based on ease of fabrication: welding, cutting, forming, safety precautions
Structure Subsystem Analysis

Internal Structure

Height
(mm)
Width
(mm)
Depth
(mm)
Available*
48.0
96.0
96.0
PC/104
15.1
90.2
95.9
Thermal Regulation by the Structure
– Operating range -40C to 80 expected†
– Passive thermal control: heatsink, coatings
* Assuming 1/8” (3mm) thick panels
† Sources: TiTech Cubesat FE analysis, PolySat Cal Poly
Structure Subsystem Analysis
Results

Aluminum alloys for structural elements
– Similar properties as P-POD material (Al 7075)
– Low density metal
– Easily worked
– Good machinability
– Commonly available
– Extruded shapes available
[Cuesta CubeSat, 2001]
ADCS Subsystem Goals

Determine current orientation of satellite
 Recover from sensor blackouts
 Initiate proper orientation as programmed
 Maintain proper orientation or change
orientation as programmed
 Missions Undefined: Therefore one system
that can handle all modes of attitude control
optimal for flexibility and usability
ADCS Subsystem Options

Determination Sensors
–
–
–
–
–
–
–
Sun Sensor
Star Sensor
Horizon Sensor
Magnetometers
GPS Receiver
Gyroscope
Combinations of any of above
ADCS Subsystem Options Cont.

Control Actuators

Control Type
– None
– None
– Gravity-gradient Boom
– 1 Axis Stability
– Magnetic Torques
– 3 Axis Stability
– Pure Spin Stabilization
– Bias Momentum
(Momentum Wheels)
– Zero Momentum
(Reaction Wheels)
ADCS Subsystem Interaction
Signal
Determination
Sensors
Command
Flight
Computer
Force
Attitude
Control Actuators
ADCS Flow
Possible Interference Interactions
Structure
Customer
Payload
And Other
Electronics
Determination Analysis

Optimal:
–
–
–
–

Options:
–
–
–
–

High Accuracy
Functionality even during sensor blackouts
Meets cost and mass constraints
Unaffected by other systems
Sun and Horizon sensors
Sun and Star sensors
Sun sensor and Magnetometer
Sun and two of three (Horizon, Star, Magnetometer)
Determination Analysis Not Yet Complete- Still
gathering data on sensor sizes available and cost
Attitude Control Analysis

Optimal:
– High Pointing Accuracy
– All 3 stability options (none, one-axis, three-axis)
– Meets cost and mass constraints
– No impairment of other systems

Options:
– 3 Reaction/Momentum Wheels
– Magnetic Torque and 2 Reaction/Momentum Wheels

Attitude Control Analysis Not Yet Complete- Still
gathering data on actuator sizes available and cost
ADCS Subsystem Analysis
Results

Multiple sensors needed for determination
 Two control systems exist allowing all three
forms of stability
 Mass and cost will make final
determination. Data still being gathered
Resultant Designs
Conclusion


Based on each subsystem’s goals, alternative
options were developed. System analysis allows
for a way to model the options for each subsystem
and to determine how subsystems interact with
each other
The analysis of each subsystem is important. The
alternative solutions for each subsystem objective
must be evaluated before we can move on to
optimization of each alternative
Questions?