Final Design Report for Obsolete Satellite Capture And Removal (OSCAR)

Version 2.0 12/11/2015

Prepared By: Jake Adzema Alex Austin

Austin Kubiniec Colin Lenhoff Alexander Malin Ryan Moriarty Jesse Pelletier

Rensselaer Polytechnic Institute

Executive Summary

Space travel has recently received increased attention from the United States government due to the high costs associated with missions. To address the high costs associated with the industry, there has been increased pressure to reduce the size of satellites, while retaining performance capabilities. NASA funding has recently begun to support the design and development of CubeSats. These satellites push forward the boundaries of engineering and science in order to meet the stringent requirements set forth for future missions.

In addition to decreasing the size of satellites, there has also been a focus on using commercially available parts in the satellites. These commercial off the shelf (COTS) parts are used with the intent to reduce the production costs of the CubeSats while also increasing the reproducibility of successful satellite systems. If a satellite can be developed as a CubeSat to solve a specific problem then, after the successful demonstration, relatively large production can occur with very drastic reduced costs. COTS parts allow for the satellite to be very cheap compared to ones that use individually designed and manufactured parts.

In order to direct the development of CubeSats, space agencies have encouraged designs to concentrate on reducing the debris that is currently in orbit around Earth. The team used this focus in researching and analyzing components to design the Obsolete Satellite Capture and Removal CubeSat (OSCAR). This system will be deployed in low­earth orbit (LEO), rendezvous with and capture a debris object, and then de­orbit both the CubeSat and the captured debris. This active debris removal concept is the best CubeSat design for cleaning space.

The team performed structural, power, thermal, radiation, data and communication analysis, in tandem with Systems Tool Kit (STK) simulations, to determine the capabilities of OSCAR and ensure success in deorbiting target debris. The team also developed and built a custom payload required to capture the debris with a net in order to ensure manufacturing feasibility and space allocation. Currently the team is awaiting sponsorship to continue more detailed analysis and begin construction of a test model.

Providing continuation of this project, the team foresees a future in which OSCAR CubeSats could be available at a moment's notice to send up as a secondary payload, which due to their highly autonomous nature, will be able to bring down debris objects effectively and safely. Over time, OSCAR will be able to have a significant impact on the amount of debris in orbit by removing the garbage in space.

1

Table of Contents

Executive summary………………………………………………………………………………..1 Table of Contents………………………………………………………………………………….2 List of Figures……………………………………………………………………………………..5 List of Tables…………………………………………………………………...………....……....7 Terms and Abbreviations………………………………………………………………………….8 1. Introduction………………………………………………………………………………......10 2. Project Objectives………………………………...……………………………………….…12 3. Customer Requirements……………………………………………………………………...13 4. Background on Existing Technology and Technical Standards. .…………..………….........14

4.1 Cubesat Technology Summary…………………………………...……...…………..14 4.2 Existing Research in Space Debris De­orbit Devices……………………..…………15

5. System Requirements and Design Constraints…………………………………………...…...18 5.1 Mission……………………………………………………………………………….18

5.1.1 Mission Overview………………………………………………………….18 5.1.2 Mission Success……………………………………………………………19

5.2 Structures…………………………………………………………………………….20 5.3 Propulsion……………………………………………………………………………20 5.4 Attitude Control……………………...………………………………………………20 5.5 Thermal Management………………………………………………………...……...21 5.6 Power………………………………………………………………………………...21 5.7 Command and Data…………………………………………………………………..21 5.8 Telecommunications…………………………...…………………………………….22 5.9 Payload……………………………………………………………………………….22

5.9.1 Debris Sensing Device……………………………………………………..22 5.9.2 Debris Capture Device……………………………………………………..22

6. System Concept Development and Selection…………………………..……………………..23 6.1 Structures…………………………………...………………………………………..22 6.2 Propulsion……………………………………………………………………………23 6.3 Attitude Control………………………………………………...……………………25 6.4 Thermal Management……………………………………………...………………...27 6.5 Power………………………………………………………………………………...29 6.6 Command and Data…………………………………………………………………..33 6.7 Telecommunications…………………………………………………...…………….34 6.8 Payload……………………………………………………………………………….36

6.8.1 Debris Sensing Device……………………………………………………..36 6.8.2 Debris Capture Device……………………………………………………..37

2

7. Design Analysis……………………………………………………………………………….39 7.1 Structures…………………………………………………………………………….39 7.2 Propulsion…………………………………………………………………………....39 7.3 Attitude Control……………………………………………………………………...42 7.4 Thermal Management………………………………………………………………..52 7.5 Power………………………………………………………………………………...53 7.6 Command and Data…………………………………………………………………..61 7.7 Telecommunications………………………………………………………………....61 7.8 Payload……………………………………………………………………………….65

7.8.1 Debris Sensing Device……………………………………………………..65 7.8.2 Debris Capture Device……………………………………………………..66

8. Final Design and System Evaluation………………………………………………………….71 8.1 Final System Overview………………………………………………………………71 8.2 Structures…………………………………………………………………………….72 8.3 Propulsion……………………………………………………………………………72 8.4 Attitude Control……………………………………………………………………...73 8.5 Thermal Management………………………………………………………………..73 8.6 Power………………………………………………………………………………...73 8.7 Command and Data…………………………………………………………………..74 8.8 Telecommunications…………………………………………………………………74 8.9 Payload……………………………………………………………………………….74

8.9.1 Debris Sensing Device……………………………………………………..74 8.9.2 Debris Capture Device……………………………………………………..75

9. Future Work…………………………………………………………………………………...76 9.1 Structures…………………………………………………………………………….76 9.2 Propulsion…………………………………………………………………………....76 9.3 Attitude Control……………………………………………………………………...76 9.4 Thermal Management………………………………………………………………..77 9.5 Power………………………………………………………………………………...77 9.6 Telecommunications………………………………………………………………....77 9.7 Command and Data…………………………………………………………………..77 9.8. Payload………………………………………………………………………………78

9.8.1 Debris Sensing Device……………………………………………………..78 9.8.2 Debris Capture Device……………………………………………………..78

9.9 General Aspirations………………………………………………………………….79 10. Risk Analysis………………………………………………………………………………...80 11. Conclusions and Future Goals……………………………………………………………….82 12. Works Cited………………………………………………………………………………….83 Appendix A: Specification Sheets……………………………………………………………….87

3

A­1 Command and Data Computer System……………………………………………...87 A­2 Attitude Control System…………………………………………………………….89 A­3 Telecommunications System………………………………………………………..98 A­4 Power System……………………………………………………………………...101 A­5 Propulsion System………………………………………………………………....104

Appendix B: Component List and Cost………………………………………………………...106 Appendix C: Code……………………………………………………………………………....107

C­1 Telecommunications……………………………………………………………….107 C­2 Thermal Management……………………………………………………………...108 C­3 Power……………………………………………………………………………....109 C­4 Attitude Control…………………………………………………………………....113

Appendix D: Supplementary Figures…………………………………………………………...116 Appendix E: Team Member Contributions……………………………………………………..117

4

List of Figures Figure 1.1: Impact From Fleck of Paint…………………………...……………………………..10 Figure 4.1: CubeSat Missions Sorted by Mission Type………...…………...………………….14 Figure 4.2: 3U CubeSat Structure with Deployable Solar Panels.…..….……...…………….….15 Figure 4.3: Concept Image of Net Grabbing a Piece of Space Debris……….…..………….…..16 Figure 4.4: Balloon Inflated to Increase the Atmospheric Drag on a Piece of Space Debris…....16 Figure 7.1: Prograde Nodal Precession Over Quarter of a Year…………………………………40 Figure 7.2: Hohmann Transfer From 800 km to 300 km Circular Orbits………………...……...40 Figure 7.3: Retrograde Nodal Precession Over Quarter of a Year………...…………………….41 Figure 7.4: Initial Approximations of Target Debris Using MPS­120 Propulsion System...……42 Figure 7.5: Coordinate System Rotation About Z Axis by Angle ……......…………………...43θ Figure 7.6: Block Diagram of Simulated Control Algorithm…………......……………………..47 Figure 7.7: Error Quaternions with Initial Orientation Error and No Noise……………………..47 Figure 7.8: Angular Rates with Initial Orientation Error and No Noise………………...……….49 Figure 7.9: Error Quaternions with Initial Orientation Error and Significant Noise…………….49 Figure 7.10: Angular Rates with Initial Orientation Error and Significant Noise…………….....49 Figure 7.11: Error Quaternions with Initial Orientation Error and Kalman Filter…………….....50 Figure 7.12: Angular Rates with Initial Orientation Error and Kalman Filter……………..…….51 Figure 7.13: Angular Rates with Initial Orientation Error and Initial Angular Rates……….…..52 Figure 7.14: Depiction of Earth’s Shadow Regions……………......……………………..……..54 Figure 7.15: Earth’s Shadow Approximation…………………...…………………….……..…..54 Figure 7.16: Variables Used to Calculate Gamma………………...…………………....…..……55 Figure 7.17: Beta Angle………………………………………...……………………....………..56 Figure 7.18: Power Supply…………………………………...…………………………..……...57 Figure 7.19: Power Out……………………………………...……………………….…….…….58 Figure 7.20: Battery Charge……………………………….………………………………....…..59 Figure 7.21: Excess Power…………………………………………………………………….....60 Figure 7.22: Frames per Second Calculated from FPGA Research……………………………...63 Figure 7.23: Calculation of Slant Range…………………………......…………….………...…..64 Figure 7.24: STK Simulation of Ground Tracking………………………......…..………….…...65 Figure 7.25: Payload with Sensing System Deployed…………………………………….....…..65 Figure 7.26: ESA Net Entanglement Simulation………………….....……..…….……....……...67 Figure 7.27: ESA Net Entanglement Microgravity Testing………………………......……........67 Figure 7.28: Net Device CAD Model………………….…………..……...……………………..68 Figure 7.29: Full­Scale Net Device Model Isometric View…………….…………….………....69 Figure 7.30: Full­Scale Net Device Model Front View…………………………………….........70 Figure 7.31: Full­Scale Net Device Model Side View………...………………………...……....70

5

Figure 8.1: CubeSat Subsystem Layout………………………………………………………….71 Figure 8.2: Complete CAD Rendering with Antenna and Sensing System Payload Deployed....72

6

List of Tables Table 6.1: Propulsion System Selection Matrix………..……………..………………………....24 Table 6.2: ACS Selection Matrix…………...…………...……………………………………….26 Table 6.3: Thermal Requirements of Satellite Components……..………….…………………...27 Table 6.4: Properties of Different Thermal Control Paints………………….…………………...28 Table 6.5: Expected Power Draw…………………………………..……………………………29 Table 6.6: Selection Matrix for Power Supply Selection…………..…………..………………..30 Table 6.7: Power Storage Selection Matrix…………………………………...………………....31 Table 6.8: EPS Selection Matrix………………………………………...……………………….32 Table 6.9: Data Processor Component Selection……………………………...……..…………..33 Table 6.10: Telecommunications Component Selection…………………………..……..……...35 Table 6.11: Debris Capture Mechanism Selection Matrix…………………..………..………….37 Table 10.1: Risks and Challenges………………………………………………………………..81

7

Terms and Abbreviations ACS ­ Attitude Control System AGI ­ Analytical Graphics Inc. B ­ Byte BIPS ­ Billions of Instructions per second CAD ­ Computer­Aided Design CCD ­ Charge­Coupled Device CHAMPS ­ CubeSat High­Impulse Adaptable Modular Propulsion System cm ­ Centimeter COTS ­ Commercial Off The Shelf cPCI ­ Compact Peripheral Component Interconnect dBic ­ Decibels referenced to a circularly polarized, theoretical isotropic radiator dBm ­ Decibel­milliwatts DCM ­ Direction Cosine Matrix EPS ­ Electric Power System ESA ­ European Space Agency FOS ­ Factor of Safety FOV ­ Field of View FPGA ­ Field Programmable Gate Array GB ­ Gigabyte I2C ­ Inter­Integrated Circuit IPS ­ Instructions per second ISIS ­ Innovative Solutions in Space KB ­ Kilobyte KB/s ­ Kilobyte per second Kbps ­ Kilobit per second Kg ­ Kilogram LEO ­ Low­Earth Orbit MB ­ Megabyte MIPS ­ Millions of Instructions per second MLI ­ Multi Layer Insulation mW ­ Milliwatts MWIR ­ Medium Wavelength Infrared OSCAR ­ Obsolete Satellite Capture and Removal P­POD ­ Poly Picosat Orbital Deployer SEFI ­ Single­Event Functional Interrupts SEL ­ Single Event Latchup

8

SEPP ­ Solar Electric Power Propulsion SEU ­ Single Event Upset SPI ­ Serial Peripheral Interface STK ­ Systems Tool Kit (Software by AGI) TID ­ Total Ionizing Dose TRL ­ Technology Readiness Level U ­ CubeSat Unit UART ­ Universal Asynchronous Receiver/Transmitter UHF ­ Ultra High Frequency VHF ­ Very High Frequency

9

1 Introduction

The accumulation of non­operational objects in near­Earth space poses a severe threat to space vehicles that could be compromised, if not fatally struck, by an object in orbit. Some of these objects are large enough that they can be tracked and monitored from Earth, but these are only objects greater than about 10cm. Most debris, however, is too small to be tracked from Earth, making the threat of space debris very realistic. Furthermore, this threat will not be mitigated without an active solution. This is because the rate of objects being launched into orbit exceeds the rate at which debris naturally de­orbits, leading to a net increase in debris. The problem could be alleviated by simply reducing the number of objects launched into orbit, but this would greatly hinder mankind’s ability to conduct research, exploration, utilization, and discovery of space. The objective is to mitigate the threats posed by space debris so that new space vehicles can continue to be launched safely, thus promoting the development of exceptional space science.

Even if no more objects are launched into orbit, the total amount of debris in orbit could still increase solely as a function of time by a phenomenon termed the Kessler Effect. The Kessler Effect is the process by which objects in near­Earth orbit collide with each other and break into smaller fragments, which in turn collide with other objects. Not only does the number of objects in orbit increase, but their average size decreases. This means that objects large enough to be tracked could potentially be rendered untraceable, increasing the danger posed by these objects. This danger is emphasized in the figure below, which shows a crater 4mm wide in the windshield of a spacecraft caused by impacting a fleck of paint 0.2mm wide. Relative to the velocity of the spacecraft, the paint fleck was traveling between 3 and 6 km/s.

Figure 1.1: Impact From Fleck of Paint (Helvajian, 2008).

10

There are some proposed methods by which debris in space can be de­orbited, but many of these are still in the concept development phase (Howell, 2014). This product is expected to show significant advancements in debris de­orbit feasibility. While there is ongoing research in space debris de­orbit techniques, this product is especially unique due to its size. The vehicle is a CubeSat, a nano­satellite that can be easily added to a launch vehicle already scheduled for flight. This greatly reduces the launch cost of the vehicle. Such launching is feasible because CubeSats are made of common 10cm cubic units, known hereafter as U’s. These units have standard dimensions, so it is fairly easy for a launch vehicle designer to account for an extra CubeSat payload as long as the size of the CubeSat is known. The size of a CubeSat also makes it less susceptible to being struck by debris. OSCAR is a 3U CubeSat, which is advantageous because it is a very common configuration that has been launched numerous times. While 3U CubeSats are common, this vehicle is unique in that most 3U CubeSats are custom vehicles. Furthermore, except for the payload, this product is fully comprised of flight­proven hardware. Developing a product entirely from flight­proven commercial off­the­shelf (COTS) hardware (with the exception of the payload) would be a great advancement. While it is crucial that the proposed product shows advancements in debris de­orbit technologies, it should be emphasized that fundamental operating principles of the spacecraft will show promise in more demanding and diverse missions. These principles include the spacecraft’s structural architecture, object rendezvous methods, and simulation techniques, among others.

11

2 Project Objectives The objective of this project will be to produce a preliminary design of a CubeSat based

