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 G eneration (Solar Cells) Power Regulation/Distribution Power Storage (Batteries) O ther Subsystem s 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 20C † 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 -40C 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?