spacecraft to demonstrate and evaluate key COTS hardware technologies for space debris removal. This design is separated into several subsystems designed based on capability, cost, power, mass, and space requirements, and through assessing the risks and challenges to which the subsystems may be subjected. The group divided responsibility for one subsystem to each of the team members based on personal preference and expertise. This report will detail the reasoning and methodology behind the component selection for each subsystem, as well as a system integration plan for the entire CubeSat.

The final satellite design must consider the constraints placed by the following customer requirements:

1. Debris to de­orbit within five (5) years of intercept by the CubeSat. 2. Significant autonomous capability in vicinity of target debris object. 3. Identify hardware failure modes and upgrade requirements to support space debris de­orbit missions. 4. Consider extension to future non­debris missions such as Near­Earth asteroid rendezvous or other valued science missions. The team will submit both a detailed design report for review and a presentation to

demonstrate the entire system’s feasibility. This report reflects the input from a peer review of the group’s midterm design review. The goal will be to move forward with prototyping based off of this design report. The team will also present ideas for furthering our concept in the future.

12

3 Customer Requirements As discussed in the introduction, space debris causes a present and future threat to

manned space flights, satellites, and other space missions. There are two major types of customers which can be identified as being interested in the removal of debris from space: the public customer and the private customer.

The public customer can be identified as NASA, the ESA, or any other space agency. Their efforts in the removal of space debris are motivated by the knowledge that decreasing the hazards of space will allow for an increase in manned space missions and the further exploration of space. They are removing space debris with the intention of not only benefiting themselves and their future missions, but the missions of others. The public customer is the likely source of funding for this project, as they know that its successful development will allow other countries or companies to use the final product at a reduced cost compared to a privately developed project.

The private customer can be said to be a non­governmental agency operating missions in space performing tasks ranging from taking images of Earth to delivering supplies to the International Space Station. Two main motives have been identified for a private space company to remove debris from orbit, the first being that it endangers their property. Satellites carry fuel to perform orbital maneuvers which puts them out of reach of space debris, but the amount of fuel they can carry is extremely limited and the more maneuvers a satellite has to perform, the shorter its mission life will be. The ability to remove dangerous space debris from the orbit of a satellite allows the company to conserve more of their satellites’ resources, enabling a longer mission life. The secondary motive as to why a private company would be interested in the project lays mostly in the removal of space debris that it inadvertently produced. According to NASA, accidental explosions are the primary source of long­lived space debris in LEO (NASA Standard 8714). While regulations are in place to reduce the chances of explosions happening (and debris being produced), accidents always happen, and the company may be required to clean up the mess they created. This project provides a good way to de­orbit nanosatellite­sized debris in a quick manner, as both customers require that the entire system deorbits in less than 5 years.

13

4 Background on Existing Technology and Technical Standards 4.1 CubeSat Technology Summary

The origin of the CubeSat can be traced back to California Polytechnic State University and Stanford University, where in 1999 Professors Robert Twiggs and Jordi Puig­Suari developed the original design which has now become the standard (National Reconnaissance Office). The original CubeSat idea came about as a way to support hands­on university­level space exploration and education with a low­cost solution to launch science experiments into Earth orbit (Some useful information about CubeSats). Since the year 2000, over 350 CubeSat missions have been launched. These missions have been carried out by universities, corporations, the military, and civilians with over fifty percent ending in success or continuing operation. Figure 4.1 shows the distribution of all CubeSat missions sorted by mission type. (CubeSat Database). It can be seen that the large majority of missions have been carried out in the last three years, with commercial missions becoming the largest contributor.

Figure 4.1: CubeSat Missions Sorted by Mission Type (CubeSat Database)

The CubeSat standard definition of a U is scalable, allowing for larger structures, such as 2U, 3U, or 6U, which consist of a group of cubes attached together. The expansion of the CubeSat industry has resulted in a large availability COTS hardware. This includes CubeSat

14

structures of varying sizes as well as propulsion systems, attitude control systems, solar panels, and communications systems. The prevalence of COTS hardware allows for a high degree of customization for different CubeSat missions while keeping the total cost of the spacecraft low (Some useful information about CubeSats). Figure 4.2 shows an example of a 3U CubeSat structure with deployable solar panels built using COTS parts.

Figure 4.2: 3U CubeSat Structure with Deployable Solar Panels (NASA, 2015)

In addition to the CubeSat standards on the size of the structure, the compatibility with

the launch device is highly critical. CubeSats are generally launched from a P­Pod, which is a device that is mounted within the upper stage of the launch vehicle. The P­Pod can hold anywhere from three to six CubeSats. Once the primary payload is free of the launch vehicle, a radiant heater severs a Vectran line to open the P­Pod door. The CubeSats are then ejected by a spring mechanism (Isaac Nason, 2002). The P­Pod structure is usually added to a launch vehicle designed to carry a much larger payload to orbit. In this way, the additional resources to bring the CubeSat to space are incredibly low when compared to a dedicated launch of a large satellite. This makes launches incredibly affordable. 4.2 Existing Research in Space Debris De­orbit Devices

There are a number of proposed methods for de­orbiting space debris which can be used as inspiration for new ideas to be implemented on the CubeSat structure. One of these ideas, currently being developed by the European Space Agency (ESA), is a satellite which could be used to deploy a large net that would entangle itself around a piece of debris. Figure 4.3 shows a concept image of what this system might look like. The satellite would then de­orbit itself, pulling the debris along with it, where both structures would burn­up during atmospheric re­entry. Scale testing of the net deployment device in zero gravity has been conducted to validate launch and entangling methods around objects of arbitrary shape (Want To Snag A Satellite).

15

Figure 4.3: Concept Image of Net Grabbing a Piece of Space Debris (Want To Snag A Satellite)

Another de­orbit concept which could be applied to CubeSats is a device that would rendezvous and attach to a piece of debris before inflating a large balloon. This would increase the atmospheric drag on the spacecraft, accelerating the natural orbital decay that would eventually cause the debris to burn up on reentry into the atmosphere. This balloon would be made of a very thin material so that, in the event that another piece of debris strikes it, that debris will not break up into many smaller pieces. Figure 4.4 shows a concept image of this type of device in operation after inflating the large balloon (Global Aerospace Corporation).

Figure 4.4: Balloon Inflated to Increase the Atmospheric Drag on a Piece of Space Debris (Global Aerospace Corporation)

16

Still another method of de­orbiting space debris that is currently being studied is an electrodynamic tether. This device consists of a 300 meter or longer wire that will be attached to a piece of debris. As the wire moves through the Earth’s magnetic field, it will generate an electric current that will slow the debris and pull it into a lower orbit. This will continue until the debris burns up during atmospheric reentry (Parabolic Arc, 2014). It is possible that a similar device could be adapted to be deployed from a CubeSat for smaller pieces of debris.

17

5 System Requirements and Design Constraints 5.1 Mission

5.1.1 Mission Overview OSCAR’s mission can be laid out into 7 stages: launch, deployment, initialization,

rendezvous, localization, capture, and deorbit. This process takes the satellite from the ground into orbit, where it will rendezvous and capture a piece of debris, before decreasing its altitude until both the CubeSat and debris object burn up upon reentry into the atmosphere.

The first stage, launch, starts with the CubeSat being sent into orbit as a secondary payload on a rocket within a P­POD. This rocket will most likely be in a sun­synchronous orbit, at an inclination of 95­105° and an altitude between 600 to 800 km. Since this type of launch is the most common for all observation objects, we can assume that OSCAR will most likely start in an orbit within this range of parameters.

The next stage, deployment, starts when OSCAR is jettisoned from the P­POD. Due to irregularities in the release mechanism of the P­Pod, OSCAR will immediately start tumbling through space. Once it has traveled a safe distance away from its launch vehicle, the antenna will deploy, power will turn on, and a systems check will be run on all subsystems to make sure they have survived launch and are still operational. Then, OSCAR will begin broadcasting its status and wait to make contact with the ground station.

The beginning of the initialization stage can be marked as the point when OSCAR makes contact with the ground station for the first time. At this point, the attitude control system (ACS) is activated and OSCAR begins detumbling. Once detumbling is complete, the sun is located, and OSCAR orients itself so the solar panels can begin producing power. Finally, the ACS spins up the craft for added stability. If all systems are listed as go, OSCAR will move on to the next step, rendezvous. Otherwise, the mission is declared a failure and it moves to the final step, deorbit, in order to eliminate the possibility of introducing any new space debris.

During rendezvous, the longest stage of the mission so far, OSCAR receives the orbital parameters of a debris object close to it, and begins the process of matching its orbit through a series of orbital maneuvers such as precession, inclination changes, and phasing maneuvers. During this stage, all remaining subsystems are activated and start continuously operating to keep the spacecraft powered, stable, at an acceptable temperature, and in communication with the ground. The rendezvous section of the mission may take multiple months, or even a year, depending on the location of the debris object, as it will be important to conserve fuel for the deorbit phase of the mission.

Once OSCAR is about 10 meters away from the target, the localization stage begins. At this point, the ground station accuracy is reached, and OSCAR must switch to tracking the object

18

by deploying its stereo vision sensing system. Once the target is located, OSCAR will slowly move towards it, stop (relative to the object, of course), and evaluate the target. The onboard computer will be used to perform an image processing algorithm that will render a three­ dimensional image for further analysis. OSCAR will move on to the next stage of the mission if the target meets all of the following criteria: approximately 10x10x10 cm, 2.5 kg, limited or no tumbling, solid, sharp edges. If not, a different target is selected, and the rendezvous stage begins again.

Once the target passes all criteria, OSCAR moves on to the capture stage, initiated by the computer. First, the spacecraft repositions and reorients itself by moving past the object, then completely turns around so that a retrograde burn will maneuver the satellite towards the debris. Next, the net is fired, which will entangle the object completely. Finally, the object is pulled back to the CubeSat to prevent a collision during the deorbit phase that could potentially create more debris.

Finally, OSCAR moves onto its final stage, deorbit. Since the CubeSat is now facing in the opposite direction, firing the propulsion system results in a retrograde burn which will lower the speed and altitude of the CubeSat and attached debris object. If the maximum sized object is captured, this final burn will bring the system to a minimum altitude of 300 km, at which drag forces are sufficient enough to deorbit the system in less than a year. If there is any remaining propellant, this maneuver will bring the system to a lower altitude, resulting in a faster deorbit time. Upon reaching an altitude of 100 km both OSCAR and the captured debris object will re­enter the atmosphere and burn up.

5.1.2 Mission Success

OSCAR can be said to have a successful mission if the following criterion are met:

1. A significant piece of orbital debris is removed from orbit

a. A significant piece would be approximately 2.5 kg and 1U in size 2. OSCAR does not contribute to the current orbital debris problem

a. OSCAR is a closed system, nothing is left in orbit b. Critical Mission point ­ do not want to contribute to the problem

3. The system completes its mission in under 5 years

The success of the mission can be evaluated following the de­orbit of OSCAR. Any mission failure should result in a full revaluation of OSCAR, as the last thing this project should do is contribute to the problem at hand.

19

5.2 Structures

Launch is a very intense process and the phase in which structural failure is most likely to occur, so it is most important to have a structure that will survive without exception. Of course, the structure is useless if it cannot support all the mission systems. While there is no standard electronic form factor for CubeSats defined by rules, the PCI­104 form has become standard through practice and the structure should support this. Despite the lack of electrical form factor requirements, there are several constraints that are imposed on the structure by the CubeSat Design Specification, mostly regarding materials, rail geometry, and size. To conform with the specification, the structure must be made of aluminum for compatibility with the P­POD deployer. Furthermore, the exact size specifications must be met and a valid size of CubeSat must be chosen. These valid sizes range from 1U to 3U+. 5.3 Propulsion

The propulsion system needs to be able to deliver OSCAR to the target through orbital maneuvers, rendezvous with the target in close proximity, and then reduce the periapsis of the orbit. The target debris will be focused in the 600­800 km orbit range at an inclination between 95° and 105°. After rendezvousing with the target debris, the propulsion system will need to be able to reduce the perigee of the two connected bodies down to at least 300 km to ensure deorbit within approximately one year. Extra fuel can be used to lower the perigee even further in order allowing for deorbit within a shorter timeframe, but this is heavily dependent on the fuel used to rendezvous with the debris. While performing these tasks, the propulsion system needs to operate within the power budget, temperature limits and structural/vibrational limits imposed by the mission. The propulsion demands stated above are anticipated to readily be met by Aerojet Rocketdyne’s MPS­130 CubeSat propulsion system, which is currently under development. 5.4 Attitude Control

The attitude control system (ACS) must provide adequate pointing accuracy to orient OSCAR towards any desired heading. This may be at an angle for optimal solar array orientation, nadir pointing, or orienting the capture mechanism towards a debris target. To accomplish this, the ACS must provide orientation control about all three body axes. Furthermore, the ACS should ideally have redundant mechanisms in case of component failure. Finally, The ACS must receive data from sun sensors and stereo cameras to perform rendezvous maneuvers or localization maneuvers. Hence, the ACS must be able to interface with these external sensors over standard interfaces.

20

5.5 Thermal Management

The thermal management system is required to keep all components of OSCAR within their accepted temperature ranges. This ensures that all parts of the satellite are able to operate at maximum efficiency and maximum lifespan. While OSCAR is in direct view of the sun, internal temperatures will rise. This extra heat must be radiated out of the spacecraft. While the spacecraft is in eclipse, the internal temperature will drop significantly. The spacecraft must produce enough heat in this period to keep the internal temperature within the acceptable operating range of all of the components. In addition, the spacecraft must be able to protect itself from harmful radiation; this can be done by using a reflective coating on the surface of the spacecraft as well as using radiation tolerant components. 5.6 Power

Only rigid body­mount solar panels were required to meet the power source needs for the

craft. At our estimated orbital altitude and inclination, continuous power consumption never exceeds or nears the power supplied by a single solar array in a suboptimal position. No electric propulsion is featured on the craft and there are no power­hungry scientific payloads to present a large continuous power draw. A multi­channel EPS is capable of supplying peak power demands, including the propulsion start­up power which represents the largest possible power draw. Such undemanding power requirements allow for the use of a small battery, which takes up relatively little space in the system. 5.7 Command and Data

Autonomy of the craft can be accomplished through the on­board computer which

features more than enough computing power to calculate its necessary maneuvers when given correct target data, as the size of these files is on the order of tens of kilobytes (KB), and the data transfer rates are on the order of tens of KB/s. Furthermore, it can coordinate the control of all of the satellite's peripherals together and store gathered data for later transmission or use. Besides the camera, these tasks require relatively little processing power and memory, so the remaining resources will be allocated to maximize the usefulness of the camera. The parameters governing the performance of the camera are its frame rate, and its resolution. Because the resolution is fixed at 2594 x 1944, the remaining processing power will be used to maximize frame rate.

21

5.8 Telecommunications

The telecommunications system is required to transmit and receive data between the CubeSat and ground station. This data may include status updates, debris location information, and commands to move forward with the next step of the mission. The combination of a transceiver and antenna must have adequate transmission power to reach the ground station and a high enough sensitivity to receive ground signals. As these criteria are governed by the distance between the CubeSat and ground station, they must be satisfied at any altitude during the mission. Finally, as it is assumed that access to a ground station will be limited to once per day for one pass of the spacecraft, the telecommunications system must be capable of data transmission rates adequate enough to transmit and receive all relevant mission data in a short amount of time. 5.9 Payload

5.9.1 Debris Sensing Device Difficult tasks, which have not been entirely considered in CubeSats, present themselves

in the topic of sensing. Ground sensing systems can aid the CubeSat in nearing its target debris, but these systems have limited resolution for small debris. This limitation demands a sensing system for the satellite which can detect its debris from around 10 meters away, providing information of not just direction, but also distance, of the object from OSCAR. Absolute mission success also requires a system which can provide insight concerning the target itself, not all debris is possible or safe for our craft to remove. For example, the ESA estimates that over 60,000 pieces of liquid space debris in the form of NaK liquid­metal coolant exist, (Mehrholz) and OSCAR’s sensing system needs to be able to determine if the debris it has come across is liquid, or any other sort of danger.

5.9.2 Debris Capture Device

It is recognized that there is not a commercially available object capture device available

at this time for integration within a CubeSat. With that in mind, the project team has decided to design a custom system for OSCAR. The device must fit entirely within the volume of 1U. In addition, it must be capable of capturing at minimum a 10x10x10 cm piece of debris with a mass of 2.5 kg. This debris object will be of arbitrary shape and may have some degree of tumble. In carrying out the design, reliability will be favored as it is not expected to be feasible to have a redundant capture device on board the satellite. For this reason, the capture system must be highly reliable, as failure of this part would result in an inability to capture a debris object and thus failure of the mission.

22

6 System Concept Development and Selection 6.1 Structures

Structural determinations were made largely on factors brought about from other system’s needs. Sheer size requirements of the large 1U propulsions system and multiple other bus systems required 2U of space alone without accounting for the payload. For complete compatibility with the CubeSat Design Specification, a CubeSat must be 3U+ or smaller and so a 3U structure was chosen, giving the payload the option to occupy the bonus volume if necessary.

Few COTS options exist for 3U structures, only two that fully met the specification standards were found. These two structures were very similar, choosing between the two required consideration of the final design’s details, before the final design existed. Mass differences between the two structures differed only by a few grams, while both were structurally proven through many launches. Selection was decided when the communication subsystem determined its choice of antenna. The antenna required mounting using a standard front or rear solar panel mounting pattern, which the 3U structure by Pumpkin Inc. could only accommodate on one of the CubeSat’s ends. Unfortunately, this antenna would block the propulsion system’s exhaust on one end or the payload subsystem’s operation on the other, but the 3U structure offered by Innovative Solutions in Space presents solar panel mounting holes in two locations in the middle of the CubeSat. This feature is useless for actually mounting solar panels, but is very useful for placing the antenna, which uses the solar panel mounting pattern, in the middle of the spacecraft. Proper accommodation of the best candidate components can only be fulfilled by the 3U structure designed by Innovative Solutions in Space, and is the primary influencing factor in its incorporation. 6.2 Propulsion

Multiple systems were researched during the selection process for the propulsion system which can be seen in the below table. Table 6.1 below has 5 of the 15 systems that were looked at, representing the most probable system of each selection type (Appendix D). Scores were determined to be from 0 to 3 for each metric with zero representing the worst and three being the best. A scaling factor of 0.3 biases the scores to emphasize the total impulse and a factor of 0.1 reduces the importance of max thrust. Mass was not apart of the selection matrix due to most data sheets excluding that characteristic and the assumption that propulsion systems would be using most, if not all, of the mass allowed for the size as per CubeSat specifications.

23

Propulsion System Metric Selection Scores

Metric Busek BHT­200

Busek BIT­1

Aerojet Rocketdyne MPS­110

Aerojet Rocketdyne MPS­130

Aerojet Rocketdyne MPS­160

Type Scaling Factor

Hall Effect

Ion Thruster

Cold Gas CHAMPS SEPP

Volume .2 2 0 3 2 1

Power Usage .2 0 1 2 2 3

Total Impulse .3 3 3 0 1 3

TRL (Technology Readiness Level)

.2 1 1 3 2 0

Max Thrust .1 0 0 1 3 0

Total 1.5 1.3 1.7 1.8 1.7

Table 6.1: Propulsion System Selection Matrix

Based on the selection criteria outlined in the above table, the MPS­130, manufactured by Aerojet Rocketdyne (Cubesat Modular), was chosen as the propulsion system for use on the satellite as it received the highest score out of the systems that were found. This system should meet the mission criteria in the best overall way. Cold gas systems were omitted mainly due to the limit in total impulse that could be provided. Ion thrusters’ and hall effect thrusters’ main limitations are the power draw that they require and the low TRL. SEPP was an integrated system that included a solar panel array, but the TRL was that of a concept stage. The CHAMPS system was the best system to achieve the orbit maneuvers that are necessary for the mission within power capabilities.

The main disadvantage of the MPS­130 propulsion system is that the new propellant does not have enough data and testing performed on it. However, if this becomes a hindrance in future production, the MPS­130 can be replaced by the MPS­120 offering a flexibility in producibility at a cost of range. The MPS­120 uses a tested hydrazine propellant with MR­142 engines, but offers an estimated 130 m/s less ∆V than the MPS­130. Currently the MPS­120 and MPS­130 product development stages are proceeding with positive results (Carpenter, 2011).

The MPS­130 system takes up 1U of volume, has a dry mass of 1.3 kg, and has a fuel tank that can carry 0.36 kg of fuel. The MPS 130 operates with AF­M315E (low­toxicity propellant), has an estimated ∆V of 340 m/s for a 4 kg CubeSat, and utilizes four 1N rocket

24

engines. Impulsive maneuvers and thrust vectoring will be possible through the use of this propulsion system, which will have enough fuel to rendezvous with debris and then place the debris in a low­perigee orbit to ensure deorbit of the debris within a few years time before the five year limit of the mission. Aerojet Rocketdyne has not yet provided a cost for either propulsion system.

6.3 Attitude Control

Reaction wheels, momentum wheels, magnetorquers, and propellant were all considered as possible attitude control mechanisms for OSCAR. Momentum wheels are generally very massive and very complex, and were consequently removed from consideration. Propellant was also quickly abandoned because OSCAR relies on its propulsion system to de­orbit. Requiring the propulsion system to also serve as the main control actuator would siphon fuel needed to enter a low­perigee orbit to ensure deorbit. The solar panel array has magnetorquers built into their infrastructure, so it was determined that these magnetorquers would provide redundancy to a separate, primary actuator system. Thus, the concept selection matrix below shows only reaction wheel systems and their specifications.

25

Attitude Control System & Metric Scores

Component Name

iADCS­100 BCT Micro Reaction Wheel

XACT ACS BCT FleXcore

Manufacturer Berlin Space Tech.

Blue Canyon Tech.

Blue Canyon Tech.

Blue Canyon Tech.

Cost $154,000** N/A N/A N/A

Mass 345g 130g (x3) 850g 850g

Dimensions 10.39 x 9.0 x 3.1 cm

4.3 x 4.3 x 1.8 cm

10 x 10 x 5 cm

10 x 10 x 5 cm

Power 0.5V (nom) ­ 1.8V (max)

0.1V ­ 8V 0.85V ­ 2.83V N/A

Power Supply 5V 12V (variable down to 8V)

12V (variable down to 5V)

28V (variable down to 5V)

Temp. Range ­20 to +40 N/A N/A N/A

Max Speed N/A 6500 RPM 6000 RPM N/A

Max Torque .000087 Nm .004 Nm N/A N/A

Pointing Accuracy

.0008° (.055° in roll)

N/A .003° (.007° for third axis)

.002°

Other Components

3 magnetorquers, 3 gyroscopes, 1 star tracker, nadir tracking

None N/A Magnetorquers, 2 star trackers

Table 6.2: ACS Selection Matrix (**Model with simpler software sold for $82,500) Upon completion of the selection matrix, Berlin Space Technologies’ iADCS­100 had the

most desirable specifications in many of the categories. While the BCT Micro Reaction Wheel seems to have the smallest mass and volume, three reaction wheels would need to be employed to gain full control of OSCAR. The total mass and volume of three reaction wheels would then exceed those of the iADCS­100 system. Lastly, the iADCS­100 system uses an I2C interface that can allow for the easy integration of external sensors, such as sun sensors or star sensors for improved pointing accuracy.

26

6.4 Thermal Management Thermal management is essential to the survival of all components of OSCAR. The average temperature must be kept within the acceptable temperature range of all parts, listed below.

Component Temperature Range ()

Radiation Tolerance

Propulsion 5 to 50 Unknown

Attitude ­20 to 40 Unknown

Command ­40 to 60 100 krads

Transceiver ­20 to 50 Unknown

Antenna ­30 to 70 Unknown

Battery ­10 to 40 15 krads

EPS ­40 to 85 10 krads

Sensors ­10 to 55 Unknown

Table 6.3: Thermal Requirements of Satellite Components

A small patch heater is required to keep the electronics within the accepted range. A Kapton heater, capable of operating at up to 120 , will be integrated to keep temperatures within the optimal range. This heater will be placed close to the propulsion system, which has the highest minimum temperature. Kapton produces heaters of various voltages and watt densities; after further thermal and power analysis, the KHLV­0502/2 was chosen, which is the smallest heater Kapton produces. This heater is small enough to be placed next to the propulsion system, keeping it above its minimum temperature. In addition, it is not too power hungry, so that it is not a huge draw on the power supply. It is 1 cm by 5 cm, and produces 2 watts of power at maximum. (Kapton® (Polyimide Film) Insulated Flexible Heaters).

The best way to keep the temperature low enough when OSCAR is in full view of the sun is to use a thermal control paint. Because the satellite is so small, no additional cooling methods such as heat pipes, radiators, or louvers can be installed. Instead, all of the excess heat must be radiated directly off the satellite’s surface. This means that the emissivity of the surface must be as high as possible. This will ensure that the maximum amount of heat is lost to outer space. In addition, the absorptivity should be as low as possible, so that a minimum amount of heat from the sun is absorbed by the sunlight. After researching various types of paint, AZ­70­WIZT

27

produced by AZ Technology was chosen due to its low absorptivity and high emissivity. One important thing to note is that the entire surface of the spacecraft will not be coated in this paint; most of the surface will be taken up by body solar panels, so only the remaining uncovered area will be coated. (Spacecraft Thermal Control and Conductive Paints/Coatings* and Services Catalog)

Paint Name Color Absorptivity Emissivity

AZ­70­WIZT White 0.1 0.91

RM­550­IB Black 0.97 0.91

AZ­3700­LSW Metallic grey 0.23 0.28

AMJ­400­IG Green 0.56 0.9

Table 6.4: Properties of Different Thermal Control Paints

Radiation protection must also be implemented. Thermal control paint is also effective against radiation because it has a high reflectance. This means that a majority of cosmic radiation will be reflected off the surface. In addition, due to the aluminum structure, a large amount of radiation will be unable to penetrate the surface. Lastly, radiation tolerant components were selected for all systems, to ensure the longevity and accuracy of the mission. Although it is impossible to protect our satellite from 100% of radiation, the steps taken should greatly reduce the amount of radiation that could potentially harm the electrical components of the satellite.

28

6.5 Power

The power subsystem is essential in ensuring that all of the other subsystems have the amount of electricity needed for the entire duration of the mission. Table 6.6 shows the current minimum and maximum power draws for each of the subsystems. This data acted as a guide for the component selections made for the power subsystem.

Power Requirements

Max (W) Min(W)

­Telecom­

Antenna 2 0.02

Transceiver 1.7 0.2

­Propulsion­

Engine 5 0

­Command­

Computer 1.5 1.5

­Power­

Battery Heater 0.3 0.1

EPS 0.4 0.4

­Attitude Control­

ACS 1.8 0.5

­Thermals­

2 0

Total 14.7 2.72 Table 6.5: Expected Power Draw

The power system is divided into 3 components: power supply, power storage, and power

management. The selection matrices for each of these components is detailed below.

29

Power supply is defined as the component responsible for generating or collecting the power to be stored or used by other subsystems. For this project, the power supply device was chosen. Other options, such as nuclear power or electromagnetic tether, were also investigated, but thrown away due to their irrelevance to our project.

Power Supply Metric Selection Scores

Metric Clyde Space ISIS Clyde Space GOM Space

Name SP­L­S3U­0016­CS

3U Solar Panel

SP­L­S1U­0002­CS

P110

Area (U) 3 x 1 3 x 1 1 x 1 1 x 1

BOL Power (W) 8.63 6.9 2.46 2.3

BOL Vmpp ( V) 16.45 2.3 4.70 4.6

Mass (g) 135 150 42 29

Total 3 0 2 1

Table 6.6: Selection Matrix for Power Supply Selection When the scoring was done on the Table 6.7 above, the components which were most

desirable to the project needs were highlighted in bold. The initial selections were done with both 1U panels and 3U panels to see if there was any benefit in selecting three 1U panels instead of one 3U panel. The total highlighted in bold was chosen as the superior solar panel for the 1U or 3U category. Following the selections, the two schemes were compared using the following equations:

3U: =62.93 W/kg135g8.63 W

1U: =58.57 W/kg42g2.46 W

Where it can quickly be seen that the power density, or watts generated per kilogram, is

higher in the 3U solar panel than in the 1U solar panel. After reviewing this data, the Clyde Space 3U solar panel was chosen for the design.

The Power Storage component component is required to store the necessary power to

keep electric components functioning through eclipse and augment the energy supplied by the

30

solar panels in any power­intensive maneuvers. The battery charge needed to make it through a 35 minute eclipse is estimated to be 1.59 Wh, based off of the minimum power needed in Table 6.6. Using this number (plus a factor of safety of 1.5) and an additional amount for orbital maneuvers, the minimum power that would need to be stored is 2.385 Wh. Using this number, Table 6.8 was constructed:

Power Storage Metric Selection Scores

Metric Clyde Space Clyde Space

Clyde Space GOM Space GOM Space

Name 10Wh 20Wh 30Wh NanoPower 2P­2S

NanoPower BPx6 Cell

Size(mm x mm x mm)

90.2 x 95.8 x 9.95

90.2 x 95.8 x 15.75

90.2 x 95.8 x20.4

93.39 x 87.44 x 22.86

91.68 x 85.9 x 40.00

Mass (g) 156 253 350 240 370

Discharge Voltage (V)

6.2 6.2 6.2 8.4 6­10.8

Capacity (WHR)

10 20 30 38.5 21.8

Rank 1 2 3 5 4

Table 6.7: Power Storage Selection Matrix

In the above table, a bold value corresponds to it being best for that metric. Due to its minimal size, low mass, and ability to meet the project's power needs, the Clyde Space 10Whr battery was selected as the CubeSat battery. Running the CubeSat in eclipse with the minimum load and full battery gives 220 minutes of power, and operating with a full power draw will provide 40 minutes of power. Proper power management will allow the satellite to perform all necessary maneuvers with very few limitations on the operations which can be performed in eclipse.

The power management component of this subsystem is fulfilled by the Electric Power System(EPS). The EPS is necessary to prevent overcharging the battery and to ensure a proper power regulation to and from all of the other subsystems.

31

EPS Metric Selection Scores

Metric Clyde Space CubeSat Kit Crystalspace

Name 3rd Gen. EPS Linear EPS P1U

Height(mm) 15.24 13 7

Mass (g) 86 58 80

Number of Outputs 10 6 6

Rank 1 2 3

Table 6.8: EPS Selection Matrix

The while it underperformed the other 2 EPSs slightly in the weight and height categories, the Clyde Space EPS was chosen as it offered a greater number of outputs compared to the two other systems, allowing for more wiring flexibility or the addition of science components in future missions. The Clyde Space EPS also has specific integration specifications with the Clyde Space Solar Panels and Batteries, which were previously selected for the product.

32

6.6 Command and Data

Board

Power

(in Watts)

Processing (in Hertz and Instructions Per Second)

Memory (in Bytes)

Interfaces

Radiation

Intrepid System

Board

300mW

400 MHz

512MB NAND flash

MicroSD

Unspecified

NanoMind

A3200

132mW

66 MHz

128MB NOR flash

I2C, UART,

CAN­Bus

Unspecified

NanoMind

A712D

232mW

8­40 MHz

2x16MB NOR flash

CAN­Bus, I2C

Unspecified

Proton200k Lite

1500mW

Floating Point:

1000 MHz

1200 MIPS

8GB

flash

I2C, UART, cPCI

SEL: > 63 LET SEU: < 1per 1000­day TID: 100 krad (Si) SEFI: 100% recoverable

CubeComputer

<200mW

4­48 MHz

2GB

MicroSD

I2C, UART, SPI

SEL: Mentioned, not given

SEU: Mentioned, not given

Table 6.9: Data Processor Component Selection

Table 6.9 compiles the findings of the group’s search for a component to satisfy the Command and Data subsystem. The search returned only two results that were radiation­hardened and, therefore, space­capable for a 5­year mission. These components include the Proton200k Lite (Space Micro) and CubeComputer. The CubeComputer datasheet makes claims of “SEU protection [... and] SEL protection” but includes no data on which to base these statements (Cube Computer). The team attempted to reach out to the manufacturer through the cubesatshop messaging system, but met with no success. Based on this analysis, the team chose the Proton200k Lite, the only CubeSat­compatible component that can back up its radiation­proofing, to form the Command and Data subsystem.

Other radiation­hardened boards from the cubesatshop reference were also considered, such as the Andrews models 160 and 110, the Q­stack, and the Q6 (CubeSatShop), but like the CubeComputer before them, they also neglected to provide meaningful radiation data. The

33

Proton200k Lite expects <1 SEU (Single Event Upset) per 1000 days, which is shorter than the timeline of the satellite's operation, so additional precautions were taken to prevent state error.

Because the Proton200k Lite was the only component to meet the design standards and specifications set forth by the team with regards to the mission design, there was no need for a weighted decision matrix. For the sake of argument, the team would’ve prioritized low power and low cost above all else. This is because the satellite requires very little processing power and memory to execute all functions aside from the camera sensors, which requires as much processing power as we design based on its frame­rate. 6.7 Telecommunications

The telecommunications system consists of two main components, the antenna and the transceiver. The first thing that was considered when selecting these components was the transmission frequency range that the system would be operating in. Two ranges were considered, Ultra High Frequency (UHF), which operates at about 100 to 500 MHz or S­Band, which operates at about 2 to 4 GHz. Both of these ranges are below the 5 GHz threshold when transmission issues due to poor weather can occur due to attenuation as the signal passes through the atmosphere (Anderson).

S­Band transceivers bring the distinct advantage of increased data transmission rates over a UHF transceiver. However, they often require an antenna with some degree of pointing accuracy and are more expensive. As OSCAR’s mission is not purely scientific but rather to perform the specific task of removing a piece of debris, there is no need to transmit large amounts of data, such as high resolution images down to Earth. For this reason, the UHF frequency range was chosen. This will also allow the CubeSat to employ an omnidirectional antenna that will eliminate any ACS requirement for transmission pointing accuracy.

34

Table 6.10 summarizes the two most promising components that were compared for this project.

Telecommunications Components Summary

Antenna Transceiver

Name UHF Turnstile

Antenna

ISIS Antenna System

ISIS Transceiver

NanoCom AX100

Maximum Power Consumption 10 W 2 W 1.7 W 2.64 W

Mass 30 g < 100 g 85 g 24.5 g

Communications Interface I2C I2C I2C I2C

Uplink/Downlink Data Transfer Rate N/A N/A

1.2 kbps/9.6 kbps 0.1­115.2 kbps

Table 6.10: Telecommunications Component Selection

Ultimately, it was decided to choose the Innovative Solutions in Space (ISIS) transceiver (ISIS VHF) over the NanoCom AX 100 (NanoCom Communication Modules). A distinct advantage of the ISIS transceiver is that it supports a full duplex mode. This means that it can both transmit and receive information at the same time. For this project it is assumed that there will be limited access to a ground station and thus this ability will ensure that the data transfer to and from the spacecraft can be maximized in the limited time that is available. This advantage outweighs the lower mass of the NanoCom unit.

Both the UHF Turnstile (GOMSpace) antenna and the ISIS antenna (Deployable Antenna) consist of four monopole aerials which, when deployed, form an omni­directional system with minimal blind spots. This will ensure that communication can occur successfully independent of the orientation of the satellite. Both systems also feature a redundant deployment mechanism, in the form of two heating elements per antenna, that melt a wire to release the spring loaded antenna after orbit insertion. It must be noted, however, that this mechanism is an additional component that must be purchased and installed for the Turnstile antenna. Ultimately, the UHF Turnstile antenna was chosen because it is able to be mounted in the middle portion of the structure. This will clear an opening at the top of the satellite for the protrusion of the debris capture and sensing systems.

35

6.8 Payload

6.8.1 Debris Sensing Device

A search of technologies currently being looked into for rendezvous with CubeSats turned up very little, with most information regarding the use of small radar distance sensors used in automobiles being converted for CubeSat use. With few other options being seriously studied it was decided to draw on technologies used in robotics and automation to find candidate technologies for sensing. Many were found, and each candidate technology was evaluated individually in a qualitative overview, ultimately leading to a clear answer. Stereo vision was ultimately selected, and brief summaries of each qualitative analysis is given here:

Radar: Small radar sensors are being looking into for use in automotive and other consumer applications. These sensors are promising for use in space and provide excellent distance resolution without large power consumption. However, these sensors are one­dimensional, so their use would need to implement a method of scanning with them, either by orienting the CubeSat or by mounting them on a electromechanical scanning device. Quickly orienting the Cubesat with the selected reaction wheels is not possible, and constantly running electromechanical systems pose great reliability risks in space. These two issues rendered this method infeasible.

Laser: Laser­based sensing methods were quickly deemed infeasible as they all rely on the assumption that the target will have optimal optical properties at the laser’s wavelength. With the size of debris OSCAR targets, optical properties vary greatly and just about anything is possible. Furthermore, the lasers must provide greater intensity than the sun for their incident beam to be detectable, which is difficult. As if that wasn’t enough, stars in the background could be confused by the laser detector as reflected laser, putting the final nail in the coffin for this concept.

Single Camera: Cameras overcome the limitations of one dimensional sensors by being

two dimensional. Limitations seen by lasers do not affect cameras that use a wide spectrum of wavelengths, such as normal commercially available cameras. This method offered a very distinct advantage in that COTS hardware is available, but there were still limitations. Some methods exist for using a single camera to determine distance, but actively evaluating the target would still prove difficult as debris may not be static.

Multi­Camera Array (Stereo): To overcome the evaluation limitations of single cameras,

a second camera can be added to allow for stereo vision. Stereo vision can be used to create a point cloud of what lies in view, this 3D data provides a huge advantage in evaluation of the

36

target, allowing for estimations of volume, mass, and observation of hazards such as sharp corners and tumble. No COTS stereo vision system exists, but payload development is expected. Also, a great deal of processing power is required for this system, though our computing system was calculated to be able to meet the requirements of it. These issues do not significantly reduce the feasibility of this method, making it the most suitable for this mission.

Structured Light or Time of Flight Cameras: While structured light cameras and time of

flight cameras are very different technologies, both suffer from similar feasibility issues as laser­based methods as both rely on projecting light. Overpowering light from the sun makes these systems infeasible as structured light projectors have a tough time giving out more light than the sun.

6.8.2 Debris Capture Device

The first step in the design phase of the debris capture device was selecting the capture method. Based on the requirement set forth in section 5.9.2 that the entire device fit within 1U, the team selected two potential options to research which are summarized in Table 6.11 below.

Debris De­Orbit Mechanism & Metric Scores

Metric Weight Factor Net Cargo Bay

Size 0.25 0 0

Cost 0.15 3 3

Power Usage 0.15 2 2

Variety of Objects 0.25 3 1

Number of Objects 0.2 0 1

Total 1.0 1.50 1.20

Table 6.11: Debris Capture Mechanism Selection Matrix.

Each item was given a score from 0 to 3 for each metric to indicate its relative advantage and benefits to the success of the mission. The highest scores for each metric have been bolded. Completion of the concept selection matrix has shown that the net mechanism shows the greatest advantage. It is expected to be very low­cost in terms of concept development, manufacturing, and testing, and it is expected to use little power to deploy the net. Perhaps most importantly, the net should be able to secure a very large range of objects. With the proper net design, an object

37

should be able to be secured regardless of its spin, shape, or material composition. The object must be smaller than a certain maximum size, but there is no minimum size to the object given enough net thread density. This is not true of the other mechanisms, which only work for objects having more specific characteristics. The most significant drawback to the net is that it is not expected to be able to capture multiple objects unless it can do so in a single launch. This, of course, is highly unlikely.

The most promising alternative to the net, according to the selection matrix, is the cargo bay. This method would work by having a volume within the CubeSat (the cargo bay) designated for debris storage. Upon tracking an object, a door to the cargo bay would open and the CubeSat would have to orient itself such that it would encapsulate the debris within the cargo bay and close the door. The largest obstacle in using a cargo bay is that an object must fit within a certain area. Furthermore, the velocity and spin of the object have to be very well­known to ensure nothing is damaged by the debris inside the CubeSat.

Based on this analysis, the team opted to pursue a debris capture method using a net. Further discussion of the final design can be found in Section 7.8.2.

38

7 Design Analysis

7.1 Structure No additional analysis was deemed to be needed for the structure at this stage of the

design after reviewing the analysis performed by ISIS. 7.2 Propulsion

The propulsion analysis is separated into three categories: orbital maneuvers, close proximity rendezvous, and deorbit of both the debris and OSCAR. Orbital maneuvers in this context are defined as maneuvers performed to align the orbital planes of OSCAR and the debris that is being targeted. Close proximity rendezvous in this context include the phasing burns to align the anomalies of the satellites. The deorbit of OSCAR and the debris is analyzed as an impulsive retrograde burn at apogee which reduces the perigee of the now coupled objects. Due to the openness of the problem, AGI STK Astrogator was used to analyze specific ∆V maneuver costs.

The first orbital maneuver that was analyzed in Astrogator is a small burn made at the ascending node of the orbit in order to change the inclination of the orbit slightly. It was determined that a change in inclination of the orbit requires a ∆V of 13 m/s per 0.1 deg of change. The extreme cost of this maneuver emphasizes the need for OSCAR to be placed in an orbit that is very close to the inclination of the target debris. Moving forward in the analysis, it will be assumed that the inclination change OSCAR can perform will be 0.3 deg change at a ∆V cost of 39 m/s. This cost is removed from the estimated total ∆V of 340 m/s resulting in a ∆V remaining of about 300 m/s.

The second orbital maneuver that was analyzed in STK is a nodal precession change maneuver performed for a circular orbit at 800 km with an inclination of 95 deg. This maneuver is composed of a small prograde burn of 38 m/s at perigee resulting in a change of the eccentricity by .01. This causes the precession rate to be 7 deg/year less than what it would have been without the maneuver. The simulation below in Figure 5 shows the result of this maneuver after a quarter of a year. The blue orbit path lines are the orbits of the satellite with no maneuver, and the green orbit paths are the orbits of the satellite after the maneuver.

39

Figure 7.1: Prograde Nodal Precession Over Quarter of a Year (Arctic Centered)

This maneuver can be used to adjust the difference between longitudes of ascending nodes of two orbits over long periods of time. It is estimated that OSCAR will have approximately 260 m/s of ∆V remaining after these orbital maneuvers.

The last orbital maneuver analyzed in STK is a hohmann transfer in which OSCAR is placed in a circular orbit greater than the target debris orbit. The largest hohmann transfer anticipated based on our mission is a transfer from 800 km to 300 km, which requires a total ∆V of 280 m/s. This transfer can be seen below in Figure 7.2 where the first retrograde burn occurs at the blue­brown transition and the second retrograde burn occurs at the brown­green transition left to orbit in a circular orbit at 300km.

Figure 7.2: Hohmann Transfer From 800 km to 300 km Circular Orbits

40

This would be a problem because the total running ∆V is 20 m/s over the capability of the

propulsion system, but with the proper planning a nodal precession can be performed with a retrograde burn causing the 38 m/s of that maneuver to contribute to lowering the radius of the orbit later performed in the Hohmann transfer. However it should be noted that the nodal precession rate is increased by 7 deg/year in the eastward direction as seen in Figure 7.3 below. Again the orbits are modeled for a quarter year with the original orbit in blue and the orbit after the maneuver in green.

Figure 7.3: Retrograde Nodal Precession Over Quarter of a Year (Arctic Centered) Now that the orbit planes of the target and OSCAR are more precisely aligned, the

propulsion system must be able to perform close proximity rendezvous. Close proximity operations include phasing maneuvers to align the true anomalies of the two orbits and are estimated to be small compared to the other maneuvers of the mission.

Further STK analysis of this stage of the propulsion needs to be performed in order to determine the costs of maneuvers for the close proximity rendezvous. The analysis would need to investigate the solutions of Lambert’s problem to align the true anomalies of the orbits. Once within a very close distance, the Clohessy­Wiltshire equations will need to be solved in order to perform the necessary burn maneuvers required to control the craft within sensing range of the debris.

Deorbit maneuvers performed by OSCAR after successfully capturing the debris need more analysis in order to directly apply to the capabilities of the mission. Due to the lack of information regarding the specifics of AF­M315E low­toxicity propellant with the MPS­130 system, the deorbit analysis was performed using properties of the MPS­120 system (hydrazine propellant). It should be noted that this will add a buffer to the simulation values due to the MPS­130 having 130 m/s greater ∆V capability for a 4 kg satellite than what is offered by the MPS­120. Using STK to solve for the changes in perigee of different target masses at increasing

41

orbit altitudes, the following data was generated below in Figure 7.4. Data points lying to the left of the dotted line represent targets which can have the periapsis reduced to 300 km or below. Reducing the object’s periapsis to this altitude is expected to deorbit the object within one year. It should be noted that these values assume no propellant used to actually rendezvous with the target and a full tank of propellant is used in the burn. Further information and modeling will be needed to generate the capabilities of the MPS­130 and develop a similar plot for expected fuel amounts that OSCAR will have at the target debris.

Figure 7.4: Initial Approximations of Target Debris Using MPS­120 Propulsion System

7.3 Attitude Control

In order to properly determine if Berlin Space Technologies’ iADCS­100 meets the ACS requirements stated in Section 5.4, a simulation was conducted using the Simulink simulation suite operated with a MATLAB script. The simulation was run using a discrete time step of 5Hz and using a quaternion­based parameterization, both of which accurately represent the operating conditions of the iADCS­100. The simulation was also designed to saturate the reaction wheel torque at 0.087 mNm, which is the maximum torque provided by any single reaction wheel in the iADCS­100. Along with the maximum torque, it is important to have a good estimate of OSCAR’s inertia matrix. The inertias about each of OSCAR’s primary body axes are presented below.

.03 Kg I .03 Kg I .006 KgIxx = 0 *m2 yy = 0 *m2 zz = 0 *m2

42

These three inertia values, obtained from the computer­aided design (CAD) of OSCAR, make up the diagonal of the full 3x3 inertia tensor. In this tensor, the off­diagonal terms are very close to zero and are approximated as equalling zero.

Before delving into OSCAR’s attitude dynamics, it is necessary to first explore two methods by which OSCAR’s body­frame coordinates can be related to an inertial frame fixed with respect to an Earth­based observer. It is crucial to establish this relation because any desired orientation angle sent to the control system is given with respect to an inertial frame, which is a reference frame that remains stationary with respect to an Earth­based observer. On the other hand, OSCAR’s on­board gyroscopes (also called gyros) measure angular rates in its own reference frame, called the body frame. The first relationship that relates these two frames to each other is established using Euler angles. The theory of Euler angles states that an object can be rotated about the three axes of a stationary (inertial) frame to achieve any orientation in the inertial frame. In order to characterize this orientation, consider just a single rotation of the body frame axes about an inertial frame as shown in Figure 7.5 below:

Figure 7.5: Coordinate System Rotation About Z Axis by Angle .θ

Consider the body frame to be defined as having axes [X’, Y’, Z’] and the inertial frame as having axes [X, Y, Z]. The z­axes of each frame are pointing out of the page in the figure above. Next, consider the body frame to initially have the same orientation as the inertial frame and then it is rotated about its Z­axis by an angle . In order to relate the inertial frame to the body frame, θ the rotation angle and simple trigonometric relations can be used. The following relation is obtained:

(eq. 7.3.1)

43

The 3x3 matrix is known as a direction cosine matrix (DCM). When the body frame is rotated about each of its axes independently, the total DCM relating the two frames is given by simply multiplying the DCM obtained by each individual rotation. By rotating the body frame about the X, Y, and Z inertial­frame axes in that order, the following total DCM is obtained:

(eq. 7.3.2)

where the subscripts represent Axes 1, 2, and 3 (X, Y, and Z in this case) and and stand for c s the cosine and sine (respectively) of the rotation angle about the subscripted axis. This DCM will be referenced in later calculations.

Relating angular rates across two reference frames using Euler angles results in equations with singularities. Arriving at such a singularity can cause a failure of the ACS unit (specifically known as gimbal lock), sabotaging the entire mission. Thus, it is imperative to use an alternative means of relating angular rates between reference frames. This method is known as the method of quaternions (also referred to as Euler parameters). Whereas the theory of Euler angles states that any orientation can be achieved through a series of rotations about three principle perpendicular axes, the theory of quaternions states that an object can achieve any arbitrary orientation in an inertial frame by performing a single rotation about a single arbitrary axis. This axis is defined by three quaternion parameters that define the orientation of the rotation axis with respect to the axes of the inertial frame. The magnitude of the rotation is characterized by a fourth parameter. These four quaternions are related to the terms in the total DCM shown earlier by the following equations:

(eq. 7.3.3)

44

(eq. 7.3.4)

where represents the item in the total DCM located at row , column . Quaternions are C ij i j desirable not only because they lack singularities, but because they are more robust and calculations can be conducted more quickly than those conducted entirely with Euler angles. Most importantly, the iADCS­100 uses quaternions when performing calculations so that is what has been simulated in all analysis. With this quaternion mapping, the attitude dynamics can now be properly assessed.

The inertia and torque properties mentioned previously are crucial in simulating the attitude dynamics of the system; in this case, OSCAR and its attitude dynamics represent the “plant” of the whole system (refer to the block diagram in Figure D.1 of Appendix D). In order to properly simulate OSCAR’s attitude dynamics, Euler’s equations of motion for rotation are used:

α x IωI = ω + τ (eq. 7.3.5)

In this system of equations, is the 3x3 inertia tensor, , is a column vector of I α = dt

dω ω body­frame angular rates measured by the on­board gyros, and is the total torque column τ vector acting on OSCAR (control torques and external disturbance torques). The system of equations above are solved for and integrated to output the vector of body­frame angular rates α . Once the rates are calculated, they are used to determine the rate of change of the orientationω

quaternions, shown below:

(eq. 7.3.6)

where , , and represent the angular velocities about the X, Y, and Z axes of OSCAR’s ω1 ω2 ω3 body­frame coordinate system. In this system of equations, the quaternion rate vector on the left­hand­side represents the values at the “present time step,” whereas the quaternion vector on the right­hand­side represents the quaternions calculated at the previous time step (keep in mind this is a discrete­time solution method). The present­step quaternions are found by integrating the

45

present­step quaternion rates, which can be plugged into the right­hand­side of the equation to find the quaternion rates at the next time step once the angular rates have been updated at the next time step as well.

While OSCAR must achieve a desired angular orientation, it must also be able to achieve a desired body­frame rotation. During the course of the mission, OSCAR may experience external disturbance torques caused by phenomena such as solar pressure, since OSCAR’s center of gravity is offset from its geometric center by roughly two centimeters. The adverse effects of the disturbance torques can be mitigated through a process called spin­stabilization. Spin­stabilization constantly re­orients an object so that the moment arm between the geometric center and center of gravity always changes direction. This prevents disturbance torques from always acting in the same direction, which would cause OSCAR to experience significant angular acceleration over time. It is important to note that OSCAR is a small craft and solar pressure will likely not be a major issue, but it is best to have spin­stabilization capability in case it is.

Since OSCAR needs to have control over angular orientation and rotation, a control scheme that takes orientation quaternion error and angular rate error into account has been implemented in simulations. Quaternion errors are calculated by first converting the orientation quaternions to a total DCM using Equation 7.3.4 and multiplying the resultant by the transpose of the total DCM relating desired orientation to OSCAR’s body frame. The angular rate error is simply the difference in the actual and desired angular rates. The actual quaternions and the actual angular rates are calculated and directly measured, respectively, while the desired quaternions and desired angular rates are sent to the on­board computer and then to the iADCS­100 unit. This information is known as ephemeris data (see Figure D.1 in Appendix D). Once the quaternion errors and angular rate errors are calculated, they are each scaled by a term known as a gain. Multiplying errors by gains allows the total control signal to be weighted more heavily on some errors than others. Gains can also be thought of as unit converters; for example, an orientation error of 0.1 radians may need to be mapped to a voltage of 2V across the reaction wheels so they provide the proper control torque to re­orient OSCAR. In this case, a quaternion gain of 20 would be appropriate. In the control scheme used for all simulations in this preliminary analysis, the quaternion and angular rate errors are each multiplied by a gain vector. These two resulting signals are added to create the control signals sent to the reaction wheels, as shown in Figure 7.6 below.

46

Figure 7.6: Block Diagram of Simulated Control Algorithm.

The first simulation that was conducted on OSCAR simulated desired Euler angles of [0°,

0°, 0°], initial Euler angles of [90°, ­165°, 120°], desired angular rates of [0°/s, 0°/s, 0°/s], and initial angular rates of [0°/s, 0°/s, 0°/s]. This produced the slowest settling time among initial angles that were simulated. Quaternion gains were tuned to [5, 5, 5] while angular rate gains were tuned to 29.*[0.8, 1.2, 1]. The results are shown in Figures 7.7 and 7.8 below, illustrating quaternion error and angular rates over time.

Figure 7.7: Error Quaternions with Initial Orientation Error and No Noise.

47

Figure 7.8: Angular Rates with Initial Orientation Error and No Noise.

In performing these simulations, it was assumed that the on­board gyros were ideal and measured no noise. That assumption is not valid for any real system. For this reason, a subsequent simulation was conducted to simulate the same initial conditions and desired conditions but with added noise in the gyros. This was done by taking the angular rates from integration of Euler’s equations and adding the product of a standard deviation and a normally­distributed random number. To model an extreme case, the standard deviation value was chosen to be 0.05 radians per second. This is about 66% of the maximum angular rate observed in Figure 7.8 above, which represents a very extreme case that might occur only in the event of a collision or some other means of harsh external disturbance. The results of this simulation are shown below in Figures 7.9 and 7.10.

48

Figure 7.9: Error Quaternions with Initial Orientation Error and Significant Noise.

Figure 7.10: Angular Rates with Initial Orientation Error and Significant Noise.

49

The settling time for the error quaternions in this case is over 15% larger than in the ideal case of no noise measurement. Fortunately, the iADCS­100 is equipped with an on­board state estimator known as a Kalman filter. Simply put, a Kalman filter uses a physics­based model to predict what the angular rates should be at the next discrete time step. It then compares these values to the values recorded by the gyros and, based on the difference between the two, applies a gain to the measured value before sending this value to the control algorithm. If the measured value closely resembles the predicted value (the state estimate), the value is “trusted” more heavily and is not much affected by the Kalman gain. On the other hand, if the two values disagree significantly, a gain will be applied to bring the Kalman filter’s output closer to the state estimate. Results of simulating the Kalman filter are shown in Figures 7.11 and 7.12 below.

Figure 7.11: Error Quaternions with Initial Orientation Error and Kalman Filter.

50

Figure 7.12: Angular Rates with Initial Orientation Error and Kalman Filter.

The results shown above are the most accurate simulations of OSCAR’s performance.

Figure 7.11 above, when zoomed in, shows that every error quaternion converges to within 1° within 70 seconds.

Next, a simulation of a detumble operation was performed. OSCAR was simulated having initial Euler angles of [90°, ­165°, 120°] and initial angular rates of [6°/s, 6°/s, ­6°/s]. The quaternion gain was set to zero so the only control effort would be to set the angular rates to zero. The simulation includes modeling of noise and a Kalman filter, with results shown in Figure 7.13 below.

51

Figure 7.13: Angular Rates with Initial Orientation Error and Initial Angular Rates.

The results indicate that OSCAR should be able to recover from a moderate tumble in less than 45 seconds under these conditions, allowing the mission to quickly take shape after deployment from the primary launch vehicle. 7.4 Thermal Management

As mentioned before, the goal of the thermal management subsystem is to ensure that the average internal temperature of the spacecraft is to be kept within the accepted temperature range of all components. This range was determined to be between 5 and 40°C. The minimum temperature is defined by the propulsion system, and the maximum temperature is defined by both the ACS and the battery. To calculate the average internal temperature, an analysis of the heat into and out of the satellite must be performed. Heat gained by the satellite is a combination of: heat absorbed by the sun (Qsun), heat from the sun reflected off the earth called albedo (Qalb), heat absorbed via infrared radiation from the earth (QIR), and heat generated by the satellite (Qgen). Heat is only lost by the satellite in one way: through radiation into space (Qrad). According to the first law of thermodynamics, Qout = Qin. Substituting in the sources of heat, the following equation is generated:

(eq. 7.4.1)

52

Heat emitted by radiation can be defined as

(eq. 7.4.2) Where A is the area, ε is the emissivity, ᵸ is the Stefan­Boltzmann constant, and T is the average internal temperature. Because the surface of the spacecraft is not all made of the same material, and therefore has different emissivities, a more complex form of this equation must be used.

(eq. 7.4.3) On a similar note, heat absorbed from the sun can be defined as

(eq. 7.4.4) Where Gs is the average solar flux, Asn is area of a specific material facing towards the sun, and n is absorptivity of a specific material The albedo can be defined as a percentage of sunlight reflected back from the Earth’s surface. The average is about 30%, so the heat from albedo equation becomes

(eq. 7.4.5) Where Aen is area of a specific material facing the Earth Heat absorbed via infrared radiation from the earth is similar, but depends on the emissivity. It is defined as

(eq. 7.4.6) Where GIR is the average infrared flux Lastly, heat generated by the satellite can be calculated in terms of maximum and minimum power used by the system. These numbers were taken from the power subsystem.

By combining all of these equations, the only unknown is internal temperature. This can be solved for in two scenarios: minimum and maximum. The minimum temperature occurs when the satellite is in eclipse; this means that heat absorbed by the sun and albedo are both zero. The maximum temperature occurs in direct view of the sun; this means that all sources of heat must be considered at their maximum values. Using a MATLAB script (appendix C­2), these temperatures were calculated to be 10.67 and 38.01, respectively. Both of these values are within the optimum temperature range, meaning that the spacecraft should be able to function properly throughout its entire mission. (Friedel, Jonas, and Sean Mckibbon) 7.5 Power

When analyzing the power subsystem in Section 6.5, the battery charge needed to sustain the CubeSat through eclipse was determined as 2.385 Wh, thus, entering eclipse with any charge

53

less that 2.385 Wh was can been seen as a failure during the validation process. An important assumption made in this section is that the CubeSat is in a circular or near­circular orbit (eccentricity ~ 0).

An important part of determining how long a satellite will be in eclipse depends on how the shadow of the Earth is modeled. The Earth (and any other planet) has two shadow regions, Umbra Cone and the Penumbra Region, both depicted in Figure 7.14. In the Umbra Cone, the Earth is completely blocking the light of the sun, while in the Penumbra region, the light of the Sun is only partial blocked (NASA Technical Paper 3547).

Figure 7.14: Depiction of Earth’s Shadow Regions

Due to the extreme distance between the Sun and the Earth, the Sun can be approximated

as a point light source, which results in the cylindrical shadow seen in Figure 7.15

Figure 7.15: Earth’s Shadow Approximation

54

To approximate the time that the CubeSat will spend in this eclipse the following steps were taken:

Radius of EarthR E = adius of orbitr = r

alf angle of eclipseγ = H

(eq. 7.5.1)

Figure 7.16: Variables Used to Calculate Gamma

Following the calculation of gamma, the time that the CubeSat spends in eclipse can be

calculated by multiplying the orbital period by the fraction of the orbit that the CubeSat is in eclipse:

rbital PeriodT = O raction of orbit in eclipsefe = f

eriod of EclipseT e = P emi ajor axisa = s −m

ravitational Parameter of EarthμE = G

(eq. 7.5.2)

(eq. 7.5.3)

(eq. 7.5.4)

55

Using these equations, the amount of time the satellite is eclipse can be calculated to be 35 minutes. For a more complex analysis, the beta angle can be used (Orbital Mechanics for Thermal Engineers).

Figure 7.17: Beta Angle

As depicted in Figure 7.17, the beta angle is the angle between the orbit plane and the

solar plane. This can be used to accurately predict the amount of sunlight a CubeSat will see at different angles of inclination and different longitudes of the ascending node. However, for OSCAR’s power analysis, the beta angle was set to zero to ensure the CubeSat could endure the worst­case power scenarios.

Utilizing the above equations and assumptions, a MATLAB model was constructed to ensure the power system can meet all of the needs of the spacecraft. The MATLAB code is featured in Appendix C­3. The following MATLAB plots are an example of some of the analyzation performed on the power system. The model has the input parameters:

0° (beta angle)β = 5° (inclination angle)i = 8 7171 km (orbital radius)r =

.1 k (rotational speed of spacecraft)ωr = 0 ˆsecrads

imestep 15.1085 sec (time in step of simulation)t = The following figures depict a snapshot of the power parameters over three orbital

periods. Each period is shown in a different color.

56

Figure 7.18: Power Supply

Figure 7.18 shows the power supplied by the solar panels to the CubeSat as a function of

time in the orbit. In this simulation, the satellite is rotating about its z­axis for reasons explained in section 7.3. This causes the solar panels to be at a constantly changing angle to the sun, which results in a sinusoidal input of power due to the cosine law of solar panels (Anderson). The power in on the graph drops to zero when the spacecraft enters eclipse.

57

Figure 7.19: Power Out

In contrast , Figure 7.19 shows the power out as a function. As stated in Section 6.5, the

minimum power output is 2.76 W, and this is set as the default power out when the craft is not in eclipse. When in eclipse, the minimum power output is set to 4.72 W; the additional 2 W of power draw comes from running the heaters on full. As discussed in 7.4, running the heaters on full for the entire eclipse is an unlikely scenario but the CubeSat is more than prepared to handle that power draw if need be. The other two spikes in the power draw are examples of what would be considered standard orbital operations; the first spike is caused by a 20 minute transmission to earth and the second spike is caused by a 5 minute burn of the propulsion system while in eclipse.

58

Figure 7.20: Battery Charge

Figure 7.20 depicts the charge of the battery as a function of time. This graph was created

taking the difference of the power in and the power out, and adding or subtracting any surplus or deficit from the charge in the battery. Any charge over 10 Wh is not allowed as that is the capacity of the battery.

59

Figure 7.21: Excess Power

Illustrated in Figure 7.21 is the excess charge that the battery currently has stored. This

value has been calculated by taking the current charge in the battery and subtracting the minimum value of power need to make it through eclipse (calculated in Section 6.6). This figure was constructed to ensure that the CubeSat never entered eclipse with an inadequate amount of power. The star points on the graph represent the points at which the satellite enters eclipse, and as long as these points remain above zero, OSCAR will successfully endure eclipse. In the future, this graph will also allow the design team to optimize the timing of orbital operations by getting the design point( the star marker) as close to zero as possible.

60

7.6 Command and Data The system computer manages all orders for the various subsystems, calculates orbital

maneuvers, communicates with telecom, processing sensor images, and operates the capture and sensing devices. Besides the image processing, these processes are relatively simple; only a couple of MB/sec (Megabytes per second) of processing power is anticipated to be needed to successfully operate them. This means we have a great deal of additional processing power than can be directed towards our sensing system. OSCAR’s sensors operate by generating a point cloud image of the object in front of them. The Proton 200k Lite comes with a Field Programmable Gate Array, or “FPGA” for short. When paired with a processor capable of 3.3 BIPS (Billions of Instructions per Second), 320 x 240 pixel images can be rendered at a rate of 46 frames per second (Frame­rate Robust Stereo on a PCI Board). It stands to reason that processing power correlates proportionally with both the number of pixels generated, and the frame rate at which these pixels are updated. OSCAR’s sensors operate at a native resolution of 2592 x 1944 pixels. We can safely say that the computer will have more than 1 BIPS of processing power remaining for allocation to the sensors.

Figure 7.22: Frames per Second Calculated from FPGA Research

The team estimates that we can image the debris more than once every five seconds

during capture. This frame rate can be pushed even higher during the later stages of the mission by lowering the camera’s resolution, as camera resolution is only critical for accurate sensing of the debris. 7.7 Telecommunications

Validation of the telecommunications system consists of two parts. The first is verifying

that the transceiver and antenna combination will have both a transmission power strong enough to reach the ground and a low enough sensitivity to receive ground signals at any point during the mission. The second validation step involves calculating the expected communication time that the satellite will have with the ground station and using that information to determine the expected amount of data that can be transmitted during each ground pass. This number must be sufficiently large enough to transmit and receive the required data objects to complete the mission.

61

The transmission power received by a system is a function of the transmitter power, the antenna gains of both the transmitter and receiver, the wavelength of the transmission frequency, and the distance between the two objects. This is governed by the Friis equation, shown below,

(eq. 7.7.1) where Pr is equal to the power received, Pt is equal to the power transmitted, Gt is equal to the transmitter antenna gain, Gr is equal to the receiver antenna gain, λ is equal to the wavelength of the signal, and R is equal to the distance between the two objects. As the component specifications are shown in dBm on the log scale, a more useful form of the Friis equation can be seen below (Schroer).

(eq. 7.7.2)

Equation 7.7.2 can be used to calculate the power received at both the ground station and CubeSat. First, the distance between the satellite and the ground station must be determined. This is known as the slant range, which is a function of the spacecraft altitude, H, and the elevation angle, ε. Figure 7.22 shows a diagram of how the slant range is calculated, where the satellite represents our CubeSat and the target represents the ground station.

62

Figure 7.23: Calculation of Slant Range

The slant range can be calculated using the following equation (Schroer),

(eq. 7.7.3)

From here, a MATLAB script (Appendix C­1) was written to calculate the power received at the CubeSat when receiving a transmission from ground and the power received at the ground station when receiving a transmission from the CubeSat based on the altitude and elevation angle of the satellite. It can be see that the power received will be a minimum when the slant range is maximum. This occurs at the maximum altitude and lowest elevation angle. OSCAR is designed to be deployed at a maximum altitude of 800 km and we will assume that the minimum elevation angle required will be 5 degrees. This gives a maximum slant range of 2,366.88 km.

The Wallops, Virginia ground station was chosen as a viable option for our mission given its operating range in the UHF frequency band and current use with a number of CubeSat missions. Using the transmission power and gain of the ground station, in addition to the known gain of OSCAR’s antenna, with the maximum slant range, it was determined that the minimum power at the CubeSat would be ­84.55 decibel­milliwatts (dBm). In order to communicate, the power received must be more positive than the receiver’s sensitivity. The selected transceiver for

63

OSCAR has a specified sensitivity of ­104 dBm, which is lower than the minimum calculated sensitivity (ISIS). As the power received will only increase throughout the mission as lower orbits are reached, this ensures that OSCAR will be able to communicate with ground at every point of the mission life.

As a further consideration, the minimum ground station antenna gain was calculated for the maximum slant range and standard ground station transmission power of 100 watts. This was found to be 15 dBic, where dBic refers to the decibels referenced to a circularly polarized, theoretical isotropic radiator. This number is within the specifications of commercially available ground station kits, giving a second communication option rather than NASA based ground stations.

The second stage of the telecommunications system analysis involved calculating the estimated amount of data that could be uplinked and downlinked during one pass of the CubeSat over the ground station. It is assumed that there will be limited ground station access time for this mission, perhaps just once a day, so it is important to ensure that the selected transceiver will have adequate transmission rates.

Using an STK simulation with the Wallops, Virginia ground station as an example, the average transmission times for a single pass of the satellite were determined. This simulation can be seen in Figure 7.23, where the yellow field represents the area that the ground station can communicate with the satellite and the green line represents the CubeSat ground track.

Figure 7.24: STK Simulation of Ground Tracking

64

The simulation was run for a one year mission at inclination angles of 85, 86, 87, 88, 89,

and 90 degrees. STK provides the transmission time for every pass over the ground station, which was found to be between 500 and 700 seconds depending on which portion of the ground station field of view the ground track intersects with. Given the uplink data transfer rate of 1.2 kilobits per second (kbps) and the downlink data transfer rate of 9.6 kbps, the total amount of data that can be communicated in this time can be calculated (ISIS). This was found to be 75 to 105 kilobytes (KB) uplink and 600 to 840 KB downlink. OSCAR’s data communication needs are relatively small, as the primary mission is an engineering payload rather than a scientific one. Assuming that the mission will have access to a ground station for just one pass of the satellite once a day, the given data sizes calculated here will be sufficient to both send debris location information to the CubeSat and transmit telemetry and status back to ground. 7.8 Payload

7.8.1 Debris Sensing Device

Figure 7.25: Payload with Sensing System Deployed

Sensing parameters for analysis purposes come from a small COTS camera which utilizes

a common small charge­coupled device (CCD). Two major aspects of the sensing system required analysis to determine feasibility and overall usefulness. First, was the mechanical

65

feasibility involved with storing the cameras and deploying them. Second, was the optical feasibility which demanded enough resolution relative to the camera’s field of view to resolve 10 centimeter objects at a distance of 10 meters.

Mechanical analysis began by designing a mechanism which could be used to deploy the cameras in the constrained space of the payload unit. This was done with low detail but enough analysis to determine that such a mechanism would fit. This preliminary design made the assumptions that a sliding mechanism could be used, and that a nichrome or kanthal heat knife could be used to cut a plastic support which allowed a preloaded spring to actuate the mechanism.

(e.q. 7.8.1)

For this preliminary design, calculations alone were used for the optical analysis, rather than physical testing or simulation. According to equation 7.8.1, if the field of view (FOV) angle of the camera and resolution for any given direction are known, then one can determine the minimum resolvable dimension for any given distance. Our distance is 10 meters, and for analysis purposes we used the data from the Raspberry Pi Camera, with a 53.50 x 41.41 degree viewing angle and a 2592 x 1944 pixel resolution (“Camera”). Using those numbers, we obtain a minimum resolvable width of 3.6 x 3.7 centimeters. Of course, multiple pixels would be required to reliably detect an object with stereo vision. At of a distance of 10 meters, these cameras could detect a 10 x 10 centimeter object (which fits our target specification) with nine pixels.

7.8.2 Debris Capture Device

Inspiration for the net launch device came from microgravity testing conducted by the

ESA on parabolic flights of a scaled down net system for capturing large debris objects. Both a simulation and picture of one of the actual tests that was conducted can be seen below in figures 7.25 and 7.26. It was found that if small weights are connected around the perimeter of the net, they will tend to entangle themselves around the debris object on collision. This initial testing demonstrated that the nets entangled themselves so well that they needed to be cut from the debris model before conducting the next test (Want To Snag A Satellite).

66

Figure 7.26: ESA Net Entanglement Simulation (Want To Snag A Satellite)

Figure 7.27: ESA Net Entanglement Microgravity Testing (Want To Snag A Satellite)

From here, the team began work on the mechanical design of a part to house and launch the net from the top of the CubeSat. Due to the tight size constraints imposed by the 1U volume limit, it was determined that the net would need to be stowed in a folded, compact position until the capture stage of the mission is reached. Upon launch, it would need to be pulled open while traveling to the debris object before colliding and entangling around it. Figure 7.27 below shows a CAD model of the final part.

67

Figure 7.28: Net Device CAD Model

Referencing the image above, it can seen that there is an open area to hold an 18 x 18 inch net. Along the perimeter are four barrels that will each hold a small weight that is connected to the net through the channels that connect the barrels to the center cavity. These barrels are angled up and away from the model so that when the weights are launched from the structure they will pull the net out of the cavity, spreading it open as it travels towards the debris.

Two options were considered for the launching of the weights from the barrels, springs or a compressed gas charge. The spring system would feature a compressed spring within each barrel that would be released by using a burn resistor to melt a small Dyneema line. This would propel the weights out of the structure. The pneumatic system would utilize a small compressed gas reservoir behind the part with a solenoid valve. Flexible tubing would be used to distribute the gas charge to each of the four barrels. Upon opening the solenoid valve, the difference in pressure would cause the gas to quickly escape, launching the weights out of the barrels.

Throughout this design process, the team’s number one concern was reliability. If the debris capture device fails then the mission will be a loss as it will not be possible to capture a debris object. Because of this, the pneumatic launch system was chosen over the springs. The

68

pneumatic system has a single point of failure, the solenoid valve, while the spring system has four individual springs that could fail to deploy. With the selection of a highly reliable solenoid valve, this design would be extremely robust.

The final component of the capture device design is a small servo motor that will be housed behind the net launch part. This will be used to pull the debris object back to the CubeSat after entanglement. As OSCAR will be performing a retrograde burn for deorbit, there is a possibility that the satellite could collide with the recently captured debris object if it is loosely attached via the net. This could potentially result in the creation of additional space debris, which directly contradicts the mission. Pulling the object back to the satellite before performing the propulsion burn will ensure that this will not be an issue.

With the preliminary capture device design solidified, the project team decided to take this to the next stage of the design process by building a full­scale design model within a 1U CubeSat structure. This model can be seen in Figures 7.28 through 7.30 below. The net launch part and CubeSat structure were manufactured from ABS plastic using a 3D printing process. The model features all of the components of the capture device payload, including the compressed gas reservoir, solenoid valve, servo motor, and pneumatic tubing. This was used to validate our component layout and ensure that the entire system will fit within the 1U CubeSat volume. In addition to this, being able to see the physical structure allows for peer review and further design refinement before manufacturing a working prototype to perform net launch tests.

Figure 7.29: Full­Scale Net Device Model Isometric View

69

Figure 7.30: Full­Scale Net Device Model Front View

Figure 7.31: Full­Scale Net Device Model Side View

70

8 System Evaluation 8.1 Final System Overview

Figure 8.1 displays the final subsystem layout for OSCAR within the 3U structure. The sensors, debris retrieval device, and propulsion are all in a fixed location due to the actions that they need to perform, while the layout of the other subsystem components is flexible and should be based on the wiring schematic of the final design.

Figure 8.1: CubeSat Subsystem Layout

The final design conforms to the CubeSat standards for both weight and length

constraints. It will be compatible with the P­Pod deployment system. Figure 8.2 shows a final CAD rendering of OSCAR with the payload sensing system and antenna deployed. This is the configuration that the satellite will be in for the majority of the mission.

71

Figure 8.2: Complete CAD Rendering with Antenna and Sensing System Payload Deployed

8.2 Structures Of chief importance to evaluating the performance of the structure was ensuring that it

could successfully contain all of the other mission subsystems. After arranging all of the components in the structure using CAD, it was found that the structure could fit all of the components and subsystems without modification. Furthermore, after checking the structure against all of the CubeSat Design Specification requirements no conflicts or violations were found. Flight heritage serves to validate the structure, providing proof of its functionality and reliability. 8.3 Propulsion

After the analysis performed in section 7.2, the propulsion system has been determined to be capable of delivering OSCAR to targeted debris if it is placed in an initial orbit that is relatively close to the debris. After acquiring the debris, the propulsion system will be able to reduce the perigee of its orbit to at least 300 km as long as the proper target is selected for specific altitudes. The analysis shows OSCAR should attempt to avoid costly ∆V maneuvers when rendezvousing with the targeted debris and gives some example costs for certain maneuvers likely to be employed on a mission. If proper planning and monitoring of fuel resources are adhered to, then the propulsion system will be able to perform the necessary actions needed to succeed in deorbiting the targeted debris within the five year time limit imposed on the mission.

72

8.4 Attitude Control

Results from Section 7.3 indicated that OSCAR has a settling time of 70 seconds when performing a large rotational maneuver. This is not too surprising, since the maximum torque of the reaction wheels is 0.087 mNm. However, this settling time meets all mission requirements; it is not a slow enough maneuver time to put OSCAR in danger of failing the mission. Furthermore, if a future generation of OSCAR has large deployables, a slower settling time is desirable so that these deployable structures are not adversely affected by structural vibrations, bending, or any other potential hazard. The iADCS­100 also interfaces properly with external sensors through an I2C interface, which will allow for the integration of sun sensors or star trackers for improved pointing accuracy and redundancy. The magnetorquers on board the iADCS­100 provide further redundancy to those in the solar panel arrays, meeting the final requirement of the ADCS subsystem. 8.5 Thermal Management

After analysing the approximate heat flow in and out of the satellite, average minimum and maximum temperatures of the satellite were found to be 10.67 and 38.01, respectively. This falls within the acceptable temperature range of 5­40. Ideally, these minimum and maximum temperatures should fall closer to the middle of the optimum range. However, it should be noted that these temperatures will not be constant: the mean temperature of the craft will always be between these values, and it will not stay at any particular value for a long period of time. In addition, most components can function outside of their optimal temperature range. Although it is not ideal to keep the components outside their ideal operating range, long­term damage should not occur if the component is outside of its range for a short period of time. 8.6 Power

Using the analyzation methods described in Section 7.5, the power subsystem was found to meet all of the standards set for it. Even at a suboptimal angle and while rotating about the CubeSat’s z­axis, the solar panels are able to produce 10.41Wh excess per orbit (with no additional orbital maneuvers/operations). The battery’s 10Wh of charge are also able to meet all of our power storage needs by storing enough power to execute power intensive orbital operations while still maintaining all essential systems through eclipse. The requirements of the EPS are also met, as it contains the required amount of power outputs, provides overcharge protection to the battery, and is radiation tolerant. Additionally, all components of the power subsystem are manufactured by Clyde Space.

73

8.7 Command and Data

The computer’s I2C interfaces will function properly with all relevant system components, and it possesses more than enough processing power and memory to calculate orbital maneuvers. Typical sheets of data require memory on the order of less than 100 KB, and the only calculations that the computer must computer are the orbital maneuvers, which can be calculated quickly with negligible dedicated processing power. Given the native resolution of 2592 x 1944 pixels, the frame rate during capture can be pushed above 1 frame every 5 seconds. The computer is also radiation­hardened and flight­proven. 8.8 Telecommunications

The transceiver and antenna selected to makeup the telecommunications system have been confirmed to have a low enough sensitivity to receive transmissions from Earth based ground stations. OSCAR will be compatible with both large NASA ground stations, such as the Wallops, Virginia site, and commercially available portable ground station units. In addition, orbital simulations in STK have confirmed that the expected data sizes that could be transferred for one pass over a typical ground station will be 75 to 105 KB for uplink and 600 to 840 KB for downlink. Assuming that the mission will have access to a ground station for just one pass of the satellite once a day, the given data sizes calculated here will be sufficient to both send debris location information to the CubeSat and transmit telemetry and status back to ground. 8.9 Payload

8.9.1 Debris Sensing Device

Despite tough requirements imposed on the sensing system, simple and highly reliable

technologies can be combined to meet those needs without ambitious methods or rash assumptions. Any potential issues with this system can be tested before flight, as the operating environment does not impose challenges to the core technologies operational concepts. A simple CAD model verified that the deployment mechanism and cameras were able to fit around the debris capture device.

74

8.9.2 Debris Capture Device

The design that this team has completed for the debris capture device has been validated through the construction of a full­scale model to fit entirely within the volume of 1U. It has been shown to be adequate to hold a net large enough to capture the intended debris object. Furthermore, it has been proven to be manufacturable and feasible for use within the structure. This has laid the groundwork to move forward with building a working prototype of this design.

75

9 Future Work 9.1 Structures

Vibration testing should be performed with mass simulators or actual components to guarantee survival through launch with the exact distribution of components in the CubeSat. The heavy propulsion system in particular may pose a threat to the structure during launch, as its mass is quite large for a single unit. Fortunately, since CubeSats are defined by their structure, it is unlikely that much work will need to go into ensuring the structure’s practicality. CubeSat structure design is relatively simple, since the other subsystems must generally adapt to the structure, as opposed to large satellites where the structure must often adapt to the components. 9.2 Propulsion

Future work to be performed on the propulsion system analysis would be to account for maneuvers required during the close proximity rendezvous. This would be done using the solutions to Lambert’s problem to determine how much fuel would be required to perform the necessary maneuvers. The Clohessy­Wiltshire equation solutions will also need to be used in order to calculate the maneuvers OSCAR will have to perform while in the sensing range of the debris.

The model data for the deorbit maneuver needs to be updated and calculated for the MPS­130 system while also predicting how much fuel will be left for the burn based on rendezvous maneuvers performed earlier during the mission. Once these are determined, a more accurate assessment of OSCAR’s capabilities will become evident. 9.3 Attitude Control

Modeling of OSCAR’s control sequence will see some adjustments moving forward. In particular, the next phase of simulation involves changing the controller to output a voltage that will be sent to the reaction wheels to obtain a particular control torque. Current simulations are run with the controller outputting a control torque directly. In order to reliably simulate a voltage output from the controller, a simple test would have to be conducted to map the voltage across a reaction wheel to the torque it produces. By doing this, it would also be possible to more accurately simulate the power consumption of the reaction wheels during maneuvers. Furthermore, magnetorquers could be added into the simulation to more accurately model attitude control. Lastly, research will need to be conducted to determine the additional sensors that can be used for pointing accuracy such as star trackers and sun sensors.

76

9.4 Thermal Management

Future work on this subsystem would involve the use of thermal modeling software, allowing for a more complete and accurate thermal analysis to be performed on the entire satellite. Precise temperatures at every point of the satellite could be modeled, instead of an average temperature for the whole satellite. In addition, the satellite can be thermally modeled in all scenarios, not just minimum and maximum temperatures. This allows for a more detailed thermal model of the satellite at all times.

Radiation analysis would also be conducted, including but not limited to; amount of radiation the satellite takes in over the duration of the mission, effects of such radiation on the electrical components of the craft, and whether gradual bombardment of cosmic particles would degrade the components enough for the mission to fail. 9.5 Power

Continuation of the development of the power model constructed in Section 7.5 would greatly benefit OSCAR. Areas of expansion include developing an envelope of operation for the CubeSat, which would allow the control team to know what angles OSCAR is allowed to have to the sun vector before the power supply becomes unstable. The power model would also benefit from a full analysis of the umbra and penumbra of the Earth, as the shadow of the Earth is currently approximated as a cylinder instead of the conical shape it truly has. 9.6 Telecommunications

Continuing work on the telecommunications subsystem would include determining exactly what information will need to be transmitted from the CubeSat and ground to ensure mission success. From here, the form that this data will take can be developed in order to determine exactly how much data will be transmitted. Further, in depth analysis of Earth based ground stations could be conducted to choose the ideal location for communications to take place. Additional research could be devoted to assessing the viability of creating a dedicated ground station built from COTS hardware. 9.7 Command and Data

Additional work to be done on the command and data system centers around our memory and processing power budgeting. In the future, the team would like to run simulations of the mission with all the subsystems to verify our predictions regarding our memory and processing power allocation. While the team is confident that the system will not come close to exceeding

77

the 1200 MIPS budget, these sorts of tests are prudent in order to better verify the reliability of the design. Them team would like to begin developing and testing sensor software with our computing hardware to refine the design and ensure compatibility before flight. 9.8 Payload

9.8.1 Debris Sensing Device

As no COTS stereo vision system exists for CubeSats one must be fully developed and

tested to ensure success. Typically, the development of stereo camera systems is considered trivial, however, OSCAR’s would be complicated by the need to develop a means of deploying the cameras to achieve greater separation between them. Additionally, cameras would have to be selected which are small but high resolution to allow for detection at distance without large optics. Radiation tolerance would have to be tested and shielding may have to be created. Special attention will have to be paid to ensure electrical compatibility. Our computer offers plenty of general purpose electrical connections which, when routed to the FPGA, can facilitate CSI camera interfaces. But analog interfaced cameras may require a special circuit to be developed that would allow for the computer to capture the images.

9.8.2 Debris Capture Device Moving forward with the debris capture device, an ideal net material will need to be

determined before manufacturing a working prototype to perform microgravity net launch testing. From here, the design would be further refined in preparation for a flight model. It is expected that the flight model will likely be made of aluminum through a CNC milling or 3D printing process.

A cover system will also need to be developed to contain the net before the capture stage of the mission. Initial thoughts for this design include a spring­loaded, hinged cover held in place by a small Dyneema line. Redundant burn resistors could be used to melt this line and open the cover before capture.

Finally, upon successful demonstration of this design for capturing debris, additional applications could be explored, such as capturing a micrometeoroid for scientific analysis.

The important thing that the design team would like to emphasize is that we believe that the initial steps have been laid in the design of this capture device to bring a unit to production. With the creation of a full­size design model, we are now ready to manufacture a working prototype for testing before refining the design for a flight model.

78

9.9 General Aspirations

Moving forward, OSCAR will advance to further stages of analysis. This stage will incorporate all future work discussed in Section 9. Once this work is complete, OSCAR will advance to prototyping. At this point, all hardware must be purchased in order to create and test a full­scale model. It is also vital that system integration and compatibility is tested and confirmed. From a project management perspective, costs of all components need to be known. At this point, final costs of the CPU and propulsion system are unknown and must be determined to further assess the feasibility of continuing the development of OSCAR.

79

10 Risk Analysis

ID Risk Description

Probability

0 ­ 10

low→high

Severity

0 ­ 10

low→high

Priority

(PxS) Risk Response Plan

01 The propulsion system is still in development and is never made available.

4 8 32 Should the propulsion system never become available, the team is confident that a replacement system could be found. Aerojet Rocketdyne offers a similar model, the MPS­120, that could easily be implemented into our structure. As this system has a lower total delta­v, the CubeSat may be forced to operate in a lower orbit or decrease the maximum sized debris object that could be de­orbited, but we believe that the project could still be successful.

02 COTS hardware becomes obsolete before procurement to build flight prototype.

6 3 18 It is likely that the COTS hardware selected for this design may become obsolete before a flight prototype is built. This risk is deemed to be of low severity, however, as there is a large selection of replacement products that could be incorporated into the design.

03 There is limited opportunity for testing of the net launch system before flight, leading to the potential for mission failure.

2 8 16 The design team has built a full­scale design model of the net capture device in order to validate the component layout within the CubeSat U. The next step is to build a working prototype to test the net launch and debris entanglement methods. Should this design be moved forward, a secondary prototype could be built for testing in a microgravity environment. This is deemed to be a low probability risk.

80

04 All members of the design team may not be available to continue production if the design is chosen.

8 2 16 As members of the design team will be graduating, there is a possibility that if this design is chosen to move forward the entire team will not be available to continue work. The team has established secondaries for each subsystem and have completed a detailed design document to mitigate this risk.

05 High levels of radiation due to solar flares could result in premature failure of the mission.

4 6 24 In order to combat the chance that a solar flare could cause premature mission failure, the team will be employing a protective radiation coating in the design as well as radiation hardened processors and memory.

06 Hardware failure leads to loss of mission

2 10 20 Due to the small size of a CubeSat, it is difficult to build redundancy into the system. For this reason, the failure of a subsystem component could lead to mission failure. The team recognizes that this is a difficult risk to mitigate and plans to take a proactive approach by choosing flight tested COTS hardware with a proven record so that we can have confidence in each subsystem.

Table 10.1: Risks and Challenges

Table 10.1 presents the risks and challenges that the design team has identified at this stage of the project. Five technical risks have been identified, with the highest priority being that the propulsion system is not fully developed in time for a flight prototype. The team has also identified the risk of COTS hardware obsolescence, inadequate testing opportunities for the custom net launch system, and the possibility of solar flares or hardware failure resulting in the loss of the mission. Mitigation strategies have been identified for each of these risks in Table 10.1. The team has also identified a project management risk that, if the design is chosen, the entire team may not be available to continue development.

The design team is confident that the risks presented can be adequately mitigated using the techniques presented in Table 10.1 to ensure the overall success of the project and design.

81

11 Conclusions and Future Goals

As we reach the end of the preliminary design phase of this project, it is important to look back on what has been accomplished to date and what we expect to see in the future. Throughout the entire design process, this team has kept an extremely important concept in mind: reliability. We set the goal of creating a CubeSat system that will be able to rendezvous with a piece of debris, capture the debris, and de­orbit both itself and the debris within five years. Beyond this, our satellite design was built to be reliable and perform to specifications on every mission.

OSCAR is built around flight­proven, COTS hardware that has been shown to perform as designed in previous CubeSat missions. This team performed structural, power, thermal, data and communication analysis, in tandem with STK simulations, to determine the capabilities of OSCAR and ensure success in deorbiting target debris. This has proven the reliability of our design.

In addition to this, recognizing that there is no commercially available debris capture device for use, this team took it upon ourselves to design a custom net launch and capture payload for use on the mission. This design has been taken beyond an initial concept to a full­scale model for the purpose of validating component layout and ensuring manufacturability. The groundwork has been laid to build a working prototype for testing and bring this capture device to production.

With this in mind, we now believe that, in addition to reliability, another concept can be added to our design: feasibility. With further analysis and refining of the components, we know that OSCAR can be tested and brought to production. We foresee a future in which OSCAR CubeSats could be available at a moment's notice to send up as a secondary payload, which due to their highly autonomous nature, will be able to bring down debris objects effectively and safely. Over time, OSCAR will be able to have a significant impact on the amount of debris in orbit by removing the garbage in space.

We hope to pursue this design further with the goal of making this a reality in the near future.

82

12 Works Cited A Minefield in Earth Orbit: How Space Debris is Spinning Out of Control. Scientific

American, 2015. Web. 9 December 2015. http://www.scientificamerican.com/article/how­space­debris­spinning­out­of­control/

Aalto­1. Earth Observation Portal. Web. 9 7 December 2015.

https://directory.eoportal.org/web/eoportal/satellite­missions/a/aalto­1.

Anderson, Kurt. Spaceflight Mechanics Lecture Notes. Rensselaer Polytechnic Institute. November, 2015.

Bailey, Sheila and Ryne Raffaelle.”Space Solar Cells and Arrays” (2003).NASA Glenn

Research Center. Web. 2 Dec 2015. "Camera." ­ Raspberry Pi Documentation. N.p., n.d. Web. 11 Dec. 2015.

https://www.raspberrypi.org/documentation/hardware/camera.md Carpenter, C., Schmuland, D., Overly, J., and Dr. Masse, R. Test Results for the MPS­120

and MPS­130 CubeSat Propulsion Systems. (2011) Aerojet Rocketdyne. Web. 3 Dec 2015. CubeSat Database. Retrieved from Saint Louis University. 2015.

<https://sites.google.com/a/slu.edu/swartwout/home/cubesat­database>

Curtis, Howard D. Orbital Mechanics for Engineering Students. 3rd ed. New York: Butterworth­Heinemann, 2014. Print.

Deployable Antenna System for CubeSats. CubeSatShop. 18 Oct. 2015.

<http://www.cubesatshop.com/index.php?page=shop.product_details&category_id=6&flypage=flypage.tpl&product_id=66&option=com_virtuemart&Itemid=70>.

Friedel, Jonas, and Sean Mckibbon. "Thermal Analysis of the CubeSat CP3 Satellite." California Polytechnic State University, 7 June 2011. Web. 17 Nov. 2015. http://digitalcommons.calpoly.edu/cgi/viewcontent.cgi?article=1054&context=aerosp

Global Aerospace Corporation. Gossamer Orbit Lowering Device (GOLD) for Low­risk Satellite De­orbit. < http://gaerospace.com/projects/GOLD/index.html>

83

iADCS­100. Berlin Space Technologies. Web. 8 December 2015.

http://www.berlin­space­tech.com/index.php_id=43.html Isaac Nason, M. C. CUBESAT P­Pod Deployer Requirements. May, 2002.

<http://www.oh1sa.net/data/satellite/cubesat/P­POD­mk1/ppod_mk1_icd.pdf>

ISIS Small Ground Station Datasheet. Innovative Solutions in Space. June 2014. <http://www.isispace.nl/brochures/ISIS.GS.DS.v13.7%20Data%20Sheet%20Gound%20Station­1.pdf>

ISIS VHF downlink / UHF uplink Full Duplex Transceiver. CubeSatShop. 18 Oct. 2015.

<http://www.cubesatshop.com/index.php?page=shop.product_details&flypage=flypage.tpl&product_id=73&category_id=5&keyword=ISIS+TRXUV+VHF%2FUHF+Transceiver&option=com_virtuemart&Itemid=67>.

"Kapton® (Polyimide Film) Insulated Flexible Heaters." Kapton Heaters. Omega Engineering, 2015. Web. 19 Oct. 2015. <http://www.omega.com/pptst/KHR_KHLV_KH.html>

Longo, Carlos and Rickman, Steven. “Method for the Calculation of Spacecraft Umbra and Penumbra Shadow Terminator Points” . NASA Technical Paper 3547. Published April 1995. Web. 11 Nov 2015.

Mehrholz, D., and L. Leushacke. "Precision Tracking and Imaging of Orbital Debris." Space Programs and Technologies Conference and Exhibit (2002): n. pag. European Space Agency. Web. 11 Dec. 2015.

NanoCom Communication Modules. GOMSpace. 18 Oct. 2015.

<http://www.gomspace.com/index.php?p=products­ax100> National Reconnaisance Office. Retrieved from Big Innovations Start Small...:

<http://www.nro.gov/about/innovation/2013­05.pdf> Navigation for Weapons. Federation of American Scientists. Web. 9 December 2015.

http://fas.org/man/dod­101/navy/docs/es310/GPS/GPS.htm

84

Oung, Raymond and Raffaello D’Andrea. The Distributed Flight Array: Design, Implementation, and Analysis of a Modular Vertical Take­off and Landing Vehicle. The International Journal of Robotics Research. Sage Publications, 24 April 2014. Web. 2 December 2015. http://ijr.sagepub.com/content/33/3/375.

Parabolic Arc. JAXA Develops Electrodynamic Tether to De­orbit Space Debris. Jan 20, 2015. <http://www.parabolicarc.com/2014/01/20/jaxa­develops­electrodynamic­tether­deorbit­space­debris/>

Poley, Bob. Orbital Mechanics for Thermal Engineers. University of Colorado Boulder.

Published 20 Nov. 2002. Accessed 23 Nov. 2015. Schmuland, D., Carpenter, C., and Dr. Masse, R. Mission Applications of the MPRS­142

CubeSat High­Impulse Adaptable Monopropellant Propulsion System (CHAMPS). AIAA 2012­4269. Web. Oct. 2015. <https://www.rocket.com/files/aerojet/documents/CubeSat/AIAA­2012­4269.pdf>

Schmuland, D., Masse, R., and Sota, C. Hydrazine Propulsion Module for CubeSats. SSC11­X­4. Aerojet Web. Oct. 2015. <https://www.rocket.com/files/aerojet/documents/CubeSat/SSC11­X­4.pdf>

Schroer, Matthew P. Naval Postgraduate School. NPS­SCAT: A Cubesat

Communications System Design, Test, and Integration. June, 2009. Some useful information about CubeSats. Retrieved from Clyde Space. 2015.

<http://www.clyde­space.com/cubesat/som_useful_info_about_cubesats> "Spacecraft Thermal Control and Conductive Paints/Coatings* and Services Catalog."

AZ Technology. Web. 26 Oct. 2015. <http://www.aztechnology.com/pdfs/materials­catalog.pdf>

UHF Turnstile Antenna. GOMSpace. 18 Oct. 2015. <http://www.gomspace.com/index.php?p=products­ant430>

Von Herzen, B., Woodfill, J., and Zabih, R. Frame­rate Robust Stereo on a PCI Board.

Cornell University. Web. 2 Dec 2015. <http://www.cs.cornell.edu/rdz/Papers/Archive/fpga.pdf>

85

Want To Snag A Satellite? Try A Net. European Space Agency. <http://www.esa.int/Our_Activities/Space_Engineering_Technology/Clean_Space/Want_to_snag_a_satellite_Try_a_net>

86

Appendix A: Specification Sheets A­1 Command and Data Computer System

87

88

A­2 Attitude Control System

89

90

91

92

93

94

95

96

97

A­3 Telecommunications System

98

99

100

A­4 Power System

101

102

103

A­5 Propulsion System

104

105

Appendix B: Component List and Cost

Component Manufacturer Model Volume Mass Cost Power

CPU Space­Micro Proton200k Lite .15U .2 kg $100,000 1.5 W

ACS Berlin Space Tech.

iADCS­100 .33U .345 Kg $154,000* 1.8W (max)

Transceiver Innovative Solutions in

Space

ISIS VHF downlink/UHF

uplink Full Duplex Transceiver

.15U .085 kg $9,500 1.7W (max)

Antenna GOMspace UHF Turnstile Antenna

.02U 0.030 kg $6,150 2W (max)

Heater Kapton KHLV­0502/2 negligible (.000127U)

negligible $36 2W (max)

Solar Panel Clyde Space 3U Side panel NA 0.676 kg $24,000 N/A

Battery Clyde Space 10 Wh 0.09U 0.156 kg $1,800 0.2W

EPS Clyde Space 3G Flex EPS. 0.15U 0.086 kg $13,500 TBD (minimal)

Structure Innovative Solutions in

Space

3U Structure N/A 0.286 kg $4,000 N/A

Propulsion System

Aerojet Rocketdyne

MPS­130 1U 1.6 kg TBD** TBD (estimated

1W)

*ACS cost is approx. $82,500 with only basic software package on board. **Propulsion System cost is yet to be determined as the product is in development

106

Appendix C: MATLAB Code C ­ 1 Telecommunications

The following MATLAB code was used to calculate the minimum CubeSat and ground station sensitivity given the altitude, elevation angle, transmitting frequency, antenna gains, and power outputs. Re = 6378.1; %Earth radius [km] H = 800; %altitude [km] e = 10; %elevation angle [degrees] f_t = 160; %downlink frequency [MHz] f_r = 2700; %uplink frequency [MHz] G_c = 1.5; %cubesat antenna gain [dBi] G_g = 35; %ground antenna gain [dBi] P_c = 22; %cubesat power [dBm] P_g = 50; %Ground station power [dBm] lambda_t = 3e8/(f_t*106); %downlink wavelength [m] lambda_r = 3e8/(f_r*106); %uplink wavelength [m] D = (Re2+(Re+H)2­2*Re*(Re+H)*cosd(180­(90+e)­asind((Re*sind(90+e))/(Re+H)))).5; %slant range [km] S_r = P_g + G_c + G_g + 20*log10(lambda_r/(4*pi*D*1000)); %uplink power at cubesat [dBm] S_t = P_c + G_c + G_g + 20*log10(lambda_t/(4*pi*D*1000)); %downlink power at ground station [dBm] fprintf('Maximum slant range is D = %0.2f km\n\n', D) fprintf('Minimum cubesat sensitivity = %0.2f dBm\n\n', S_r) fprintf('Minimum ground station sensitivity = %0.2f dBm\n\n', S_t)

107

C ­ 2 Thermal Management

This MATLAB code calculates four different average internal temperatures of the spacecraft: maximum heat generated in full sunlight, minimum heat generated in full sunlight, maximum heat generated in eclipse, and minimum heat generated in eclipse. See section 7.4 for further explanation. As = .3405*.1; %Side area m2 Asolar = .3*.09; %Solar panel area (per side) m2 Asc = As­Asolar; %Side area, thermal coating m2 Atb = .12; %Top/bottom area m2 Aopen = .082; %Open area (only on top) m2 Aprop = .012; %Open area (bottom) m2 Atc = Atb ­ Aopen; %Top area, thermal coating m2 Abc = Atb ­ Aprop; %Bottom area, thermal coating m2 alphas = 0.8; %Absorptivity, solar panel alphac = 0.1; %Absorptivity, thermal coating epss = .85; %Emissivity, solar panel epsc = .9; %Emissivity, thermal coating epso = 1; %Emissivity, open %Qsun W Gs = 1366; %W/m2 Gse = 0; %W/m2 Qsun = Gs*(Asolar*alphas + Asc*alphac); %W Qsune = Gse*(Asolar*alphas + Asc*alphac); %W %Qir W Gir = 260; %W/m2 Qir = Gir*(Asolar*epss + Asc*epsc); %W/m2 %Qalb W Galb = Gs*0.3; %W/m2 Galbe = Gse*0.3; %W/m2 Qalb = Galb*(Asolar*alphas + Asc*alphac); %W Qalbe = Galbe*(Asolar*alphas + Asc*alphac); %W Qgenmax = 14.7; %W Qgenmin = 2.72; %W Qemit1 = Qsun + Qir + Qalb + Qgenmax; %W Qemit2 = Qsun + Qir + Qalb + Qgenmin; %W Qemit3 = Qsune + Qir + Qalbe + Qgenmax; %W Qemit4 = Qsune + Qir + Qalbe + Qgenmin; %W sig = 5.6703*10­8; %W m−2 K−4 Aesig = (4*(Asolar*epss + Asc*epsc)+ Atc*epsc + Abc*epsc + Aopen*epso + Aprop*epso)*sig; % WK−4

108

%Qemit = Aesig*T4 W %Solve for T, convert from Kelvin to Celsius T1 = (Qemit1/Aesig).25 ­273.15 %Degrees Celsius T2 = (Qemit2/Aesig).25 ­273.15 %Degrees Celsius T3 = (Qemit3/Aesig).25 ­273.15 %Degrees Celsius T4 = (Qemit4/Aesig).25 ­273.15 %Degrees Celsius C ­ 3 Power

This MATLAB code takes in the qualities of the components in the power system as well as the orbital parameters and returns graphs indicating how OSCAR will perform in orbit. %Power Sim %Assumptions %­Circular Orbit %­BOL efficiency clear close all %% Constants e=0; %eccentricity a=7171; %semi major axis, km mu=398600.4418; %gravitational parameter, km3/s2 Re=6371; %radius of earth in km h=a­Re; % coords start on sun vector inc=1.4835; %orbital inclination, 85 degrees omega=0; %long of ascending node power_base=7.29; %max power production, watts batt_charge=10; %watt hours %beta calc %ref nasa presentation GAMMA=0; %vernal equinox epsilon=23.45*pi/180;%obliquity of the earth ecleptic beta=asin((cos(GAMMA)*sin(omega)*sin(inc))­(sin(GAMMA)*cos(epsilon)*cos(omega)*sin(inc))... +(sin(GAMMA)*sin(epsilon)*cos(inc))); %power draws %in watts tel_com_max=3.7;

109

tel_com_min=0.22; prop_max=5; prop_min=0; comp=1.5; power_max=0.7; power_min=0.5; acs_max=1.8; acs_min=0.15; therm_max=2; therm_min=0; %draw scenarios max_draw=14.7; min_draw=2.72; %nothing "on": 2.72 %prelim calcs T=2*pi*(a(3/2))*(mu(­1/2)); %period in secs %calculations for 1 revolution %%%Power In %numerical integrate power t_step=400; %number of time steps [power_in_vec,power_out_vec]=deal(zeros(t_step*2,1)); batt_charge_vec=zeros(t_step*2,1); tis=T/t_step; %time in step (in secs) del_theta=pi/t_step; %change in orbit angl each step(rads) step_draw=(min_draw*tis/3600); %charge draw per step w*hr gamma=acos(Re/a); num_revs=3; revs=1; rot_vel=0.1; %radians/sec rot_vel_rel=rot_vel*tis; theta_cos_1=pi/2; theta_cos_2=0; %eclipse draw f_ec=(1/pi)*acos(sqrt((h2)+2*Re*h)/((Re+h)*cos(beta))); %time fraction in eclipse(based on beta angle if isreal(f_ec)==0 disp('Satellite is always in sun'); charge_ec=0; else T_ec=T*f_ec; %time in eclipse charge_ec=min_draw*(T_ec/3600);%charge needed to make it through eclipse end

110

while revs<=num_revs k=0; %iterator nu=0; %angle in orbit, 0 is 'sunrise' rev_charge=0; %power gained this revolution while k<=t_step*2; step_charge=0; if nu<=(pi+gamma) || nu>((2*pi)­gamma) % Power In min_draw=2.72; theta_cos_1=theta_cos_1+rot_vel_rel; theta_cos_2=theta_cos_2+rot_vel_rel; step_power=abs(power_base)*(abs(cos(theta_cos_1))... +abs(cos(theta_cos_2))); %watt step_charge=cos(0)*step_power*tis/3600;%end is adding rotational velocity rev_charge=step_charge+rev_charge; power_in_vec(k+1)=step_power; elseif nu>=(pi+gamma) || nu<((2*pi)­gamma) min_draw=4.72; if nu<=pi+gamma || nu>=0.01*(pi+gamma) aa=k; end end %%% Power out if k>=500 && k<=520 step_out=7.4; step_draw=(7.4*tis/3600); elseif k<=200 && k>=120 %5 min burn minute transmission step_out=7.4; step_draw=(7.4*tis/3600); else step_out=min_draw; step_draw=abs(min_draw*tis/3600); %charge draw per step w*hr end batt_charge=batt_charge+step_charge­step_draw; if batt_charge>=10 batt_charge=10; end power_out_vec(k+1)=step_out;

111

%progress nu=nu+del_theta; batt_charge_vec(k+1)=batt_charge; k=k+1; end %%% Power Out % batt_charge=batt_charge­min_draw; % batt_charge=batt_charge+rev_charge; %Plot stuff % figure(1) %power in vs timestep figure(1) subplot(2,2,1) title('Power In') xlabel('Timestep') ylabel('Power In (W)') plot((t_step*2+1)*(revs­1):t_step*2+(t_step*2+1)*(revs­1),power_in_vec) hold on % figure(2) %Battery Charge figure(1) subplot(2,2,2) title('Battery Charge') xlabel('Timestep') ylabel('Battery Charge (W*h)') plot((t_step*2+1)*(revs­1):(t_step*2+(t_step*2+1)*(revs­1)),batt_charge_vec) hold on figure(1) subplot(2,2,3) title('Power Out') xlabel('Timestep') ylabel('Power Out (W)') plot(((t_step*2+1)*(revs­1):t_step*2+(t_step*2+1)*(revs­1)),power_out_vec) hold on %excess power calculated by subtracting the amount of power left by the %minimum power needed to make it through eclipse figure(1) subplot(2,2,4) title('Excess Power') xlabel('Timestep')

112

ylabel('Excess Charge (W*h)') axis([0 t_step*revs*2.5 ­1 10]) plot((t_step*2+1)*(revs­1):t_step*2+(t_step*2+1)*(revs­1),(batt_charge_vec­charge_ec*1.5)) hold on revs=revs+1; %progress end C­4 Attitude Control

This MATLAB code, called OSCAR_Script, was used to operate Simulink files called “OSCAR_Sim”, “OSCAR_Sim_Gyro”, and “OSCAR_Sim_KF.” % Space Vehicle Design ­ CubeSat Design Project % Team 3: Obsolete Satellite Capture and Removal [OSCAR] % % Jake Adzema % Alex Austin % Austin Kubiniec % Colin Lenhoff % Alexander Malin % Ryan Moriarty % Jesse Pelletier % %This script is used to simulate attitude control of the OSCAR CubeSat %using Space­123 transformations close all; clear all; clc; %% Time Parameters T0 = 0; Tstep = .2; Tfinal = 80; %For discrete­time Simulink simulation %% CubeSat Parameters Ixx = 0.03; Iyy = 0.03; Izz = 0.006; % Define non­diagonal terms I_matrix = [Ixx, 0, 0; 0, Iyy, 0; 0, 0, Izz]; I_inv = inv(I_matrix); %% Reaction Wheel Parameters J_full = 1e­6.*[ 204.1 77.71 ­1.19 ; ... ­77.71 185.1 ­1.85 ; ... 1.19 1.85 351.9 ];

113

J_cg = diag(J_full); Max_Torque = .000087; Sat_Mom = 0.0015; %% Attitude Parameters %[roll; pitch; yaw] = [gamma; beta; alpha] gamma0 = 90*pi/180; beta0 = ­165*pi/180; alpha0 = 120*pi/180; init_angles = [gamma0; beta0; alpha0]; p0 = 0; q0 = 0; r0 = 0; rates0 = [p0; q0; r0]; EA1=init_angles(1); EA2=init_angles(2); EA3=init_angles(3); C11=cos(EA2)*cos(EA3); C12=cos(EA2)*sin(EA3); C13=­sin(EA2); C21=sin(EA1)*sin(EA2)*cos(EA3)­cos(EA1)*sin(EA3); C22=sin(EA1)*sin(EA2)*sin(EA3)+cos(EA1)*cos(EA3); C23=sin(EA1)*cos(EA2); C31=cos(EA1)*sin(EA2)*cos(EA3)+sin(EA1)*sin(EA3); C32=cos(EA1)*sin(EA2)*sin(EA3)­sin(EA1)*cos(EA3); C33=cos(EA1)*cos(EA2); q0_4 = 0.5*sqrt(1+ C11 + C22 + C33); q0_1= (C32 ­ C23)/(4*q0_4); q0_2= (C13 ­ C31)/(4*q0_4); q0_3= (C21 ­ C12)/(4*q0_4); init_quats = [q0_1; q0_2; q0_3; q0_4]; desired_pos = [0; 0; 0]; desired_rates = [1*pi/180; 1*pi/180; 1*pi/180]; %i.e., ephemeris data %% Noise Parameters noise_01 = 1; % 0/1 for off/on of gyro sensor noise gyro_mean = 0; %Gyro bias s_gyro = 5e­2; %Standard deviation of gyro noise s_gyros = s_gyro.*ones(3,1); M_e = [0; 0; 0]; %External disturbance torques

114

%% Kalman Filter Parameters P_k0 = 0.5; process_noise = 1e­8; %Mechanical or disturbance noise (small) %% Control Parameters Kq = 5.*[1; 1; 1]; %Quaternion gain Kw = 29.*[.8; 1.2; 1]; %Angular rate gain %% Simulation sim('OSCAR_Sim_KF'); %OSCAR_Sim_Gyro and OSCAR_Sim_KF for gyro and Kalman filter, respectively PrintGraphs The following function, called PrintGraphs, was called in the OSCAR_Script function to print the data collected in the Simulink simulations. ts = T0:Tstep:Tfinal; %Defined in OSCAR_Script figure; plot(ts, Err_Quats_Data(:,2), 'b', 'LineWidth', 1.5); hold on; plot(ts, Err_Quats_Data(:,3), 'g', 'LineWidth', 1.5); hold on; plot(ts, Err_Quats_Data(:,4), 'r', 'LineWidth', 1.5); legend('q1', 'q2', 'q3'); title('Error Quaternions: Sensor Noise \sigma = 0.05 Radians/Second with KF'); %Example title xlabel('Time (Seconds)'); ylabel('Quaternion Error (Radians)'); grid('on'); figure; plot(ts, Rates_Data(:,2), 'b', 'LineWidth', 1.5); hold on; plot(ts, Rates_Data(:,3), 'g', 'LineWidth', 1.5); hold on; plot(ts, Rates_Data(:,4), 'r', 'LineWidth', 1.5); hold on; legend('\omega_1', '\omega_2', '\omega_3', 'Location', 'southeast'); title('Body­Frame Rates: Sensor Noise \sigma = 0.05 Radians/Second with KF'); %Example title xlabel('Time (Seconds)'); ylabel('Body­Frame Rates (Radians/Second)'); grid('on');

115

Appendix D: Supplementary Figures

Figure D.1: Control System Block Diagram.

116

Appendix E: Team Member Contributions Jake Adzema ­ 5.1.1, 5.5, 6.4, 7.4, 8.5, 9.4, C­2 Alex Austin ­ 4, 5.8, 5.9.2, 6.7, 6.8.2, 7.7, 7.8.2, 8.8, 8.9.2, 9.7, 9.8.2, 10, 11, C­1 Austin Kubiniec ­ Table of Contents, List of Figures, List of Tables, 2, 5.7, 6.6, 7.6, 8.7, 9.6 Colin Lenhoff ­ Executive Summary, 5.3, 6.2, 7.2, 8.3, 9.2 Alexander Malin ­ 5.2, 5.9.1, 6.1, 6.8.1, 7.1, 7.8.1, 8.2, 8.9.1, 9.1, 9.8.1 Ryan Moriarty ­ 3, 5.1.2, 5.6, 6.5, 7.4, 8.1, 8.6, 9.5, C­3 Jesse Pelletier ­ 1, 5.4, 6.3, 7.3, 8.4, 9.3, 9.9, C­4

117